动态商品广告可以根据用户偏好来实现精准投放，进而推送用户可能感兴趣的内容，促成用户下单，推动增长。那么，动态商品广告（DPA）是如何实现投放的？DPA的出现又为广告主与广告平台带来了哪些变化？本文作者就DPA投放做了总结，一起来看一下。

广告商品化，或许是互联网广告史上比较重要的一次进化，从以前的“用户找商品”演变为现在的“商品找用户”，在为用户提供优质广告体验的同时提升投放效果，这一切都得益于今天的主题：动态商品广告。

一、前言

在正式介绍动态商品广告之前，我们先来看一个大家在平时生活中经常会遇到的故事：

上面这个故事，便是广告投放过程中一次精准营销的典范：抖音APP根据小包同学在淘宝APP浏览冰箱的记录，同时关联冰箱的商品信息再推荐给小包，精准高质量的重复信息推送唤起小包大脑中的记忆，勾起其购买欲望，最终成功促成转化。

在这笔转化过程中，小包的浏览行为+冰箱的商品信息发挥了巨大的作用，通过把冰箱广告推送给有潜在需求的小包同学，精准定位人群，促成订单转化，这就是商品广告。

二、动态商品广告

动态商品广告，DPA（Dynamic Product Ads），其根据用户在广告主侧的兴趣行为数据，并结合广告主提供的商品库信息动态地向用户展示最契合的商品内容，提升转化效果。

DPA的愿景：为用户推送更加契合的商品内容，而不仅仅是广告。

既然是动态商品广告，那么何为“动态”？

1）动态内容

所谓的动态内容是指基于用户的不同行为数据，向其推送契合的内容。例如对于不同用户来讲，同样有购买冰箱意向的两个用户，小包喜欢双开门，小许喜欢单开门，那么在同一时间，他俩看到的商品广告内容是不一样的；即使是对于同一个人，如果其最近的网购发生变化，那么看到的广告商品内容也会随之发生变化。

2）动态落地页

所谓动态落地页是指用户看到的落地页不再千篇一律，可以是商品的详情页，也可以是同类商品的聚合页，更有甚者可以是不同商品的搭售页，这些都是根据用户的兴趣偏好+商品库通过程序化生成的动态落地页。

3）动态用户

所谓动态用户是指广告的受众不再事先圈定，每天的商品访客就是动态受众，持续变化。

动态商品广告，数据源于用户，它给用户的感觉这不像是营销广告，而更像是懂用户需要的站外个性化推荐，因此它会获得更多的关注和点击，转化效果也更加好。

既然动态商品广告这么好，广告主已经蠢蠢欲动，心里一定在想自己的广告能不能投DPA？这里要说一下，虽然DPA投放效果好，但是其投放门槛比较高，并不适合所有广告主，需要满足如下条件：

• 商品库：这里指的是广义上的商品，首先品类多，其次具有明显的结构特征，可通过结构化语言描述商品信息，因此比较适合零售、旅游、酒店等；
• 用户行为数据：广告主需自行统计用户在端内的行为数据，并计算出用户的意图商品，同时通过技术对接让广告平台感知用户的意图数据；
• 用户数量：广告主APP的用户数量需达到一定的量级，这样在跟广告平台的媒体match时能覆盖更多用户，发挥DPA最大的功效。

三、DPA投放流程

相信对于符合上面条件的广告主已经迫不及待地想去了解DPA的投放流程，这一节我们来看看一个完整的DPA广告投放流程是怎么样流转的以及广告主需要的配套设施搭建。

DPA的投放都是需要开白名单的，因此在产研正式对接之前，商务侧先进行开白操作。等白名单开通之后，进入真正的DPA投放对接。

1. Step1 商品库

广告主需要将自身的商品数据同步到广告平台的商品库，在平台侧维护商品信息，同步的方式主要有如下三种：

1. 手动录入：适用于商品数量较少，并且商品信息基本不会更新的情况。这种情况的使用场景还是比较少的。
2. 文件上传：适用于商品数量一般，并且商品信息不太会频繁更新的情况。广告主如需更新商品信息，通过在平台进行上传XML文件即可。
3. 定时拉取：适用于商品数量较多，并且商品信息会频繁更新的情况。通过配置数据源地址以及账号密码，平台侧即可定时同步最新的商品信息。

广告主可根据自身商品更新的情况来动态选择合适的方式。推荐使用定时拉取的方式，可以第一时间同步商品库的信息。

