概要：记录激活后的富应用内事件（如登录、注册或内购），将其归因到媒体渠道和广告活动。
为什么要记录应用内事件？
应用内事件能让您深入了解用户动态，帮助您有效识别用户价值以及来自不同媒体渠道的流量质量。记录应用内事件有助于您衡量ROI（投资回报率）和LTV（生命周期价值）等各项KPI。
当用户进行注册、完成教程、将商品添加到购物车或购买商品时，应用内事件数据会记录这些事件及其详细信息。如果要分析激活后的用户行为，就必须启用应用内事件。
关于应用内事件
创建应用内事件时，您需要填写事件名称，也可以添加事件参数。当您在应用内事件中加入事件参数时，该事件就被称为富应用内事件。事件参数能针对正在发生的事件提供更多背景和信息。比如，在用户预订机票后，您不仅能看到这个订票事件，还能通过事件参数了解订单详情，如购买类型、目的地和收入金额等。
预定义和自定义事件
您的开发人员需要在应用中的相关位置添加代码，然后您才能发送对应的应用内事件。事件名称和事件参数分为以下几种：
-
预定义型：这类事件名称和事件参数是各种应用中最常用的。建议尽量使用预定义事件名称和事件参数，原因如下：
- 预定义名称可自动将事件映射到渠道。
- 如果AppsFlyer决定更改任何事件的名称或参数，您的设置是可以向下兼容的。
- 自定义型：这类事件名称和参数是由您自行根据应用中出现的特定用户场景来定义的。您可以使用任何自定义的事件名称或参数名称字符串，但请注意自定义事件是需要您的开发人员去维护的。详情请见相关建议和限制。
发送事件
您可通过多种方式将应用内事件发送给AppsFlyer：
- AppsFlyer SDK：这是最常用的事件发送方式。您可以在SDK级别使用AppsFlyer应用内事件API发送富应用内事件，以记录用户在应用中的行为。
- 服务器到服务器（S2S）API：使用S2S API可以直接向AppsFlyer发送在移动应用以外发生的事件。例如，如果您有用户同时活跃于Web端和移动端，您可以通过这类API同时记录来自这两个端的事件，并在AppsFlyer中将这些事件匹配到同一个用户。它可以是应用内事件，也可以是其他事件，例如：网站事件、呼叫中心事件或实体店购买事件。
- 收据验证：苹果和谷歌等支付平台可以通过这个安全的机制来验证报告中所呈现的应用内购事件是否真实发生。验证购买是防止内购刷单的主要手段。您还可以通过该机制查看真实的收入数据，并过滤掉未完成的应用内购买。
- 混合应用：这类应用结合了原生视图和HTML内容，同时也可以记录应用内事件。但由于SDK只能从原生侧发送事件，因此开发人员需要将所有事件数据转发到原生代码。
设置应用内事件
应用内事件的设置流程需要市场人员和开发人员的共同参与，具体方法如下：
| 步骤 | 角色 | 任务 | 细节 |
|---|---|---|---|
|
1 |
市场人员 |
建议先设置3-5个事件作为KPI来衡量用户的质量（如购买、注册、分享）。事件参数不是必须设置的项目，您可以为任一事件名称设置任何事件参数。 常见的应用内事件请参考针对各垂类的推荐事件。 |
|
| 2 | 开发人员 |
在应用中的相关位置添加代码。 |
点击此处查看开发者文档。 |
| 3【可选】 | 市场人员 | 与开发人员合作设置客户用户ID字段（CUID）。 |
该字段以CUID为密匙，将AppsFlyer归因数据与其他数据进行对照，从而使应用内事件数据更丰富。 |
| 4【可选】 | 市场人员 | 在控制面板中将事件映射到相应的渠道。 | 这是一项长期持续的工作，具体取决于与您对接的渠道。 |
定义应用内事件
确定了要衡量的应用内事件后，请使用应用内事件生成器按以下方式对事件和参数进行定义：
- 基于您想要记录的场景，选择最合适的事件名称。
- 考虑一下哪些参数能为该事件提供更多背景、使数据更丰富，以此来选择与该事件相关联的事件参数。
- 应用内事件生成器会根据您的设置生成相应代码并打包成压缩文件，请在生成器页面下载该文件并发送给您的开发人员。
示例
一个电商应用的市场人员想要记录用户浏览的内容类型，以更好地了解哪些品类最受欢迎，并查看商品浏览量与商品销量之间的关系。
下表为该市场人员发送给开发人员的事件结构范例：| eventName | 事件参数 | 参数值： | 事件何时被触发？ |
|---|---|---|---|
| af_content_view | af_price | 产品价格 |
当用户浏览特定的商品详情页时 |
| af_content_type | 商品品类名称，如鞋类 | ||
| af_content_id |
商品ID，如SKU |
针对各垂类的推荐事件
下表所列的文章是我们针对各垂类推荐的常见应用内事件，其中包含实例和流程。
| 业务垂类 | 文章标题 |
|---|---|
 |
