Adgora 与 Keitaro 集成使用指南

如何将 Adgora 与 Keitaro 一起使用

如果你的目标是把 Adgora 流量导入 Keitaro，用于跳转、筛选或着陆页控制，那么只要把各自职责理清，这套配置其实很直接；这也是很多人会搜索 “Adgora 与 Keitaro 怎么用” 的原因。重点不是从头重建追踪，而是决定点击该去哪里、Keitaro 该如何处理它，以及在整个重定向链中哪些数据需要保留下来。

这一点在有多个路径的漏斗里尤其重要。一个 offer 可能需要预落地页，另一个可能适合直达流量，还有一个可能只对某个地区或设备有效。Keitaro 很擅长处理这种分流，而 Adgora 则提供进入的点击流；如果你想看更系统的操作步骤，可以参考“Adgora 接入 Keitaro 教程”来对照自己的流程。如果你想从更宏观的角度了解流量系统，加密广告、变现与 Ad-Tech 指南板块很适合用来对比不同方案。

1. 为这套配置选择正确的集成目标

先从目标入手，而不是工具本身。如果你希望 Adgora 把点击送进 Keitaro，让 Keitaro 把流量路由到某个落地页、对流程做 A/B 测试，或者按规则把流量送到不同 offer，这就是正确的模式；这正是“Keitaro 流量路由配置”的核心思路。如果你要配置 postback，那就是另一回事了。这里应当由 Keitaro 充当流量决策层，而不只是一个被动记录工具。

举个简单的例子。假设 Adgora 正在从一个活动投放访客，而 Keitaro 需要把桌面端用户送到评测页、把移动端用户送到短预落地页。这是路由任务，不是追踪包装任务。区别很实际：前者改变点击去向，后者记录着陆后发生了什么。

保持范围尽量小。一个有 2 个着陆页和 1 个 offer 的漏斗，比一个有 7 条分支规则和 4 个隐藏参数的漏斗更容易排查。后续总可以再扩展。

先决定 Keitaro 负责什么

在这套配置里，Keitaro 通常至少负责以下其中一项：着陆页选择、offer 轮转、地区过滤、设备过滤，或基于来源的分段。Adgora 继续作为流量来源。这样的分工会让逻辑更清晰。

如果你已经在多个垂直领域投放，这种思路也会体现在诸如 CPC vs CPM vs CPA 之类的指南中。模型很重要，因为路由规则应该与活动类型匹配。CPA 活动通常需要比 CPM 活动更严格的预筛选，而如果流程搭建得足够清晰，Keitaro 可以强制执行这种差异。

2. 对齐 Adgora 与 Keitaro 之间的账户职责

应该由一个系统来掌管活动 URL。大多数情况下，这个系统应该是 Keitaro。Adgora 把流量送到 Keitaro 的活动链接，由 Keitaro 决定访客下一步去哪里。如果两个系统都试图控制同一个决策，就会出现重复规则和不一致的报告。

第一次点击的目标地址应使用单一事实来源。Adgora 应接收你打算测试的外部活动 URL。Keitaro 应接收点击并处理逻辑。不要把一套路由规则放在 Adgora 里，再在 Keitaro 里放另一套相互冲突的规则。那样最终得到的流量看起来是有效的，却落到了错误页面。

还有一个实用点：命名要保持一致。如果 Adgora 的活动 A 指向 Keitaro 的流程 A，那就按这个方式命名。若来源标签含糊不清，你会浪费大量时间去猜到底是哪一个活动产生了哪个结果。两个系统，一套命名规范。

避免逻辑重叠

如果 Adgora 已经按来源做了分段，除非你有明确理由，否则不要在 Keitaro 里再做一遍完全相同的拆分。双层分段是有用的，但前提是每一层承担不同工作。比如，Adgora 负责按版位区分流量，而 Keitaro 负责按设备区分，这样就很清晰。

相反，如果两个平台都按地区拆分，并且都指向不同目的地，你可能会制造路由冲突。访客仍然会到达，但路径会更难解释。让一层负责主要决策，另一层负责辅助逻辑。