关于商品库的更新一般都是全量更新，目前主流的平台据我了解还不支持增量更新（如有误，欢迎斧正）。在商品信息更新的时候会有一个更新保护，主要是为了防止商品被误删除，系统提供的自动保护机制。开启更新保护后，若商品文件更新前后商品差异超过一定比例，则系统会自动停止本次更新并保留上一次更新成功的商品文件。

2. Step2 行为数据同步

用户在广告主端内会产生各种各样的行为数据，比如搜索、点击、收藏、下单等等，广告主可以根据这些行为数据计算出用户的意图产品。如果用户在端内未完成最终的转化，那么通过DPA可以在广告平台的媒体上对这些用户投放意图商品，召回用户，促进转化。

对于用户行为数据同步，广告平台一般提供以下对接途径：

1）SDK

通过接入广告平台的SDK，该SDK可自动采集用户行为数据，用户的意图产品也会由广告平台来计算，广告主只需接入SDK接口，开发工作量较小；但该方案的问题是广告主参与用户意图商品的计算逻辑，全依赖广告平台；

2）MAPI

广告主BI团队计算完用户的意图商品后通过对接广告平台的MAPI将用户行为数据回传给广告平台，这就要求广告主组建数分团队来分析用户的行为数据，同时还要对接广告平台的行为数据MAPI（非DMP MAPI），开发量较大。

3）RTA

对于前面两种方案，广告主都需要将用户的行为数据回到给广告平台，这会涉及到用户隐私安全问题。因此广告平台推出了RTA接口来解决该问题，关于RTA的更多知识，大家可以参考《APP投放增长：RTA》相关内容。

3. Step3 广告投放

商品库和用户行为数据都准备ready了，接下来要做的事就是通过创建广告投放将商品库数据和用户行为进行关联投放。

DPA广告与传统广告投放最大的区别在于便捷：针对海量商品的投放，传统广告投放可能需要创建海量的计划，而DPA广告仅需创建一条计划即可，极大地提高了广告投放的效率。

在广告投放时，还有一点会影响广告投放效果，那就是创意模版。由于商品库中是商品主图，尺寸各异，因此在投放时需要套用创意模版来进行创意尺寸统一并拼接商品的其它信息在创意上，例如商品归属地、价格等信息。通过将更多的信息披露在创意上，可以提升商品的转化率。

广告平台都会提供创意模版的制作编辑工具，广告主可以自行上传PSD文件，也可以使用平台提供的创意模版。

关于模版拼接这块，阿里妈妈提出了动态描述广告创意技术，感兴趣的小伙伴可以参考《告别拼接模板 —— 阿里妈妈动态描述广告创意》，希望未来各大广告平台都能提供类似的技术，真正的服务广告主。

4. Step4 广告下发展示

广告展示这块完全就是平台的能力了，平台会结合广告主提供的用户行为数据和自身对用户的理解向用户下方最契合的商品广告。

四、SDPA

动态商品广告还有一种衍生方式，SDPA（Single Dynamic Product Ad），也称单商品广告。

如果说DPA是广告主为了拉活投放，实现千人千面的投放（为人寻找合适的商品），那么SDPA主要用于广告主爆款单品的投放（为优质的商品找到懂它的人）。

SDPA相较于DPA，除了出发点不一致之外，两者用到的数据模型也不一样。

• DAP：结合广告主上传的用户行为数据和广告平台侧对用户的理解，给用户推送最契合的商品广告。
• SDPA：结合广告主历史投放数据和广告平台侧对用户的理解，把爆款商品推送给最合适的用户。

五、总结

本文通过一个平时大家都会遇到的case来讲解DPA，现在我们回过头来再看看DPA给广告主和广告平台提供了哪些帮助。

1. 广告主

• 减少广告创建成本，通过将广告计划和商品库关联，即可投放海量商品，触及更多的用户，实现规模化投放；
• 通过模版制作，实现在广告中动态显示商品价格、名称等相关信息，减少创意制作的成本；
• 通过用户行为数据对接，并结合广告平台的模型技术，重定向商品意图用户，提升ROI。

2. 广告平台

• 通过积累用户行为数据和商品数据，更好地了解用户、行业、商品，不断优化平台模型，反哺广告主，促进行业正向发展；
• 广告商品化：从以前给用户推送广告演变为推送商品，促进行业的变革。

作者：包子

来源公众号：商业化产品日常日记

