文档使用方式

首次使用建议先按角色阅读；上线实施建议按任务路径阅读；遇到异常时直接进入故障矩阵。每篇文章都尽量包含操作步骤、字段含义、验证方法和常见错误。

遇到问题先从这里进

支持和实施场景里，用户通常先描述现象。下面按最常见问题组织入口，先确认现象，再进入对应工具和文章排查。

按角色进入知识库

如果是第一次使用，建议先按自己的岗位进入。每个角色都给出推荐起点、接着要看的文章和验收结果，避免从完整菜单里慢慢找。

常用搜索与快速定位

这些词覆盖支持、实施和日常运营最常问的问题。点击后会自动把关键词放进顶部搜索框，并展开对应搜索结果。

按阅读场景筛选

根据当前任务缩小菜单范围：基础使用、平台管理、上线实施或开发对接。也可以保持“全部文档”，从左侧完整目录进入。

上线验收模式

实施人员可以直接进入生产上线检查清单，按阶段勾选环境、授权、品牌、追踪域名、Offer、点击、转化、Postback、付款、邮件、通知、备份和安全。

特色能力专题入口

这些能力是 Afftrix 和普通联盟后台拉开差异的地方。下面按专题组织入口，适合产品介绍、团队培训和日常运营快速进入。

按功能场景阅读

安装完成后，日常使用不需要先理解技术细节。可以按“每天要处理什么”来阅读：处理提醒、创建 Offer、接入店铺、检查风险、查看报表和处理付款。

按集合阅读

如果不确定先看哪篇，可以先选择对应集合。每个集合下面都放了最常用的文章入口，适合上线配置、日常运营和支持排查场景使用。

按任务查找

实施过程中经常不是从头阅读，而是遇到一个明确任务。下面按真实业务场景列出建议阅读路径。

核心流程示意

Afftrix 的日常闭环可以理解为：平台创建业务规则，联盟用户推广 Offer，广告主或店铺回传转化，系统根据规则计算佣金并进入财务流程。

重点截图入口

复杂页面建议结合截图阅读。下面列出最常被问到的几个位置，便于快速确认界面和字段所在位置。

推荐阅读顺序

1. 先读上线教程。适合实施人员和首次部署团队，从域名解析开始，最后完成第一条转化。
2. 再读平台设置。完成品牌、注册、邮件、账号团队、员工权限和基础运营选项。
3. 重点读 Offer 创建。Offer 是平台业务核心，追踪 URL、佣金、目标规则和访问权限都要确认。
4. 接着读追踪与回传。理解 CID、S2S、Pixel、Connector 和 API 的关系，避免漏单。
5. 最后读排查与字段字典。运营支持和技术对接时，字段字典与排查中心能快速定位问题。

上线与使用建议

角色阅读路径

培训建议

1. 第一天只讲安装、账号、Offer、Tracking、Postback 和健康检查，不要把所有高级能力一次性塞给新团队。
2. 第二天按岗位拆分：运营练 Offer 和申请审核，技术练 Postback 和 API，财务练付款和对账。
3. 上线后一周重点看 按症状排查，把真实问题沉淀成标准处理流程。

先按岗位分配阅读

第一天只需要跑通六件事

1. 登录后台，确认自己账号能看到应该负责的菜单。
2. 打开 Settings Center，确认平台名称、Logo、支持邮箱、注册规则和通知渠道。
3. 创建或检查一个广告主，记录联系人、官网、结算方式和回传要求。
4. 创建一个验证 Offer，填写落地页、追踪链接、佣金、国家、设备和访问规则。
5. 复制 Affiliate tracking link，完成一次点击，并确认 Clicks 里生成 CID。
6. 发送一次验证 Postback，确认 Conversion、Payout、Postback Logs 和报表都有结果。

平台基础设置快速路径

Offer 创建快速路径

1. 先创建广告主，再创建 Offer，不要用临时广告主长期承载正式业务。
2. 填写 Offer 名称、分类、公开描述、状态、国家、设备和访问规则。
3. 把广告主链接里的点击 ID 宏替换成 Afftrix 的 {cid}，需要传联盟用户 ID 时使用 {affid}。
4. 配置 Revenue、Payout、Caps 和是否需要申请审核。
5. 先保存为 Draft 或 Paused，完成点击、回传、健康检测和权限检查后再切换为 Active。

广告主接入快速路径

遇到问题先收集这些信息

继续阅读

排查决策树

先按用户描述选择一个症状，系统会给出优先检查顺序、需要使用的工具和工单里必须收集的证据。

排查向导怎么用

常见症状处理表

工单必须收集的信息

• 问题发生时间、时区、页面入口和操作账号。
• Offer ID、Affiliate ID、Advertiser ID、CID、order_id、Payment ID 等业务 ID。
• 用户看到的错误截图、完整 URL、HTTP 状态和浏览器环境。
• 相关日志截图：Click、Conversion、Postback、Offer Health、Anti-Spy、Payment 或 Email 记录。
• 修复动作和验证结果，避免只写“已处理”。

推荐权限矩阵

上线前权限检查

• 每个员工都有独立账号，不能共用同一个管理员账号。
• 财务账号不能修改 Offer payout、revenue 或 tracking 规则。
• API Key 管理、Advanced Settings、安全设置只给少数管理员。
• 离职、实施结束或外包完成后，及时禁用账号和密钥。
• 重要操作能在 Audit Logs / Staff Activity 中追溯到具体员工。

接口分层

API 产品导航

开放 API 按调用方拆分权限和数据范围。开发者开始对接前，先确认自己属于哪一类调用方，再读取对应资源。

接口资源目录

权限边界

API Key 不只是一个登录凭据，它还决定调用方能访问哪些资源、哪些字段和哪些操作。

鉴权与安全

• 优先使用 Bearer Token 或 X-Afftrix-Api-Key，不要把 key 写在公开页面里。
• 如果兼容旧系统使用 api_key、key 或 token 参数，生产环境仍建议迁移到 Header。
• API Key 应支持启用、禁用、过期、重新生成和账号状态校验。
• 请求日志不要记录完整密钥，文档截图里也不要展示真实 token。
• 外部系统上线前必须跑验证接口、验证转化和错误码验证。

开发者快速开始

给外部开发者时，建议直接提供下面这组最小资料：Base URL、账号类型、API Key、接口版本、验证账号和一条验证 CID。不要只发密钥。

curl -H "Authorization: Bearer YOUR_API_KEY" \
  https://your-domain.com/api/v1/me

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://your-domain.com/api/v1/offers?page=1&per_page=50"

curl -X POST https://your-domain.com/api/v1/conversions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"cid":"VERIFY_CID","order_id":"VERIFY-1001","amount":19.90,"currency":"USD","status":"approved"}'

响应、分页和限流

API 响应应保持稳定，方便外部系统长期集成。列表接口必须分页，写入接口必须返回可追踪 ID。

{
  "data": {
    "id": 1001,
    "status": "approved"
  },
  "meta": {
    "request_id": "req_20260619_001",
    "api_version": "v1"
  }
}

错误码速查

版本和兼容策略

• 路径中保留版本号，例如 /api/v1，避免未来升级影响已有集成。
• 新增字段默认向后兼容，调用方不应依赖字段顺序。
• 字段废弃时先保留旧字段一段时间，并在响应 meta 或文档中说明替代字段。
• 金额字段统一说明币种、精度和四舍五入规则。
• 时间字段统一使用 ISO 8601 或明确时区，报表按平台时区展示。
• 写入类接口必须支持去重，避免网络重试造成重复转化。

对接检查清单

1. 确认 Base URL、账号类型、API Key、接口版本和调用环境。
2. 先调用 health / me 类接口，确认鉴权成功和账号状态正常。
3. 如果是转化回传，准备验证 CID、唯一 order_id、amount、currency、status 和 timestamp。
4. 调用后检查 response、Postback Logs、Conversions 和 Reports 是否一致。
5. 故障时提供完整请求时间、URL path、HTTP 状态、响应体、CID、order_id 和账号 ID。

外部调用教程入口

给外部开发者、广告主技术团队或联盟用户系统对接时，不要只发一个 API Key。建议按调用方拆分资料、权限和验证步骤。

API 截图和标注标准

API 教程的截图应优先覆盖下面四类。截图里必须隐藏完整 token、邮箱、订单号和客户域名。

• API Key 创建或重新生成页面：标注权限范围、过期时间、启用状态和复制按钮。
• Affiliate / Advertiser API 权限示例：标注只能访问自己数据的范围。
• 401 / 403 / 422 错误响应：标注 Header、必填字段、响应体和修复方式。
• Integration API 回传结果：标注 request time、CID、order_id、Conversion、Postback Logs 和 Reports 验证位置。

常见错误

先按你的任务选择文章

如果你只想完成某个操作，可以直接点击下面的文章入口，不需要从头阅读整套文档。

普通用户怎么读

如果你是平台运营人员，优先看操作步骤和页面入口；如果你是广告主，优先看 Connector 和 S2S Postback；如果你是联盟用户，优先看 Offer 申请、推广链接和付款资料。

特色能力专题入口

先按专题选择能力组，再进入具体教程。每个专题都对应后台入口、适用角色和验收结果。

特色能力展示卡

售前介绍和团队培训时，可以直接按下面的卡片讲：先讲它解决什么问题，再讲谁使用，最后讲怎么验收。

特色能力清单

建议阅读顺序

1. 先看 Offer Health、Offer Spy、Traffic Simulator 和 Postback Debugger，掌握上线前最常用的检测和排查工具。
2. 再看 Smartlink、Offer Source、Offer Supply Map，理解大量 Offer 和上游来源如何规模化管理。
3. 接着看 Profit Guard、Anti-Spy / Fraud、上游链接保护、Offer Access、质量核减和无转化点击自动保护，建立利润、权限和流量质量保护体系。
4. 最后看通知中心、公开 Offer 与 Top Offers、邮件营销、Connector、系统健康、财务对账和后台运营工具，把增长、集成、运维和结算闭环完善。

什么时候使用

