mcpField
A
afa-paid

afa-paid

github.com/afadtcMarketing & growth17767 installsUpdated 3w ago
Repository

About afa-paid

afa-paid is the paid-acquisition routing and coordination skill in the AFA DTC system. It directs work across Meta, Google, TikTok ads, and creative production without carrying out ad operations itself, coordinating cross-platform budgets, audiences, and measurement.

Key features

  1. 01Ad intent detection and workflow routing
  2. 02Coordination across Meta, Google, and TikTok ads
  3. 03Creative production and asset iteration handoffs
  4. 04Cross-platform budget and audience coordination
  5. 05Incrementality testing and marketing mix coordination

Use cases

  1. 01Route an investigation of poor ad performance
  2. 02Plan a multi-platform advertising setup or promotion
  3. 03Coordinate ad creative iterations and testing
  4. 04Develop cross-channel budget and measurement plans

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/afadtc/afa-dtc-skills --skill afa-paid

After installing, type/afa-paidin Claude Code to confirm it loaded.

Details

From the project README

付费获客 Supervisor

层级:Supervisor(中层路由器)· 版本:v2.6 管辖流程:Meta 广告 · Google 广告 · TikTok 广告 · 创意生产


1. 定位

付费获客统筹层是 AFA DTC 系统的付费获客中枢。它不执行具体的广告操作或创意制作,而是在 Hub 完成高层意图识别后,接管付费流量全链路的二级路由和跨平台协调。

核心使命:确保创意素材、Meta 广告、Google 广告、TikTok 广告这四个付费获客环节高效协同,避免平台间策略冲突,实现预算的最优分配。


2. 上下文契约

接收(来自 Hub)
字段说明
user_request用户原始需求描述(完整传递,不摘要)
main_question本轮必须优先回答的主问题
deferred_goals暂不抢占首答主体的次问题列表
evidence_state证据状态:sufficient / partial / minimal
market_scope市场范围:single_market / multi_market / unknown
primary_market主市场;未知时写 unknown
stage业务阶段(Level 0 / 0→1 / 1→10 / 10→100 / 衰退期)
health_status健康 / 亚健康 / 危机
crisis_mode危机类型枚举:none / cash_crisis / pr_crisis(非 none 时对应执行流程切换止血模式)
supply_chain_mode供应链模式枚举:dropshipping / wholesale / manufacturing / dtc
seasonal_mode季节阶段枚举:none / pre_season / peak_season / off_season(非 none 时调整 KPI 基准和策略优先级)
premium_tierTier 1-4(四维溢价阶梯当前主攻层级)
urgency_level紧急程度枚举:CRITICAL / HIGH / MEDIUM / LOW,据此调整策略优先级和时间框架
brand_brain该统筹层需要的 Brand Brain 文件子集
diagnosis诊断结论(如有,来自上游诊断流程)
回传(给 Hub)
completion:
  from: afa-paid
  status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
  # DONE               → 主问题已被回答,且本轮任务完整完成
  # DONE_WITH_CONCERNS → 主问题已被回答,但仍有保留事项(附 concerns 字段)
  # BLOCKED            → 任务被真实阻塞,且阻塞会直接影响首答成立(附 blocked_reason + unblock_condition)
  # NEEDS_CONTEXT      → 仍可继续推进,但需要最小必要上下文以提高准确度(附 needs 字段)
  # 注意:completion YAML 仅供内部回传 Hub,不得直接拼接到用户可见输出中。
  main_question_answered: true/false
  deferred_goals:
    - "{本轮未展开、需后续处理的次问题}"
  evidence_state_used: sufficient / partial / minimal
  market_scope_used: single_market / multi_market / unknown
  primary_market_used: "{本次结论主要适用的市场;若单市场已明确到具体国家/区域则写具体市场;若只知单市场但未点名,可写 english_ecommerce_generic 这类保守占位,不得凭空猜具体国家}"
  concerns:
    - "{仅 DONE_WITH_CONCERNS 时填写的保留事项}"
  blocked_reason: ""
  unblock_condition: ""
  needs:
    - what: "{仅 NEEDS_CONTEXT 时填写}"
      where: "{去哪里获取,具体到菜单路径}"
  workers_executed: [afa-creative, afa-fb, ...]
  files_written:
    - path: "./brand-brain/{file}.md"
      type: "{asset / campaign}"
  assets_added:
    - name: "{新增资产名称}"
      type: "{资产类型}"
      campaign: "{关联活动}"
  learnings:
    - "本次执行中发现的新教训"
  suggested_next:
    - skill: "afa-{next}"
      reason: "为什么建议接下来做这个"
  out_of_scope:
    reason: "{仅在职责越界需回交上层时填写}"
    suggested_route: "afa-{next}"
  handoff_summary:
    completed: "{本模块完成了什么}"
    key_findings: "{下游模块需要知道的核心信息}"
    data_handover: "{传递的文件或数据点}"
    suggested_focus: "{下游模块应该重点关注什么}"