01 前言

作为用户，心里一定在想：“这购物真方便，都不要自己打开淘宝搜索商品了”，作为广告主，心里在想：“又拉活了一个用户，说不定还能带来一笔转化”。用户&广告主其乐融融，开开心心完成了ROI。

那么，资讯类App是如何唤醒淘宝App的呢，淘宝App又是如何跳转至用户浏览的广告页面呢，接下来的篇幅将为您讲解这其中的黑科技：唤醒和场景还原。

唤醒&场景还原，作为运营常用的拉活增长手段，有利于提升老用户在App的活跃度，场景化的唤醒更能激发用户的转化意愿。其适用于如下几个营销场景：

a）微信、QQ等社交软件–>目标App

现在App为了做裂变都会带有分享功能，用户A分享了App内容链接至微信或QQ，用户B点开该链接后，会引导用户B打开该App或者下载该APP，从而对用户B实现拉新或者拉活。

b）短信、邮件、push等 –>目标App

短信、邮件、push也是常规的运营营销手段，用户A打开了某App的推广短信、邮件、push等，会引导用户打开该App或者下载该App。

c）宿主App–>目标App

用户A在宿主App上浏览并点击了目标App的推广活动，宿主App会引导用户打开该App或者下载该App。

简而言之，任何需要将用户吸引到目标App的活动都会用到唤醒和场景还原。

02 DeepLink

说到唤醒&场景还原，不得不说到DeepLink技术，因此他是实现唤醒和场景功能的基础。Deeplink分为Deeplink和Deferred Deeplink，行业内常说的“Deeplink”往往是这两者的统称。

Deeplink：深度链接，指已安装目标App的情况下，宿主App把特定的参数通过url 的形式传递给目标App，从而直接在目标App内打开指定的内部页面，实现从链接直达App 内部页面的跳转。

Deferred Deeplink：延迟深度链接，区别于普通的Deeplink，主要是增加了一个是否已安装目标App的判断，用户点击链接时，如果未安装 App，则引导用户前往应用市场，下载完对应 App后，首次打开该 App 时自动跳转进入指定的内部页面。

03 唤醒方式

目前常用的App唤醒方式包含如下几种：Url Scheme、Universal Link、App Link。

UrlScheme

在用户在点击scheme链接后，如果已安装则通过参数调用目标App并打开指定页面，如果未安装App，点击链接后无反应。通过Url Scheme方式，需要App端能够接收参数，传递给 App。

由于Scheme在未安装App时点击链接无反应的问题，所以在在投放时，一般都会选择双链，即Scheme+H5，在唤醒失败的时候可以打开H5页面。

通过Scheme唤醒App时，一般都会先判断用户是否已安装目标App。针对是否已安装App的判断，Android可通过App包名判断，IOS只能判断40个App(系统级别，变更列表需要发版)。所以这也是为什么广告平台提供的已安装App用户定向支持Android的原因，其可以通过下发包名list在App端进行探测。

在进行已安装App判断时，如果是可以明确判断已安装，直接使用Scheme进行唤醒；如果无法判断当前设备是否已安装目标App，优先使用scheme进行唤醒并设置倒计时，监听倒计时结束之前是否已唤醒目标App。常用的监听方法是判断当前页面是否可见。

Universal Link

Universal link是苹果推出的通用链接技术，如果目标App 支持Universal link，就可以通过访问http/https链接打开目标App内指定页面；如果没有安装App，可以跳转到自定义网页，很好的解决了Scheme在未安装App无反应的缺陷，但仅限在IOS（9.0以上版本）上使用，在Android上会打开对应的H5页面。例如：https://dp.ctrip.com。

由于Universal Link仅在IOS上才可以唤醒App，因此在投放时，如果需要使用Universal Link，那么需要做系统定向，仅定向IOS用户。

App Link

App link是Android（6.0以上版本）推出的链接技术，功能类似于IOS的Universal link。如果使用App link进行投放，同样需要选择系统定向。

04 场景还原

场景还原，主要解决在用户未安装目标App时如何在下载安装激活之后打开App内指定页面的问题。相比于传统的唤醒，其难点主要在于新下载激活的App如何获取在宿主App点击时候的链接内容。

目前常规的信息传递方式主要是监测链接和剪贴板方案。

监测链接