• 同一批 Affiliate 流量来自多个国家或设备，需要自动分发到不同 Offer。
• 某些 Offer 会临时暂停、达到 Cap 或健康度下降，需要 fallback 到其他可投放 Offer。
• 上游网络提供大量同类 Offer，运营希望用一个入口统一承接。
• 需要给 Affiliate 一个稳定链接，后台可以不断调整流量池和权重。

配置步骤

1. 进入 Smartlinks 新建智能链接，填写名称、code、状态和说明。
2. 选择可进入流量池的 Offer，确认每个 Offer 已启用、Tracking URL 正常、Targeting 和 Caps 已配置。
3. 设置优先级、权重、国家和设备规则。权重用于同等条件下的分配比例，优先级用于强制排序。
4. 配置 fallback：当没有命中 Offer、Offer 暂停、Cap 达到或被 Anti-Spy 拦截时跳到备用 Offer、Smartlink 或安全页面。
5. 开放给指定 Affiliate 或群组，避免没有权限的用户看到不该推广的 Smartlink。
6. 用 Traffic Simulator 模拟不同国家和设备，确认路由结果符合预期。

验收标准

• Affiliate 后台能看到并复制 Smartlink。
• 不同国家、设备或权限下能路由到预期 Offer。
• 主 Offer 暂停或达到 Cap 时，fallback 生效。
• 点击日志能记录 Smartlink 来源，并能追踪到最终 Offer。

关键字段和常见错误

操作步骤

1. 先准备上游 API 地址、鉴权方式、返回字段样例、币种、国家和分类映射。
2. 进入 Offer Sources 新建来源，保存上游凭证、同步频率、默认广告主、默认分类和默认价格策略。
3. 进入 Offer API Automation 拉取预览数据，检查标题、URL、国家、payout、revenue、status、cap、creative 字段是否能正确映射。
4. 设置字段映射和默认值。上游缺失字段必须有兜底值，不要把空 URL、空币种或未知 payout 直接导入。
5. 先导入少量验证用 Offer，跑 Offer Health、Tracking URL 和 Postback 验证，再开启定时同步。
6. 开启同步后，每天检查导入失败、价格变化、暂停状态和 Profit Guard review queue。

常见风险

导入前验收清单

• 上游返回的 Offer ID、名称、URL、国家、币种、价格、状态都能映射。
• 默认广告主、默认分类、默认 tracking domain 和默认价格策略已经设置。
• 导入预览里没有空 Destination URL、未知币种、负利润和无效国家代码。
• 少量导入后先跑 Offer Health、Offer Spy 和验证点击，再开启定时同步。
• 价格下降、状态变更、上游暂停等风险进入 Profit Guard 或人工复核。

主要看什么

验收标准

• 每个上游来源都有明确的导入数量、失败数量和最近同步时间。
• 重复 Offer 有处理结果：合并、保留、暂停或标记来源。
• 重点国家和分类能看到可用 Offer，不是只有导入记录但不可投放。
• 供应地图中显示异常的 Offer 能跳转到 Offer Health、Offer Source 或 Offer 详情继续处理。

操作步骤

1. 选择模拟来源：Offer 或 Smartlink。
2. 填写 Affiliate、国家、设备、IP / proxy、User-Agent、Referrer 和需要验证的 sub 参数。
3. 如果要验证目标国家，先用代理连通性验证确认出口国家正确。
4. 运行模拟，查看命中的 Offer、跳转 URL、fallback、Anti-Spy 判断和页面预览结果。
5. 如果模拟结果和预期不同，回到 Offer Targeting、Smartlink rule、Anti-Spy rule 或 Tracking Domain 修正。

和 Offer Spy 的区别

Traffic Simulator 主要验证 Afftrix 自己的路由和规则；Offer Spy 主要分析某个外部 URL 或最终落地页的跳转链路。一个看平台规则，一个看链接链路，排查时经常一起使用。

常见模拟场景

什么时候使用

• 点击有了，但转化没有出现。
• 广告主说已经回传，但 Afftrix 没收到或状态不对。
• Affiliate Postback 没发出、失败或参数不完整。
• 需要复现一条验证回传，从 test 到 approved / pending 完整验证。

排查步骤

1. 准备 CID、Offer ID、Affiliate ID、订单号、广告主回传 URL 和问题发生时间。
2. 在 Postback Debugger 输入 CID 或相关 ID，查看点击记录和原始参数。
3. 检查 advertiser postback 是否到达，HTTP 状态、raw params、secret、amount、currency、status 是否正确。
4. 检查 conversion 是否创建或更新，是否被去重、hold、reject 或 fraud rule 影响。
5. 检查 affiliate postback 是否触发，失败时复制错误码和响应内容给 Affiliate。
6. 修复后重新发送验证回传，确认 Click、Conversion、Postback Log 三边能对上。

需要重点看哪些字段

需要保护什么

• 不要在公开文档、公开 Offer 页面或 Affiliate 端暴露广告主原始 click URL。
• Affiliate 应使用 Afftrix tracking link，点击经过平台记录 CID 后再跳转。
• 可疑爬虫、侦察工具、数据中心代理和异常 referrer 应进入 Anti-Spy 观察或拦截。
• 对被拦截或不符合条件的点击，使用 fallback 页面或 Smartlink，不要泄露上游落地页。

配置步骤

1. 进入 Tracking & GeoIP，确认 tracking domain、HTTPS、GeoIP provider 和代理配置可用。
2. 开启或检查 Redirect Protection / tracking 默认保护相关开关，确保 Affiliate 只拿到 Afftrix tracking link。
3. 在 Offer 里只给 Affiliate 展示 tracking link，不展示上游原始 URL。
4. 配置 Anti-Spy shadow mode，先观察可疑 User-Agent、Referrer、数据中心 IP、扫描频率和 Offer sweep 行为。
5. 确认规则稳定后，再对高风险来源启用 block、fallback 或限制访问。
6. 用 Traffic Simulator 和 Offer Spy 验证：正常用户能跳转，可疑环境不会暴露上游链接。

这个功能解决什么问题

访问模式怎么选

设置哪些 Affiliate 可以推广

1. 进入 Offers，打开要设置的 Offer，进入 Traffic & Access 或 Affiliate Access 区域。
2. 先选择 Offer 的可见性：Public、Requested、Private 或只对指定分组开放。
3. 如果是 Private 或专属合作，在 Allowed Affiliates / Allowed Groups 中加入可以推广的 Affiliate 或分组。
4. 如果需要审核申请，确认 Access Requests 会把申请送到运营或 AM 处理。
5. 保存后用一个被允许的 Affiliate 登录，确认能看到 Offer、复制 tracking link，并且点击后 Clicks 里有记录。
6. 再用一个未被允许的 Affiliate 验证：不能看到 Offer、不能复制链接，或点击会进入 fallback / no access 提示。

设置哪些 Affiliate 禁止推广

禁止推广建议按原因分类，不要只写一个模糊的“Block”。后续客服解释、AM 复盘和恢复权限都需要看到原因。

点击控制规则怎么配置

点击控制不是为了惩罚所有低转化流量，而是防止明显没有质量的点击持续消耗预算、污染报表或触发广告主投诉。阈值要按行业、国家、Offer 类型和历史数据调整。

推荐上线策略

1. 第一阶段使用 Shadow Mode，只记录哪些 Affiliate 会命中规则，不自动屏蔽。
2. 每天查看命中列表，排除平台验收、广告主验收、品牌监测工具和样本太小的 Offer。
3. 把明显异常的 Affiliate 设置为 Review 或限制单个 Offer，不要一开始全平台封禁。
4. 确认 3 到 7 天规则稳定后，再启用自动限制、fallback 或自动屏蔽。
5. 所有自动动作都要写入日志：Affiliate、Offer、点击数、转化数、窗口、动作、恢复时间和处理人。

验收标准

• 被允许的 Affiliate 能看到 Offer、复制 tracking link，并产生正常 Click。
• 被禁止的 Affiliate 看不到 Offer，或点击旧链接时被拒绝、fallback 或记录为 no access。
• Access Request 有明确的通过、拒绝、原因和处理人。
• 连续点击无转化规则能在验证阈值下产生提醒，且不会影响平台验收账号。
• 自动屏蔽或限制有恢复方式，AM 能在日志中解释为什么被限制。

什么时候使用质量核减

两种模式怎么选

平台默认规则怎么配置

1. 进入 Settings Center > Tracking & GeoIP，找到转化质量相关设置。
2. 把 Default deduction mode 统一解释为“默认质量核减模式”，正式文案中使用“质量核减模式”。
3. 如果选择 Quality rules，先设置最小样本量，例如同一 Affiliate + Offer 当天达到 30 个转化后才开始评估。
4. 设置每日最大核减比例，例如 10%，避免规则误判时影响过大。
5. 设置短点击秒数、重复 IP 阈值、重复 subid 阈值。阈值越低越严格，建议先保守。
6. 保存后跑一条验证转化，确认正常转化不会被标记为质量核减。

Offer 和 Affiliate 级别怎么处理

验收标准

• 正常验证转化不会被错误标记为质量核减。
• 命中规则的转化有清楚原因，例如 short-click、repeat IP、repeat subid 或固定间隔。
• 被质量核减的转化不会进入可付款金额，也不会误发 Affiliate Postback。
• 验证账号、广告主验收账号或白名单 Affiliate 可以按规则豁免。
• Performance Report、Conversions、Payments 能区分正常转化和质量核减转化。

规则处理什么问题

推荐规则模板

配置步骤

1. 进入后台 Automation & Tools > Automation Rules。
2. 创建规则，触发器选择 Affiliate high clicks, no conversions。
3. 设置观察窗口，例如最近 24 小时或最近 7 天。
4. 设置最低点击量和转化条件，例如点击超过 300 且转化为 0。
5. 第一阶段动作选择 Notify AM、Create task 或 Log only。
6. 排除平台验收 Affiliate、广告主验收账号、刚上线且样本量不足的新 Offer。
7. 观察 3 到 7 天后，再把动作升级为限制单个 Offer access、fallback 或自动屏蔽。
8. 到 Automation Logs 检查命中记录，确认每条都有原因、范围、动作和恢复方式。

避免误伤的检查