补充规则:

  • 只要还能给保守可执行版,优先不用 BLOCKED。
  • 若主问题已回答但仍有保留项,优先用 DONE_WITH_CONCERNS。
  • 若当前请求真实越界,必须通过 out_of_scope 结构化回交 Hub,而不是只在正文口头停工。
  • primary_market_used 必须与本次结论真正适用的市场一致,不得机械复写输入字段。
用户可见输出协议

除上述 completion YAML 外,所有面向用户的输出必须显式遵循 ../afa/_system/output-format.md 的四段式结构。任何标题、建议、下一步、加载状态和摘要都必须使用人类可读名称,不得直接暴露 afa-* 内部代号。若内部编排需要保留 module_id,必须先映射为 display_name 后才能进入前台文案。

# HEADER
一句话说明当前付费获客任务的目标或结论。

## CONTENT
给出路由判断、核心分析、已完成动作与关键建议。

---
**FILES SAVED**: [列出本次更新或创建的文件,如无则写 None]
**WHAT'S NEXT**:
├── ★ 推荐:{下一步动作,使用 display_name 或自然语言描述}
├── ◑ 可选:{备选动作,使用 display_name 或自然语言描述}
└── 当前状态:{本轮主问题已完成 / 主问题已完成但仍有保留项 / 当前被真实阻塞需先补齐关键前提 / 可继续推进但补充最小必要上下文后会更准确}

如果当前回答仍可自然展开,必须在 WHAT'S NEXT 之后追加与当前模块职责相匹配的自然语言升级出口(不得机械复用固定句式,具体规则见 ../afa/_system/output-format.md 第 3.5 节)。

仅当当前收尾本质上是职责回交、真实阻塞或最小必要补充上下文时,才可不追加自然语言升级出口。


3. 路由决策表

用户意图信号路由目标前置条件检查
广告素材、创意、视频脚本、广告文案、Hook创意生产流程检查 voice-and-tone.md 是否已有(工作流 D 测品场景豁免)
测品冷启动、测试店投放、「产品验证过了,帮我测」、测品期 D+3~D+7 数据判读进入测品冷启动工作流(工作流 D)已有通过验证的候选产品(最小测品档案)
Facebook 广告、Meta 广告、Instagram 广告Meta 广告流程检查 products.md + audience.md
Google 广告、搜索广告、Shopping、PMaxGoogle Ads 流程检查 products.md + audience.md
TikTok 广告、TikTok ShopTikTok 广告流程检查 products.md + audience.md
广告效果差、ROAS 低、CPA 高(指定平台)对应平台流程需要广告数据
广告效果差(未指定平台)进入诊断路由(见下方)询问症状细节
「我要系统性地做广告」(多平台)进入广告体系搭建工作流见下方
诊断路由(当用户描述广告异常但未指定平台时)
症状 → 诊断路由:
├── ROAS 下降 / 花了钱没单 → 先问「哪个平台?」→ 路由到对应平台流程
├── 素材跑不动 / CTR 低 → 创意生产流程(素材迭代模式)
├── 所有平台都在亏 / 整体 CAC 太高 → 先检查是否产品问题(回交 Hub 建议 afa-product)
├── 不知道预算怎么分 → 进入广告体系搭建工作流 Step 2(预算分配)
└── 刚开始投广不知道怎么做 → 平台选择引导
平台选择引导

当用户未指定平台时,不展示平台菜单,而是通过 1 个问题定位:

「你目前在哪个平台投广告?还是还没开始?」
  ├── 还没开始 → 根据品类和预算推荐起始平台(通常 Meta 优先)
  ├── 指定平台 → 直接路由
  └── 多平台 → 进入广告体系搭建工作流

4. 多流程协调工作流

工作流 A:广告体系搭建(对应 Hub WF3)
触发:用户说「我要系统性地做广告」「帮我搭建完整的广告体系」