当用户点击唤醒按钮时，通过监测链接回传用户的设备号信息和点击内容。在用户下载安装激活后，通过设备号匹配其在宿主App内的点击内容，即可知晓此时需要引导用户至哪个对应页面。目前主流的广告平台在上报监测数据时，都支持替换监测链接中的落地页宏。除了落地页宏，也可以通过其他宏获取映射关系，比如说广告ID/创意ID等，这就需要维护宏参数和落地页的关系。

该方案依赖于广告平台侧需要支持对应的宏替换，其触发时机是用户看到或者点击广告创意（最外层），如果投放的内容是聚合页，用户在聚合页内的操作，平台侧是无法提供的，只能依靠广告主的技术去实现还原。

剪贴板

在说到通过监测链接进行场景还原时，对于投放的内容是聚合页场景，无法很好地完成场景还原，那么广告主可以通过剪贴板的功能来实现聚合页中的内容场景还原。

当用户在在聚合页发生交互行为时，由于聚合页是广告主自己搭建的页面，可嵌入自家采集数据的JS-SDK，该SDK的主要作用是采集用户在当前页面的交互行为，然后进行数据上报。这样当用户下载激活时，就可以通过该数据进行场景还原，打开对应的页面。

最佳实践

05 总结

其实场景还原的技术方案与《App投放增长：归因模型及框架介绍》中讲的归因方案有异曲同工之处，读者可以相互借鉴。其核心都是在于获取记录转化发生前的用户行为，场景还原的转化是用户首次打开App，使用的归因模型是Last Model逻辑。

作者：包子

公众号：商业化产品日常日记

RTA（RealTime API），中文解释“实时广告API”，广告平台在进行广告检索阶段，通过RTA接口向广告主询问其广告是否参与竞价，广告平台在接收到该信息后再进行广告检索召回。

一、背景

任何一个新鲜事物的出现一定是伴随着一定的需求背景的，让我们先来了解下RTA产品的需求背景。在上文《Marketing API的那些事儿》中我们有提到广告主投放广告的三种途径，除了自建DSP对接ADX是依赖于广告主自身数据和技术之外，剩下的两种：媒体后台开户投放和对接MAPI搭建Trading Desk方式都是依赖于广告平台的能力建设。由于广告主自建DSP需要较深的技术沉淀，广告主一般都会选择媒体后台开户投放或者对接MAPI搭建Trading Desk方式来满足自家App推广需求。

在推广前期，广告主可通过广告平台提供的定向能力来获客，但随着互联网红利的消失，广告主获客越来越难且成本水涨船高，以前的粗放式投放不再适用于眼下的市场，精细化投放已经成为广告主不可或缺的选择。结合广告主一方数据和广告平台的技术能力来辅助投放是行之有效的解决方案。

那么，在没有RTA之前，广告平台是如何实现通过一方数据弥补广告平台定向能力不足的？很简单，在《Marketing API的那些事儿》中有提到，MAPI的一个很重要的功能是数据回传。不论是DMP API还是用户行为数据回传API，广告主均可通过这将所需定向数据回传到DMP平台，然后广告平台将自身的DMP和DSP打通，利用广告主上传的数据来进行定向投放。广告主的一方数据，除了弥补定向之外，还有一个重要的应用场景是OCPX，因此这也是为什么说广告平台推荐大家使用OCPX，这样其可以获取到后链路数据，丰富其数据特征，辅助优化模型。

既然已经有了数据回传MAPI，那广告平台为什么又要推出RTA呢？考量点主要出于如下几个原因：

1. 出于保护用户隐私数据安全考虑，广告主不再将数据通过API输出给外部平台，用户数据只能在自身平台发挥作用；
2. 通过MAPI回传数据存在滞后性，无法保证数据的实时性；利用RTA接口可以来弥补平台实时定向能力的不足。

二、RTA广告流程

广告平台在进行广告检索阶段，通过RTA接口向广告主询问其广告是否参与竞价，广告平台在接收到该信息后再进行广告检索召回，一个完整的RTA广告流程如下图所示。

