文章目录

广告商业形态
- 深思广告到底是什么？
- - 互联网广告市场形态
  - 互联网平台角色
  - 流量售卖方式
  - - 非合约式
    - 合约式
- 平台流量收益最大化
- - 广告位分配
  - 流量分配
  - 广告样式
  - 实时竞价
  - - 第二竞价
广告应用架构
- 全局链路架构
- - Adapter 适配
  - ADX 核心
  - Storage 存储
  - Depend 依赖
  - Platform 平台
  - 组件业务关联
- AbTest 平台
- 实时竞价
- 服务间通信
Q&A
附录

广告商业形态

深思广告到底是什么？

不管当前的你是广告新人，还是接触广告很多年，现在试问自己：
”广告业务的本质是什么？每天工作或接触广告的意义在哪里？这些日夜的付出有哪些是无用功呢…“
了解更多，请关注公众号 “ code 杂坛 “！
这里简单聊一下互联网广告的产品形态及契合的应用架构，感兴趣的同学可以驻留片刻！

互联网广告市场形态

互联网广告所有的商业举动都是在市场形态之下，进行的利益或资源分配。

从互联网平台角度看，做广告的目的是为了企业营收。通过平台流量触达用户，完成广告主的诉求，收取广告主费用。
从广告主的角度看，其实质的诉求是以低成本接触用户，实现最大曝光或用户转化或购买。
用户在整个广告商业中显得颇为被动，在汲取互联网平台的服务时，被迫消费着出现的广告。

整合起来，这就是平台广告商业形态的市场形态：平衡用户服务体验、广告主实质诉求及平台的最大营收三方关系，追求各自最大收益。

互联网平台角色

平台作为承接广告主和用户的角色，其商业思维本质是：

在平衡用户服务体验、广告主认可的前提下，如何把流量卖的更贵、更多、更好，以获得更多的营收。

了解更多，请关注公众号 “ code 杂坛 “！

流量售卖方式

作为互联网平台，产品服务体验越好，用户越多，意味着流量越多。而广告正是流量变现的手段之一，如何进行广告售卖呢？

非合约式

广告主在各自的业务市场发展过程中，不同阶段所需要曝光的目的不同。

举个例子，当一款 APP 研发结束。上架初期，主要的诉求是曝光，以最快的速度、最大的范围去让更多的人知道这款产品的主打服务。

这个时候，在采买广告的时候，可以按展现次数采购，以千次展现付费，行话叫 CPM[ todo 展现一千次多少钱]。这种方式也是品牌广告类型采买的主要形式。
当曝光到某个程度后，其诉求会转向获客，也就是用户转化，当然曝光和转化时间也可交叉。这个时候，两种常用的采买方式，一种是点击，一种是转化。
- 点击，就是以广告点击次数付费，行话叫 CPC[todo 点击一千次多少钱]。像某不记名投票，点击广告进入就会默认跟投。
- 转化，就是以最终成为 APP 用户个数付费，行话叫 CPA[todo 转化一个用户多少钱]。像游戏等垂类产品，通过广告引导用户下载登陆。

用户增长往往伴随产品的主生命周期。在增长趋势放缓的时候，广告主的诉求就会变得更加精准，要求制定人群或地域各种定向条件去投放广告，具体采买形式可能是上面几种的叠加，等等。

合约式

上面是以 APP 为例，在一些传统或 toB 的产品中，广告主的采买有些不同。其追求主打的是长期的市场品牌效应，这种场景中，以合约式的方式付费更为稳妥，有计划稳定持续的投放。

合约式，就是签合同，把需要的展现次数、展示时间、主要流量…等等[不同广告主不同要求]写进合约，双方约定生效并按合约付费。

广告主可以根据不同的诉求可以选择不同的采买方式，目前市场主流采买，也就是流量变现的方式主要是上面三种。

平台流量收益最大化

有了采买方式，作为平台方，如何才能保证广告主诉求、用户体验的同时，收益最大化呢？

平台方掌握了互联网广告市场上下游重要的一环——流量。

如何分配流量，如何分配广告位，如何设计广告样式…是平台不得不思考的问题，也是收益最大化的秘诀！
了解更多，请关注公众号 “ code 杂坛 “！

广告位分配

有利的位置等于一切。

广告行业有这样的一句话，表明广告位置的重要性。的确是这样，纽约时代广场巨幕 LED 广告投放比小巷子里的小广告效果好、报纸头条要比背缝的阅读量高、热搜榜单第一的点击率最高…不错，一些的一些都在表明接触更多用户的位置更具有价值。

