计算广告2.0-Lecture03-认识商业化体系

摘要: 计算广告2.0, 关于商业化体系

【对数据分析、人工智能、金融科技、风控服务感兴趣的同学，欢迎关注我哈，阅读更多原创文章】
我的网站：潮汐朝夕的生活实验室
我的公众号：潮汐朝夕
我的知乎：潮汐朝夕
我的github：FennelDumplings
我的leetcode：FennelDumplings

---

1. 计算广告的整体计算框架和里面的关键的算法问题
2. 计算广告里面的产品相关关键问题
3. 产品中用到的供需接口的各种形式，SDK, API等
4. 系统架构，如何用开源工具架起来

解决问题的第一步，把指标写成一个可量化的式子

k 的意义：每一个 k 代表一个合同

特点：

1. 优化的是利润
2. 有约束：

一个广告合同的常见约束：

预算限制：即最多推多少钱
投放量的限制：最少推多少次展示量

广告业务的转化漏斗与目标

点击和转化是在不同的地方发生的

优化的重点：r 即收入，eCPM 千次展示的收入，成本一般不用单独优化

优化 eCPM 的时候先把用户的转化漏斗画出来，分段优化

eCPM 是广告业务的最重要指标，所有的广告排序都用它

点击率：ad, user, context 的函数

点击单价：ad, user 的函数

ad: id
context: url
user: 比较复杂

user 如何表示

1. PC web / Mobile web 环境(http环境)中，用 cookie

问题：存续性差，用户可以主动清除，移动端更严重，不同APP可能在app 内打开浏览器/网页，不同应用之间无法串在一起

跨域需要映射

1. iOS 应用里

IDFA:存续性好于 cookie，删除它的用户不多，iOS10有更严格的政策(用户不让用就)

1. Android 应用里

Android ID: 存续性好于 IDFA, 中国有部分应用使用的是使用, 但国外不允许(获取不了)

1. 无以上场景

FingerPrint(IP+User Agenr): 存在于 http 头中。user agent：操作系统和浏览器的版本

准确成都低，因为 IP 和 User Agent 经常变

商业化体系六大算法问题

都是优化问题，底下有哪些算法问题：

1. 仅仅用号标识用户，不太好估计 eCPM，需要一些加强的东西 -> 提取用户的一些特征(用户画像)
2. 估计每一个 ad 的 r 是多少 -> 转化为点击率的估计
3. 式子中看不出来的是存在宏观的博弈(广告主和媒体优化的目标不一样)，广告主会调整出价，双方都相对满意达到稳态才是有意义的
4. 由于有 constrain 的存在，带约束优化，在计算广告中叫在线分配
5. 所有的互联网应用中都广泛存在，探索与利用。新广告，新用户，新媒体，(广告，用户，媒体)的组合无穷无尽，没出现的组合靠猜去猜 eCPM 是猜不太准的，有意识地去给用户一些它没看过的广告，看看效果怎么样，但是这个过程会损失收入，它的目的是获取之后的更好的收入，但是当前解决的不好，只有一些 naive 的方法还算 work，advanced 方法在普适意义下都不太好
6. 个性化推荐。在商业化体系中非常常见。

解决以上6个问题需要从两方面努力

1. 研究算法，研究数据
2. 广告/传播本身 -> 设计相应的技术使得传播效率提高

参考传播学的模型，理解用户的决策过程

用户决策的转化漏斗模型

曝光：物理上能看到 -> 取决于广告位的天然属性。具备极强属性的例子：北京东三环的大楼墙面。
关注：心理上也要看到 -> 1. 不打断用户的任务(上下文定向的原理) ； 2. 明确揭示给他推荐的原因, e.g. 同城/以前看过；3.符合用户兴趣
理解：试图理解，在用户的认知之外则用户不理解 -> 与用户的个性有关
信息接收：理解了不一定认可 -> 与媒体和广告主的品牌均有关系(不太容易通过技术改变)
保持：如果是品牌广告，希望长时间记住(强调艺术性)
购买：如果是效果广告，希望马上购买(动用一些价格敏感的操纵因素，例如打折)