1. 前端发起广告请求，请求后端广告服务；
2. 广告服务一般会经过广告检索、广告召回、广告粗排、广告精排等一些过程，最终将广告下发给前端展示给用户；
3. RTA请求时机：为什么没有将RTA插入到上述的某一个流程中，原因在于RTA适合于广告检索到广告下发之间的任一环节，但是处于不同的环节，对于广告平台和广告主的处理逻辑是不一样的；因此广告主开发者在对接RTA时需要跟对方明确其RTA的请求时机是在什么阶段；
4. RTA超时控制：RTA对时效性要求很高，所以当一旦出现超时等问题时，不同平台的处理机制不太一样。有些平台在超时后会默认广告主不需要本次流量；有些平台则相反，会默认广告主需要本次流量。因此开发者在对接RTA时需要跟对方明确其RTA的超时时间和超时处理逻辑；
5. RTA控制维度逻辑：RTA的控制粒度可以到广告账号、广告计划等维度，但不同平台的控制粒度不太一样，粒度更细，广告主可更好地进行精细化投放，目前大部分平台都还在广告账号维度。开发者在对接RTA时需要跟对方明确其RTA的控制维度；
6. RTA出价：目前主流广告平台的RTA接口支持设置出价（或者价格系数），广告主开发者可结合自身数据对本次流量进行价值预估，掌握出价的主动权。还有一些RTA接口支持质量分，功能与出价类似，都是返回本次流量的价值；开发者在对接RTA时需要跟对方明确其RTA是否支持出价或者质量分；
7. DPA广告：目前主流广告平台的RTA支持返回商品ID（需提前跟广告平台对接商品库），即可以投放DPA广告，适合做remarketing，进一步对流量做精细化运营。开发者在对接RTA时需要跟对方明确其RTA是否支持DPA广告；
8. 监测链接：对于支持曝光点击监测的广告平台，部分平台的监测宏支持RTA_ID，这样可以区分出哪些广告是通过RTA策略胜出的，同时可以针对广告流量质量做监控，例如曝光点击监测数据中出现了未知的RTA_ID，那么该流量可能存在问题。开发者在对接RTA时需要跟对方明确其监测链接是否支持替换RTA_ID宏参数。

三、RTA接入

RTA，作为一个扩展实时定向能力的API，可以提升广告投放效果，首先广告主肯定是希望接入的，但广告平台出于数据安全和时效性考虑，一般都会设置接入门槛，这一点与对接ADX类似。

1. 消耗门槛：由于广告平台开放RTA功能存在数据输出的风险，所以广告平台一般只会针对KA客户开发RTA能力；
2. 技术门槛：RTA是一个实时接口，对时效性要求很高，因此广告主开发者必须具有较好的技术沉淀，才可以对接RTA；
3. 数据能力：RTA需结合广告主一方数据和广告平台技术能力才能最大化发挥其功效，因此广告主开发者需具备一定的数据能力，有能力基于一方数据对流量质量进行评分，衡量流量价值。

广告主在搭建RTA平台时，需要关注接口超时问题，一旦超时比例过高，平台有可能关停RTA能力。尤其是当广告主对接了各大平台的RTA时，比如广点通，巨量或者百度的流量，每次都对广告主进行RTA请求的话势必会导致广告主服务器QPS的量很大，压力很有可能扛不住。

那么，这个时候为了提升QPS，广告主开发者可以设置缓存机制，优先使用缓存数据。到这里需要考虑缓存过期问题，除了设置过期时间外，还需结合业务逻辑主动删除缓存，比例用户安装激活了App，比如用户购买了广告产品等场景。广告平台侧同样可以设置相应缓存机制，即对广告主已经进行“标记”的用户进行缓存或者记录，下次无需再广告主发起请求。随着RTA数据的不断积累，广告平台就能掌握更多广告主用户侧的数据特征，从而减少RTA的次数。同时广告主一方数据的积累对于广告平台的好处也是显而易见的，比如用于训练OCPX模样等。

广告主在搭建RTA时，应当关注如下几个指标：

1. 超时率：过高的超时率对广告平台和广告主开发者都是一种不好的体验，平台侧有可能关停RTA能力；
2. RTA有效返回占比：有效返回RTA结果的比例，如果该比例过低，会导致RTA消耗过低，平台侧会认为RTA并未给广告主带来较大的效果提升，有可能会关停RTA能力；
3. RTA消耗占比：参与RTA的消耗占大盘整体消耗的比例，与RTA参与率类似；
4. RTA匹配分析：通过结合监测链接中的RTA_ID数据和RTA有效返回数据分析RTA最终匹配情况。
5. ……

四、RTA应用

RTA提供了实时定向的能力，那么在哪些场景可最大化发挥作用呢？下面罗列一下电商行业几个常用的场景，如果读者有更好的场景，欢迎一起探讨。

1. 拉新