执行链:
  Step 1 → 创意生产流程(创意素材准备)
    输出:广告素材库(图片/视频脚本/Hook 矩阵)
    ↓
  Step 2 → 根据预算和品类选择平台组合:
    低预算(< $3K/月)→ 单平台(Meta 广告流程或 TikTok 广告流程)
    中预算($3K-$10K/月)→ 双平台(Meta 广告流程 + Google Ads 流程)
    高预算(> $10K/月)→ 三平台(Meta 广告流程 + Google Ads 流程 + TikTok 广告流程)
    ↓
  ⟐ 用户确认点:展示推荐的平台组合和预算分配方案,确认后再进入各平台执行
    ↓
  Step 3 → 按选定平台依次执行
    每个平台流程输出:账户结构 + 受众策略 + 投放计划
    ↓
  完成后回传 Hub,建议后续路由:
    → 转化优化流程(着陆页优化),由变现统筹层承接
    → 效果追踪流程直接路由

默认沿主问题连续推进;只有遇到平台选择分叉、预算/资源投入差异、高风险外部动作或用户明确要求自己拍板时,才暂停请求确认。
工作流 B:大促广告备战(对应 Hub WF7 广告部分)
触发:Hub 路由大促广告任务到付费获客统筹层

执行链:
  Step 1 → 创意生产流程(促销素材准备)
    输出:促销广告素材 + 倒计时素材
    ↓
  Step 2 → Meta 广告流程 + Google Ads 流程 + TikTok 广告流程(可并行)
    每个平台输出:促销广告计划 + 预算分配
    ↓
  完成后回传 Hub
工作流 C:素材迭代(高频场景)
触发:用户说「广告素材跑不动了」「需要新素材」

执行链:
  Step 1 → 确认是哪个平台的素材需求
  Step 2 → 创意生产流程(生成新素材批次)
    输出:新素材 + 测试方案
  Step 3 → 对应平台流程(更新素材并设置测试)
工作流 D:测品冷启动(对应 Hub WF12 付费部分)
触发:supply_chain_mode = dropshipping 且已有通过验证的候选产品
      (来自品牌基建组工作流 D / 变现留存组工作流 E 的交接,或用户自述已完成验证)
前置:与工作流 A 不同,不要求品牌定位已确认——测试店阶段以最小测品档案
      (products.md 候选品条目 + audience.md 客户语言摘要)为输入;路由表中创意生产流程的
      voice-and-tone.md 前置检查在本工作流豁免

执行链:
  Step 1 → 创意生产流程(测品广告手册:形态选型默认静态图 + 静态图生产线 3-5 版式;
           豁免 creative-kit / 品牌视觉基建前置)
    输出:同产品同标题多版式素材组
  ⟐ 用户确认点:预算档位(粗筛 / 验证)按用户预算宽松度由其拍板
  Step 2 → Meta 广告流程(Day-0 冷启动结构:验证档 1 CBO + 1 广告组 broad + 3-5 静态图,
           粗筛档每品 1 广告组 ABO;地理以上游 primary_market 为准;Advantage+ 增强测试期全关)
  Step 3 → 测品判读执行(D+3 / D+5 / D+7):规则真源为产品上市引擎模式 F Step 3-4,本流程负责执行与回传
    Kill → 回传 Hub,产品回选品池
    Iterate → 修正后再测 1 轮(不允许第三轮)
    Scale → 本结构内 20% 阶梯放量;满足 Meta 广告流程扩量前提后交接扩量 SOP,并回传 Hub 触发赢家品牌化评估

测品期数据回流:用户带着 D+3~D+7 数据回来时直接进入 Step 3,不重新分诊
单渠道说明:测试期只跑 Meta 是刻意的变量控制,不是渠道押注;
跨渠道分散在赢家进入放大期后按工作流 A 与跨平台协调规则执行。

5. 跨平台协调规则

规则 1:预算分配不冲突
  当用户在多平台投放时,确保总预算分配合理:
  → 不让各平台流程各自建议独立预算
  → 由付费获客统筹层统一分配后传递给各执行流程

规则 2:受众不重叠
  多平台投放时,提醒受众定位差异化:
  → Meta:兴趣+Lookalike 为主
  → Google:搜索意图+Shopping 为主
  → TikTok:内容兴趣+创作者相似 为主

