API对接，这些坑你一定掉过！（附ADXING广告行CTO爬坑宝典）

      在上一期《媒体API接入是在接入什么》（戳我回顾）中，我们介绍了APP与SSP或者Ad exchange 在数据交互过程中传输的数据类型和内容。然而，理想很丰满，现实很骨感，纵然在对接前就和媒体约定好了对接的协议内容和交互方式，由于各种因素会导致对接调试时间无限拉长，大致上遇到的坑会有以下几类：

      坑1:

      我是媒体的技术，发的文档我都能看懂，但是感觉起来总觉得不太对劲。

      掉到坑里的原因：

      之前没有将广告位对接到第三方媒体的技术同学往往都会遇到这样的问题。单从技术视觉理解，对接就是发起请求，接收请求。但如果媒体技术同学没有理解到对接背后的概念以及整套广告交易概念，都会掉到这样的坑里，自己的代码可能会不断修改。

      爬坑姿势：

      掉到这种坑里的同学，可以先在心里默念一句：“谁、在什么媒体的、什么广告位上产生了一次曝光展示机会” 。带着这个问题去找答案就好办了。 不管是和什么SSP或者ad exchange进行对接，肯定会有一个媒体的唯一标示号给到媒体侧（如通过广告交易平台上产生的ID），我们这里记作media_id，使用该唯一标示，去获取到目前使用系统的用户的信息（如UA，IP，设备号等）不同的平台字段或许名称不同，但是万变不离其宗，对用户需要一个唯一标示，记作User_id。 再接下来就是一个顺序机的问题了，用户打开一个页面的时候可能会有几个广告位展现出来，依次取广告位的唯一标示，记作adslot_id. 

      我们有了media_id, user_id，adslot_id 三个主要元素，再加上广告展示的时间戳Timestamp. 这4个信息可以形成一个联合主键，代表一次唯一的请求。再通过对接的SSP或者Ad exchange 约定的具体数据进行传输即可。 对方在接受到你的请求后，会给到一个反馈。媒体的开发同学在接受到这个反馈信息后，按照约定解析展示即可。

      概括下就是：媒体的开发同学发送 “谁在什么媒体的什么广告位上产生了一次曝光展示机会”，并等待广告平台告诉你，这个曝光机会需要展示的图片（视频）URL，当点击时需要跳到哪里，当用户看到这个广告或者点击时同时需要告诉哪一个URL （第三方监测）。

      Tips: 市面上也有很多成熟的解决方案可以直接输出给媒体，如美数科技的媒体广告平台，不需要媒体的开发同学关注与广告平台对接的细节，直接使用解决方案快速接入。

      坑2:   

      APP与广告平台API耦合太深（如接入了多个广告平台API）

      广告平台API更新但APP没有办法快速更新

      掉到坑里的原因：

      通过广告进行变现也是很多APP的选择，一个APP可能会接入很多广告平台的API，如广点通，百度，ADXING广告行等。 因为商务原因或许会经常调整广告交易平台的权重，或者因为单个广告交易平台一旦要进行更新，代码工作量会非常大。 这里出现问题一般会是因为APP流量太优质了，系统架构设计有点跟不上业务发展。 但不要紧，因为没有不变的代码，我们可以通过下面的改动来减少开发量。

      爬坑姿势：

      先看一种简单粗暴的对接方式，广告位展示的实现是放在APP内的代码当中，通过APP直接访问广告交易平台。这种设计虽然简单，但是扩展性比较差。

      我们来进行改进一下。

      ADXING广告行提供的设计思路是，对于APP自身内的广告模块不用关注广告请求要发送到哪一个广告平台服务器，只需要按照约定将用户信息发送到APP Ad Server。App Ad Server 是一个媒体自己搭建的处理自己业务的API平台，提供adHandle（广告处理）服务。在 AdHandle服务当中去定义各个广告交易平台的优先级，因为考虑到各个广告交易平台的对接协议会有细微差异，所以提供一个convertDataFormate功能用于APP传出来的数据和各个交易平台的协议进行转化。

      所以，按照这种思路考虑，对于APP来说的话，APP 自身的代码只用考虑将媒体信息、用户信息、广告位信息发送给自己的APP Ad Server，由APP Ad Server 根据商务上设定的优先级，选择一个合适的交易平台后，将APP发送过来的协议转换成交易平台的协议用于适配广告。（以上仅仅提供一些小思路，各位有兴趣的可以参与讨论）

      坑3:

      网络联通性问题

      掉到坑里的原因：

      作为SSP或者Ad Exchange, 我们不生产流量，我们只是流量的搬运工。但是因为广告展示的要求都是在毫秒级以内的，再好的搬运工也架不住路途遥远。比如APP媒体端的服务器是在天津联通机房，Ad Exchange的服务器是在深圳电信机房。两地物理距离就遥，如果双方的网络链路不够好，在数据交互上容易产生误差或者一些广告无法展示。

      爬坑姿势：

      在遥远的自己建立IDC的时代，这个是个头疼的问题，自建一个机房费时又费力，但是我们现在在云端时代，这种问题很好解决。以ADXING广告行为例，ADXING广告行使用的阿里云提供的服务，主要业务部署在‘华北X’区。假设有一个APP的机房在深圳，和我方云上的可用区存在同路问题。解决该问题只需要‘华南’部署一套服务用于就近对接上APP的流量，阿里云内部 ‘华北’和‘华南’之间的互通，使用阿里云提供的高速通道即可解决该问题。

      Tips: 其他云厂商也提供类似服务。

      坑4:

      对接完成后广告物料的安全问题

      掉坑原因：

      投放广告也要在信息安全可靠的情况下投放，在保证了用户数据不遭暴露后。媒体的安全也需要得到保护，不能因为广告物料呈现内容带有一些敏感问题而导致严重后果。如何解决？人工审核？双重人工审核？

      爬坑姿势：

      技术的能力体现就是提高生产力，AI离我们远吗？一点都不远，我们完全可以利用AI来帮我们完成大量的图片识别，小量的图片我们使用人工审核。

      ADXING广告行同样使用了阿里云提供的Image Recognition，通过阿里云的能力，准确识别图片或者视频的内容，并实现内容检索和审查分发，对敏感图片进行处理。