如何将Keitaro流量源回调连接到Adgora

开始之前的前提条件

在尝试将 Keitaro 流量源的回调连接到 Adgora 之前，请确保两个账户都是活跃的，并且您可以在 Keitaro 中编辑流量源。这听起来很简单，但这是许多设置停滞不前的地方：用户在 Adgora 中拥有管理员访问权限，但在 Keitaro 中只有查看权限，因此回调字段保持锁定。您需要确切的 Adgora 账户来发送事件，并且您需要在 Keitaro 中实际接收点击的流量源条目。

首先检查三件事。第一，Keitaro 流量源必须已经存在。第二，您必须知道哪个优惠或活动将生成转换事件。第三，您需要 Adgora 在其账户设置中期望的标识符。如果缺少其中任何一项，请停止并修复访问权限，然后再粘贴任何 URL。

在实践中，最干净的设置是分别在不同的标签页中打开这两个工具，并并排比较源名称、回调字段和点击标识符字段。小的拼写错误可能会导致大问题。在 Keitaro 中称为“Meta US”的流量源和在 Adgora 中称为“meta_us”的流量源仍然可以工作，但前提是实际参数匹配，而不是您为方便起见使用的标签。

如果您想在发送请求之前对报告术语进行更广泛的复习，广告技术词汇表可以帮助您了解在跟踪屏幕中不断出现的基本词汇。如果您正在构建更完整的跟踪堆栈，检查其余的加密广告、货币化&广告技术指南也是值得的，因为回调设置很少单独存在。

查找 Adgora 回调端点和所需参数

第一个技术步骤是从配置转换的 Adgora 账户区域复制 Adgora 回调端点。不要猜测 URL。不要重用另一个账户的回调。端点路径中的一个字符可能会将有效的转换变成静默失败，而静默失败是最糟糕的，因为它们看起来像是“没有流量”，而不是“设置错误”。

Adgora 通常会期望一个基本端点加上几个标识事件的参数。在流量源回调设置中，这些参数通常包括点击 ID、源标识符和转换参考。Keitaro 必须发送 Adgora 用于将事件连接回正确源行的内容。如果源行错误，转换将落入错误的位置或根本不落入。

准确复制 Adgora 中显示的端点，然后注意 Adgora 列出的请求宏。一些团队会保留一个文本笔记，其中包含端点、HTTP 方法、所需参数名称以及任何可选值，如支付或状态。这个笔记可以节省后续的时间，特别是当第二个流量源需要相同的模式时。

如果您的 Adgora 账户用于加密活动，设置逻辑是相同的，无论您是为发布者工作流运行加密广告网络还是其他内容。回调仍然需要正确的标识符。因为活动与加密相关，所以没有什么神奇的事情发生。

在 Keitaro 中构建回调 URL

在 Keitaro 中打开流量源设置，找到该源的回调或转换回调字段。将 Adgora 端点粘贴到那里，而不是粘贴到活动回调框中。这个区分很重要。源级回调从流量源配置本身发送数据，这是 Adgora 进行基于源的报告所需的；活动级跟踪是不同的层次，如果混合在一起可能会造成混淆。

现在将 Keitaro 令牌映射到 Adgora 参数。例如，如果 Adgora 期望一个点击 ID，Keitaro 必须传递包含该点击值的令牌。如果 Adgora 期望一个源名称或源 ID，Keitaro 应该发送与流量源记录相关的令牌，而不是活动名称。保持映射的字面意义。保持简单。

一个小心的习惯可以节省数小时：在将其保存在 Keitaro 中之前，在一个普通文本编辑器中写下完成的 URL。然后逐个比较每个参数。缺少的和号、复制的空格或用错误的括号包裹的令牌都可能破坏请求。这在 URL 看起来正常时尤其令人恼火。

一些团队在进入更大购买之前，首先用低风险的源进行测试，例如小型测试活动。这是明智的。如果您还在处理小众垂直领域，例如移动应用安装活动或外汇和交易优惠，相同的回调逻辑仍然适用，即使优惠页面看起来完全不同。

正确匹配点击 ID 和源标识符

这是集成通常会中断的部分。Keitaro 可以接收许多 ID，但 Adgora 仅在确切的点击或源标识符以其期望的格式返回时才会识别事件。如果 ID 缺失、被截断或在错误的参数名称下发送，Adgora 将无法将转换与原始点击关联。

从一开始就使用一种命名模式。如果您的源在 Keitaro 中是“fb_us_01”，请在 Adgora 笔记、跟踪表和任何内部文档中保持相同的逻辑。不匹配的名称并不总是会破坏请求，但会破坏人工故障排除。一个源的三个不同标签可能会浪费一个下午。