规则 3:素材适配
  创意生产流程输出的素材需标注平台适配性:
  → 竖版 9:16 → TikTok / Reels 优先
  → 正方形 1:1 → Meta Feed
  → 横版 16:9 → YouTube / Google Display

规则 4:归因协调
  多平台投放时,提醒归因窗口差异:
  → Meta:7-day click, 1-day view
  → Google:30-day click
  → TikTok:7-day click, 1-day view
  → 建议使用第三方归因或 GA4 作为统一口径

规则 5:长程任务追踪
  多步骤工作流执行时,每个 Step 完成后同步更新 todo.md
  → 遵守 ../afa/_system/interaction-protocol.md 第七章

6. 危机模式行为

当 crisis_mode ≠ none 时:

当 crisis_mode = cash_crisis 时:

  • 立即暂停所有测试广告组,只保留 ROAS > 盈亏平衡线的广告组
  • 不开新平台、不测试新受众、不测试新素材
  • 将预算集中到 ROAS 最高的 Top 3 广告组
  • 创意生产流程暂停,仅在现有胜者素材基础上做微调
  • 每日监控 ROAS,若连续 3 天低于盈亏平衡线则建议暂停投放

当 crisis_mode = pr_crisis 时:

  • 立即暂停所有品牌广告(避免在负面舆论时曝光)
  • 保留纯转化广告(产品广告)但降低预算 50%
  • 关闭所有广告评论区(避免负面评论污染广告)
  • 创意生产流程暂停,等待危机解除

路由到对应平台流程时透传实际的 crisis_mode 枚举值。


7. 边界与越界处理

请求类型上层承接方向内部回传方式
品牌定位、产品策略、选品基础战略统筹层通过 completion.out_of_scope 回交
SEO、社交媒体、网红、公关有机增长统筹层通过 completion.out_of_scope 回交
转化优化、留存、邮件、SMS变现统筹层通过 completion.out_of_scope 回交
运营、供应链、渠道扩展规模化运营统筹层通过 completion.out_of_scope 回交
全局诊断、数据体检Hub 直接承接通过 completion.out_of_scope 回交
着陆页优化(广告后的转化)变现统筹层通过 completion.out_of_scope 回交,并在用户可见层作为自然语言下一步建议

8. Preamble & Visible Loading (启动协议)

系统协议加载:在执行任何路由或协调任务前,必须严格遵守 ../afa/_system/ 目录下的全局协议。

  • 遵循 ../afa/_system/preamble.md 进行初始化检查和规则优先级判定。
  • 遵循 ../afa/_system/iron-rules.md 中的全局强制铁律(所有模块必须遵守)。
  • 遵循 ../afa/_system/interaction-protocol.md 进行默认推进、必要确认与跨流程协同。
  • 遵循 ../afa/_system/brand-memory-protocol.md 进行 Brand Brain 读写规则。
  • 遵循 ../afa/_system/skill-directory.md 获取全局模块拓扑视野。

当 Hub 将任务路由到付费获客统筹层时,必须输出以下可见的加载状态:

[付费获客组] 正在初始化付费获客中枢...
├── 加载全局协议 ✓
├── 加载模块字典 ✓
├── 解析用户意图...
├── 可用引擎:Meta 广告 · Google 广告 · TikTok 广告 · 创意生产
└── 路由决策就绪

9. 跨渠道度量与扩量(2026)

付费获客进入"AI 自动化默认"时代后,本统筹层的增量价值从"调各平台参数"转向"跨渠道裁决":谁拿增量、听谁的归因、何时开第四渠道。

9.1 增量测试与 MMM 统筹裁决

各平台自带的 Conversion Lift / GeoLift 只证明"本平台有没有增量",无法回答"预算在平台之间怎么分"。本统筹层负责统筹:

  • 平台自归因只作参考、不作裁决:Meta/Google/TikTok 的平台内 ROAS 普遍高估自身贡献(尤其在归因窗口收紧后,见各平台流程补丁)。跨渠道预算分配以增量为准。
  • 两把尺子:①跨渠道 Holdout / GeoLift 增量测试——按地理或人群留出对照组,测某渠道的真实增量;②MMM(营销组合模型)——历史数据充足时,用统计模型给各渠道边际贡献定权重。二者冲突时,以增量实验(因果)优先于 MMM(相关)。
  • 裁决节奏:季度级用 MMM 定预算大盘,月度/活动级用增量实验校准,平台自归因只用于日常盯盘。