小漏斗需要更少层级。大漏斗需要纪律。

3. 为 Adgora 流量构建 Keitaro 目标流程

在流量到来之前，先在 Keitaro 里搭好目标流程。这意味着创建活动、选择落地页或多个落地页，并定义点击之后应该发生什么。如果你的漏斗使用预落地页，现在就加上；如果访客应直接进入 offer，就明确写出来。空白活动不是策略。

按路径来思考。Adgora 点击进入，Keitaro 流程检查规则，访客落到页面 1 或页面 2，然后流程要么继续到 offer，要么停止。这个顺序在你发布之前就应该能画在纸上。糟糕的流程图也比糟糕的线上测试强。

对于跨不同变现模式工作的发布者和活动搭建者，Adgora 也有关于漏斗另一侧的内容，例如 面向发布者的加密广告网络。并不是每个活动都需要相同的目标逻辑，Keitaro 应该映射流量结构，而不是和它对着干。

先使用一条清晰的落地路径

从 1 个落地页、1 个 offer 和 1 套规则开始。这样你能先确认 Adgora 的点击是否进入了正确的 Keitaro 活动，再去加分流测试或条件跳转。如果第一条路径就失败了，额外分支只会把问题藏起来。

之后你可以再添加第二个落地页或备用 offer。备用方案在主页面加载缓慢或 offer 暂停时尤其有用。一个干净的兜底方案就能省去一整天排错时间。

落地页应该与流量意图相匹配。如果 Adgora 受众期待的是简短的预售页，就不要立刻把他们送到一个信息密集的表单页。如果活动是直效导向，就把点击路径保持得更短一些。相关性仍然比复杂度更重要。

4. 在重定向链中传递正确的点击标识

只保留你真正需要的标识。如果你的目标是后续分析或优化，那就保留能回答真实问题的参数：哪个来源、哪个版位、哪个设备，或者哪个活动变体表现更好。不要因为某个字段存在就全部保留。多余的负担会拖慢排查速度。

从 Adgora 到 Keitaro，再到最终目的地，点击 URL 结构应该保持一致。这种连续性很重要，因为断开的参数链在浏览器里很难看出来，尤其是重定向速度很快的时候。丢失一个 token，就可能让整个测试失去意义。

实用规则是：除非 Keitaro 需要映射字段，否则端到端保持相同的参数名。如果 Adgora 发送了来源值，就保留这个来源值。如果你中途把它改名了，报告也许仍能加载，但标签的含义可能已经和你理解的不一样了。

检查最少但足够有用的数据

最少但有用的数据通常包括：一个活动标识、一个来源或版位标记，以及在流程中需要时可选的设备或地区字段。这对大多数路由和分析任务来说已经足够。除此之外的字段，都应该证明自己有价值。

再举个例子：如果你在跑多个创意，就保留创意 ID；如果你并不打算比较创意，那就不要加。版位、区域或子来源标签也是同理。每个字段都应当为后续决策提供支持。

在配置过程中，如果团队对同一概念使用不同叫法，Ad Tech 术语表会很有帮助。一个人的 sub ID，可能是另一个人的版位标签。当你要保留重定向链时，这种混淆代价很高。

5. 在 Keitaro 中配置分段和流量控制规则

现在进入有意思的部分：Keitaro 侧路由。这里可以按地区、设备、来源或你真正需要的任何条件来拆分 Adgora 流量。比如，同一个 Adgora 活动如果向 3 个国家发送访客，Keitaro 就可以把每个国家路由到不同的落地页或 offer。这样既能保持活动有序，又不必为每一种变化单独开 Adgora 活动；这也正是很多人理解“Keitaro 流量路由配置”时最先关注的部分。

当变量是落地页本身时，分流测试就很有用。50/50 测试可以看出页面 A 还是页面 B 带来了更好的后续行动。地区规则在合规或语言有差异时很重要。设备规则在移动端用户应看到更短页面时也很关键。基于来源的分段适合某个版位与另一个版位表现不同的情况。

先选一个主要控制维度。如果第一天就加上地区、设备、来源和一天中的时间规则，你可能会把更多时间花在读日志上，而不是管理流量。Keitaro 可以处理分支，但你的团队仍然需要理解这些分支。