• 先确认 Offer 本身没有坏链、GEO 限制或上游落地页问题，必要时先看 Offer Health 和 Offer Spy。
• 新 Offer 低样本期不要把阈值设置太低。
• 不要一开始全平台封禁 Affiliate，优先限制单个 Affiliate + Offer 组合。
• 每个自动动作都要保留恢复条件，例如 24 小时后自动恢复或人工复核后恢复。
• 对优质 Affiliate 或广告主验证账号，使用排除名单或白名单避免误触发。

适合自动化的场景

一条规则由哪些部分组成

配置步骤

1. 进入 Automation & Tools > Automation Rules，点击创建规则。
2. 先写清楚规则目的，例如提醒 AM、创建复核任务、限制某个 Offer access 或暂停风险对象。
3. 选择触发器，并设置业务范围、观察窗口和阈值。
4. 添加排除名单，例如验收账号、新上线 Offer、可信 Affiliate、广告主验证账号。
5. 第一阶段动作选择 Log only 或 Notify，进入 Shadow Mode 观察命中结果。
6. 连续观察一段时间，确认命中对象、条件值和业务预期一致。
7. 再把动作升级为 Create task、Review queue、Limit offer access 或 Pause offer。
8. 启用后定期查看 Automation Logs，确认每条命中都有原因、动作、处理人和恢复方式。

常用规则模板

动作怎么选择

验收标准

• 规则目的、触发器、条件、范围、动作、排除名单和冷却时间都能解释清楚。
• 规则启用前已使用 Log only 或 Shadow Mode 观察命中记录。
• Automation Logs 能看到命中对象、条件值、执行动作和处理结果。
• 被限制或进入复核的对象可以找到恢复方式和处理人。
• 验收账号、广告主验证账号、可信 Affiliate 和新上线 Offer 不会被误伤。

建议配置

1. 上线初期先启用提醒或 review 模式，不要直接自动暂停所有命中 Offer。
2. 设置最低毛利率、负利润、payout 变化、币种不一致和上游价格下降阈值。
3. 对 Offer API Automation 导入的价格变化开启人工复核，避免上游价格异常自动影响投放。
4. 把 Critical 级别提醒发送给运营负责人和财务，普通 Warning 可在 Action Center 里处理。
5. 每次付款前检查 Profit Guard Alerts 和 Review Queue，确认高风险记录已处理。

验收标准

• 故意配置一条 payout 高于 revenue 的验证用 Offer，Profit Guard 能生成提醒。
• 低毛利、负利润、币种不一致有不同等级，不会全部混成同一个错误。
• 处理提醒后有记录：谁处理、怎么处理、是否暂停或恢复。
• 付款前能把 held、blocked、rejected 和高风险转化排除。

上线建议

1. 第一阶段使用 Shadow Mode，只记录风险，不直接拦截真实流量。
2. 观察 3 到 7 天，标记误报和真实风险，调整阈值和 allow list。
3. 把明显异常的 User-Agent、Referrer、数据中心 IP、扫描器和重复点击加入规则。
4. 对高风险 Offer 或 Smartlink 单独设置更严格规则，不要一开始全局强拦截。
5. Fraud Rules 重点关注重复 order_id、异常金额、高退款率、异常 CR 和短时间大量转化。
6. 确认规则稳定后，再启用 fallback、block、hold conversion 或人工审核。

处理误报

• 先看 Anti-Spy Logs 的 risk score breakdown，不要只看最终等级。
• 确认是否为真实客户、代理验证、广告主监测工具或验证账号。
• 确认为误报后，按 IP、Affiliate、Offer、Referrer 或 UA 加入 allow list。
• 调整规则后用 Traffic Simulator 复测，确认正常用户不会再被拦截。

先理解几个入口

通知渠道怎么选

邮箱通知设置

1. 进入 Settings Center → Mail & SMTP。
2. 开启 Email notifications enabled。如果需要找回密码，开启 Password reset emails enabled，并保留合理的重发间隔。
3. 根据业务需要开启 Affiliate 注册确认、Advertiser 注册确认、团队申请提醒和付款邮件。
4. 填写 From email、From name、SMTP host、端口、加密方式、用户名和密码。常见端口是 587 TLS、465 SSL。
5. 填写 Test recipient 后发送验证邮件。验证成功后，再回到 Notification Center 开启 Email channel。
6. 进入 Notification Logs 查看邮件渠道是否为 sent。若显示 failed，优先处理 SMTP 错误、端口拦截、账号授权或队列问题。

Telegram Bot 全局设置

1. 在 Telegram 打开 @BotFather，使用 /newbot 创建机器人，记录 Bot Token 和机器人 username。
2. 进入 Settings Center → Telegram Bot，开启 Telegram channel，填写 Bot Token。Bot Token 必须包含冒号，格式类似 123456789:AA...。
3. 填写机器人 username。username 不需要带 @，也可以点击诊断后由系统自动保存。
4. 设置 Webhook secret。建议使用一段不容易猜到的字符串，Telegram 回调会带这个 secret，Afftrix 会校验它。
5. 保存后点击连接诊断，确认 Bot Token、Telegram API 和 Webhook URL 都可访问。
6. 点击 Sync webhook。系统会把 Telegram webhook 指向 /api/telegram/bot/webhook，并清理旧的 pending updates。
7. 点击 Sync bot commands，把 /start、/today、/tasks、/offer、/postback 等命令同步到 Telegram。
8. 选择菜单语言。推荐使用 Follow linked account language，让机器人菜单跟随绑定账号语言。

Telegram webhook URL:
https://your-domain.com/api/telegram/bot/webhook

Telegram 菜单模块

机器人菜单会按角色、员工权限和数据范围自动过滤。Affiliate 和 Advertiser 只能看到自己可见的数据；非管理员不会看到敏感利润、上游来源、私有 token 或原始密钥。

用户如何绑定 Telegram

1. 管理员、AM 或员工登录后台，进入 Settings Center → My Notifications。
2. 在渠道里勾选 Telegram，并选择自己要接收的事件。
3. 点击生成 Telegram 绑定码。系统会生成类似 /link AFF-XXXX-XXXX 的命令，有效期 15 分钟。
4. 如果已配置机器人 username，可以直接打开页面给出的 t.me 一键链接；也可以在 Telegram 里给机器人发送 /link AFF-XXXX-XXXX。
5. 绑定成功后，返回 My Notifications 发送 Telegram 验证通知。
6. 如果账号离职或不再需要 Telegram 通知，可以在绑定列表里禁用对应 Telegram 账号。

角色事件怎么配置

通知健康检查

• Notification center：总开关是否开启。
• In-app notifications：站内通知是否可以写入。
• Email notifications：邮箱渠道是否开启，SMTP 配置是否完整。
• Telegram notifications：Telegram 是否开启，Bot Token 是否存在，是否已有绑定账号或 fallback Chat ID。
• Webhook notifications：Webhook 是否开启，是否有默认 URL 或用户自己的 URL。
• Queue worker：生产环境建议使用 database queue，并配置 Supervisor 或 Cron queue:work --once。
• Delivery logs：通知日志表是否可用，近期是否有连续失败。

通知日志怎么排查

1. 进入 Notification Logs，按事件、渠道、收件人、状态筛选。
2. 状态为 sent 代表平台已发送；状态为 skipped 通常表示渠道关闭、事件未勾选、收件人没有地址或被去重限制。
3. 状态为 failed 时，先看错误信息，再分别检查 SMTP、Telegram Bot、Webhook URL 或队列任务。
4. 如果 Telegram 菜单能打开但收不到推送，检查该账号是否在 My Notifications 勾选了 Telegram 和对应事件。
5. 如果员工看不到某个菜单，检查 Staff Role 是否有对应权限，例如 Telegram Bot access、Offer 管理、Postback 查看或系统健康查看。

推荐配置顺序

第一次部署或迁移后，建议按下面顺序处理。不要先配置代理再回头修 GeoIP；国家识别不准时，Offer Health、Offer Spy 和 Traffic Simulator 的结果都会跟着不准。

关键配置项

GeoIP 数据库部署

GeoIP 负责把点击 IP 识别为国家、地区和城市，会影响 Offer 国家限制、Traffic Simulator、Offer Health、Offer Spy、代理验证和风控判断。生产环境建议使用 MaxMind GeoLite2 City 本地数据库。

方式 A：MaxMind 自动更新

推荐正式生产环境使用这种方式。系统会用 MaxMind Account ID 和 License Key 下载 GeoLite2-City.mmdb，并通过 scheduler 每日更新。

1. 打开 MaxMind GeoLite2 注册页，注册或登录 MaxMind 账号。
2. 登录后进入账号页面，在 Account information 中复制数字形式的 Account ID。
3. 进入 Manage License Keys，点击生成新的 License Key，名称可以填写 Afftrix GeoIP。
4. License Key 只会完整显示一次。生成后立即复制并保存到安全位置，不要把完整 key 放进截图、公开文档或工单正文。
5. 进入 Afftrix 后台 Settings Center > Tracking & GeoIP，开启 GeoIP enabled。
6. GeoIP provider 选择 MaxMind GeoLite2 local database。
7. GeoIP database path 保持 storage/app/geoip/GeoLite2-City.mmdb。
8. 填写 MaxMind Account ID 和 MaxMind License key，GeoIP update mode 选择 automatic 或 manual。
9. 保持 Verify MaxMind SSL certificate 开启。只有本地开发环境缺少 CA 证书时才临时关闭。
10. 点击 Update database now，完成后用 8.8.8.8 或真实公网 IP 执行 Test IP lookup。

如果自动更新开启，服务器还必须配置 scheduler cron。Afftrix 默认在每日 03:20 触发 geoip:update。服务器防火墙需要允许出站 HTTPS 访问 download.maxmind.com，并允许 MaxMind 下载服务跳转到的文件存储域名。

cd /path/to/afftrix
php -d memory_limit=512M artisan geoip:update --force

方式 B：手动上传 GeoLite2-City.mmdb

如果服务器不能访问 MaxMind，或虚拟主机不能调整内存，可以直接下载 Afftrix 提供的离线数据库，再上传到服务器。