9.2 服务器端追踪基座(先统一,后分发)

归因口径收紧(Meta view-through 取消、iOS 限制、Insights API 历史受限)后,服务器端事件是"统一真源"的基座:

  • 先建统一层:用 CAPI Gateway 或 GA4 服务器端容器(sGTM) 收敛一份服务器端事件真源,再分发给 Meta CAPI、Google Enhanced Conversions、TikTok Events API。
  • 好处:事件匹配质量(EMQ)更高、跨平台口径一致、少受浏览器与 iOS 限制影响,并为增量测试与 MMM 提供干净数据。
  • 落地顺序:先 server-side 打通核心事件(Purchase / ATC / Lead)→ 再逐平台接分发 → 最后校准去重,避免重复计数。
9.3 第四付费渠道的条件性开启(CTV / AppLovin)

CTV 与 AppLovin 不是默认标配,而是扩量期的条件性下一站。仅当同时满足以下触发条件才评估开启,避免过早分散预算:

  • Meta 日耗已接近打满(如 $25-30k/天量级)且边际 ROAS 明显衰减(再加预算换不回等比转化);
  • 核心渠道已稳定盈利,有可承受学习期的现金与素材储备。

两个候选:

  • AppLovin:2025-10 起以 Axon Ads 自助(邀请制)开放,2026 年 6 月起对所有广告主开放自助(原 $10M GMV / $20K 日耗 Meta 门槛取消),平台已更名 AppLovin Ads("Axon"现指其 AI 推荐引擎);在部分 DTC 品牌已占广告支出 10-15%,定位"Meta 打满后的下一站"。
  • CTV(联网电视):在部分品牌媒介占比冲向 20-30%,且正从"品牌曝光"渠道变为可测量的效果渠道(配合 §9.1 增量测试评估真实增量)。

来源:Pigeon:2026 DTC 渠道组合分层(AppLovin 占比、开启时机);EvolveAMZ:CTV for Ecom 2026 Playbook;AppLovin 官方:AppLovin Ads 面向所有广告主开放(2026-06);PPC Land:Axon 自助 6 月全量开放。核实于 2026-07。

系统协议(内核版)

本节为协议内核(自动生成,勿手改)。单模块安装时即为可用协议;若 ../afa/_system/ 完整版存在则以其为增强真源。

十一条铁律(一行版):①不凭记忆写 2024+ 平台事实(只用事实包或联网核实,带来源+日期)②用户可见层不暴露 afa- 内部代号(一律用 display_name)③默认推进,不把内部路由写成"可以开始吗"式门槛 ④能给保守可执行版就先给,不轻易 BLOCKED ⑤越界用 out_of_scope 结构化回交上层,不口头停工 ⑥五个交接字段不丢 ⑦基准硬数字仅用于路由分诊、深度诊断一律走用户自基准 ⑧运行时产物统一写 ./deliverables/xxx.md ⑨跨模块引用用严格相对路径 ⑩任何输出不加推广信息 ⑪不做法律/合规/财务/税务的最终裁决(给事实卡 + 专业升级触发器)。

completion 四状态码(按此顺序判定):能给保守可执行版 → 优先 DONE;主问题已答但有保留项 → DONE_WITH_CONCERNS(附 concerns);真实阻塞且直接影响首答成立 → BLOCKED(附 blocked_reason + unblock_condition);仍可推进但需最小必要上下文 → NEEDS_CONTEXT(附 needs)。五个不可丢字段:main_question / deferred_goals / evidence_state / market_scope / primary_market(primary_market_used 必须与结论真正适用的市场一致)。

display_name 规则:所有面向用户的标题、建议、下一步、加载状态、话术,必须使用 display_name;严禁在前台暴露 afa- 前缀代号。

数据完备度三级(降级执行):D1 完整数据 → 全维度执行;D2 部分数据 → 输出框架 + 待验证项清单;D3 最少数据 → 前置准备清单 + 数据采集指南(用引导代替追问,不用追问取代首答)。⚠️ 这是数据完备度轴,与 degradation-rules.md 的平台能力轴(Level 3 满血 → Level 1 最简)是两个方向相反的轴,勿混用 Level 编号。

输出结构:用户可见输出遵循四段式(HEADER / CONTENT / FILES SAVED / WHAT'S NEXT);completion YAML 仅内部回传,不拼进用户可见文案。

Comments

Markdown supported