持续创造，加速成长！这是我参与「日新计划 6 月更文应战」的第8天，点击检查活动概况
前言
运用广告归因渠道（MMP） 是为APP投进优化的常见计划，检查广告数据，投进收入，埋点数据等，是很重要有用的一个广告优化工具。
假设看看对应的接入SDK，无非都是初始化（账号认证）、deeplink、埋点数据上报这些功用。看似很简略，实践上却有许多的坑，需求一步一个脚印的走。
下面对AF渠道的接入以及部分常见接入问题做出总结
初始化
MMP渠道的SDK基本都需求在APP启动时或之前认证，有些在AndroidManifest.xml / Info.plist中装备，有些在代码中，或者两者结合，一般在代码中的会更加方便。
AF的主要是在代码中装备的方法，且Android和iOS的方法会有点不同，AF_DEV_KEY和APP_ID可在代码中装备。DEV_KEY是仅有的KEY，而APP_ID则是iOS商铺id。
AppsFlyerOptions appsFlyerOptions = AppsFlyerOptions(
afDevKey: _AF_DEV_KEY,
appId: kReleaseMode ? _AF_APP_ID : _AF_APP_ID_DEBUG,
showDebug: false,
timeToWaitForATTUserAuthorization: 30,
);
大部分的装备初始化能够在代码中完结。
区别环境
那怎么区别测验环境和正式环境呢？
AF这一点不是很好，没有直接能够区别出来是否沙盒的开关，也便是说，按我理解的，他们没有规划区别测验环境，沙盒环境的场景，而这是很常见的功用。
要区别测验环境（沙盒环境）和正式环境，且数据别离，只能够其他建个运用、项目，然后用这个新的运用，作为他的测验环境。
为了实现不同的运用，iOS需求虚拟一个测验用的APP_ID，由于他是用APP_ID来作为不必运用的区别。就比方上一点的示例代码中的AF_APP_ID_DEBUG。
Android则是依据包名来区别不必运用，所以需求在build.gradle的buildTypes中，设置applicationIdSuffix，使在debug中主动添加后缀
buildTypes {
debug {
...
applicationIdSuffix ".debug"
}
profile {
...
applicationIdSuffix ".debug"
}
release {
...
}
}
这会导致一个问题，Android测验和正式为两个包，由于包名不一样，iOS则是同一个包，但APP_ID不一样。
还有另一个影响，如果运用了如google firebase这种，需求类似google-services.json来认证加载装备的，Android由于它会依据包名来认证，所以需求在不同环境下进行不同的装备。如下
比方在debug下的，更改里面的package_name，加上后缀.debug
DeepLink
DEEPLINK分为深度链接和推迟深度链接（defer deeplink），简略来说便是分为已装置状况（前者）和未装置状况（后者）下带着过来的链接处理。
但关于技术方面SDK的接入，实践上不必考虑他是普通的仍是推迟的，都是相同的处理。
主要要装备好url scheme（运用链接）和UniversalLinks/App Link（通用链接）
Url Scheme：，也称运用链接，只针对App已装置状况，打开指定app并呼应跳转落地页
Android(AndroidManifest.xml)
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data
android:scheme="test" />
</intent-filter>
iOS(Info.plist)
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleTypeRole</key>
<string>Editor</string>
<key>CFBundleURLSchemes</key>
<array>
<string>test</string>
</array>
</dict>
</array>
UniversalLinks/App Link，也称通用链接：即可在已装置状况下直接打开app并跳转落地页。在未装置状况下也可按普通Url打开浏览器访问（并不一定是商铺页）。
Android(AndroidManifest.xml)
<!-- App Links -->
<intent-filter android:autoVerify="true"
tools:targetApi="m">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data
android:scheme="https"
android:host="www.test.com" />
<data
android:scheme="http"
android:host="www.test.com" />
</intent-filter>
iOS(Associated Domains)，详细格局依据渠道定
处理回调
在装备完结之后，就能够接入他们的监听回调。AF中，有两种回调onInstallConversionData和onDeepLinking。他们都是深度链接的监听。
onInstallConversionData则依赖于归因，会处理完归因数据后再将原数据回来，不会处理数据结构。优点是能够拿到来自广告的一切信息，并依据信息自行处理跳转。缺陷则是呼应速度慢，精确性不如UDL。
onDeepLinking为新的UDL（Unified deep linking） 形式，该形式不依赖归因进行深度链接处理，优点是能够更快更精确的呼应。缺陷是只处理深度链接（DeepLink）的数据，所带着参数有必要带有deep_link_value，才干够触发呼应。
后者为新的方法，呼应更快，但它并不是对前者的代替。许多功用仍旧需求前者才干用，后者主要是用在比方说AF的onelink跳转的场景下，其他的功用场景比方横幅跳转并没有适配，要用的话还得手动加参数。
不过前者还能够拿到广告的信息。所以建议两者都接入，做一下判断，若是会触发后者，则不运用前者做链接处理。如：
if (attr["deep_link_value"] == null && attr["af_dp"] != null) {
}
deep_link_value是后者用来处理的参数，af_dp则是前者用来处理的参数。
其他监听回调
回调并不能支撑一切广告来历的回调。比方facebook的推迟深度链接，需求其他实现facebook的defer deep link。
详细在接入各渠道各功用（如目录投进、Feed流这种）时，需求注意下渠道是否能支撑，是否需求其他接入，接入后怎么防止重复处理。
埋点上报
埋点能够将App运用事情和广告来历构成关联，完结事情、装置、打开、收入等的归因。有主动上报事情和手动事情，装置打开这些一般便是主动上报的，加购、收入等则是手动上报的。
可用logEvent来手动上报
logEvent(eventName, eventValues);
eventName：事情名； eventValue：事情参数。
在官网阐明中会有建议的事情，实践上依据自己的需求即可。事情名事情参数其实都不是固定的，能够依据详细状况添加删除，最主要是为了广告这边的分析，而不是别人上报什么就上报什么。
上报时是实时上报，能够考虑下频率的问题，比方加入列表曝光事情，一次性上报曝光列表而不是循环上报。
设置附加数据
假设有统一的附加数据带着，不需求在每个事情中修改eventValues来带上，能够通过setAdditionalData来装备
setAdditionalData({
"user_id": user_id,
});
iOS SKAN
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）
class func updatePostbackConversionValue(
_ conversionValue: Int,
completionHandler completion: ((Error?) -> Void)? = nil
)
便是这么神奇的计算方法，假设一起接入了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渠道都能够将数据回传给其他自归因或非自归因渠道，所以也不必忧虑在广告渠道上无法检查到数据。
假设关于上面的问题有好的解决计划欢迎大佬们提出！
