App开屏广告程序化之坑

​1.投某top新闻媒体App开屏广告PD模式控不住量的遭遇

前几天一朋友找我聊，问为什么某top新闻媒体开屏广告PD投放控不住量？是他的一个广告主甲方同学问他的，他们在使用某平台采用PD方式，对某top新闻媒体开屏广告资源进行投放时，曝光量到了关停投放，但是却发现曝光量还是在嗖嗖地往上涨，根本停不下来。比预期目标多花了钱，所以广告主爸爸很生气，后果很严重！

故而找到我咨询是否知道怎么回事？以及责任可能会在谁？若要追责赔偿的话该找谁？

我的回答是：问题就出在开屏广告须要持实时程序化管理的这个问题上。当前并不是所有媒体的开屏广告都支持实时程序化。因为开屏广告加载展示一般时间都很短，也就3-5秒左右的时间（在这么短的时间去完成对广告决策问询，尤其是还要进行素材的下载和加载。开屏素材一般文件都不小，而且移动环境下网络也不一定很稳定。若真正实时程序化，可能会因加载时间过长导致用户体验差，若限制时长则会因超时导致本次广告展示失败。）。所以很多媒体为了保护用户体验，及确保开屏广告库存不被浪费。往往会采取提前预拉取，广告预加载的机制。

在这样的机制之下，若媒体方没有对实时程序化做好特定的支持，实时控量肯定是控制不住的。当前很多App媒体都会提前3天甚至更长时间，让App提前预加载开屏广告素材及相应的展示排期。也有所谓“实时”是本次拉取下次展示的。但从广告主期望严格和纯粹地实时管理每次曝光机会，这个意义点上来看都是无法满足的。自然就会出现了上面那种PD投放模式下控不住量的问题啦。

然后聊到责任在谁？该找谁追责呢？

我的回答是：这个事情出在，大家对实际情况都不是很清晰地了解透彻，就仓促上马了，应该是专业上的问题吧。各方都有问题吧。若非要纠谁的责任更大，应该还是媒体吧。因为媒体都还没搞清楚什么是程序化广告，广告主要怎么用好开屏广告程序化之前。就都十分开心地推出什么几开屏联动的产品。再加上生态中那些不负责任的服务商，没有专业了解清楚情况，应付了事。就大家热火朝天的嗨起来，没有把问题清晰地告知广告主及各方，让他们能根据自己实际需求情况，做出慎重的选择。

2.还存在跨媒体频次控制的问题

其实我看到的情况，除了上述PD量控不住的问题，在PDB场景还存在跨媒体频次控不住的问题。很多广告主使用程序化一个十分基础的需求就是跨媒体频控，这样做的好处是相同的预算覆盖更多的人。若开屏广告无法做到实时精准控制。这个问题也很麻烦的。

3.程序化广告的核心特征：实时管理每次广告曝光机会

自2013年以来，我一直在行业中，致力于推动程序化广告升级。经常会应广告主的需求，推进媒体方进行程序化改造。我常说的一句句话就是：要

“实时管理每次广告曝光机会”。

可以说就是这么简短的一句话，恰恰是程序化广告的核心特征。

很多媒体的产品同学老问我说：您能否再给些具体点的场景吗？例如：创意轮播的场景，我们媒体就能支持的呀，那广告主也没必要搞那么复杂，没必要每次广告展示前都去问询AdServing系统。直接把轮播规则给我们，我们来做控制就行呗。

其实，“实时管理每次广告曝光机会”，关键是满足广告主（一对多）的传播（沟通互动）目标：要“针对合适的人、合适的时间场景、合适的地点、传递合适的内容”，促进其对品牌、产品特性、某特性需求解决的功能性等（定位）留下一定印象，进而在其产生需求时促进产生转化购买。

下面我们采用图示的方式说明几种个性化投放的系统流程：

a.传统排期投放系统流程示意，如下图：

广告提前按排期下达到媒体内容发布系统中，无法针对合适的人在合适的时间在合适的地点展示合适的广告。

b.如下图所示，媒体端定向投放系统流程示意，如下图：

广告提前按排期下将一些定向条件达到媒体内容发布系统中，满足一定程度的定向投放，但还是无法针对合适的人在合适的时间在合适的地点展示合适的广告（尤其跨媒体联合控制）。

c.程序化（自动化）广告投放系统流程示意，如下图：

才是每次广告要展示之前去问询AdServing系统根据广告主的第一方DMP及业务需求决策要不要这个流量或投什么广告素材

这才是程序化广告的核心特征。

在任何场场景，对问题的识别，若各方都能始终不离这个核心原则就不会出什么大乱子的。