那么作为平台如何分配出现广告的位置呢？

广告的位置和广告类型有关。比如：

条幅类型总在网站的横批位置；文本链接类型总是在文章中飘出，这种一般是网页固定的 <a href> 超链接形式。
媒体类型总是在网站做左右侧及下方不定时弹出，这种一般都是网页内嵌 JS 代码动态拉取广告展示。
在搜索结果和 Feed 流中，根据用户体验数据分析，通常依据 “ 素数原则 ”，广告位一般是 1、3、5、8、11、13、15……
…

流量分配

现在 Feed 流兴起，下面就以 Feed 流为例子介绍。

在 Feed 流中，广告位存在先后顺序[ 1\3\5…]，考前的位置价值更高。意味着每次用户看到的顺序。位置越靠前，越容易被用户看到。

广告位值价值不同，如何售卖才能最贴近其市场价值呢？或者说，位置靠前的位置安排哪个广告收益最高呢？

平台面向全社会提供服务，拥有海量的用户群体，不同群体有各种的属性，以此可划分流量。

举个例子，用户 A 是某度的用户，在某度就会有 A 的用户画像。

A 最近登陆地址，是 XX 省 XX 县；A 年龄 30 岁，经常搜索汽车相关 query 词；A 性别男性；A 最近通过搜索词跳转并购买了儿童用品…
等等

基于这个画像，标识着此用户流量的通用价值及定向价值。

通用价值：男， 39 ，拥有不错的购买力，求知欲望丰富，这种是平台主要服务对象，相对比儿童、老年人….价值更高。
定向价值：此部分是相对广告来讲，依据画像就可以更精准的投放广告。既然是男性，就不会投放女性相关广告；XX 省就不会投放 YY 省…就此区分，广告主的转化点击也会更多，那么这个流量收费就更高，价值就更大。
了解更多，请关注公众号 “ code 杂坛 “！

定向价值也解决了平台尾部流量不好卖的问题。因为从用户等维度区分，就不存在流量首尾衡量标准。

广告样式

不同平台支持不同的广告展现方式。样式风格主要是贴合平台调性。

举个例子，搜索平台的广告一般都是以搜索结果显示，顶多尾部加 “广告” 字样；Feed 流平台一般都是以文章、帖子…等样式出现，较平和的和主题打成一片，避免突兀的用户体验；在 PB 页面一般都是大的 Ban 图示链接；FS 页面一般都是尾部跳转样式……

更多的样式，意味着广告触达用户的不同方式，带来的转化，点击…等效果也明显不同。这部分暂且搁置，后续介绍。

实时竞价

采买背后落地是一个个广告。

除合约广告外，按次、点击、转化…这种类型采买形式平台如何分配落地呢？

广告系统利用实时竞价机制可合理分配库存并实施落地。实时竞价是依据当前流量类型，广告主实时出价，广告系统以拍卖竞价的形式将中标广告落地。

第二竞价

实时竞价中，除合约广告外，采买之后也将按照拍卖行的第二竞价进行结算，以实现 “纳什平衡”，达到帕累托最优。详细结算及纳什平衡

这种实时竞拍机制使广告主更加动态，灵活的参与市场变化，同时平台流量能以最大程度贴近其市场价值售卖。

铺垫介绍这些广告背景之后，来聊广告系统架构足够了。

了解更多，请关注公众号 “ code 杂坛 “！

广告应用架构

如果你熟悉搜索架构，那么一定就可以搭建一个广告应用架构。

业界有这样的一种看法，广告、搜索、推荐三大业务被认为是现在互联网中最具挑战的方向。三者都是基于海量数据且具有持续优化特性的，在具有相关通用性的同时，存在着策略的差异。

全局链路架构

从图中可以看到，整个请求是分为站内外流量，站外流量需要经过 Adapter [适配]模块在进入到真正服务组。

Adapter 适配

那么这个 Adapter 包含的 Protocol\Anti-cheat 等服务主要是适配处理什么呢？
了解更多，请关注公众号 “ code 杂坛 “！

主要两个部分，