1. 点击 从 Afftrix 下载数据库，浏览器会直接下载 GeoLite2-City.mmdb。
2. 如果改用 MaxMind 官方下载并得到 .tar.gz 压缩包，先在本地解压，找到里面的 GeoLite2-City.mmdb。
3. 不要把压缩包直接上传成数据库文件；最终文件名必须是 GeoLite2-City.mmdb。
4. 把文件上传到服务器项目目录：storage/app/geoip/GeoLite2-City.mmdb。
5. 确认 storage/app/geoip 不在 public 目录下，不要把 GeoIP 数据库放到 public。
6. 设置目录和文件权限，让 PHP 运行用户可读，后续如果要自动更新还需要可写。
7. 回到 Tracking & GeoIP，确认 provider 和 database path 正确，然后执行 Test IP lookup。

PROJECT_ROOT="/replace/with/afftrix-project-root"
WEB_USER="replace_with_web_user"
WEB_GROUP="replace_with_web_group"

cd "$PROJECT_ROOT"
mkdir -p storage/app/geoip
chown -R "$WEB_USER:$WEB_GROUP" storage/app/geoip
chmod 775 storage/app/geoip
chmod 664 storage/app/geoip/GeoLite2-City.mmdb

手动上传后建议马上用 Test IP lookup 测试多个公网 IP。只测服务器本机内网 IP 没有意义，内网地址通常无法识别国家。

住宅代理和截图怎么配置

住宅代理用于模拟目标国家访问上游落地页。它会影响 Offer Health、Offer Spy、Traffic Simulator 和截图预览，尤其是只允许美国、英国、德国等特定国家访问的 Offer。

保存并检测代理

1. 先填写代理类型、主机、端口、账号模板和密码。
2. 在检测框输入目标国家代码，例如 US、GB、DE。
3. 点击 保存并检测代理，等待系统返回出口 IP、国家和检测服务。
4. 检测成功后，用同一个国家跑一次 Traffic Simulator，确认不会进入 fallback。
5. 再用 Offer Spy 或 Offer Health 检查真实上游链接是否能打开。

上线验收清单

• Test IP lookup 能识别 8.8.8.8 和真实访客公网 IP。
• 真实点击记录里的国家不是服务器 IP 国家，也不是 Cloudflare 节点国家。
• 代理检测返回的出口国家与目标国家一致。
• 有 GEO 限制的 Offer 在 Traffic Simulator 里不会误进 fallback。
• Offer Health 能检测上游链接状态，不再因为国家限制误判打不开。
• Offer Spy 使用目标国家后，最终落地页和手动浏览器测试一致。
• 截图预览失败时，先检查代理、浏览器路径、服务器出站访问和上游反自动化规则。

全局设置

单个 Offer 展示怎么配

1. 进入 Offers，打开需要公开展示的 Offer。
2. 确认 Offer 状态为 active，并且 Tracking URL、价格、国家、设备、Caps 已经通过上线检查。
3. 在 Public Showcase 区域开启展示，填写公开标题、简介、分类、徽章和排序。
4. 如果 Offer 不适合公开展示，只保留 Private 或 Requested，不放入公开市场。
5. 保存后打开公开 Offer 市场，确认展示内容、图片、国家、佣金和申请按钮符合预期。

Top Offers 自动推荐

使用权限和安全说明

这些工具会影响导入、付款、审批、审计和系统运行。建议按岗位分配权限，并在操作前确认账号、数据范围和审批要求。

工具清单

推荐学习顺序

1. 先讲主流程：安装、账号、Offer、追踪、回传、付款。
2. 再讲运营增强：通知中心、媒体库、公告、邮件营销、公开 Offer 市场。
3. 然后讲风控和审计：Profit Guard、Anti-Spy、质量核减、敏感审批、审计日志。
4. 最后讲运维工具：Migration Assistant、Background Tasks、Launch Health、Performance Monitor。
5. 每个工具都要对应一个“什么时候用”的场景，避免只看到菜单名但不知道用途。

什么时候使用

迁移前准备

• 完成数据库和上传文件备份，确认可以回滚。
• 确认来源系统、导出格式、字符编码、时区、币种和日期格式。
• 整理字段映射表，尤其是旧 ID、公开 ID、邮箱、状态、价格、国家、回传参数和付款资料。
• 确认去重键，例如 affiliate email、advertiser email、offer source id、conversion transaction id。
• 确认数据归属，例如默认 Manager、默认 Advertiser、默认 Offer 状态和默认付款状态。
• 隐藏文件里的真实密钥、银行卡号、支付账号和敏感个人信息。

操作步骤

1. 进入 Automation & Tools > Migration Assistant。
2. 选择来源类型，例如旧联盟系统导出、CSV、XLS 或指定平台模板。
3. 上传文件，并确认编码、分隔符、时区和币种。
4. 在字段映射页把来源字段对应到 Afftrix 字段，必填字段不能留空。
5. 点击预览，检查即将创建、更新、跳过和错误的记录数量。
6. 先导入小批量记录，确认 Affiliate、Advertiser、Offer、转化和付款数据没有错位。
7. 修正错误行，再继续导入剩余数据。
8. 导入完成后到 Background Tasks、相关列表页和报表里检查数量、状态、金额和日志。

常见字段映射

导入后验收

• 每类对象的导入数量、跳过数量、错误数量和来源文件记录数能对上。
• Affiliate、Advertiser、Offer 的公开 ID、旧 ID 和状态映射正确。
• 核心 Offer 的 Tracking URL、国家、价格、Caps、访问权限和健康度检查正常。
• 历史转化的 revenue、payout、profit、状态和付款资格与来源系统口径一致。
• 付款记录、余额和财务报表没有重复或漏记。
• Background Tasks、Audit Logs 和导入结果页保留完整记录，便于后续追溯。

常见错误和处理

先区分两类邮件

如果是“收不到注册、密码重置、付款或系统提醒”，先看 Mail & SMTP、Notification Center 和 Notification Logs。如果是“批量活动邮件没有发送”，再看 Email Campaign 的分组、模板、队列和发送记录。

操作步骤

1. 先到 Mail & SMTP 配置发件人、SMTP host、端口、加密方式、用户名和密码，并发送验证邮件。
2. 在 Email Templates 维护常用模板，确认变量、退订说明和品牌信息正确。
3. 在 Email Groups 建立收件人分组，例如高质量 Affiliate、新注册广告主、某个 Manager 负责的客户。
4. 创建 Email Campaign，选择模板、分组、发送时间和追踪设置。
5. 发送前预览一封验证邮件，确认链接、变量、落款和退订入口都正确。
6. 发送后查看队列、发送失败、打开和点击记录；失败较多时先检查 SMTP 和退信原因。

常见用途

上线前检查

1. 进入 Launch Health，检查 Redis、队列、scheduler、cron、storage、mail、tracking 和 failed jobs。
2. 所有 blocker 级别问题必须先处理，再开放真实投放。
3. 跑一条验证点击和验证转化，确认 Tracking、Postback、Conversion、Report 都能闭环。
4. 检查 Notification Logs 和 Background Tasks，确认任务没有连续失败。

日常巡检

• 每天检查 failed jobs、邮件失败、Postback 失败和队列堆积。
• 数据量增加后定期查看 Performance Monitor，关注慢页面和慢 SQL。
• 大版本升级后重新跑 Launch Health 和关键业务闭环。
• 性能问题不要只看服务器 CPU，还要看报表范围、索引、队列和缓存命中。

付款前流程

1. 先在 Performance Report 或 Conversions 中确认统计周期和 approved 转化范围。
2. 运行 Balance Check，确认 Affiliate 可付款余额、held、rejected、refunded 和 paid 状态。
3. 检查 Profit Guard、Fraud Logs 和 Review Queue，高风险记录不进入付款。
4. 生成 Payments 或 Batch Send，确认付款方式、币种、最低付款金额和外部交易号字段。
5. 付款后导入银行或支付服务商文件到 Reconciliation，核对系统记录和外部流水。
6. 差异项要形成处理记录：补付、冲减、退款、重新标记 paid 或提交人工审核。

验收标准

• 付款批次金额等于 approved 且 unpaid 的可付款转化金额。
• held、blocked、rejected、refunded 不会被提前付款。
• 外部交易号、付款时间、付款方式和系统状态一致。
• Reconciliation 的差异能定位到具体 Affiliate、Payment、Conversion 或退款记录。

什么时候会看到提醒

日常处理流程

1. 进入后台后先看右下角悬浮按钮是否有数量。
2. 点击悬浮按钮，查看任务列表和每条提醒的来源。
3. 能马上处理的任务，直接点击进入对应页面处理。
4. 确认不需要处理的提醒，可以选择忽略。
5. 如果同类提醒很多，使用一键处理或批量忽略，避免数字长期停留。
6. 处理后刷新页面，确认悬浮数量已经下降。

如何关闭或隐藏

如果客户不想显示右下角悬浮入口，可以在后台设置里关闭。关闭后不代表提醒功能不存在，只是前台不再显示悬浮按钮。

相关文档

怎么使用这个索引

当你不确定某个功能属于哪个后台模块时，先从这里确认入口、关联教程、常见检查点和排查方向。找到对应模块后，再进入详细文章完成配置或验证。

后台模块速览

下面按日常使用频率列出重点模块。先完成核心业务闭环，再进入高级运营、风控、运维和增长工具。

阅读对象和使用场景

后台索引按读者和任务场景拆分。基础使用侧重操作流程和验证方法；平台管理、上线实施、风控财务和开发对接则分别覆盖权限、上线、质量、审计、API 和排查细节。

后台栏目索引

后台通用区域

Operations：Offer 和合作方

Operations 是日常运营最常使用的区域，主要处理 Offer、Affiliate、Advertiser、Manager、员工和 AM 工作台。

Tracking 和 Reports：追踪、转化和报表

Finance：付款、对账和经理佣金

Protection：利润、反作弊和安全流量

Automation：自动化、健康和性能

Growth & Support：营销、素材和工单

Settings Center：系统设置

公开 ID 起始值

公开 ID 用于避免新平台从 1 开始暴露 Affiliate、Advertiser 和 Offer 数量。它是平台用户、Affiliate、广告主、API、追踪链接和报表里看到的业务编号，系统数据库主键仍由系统自己维护。

