您的开发人员需要在应用中的相关位置添加代码，然后您才能发送对应的应用内事件。事件名称和事件参数分为以下几种：

• 预定义型：这类事件名称和事件参数是各种应用中最常用的。建议尽量使用预定义事件名称和事件参数，原因如下：
  • 预定义名称可自动将事件映射到渠道。
  • 如果AppsFlyer决定更改任何事件的名称或参数，您的设置是可以向下兼容的。
• 自定义型：这类事件名称和参数是由您自行根据应用中出现的特定用户场景来定义的。您可以使用任何自定义的事件名称或参数名称字符串，但请注意自定义事件是需要您的开发人员去维护的。详情请见相关建议和限制。

您发送购买或航班预订等应用内事件时，该事件会带有相关收入。在应用内事件中，只有af_revenue参数才能代表收入。

• SDK中的收入记录
• Unity中的收入记录

您可以通过记录负收入来监测取消订单或发出退款等事件。只需在传递到af_revenue的收入值前面加上负号（-）即可记录负收入。

af_revenue是唯一一个能记录用户累计收入的参数。请务必在应用内事件中使用该参数来代表业务逻辑中实际产生的收入。

该参数值的范围应介于$-10,000到$+10,000（或以实际使用货币为单位的等价金额）之间。在这个区间之外的值会出现在原始数据报告中，但汇总报告中不包含这类值。

af_revenue也可以带负值，用来记录取消交易或退款等事件。

• 请勿对收入值进行任何的格式调整。收入值中不能带有逗号分隔符、货币单位、特殊字符或文字。比如1234.56就是一个有效的收入值。AppsFlyer可支持精确到小数点后五位的收入值。
• AppsFlyer后台会按原样展示SDK上报的收入数据，其中对VAT或应用商店抽成等不做任何计算。如需对SDK上报的收入作相应调整，SDK侧开发人员需要在上报收入前写入相关运算。

af_currency代表af_revenue（或 af_price）中所呈现金额的货币单位。如果事件中没有配置af_currency参数，AppsFlyer会以默认值“USD”（美元）为单位发送数据。

您可以将af_price用作不计收入的金额参数（在“添加到购物车”等事件中配置）。该参数代表商品单价，所有购买的总金额须用af_revenue参数表示。

收入数据的货币单位

AppsFlyer处理货币设置和货币换算的方式是非常重要的知识点，建议您了解相关内容。

AppsFlyer会通过货币换算来调和应用配置中的指定货币与应用内事件货币之间的差异。

上图说明了货币换算的大致流程，具体内容如下：

1. SDK发送应用内事件 — 每个事件的货币各不相同
2. AppsFlyer将所有货币统一换算到美元
3. AppsFlyer处理收入数据
4. 面板会按应用配置中的指定货币显示收入数据
5. AppsFlyer会在原始数据报告中同时用事件货币和应用配置中的指定货币来填充收入数据。

AppsFlyer使用Open Exchange Rates进行货币换算，其中的汇率每小时更新一次。AppsFlyer总是使用最近一小时内更新的汇率进行货币换算。

货币换算

Map<String, Object> eventValue = new HashMap<String, Object>();
eventValue.put(AFInAppEventParameterName.REVENUE,200);
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"category_a");
eventValue.put(AFInAppEventParameterName.CONTENT_ID,"1234567");
eventValue.put(AFInAppEventParameterName.CURRENCY,"EUR");
AppsFlyerLib.getInstance().trackEvent(getApplicationContext(), AFInAppEventType.PURCHASE , eventValue);

货币显示

货币单位是在应用配置中设置的。您在应用配置中设置的货币单位就是面板数据的货币单位。无论您的应用内事件是以什么货币发送的，面板总是会按您在应用配置中设置的货币来显示收入数据。

确定了要衡量的应用内事件后，请使用应用内事件生成器按以下方式对事件和参数进行定义：

1. 基于您想要记录的场景，选择最合适的事件名称。
2. 考虑一下哪些参数能为该事件提供更多背景、使数据更丰富，以此来选择与该事件相关联的事件参数。
3. 应用内事件生成器会根据您的设置生成相应代码并打包成压缩文件，请在生成器页面下载该文件并发送给您的开发人员。

下表所列的文章是我们针对各垂类推荐的常见应用内事件，其中包含实例和流程。

