集成流程
1、客户端集成 AppsFlyer SDK;
2、在AppsFlyer的【安全中心】获取API token以及在【首页】产品下获取 App ID;
3、在DT平台的【管理-数据接入-三方集成-AppsFlyer Raw Data Pull API】中完成相关配置;
4、在DT平台的【管理-数据接入-三方集成-AppsFlyer Raw Data Pull API-详情】中校验数据接入情况;
一、集成SDK
- 集成AppsFlyer SDK,方法如下:
- 获取DT_ID:在 DT SDK 初始化完成后,通过
DTAnalytics.getDataTowerId
方法获取dataTowerId
- 透传dt_id至AF:在AF初始化前,需要调用 AppsFlyer SDK 的
setAdditionalData
方法将第二步获得的dt_id传至AppsFlyer的SDK,代码如下: - 参照方案:如何透传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 Raw Data Pull API”方案,并且完成相关配置操作。
- API授权配置:配置API token以及App ID,完成授权校验;
- 定时拉取配置:配置请求拉取报表数据的频率;
- 拉取时区配置:配置Appsflter中应用的特定时区;
- 事件存储配置:决定回传的事件是否要入库存储;
- 用户识别配置:配置回传的事件数据中可用于作为账号ID的关联规则;
- 事件类型配置:配置需拉取的事件类型以及生成名称;
- 事件属性映射:配置获取到的事件数据字段在DT平台的事件属性命名与格式类型;
- 用户属性更新:配置需要同步至用户属性的回传事件字段,以及其命名与格式类型;
2.1 API授权配置
登录AppsFlyer后台后按下述步骤获取API token以及App ID。
说明 | |
---|---|
API token | 参考:API token 管理指南-AppsFlyer
1. 从菜单栏中,访问用户菜单(右上角的电子邮件地址下拉菜单) 2. 选择安全中心。在 AppsFlyer API 令牌部分,单击管理您的 AppsFlyer API 令牌 3. 显示可用的令牌(V2.0) 4. 复制所需的令牌。 |
App ID | 在 Appsflyer 首页产品下获取,见下图
|
登录DT后台在“AppsFlyer Raw Data Pull API”方案的“API授权配置”中点击“授权”进入弹窗完成授权操作。
2.2 定时拉取配置
“定时拉取配置”可配置请求拉取报表数据的频率。可以自行控制在每天的一个固定整点或每小时进行拉取指定天数范围的数据。AppsFlyer的Pull报告拉取存在限制(详情可见报告拉取限额说明),比如每个账户每天最多120次,请确认您的账户下是否存在多个项目配置了Pull方案以及尽量降低拉取频次,避免触发限制。
当触发频次限制时(接口返回400),将无法获取数据,在方案“接入详情”中将通过请求结果提示失败以及原因
2.3 拉取时区配置
“拉取时区配置”可配置目前项目的本地化时区,需要与【AppsFlyer-应用配置】中的时区设置一致。需要注意,如果该设置为空则数据默认会使用UTC时间返回。
2.4 事件存储配置
”事件存储配置“可自主控制归因事件数据是否需要入库存储,默认情况下勾选。未勾选时,回传事件数据将不做入库存储,仅用于更新用户属性。
2.5 用户识别配置
“用户识别配置”用于建立DT平台中dt_id、acid与三方数据中相关账号ID的关联关系(dt_id和acid定义可查看ID类别说明)。其中#dt_id为必填项并且默认填充“dt_id”字段取值(当依据本文档完成SDK配置时,可直接使用dt_id值)。DT平台将根据最终输入内容在回传数据进行识别并且关联至平台用户上,若识别无果则该事件数据无效,建议集成并使用dt_id。
2.6 事件类型选择
AppsFlyer的Pull API回传机制可以通过请求不同的接口类型获取对应的报告数据,比如激活、自然激活、应用内事件等。DT平台支持请求获取自然和非自然的原始数据报告,可在方案内配置多种事件类型的获取,并可自行设置数据接收后是否应用同一套数据接收处理机制。
您可以在“回传事件配置”表单中选择需要拉取的事件类型(如“激活(非自然)”)同时可修改将在DT生成的事件名称。
在拉取“In-app event”、“Organic In-app events”事件类型的数据时,您可以选择获取该类型下的所有事件,并且可将名称统一映射为“dt_{even_name }”,即回传的“event_name”字段会增加“dt_”前缀后作为DT事件名称呈现(如下图);
如果只需要获取个别事件,可在事件类型“In-app event”或“Organic In-app events”的二级选项中选择“单个应用内事件”后输入对应的事件名称,在请求时将作为筛选条件获取。您同时可以在表单中配置期望生成的DT事件名称。
2.7 事件属性映射
AppsFlyer Raw Data Pull API的响应数据默认会固定返回如【表1】字段,“事件属性映射”可配置回传的事件数据字段在DT平台的事件属性命名与格式类型(包含在“添加事件属性”配置中额外添加的字段)。可在“回传属性”列输入原始字段名,在“生成DT属性”中输入期望在DT平台生成的事件属性命名,未配置时将按原始字段入库生成事件属性(注意:当配置不同回传属性映射同一个生成DT属性时,将取后接收的值以覆盖前者)。
字段 | 中文名 |
attributed_touch_time | 归因时间 |
install_time | 激活时间 |
event_time | 事件时间 |
event_name | 事件名称 |
event_value | 事件值 |
event_revenue | 事件收益 |
event_revenue_currency | 事件收益货币类型 |
event_revenue_usd | 事件收益(USD) |
event_source | 事件来源 |
is_receipt_validated | 是否开启验证接收 |
partner | 合作伙伴 |
media_source | 媒体渠道 |
channel | 子渠道 |
keywords | 关键词 |
campaign | 广告计划名称 |
campaign_id | 广告计划 ID |
adset | 广告组名称 |
adset_id | 广告组 ID |
ad | 广告素材名称 |
ad_id | 广告素材 ID |
ad_type | 广告类型 |
site_id | 站点 ID |
sub_site_id | 子站点 ID |
sub_param_1 | 子参数 1 |
sub_param_2 | 子参数 2 |
sub_param_3 | 子参数 3 |
sub_param_4 | 子参数 4 |
sub_param_5 | 子参数 5 |
cost_model | 成本模型 (CPC/CPI/CPM/Other) |
cost_value | 成本值 |
cost_currency | 成本货币类型 |
contributor_1_partner | 贡献者 1 合作伙伴 |
contributor_1_media_source | 贡献者 1 媒体渠道 |
contributor_1_campaign | 贡献者 1 广告计划 |
contributor_1_touch_type | 贡献者 1 归因类型 |
contributor_1_touch_time | 贡献者 1 归因时间 |
contributor_2_partner | 贡献者 2 合作伙伴 |
contributor_2_media_source | 贡献者 2 媒体渠道 |
contributor_2_campaign | 贡献者 2 广告计划 |
contributor_2_touch_type | 贡献者 2 归因类型 |
contributor_2_touch_time | 贡献者 2 归因时间 |
contributor_3_partner | 贡献者 3 合作伙伴 |
contributor_3_media_source | 贡献者 3 媒体渠道 |
contributor_3_campaign | 贡献者 3 广告计划 |
contributor_3_touch_type | 贡献者 3 归因类型 |
contributor_3_touch_time | 贡献者 3 归因时间 |
region | 地区 |
country_code | 国家代码 |
state | 州/省 |
city | 城市 |
postal_code | 邮政编码 |
dma | DMA码 |
ip | IP地址 |
wifi | 是否开启WI-FI |
operator | 移动运营商 |
carrier | 手机运营商 |
language | 语言 |
appsflyer_id | AppsFlyer ID |
advertising_id | Advertising ID |
idfa | IDFA |
android_id | Android ID |
customer_user_id | Customer User ID |
imei | IMEI |
idfv | IDFV |
platform | 平台 |
device_type | 设备类型 |
os_version | 操作系统 |
app_version | 应用版本 |
sdk_version | SDK 版本 |
app_id | App ID |
app_name | 应用名称 |
bundle_id | Bundle ID |
is_retargeting | 是否再营销 |
retargeting_conversion_type | 再营销转化类型 |
attribution_lookback | 归因 Lookback |
reengagement_window | 再互动窗口 |
is_primary_attribution | 是主归因 |
user_agent | 用户代理 |
http_referrer | HTTP Referrer |
original_url | 原始 URL |
支持在“生成DT属性”为首次接入时,自定义其属性类型为文本、数值、时间或布尔,请勿配置与已存在属性冲突的类型,每个属性的类型将在首次接收数据的时候被设置,且不可更改。
DT平台提供的默认事件属性映射规则如下。该部分属性将默认存储在dt_ads_object对象下,建议不做变更,以便用于与其他三方接入数据(如广告投放、变现)的关联分析。
|
AF返回字段
|
事件属性映射默认配置
|
---|---|---|
1
|
Media Source
|
dt_ads_object.media_source
|
2
|
Campaign
|
dt_ads_object.campaign_name
|
3
|
Campaign ID
|
dt_ads_object.campaign_id
|
4
|
Adset
|
dt_ads_object.adgroup_name
|
5
|
Adset ID
|
dt_ads_object.adgroup_id
|
6
|
Ad
|
dt_ads_object.ad_name
|
7
|
Ad ID
|
dt_ads_object.ad_id
|
8
|
Channel
|
dt_ads_object.platform_name
|
2.9 用户属性更新
“用户属性更新”可配置需要同步更新至用户属性的属性命名、格式类型与更新方式。当方案内配置了多种事件类型回传并且期望使用同1套更新规则时,可在“应用范围”内选择针对“所有事件”选项。也可以通过选择“单起事件”模式来实现针对不同事件的个性化配置。更新方式可选择user_set做持续覆盖更新,或者选择user_set_once做仅在首次创建时更新。注意每更新1个用户的属性将生成1起用户事件。
支持在“用户属性”为首次接入时,自定义其属性类型为文本、数值、时间或布尔,请勿配置与已存在属性冲突的类型,每个属性的类型将在首次接收数据的时候被设置,且不可更改。
方案中,DT平台提供的默认用户属性更新规则如下。该部分属性将默认存储在dt_ads_object对象下,建议不做变更,以便用于与其他三方接入数据(如广告投放、变现)的关联分析。当配置“installs”事件回传时,请务必添加“回传属性”为“event_time”,“更新用户属性”为“dt_ads_object.install_time”
|
AF返回字段
|
用户属性更新默认配置
|
---|---|---|
1
|
Media Source
|
dt_ads_object.media_source
|
2
|
Campaign
|
dt_ads_object.campaign_name
|
3
|
Campaign ID
|
dt_ads_object.campaign_id
|
4
|
Adset
|
dt_ads_object.adgroup_name
|
5
|
Adset ID
|
dt_ads_object.adgroup_id
|
6
|
Ad
|
dt_ads_object.ad_name
|
7
|
Ad ID
|
dt_ads_object.ad_id
|
8
|
Channel
|
dt_ads_object.platform_name
|
三、数据使用
3.1 接入校验
完成DT平台的相关配置后,可通过“方案状态”判断数据是否已正常接入,当至少有1条数据接收和入库成功后,方案状态将调整为“已接入”(该状态根据数据回传频率实时更新)。
如果您关注整体数据的接收情况,可以通过在“已集成方案”中进入“接入详情”页面,查看每小时段的请求结果是否成功,如果存在请求失败可通过“失败”状态的悬浮提示文案查看具体原因为请求限额或者是参数配置问题,以便进一步排查解决。
同时可检查每个时段内各类事件的接收量,以及其中的处理异常和处理失败指标,通过失败原因、样例数据确认是否存在诸如属性类型不合法、必填字段缺失等问题。
3.2 使用示例
接收、处理并入库成功的事件与属性数据可以在【管理-数据管理-元事件/事件属性/用户属性】中查看与管理,您可以为事件或属性增加更具备语义化的“显示名”、“描述”信息,便于后续使用以及团队协作理解。
事件和属性数据都可以在分析模型中的筛选或分组项中进行选择使用,例如分析每个广告计划(dt_ads_object.campaign_name)下的某个指标(新用户数、ROI、获客成本、收入)。以分析指标「新用户数」做示例:
分析对象 | 图例 |
---|---|
分析新用户的广告计划分布 | ![]() |