• 设置入口：Settings Center > Platform / Brand > Public IDs。
• 生成规则：新记录使用“设置起始值”或“当前最大公开 ID + 1”中更大的那个。
• 已有记录不会被重新编号，避免历史 tracking link、postback、报表和客户沟通编号失效。
• 迁移旧系统数据时，已有旧 ID 会保留，后续新数据从当前最大值继续增加。
• 如果发现新建 Offer 没有从设置值开始，通常是因为系统里已经存在更大的公开 Offer ID。

推荐检查顺序

1. 先在 Dashboard 确认顶部搜索、日期范围、通知和 Action Center 是否正常。
2. 再到 Operations 完成 Advertiser、Affiliate、Offer 和员工账号配置。
3. 接着在 Tracking 跑通 Click、CID、Postback 和 Conversion。
4. 然后到 Finance 确认 approved 转化如何进入付款、批量付款和对账。
5. 最后检查 Protection、Automation、Settings，确认日常巡检项和上线排查项都已配置。

核心入口

从空白服务器到第一条转化

如果客户是第一次部署 Afftrix，可以按下面顺序操作。这个顺序覆盖了域名、安装、品牌、用户、Offer、追踪、回传和付款检查。

上线前第一天配置

商用实施阅读顺序

安装向导示例

验证闭环清单

• 管理员可以登录后台。
• 联盟用户可以注册、登录、申请 Offer。
• 广告主可以注册、登录、查看 Offer 和转化。
• Tracking link 可以跳转，并且 Clicks 有记录。
• Postback 或 Connector 可以创建 Conversion。
• revenue、payout、profit 计算正确。
• 付款、邮件和 API Token 流程正常。

正式上线资料清单

• 后台地址、Affiliate 登录地址、Advertiser 登录地址。
• 超级管理员账号，以及建议客户安装后立即修改密码和启用 2FA。
• 主域名、追踪域名、公开 Offer 市场地址、文档地址。
• SMTP 验证结果、队列 worker 状态、Cron 状态。
• 验证用 Advertiser、验证用 Affiliate、验证用 Offer 和验证 tracking link。
• 一条成功 Click、一条成功 Conversion、一条成功 Postback 日志截图或记录。
• 付款设置、最低付款金额、支持的付款方式和财务联系人。

上线目标

完成本教程后，平台应达到以下状态：管理员可以登录后台，品牌和邮件可用，广告主和联盟用户已创建，Offer 已配置，tracking link 可以产生点击，Postback / Pixel / Connector 能创建转化，佣金和付款数据可以核对。

上线前资料清单

第 1 步：域名解析和服务器准备

1. 把主站域名解析到服务器公网 IP，例如 affiliate.example.com。
2. 把追踪域名解析到同一台服务器或专门的追踪入口，例如 link.example.com。
3. Web 站点根目录必须指向程序的 public 目录。
4. 为主站域名和追踪域名配置 HTTPS 证书。
5. 确认 PHP 版本、必装 PHP 扩展、数据库、目录权限、队列和定时任务满足安装要求。必装扩展包括 fileinfo、mbstring、openssl、pdo_mysql、curl、zip、intl、gd、bcmath；redis、exif、opcache 为生产推荐扩展；使用 ionCube 加密包时必须安装 ionCube Loader。

文件权限也要提前确认：项目普通目录建议 755，普通文件建议 644；storage 和 bootstrap/cache 必须允许 PHP 运行用户写入，建议设置为 775。如果权限不正确，安装器、日志、缓存、上传、导出和后台任务都可能失败。不要把整站设置成 777。

如果准备用 Supervisor、宝塔进程守护或 systemd 跑队列，还要确认 PHP CLI 支持 pcntl_signal、pcntl_alarm、pcntl_async_signals。虚拟主机或受限环境无法开启这些函数时，可以使用安装完成页提供的 Cron + queue:work --once 备用队列命令。

第 2 步：运行安装向导

全新安装时，安装器会自动创建或更新 .env：如果项目根目录没有 .env，会从安装包自带的环境模板文件创建；如果 .env 已存在且可写，会更新 APP URL、数据库、缓存、队列和 APP_KEY 等配置。服务器权限不允许写入时，安装器会显示可复制的 .env 内容，部署人员需要手动粘贴到项目根目录的 .env 后再继续。

生产授权需要环境模板文件或 .env 中存在 AFFTRIX_LICENSE_CENTER_URLS。正式安装包默认应包含授权中心地址；如果服务商提供其他授权中心，以服务商提供的 HTTPS 地址为准。

安装完成页会显示后台登录地址、计划任务命令、队列 worker 命令和虚拟主机备用队列命令。真实部署时请优先复制安装完成页自动生成的命令，教程里的命令只说明格式。

第 3 步：首次登录后台

首次登录后，先确认顶部日期范围为当天，左侧菜单可以正常展开，语言显示符合客户配置。后台首页没有数据是正常现象，后续完成点击和转化验证后才会出现指标。

• 管理员账号可以登录后台。
• 左侧菜单、顶部搜索、语言切换和日期筛选可用。
• 后台没有错误弹窗、空白页或源码泄露。

第 4 步：配置品牌、注册和邮件

第 5 步：创建团队、广告主和联盟用户

1. 创建一个 Advertiser，用于绑定首个 Offer 和后续账单。
2. 创建一个 Affiliate，用于验证申请 Offer、复制 tracking link 和查看佣金。
3. 创建必要员工账号，例如运营、财务、客服、技术支持。
4. 给员工分配角色，避免财务人员能改 payout，运营人员能直接批量付款。
5. 确认广告主中心和 Affiliate 用户中心都能正常登录。

第 6 步：创建第一个 Offer

第 7 步：设置追踪和回传

第 8 步：WooCommerce 店铺对接

1. 在后台 Integrations 生成专属 Connector Key 或下载预配置插件。
2. 广告主在 WordPress 后台安装并启用 Afftrix Connector。
3. 插件中保存 Afftrix Site URL 和 Connector Key。
4. 从 Affiliate tracking link 进入店铺，确认插件保存 CID。
5. 创建验证订单，确认订单状态触发回传。
6. 在 Afftrix Conversions 和插件日志中核对 response。

第 9 步：跑通第一条转化

1. 使用验证用 Affiliate 复制 Offer tracking link。
2. 在无痕窗口打开链接，确认跳转到正确落地页。
3. 后台 Clicks 页面确认生成点击和 CID。
4. 广告主网站或插件确认保存 CID。
5. 触发 S2S、Pixel 或 Connector 回传验证转化。
6. 后台 Conversions 确认状态、金额、币种、revenue、payout 和 profit。
7. 如果配置 Affiliate Postback，检查回传日志是否返回 HTTP 200。

第 10 步：报表、风控和付款核对

• Performance Report 能看到 clicks、conversions、revenue、payout、profit。
• Profit Guard 没有负利润或高风险提醒。
• Postback Logs 没有连续失败。
• Affiliate Balance 与 approved conversions 一致。
• 付款方式、最低付款金额、发票信息和付款周期已配置。

第 11 步：正式开放前检查

正式上线资料清单

阅读方式

建议先完成品牌、邮件、追踪域名、广告主、联盟用户和 Offer 的基础配置，再开始正式投放。这样点击、转化、佣金和报表会更容易对齐。

按角色选择页面

不同岗位不需要每天打开所有菜单。可以先按角色进入最相关的页面，再根据异常提示进入其他模块。

常用模块速查

1. Dashboard 与全局入口

2. Offer 运营菜单

Offer Spy 怎么使用

Offer Spy 位于 Offer > Offer Spy。它不是简单的链接检测，而是用来还原一个 Offer 从入口链接到最终落地页之间的完整链路，适合运营、技术支持和 AM 在上线前或排查时使用。

常见使用场景：

• 上游网络给了一个 click URL，需要确认中间跳转是否正常。
• 某个国家打开落地页是 404、白屏、跳错页面或被拒绝访问。
• Affiliate 反馈 tracking link 打不开，需要确认问题发生在 Afftrix、上游 broker 还是最终落地页。
• 竞品或供应商 Offer 经过多个中转域名，需要看最终落地页、跳转次数和耗时。
• Offer Health 显示 Broken，需要进一步查看到底是哪一步 Broken。

操作步骤：

1. 打开后台 Offer > Offer Spy。
2. 在 URL 输入框粘贴要分析的链接，可以是上游网络 click URL、Affiliate tracking link、短链或最终落地页。
3. Max redirects 建议保持 10；如果上游链路很长，可以提高到 15 或 20。
4. Verify SSL certificate 生产环境建议开启。只有本地验证、自签证书或确认是证书问题时才临时关闭。
5. 点击 Analyze Offer。
6. 查看 Offer Summary，确认是否到达 Final Landing URL。
7. 查看 Tracking Detection，逐步核对每一步请求 URL、Host、IP、HTTP 状态。
8. 查看 Redirect Visualization，确认 301/302、Meta refresh、JavaScript redirect 是否符合预期。

Check link availability 怎么使用

Check link availability 位于 Offer 列表的 Actions / 右键菜单，也可以在 Offer 详情页顶部使用。它用于快速检测当前 Offer 的目标链接是否可以打开，并把检测结果写入 Link health。

常见使用场景：

• 新建 Offer 后，正式开放给 Affiliate 前先检测一次。
• 批量导入 Offer 后，勾选多条记录批量检测。
• 上游网络更换 click URL 后，确认新链接是否可访问。
• Affiliate 反馈打不开时，先确认是链接失效、GEO 限制、SSL 问题还是代理问题。
• Offer Health 显示 Broken 或 Geo not verified 时，重新检测并保存最新记录。

结果判断：

如果系统提示未配置代理，可以继续用服务器 IP 做基础检测，但不要把它当作目标国家的真实访问结果。带 GEO 限制、上游风控或国家专属落地页的 Offer，应先配置住宅代理。

创建 Offer 的推荐顺序