广告主在推广App时，一定会涉及到拉新，获取新客户。既然是拉新，那如果将广告投放给老客户，浪费预算的同时又会影响老客的用户体验，因此在投放拉新广告时需要排除老客。如何判断一个用户是某App的新用户还是老用户，只有广告主自己才知道，而且每个广告主的判断标准还不一致，因此广告平台无法屏蔽这部分用户。通过RTA接口，广告主可以自行判断是否针对本次流量投放拉新广告，从而提升广告投放效果。

2. DPA

目前主流的广告平台均支持在RTA返回结果中返回商品信息，这就表示广告主可以结合内部推荐数据给本次流量推送最合适的广告素材。广告主开发者需要支持实时+离线的方式计算用户的个性化数据，这里面就需要考量耗时问题，毕竟实时推荐可能达不到RTA要求的时效性。

3. 频控

在广告行业中，大家有一个共识，针对同一个用户投放多次并不会提升效果，反而需要将用户看到广告的频次控制在一定范围内。广告主在推广App时，一般都会渠道投放。在没有RTA之前，广告主一般只能设置单渠道的频控设置。在有了RTA之后，如果投放的渠道均支持RTA，那么广告主可以做到全局频控，可以节省投放费用，同时提升投放效果。

4. 流量分层运营

在App运营体系中，不同活跃度用户的流量价值是不一样的，活跃度越高，相应的流量价值也越大。因此广告主一般都会针对不同的活跃度的用户打上不同的质量分，同时设置对应的运营策略。由于RTA接口支持回传流量质量分，广告主可通过此字段向广告平台传达其对本次流量的打分情况，平台在收到该信息后，叠加平台侧的动态出价能力，为广告主更好的去竞得本次流量，实现流量的分层运营。

五、RTA VS RTB

RTB（RealTime Bidding），中文解释为“实时广告竞价”，广告主可针对ADX的每一次流量进行流量价值、CTR以及CVR预估，然后决定是否参与竞价，如若参竞，需要返回对应的广告素材以及出价。广告主通过自建DSP对接ADX，由于缺少平台媒体侧上下文信息（context）、用户媒体的用户行为（user）以及其他相同广告主投放的泛化数据，因此相同技术能力条件下，广告主的CTR和CVR预估模型也比较有限。

RTB和RTA，虽然两者从名称上看就一字之差，但两者是完全两个不同的工具，主要差异点见下图。

1. 广告归属：RTA的广告创建位于广告平台侧；RTB的广告创建位于其自建的平台侧；
2. 出价：RTA的出价可以是平台的出价*用户质量分，也可以是RTA的实时出价；RTB的出价是实时竞价；
3. 定向：RTA的定向结合平台侧的定向和广告主的实时定向；RTB的定向主要是其自建平台的定向功能；
4. 定向粒度：RTA的定向粒度可以是账号和计划级别；RTB的定向粒度是广告级别；
5. 数据：RTA利用了广告平台数据和广告主一方数据；RTB仅利用了广告主一方数据。

六、总结

RTA是这两年兴起的广告技术能力，其核心要点在于通过广告主一方数据并结合广告平台的技术能力来更好的实时辅助广告投放，包含但不限于定向优化、出价优化、DPA优化等，随着各平台对于RTA的深入探讨研究，期望这个行业能给大家更多的玩法。

作者：jdyx728

公众号：商业化产品日常笔记，懂产品、懂运营、懂代码的商化产品经理

Marketing API（以下简称MAPI），是各大主流广告平台基于自家营销系统推出的帮助广告主更好投放广告的open API。基于MAPI，广告主可以搭建Trading Desk来辅助广告投放。

那么MAPI提供了哪些能力，广告主开发者基于这些功能该如何帮助广告投放提效，本文将带你一探究竟，希望读者能有所启发……

一、初识MAPI

Marketing API，是各大主流广告平台基于自家营销系统推出的open API，可以为广告开发者提供全面的技术及数据支持，全方位实现自动化营销及高效管理。

我们先来一起回顾下，如果广告主想要投放广告到某媒体（平台），常规方式主要有如下几种：

1. 广告平台侧开户投放：广告平台成熟稳定，功能齐全，广告主只需开户充值，就可在平台上进行广告投放。
2. 对接ADX投放 ：广告主可自行搭建DSP ，通过对接广告平台的ADX服务进行广告投放。但通常来说，由于对接ADX会将平台流量分发到广告主侧，广告主可自由挑量投放，因此主流平台的ADX一般不对外开放，需要评估广告主的消耗情况，只有达到消耗门槛才会准入。

