基础SDK对接指南

用户每次安装一个应用后，AF都会为其匹配一个专属的AppsFlyer ID。这个环节无需市场人员进行任何操作。

您可以使用该标识符来完成下列事项：

• 发送S2S应用内事件。
• 将AppsFlyer ID与您后台的用户记录进行匹配。
• 下载应用内事件原始数据报告并使用appsflyer_id来分析用户行为和链路。

在AppsFlyer SDK中设置CUID（客户用户ID）后，您就可以对BI系统中的专属ID、AppsFlyer ID和其他ID进行交叉对照。您可以在AppsFlyer的原始数据报告中查看CUID，还能在回传API中使用该ID与您的内部ID进行交叉索引。

如需进一步了解CUID，请参阅此文档。

GOOGLE PLAY INSTALL REFERRER

Google Play Install Referrer API改善了归因准确率，保护广告主免受假量侵害，而且能以安全的方式让广告主从Google Play获取安装来源数据（如应用首次激活时的版本信息）。

建议您将Google Play Install Referrer API部署指南发送给开发人员。

GAID

从SDK V4.8.0开始，AppsFlyer会自动收集这个设备标识符。

您可以通过AppsFlyer对来自第三方应用商店的激活进行归因，这些商店包括亚马逊、Opera,、GetJar、百度和华为。这样，您就可以在没有Google Play商店的市场中推广您的应用，并触达更多用户。

AppsFlyer支持第三方应用商店的归因，具体如下：

• IMEI或Android ID：SDK不会自动收集IMEI或Android ID。如果您需要收集这些标识符（如在中国国内市场推广应用时），可以让开发人员通过以下任意一种方式来实现这一功能：
  • 手动收集：通过setImeiData或setAndroidIdData API（详见下方窗口中列出的参考函数信息），让应用将IMEI或Android ID发送给SDK，然后SDK再将数据发送到AppsFlyer服务器。
    安卓端原生Unity

    安卓SDK参考信息：

    • setImeiData 
    •  setAndroidIdData 

    Unity SDK参考信息：

    • setImeiData
    • setAndroidIdData
  • 启用设备ID收集：使用setCollectIMEI和setCollectAndroidID强制SDK收集IMEI或Android ID（详见下方窗口中列出的参考函数信息）。
    安卓端原生UnityReact Native

    安卓SDK参考信息：

    • setCollectIMEI
    • setCollectAndroidID

    Unity SDK参考信息：

    • setCollectIMEI
    • setCollectAndroidID

    React Native参考信息：

    • setCollectIMEI
    • setCollectAndroidID

• OAID：您可通过该ID对来自第三方安卓应用商店的激活进行归因。详情请见OAID使用指南。
• Install referrer（激活来源标识）：AF的SDK支持从Samsung Gallery和华为应用市场拉取referrer数据。

背景介绍

从iOS 14.5开始，IDFA的收集需要得到用户的授权。也就是说IDFA的读取权限是由App Tracking Transparency（应用追踪透明度，简称ATT）框架所控制的。在iOS 14+设备上，SDK需要通过ATT框架来获取设备IDFA的读取权限。有关ATT的简介请参阅ATT原则。

若使用IDFA进行归因，一定要在应用首次启动时发送IDFA。为此，AppsFlyer SDK专门提供了waitForATTUserAuthorization方法以确保相关数据的发送。

waitForATTUserAuthorization功能简介

您可以通过waitForATTUserAuthorization来设定让SDK延迟多久再将数据发送给AppsFlyer服务器，并在此期间等待ATT授权状态。

当终端用户打开应用时，ATT状态为notDetermined。在waitForATTUserAuthorization的计时器走完之前，SDK会将激活和后续的应用内事件组成队列保存在缓存中，这与离线事件的记录方式相似：

• 如果用户在ATT弹窗中选择了同意（IDFA收集）：
  • SDK将IDFA添加到缓存的事件中。
  • SDK启动，发送带有IDFA的缓存事件（无需等到timeout结束）