1. 先创建或确认 Advertiser。
2. 进入 Offer 列表，点击创建。
3. 填写 Offer Basics：状态、名称、广告主、任务类型、分组和分类。
4. 填写 Tracking：Preview URL、Destination URL、回传方式和参数。
5. 填写 Pricing：Revenue、Payout、币种和佣金规则。
6. 填写 Traffic & Access：国家、设备、Affiliate 可见性和申请规则。
7. 保存草稿或保存上线。
8. 用验证用 Affiliate 链接点击一次，再模拟转化回传。

3. 合作方与团队菜单

4. 追踪、点击与转化菜单

5. 报表、付款与财务菜单

6. 风控、自动化与系统健康

7. 增长、素材与支持菜单

8. 设置中心

自定义后台入口

如果在 Platform / Brand 里修改了后台登录路径，后续登录地址就不一定是 /admin。团队操作手册、员工浏览器书签和后台入口提示都应使用新的入口。

9. 日常验收顺序

10. 常见操作建议

• 新建客户前，先确认客户属于 Affiliate、Advertiser、Manager 还是后台 Employee，不要混用账号类型。
• 新建 Offer 前，先准备广告主、落地页、佣金规则、目标国家、允许设备和验证回传方式。
• 上游广告网络场景，Destination URL 通常填写上游 click URL，并把 Afftrix 的 {cid} 放到上游要求的参数中。
• 自建站、WooCommerce 或 Shopify 场景，Destination URL 通常填写商品页、注册页或落地页，点击参数由 Afftrix 自动追加。
• 付款前先检查 Conversions、Reconciliation 和 Performance Report，确认没有重复转化、退款或负利润异常。
• 员工权限按岗位最小化配置；财务、技术、运营、AM 不建议共用同一个后台账号。

后台入口与自定义路径

管理后台默认路径是 /admin，但客户可以在 Settings Center → Platform / Brand → 管理面板路径 修改。修改后请使用实际后台路径登录，例如 https://your-domain.com/afftrix-secure。

后台看板

Dashboard 用于查看平台经营状态，默认建议显示当天数据，其他时间通过顶部日期筛选查看。

Offer 管理

Offer 是平台最核心的推广对象。创建 Offer 时要确认广告主、落地页、佣金、国家、设备、访问权限和状态。

后台菜单怎么理解

管理员第一次进入后台时，建议先按“配置、用户、Offer、追踪、财务、风控”的顺序理解菜单。不要一开始就直接创建 Offer，否则后面容易出现邮件发不出、付款方式缺失、追踪链接无法闭环的问题。

日常运营模块

第一次创建业务数据

1. 进入 Settings Center，先设置平台名称、Logo、SMTP、默认语言、默认时区和付款币种。
2. 创建 Advertiser，填写公司名、联系人邮箱、状态、账单备注。
3. 创建 Affiliate，填写邮箱、状态、AM、付款方式，确认可以登录用户中心。
4. 创建 Offer，绑定 Advertiser，填写 Destination URL、revenue、payout、国家、设备、访问权限。
5. 如果 Offer 是私有或需要申请，先允许验证用 Affiliate 访问。
6. 复制验证用 Affiliate 的 tracking link，在无痕窗口打开。
7. 检查 Clicks 是否产生 CID，确认跳转后的广告主 URL 带有追踪参数。
8. 用 Postback、Pixel 或 Connector 发送验证转化。
9. 在 Conversions、Reports、Profit Guard、Payments 中检查结果。

管理员每日检查清单

1. 打开 Dashboard，确认今日点击、转化、收入、payout、profit 是否正常。
2. 检查 Action Center 或待处理任务，处理申请、告警和失败回调。
3. 查看 Offer Health，确认核心 Offer 链接没有 broken。
4. 查看 Profit Guard，确认没有负利润或异常 payout。
5. 查看 Postback Logs，处理 HTTP 非 200 或参数错误。
6. 查看 Payments，确认是否有达到付款周期的 Affiliate。

管理员常见误操作

登录和注册

默认入口是 /affiliate/login 和 /affiliate/register。如果平台关闭注册，用户需要联系平台管理员创建账号。

申请和推广 Offer

Affiliate 首次使用步骤

1. 登录 Affiliate Center。
2. 进入 Settings 或 Profile，补全联系人、公司资料和付款方式。
3. 阅读平台条款和需要推广的 Offer terms。
4. 在 Offers 中筛选国家、设备、类型和佣金。
5. 申请 Request required 的 Offer，等待管理员批准。
6. 复制 tracking link，并使用 s1 到 s5 标记渠道。
7. 投放后每天查看 Clicks、Conversions、CR、EPC、Payout。
8. 需要回传给自己的系统时，配置 Affiliate Postback 并验证。

资料和付款方式怎么填写

Affiliate 资料越完整，平台审核和付款越顺。平台管理员也可以在后台代为检查资料是否完整。

Tracking Link 示例

https://your-domain.com/sotl?offer=1001&aff_id=2001&s1=facebook&s2=adset-a

s1 到 s5 用于记录流量来源、广告组、关键词、素材等自定义信息。

投放链接怎么使用

佣金状态

报表怎么看

• Clicks：先看点击是否进入系统，是否有国家、设备、Sub ID。
• Conversions：看转化状态、payout、order_id、goal 和时间。
• Reports：按日期、Offer、Sub ID 分析 CR、EPC、收入和趋势。
• Payments：只看 approved 且达到最低付款金额的佣金是否进入付款。
• Postback Logs：如果 Affiliate 有自己的系统，检查回调是否发送成功。

Affiliate 常见问题

• 看不到某个 Offer：可能是 Offer 为 Private，或需要先申请访问。
• 点击有记录但转化没有记录：广告主可能没有回传，或回传缺少 CID。
• 佣金是 pending：需要等待广告主或平台审核。
• 付款未到账：检查是否达到最低付款金额，以及付款方式是否填写完整。

广告主接入快速路径

广告主不需要理解全部后台功能。对接时先把“落地页、CID、回传、账单”四件事讲清楚，再让广告主进入对应页面查看数据。

1. 收集广告主落地页、测试链接、点击 ID 宏、订单号宏、金额宏和转化状态说明。
2. 在后台创建 Advertiser，并确认广告主是否需要独立登录账号。
3. 创建 Offer，把 Afftrix 的 {cid} 传给广告主链接，让广告主保存这个点击 ID。
4. 把 tracking domain 的 /postback.php 回传地址发给广告主，并按对方平台宏替换参数。
5. 让广告主发送测试回传，在 Advertiser Postback Logs 和 Postback Debugger 里确认 success。
6. 上线后定期核对 Conversions、Billing、Postback Logs 和对账结果。

广告主入口

默认入口是 /advertiser/login 和 /advertiser/register。广告主注册后可能需要平台审核。

广告主能做什么

• 提交和编辑自己的 Offer。
• 查看自己 Offer 的点击、转化和成本。
• 审核转化，导出转化数据。
• 查看 Billing 账单。
• 查看 Postback 指南和日志。
• 创建广告主 API Token。

落地页怎么填写

如果广告主使用自己的商城或官网，Offer 落地页可以直接填写商品页、注册页或首页。

https://shop.example.com/products/a
https://example.com/signup

Afftrix 跳转时会把 cid、aff_id、offer_id 和 Sub ID 带到广告主页面。

广告主中心常用页面

转化回传方式

广告主首次对接步骤

1. 平台管理员先创建 Advertiser 账号，并确认联系人、结算周期和允许的 Offer 类型。
2. 广告主提交 Offer，填写名称、落地页、国家、设备、转化事件和禁止推广规则。
3. 管理员审核 Offer，并设置 revenue、payout、访问权限、caps 和状态。
4. 广告主技术选择回传方式：S2S Postback、Pixel、Integration API 或 WooCommerce Connector。
5. 使用验证用 Affiliate 点击追踪链接，确认广告主页面可以接收并保存 cid。
6. 广告主发送一条验证转化，后台 Conversions 必须看到正确的 offer、affiliate、amount、currency 和 order_id。
7. 管理员检查 Profit Guard，确认 revenue 大于 payout，避免上线后出现负利润。
8. 验证通过后，把 Offer 状态切换为 active，并通知 Affiliate 开始投放。

广告主验收清单

• 广告主账号已审核通过，并且只能看到自己的 Offer 和转化。
• Offer 落地页可以正常打开，目标页面不会丢失 cid。
• 至少完成一条真实或模拟验证转化，并保存回传日志。
• 广告主明确知道转化审核、退款、取消订单和账单周期怎么处理。
• API Token 或 Connector Key 已按广告主隔离，不使用全局密钥。

它解决什么问题

什么时候需要新建

• 首次生产上线前，至少要配置一个可用的默认追踪域名。
• 客户希望推广链接使用自己的品牌域名，例如 go.brand.com、track.brand.com。
• Offer、Smartlink、公开 Offer 市场或特殊广告主需要分开域名。
• 旧域名被拦截、证书异常、DNS 指向错误，或者要逐步替换成新域名。
• 需要临时暂停某个域名，防止继续生成或匹配点击流量。

创建前先准备

后台新建步骤

1. 进入后台，打开 Tracking > Tracking Domains。也可以用顶部搜索输入 Tracking Domains 快速进入。
2. 点击 Create 或 New tracking domain。
3. 在 Tracking domain 填写纯主机名，例如 track.example.com。不要填写 https://，也不要带路径。
4. 选择 Type。如果不确定，先选择用于 click / tracking 的默认类型；后续再按 Smartlink、Postback 或品牌场景拆分。
5. 选择 Status。DNS 和 SSL 未验证前建议保持 paused；确认可用后再切换为 active。
6. 如果这是平台默认使用的域名，打开 Default tracking domain。默认域名会在 Offer 或 Smartlink 没有指定域名时被使用。
7. 证书已经可用后，再打开 SSL enabled。如果证书尚未生效，先不要打开。
8. 保存后回到列表，确认 domain、type、status、default 和 SSL 状态显示正确。
9. 打开详情或列表里的 DNS setup / DNS example，核对系统提示的 A 记录目标 IP 是否和域名服务商里填写的一致。

字段怎么填

上线验证清单