那么读者心中会不会存在疑惑，既然各大主流广告平台都有自身的营销系统和ADX，广告主可以通过上述两个途径进行广告投放，为什么还需要推出MAPI呢？

我个人认为，主要有以下几个方面原因：

1. ADX有消耗门槛限制，除非KA客户，不然广告平台通常情况下不会提供对接；
2. 广告平台的营销系统面向的是所有客户，无论是操作流程还是功能点都高度统一，无法满足客户个性化定制需求；
3. 客户在营销活动时，为了最大化触及用户，一般都会选择全网通投（即通过不同的广告平台投放广告），这时候无法聚合各个平台的数据进行分析，不方便运营。

基于以上客户真实存在需求，各主流平台纷纷推出了MAPI供广告主接入，为广告开发者提供全面的技术及数据支持，全方位实现自动化营销及高效管理。

那么哪些客户适合通过对接MAPI来进行广告活动呢？广告主该如果通过MAPI给广告投放提效呢？

1. 懂技术：由于对接MAPI是需要一定的技术开发成本，所以接入方必须有很好的技术沉淀；
2. 懂业务：毕竟接口是脱离系统操作页面的，因此需要理解各个接口所能提供的能力以及准确判断是否能满足自身业务需求；
3. 懂效果分析：由于各大平台仅能提供展点消等基础数据报表，无法展示站内转化效果数据（除非广告主向平台会回传转化数据），因此可以对接MAPI来回收展点消数据并进行转化归因，从而来分析各渠道的流量质量；
4. 需多渠道投放：如果广告主想要多平台进行广告投放，必须通过MAPI回收各平台数据进行聚合分析；
5. 广告投放提效：由于广告平台提供的功能是统一的，无法满足广告主的个性化投放需求，例如所有广告投放仅定向不同，在平台侧就得手动创建N个策略，但是通过MAPI就可以通过自定义规则来批量投放广告；
6. ……

简而言之，通过MAPI，可以辅助广告主更好地进行广告投放。

看到这，小伙伴肯定在想既然MAPI这么好使，赶紧对接，以后投广告就轻松了。别急，先看看MAPI目前存在的两个不足之处：

1. MAPI的功能实时性：目前各大平台，同一个功能，MAPI的支持程序一定是晚于平台侧的，即存在滞后性，但未来不排除API先行的情况。
2. MAPI的功能完整性：不管是出于安全角度还是商业布局角度，MAPI无法cover平台侧的所有功能，广告主需要评估已有功能是否能满足自身需求。

下图总结了三种投放方式的优劣势，供读者参考～

二、MAPI功能

目前市场上，主流广告平台一般都支持marketing API，例如巨量引擎、广点通、百度、快手、阿里汇川等……虽然合家的支持程度不太一样，但主要的功能基本都能支持，包含广告投放、数据报表、帐号管理等，好一点的平台能提供更多的辅助工具，常规功能如下图：

三、活用MAPI

广告平台的marketing api提供了那么多功能，基于此，广告主该如何去搭建Trading Desk来满足自身的广告投放需求呢？

搭建Trading Desk是一个漫长且痛苦的事情，正所谓“痛并快乐着”～笔者整理了几个不同的对接阶段，各广告主开发者可以参照这几个阶段循序渐进地开展工作。

1. 市场摸索阶段

处于该阶段的广告主，业务一般刚刚起步，通过投放适量的广告，来摸索市场。此时广告主可直接在平台开户投放即可，无需投入研发资源来对接MAPI。

2. 投放初步阶段

在投放一段时间之后，广告主需要对投放的数据进行更多的分析来验证投放效果。由于平台侧无法提供广告主站内数据情况，需回收平台侧相关数据并结合站内转化数据来进行数据分析，但广告主开发者需准备如下技术支持。

1）自建监测体系

目前各大主流平台支持添加曝光点击监测，广告主开发者可自建监测体系，回收广告展点相关数据。监测链接需带有相关的标识参数，用以保证链接的唯一性，通过标识参数可以分析不同渠道不同的广告的投放效果。

2）转化归因

基于回收的展点数据，核心字段为设备号和时间戳，再结合广告主站内转化数据，可以归因。

3）数据监控——流量质量