业务垂类	文章标题
	游戏类应用内事件推荐
	电商类应用内事件推荐
	娱乐类应用内事件推荐
	金融银行类应用内事件推荐
	P2P贷款类应用内事件推荐
	在线教育类应用内事件推荐
	打车类应用内事件推荐
	机票预订类应用内事件推荐
	酒店预订类应用内事件推荐
	医疗保健类应用内事件推荐
	电信类应用内事件推荐
	电子钱包类应用内事件推荐
	体育博彩类应用内事件推荐

用户从某个媒体渠道安装应用后，该用户整个生命周期内发生的应用内事件都会归因到这个渠道。事件数据以用户生命周期价值或行为数据的形式呈现。

您可在下列板块中查看应用内事件数据：

• 总览面板：实时显示用户获取（UA）的LTV效果数据。请注意：其中包含通过应用事件上报的收入数据，分为自然量和非自然量收入，同时包括双重归因的再营销收入。
• 事件页面： 显示不同媒体渠道的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的原始和聚合数据中记录收入（包括负收入），必须使用af_revenue参数。请务必根据您的业务逻辑，选择能实际产生收入的应用内事件来使用该参数。

af_currency代表af_revenue（或af_price）中所呈现金额的币种。如果事件参数中没有af_currency，那么AppsFlyer会默认以美元发送收入数据。

关于af_revenue参数的详细信息，请参见收入归因指南。

AppsFlyer会将应用内事件归因到最初带来应用激活的那个媒体渠道。

用户激活应用（即首次打开应用）时，AppsFlyer会通过各种归因方式判断这次激活的归因结果。同时，AppsFlyer的SDK会生成一个全新的AppsFlyer ID，并关联到归因信息。

之后用户在同一个设备上完成的每一个应用内事件都会带有这个ID。这样，AppsFlyer就可以通过该ID将这些事件归因到最初带来用户的渠道，而广告主则可以使用该ID来追溯用户在其应用中的完整链路。

由新近再营销广告促成的事件可能会受到双重归因。

出现以下情况时，AppsFlyer会将用户在非自然激活后完成的事件计为自然量：

• 用户激活应用后过了24个月才执行事件。
• 媒体渠道规定必须删除用户层级数据。
• 用户删除了应用在其设备上存储的数据，迫使SDK生成新的AppsFlyer ID。

AppsFlyer可以记录用户在离线时触发的事件，其工作原理如下：

1. SDK向AppsFlyer服务器发送事件后，会等待服务器回复一个发送成功的信息。
2. 如果SDK没有接收到这个信息，那么事件就会被保存到缓存中。
3. 而一旦收到了发送成功的回复，缓存中的事件就会被再次发送到服务器。
4. 如果缓存中有多个事件，这些事件会依次被发送到服务器。

复杂应用内事件允许通过一次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"
   }
  ]
}

您可以在单笔交易中添加多件商品。您可以用多件商品的数组来描述一笔交易，商品之间用逗号区隔开，不需要针对每件商品分开填写参数值。格式是JSON字符串。

"{\"af_content_id\": [\"123\",\"988\",\"399\"], \"af_quantity\": [\"2\",\"1\",\"1\"], \"af_price\": [\"25\",\"50\",\"10\"], \"af_revenue\": \"110\", \"af_currency\": \"USD\"}"

我们会通过应用内事件去重机制检查所有的应用内事件，查看是否有同一个appsflyer_id在10秒内发送相同事件的情况。如果发现此类情况，该机制会把重复的事件删除。

如果两个事件中的以下字段相同, 系统将视其为同一个事件:

• eventName
• Event value
• App ID
• AppsFlyer ID

对于用户层级的数据（即原始数据），AppsFlyer会保留24个月，除非法律另有指示、要求或许可。某些SRN/渠道会要求AppsFlyer等归因服务方在24个月到期之前就删除与其相关的用户层级数据。

数据一经删除，与被删除的用户有关的事件就会显示为自然流量事件，但之前的聚合数据保持不变。请参阅数据保留与删除义务了解详情。

• 安卓SDK和iOS SDK会自动添加OS（操作系统）参数。
• 对于S2S API，自2021年7月1日起，iOS应用必须发送OS（操作系统）参数。如果您不发送这个参数，那么系统就会默认数据来自iOS 14.5的用户，这会影响原始数据的呈现方式。