AppsFlyer Push API

集成流程

1、客户端集成 AppsFlyer SDK；

2、在DT平台的【管理-数据接入-三方集成-AppsFlyer Push API】中完成相关配置并且复制回传终端地址；

3、在AppsFlyer的【导出-API数据接口-Push API】配置中填充回传终端地址并选择回传事件类型与消息字段；

4、在DT平台的【管理-数据接入-三方集成-AppsFlyer Push API-详情】中校验数据接入情况；

一、集成SDK

1. 集成AppsFlyer SDK，方法如下：
   • Android 参见：AppsFlyer Android SDK guides for developers
   • iOS 参见：AppsFlyer iOS SDK guides for developers
   • Unity 参见：AppsFlyer Unity SDK guides for developers
2. 获取DT_ID：在 DT SDK 初始化完成后，通过 DTAnalytics.getDataTowerId 方法获取 dataTowerId
3. 透传dt_id至AF：在AF初始化前，需要调用 AppsFlyer SDK 的 setAdditionalData 方法将第二步获得的dt_id传至AppsFlyer的SDK，代码如下：
4. 参照方案：如何透传dt_id至第三方

DTAnalytics.getDataTowerId(object : OnDataTowerIdListener {
      override fun onDataTowerIdCompleted(dataTowerId: String) {
          HashMap<String,Object> CustomDataMap = new HashMap<>();
          CustomDataMap.put("dt_id",dataTowerId);
          AppsFlyerLib.getInstance().setAdditionalData(CustomDataMap);
      }
  }

二、方案配置

在客户端的SDK集成与配置完成后，需要在DT平台（数据引擎）的【管理-数据接入-三方集成】中添加“AppsFlyer Push API”方案，并且完成相关配置操作。

1. 回传事件配置：配置需回传的事件类型以及生成名称，并获取用于接收数据的“回传终端地址”；
2. 事件存储配置：决定回传的事件是否要入库存储；
3. 用户识别配置：配置回传的事件数据中可用于作为账号ID的关联规则；
4. 事件属性映射：配置回传的事件数据字段在DT平台的事件属性命名与格式类型；
5. 用户属性更新：配置需要同步至用户属性的回传事件字段，以及其命名与格式类型；

2.1 回传事件配置

AppsFlyer的Push API回传机制可以通过前端配置选择共8类事件以及自定义回传的消息字段。DT平台支持接收所有的回传事件类型，可在方案内配置多种事件类型的回传，并可自行选择是否应用同一套数据接收处理机制。请在完成DT平台的所有方案配置项目之后，再复制“回传终端地址”填充至Appsflyer后台保存配置（具体可见“三、AppsFlyer配置”部分说明）

您可以在“回传事件配置”表单中选择需要回传的事件类型（如“激活（非自然）”）同时可修改将在DT生成的事件名称。

在需要回传“UA应用内事件（非自然）”、“UA应用内事件（自然）”、“再互动应用内事件”、“再归因应用内事件”事件类型时，您可以选择将该类型下的所有事件名称统一映射为“dt_{even_name }”，即回传的“event_name”字段会增加“dt_”前缀后作为DT事件名称呈现（如下图）；

如果需要针对单个“应用内事件”配置DT事件名称时，可选择单个事件选项后输入原事件名称以及期望生成的DT事件名称（注意：其他未配置映射规则的事件，事件名称将默认为“dt_{event_name}”）。

原事件名称可在AppsFlyer的Push API配置中，选择至少一个“应用内事件”的事件类型，在Select in-app events to send的下拉选项中查看可用于回传的事件以及名称。

2.2 事件存储配置

”事件存储配置“可自主控制归因事件数据是否需要入库存储，默认情况下勾选。未勾选时，回传事件数据将不做入库存储，仅用于更新用户属性。

2.3 用户识别配置

“用户识别配置”用于建立DT平台中dt_id、acid与三方数据中相关账号ID的关联关系（dt_id和acid定义可查看ID类别说明）。其中#dt_id为必填项并且默认填充“dt_id”字段取值（当依据本文档完成SDK配置时，可直接使用dt_id值）。DT平台将根据最终输入内容在回传数据进行识别并且关联至平台用户上，若识别无果则该事件数据无效，建议集成并使用dt_id。

2.4 事件属性映射

“事件属性映射”可配置回传的事件数据字段在DT平台的事件属性命名与格式类型。可在“回传属性”列输入原始字段名，在“生成DT属性”中输入期望在DT平台生成的事件属性命名，未配置时将按原始字段入库生成事件属性（注意：当配置不同回传属性映射同一个生成DT属性时，将取后接收的值以覆盖前者）。

支持在“生成DT属性”为首次接入时，自定义其属性类型为文本、数值、时间或布尔，请勿配置与已存在属性冲突的类型，每个属性的类型将在首次接收数据的时候被设置，且不可更改。

在方案中，DT平台提供的默认事件属性映射规则如下。该部分属性将默认存储在dt_ads_object对象下，建议不做变更，以便用于与其他三方接入数据（如广告投放、变现）的关联分析。

2.5 用户属性更新

“用户属性更新”可配置需要同步更新至用户属性的属性命名、格式类型与更新方式。当方案内配置了多种事件类型回传并且期望使用同1套更新规则时，可在“应用范围”内选择针对“所有事件”选项。也可以通过选择“单起事件”模式来实现针对不同事件的个性化配置。更新方式可选择user_set做持续覆盖更新，或者选择user_set_once做仅在首次创建时更新。注意每更新1个用户的属性将生成1起用户事件。

支持在“用户属性”为首次接入时，自定义其属性类型为文本、数值、时间或布尔，请勿配置与已存在属性冲突的类型，每个属性的类型将在首次接收数据的时候被设置，且不可更改。

在Adjust实时回传方案中，DT平台提供的默认用户属性更新规则如下。该部分属性将默认存储在dt_ads_object对象下，建议不做变更，以便用于与其他三方接入数据（如广告投放、变现）的关联分析。当配置“激活”事件回传时，请务必添加“回传属性”为“event_time”，“更新用户属性”为“dt_ads_object.install_time”的规则。

三、AppsFlyer配置

完成DT平台的所有配置并成功保存方案后，可复制在“回传事件配置”中的“回传终端地址”，登录AppsFlyer后在对应应用下的【导出-API数据接口-Push API】配置中“添加端点”，选择“POST”方法并将地址填充在“端点URL”中。

在“事件信息”中选择您在DT集成方案配置中的事件类型，并在“消息字段”中选择您需要回传的字段范围（customData必选，请注意添加），另外“消息字段”将作为事件属性入库，请勿添加过多，避免项目内事件属性量达到限制。

另外如果您需要回传“再互动应用内事件”、“ 再归因应用内事件”或自然类事件，请注意需要勾选“Event Type”字段，以便用于区分事件类型。

四、数据使用

4.1 接入校验

完成DT平台和AppsFlyer后台的相关配置后，可通过“方案状态”判断数据是否已正常接入，当至少有1条数据接收和入库成功后，方案状态将调整为“已接入”（该状态根据数据回传频率实时更新）。

如果您关注整体数据的接收情况，可以通过在“已集成方案”中进入“接入详情”页面，查看每个时段内各类事件的接收量，以及其中的处理异常和处理失败指标，通过失败原因、样例数据确认是否存在诸如属性类型不合法、必填字段缺失等问题。

4.2 使用示例

接收、处理并入库成功的事件与属性数据可以在【管理-数据管理-元事件/事件属性/用户属性】中查看与管理，您可以为事件或属性增加更具备语义化的“显示名”、“描述”信息，便于后续使用以及团队协作理解。

事件和属性数据都可以在分析模型中的筛选或分组项中进行选择使用，例如分析每个广告计划（dt_ads_object.campaign_name）下的某个指标（新用户数、ROI、获客成本、收入）。以分析指标「新用户数」做示例：

分析对象	图例
分析新用户的广告计划分布