有了曝光点击数据，就可以监控流量质量，判断是否存在异常流量。关于异常流量的相关知识，可以参考，也可以加笔者微信详聊一些常见的反作弊判断标准。

3. 投放起量阶段

在验证了投放效果之后，广告主进入投放起量阶段。在该阶段，广告主为了快速占领市场，在市场上投入大量的广告，这需要较高的运营成本。为了提升运营人效，广告主开发者需做如下技术支持：

1. 数据回收：对接广告投放相关的API，回收平台侧的广告相关数据，包含计划、广告、创意的展点消数据；
2. 广告排行榜：通过创意数据，分析各创意的展点消转化数据，输出广告排行榜，供运营同学分析投放效果；
3. 广告模块​：对接广告的增删改查操作API，可操作广告投放​；​
4. 自动化规则：通过广告排行版数据，制定优劣广告标准；通过自动化规则，针对优质广告批量创建广告投放进行市场抢量；针对劣质广告，自动关停广告，避免预算浪费。PS：这里的自动化规则是一个持续摸索的过程，需联合运营、财务、算法团队共同探讨制订，充分利用AB实验来获取最佳的规则配置；
5. 数据监控——账户：对接账户级别接口，获取账户的消耗以及余额情况。需实时监控账号情况，防止出现余额不足或无消耗情况；
6. 数据监控——审核：对接广告投放级别接口，监控广告审核情况，避免出现广告审核不通过但无运营知晓的情况，导致广告投放无法起量；
7. 利用好平台的自动化规则：针对一些的简单的监控，可以充分利用平台提供的自动化规则进行广告投放/账户监控；
8. 辅助工具：对接媒体的辅助工具，例如文案助手、视频工具等，获取优质文案，制作动态视频，给运营投放提供指导；
9. 更多工具，等待读者进一步去发现……

4. 投放挑量阶段

经过前期大量的市场投放，广告获客成本越来越高，这时候来到了流量精细化运营阶段，即广告投放挑量。广告挑量投放的方案一般有三种。

1）媒体标签

通过媒体后台标签定向进行广告投放，但这取决于媒体标签的丰富度。目前基本上都是一些常规标签，如需结合自身业务投放，还是比较困难。

2）DMP（人群）

对接平台提供的人群管理API，广告主可根据自己的算法计算出需要定向/排除的人群包，通过人群管理API同步到广告平台进行人群定向投放。但这就涉及到广告主数据暴露，需与公司信安一起讨论决定数据输出的形式及颗粒度，数据必须脱敏，不然会存在泄露用户隐私数据的风险。

3）RTA

为避免数据同步至广告平台侧但同时又想精细化运营流量，各大平台侧于20年提供了RTA接口，即在广告召回之前先询问广告主是否对本次流量进行广告投放，将选择权给到了广告主。关于RTA的更多相关知识，读者可自行百度，目前网上的资料非常多，本文不做过多的介绍。

5. 投放智能化阶段

其实在上述几个阶段，已经涉及到了一些算法相关内容，但这里为啥需要单独拉出来一个智能化阶段来介绍，我想从另外一个角度来看MAPI的使用场景。

大多数的公司，尤其是各种提供Saas服务的公司，在利用MAPI的时候，通常是对单广告平台的能力进行包装定制化。

但有木有考虑过这样一种场景，基于广告位的属性来进行包装，比如将巨量引擎、广点通、百度的信息流统一包装为信息流，这样从广告形式上可以分为开屏、信息流、搜索广告等。这里就涉及到强大的算法能力以及产品拆解包装能力：

1. 产品拆解包装能力：产品需熟知各家平台提供的MAPI能力，能够剥离拆解出共同模块部分，并整合映射到同一级别；
2. 算法能力：由于对各家的产品能力进行包装，这里就会涉及各种算法，例如预算分配、自动出价、定向策略等，这里面由于各家的日预算规则不一样，预算分配是个难题，需重点照顾。

四、总结

Marketing API，虽然存在着功能性和时效性问题，但其在很大程度上可以辅助广告主更好地进行广告投放。本文通过对各家MAPI支持的能力程度进行分析，提出了活用MAPI的一些方案以及路径规划供读者参考，希望能给大家带来启发。

通过对接广告平台的MAPI来搭建Trading Desk是一个漫长且痛苦的事情，大家一起排坑～

作者：jdyx728

公众号：商业化产品日常笔记，懂产品、懂运营、懂代码的商化产品经理，欢迎一起探讨商化日常想法和产品策略~