1. 在 DNS 检查工具里确认 track.example.com 的 A 记录已经指向 Afftrix 服务器 IP。
2. 浏览器打开 https://track.example.com，确认证书有效，没有安全警告。
3. 后台 Tracking Domains 列表中，该域名是 active；如果它是默认域名，default 开关也已开启。
4. 进入验证用 Offer 或 Smartlink，复制 Affiliate tracking link，确认链接域名使用了新的追踪域名。
5. 用无痕窗口点击链接，页面能跳到正确落地页，并且浏览器地址栏或落地页能收到 cid。
6. 回到后台 Clicks，确认生成了 Click 记录，并且 offer、affiliate、cid、country、device 有值。
7. 如果后续会回传转化，再用 Postback Debugger 或验证订单验证同一 CID 能生成 Conversion。

常见错误

和其他模块的关系

追踪流程

Tracking Link 类型

Affiliate 一般在用户中心的 Offer 详情页复制 Tracking Link。运营人员需要先确认 Affiliate 已被允许访问该 Offer，否则用户可能看不到链接或无法申请。

https://link.example.com/click?offer_id=1001&aff_id=2001&s1=facebook&s2=campaign-a&s3=creative-01

广告主网站需要保存什么

广告主落地页收到 cid 后，必须在用户注册、下单或支付流程中保存它。保存位置可以是 Cookie、localStorage、Session、订单表或 CRM 字段。

三种回传方式怎么选择

广告主 Postback

https://your-domain.com/postback.php?cid={cid}&amount=99.00&currency=USD&status=approved

最推荐带回 cid。如果没有 CID，可以用 offer_id、affiliate_id、优惠码等辅助归因。

排查转化不到账

1. Affiliate 是否使用 tracking link。
2. Clicks 是否有点击记录。
3. 点击记录是否有 CID。
4. 落地页是否收到 CID。
5. 广告主回传是否带 CID 或有效 Offer/Affiliate。
6. Conversion 是否被风控置为 held、blocked 或 rejected。

上线前追踪验证

1. 用验证用 Affiliate 复制 tracking link。
2. 在无痕窗口打开链接，确认页面跳到正确落地页。
3. 后台 Clicks 检查是否有点击记录。
4. 查看点击详情，确认 offer、affiliate、cid、country、device 都有值。
5. 在广告主网站完成验证注册或订单。
6. 触发 S2S、Pixel 或 Connector 回传。
7. 后台 Conversions 检查状态、金额、payout、revenue。
8. 如果配置 Affiliate Postback，检查 Postback Logs 是否 HTTP 200。

先分清三种 Postback 测试

最标准的一句话流程是：广告主测试时，我们生成 /sotl 测试链接发给广告主，让广告主回传给我们；联盟用户测试时，Affiliate 提供接收地址，我们在 Afftrix 点 Send test 发给他；完整测试时，Affiliate 点击 Offer，广告主回传，Afftrix 入账，再回传给 Affiliate。

广告主回传设置与测试

广告主回传是广告主平台通知 Afftrix：“这个点击产生了转化”。生产环境必须使用追踪域名，不要把后台域名发给广告主。

https://your-tracking-domain.com/postback.php?cid={click_id}&amount={payout}&status=approved&txid={transaction_id}

如果 Offer 开启了回传密钥校验，需要追加密钥参数：

https://your-tracking-domain.com/postback.php?cid={click_id}&amount={payout}&status=approved&txid={transaction_id}&key=POSTBACK_SECRET

广告主给测试推广链接时怎么处理

广告主 AM 可能会给一个他们平台的测试链接：

https://advertiser.example.test/tl?a=1812&o=7912&aff_click_id={AFF_CLICK_ID}&sub_affid={SUB_AFFID}

在 Afftrix 生成测试链接时，把广告主宏替换成 Afftrix 宏：

https://advertiser.example.test/tl?a=1812&o=7912&aff_click_id={cid}&sub_affid={affid}

1. 先把 Afftrix 的 Postback 地址发给广告主 AM。
2. 让广告主 AM 提供他们平台的测试推广链接和宏说明。
3. 在 Afftrix 中用 {cid} 替换广告主点击 ID 宏，用 {affid} 替换联盟用户宏。
4. 生成测试 Offer 链接。Afftrix 会使用隐藏的测试 Affiliate 和测试 Offer 生成正常追踪链接。
5. 把生成的测试链接发给广告主 AM，例如 https://trk.example.com/sotl?a=TEST_AFFILIATE_ID&o=TEST_OFFER_ID。
6. 广告主 AM 点击该链接或放进他们平台测试。
7. 广告主平台拿到 Afftrix 传过去的 CID 后，向 /postback.php 发回传。

测试完成后，在 Afftrix 检查这些位置：

• 后台 -> Advertiser Postback Logs。
• 后台 -> Postback Debugger。
• 后台 -> 广告主详情 / Postback 测试区域。
• 成功时应看到验证点击、验证回传或验证转化，且标记为验证数据。

联盟用户回传设置与 Send test

联盟用户回传是 Afftrix 把转化通知发送给 Affiliate 自己的系统。管理员可以帮联盟用户配置，联盟用户也可以在自己的后台配置。

推荐联盟用户填写 Server Postback：

https://affiliate-system.example.com/postback?cid={cid}&amount={amount}&status={status}&country={country}&affid={affid}&offer={offerid}&txid={txid}&s1={s1}

Global Postback 和 Offer Postback

Send test 操作流程

1. 进入 Affiliate 的 Postbacks & Pixels 页面，新增 Global Postback 或 Offer Postback。
2. 填写接收地址，例如上面的推荐模板。
3. 选择触发状态，常用 Approved。
4. 点击 Send test。
5. 填写验证数据：CID、Amount、Status、Country、Offer ID、Transaction ID。
6. 发送后检查 Affiliate Postback Logs 或 Postback Debugger。

CID: test-cid-xxxx
Amount: 1.00
Status: approved
Country: US
Offer ID: 1001
Transaction ID: test-txid-xxxx

Send test 只会发送样例请求并写入验证记录，不会创建真实转化，也不会修改 Affiliate 余额。

真实完整测试流程

1. 创建真实 Offer，Destination URL 中把广告主点击宏替换成 {cid}。
2. 给 Affiliate 分配 Offer，Affiliate 复制追踪链接。
3. 点击追踪链接，例如 https://trk.example.com/sotl?a=10001&o=30001。
4. Afftrix 生成 CID，并跳转到广告主页面。
5. 广告主平台保存 CID。
6. 广告主转化后回传：https://trk.example.com/postback.php?cid=REAL_CID&amount=10.00&status=approved&txid=order123。
7. Afftrix 创建转化、计算收入和佣金，并执行质量核减与状态规则。
8. 如果没有被质量核减，且 Affiliate 设置了符合触发条件的 Postback，Afftrix 再通知 Affiliate。

最后检查：Clicks、Conversions、Advertiser Postback Logs、Affiliate Postback Logs、Postback Debugger 和 Affiliate Balance。

1. 从验证用 Affiliate 生成真实点击

必须从 Affiliate 的 tracking link 进入落地页。只有这样 Afftrix 才会记录 Click 并生成 CID。

https://link.example.com/click?offer_id=1001&aff_id=2001&s1=postback-verify

1. 打开无痕窗口，访问上面的 tracking link。
2. 确认浏览器跳转到广告主落地页。
3. 检查最终 URL 是否包含 cid。
4. 在后台 Clicks 或实时日志里找到本次点击记录。

2. 确认广告主保存 CID

广告主必须把落地页 URL 上的 cid 保存到订单、用户、Lead 或 Session 中。真实转化发生时，再从订单或用户记录里取出 CID 回传。

3. 做一次接口连通验证

从 Click 日志复制真实 CID，然后请求 Postback URL。接口连通验证建议使用小金额和明显的验证订单号。

curl "https://afftrix.example.com/postback.php?cid=CLICK_ID&amount=100.00&currency=USD&status=approved&order_id=TEST-POSTBACK-10001"

4. 在 Conversions 验证接口验证结果

• Conversion 是否命中刚才的 order_id。
• Affiliate 是否来自刚才点击的 Affiliate。
• Offer 是否是本次验证 Offer。
• Amount、Currency、Status 是否等于回传参数。
• Revenue、Payout、Profit 是否符合 Offer pricing。
• 如果启用 Affiliate Postback，是否发送成功。

5. 做真实业务闭环验证

接口连通验证通过后，还要走真实业务流程。这里以 WooCommerce 订单为例，S2S 注册或普通订单也可以按同样逻辑验证。

1. 清理浏览器 Cookie，打开无痕窗口。
2. 访问验证用 Affiliate 的 tracking link。
3. 确认最终进入广告主商品页，并且地址栏带有 CID。
4. 把商品加入购物车并完成验证付款。
5. 等待订单状态到达插件或广告主配置的触发状态，例如 paid、processing、completed。
6. 检查 Connector Logs、Server Postback Logs 或 Pixel 日志。
7. 进入 Conversions，核对金额、状态和佣金。
8. 把同一个订单状态重复触发一次，确认不会重复记佣金。
9. 做一次退款或取消订单验证，确认系统按规则撤销或调整转化。

6. 生产环境参数模板

正式给广告主技术对接时，建议只提供一条清晰模板。模板里的宏必须换成广告主平台自己的宏，不要把 {cid} 原样发给广告主，除非广告主平台的宏本来就叫 {cid}。

https://your-tracking-domain.com/postback.php?cid={click_id}&amount={payout}&status=approved&txid={transaction_id}&currency={currency}&key=POSTBACK_SECRET

最重要的是 cid。如果广告主没有把点击时收到的 CID 原样回传回来，系统通常会返回 click not found，转化无法正确归因。

7. 常见失败场景

8. 上线验收清单

• 验证用 Affiliate 链接能生成 click 和 CID。
• 广告主页面能保存 CID 到订单或用户记录。
• Postback URL 使用生产域名，不是本地或验证域名。
• 密钥、签名、白名单或 Connector Key 正确。
• 真实订单能创建 conversion。
• 重复订单不会重复记佣金。
• 退款或取消订单能同步。
• Affiliate Postback 如启用，能收到 conversion。
• Conversions、Reports、Payments 三处金额口径一致。

从哪里获取 API 资料

接口约定

认证方式