当 Adgora 参数列表包含点击 ID 字段时，将其映射到存储源点击记录中点击标识符的 Keitaro 令牌。当它包含流量源标识符时，传递源令牌，而不是活动令牌。源标识符和点击标识符不是同一回事，混淆它们可能会使转换看起来有效，但指向错误的源。

对于比较基于 CPA 的流程的团队，跨定价模型的相同原则也很重要。如果您仍在整理报告逻辑，关于CPC 与 CPM 与 CPA的文章是一个有用的补充，因为回调只告诉您发生了什么；它并没有解释您为什么最初选择该模型。

发送测试转换并确认请求

在保存 URL 后运行一次测试转换。一次。不是五次。以受控的方式触发事件，然后检查两个系统。在 Keitaro 中，打开源或活动日志，查找外发请求、HTTP 代码和发送的最终 URL。在 Adgora 中，查找匹配的事件记录和时间戳。这两个时间戳应该接近，即使它们不是完全相同的秒。

如果 Keitaro 显示 200 响应但 Adgora 什么也没有，说明请求到达了某个地方，只是没有到达预期的事件处理程序。如果 Keitaro 显示 4xx 代码，端点、方法或参数名称可能是错误的。如果请求从未出现在日志中，Keitaro 中的令牌放置可能是错误的，或者源回调从未保存。

使用一个唯一的测试点击和日志中的备注。例如，“周二手动测试，14:20。”这给您提供了一条干净的记录，以便稍后搜索。一个混乱的测试，多个点击而没有备注，看起来很繁忙，但很难调试。

短语如何将 Keitaro 流量源回调连接到 Adgora只有在您能够匹配一个源点击、一个外发请求和 Adgora 内的一个事件时才会变得清晰。如果这三者都对齐，设置就是真实的。如果缺少一个，请不要继续。

修复最常见的源回调错误

错误的宏放置是最常见的错误。一个用于活动数据的令牌被粘贴到源字段中，或者一个点击 ID 令牌被放置在应该放置源 ID 的地方。请求仍然会触发，这就是为什么这个错误很容易被忽视。URL 存在，但转换不存在。

URL 编码会导致下一层问题。如果参数包含特殊字符，而值没有按照 Adgora 期望的方式编码，请求可能会带着损坏的部分到达。这通常出现在源名称、自定义备注或重定向值中。加号可能变成空格。斜杠可能会分割字段。微小的字符，巨大的头痛。

不正确的方法设置也会导致失败。如果 Adgora 期望 GET 而 Keitaro 发送 POST，或反之亦然，端点可能会拒绝请求或忽略它。在您更改其他任何内容之前，请检查两个工具中的方法。一次更改三个字段会使您无法知道哪个修复了问题。

重复的参数会造成另一个安静的混乱。同一字段中的两个值可能导致一个系统读取第一个值，而另一个系统读取最后一个值。每个目的保持一个参数。如果您需要测试回退值，请在单独的版本中进行，而不是在实时 URL 中。

有时问题根本不在 URL。Keitaro 中的流量源可能以一种方式命名，而 Adgora 中的源条目期望另一账户或另一个网络 ID。这种不匹配可能会使每个请求看起来“有效”，但落入错误的位置。在重新处理回调本身之前，请检查账户连接。

上线并监控第一个真实事件

测试通过后，切换从测试流量到真实流量，而不更改漏斗的其余部分。这意味着您保持优惠、着陆页和路由逻辑不变，同时源回调继续触发。这里的规则是一次只更改一个。如果您同时更改漏斗和回调，您将不知道哪个部分导致报告下降。

密切关注第一个真实事件。前 10 个转换是最有信息量的，因为它们显示源回调是否在正常流量下继续触发，而不是一次手动点击。检查 Adgora 中的事件记录与 Keitaro 中的源日志。您要寻找一致性，而不仅仅是一个成功的记录。

关注源名称、参数值和时机。如果一个广告组生成转换而另一个不生成，问题可能出在源设置而不是回调本身。干净的实时交接意味着相同的 URL、相同的令牌和相同的标识符模式在流量量变化时继续有效。

如果您的活动组合包括其他垂直领域，报告习惯保持不变。无论您是为约会优惠发送转换、构建加密广告，还是将新源与旧流量进行比较，请在日志和记录一致之前保持对前几个实时事件的审查。然后继续监控源回调，因为第一个静默失败通常在第一个干净的日子之后出现，而不是在期间。