一些传统广告策略的效果以及在哪个环节起作用了

幽默：对关注大大提高(看到好玩的东西都是想看看)，但是提高了理解门槛(要幽默，话就不能只说)
性感：美女图，刺激关注。但对信息接受有负面，有一些人认为这些东西是负面的，有些人无所谓
艺术：提高用户长时间的保持，但是使得理解变得困难。例如益达口香糖的广告，对益达印象非常深，但是至今不知道那个广告在讲什么
折扣：对关注和购买都有作用，但是折扣与前面三个的区别是要付出成本的

在线广告的主要结算方式

CPT: T 是 time，适合需要强曝光的场景
CPM: M 是 Million，千次展示
CPC: 比较合理，因为点击的行为发生在媒体侧。广告主估计点击单价然后报给媒体，媒体拿到一系列报价后估计自己的点击率
CPS: 供给方估计点击率和点击单价，不普适，存在问题

一头沉的模式 1, 2, 4：都需要第三方监控

互联网广告 DSP（Demand-Side Platform），就是需求方平台。这一概念起源于网络广告发达的欧美，是伴随着互联网和广告业的飞速发展新兴起的网络广告领域。它与 Ad Exchange 和 RTB(实时竞价) 一起迅速崛起于美国

CPA/CPS 的问题与合理的场景

问题：

1. 供给方同时负责优化点击和转化率，广告主的网站做得差，使得媒体提供了2万的点击量但是一个都没买，这个媒体优化不了
2. 媒体因为优化不了，所以可能会搞灰色手段，比如劫持，代销等
3. 用于优化的数据对单个广告主来说严重不足

适用的场景：

1. 转化流程一致且规范的市场
2. 例如：淘宝客(转化流程为淘宝统一提供)；APP下载(转化流程在Apple Store或Google Play)

oCPM 和 CPA

optimized CPM : Facebook 提出的一种新的结算模式：创造性的做了以下事情，是一种产品侧的优化：
按照 CPM 结算，但是按照 CPA 来优化
初始时候，按照CPM结算，但是广告主把A(action) 接给媒体，媒体按照 CPA 优化，优化一段时间有效果了，再把 CPA 的接口打开
最终还是为了 CPA，oCPM 是过渡，本质是优化 A，但是通过 oCPM 这个过渡控制了风险

开放式思考题

社交网络中的传播营销与广告营销区别在哪里，应该如何建模?

oCPM 和 CPM 在技术上有何区别?

商业产品设计运营原则

商业产品：面向商业客户，最典型的代表是广告产品

相对于产品功能，特别关注产品中的策略部分

特别关注数据，让运营和产品优化形成闭环。所有产品特征和策略的成功与否，要严格根据数据的反馈来判断。用户产品里面有感性的部分，商业产品是理性的。

优化的是确定的商业目标，而非使用便捷性

数据驱动的商业产品发展历程

各种产品出现的背后逻辑：利用数据的深度和广度要求越来越高

首先产生的是 CPT
为了变现男女这种人口属性，改为了展示量合约广告，得到一定溢价
竞价广告是最重要的里程碑，对数据的精细加工程度有了质的飞跃
程序化交易的目的是变现第一方数据和第三方数据
场景数据：移动端的变现要特别注意场景，(用户拿着手机在干什么) PC 时代没有场景的概念

商业化产品体系六大产品问题

1. 供需接口
2. 竞价机制(算法研究只是一方面，动态比价，价格挤压等在产品侧有调整的空间)
3. 数据化运营
4. 标签体系 (用户画像体系，targeting)
5. 程序化交易
6. 原生广告 (移动端的重要问题，怎样让所有广告位都利用到)

供需接口 - 需求方层级组织

广告活动：对应于广告主的一次投放合同，其中高括了预算，时间范围等基本信息
广告组：对应于一个具体的广告投放策略，主要是设定手中定向条件和出价
广告创意：最终展示出来的素材，可能在同一组策略下有不同尺寸的创意存在