为了安全，生产环境不建议把 API Key 放在 URL 查询参数里。Connector Key 应该为每个广告主或店铺单独生成，泄露后只禁用该店铺的 key。

响应、分页和错误码

{
  "success": true,
  "data": [],
  "meta": {
    "page": 1,
    "per_page": 50,
    "total": 128
  }
}

Affiliate API

基础路径：/api/affiliate/v1。Affiliate 只能读取和操作自己的数据。

Offer 列表筛选

Offer 列表接口适合 Affiliate 同步可推广项目，也适合第三方工具做 Offer feed。

curl -H "Authorization: Bearer YOUR_AFFILIATE_TOKEN" \
  "https://afftrix.example.com/api/affiliate/v1/offers?status=active&country=US&per_page=50"

Advertiser API

基础路径：/api/advertiser/v1。广告主只能读取自己名下 Offer、转化、报表和 Postback 信息。

curl -H "X-Afftrix-Api-Key: YOUR_ADVERTISER_TOKEN" \
  "https://afftrix.example.com/api/advertiser/v1/conversions?from=2026-06-01&until=2026-06-14"

Integration API

基础路径：/api/integration/v1。用于店铺插件、CRM、支付系统或第三方系统把订单和转化回传到 Afftrix。

{
  "source": "woocommerce",
  "event": "order_completed",
  "dedup_key": "woocommerce:10001:order_completed",
  "order_id": "10001",
  "amount": 128.50,
  "currency": "USD",
  "status": "approved",
  "cid": "CLICK_ID_FROM_LANDING_PAGE",
  "coupon_code": "MIKE10"
}

去重和状态映射

WooCommerce、Shopify 和支付 webhook 可能多次触发，同一个订单可能出现 created、paid、completed、refunded 多个事件。生产环境必须配置去重规则。

开发者验证流程

1. 创建验证用 Affiliate、Advertiser 和 Offer。
2. 复制 Affiliate tracking link，在浏览器打开并确认跳转正常。
3. 在 Clicks 页面确认产生点击和 CID。
4. 让广告主页面或验证工具保存 CID。
5. 调用 Postback 或 Integration API 创建验证转化。
6. 在 Conversions 检查归因、状态、金额、payout、revenue。
7. 如配置 Affiliate Postback，在 Affiliate Postback Logs 检查 HTTP status、response 和发送时间。
8. 验证退款、取消、重复请求和无 CID 场景。

安全和上线建议

• 不同广告主、店铺、插件使用独立 key，不共享全局 key。
• API Key 只在服务端保存，不写入前端页面。
• 日志中隐藏 key、邮箱、手机号、支付账号等敏感字段。
• 生产环境只使用 HTTPS。
• 对高频接口启用频率限制。
• 上线前必须验证 200、401、403、422、409、500 等结果。
• 正式上线时同时提供接口域名、验证 key、验证用 Offer、验证 Postback URL 和排查日志入口。

插件对接流程

标准流程

1. 平台后台创建 Advertiser。
2. 后台创建 Offer，落地页填写广告主 WooCommerce 店铺页面。
3. 后台设置 Offer 佣金规则。
4. 后台生成 WordPress Connector 下载包。
5. 广告主安装插件并验证连接。
6. 用户点击 Affiliate 链接进入店铺。
7. 插件保存 CID、Affiliate、Offer、UTM 等参数。
8. 订单完成后插件回传到 Afftrix。

后台如何生成插件包

1. 进入后台 Settings Center → Integrations。
2. 点击 Generate WordPress Connector。
3. 选择 Advertiser。
4. 选择 Default Offer。
5. 如需要，可选择默认 Affiliate、优惠码映射或商品映射。
6. 下载生成的 zip 包，发送给广告主或商家。

专属插件包会自动写入 Afftrix Site URL、Connector Key、Default Offer ID 和 Default Advertiser ID。这样商家安装后不用手动复制复杂 key。

配置项

商家在 WordPress 里怎么安装

1. 登录 WordPress 后台。
2. 进入 Plugins → Add New → Upload Plugin。
3. 上传 Afftrix Connector zip 包并启用。
4. 进入 Afftrix Connector 设置页。
5. 确认 Afftrix Site URL 和 API Key 已经自动填好。
6. 点击 Save and verify connection。
7. 连接成功后，不要只停在这里，还必须做一笔 WooCommerce 验证订单。

必须验证真实订单

1. 在 Afftrix 创建验证用 Affiliate，并复制该 Offer 的 tracking link。
2. 用无痕窗口打开 tracking link，进入 WooCommerce 商品页。
3. 加入购物车并完成一笔验证订单。
4. 在 WordPress 插件日志中检查是否捕获 cid、order_id、amount、currency。
5. 回到 Afftrix 后台 Conversions，确认生成转化。
6. 检查 payout、revenue、profit 是否正确。
7. 如果订单取消或退款，验证是否能回传 refunded / cancelled。

优惠码归因

优惠码适合电商场景。例如 MIKE10 绑定 Affiliate Mike。用户没有点击联盟链接，但结账用了专属优惠码，也可以归因。

先分清三种码

什么时候必须激活

• 生产环境必须使用 License Key 或 CodeCanyon Purchase Code 激活，否则受保护的后台工具可能无法使用。
• 非生产开发地址可以跳过激活，但仍建议验证一遍授权流程，避免正式上线时卡住。
• 授权中心地址由程序包或环境变量配置，客户一般只需要填写授权凭据，不需要填写 License Center URL。
• 生产环境必须有可用的授权中心端点，并且远程授权中心 URL 必须使用 HTTPS。
• 程序包需要包含 config/afftrix-license-public.pem，或配置 AFFTRIX_LICENSE_PUBLIC_KEY，用于验证签名授权载荷。

客户从哪里拿 Purchase Code

1. 客户登录购买 Afftrix 的 Envato / CodeCanyon 账号。
2. 进入 Downloads / Buyer downloads 页面。
3. 找到 Afftrix 产品。
4. 下载 License Certificate，或点击对应入口查看 Purchase Code。
5. 复制形如 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 的 CodeCanyon Purchase Code。
6. 不要截图发送完整购买码；如果需要支持排查，只提供前后几位并隐藏中间字符。

安装向导里怎么填

1. 完成 Welcome、Environment Check、Configuration、Database 步骤。
2. 进入 Admin / License activation 区块，先创建超级管理员账号。
3. 在激活方式中选择 CodeCanyon Purchase Code。
4. 把客户提供的购买码填入 CodeCanyon purchase code 字段。
5. 确认页面里的 Trusted license endpoints 已显示授权中心地址；如果显示未配置，需要先在服务器环境变量里配置 AFFTRIX_LICENSE_CENTER_URLS。
6. 点击 Install Afftrix。系统会把购买码发送给授权中心，授权中心验证通过后返回本地激活令牌。
7. 安装完成后进入后台，打开 License & Updates 检查 License Status 是否 active / verified。

安装后在后台重新激活

如果安装时跳过了非生产开发地址激活，或后续才提供 Purchase Code，可以在后台补做。

1. 使用超级管理员登录后台。
2. 进入 Settings / License & Updates，或在后台搜索 License & Updates。
3. 在 License & Authorization 区域选择 CodeCanyon Purchase Code。
4. 填写购买码，点击 Activate Installation。
5. 成功后系统会提示此安装已通过 CodeCanyon purchase code 关联。
6. 点击 Verify Connection，确认授权中心能验证当前安装。
7. 检查页面上的 Authorization Checklist：Connect to License Server、Validate Credential、Activate Installation、Verify Entitlement 都应完成。

字段和按钮说明

上线验收清单

• 生产环境 APP URL 已经是最终域名，不是 localhost、临时 IP 或验证域名。
• AFFTRIX_LICENSE_CENTER_URLS 已配置，后台能看到 Trusted license endpoints。
• 远程授权中心 URL 使用 HTTPS，本地开发环境才允许 HTTP。
• 购买码或 License Key 已激活，License Status 显示 active / verified。
• 后台 License & Updates 的 Verify Connection 可以成功。
• 授权码、购买码、License Key 和 Activation Token 没有出现在公开截图、工单正文、聊天记录或文档里。
• 上线记录只写“已完成授权验证”和隐藏中间字符后的码段，不保存完整凭据。

常见问题

安装流程总览

完整部署顺序

正式部署不要直接从浏览器打开 /install 开始。正确顺序应该先把域名、服务器、SSL、数据库和站点目录准备好，再进入安装向导。

1. 确认客户要使用的主域名，例如 aff.example.com。
2. 在 DNS 服务商添加解析记录，并等待解析生效。
3. 准备服务器环境：PHP、数据库、扩展、队列、Cron、Redis 或文件缓存。
4. 在服务器或主机面板中创建站点和空数据库。
5. 上传程序代码，确认 Web 根目录指向程序的 public 目录；如果虚拟主机固定入口为 public_html，使用 public_html 兼容结构。
6. 配置 HTTPS 证书，确认主域名可以通过 HTTPS 打开。
7. 打开 https://your-domain.com/install，按向导完成安装。
8. 安装后配置 SMTP、队列 worker、scheduler cron、品牌 Logo 和验证闭环。

域名和 DNS 解析

域名解析是部署第一步。客户如果尚未准备域名，需要先在域名服务商购买域名，并把 DNS 指向当前服务器。

Cloudflare 和 CDN 注意事项

• 如果使用 Cloudflare，先确认 SSL 模式不要造成循环跳转。生产建议使用 Full 或 Full strict。
• 追踪域名默认不建议开启 CDN / 橙色云。只有服务器已经正确还原真实访客 IP，并且确认 WAF、缓存和挑战规则不会影响点击与回传时，才考虑给追踪域名开启代理。
• 后台、API、Postback、Pixel、Connector 接口不要被缓存。
• 如果 WAF、Bot Fight、JS Challenge 影响 Postback 或 API，可以对 /postback.php、/api/*、/pixel* 设置跳过规则。
• 追踪域名如果出现点击丢失，先临时切换为 DNS only 验证，确认问题是否来自 CDN 规则。
• 不要在 CDN 层强制改写查询参数，cid、aff_id、offer_id、s1 到 s5 都必须保留。