持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第8天，点击查看活动详情

使用广告归因平台（MMP） 是为APP投放优化的常见方案，查看广告数据，投放收入，埋点数据等，是很重要有用的一个广告优化工具。

假如看看对应的接入SDK，无非都是初始化（账号认证）、deeplink、埋点数据上报这些功能。看似很简单，实际上却有很多的坑，需要一步一个脚印的走。

下面对AF平台的接入以及部分常见接入问题做出总结

MMP平台的SDK基本都需要在APP启动时或之前认证，有些在 / 中配置，有些在代码中，或者两者结合，一般在代码中的会更加方便。

AF的主要是在代码中配置的方式，且Android和iOS的方式会有点不同，AF_DEV_KEY和APP_ID可在代码中配置。DEV_KEY是唯一的KEY，而APP_ID则是iOS商店id。

大部分的配置初始化可以在代码中完成。

那怎么区分测试环境和正式环境呢？

AF这一点不是很好，没有直接能够区分出来是否沙盒的开关，也就是说，按我理解的，他们没有设计区分测试环境，沙盒环境的场景，而这是很常见的功能。

要区分测试环境（沙盒环境）和正式环境，且数据分离，只能够另外建个应用、项目，然后用这个新的应用，作为他的测试环境。

为了实现不同的应用，iOS需要虚构一个测试用的APP_ID，因为他是用APP_ID来作为不用应用的区分。就比如上一点的示例代码中的AF_APP_ID_DEBUG。

Android则是根据包名来区分不用应用，所以需要在的中，设置，使在中自动增加后缀

这会导致一个问题，Android测试和正式为两个包，因为包名不一样，iOS则是同一个包，但APP_ID不一样。

还有另一个影响，如果使用了如google firebase这种，需要类似来认证加载配置的，Android因为它会根据包名来认证，所以需要在不同环境下进行不同的配置。如下

比如在debug下的，更改里面的，加上后缀

DEEPLINK分为深度链接和延迟深度链接（defer deeplink），简单来说就是分为已安装情况（前者）和未安装情况（后者）下携带过来的链接处理。

但对于技术方面SDK的接入，实际上不用考虑他是普通的还是延迟的，都是同样的处理。

主要要配置好url scheme（应用链接）和UniversalLinks/App Link（通用链接）

· Url Scheme：，也称应用链接，只针对App已安装情况，打开指定app并响应跳转落地页

Android(AndroidManifest.xml)

iOS(Info.plist)

· UniversalLinks/App Link，也称通用链接：即可在已安装情况下直接打开app并跳转落地页。在未安装情况下也可按普通Url打开浏览器访问（并不一定是商店页）。

Android(AndroidManifest.xml)

iOS(Associated Domains)，具体格式根据平台定

在配置完成之后，就可以接入他们的监听回调。AF中，有两种回调onInstallConversionData和onDeepLinking。他们都是深度链接的监听。

· onInstallConversionData则依赖于归因，会处理完归因数据后再将原数据返回，不会处理数据结构。优点是可以拿到来自广告的所有信息，并根据信息自行处理跳转。缺点则是响应速度慢，准确性不如UDL。

· onDeepLinking为新的UDL（Unified deep linking） 模式，该模式不依赖归因进行深度链接处理，优点是可以更快更准确的响应。缺点是只处理深度链接（DeepLink）的数据，所携带参数必须带有deep_link_value，才能够触发响应。

后者为新的方式，响应更快，但它并不是对前者的替代。很多功能依旧需要前者才能用，后者主要是用在比如说AF的onelink跳转的场景下，其他的功能场景比如横幅跳转并没有适配，要用的话还得手动加参数。

不过前者还可以拿到广告的信息。所以建议两者都接入，做一下判断，若是会触发后者，则不使用前者做链接处理。如：

是后者用来处理的参数，则是前者用来处理的参数。

回调并不能支持所有广告来源的回调。比如facebook的延迟深度链接，需要另外实现facebook的defer deep link。

具体在接入各平台各功能（如目录投放、Feed流这种）时，需要注意下平台是否能支持，是否需要另外接入，接入后怎么避免重复处理。