供需之间的各种对接方式

合格的产品经理必须把各种对接方式搞透彻，什么时候该用哪个

开放性思考题

1. 媒体应该如何选择 SDK/API/RTB 这几种方式对接广告主
2. 向需求方(广告主)提供 API 与 UI 投放(手动)相比，有何优劣

商业化产品 — 系统框架

个性化系统一般框架

投放引擎：处理请求，返回结果

投放引擎特点：

• 高并发：DSP 每天处理上百亿次 ad request 不稀奇
• 低延迟：必须 10ms 以内

数据高速公路特点：

• 数据量吞吐量极大
• 对数据一致性要求不那么高，数据丢了千分之一往往对业务没什么影响

在线计算 — 流计算平台 spark

离线计算 — 海量数据挖掘 hadoop ，迭代式计算场景也要用到 spark

搜索，广告，个性化推荐 — 全网范围的技术问题

安全性：如何保证广告的内容不是虚假的
质量：如何保证展示的东西与媒体的调性是符合的，不对媒体的形象造成负面影响

广告系统的特点

1. 高并发低延迟同时存在，并且是刚需
2. 数据处理的规模很大：(用户，环境，信息) / (a, u, c) 三元组上的数据建模。某种程度上还高于搜索，搜索只是在二元组(query , document)上建模
3. 数据处理的速度优先于精度。用户想买鞋，需要快速把信息送到决策引擎上，如果为了更精确地知道用户想买耐克还是阿迪，决策慢了，用户的兴趣就失效了
4. 主流程的一致性要求不高 (丢千分之一的数据或者千分之一的请求超时，对业务没什么影响。作为对比，交易数据一笔都不能错)

要设计成本可控，效果还不错的广告系统，关键是后两点，因为前两点大部分人都能看到

广告系统的设计原则

1. 弱一致性系统的设计思维方式。例如：Near-line page fetcher
2. 大量数据尽量环形单向流动，避免集中读写形成的单点性能瓶颈
3. 在线时不要发生与关系型数据库的交互 — 增删改查的传统需求在广告系统里实际不存在。广告系统在数据库方面的需求的特点：批量写，高并发随机读
4. 充分利用开源社区的成熟技术

开源软件的优势和顾虑

优势

1. 大量细分使用场景都有开源方案
2. 大型互联网公司的开源产品经过充分测试

顾虑

1. 需要仔细甄别好的和不太好的开源项目
2. 在遇到深层次 bug 时无能为力

核心业务逻辑不应该选择开源：对广告来说，是广告的排序和检索的算法，不要用开源的。

商业化产品系统架构统一框架

图里的骨架基本都可以用开源的东西

商业化系统的开源架构

中间的广告检索，广告排序，不可用开源的(广告检索也可以用开源ES，但现在有些排序的东西放在检索里做的倾向)
左下角的ETL部分是关系型的部分，但是这里已经是离线侧了
Thrift: 数据高速公路方案，同时有跨语言的能力(Protobuf也可以跨语言)
Hadoop 上：模型的优化工具可以用开源的，但是模型怎么建，数据流怎么建需要工程师做
Spark 只是做计算用，代替不了 Hadoop 存储的作用
左边并排的3个Redis作用是缓存：存的是点击率模型的参数，点击率用到的特征，用户的标签等。不是现算的
右边的 storm/spark：在线计算，例如实时反馈，计费，反作弊等
Thrift 与在线计算的相连：Kafka
在线计算的结果同样放在 Redis 供线上使用
右上角广告库：通过管理界面填写进来的广告组等，用到关系型。线上与用倒排索引(Lucene/ES)，不与关系型数据库打交道。

广告系统拆解成12部分

计费模块

1. 在线计费：做预算控制
2. 离线计费：做财务结算

因为在线的反作弊策略比较粗，离线可以很详细，所以结果不一样

商业化产品六大系统技术

广告产品优化目标分解

开放式问题：如何估算你的广告系统的硬件成本

---