让逻辑更易读

易读的逻辑通常遵循一种模式：一个条件，一个动作。如果地区等于 X，就送到落地页 A；如果设备等于 mobile，就送到落地页 B；如果都不满足，就走默认路径。这样在 6 天后重新审计也很容易，而这往往才是大多数人真正再次检查配置的时候。

基于来源的分段在 Adgora 流量已经携带可靠来源标签时效果最好。如果标签缺失或不一致，规则看起来没问题，实际却会失败。不是规则坏了，而是输入有问题。

对于相邻垂直领域的活动，同样的路由纪律也适用于诸如 约会类 offer 或其他高强度效果流量。垂直不同，需求相同：入口干净、路由清晰、目的地可衡量。

6. 验证 Adgora 点击是否到达预期的 Keitaro 路径

验证应在放量之前完成。先测试一次点击，再测试第二次；如果规则依赖设备类型，再换一个设备测试同样的点击。检查点击是否进入了预期的 Keitaro 活动、是否打开了正确的落地页，以及参数是否仍按预期显示。一次干净的测试可以省掉半天时间。

使用检查清单，不要靠记忆。确认 Adgora 中的活动 URL 指向正确的 Keitaro 入口链接。确认 Keitaro 展示的落地页就是你选定的那一页。确认保留的点击标识仍与原始值一致。如果你在测试分流，就重复点击足够多次，看看轮转是否按预期工作。

浏览器差异也会有影响。在一个浏览器中测试的点击，可能会以不同方式存储 cookie。移动端测试也可能触发与桌面端不同的分支。这就是为什么当流程使用设备逻辑时，测试集至少应包含 2 种环境。

先看什么

先看入口 URL，然后检查第一次重定向，再检查目标页面。如果第一次重定向就不对，先停在这里。不要在确认点击是否沿着正确的 Keitaro 路径走之前，就急着追最终页面。

还要检查时间。一个页面加载很慢时，看起来像路由失败，但其实只是加载晚了。如果页面打开要 8 秒，人们常会以为点击根本没成功。其实成功了，只是感觉像坏了一样。

7. 排查落地页、路由或参数捕获不匹配的问题

当 Adgora 流量已经到达 Keitaro，但路径错误时，先从最简单的不匹配项开始：活动 URL。错一个字符，就可能把流量送进错误流程。接着检查 Keitaro 中的规则顺序，是否把一个大范围条件放在了更细条件的上方。大范围规则会先捕获流量，并覆盖你原本期望的分支。

如果落地页不对，就把点击条件和实际测试点击进行对比。地区不匹配通常来自 IP 或 VPN 差异。设备不匹配通常来自在错误设备上测试。来源不匹配通常来自未设置或被重命名的参数。症状是一样的，但原因不是。

如果参数丢失，就按重定向链逐跳检查。Adgora 和 Keitaro 之间的某一步，可能把某个值丢掉了、改名了，或以下一步不接受的方式编码了。这也是“Adgora 接入 Keitaro 教程”真正落地的地方：配置是否成功，取决于每一跳中点击能否干净地存活下来。

在最窄的地方修复问题

不要为了一个错误规则就把整个流程推倒重来。如果问题是来源标签缺失，就修标签；如果问题是规则顺序，就调整规则顺序；如果问题是落地页不对，就更新目标并再次测试。定点修复能节省时间，也能减少损失。

如果同一套配置在一个浏览器里正常、在另一个浏览器里不正常，就记下浏览器名称和版本；如果在一个地区正常、在另一个地区不正常，就记下所用的 IP 段或 VPN。具体记录胜过空泛的挫败感。

修复后，重复完全相同的点击路径。不要只是“差不多”测一下。使用相同的活动、相同的 URL、相同的设备和相同的流量来源标签。如果这 4 个变量都一致，结果才真正有意义。

这正是 Adgora 和 Keitaro 协作的真正价值：Adgora 提供流量，而 Keitaro 让你有足够的控制力，一次只用一条清晰规则去塑造后续发生的事情。