• 如果用户在ATT弹窗中选择拒绝授权：SDK启动后发送不带有IDFA的缓存事件（无需等到计时器走完）
• 如果计时器走完后ATT状态仍然是notDetermined：SDK启动后发送不带有IDFA的缓存事件。

注意事项

• 如果在没有设置waitForATTUserAuthorization的情况下调用requestTrackingAuthorization，那么iOS 14+设备上的应用启动和事件在回传时不会带有IDFA。
• 如果用户在timeout期间将应用切换至后台：
  • timeout计时器暂停，直到该应用重新返回到前台运行。
  • 事件被保存在缓存中。

• 如果用户在timeout期间关闭应用，系统自动退出：
  • 计时器在下次应用启动时重新开始计时。
  • 缓存的事件会丢失。

您可以在ATT弹窗中使用定制的文案。清晰地说明收集设备ID的意义能够提升用户的同意率。

编写弹窗文案时请注意以下事项：

• 以最清晰有效的方式向用户解释您的应用为什么要请求授权。
• 告诉用户他们的数据会以何种方式被使用。详情请见用户隐私和数据使用。

弹窗文案完成后，请将执行指南与文案一并发送给开发人员。

查看ATT弹窗文案示例。

SKAN是iOS中用来验证非自然激活的一种方式，其中的应用激活验证流程涉及到流量方应用（source app）和广告主应用（advertised app）。

在广告平台上投放的广告会展示在流量方应用中。广告展示的配置并不在AppsFlyer SDK可控制的范围内。如需进行相关配置，请按照Apple的相关说明进行操作。

对于广告主应用（即配有AppsFlyer SDK的应用），AppsFlyer的SKAN解决方案会通过SKAN来实现归因回传，同时在确保用户隐私的前提下对数据进行收集、转换和汇总。用户首次启动应用时，AppsFlyer平台会基于广告主侧所设定的配置来指导SDK如何设置SKAN转化值。

请按以下步骤启用SKAN解决方案：

• 首先，市场人员需要在AppsFlyer后台配置SKAN衡量方案。开发人员无需进行任何操作。
• AppsFlyer SDK 会自动调用必要的SKAN API。
• 通过AppsFlyer进行SKAN归因时，请务必关闭其他SDK中的SKAN调用。
• 开发人员和市场人员都无需在App Store中再完成其他操作或注册流程。

如需关闭SKAN归因，请让您的开发人员在SDK中将其禁用。

您可以通过任何应用内事件发送收入数据。如需记录收入数据，请务必使用af_revenue参数，只有这个参数才在原始数据和面板报告中统计实际收入。了解详情。

AppsFlyer的SDK可通过服务器验证机制对应用内购进行验证。应用内购验证功能会自动将应用内购事件上报给AppsFlyer，如果广告主侧再发送这些事件就会造成重复上报。

请参考按垂类梳理的应用内事件推荐，其中包括旅游、游戏、电商等各种垂类。

若用户还未安装应用，OneLink能够识别设备类型并跳转到正确的终点（如Google Play、苹果应用商店、三方应用商店、网页等）。具体的跳转取决于您的OneLink模板设置。了解详情

如果用户已经安装了您的应用，OneLink就会打开该应用。此外，您还可以通过深度链接让用户跳转到应用中某个具体的页面。要实现这个功能，您的开发人员需要使用Unified Deep Linking（UDL）。

注意：

• 若需使用UDL，请确保安装SDK V6.1或以上版本。
• 如果您已经在用OneLink进行深度链接，那么您可能是通过历史API的方式实现的，而非UDL。

请参见深度链接和延迟深度链接的设置指南。

如果用户尚未安装相关应用，OneLink能够识别设备类型并跳转到对应的终点，不管是Google Play、Apple App Store,、第三方应用商店还是落地页。延迟深度链接可以在用户打开应用时将其引导至应用中某个特定的页面。

如需实现这个功能，开发人员须使用扩展延迟深度链接。

注意：

• 若需使用UDL，请确保安装SDK V6.1或以上版本。
• 如果您已经在用OneLink进行延迟深度链接，那么您可能是通过历史API的方式实现的，而非UDL。

请参见深度链接和延迟深度链接的设置指南。