广告流量售卖，用SDK还是API？

当媒体决定通过自主开拓来开展APP广告商业化，在广告平台搭建完成后（采买或自建），还会考虑广告流量售卖的对接方式：API或SDK。

*如果你还不懂SDK和API

现在有两款炒菜机：

炒菜机A上有3个洞，第一个洞扔进去一个西红柿，吐出一堆西红柿块；第二个洞，扔进去几个鸡蛋，吐出来一杯蛋液；第三个洞，扔进去一些盐和糖，吐出来一份配比好的调料；说明上还补充说再找个锅来炒。

炒菜机S上只有1个洞，说明书上写着扔进去西红柿、鸡蛋、糖、盐，就能吐出一碗炒好的番茄炒蛋。

炒菜机A就是API，通俗的叫法是接口，是前端调用后端数据的一个通道；炒菜机S就是SDK，相当于开发集成工具环境，集合多个API以及其使用范例。

如果说是“云”是互联网的基建，API和SDK就像水泥和混凝土，能够提升互联网生态中信息交换和传递的效率，最终完成价值交换。

在广告流量售卖中，如果单纯基于成本考虑，SDK对接更为简单直接，API则需要媒体有强开发和定制能力，并且熟悉广告商业化，可以根据自身需要来调整

本文简要整理了媒体使用API和SDK的场景，并进行综合性比较。

用API的场景：媒体开发实力和定制能力强，只需拓展广告源

API对接的特点如下：

对接周期：不可控，APP开发者可选单一平台的广告接口或者聚合广告接口，不同接口对接文档并不统一，需要先理解文档后再进行开发。

稳定性：一般，在对接过程中会出现兼容等问题，广告展示效果受影响

安全性：传输的数据是透明，与文档一一对应的，服务商只能获取接口规则上提供的数据。

灵活性：灵活性高，可以自由开启和关闭接口，随时根据需要更新配置和升级功能。

对客户端(APP)的影响：几乎无需改动。

对服务器端的影响：需要服务器端技术支持，需要前置开发前端的数据收集模块、配置广告位等。

▲穿山甲，国内头部广告联盟之一，目前不支持API对接

为什么选择API？

媒体开发实力比较强劲，比如已搭建或者正计划开发自有广告平台，本身已有稳定的广告主来源，需要拓展广告源售卖尾量，或者是采用比较保守的变现策略，暂时只需要通过一两个广告位变现，比如开屏广告，此情况并不需要嵌入功能全面的SDK。

用SDK的场景：媒体变现经验和开发能力不足，希望快速变现

SDK对接的特点如下：

对接周期：通常比较可控，以对接聚合SDK为主，媒体可在SaaS服务商的广告系统上自助式对接测试，相比API的对接更为标准化，一般可在数小时内对接完毕。

稳定性：广告在当前的环境下，越是标准化，效率越高，SDK便是标准化的产物，对接成功后不容易出问题。

安全性：不排除违规收集数据的可能，具体审查方式可参考AdBright之前发布的文章（一文了解广告SDK工作机制及审查方式）

灵活性：较差，SDK更新后，APP也需要发版才能使用到最新的功能和服务。

对客户端(APP)的影响：会增加包体的体积，视SDK情况，会增加100k到10M不等的体积，当然媒体可删除SDK中部分未使用模块，进一步减少新增体积。

对服务器端的影响：不需要很强的开发实力，不需要服务器端的支持。

▲AdBright 广告聚合SDK

为什么选择SDK？

媒体变现经验和开发能力不足，不能完全理解广告的业务逻辑，精力更希望放在提高 APP 本身的体验和核心竞争力上，但同时有希望能快速进行广告变现或者增加广告收入，得到外部技术服务商的支持，此情况API对接不足以完整满足需求。

*SDK和API比较

对接周期：SDK＜API

稳定性：SDK＞API

对服务端的影响：SDK＜API

安全性：API＞SDK

灵活性：API＞SDK

对客户端（APP）的影响：API＜SDK

综上来看，对于媒体来说，SDK和API各有优势和缺陷，更多的是围绕当前的业务场景进行决策。

展望互联网To B领域，标准化浪潮来袭，广告SDK代表着一个标准化的服务和规范，与广告变现SaaS相辅相成，能够为行业带来更多的效率和利润的提升空间，帮助媒体，尤其是中小媒体，无需任何成本投入，即使没有任何广告变现经验，也能快速开展广告业务、获取广告收益，从而缩短业务链条、提升广告变现效率。