埋点可以将App应用事件和广告来源形成关联，完成事件、安装、打开、收入等的归因。有自动上报事件和手动事件，安装打开这些一般就是自动上报的，加购、收入等则是手动上报的。

可用来手动上报

eventName：事件名； eventValue：事件参数。

在官网说明中会有建议的事件，实际上根据自己的需求即可。事件名事件参数其实都不是固定的，可以根据具体情况增加删除，最主要是为了广告这边的分析，而不是别人上报什么就上报什么。

上报时是实时上报，可以考虑下频率的问题，比如加入列表曝光事件，一次性上报曝光列表而不是循环上报。

假如有统一的附加数据携带，不需要在每个事件中修改来带上，可以通过来配置

iOS 14开始出现隐私弹窗并且需要用户同意。iOS 14.5之后必须同意之后才能跟踪用户数据，且归因的方式也改变了，变成SKAN归因（Apple的广告归因）

所有平台在iOS14.5之后都只能用SKAN来进行归因，这就导致了很多的坑。

14以下是用的旧的归因方式，所以展示在总面板中。14以上使用的SKAN，数据汇总在SKAN面板。

SKAN面板需要设置衡量模式，大致是收入、事件转化这些。

事件数还好，他能够正常的统计。收入则是最麻烦的，因为他不会上报具体的收入数值，他让你设置一个衡量范围，所谓的CV值（conversion value），且最多64个，即0-63。并且无论衡量什么，总数量上限就是64。

不过cv限制，也是投放同学考虑如何设计来保证投放效果。但随之而来的一个重要问题是，所有平台都使用的同一个Apple的SDK上报，他们的数据会互相影响！

这又多坑，SKAN SDK上报cv，是这样上报的，比如5块钱的收入事件触发了一次，那他就会上报五块钱的cv，5的cv则为1，假如又支付了五块钱，就是五块钱触发了两次，那就会将五块钱的cv+1，5的cv变为2。（这个五块钱就上面定的每个衡量范围0-63）

就是这么神奇的统计方式，假如同时接入了AF和FB的SDK，都上报了一次五块钱的收入事件，那他的cv就会变成2，实际是1，导致数据错乱。甚至于假如说FB定的衡量模式跟你的不一样，导致fb上报的不是5，而是其他的，比如具体收入值。那你的衡量会被完全打乱，SKAN回传的数据跟实际数据完全不一样。

这是要注意的一个点，尽量避免接入多个涉及广告的SDK，假如要接入，要确认仅一个SDK做SKAN的上报。

即使已经调整为仅一个SDK来处理SKAN的CV事件，还是有很多问题。比如我遇到的，cv数永远都是记在最大的范围值上，也就是上报的cv超过了设置的最大衡量值，比如63，现在全部收入都是63（确认上报的数据大部分没有超过63）。并且没有有效的解决方案，说是接入多个SDK互相影响，现在全屏蔽了，仅用AF的S2S上报来做收入上报，依旧是这样的问题。不知道是不是AF的上报有问题，还是有其他数据在用别的衡量模式，但按理来说，假如AF成功update了cv，那即使有其他导致63（或超过63）的值改变，也应该有实际衡量值的数据，为什么只有63的呢？

这个问题至今未解决。所以说iOS的SKAN，不仅仅影响了广告投放的方式，效果，也影响了技术方面和数据的难度。

iOS的Appid测试id是虚构，这也是没有沙盒环境设计埋下的坑。SKAN是根据APPID来上报到对应的应用，然后AF根据Appid来拿到对应Apple回传的数据。

假如是虚构的，而SKAN是根据实际APPID来上报的，为了不影响只能屏蔽，所以就拿不到对应测试环境的数据。

SKAN的上报也无法抓包（或者说我没找到方式），抓不到问题。

MMP平台的接入，并没有想象中的这么简单，会有很多细节问题，而且更新频繁，过一段时间就会出来新的优化方案、技术手段，然后就得学习接入，调试跟进。

很多坑还需要一步一个脚印的去走。建议可以的话广告方面，就接入一个平台作为数据的分析，避免数据之间的互相影响。现在的MMP平台都可以将数据回传给其他自归因或非自归因平台，所以也不用担心在广告平台上无法查看到数据。