4.媒体方程序化广告平台产品同学的为难

实际在推进媒体程序化升级的时候，我们面对的很多都是媒体程序化广告平台的同学。我这里也为他们说几句话吧，他们也很为难。稍微资深一些的同学上面那个“实时管理每次广告曝光机会”的原则肯定是了然于胸的。但是很多时候媒体的广告系统的构成会很复杂，有客户端团队（会比较重视用户体验），广告传统排期团队（传统锁量的），流量排期锁好最后才是给到程序化广告平台。所以往往程序化广告平台的同学也有心无力，很多时候只能是巧妇难为无米之炊，在对现有系统及体系没有太大改动的情况下，采用一些临时变通的方式来满足广告主方的具体某一场景的需求。

5.可能的可行的解决方案

说了这么多，很多同学肯定会问了，那么有没有可能的可行的解决方案呢？既能保护媒体的利益又能达到广告主“实时管理每次广告曝光机会”的诉求。

附上我之前在某个客户项目上对场景和解决方案的描述：

（此处隐去媒体名，用“该”替代）该App开屏资源都存在无法精准AdServing的问题：

问题描述：

由于开屏广告加载及展示的时间很短（3-5秒），App为了保护其用体验，目前机制是本次问询AdServing获取的广告，用户下次打开App时才会展示。这样就会造成AdServing无法精准控制每个设备广告曝光的机会。

因此造成的后果：

1.很多AdServing广告请求都无法被曝光（20%左右的成功率），大量占用媒体和AdServing方的带宽及计算资源。

2.无法满足业务上跨媒体频次控制的业务需求，例如：某用户A在该App已拉取广告1但未曝光，而在另外几个媒体的App已曝光超过2次频次，这时该用户A不能再播放广告1，要换成播放广告2，按目前处理机制，下次用户打开该App是只能播放广告1不受AdServing的精准控制。

3.无法满足多创意轮播、Retargeting追投补频、排除投放等业务场景要求精准对不同人不同场景播方不同广告进行控制。。

无法满足有效个性化传播营销的诉求是对广告预算是一种浪费

解决的方向建议，该App可升级为：

解决方案一：在广告要曝光前实时问询AdServing拉取。

目前WIFI及4G用户占比已超过90%，大量媒体开屏资源都已升级为实时拉取广告模式。

例如：……(此处隐去媒体清单，目前十来个大媒体是支持的)等。

这是最优方案，可以满足业务随时根据需要更换素材及投放策略的调整。

解决方案二：提前预加载所有要播放的广告，在广告要曝光前实时问询AdServing播放哪版广告。

还是提前3-5天预加载，不同点是先预加载所有要播放的广告。在每个用户要曝光广告前，媒体方来问询AdServing该出哪个广告的ID及相应的监测代码，之后媒体根据该广告ID匹配到本地已缓存好的素材进行播放。

例如：……(此处隐去媒体清单，目前有些大媒体是支持的)等等。

该方案不是最优方案，因为会存在预加载素材的带宽及计算资源浪费；且素材提前预加载，无法临时更换等问题。

文章写到这里基本告段落。

最后小结一下：

1.虽然存在各种各样的问题，大的行业还是在向前高速发展的，随着2019经济形势的压力，传统互联网产业格局，也正由圈地粗放经营，向深度精细化运营升级。由广告主根据第一方DMP及业务需求来挑量投放的需求越来越强烈。

2.可喜的是看到很多媒体，尤其是行业排名2、3的媒体都在积极响应这个趋势和需求，积极投入基础设施的改造，有部分已改造完成，有部分已蓝图落实试点测试阶段。相信用不了太长的时间行业生态会越来越完善。

3.程序化广告在今天的行业状态是基础设施，高速公路已经建好，就差上面跑汽车了，而这些汽车就是大数据。（但在一些难点区域，例如：开屏广告程序化可能会存在一些坑有待进一步完善。）

4.不仅仅在传统互联网领域，随着4G、5G、IoT物联网基础设施不断成熟，越来越多的线下触点将被数字化（终极理想情况下，所有用户触点将被数字化，被程序化管理），例如OTT、OOH、智能终端、智能穿戴设备等等新兴的触媒载体。恰恰由于IoT物联网雾计算的特点，网络传输及计算的分散化。未来会有更多的“实时管理每次用户触点沟通机会”，类似的课题会出现，需要我们不断地去面对去解决的。（不断地缩短产品同消费者之间的连接，甚至20-30年后，传统B2C模式将演变为C2B模式，变为由市场反向拉动生产，反向配置商业资源。）

（转载请注明出处：微信订阅号：ad_automation）