巨量营销融合归因优化方案接入手册

  将巨量的归因能力通过SDK赋能给客户，由SDK进行APP打开事件上报，并进行激活的预归因，同时新增HTTP实时归因接口，将巨量引擎预激活归因结果回传给客户，由客户认领并筛选激活，最终通过API回传激活和深度事件；同时基于采集的全渠道APP打开事件用于模型助攻和已转化用户去重优化，提升投放效果。在正确接入的前提下，预计可在成本不变的同时增长10%-20%（IOS+20%，安卓+10%）。

接入流程（一个全人力8天）

4.1接入check list

接入流程需客户1个全人力8天

暂时无法在飞书文档外展示此内容

问题自助排查：接入中的状态与问题，均可在账户后台-事件管理-融合归因方案中查看，并可在对应建议中导出问题明细（涉及IDFV）进行辅助排查，确认问题原因

以下为接入流程的关键步骤，建议完成客户端和服务端的开发前后都重点check下各步骤是否完成

步骤	checklist	备注
step1 客户端SDK接入	客户端是否集成SDK代码 是否有按照要求注册URL Scheme	SDK代码详见： IOS SDK接入代码
	接入SDK版本是否为最新版本？	SDK最新版本号： IOS：1.0.5
	IDFV 是否100%获取？	IDFV需要采集最新的IDFV，不能使用Keychain缓存的IDFV 用户卸载重装后IDFV会发生变更，此时需要采集变更后的IDFV传给实时激活归因接口；采用keychain缓存过去的IDFV上报是无法生效的
	接入SDK后应用是否发版？	/
step2 服务端实时归因接口调用	是否前置观看归因改造指导视频？（仅需花费3分钟）	视频链接：https://bytedance.larkoffice.com/minutes/obcnzku9pn91bkx9j9m678su
	是否对于全量激活均调用实时归因服务接口 （需使用IDFV原值）	需要对全量激活均调用接口获取数据，避免出现以下情况： 在原归因逻辑归到巨量时才请求巨量实时归因服务接口❌ 在原归因逻辑未归因成功时才请求巨量实时归因服务❌ “新增用户”与“回流激活”均需要请求归因接口 “新增用户”指的是用户初次下载激活APP “回流用户”指的是用户新增之后，经过客户认为的窗口期没有产生过活跃，再次活跃时算作激活可以给广告进行归因。这两个时机需要客户请求实时归因接口。
	是否成功调用巨量实时归因接口？	参考4.4.3巨量实时归因接口 实时归因接口返回错误码为0代表请求成功
	接口请求失败后是否有重试逻辑？	由于网络等不可控原因，SDK事件上报可能出现时延情况，建议客户在接口调用失败后有兜底重试逻辑，保障100%的激活均可以获得归因结果。建议最多重试三次，每次间隔300ms，也可以根据自身情况来确定，期间保持APP运行不要退出。如果重试后还是同样情况，建议更换设备再试试。
step3 服务端归因逻辑改造	是否将巨量实时归因接口返回的last_touch_time，跟匹配触点找到的最后一次点击时间放在同一优先级比较，转化回传给时间更靠后的一个；	建议将巨量实时归因接口返回的归因结果跟匹配触点的结果放在同一优先级比较 避免出现以下情况： 在原归因逻辑归到巨量时才使用巨量实时归因服务接口返回callback回传❌ 在原归因逻辑未归因成功时才使用巨量实时归因服务返回callback回传❌ 仅在is_dp_open=ture 时才使用巨量实时归因服务返回callback回传❌
	确认在触点监测中的设备id停发的前提下，巨量渠道的归因是否无影响？
	通过原触点监测未归因到投放渠道的转化，巨量实时归因接口返回巨量归因成功，是否会回传给巨量？
	深度事件归注册的包（如付费行为归因至注册行为归因渠道），SDK要上报注册事件和用户ID	/
	转化上报接口是否新增转化对应设备客户app采集到（非触点监测中下发）的idfv	无论是通过融合归因接口还是触点完成归因，都需要带采集到的IDFV上报
	新版归因逻辑是否完成上线？	/
	是否有通过事件管理联调	参考链接