Adgora 与 Binom postback 跟踪指南

先确认你希望 Binom 接收的准确 postback 数据

如果你正在学习如何将 Adgora 与 Binom 配合用于 postback 跟踪，先从数据开始，而不是从 URL 开始。一个清晰的字段清单，胜过三页猜测。先决定工作流程里真正重要的字段：click ID、payout、status、campaign source，以及任何你做报表时需要的合作伙伴标签。

这个清单应该尽量短。五个字段通常就够了。如果你加到十二个，最后往往只会追着空值跑。

当 postback 方案与你每天早上真正查看的报表一致时，Adgora 和 Binom 才会更好地协同工作。对 media buyer 来说，关键数字可能是 payout；对 affiliate manager 来说，关键数字可能是状态变化；对财务核对来说，关键数字可能是 approved 数量。

在你接触任何平台之前，先把字段名写下来。名称必须完全一致。像 “clickid” 和 “click_id” 这样细微的差异，都可能导致匹配失败，最后日志里虽然有 conversion，却没人能归因。这个原则也正是 Adgora Binom postback 跟踪 成功与否的基础。

如果你还运营其他流量类型，可以把这套方案和你关于 加密广告网络评测 或 加密广告网络定向选项指南 的笔记对照一下，这样所有 campaign 都能使用同一种报表语言。团队同时处理 2 个或 20 个 offer 时，一致性能省下很多时间。

将 Adgora 的 conversion 事件映射到 Binom 的 conversion 状态

Binom 需要为每个事件设定清晰规则。conversion 不只是 conversion。它可能是 approved、pending、rejected、duplicated，或者是你们团队用的其他名称；这就是 Binom conversion 状态映射 必须事先定义好的原因。

映射要简单。一个 Adgora 事件应当对应一个 Binom 状态。如果同一个事件可能代表两种意思，报表层很快就会变得混乱。

比如，一个通过初步检查的 lead 可能先变成 pending，验证后再变成 approved。退款或欺诈标记可能会变成 rejected。同一个 token 的重复提交可能会变成 duplicated。这些并不是抽象标签；它们决定的是漏斗到底是干净还是混乱。

有些团队喜欢把 “accepted” 和 “approved” 分开。可以，但只有当 Binom 的报表方式确实是你的 account manager 会检查的那种时，才值得这样区分。如果没人看某个字段，就别围着它做设计。

先想事件流，再想界面。Adgora 发起的 campaign，可能还需要参考 加密 offer 的原生广告 里的说明，如果同一个 offer 也通过原生版位推广。很多时候，状态逻辑就是在那里发生变化的。一个流量来源可能接受软 lead，另一个则不行。

不要在第一天就把所有边缘情况都映射完。先从你真正会用到的 3 到 4 个状态开始。等第一次测试 conversion 证明整条路径可用后，再补上其他内容。

准备 postback 匹配所需的 ID 透传

ID 是锚点。没有它，Binom 就无法有把握地把 click 和 conversion 对上。多数设置里，你会把 click 标识或交易 token 从 Adgora 传到落地页 URL，再把它存到 Binom 以后能读取的位置。

选定一个 ID，然后保护好它。不要在设置中途改名。不要把它拿去当 payout。也不要因为参数看起来空着，就往里面塞额外文字。

如果 Adgora 是通过 URL 参数发送 click ID，那么 Binom 应该在 campaign 记录里保留这个值。如果你的流程里还会使用 advertiser 侧的 transaction token，那就两个都保留。双重标识在链路一侧延迟时特别有用。

很多团队就是在这一步丢失归因的。点击已经落地，用户也完成了转化，但 postback 带来的 token 格式不同，或者少了分隔符。于是日志里看得到活动，却匹配不上。这会让人很难受。

如果你还需要更广泛的设置思路，同样的透传纪律也适用于 面向电商店铺的加密广告 和 电商加密广告网络 相关 campaign。Offer 不同，规则相同：ID 必须完整穿过整条链路。

把这个 ID 存在你之后能检查的位置。Binom 日志、campaign 变量和 conversion 备注都比记忆可靠。记忆会失效，日志不会撒谎。

构建 postback URL 模板，实现单向 conversion 交接

postback URL 只该做一件事：告诉 Binom 发生了 conversion，并传递归因所需的字段。不要多余内容。不要装饰性参数。不要试验性的文本字符串。postback URL 模板 设置 也应始终保持同样的简洁标准。

模板应该围绕你前面定义好的变量来构建。如果流程需要 click ID、status 和 payout，那模板就应该只包含这些值。一个干净的模板更容易测试、更容易阅读，也更容易在某个值缺失时修复。

单向交接也能减少混乱。Adgora 发送 conversion 信号，Binom 接收，Binom 记录结果。就这些。如果你想让一个 URL 同时负责报表、对账和素材轮转，设置就会变得很脆弱。

参数名要完全一致。端点格式也要完全一致。少一个 &、多一个问号，或者转义字符放错位置，都可能在 Binom 看到请求前就把它拦下。浏览器也许仍然会显示感谢页，这会让错误更难发现。