游戏类应用内事件推荐 |
 |
电商类应用内事件推荐 |
 |
娱乐类应用内事件推荐 |
 |
金融银行类应用内事件推荐 |
 |
P2P贷款类应用内事件推荐 |
 |
在线教育类应用内事件推荐 |
 |
打车类应用内事件推荐 |
 |
机票预订类应用内事件推荐 |
 |
酒店预订类应用内事件推荐 |
 |
医疗保健类应用内事件推荐 |
 |
电信类应用内事件推荐 |
 |
电子钱包类应用内事件推荐 |
 |
体育博彩类应用内事件推荐 |
查看应用内事件数据
用户从某个媒体渠道安装应用后，该用户整个生命周期内发生的应用内事件都会归因到这个渠道。事件数据以用户生命周期价值或行为数据的形式呈现。
您可在下列板块中查看应用内事件数据：
- 控制面板的概览页面：显示实时LTV获客（UA）效果
- 事件页面： 显示不同媒体渠道的LTV应用内事件效果
-
原始数据应用内事件报告：展示行为数据及其含义，以及整个用户群的行为列表（按时间顺序罗列）。该报告包含事件参数值，如：
{ "af_level":"10", "af_score":"3387", "arena":"7", "char_type":"paladin" }请注意，原始数据报告是高阶功能。
建议
设置应用内事件名称和参数时请注意以下几点：
- 为确保原始数据报告中的数据一致性，我们建议在各平台上使用相同的应用内事件名称和结构，并对其做出相同的定义。
- 在对比不同渠道的用户质量时，建议您有针对性地选取事件，尽量缩减事件数量，以简化分析工作。
- 为了保护用户的隐私安全，请确保事件值中不包含能直接识别用户身份的信息，包括邮箱地址、姓名、身份证件号码等，这些都是保密信息。详情请见服务隐私政策。
- 请注意，AppsFlyer会在用户互动期间收集设备的IP地址。在某些地区或使用场景中，IP地址也被视为个人身份识别信息（PII）。我们仅使用IP地址来获取粗粒度的地理位置信息（城市、行政区划层级），而非详细地址。如有需要，您可选择掩盖IP地址，不让这些信息出现在原始数据报告中。
- 应用内事件是AppsFlyer中收入数据的唯一来源。您可以为每个事件设定具体的收入值, 然后在应用的控制面板中查看相关数据。详情请参考变现参数。
限制
设置应用内事件名称和参数时请注意以下几点：
- 建议仅使用小写字母和数字（a-z 和0-9）来命名您的应用内事件。事件名称区分大小写，也就是说af_purchase和af_PURCHASE在原始数据中是两个不同的事件，但在聚合报告（如“概览”或“事件“面板）中可以显示为同一个事件。
- 每天最多可用300个不同的事件。了解详情
- 用户激活应用后完成的前100个事件有独立用户数指标，之后的事件不再统计该指标。
- 事件名称不能以下列字符开头：" = + -
- 事件值不能超过1000个字符。
- 如果事件值中包含链接，该链接必须经过URL编码。
- Facebook对于事件名称和参数设有限制。点击此处查看限制详情。
常见问题解答
本章解答了关于应用内事件的常见问题。
如何使用收入参数？
AppsFlyer是如何对事件进行归因的？
AppsFlyer会将应用内事件归因到最初带来应用激活的那个媒体渠道。
用户激活应用（即首次打开应用）时，AppsFlyer会通过各种归因方式判断这次激活的归因结果。同时，AppsFlyer的SDK会生成一个全新的AppsFlyer ID，并关联到归因信息。
之后用户在同一个设备上完成的每一个应用内事件都会带有这个ID。这样，AppsFlyer就可以通过该ID将这些事件归因到最初带来用户的渠道，而广告主则可以使用该ID来追溯用户在其应用中的完整链路。
由新近再营销广告促成的事件可能会受到双重归因。
出现以下情况时，AppsFlyer会将用户在非自然激活后完成的事件计为自然量：
- 用户激活应用后过了24个月才执行事件。
- 媒体渠道规定必须删除用户层级数据。
- 用户删除了应用在其设备上存储的数据，迫使SDK生成新的AppsFlyer ID。
能否记录离线设备上的事件？
AppsFlyer可以记录用户在离线时触发的事件，其工作原理如下：
- SDK向AppsFlyer服务器发送事件后，会等待服务器回复一个发送成功的信息。
- 如果SDK没有接收到这个信息，那么事件就会被保存到缓存中。
- 而一旦收到了发送成功的回复，缓存中的事件就会被再次发送到服务器。
- 如果缓存中有多个事件，这些事件会依次被发送到服务器。
注意
SDK的缓存最多可以存储40个事件，也就是说只有最早发生的40个离线事件会被保存下来。在这之后发生的所有事件都会被删除，直到下一次发送成功为止。
原始数据中显示的事件时间是设备再次联机后事件发送到AppsFlyer的时间，而不是事件实际发生的时间。
复杂应用内事件的含义和设置方法
复杂应用内事件允许通过一次API调用发送多个事件。
复杂应用内事件能将多个紧密相关的用户行为归到一起，便于查看（如在一次会话中将多件商品加入购入车）。
示例：
{
"af_revenue":"50.87",
"af_currency":"USD",
"af_receipt_id":"57601333",
"product":[
{
"af_content_id":"1164_8186",
"af_price":"8.97",
"af_quantity":"1"
},
{
"af_content_id":"1164_8186",
"af_price":"8.97",
"af_quantity":"1"
},
{
"af_content_id":"1164_8186",
"af_price":"8.97",
"af_quantity":"1"
},
{
"af_content_id":"1177_8185",
"af_price":"8.97",
"af_quantity":"1"
},
{
"af_content_id":"0153_9077",
"af_price":"14.99",
"af_quantity":"1"
}
]
}
注意
复杂应用内事件在回传到Facebook和Criteo时会出现问题。如果您需要将事件完整映射到Facebook和Criteo，请针对每个用户行为分别发送事件（如针对每件加购商品分开发送加购事件），然后利用应用内事件原始数据将这些事件归到一起。
能否在单笔交易中添加多件商品？
您可以在单笔交易中添加多件商品。您可以用多件商品的数组来描述一笔交易，商品之间用逗号区隔开，不需要针对每件商品分开填写参数值。格式是JSON字符串。
示例
Smith先生在一家美国线上商店下单，在这一单中他分别购买了两件相同的衬衫、一双鞋和一个帽子。每件商品的罗列次序必须与各参数完全一致。
"{\"af_content_id\": [\"123\",\"988\",\"399\"], \"af_quantity\": [\"2\",\"1\",\"1\"], \"af_price\": [\"25\",\"50\",\"10\"], \"af_revenue\": \"110\", \"af_currency\": \"USD\"}"
多商品事件一般会以数组的形式回传。目前，Facebook和Twitter都无法正确解析数组。为协助解决这个问题，AppsFlyer不再把多件商品以数组形式发送给SRN，而是对商品数量（af_quantity）进行加总。在上述案例中，Facebook就会收到af_quantity=4。
注意
您可以在以下应用内事件中使用多商品描述：
af_add_to_cart, af_add_to_wishlist, af_tutorial_completion, af_initiated_checkout, af_purchase, af_rate, af_spent_credits, af_content_view, af_travel_booking, af_update
AppsFlyer如何进行事件去重？
我们会通过应用内事件去重机制检查所有的应用内事件，查看是否有同一个appsflyer_id在10秒内发送相同事件的情况。如果发现此类情况，该机制会把重复的事件删除。
如果两个事件中的以下字段相同, 系统将视其为同一个事件:
- eventName
- Event value
- App ID
- AppsFlyer ID
注意
去重机制仅适用于从SDK发送的应用内事件。
服务器对服务器的应用内事件不会去重。
AppsFlyer对用户层级数据会保留多久？负有什么删除义务？
对于用户层级的数据（即原始数据），AppsFlyer会保留24个月，除非法律另有指示、要求或许可。某些SRN/渠道会要求AppsFlyer等归因服务方在24个月到期之前就删除与其相关的用户层级数据。
数据一经删除，与被删除的用户有关的事件就会显示为自然流量事件，但之前的聚合数据保持不变。请参阅数据保留与删除义务了解详情。