一笔9.99的订单在AppsFlyer变成999，或者交易数量正确但收入为零，应先检查该笔订单的数据链，暂时不要调整广告预算。本文只解决收入金额与币种验收，适用于已经接入事件的应用。以下订单、商品、数额和字段组合均为虚构演示，不代表真实交易或客户成果。
先确认收入由哪条链路生成
开始前列出手动SDK事件、服务端事件、收据验证及ROI360商店收入等现有来源，并写明每一类收入由谁负责。AppsFlyer的ROI360商店收入文档明确提醒，使用该方案时再发送应用内购买事件会造成重复收入。
因此下文的手动af_revenue示例，只用于已经确认需要手动上报且没有自动链路重复覆盖的场景。已使用ROI360的应用，应首先验证购买连接器、商店通知及产品生成事件；不能看到购买按钮就额外补发一笔af_purchase。其他验证方案也应按其文档核对是否生成收入事件，不能凭产品名称推断。
第一步：把金额口径写成一条明确规则
编辑建议在代码验收前，让产品、财务和数据同事共同确认：记录的是成交金额、税费处理后的金额，还是净收入；退款按什么时点计入；优惠券由谁承担；一次购买多件商品时使用单价还是总价。口径没有统一，任何平台之间的总额都可能看起来“不对”。
虚构规则示例：一次购买两件，每件4.99美元，优惠1.00美元，本例假定无其他税费，成功收款总额8.98美元。若该业务决定以成功收款总额记收入，则发送8.98，而不是4.99、9.98或898。这里的计算规则只服务这个例子，不能自动套用到其他业务。
第二步：检查真正计入收入的字段
按官方事件结构，af_revenue用于收入，包含退款等负收入；af_price用于商品价格。仅上报商品单价和数量，不应期待平台自动按你的订单规则计算总收入。
下面是事件参数示意，不是某个S2S接口的完整请求体：
{
"af_revenue": 8.98,
"af_currency": "USD",
"af_price": 4.99,
"af_quantity": 2,
"qa_order_ref": "DEMO-ORDER-001"
}qa_order_ref是本文自定义的虚构对账标签，不代表AppsFlyer保证用它自动去重。实现时要用当前SDK支持的类型与接口；不要把通用JSON片段直接复制为全部平台的函数调用。
官方收入排障特别要求金额不包含千位逗号、货币符号或文字。将“$8.98”“8,98 EUR”“8.98美元”直接作为金额，会引入解析问题。UI本地化展示与SDK数值应分开：界面可以显示当地格式，上报保留规范数值。
第三步：重点防止分、微单位与主币种混淆
如果支付系统返回898分，转成美元主单位才是8.98；如果某上游接口返回微单位，换算尺度又不同。这里不能统一写成“金额一律除以100”，因为不同接口的单位和不同币种的小数规则并不相同。
- 在每个上游字段旁标注单位及币种，如“minor units，USD”，而不是只写amount。
- 在订单模型边界完成一次换算，记录输入值、换算规则和输出值。
- 上报前做范围与精度校验，避免重复除法或重复乘法。
- 用小数金额、整数金额及边界金额分别测试，不只测1美元。
SDK事件规范允许收入保留最多五位小数。编辑建议使用明确的小数金额处理方式，避免从本地化字符串解析金额，也避免为了消除浮点尾数而随意四舍五入到整数。精度规则应先由业务定义，再按接口支持范围发送。
第四步：核对交易币种与报表币种
Android事件指南规定，af_currency使用三位ISO 4217代码，默认币种为USD。多币种业务建议每笔明确传入与af_revenue一致的币种，避免设备语言、用户所在国或应用展示币种被误当成成交币种。
虚构错误例子：订单实际收取8.98欧元，却发送af_currency=USD。它不是“展示差异”，而是原始输入已经错误。相反，若输入为8.98欧元、报表按美元展示，数值不同可能来自正常换汇，不能立即补发收入。
AppsFlyer币种处理说明指出，收入会经过币种换算，仪表盘按应用设置币种展示，使用的汇率按小时更新。不要拿今天银行结算汇率去要求历史事件的展示金额逐分一致，也不要提前把金额换成美元后仍标记原币种。
第五步：逐笔对账，再比较汇总
先定位同一测试订单的原始事件值、事件收入及事件收入币种，再查看换算字段。根据原始数据字段字典，即使字段名带USD，也需要结合报表工具判断输出币种：Data Locker、导出页和Pull API存在不同规则。不要只看列名就将各来源直接相加。
使用Pull API时，另行保存currency、timezone、日期和过滤条件；官方接口支持preferred或USD等币种选择。核对同一时间范围、相同事件集合和相同币种之后，才比较汇总金额。安装日期口径和事件发生日期口径也应按当前报表定义统一。
用三笔虚构样本快速找出错误
- A：成功订单8.98 USD，预期一条有效收入，原币金额8.98。
- B：成功订单8.98 EUR，预期原币仍为8.98 EUR；换算金额按实际报表记录核对，不预造汇率。
- C：A发生2.00 USD部分退款，手动链路按业务规则记录-2.00 USD；本例A与退款的原币合计为6.98 USD。
上述测试不应混进正式销售结论。如果同一订单出现两条正收入，检查SDK与服务端是否都发送、支付成功回调是否重入、页面恢复是否再次触发，以及自动购买测量是否已开启。只添加订单字段并不会自动让所有链路统一去重；幂等规则需要按具体方案实现并验证。
净收入与问题修正的最后检查
当前官方支持额外的af_net_revenue用于净收入，它不替代af_revenue；净额口径由相应业务逻辑或ROI360方案决定。净收入指标说明也区分了自动生成和自行传入的来源。不要把净回款与毛收入指标直接对比，或者在已经扣除佣金的金额上再次扣除。
- 每种收入来源有明确责任方，无同一交易重复覆盖。
- 金额单位、精度、正负号和币种逐笔可追溯。
- 商品价格、订单总额、毛收入与净收入分别定义。
- 退款、重试和多币种样本已验收，查询币种与时区已保存。
- 历史错误单独评估处理方式，未用补发一整笔收入草率“修平”。
需要支持协助时，提供脱敏事件参数、报告类型、查询条件和对账差额。不要把商店密钥、完整收据或付款人的个人信息贴到公开讨论区。先修正数据生成和重复链路，再观察后续样本，才能让收入报表成为可靠的投放依据。
问题找早鸟出海，早鸟出海（NBOVERSEA）深耕出海近十年。专业提供谷歌、苹果APP代上架服务，支持PWA/W2A/H5/APP广告代投，提供Google/Facebook/Tiktok广告账户，谷歌/苹果开发者账户，一站式解决您的后顾之忧。如有任何疑问，请点击服务流程或咨询飞机：@nboversea