如果你的团队也管理 push 流量，同样的 postback 纪律同样适用于 加密广告网络推送广告 和 网页推送广告的加密广告，因为快速点击常常会掩盖糟糕的跟踪。一次快速点击，就足以暴露一个坏模板。

把模板放在共享笔记或团队文档里。给版本命名。以后如果有人修改，你要知道到底是哪一行变了，为什么变。

为缺失或延迟的 conversion 值添加兜底规则

并不是每次 conversion 都会带着完美数据到达。有些会晚到，有些会来两次，有些会缺少 payout，或者缺少预期的 source 值。你的 Binom 方案必须为这些情况逐一设定规则。

先从缺失值开始。如果 payout 为空，要决定 Binom 应该存 0、占位符，还是 advertiser 的默认值。如果 status 缺失，要决定该事件是否先留在 pending，等第二次调用来修正。这些工作看起来很枯燥，但能省下时间。

当 advertiser 在人工审核后才确认 lead 时，延迟值很常见。此时，如果你的业务流程允许后续更新，Binom 就不应把第一次事件视为最终结果。时间点的重要性往往被低估。

重复数据需要明确后果。有些团队会忽略第二次命中；有些团队会把它标记为 duplicated；还有些团队会保留它用于审计，但从总计里排除。选定一个规则，然后写下来。

兜底规则不是事后修补，而是设置的一部分。没有它，一条不完整的请求就可能扭曲当天数据，还会引发毫无意义的争论：问题到底出在 Adgora、Binom，还是 advertiser 那一边。

如果你的 campaign 组合里也包含 banner 流量，保留同样的兜底思路会很有帮助，就像 加密货币横幅广告指南 里说的那样。Banner 点击可能很嘈杂，你的跟踪不该如此。

用一次测试 conversion 验证 postback 是否触发

运行一次受控 conversion。一次就够。不要五次，也不要一批测试。单次测试能让问题出错时更容易看清原因。

使用一个已知点击、一个已知落地页和一个已知最终事件。然后检查 Binom 是否收到了正确的标识、预期的 status，以及你前面准备好的值映射。如果这三点都正确，就说明整条链路已经有了可运行的雏形。

同时查看两个系统里的日志。Adgora 应该显示发出的事件，Binom 应该显示接收记录。如果事件只出现在一边，另一边没有，你立刻就知道该把注意力放在哪里。

很多人会在这一步忘记核对最终请求体，而只看 URL。请求在地址栏里看起来正确，不代表真的成功，因为参数可能在发送过程中丢失了，或者编码错误。

如果可能，最好用你在生产环境中预期的同一浏览器、同一设备和同一路径来测试。桌面端和移动端的表现可能不同。两次测试通常就足以暴露模式。十次测试反而经常会把问题掩盖掉。

如果你也在对比不同流量来源，这种方法同样适用于像 应用安装 campaign 的加密广告 这样的文章。平台可以变化，但逻辑很简单：一次点击、一个事件、一个已确认记录。

在日志中检查常见的 postback 失败点

日志比工单更能快速说明真相。先看 click token。如果 Adgora 中的 token 与 Binom 中的不一致，postback 可能已经到达，但仍无法绑定到对应点击。

接着检查请求是否被拦截。防火墙、浏览器扩展或服务器规则都可能在请求到达 Binom 前把它拦下。这样一来，在一侧看起来是“已发送”，在另一侧却完全不可见。

参数被覆盖也是常见问题。如果后续重定向替换了原始 ID，Binom 接收到的就不是正确值。这样会生成一条带真实时间戳、却带虚假来源的 conversion 记录。这组合很糟糕。

端点格式比很多人想象得更重要。少一个斜杠、多一个空格、协议写错，调用就会失败。浏览器也许会容忍它，但跟踪服务器通常不会。

按顺序读日志。先看 click，再看 redirect，再看 conversion，最后看 postback。如果你来回跳着看，只会浪费时间。按行查看，问题通常不到 10 分钟就会暴露出来。

当团队在多个渠道使用同一套设置时，日志审查的方式也应该保持一致。无论 campaign 是用于 现代 campaign 的加密广告，还是只是一个简单的测试 offer，这种纪律都很有帮助。流程一致，惊喜就会更少。

为未来流量记录最终可用的 postback 格式

一旦 postback 正常工作，就要把它按当前实际运行的样子完整记录下来。保存 URL 模式、参数名、可接受的状态、兜底规则，以及那次单次 conversion 的测试笔记。全部都要记。

不要指望六周后还能靠记忆。总会有人问，为什么某个 campaign 显示的是 pending 而不是 approved，而唯一有用的答案，就是那份已记录的格式，再加上证明它有效的测试案例。

文档里应该写明当前端点、必需的 ID 字段、状态映射，以及哪些值必须保持为空。如果你在测试过程中改过某一部分，也把旧版本记下来。这样下一个人就不会重复你最初的三个错误。

把这份记录放在 campaign 模板附近，而不是随手丢进某个聊天线程。共享文档、工单备注或团队 wiki 页面都可以。会消失的消息不行。

当下一个 campaign 到来时，团队应该能在几分钟内复制出完全相同的 postback 格式，然后直接跑一次新测试，而不是从头重建整套逻辑。这才是认真跟踪带来的真正回报。