Protocol ：协议的转换 & 账号体系的映射 & token 校验 & …
- 在企业内部各服务模块 RPC/HTTP 通信通常是自定义，需要对第三方或站外流量进行一个转换；
- 不同产品的用户体系生成规则不同，需要对额外流量进行一个关系映射；
- 由于流量非站内，请求不可控，故需要进行类 token 机制的校验；
- ……
Anti-cheat：反作弊，也就是风控 & …
对非站内流量账号做马甲号、黑名单、风险评估…等系列反作弊的操作。
- 有同学可能就会问，为什么不和站内的一起做风控呢？
  这里要注意，站内规则和站外规则不同，同时站外来源不同，规则也就不同，风控场景更加丰富。

ADX 核心

ADX 核心可概要分为 Facade\Rend\Flow Engine 三部分，每部分承担的角色都不同。

Facade 前置模块，用来对流量进行规则分流，其包含 AbTest …等功能模块[图中的 Abagent 是 AbTest 本地化的代理服务块，下文细述]；
FlowEngine 流量引擎，主打库存分配、广告投放、广告竞价；
- Alaya 用户画像功能模块。获取流量主体用户的画像去请求投放引擎；
- Darwin 广告竞价模块。针对投放引擎返回的候选做实时统筹竞价；
- Baya 媒体干预广告竞价配置模块。对各类候选进行规则处理；
- Delivery Engine 投放引擎。为流量携带广告位匹配合适的广告候选；
Rend 支持广告的实时渲染效果及样式；
了解更多，请关注公众号 “ code 杂坛 “！

Storage 存储

Storage 主流包括 Redis\Hive\Kafka\Cloud…存储组件。

不同的存储组件适应不同的数据。

比如 Redis 存储用户画像信息，读频次高，且实时变化；Hive 存储日志主字段，数据规模庞大，用于数据的离线分析；Kafka 通常作为缓存，削峰填谷，用于不同流的异步映射、消息生产消费等；Cloud 用于数据链路监控的数据存储及 Query 等等……

Depend 依赖

Depend 依赖核心含有 DMP\AB\FlowAnalysis\Strategry\Account …等组件；

DMP 数据管理平台。用于用户实时标签，广告投放人群圈定，基于 ClickHouse 的上下文数据分析等;
AB 数据实验平台。支持精细化运营，科学实验及方案决策等；
FlowAnalysis 流量分析平台。对流量整体链路进行实时监控分析，便于各模块实时性能分析及数据快照等；
Strategy 策略平台。对流量切分，广告竞价的算法策略调整具有统筹协调作用；
Account 结算平台。支撑广告主结算、广告实际曝光、广告数据归因等；
了解更多，请关注公众号 “ code 杂坛 “！

Platform 平台

Platform 平台主要介绍 SSP \ BP 。

SSP 是媒体对广告链路干预配置平台。
BP 是广告主投放广告，制定投放计划平台。

组件业务关联

上述的组件是通用广告系统的主要部分，还有更详细的部分下次细述。

这些组件的功能耦合模块，都用相同的颜色做了标记。比如 Depend 依赖的 AB 功能和 ADX 中 Facade 的 Abagent 是业务关联的…

当站内外流量到来 ADX 后，会进行 Abagent 实验分流；进入到 FlowEngine ，FlowEngine 从 Alaya
拿到流量主体用户画像及 Baya 的库存\广告类型数据给到投放引擎 Delivery Engine；投放引擎根据策略及 DMP
Strategy 进行广告主投放计划的召回，返回广告候选；FlowEngine 拿到候选后在 Darwin
进行竞价，决断出最终将要曝光广告给 Facade；前置就会去 Rend
模块拉去广告相关的渲染信息进行外漏，完成当前广告投放。[归因及曝光的涉及端上和第三方，暂略，下次细述]

整个广告应用架构的概述到这里就告一段落，下面分小的模块详细聊。
了解更多，请关注公众号 “ code 杂坛 “！

AbTest 平台

关联 AB ? Angelababy ? 噢不，拒绝老板拍板决策的神器！用数据说话的决策实验平台 —— AbTest ！
Ab Test 衍生功能之锦上添花 —— 目标流量筛选

实时竞价

关联有人的地方就有广告！你有想过这些平台背后，广告是如何变现的呢？

服务间通信

关联 RPC 和 HTTP 有哪些区别？通信协议、网络模型、服务治理框架…

Q&A

1、品牌广告 & 效果广告？

后续有时间在码文

2、为什么会有不同投放引擎？

后续有时间在码文

3、文章是概要，有详细需求的同学可私信交流…
了解更多，请关注公众号 “ code 杂坛 “！

附录

生而平凡，为而卓越！

了解更多，请关注公众号 “ code 杂坛 “！