亚马逊广告优化

概述

八头象AI广告优化（btx-ai-ads）

概述

八头象AI广告优化让亚马逊广告投放从"人工盯盘+凭经验调价"升级为"AI全自动托管+数据驱动决策"：

本技能将"提高成单词花费、降低非成单词花费"的广告调优目标，转化为三步优化闭环：

适用于任何已托管店铺/ASIN，按周为节奏执行。详细方法论见 references/tuning-methodology.md，参数模板见 references/strategy-params-template.md，MCP接口缺口分析见 references/mcp-interface-gap-analysis.md。

使用流程（用户必读）

Phase 1 · 注册八头象账号

本技能依赖八头象广告优化平台的 MCP 服务。使用前，用户需前往八头象官网注册账号：

1. 访问八头象官网：https://www.batouxiang.com
2. 注册账号：填写手机号/邮箱 → 设置密码 → 完成注册
3. 登录控制台：进入用户中心/控制台

Phase 2 · 授权亚马逊店铺接口

注册并登录后，需在八头象官网授权亚马逊店铺的 API 接口：

1. 在控制台找到「店铺管理」或「授权管理」
2. 授权 SP-API（亚马逊卖家平台 API）：用于读取产品、库存、订单等数据
3. 授权 Ads-API（亚马逊广告 API）：用于读取广告活动、关键词、搜索词、竞价等数据
4. 授权完成后，店铺信息会出现在控制台中

⚠️ 授权注意：SP-API 和 Ads-API 授权是使用本技能的前提条件。未授权的店铺无法读取广告数据。

Phase 3 · 申请 API Key 并配置 MCP 连接器

完成授权后，在八头象控制台申请 API Key，并在 WorkBuddy 中配置 MCP 连接器：

1. 在八头象控制台获取 API Key（格式为 ck_xxxxxxxxxxxxxxxx）
2. 打开 WorkBuddy，进入连接器管理页面（侧边栏「设置」→「连接器管理」）
3. 点击「添加自定义连接器」或编辑 ~/.workbuddy/mcp.json，添加以下配置：

{
  "mcpServers": {
    "ad-tuning-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.batouxiang.com/mcp",
        "--header",
        "Authorization: Bearer ck_你的APIKey"
      ]
    }
  }
}

1. 将 ck_你的APIKey 替换为你在八头象官网申请的实际 API Key
2. 保存后，在连接器管理页面找到「ad-tuning-mcp」，点击「信任」激活连接
3. 激活后即可使用本技能

💡 域名说明：八头象官网是 www.batouxiang.com，MCP API 服务端是 mcp.batouxiang.com（二者是网站与服务后端的关系，类似于 example.com 官网和 api.example.com 接口）。

连接检查：工具调用前若 ToolSearch 找不到 mcp__ad-tuning-mcp__*，提示用户重启 MCP 连接或检查 API Key 是否正确。重启后重新 ToolSearch 加载 schema。

Phase 4 · 免费使用广告诊断

完成以上配置后，用户可免费使用广告诊断功能：

• Step 1 整体效果对比：AI vs NON_AI 广告数据对比（销售/花费/ACOS/CPC/CVR）
• Step 2 分层下钻分析：浪费词/ASIN排名、优质词/ASIN排序、AUTO匹配模式拆分
• 诊断报告输出：自动生成广告浪费分析报告、优质词排名报告

✅ 广告诊断是免费功能，授权 SP-API + Ads-API 后即可使用，无需激活店铺站点。

Phase 5 · 激活店铺站点 → 使用 AI 广告调优

如需使用 AI 广告调优功能（Step 3 调价策略验证 + 参数调优落地），需在八头象官网激活店铺站点：

1. 在八头象官网控制台找到「店铺激活」或「站点管理」
2. 选择要激活的店铺和站点（如 US/DE/JP 等）
3. 完成激活操作（可能涉及订阅/付费）
4. 激活后，本技能可调用以下调优功能：
   • preview_strategy_action — dry-run 预览策略调价动作
   • update_strategy_config — 落地策略参数修改
   • get_strategy_execution_logs — 回看执行记录与 skipped 原因
   • get_bid_adjustment_details — 逐词/逐ASIN调价明细

🔑 AI 调优是付费功能：需在八头象官网激活店铺站点后才能使用。未激活时，Step 3 的调价策略验证和参数调优落地功能将无法操作（preview/update 等接口会返回权限错误）。

功能权限对照表

触发场景

• 用户要求优化某店铺某ASIN的广告策略执行效果
• 用户要求提高成单词花费、降低非成单词花费
• 用户要求诊断广告策略为何全 SKIPPED 或执行偏差
• 用户要求按周分析广告花费结构（成单词/非成单词、成单ASIN/非成单ASIN）
• 用户要求对比 AI广告 vs 非AI广告的整体效果
• 用户要求分析浪费广告费的关键词/ASIN并排名
• 用户要求验证调价行为是否符合流量最大化原则
• 用户要求封装或执行广告策略自动调优
• 用户要求做广告诊断分析（免费功能）

依赖工具（ad-tuning-mcp）

已有接口（含2026-07-22上线的新接口）

接口缺口状态（2026-07-22 全部已补齐）

6个缺口已于2026-07-22全部上线并通过实测验证。三步闭环完整可用。

三步优化工作流

Step 1 · 整体效果对比

目标：对比 AI广告活动 vs 非AI广告活动的销售/花费/ACOS，判断AI托管整体效果趋势。

1.1 时间粒度规则

根据 AI 托管时长选择统计粒度：

接口已支持：bucket_size 参数支持 day/3day/week 三种粒度，传入时忽略 group_by_week，从 week_end 倒推按步长切桶，返回 buckets 数组。

1.2 数据采集

1. 检查店铺激活状态：list_authorized_stores() 返回的每店信息中，ai_tuning_enabled + enabled_strategy_count 决定 Step 3 是否可用。若 ai_tuning_enabled=true 且 enabled_strategy_count > 0，则该店铺已激活 AI 调优，Step 3 可直接执行；否则需提示用户激活。报告页脚不得硬编码"请激活"提示，必须根据此判断结果动态生成。
2. 取托管范围：get_managed_asins(store_id, country_code) → 拿到 parent_asin 列表 + 每个ASIN的 target_acos / promotion_style / manage_all_campaigns。promotion_style 决定提价幅度（见 references/strategy-params-template.md 风格映射表）。
3. 拉 AI vs NON_AI 分组数据：get_ad_perf_by_ai_group(store_id, country_code, group_by_week=true, week_start, week_end) → 获取两组的 spend/sales/orders/acos/cpc/cvr/clicks/impressions 时间序列。
4. 拉变体级数据：对每个 parent_asin 调 get_ad_perf_by_asin(store_id, country_code, parent_asin, group_by_week=true)，取近4周数据。
5. 拉投放类型拆分：get_ad_perf_by_ai_group(..., include_targeting_breakdown=true) → 获取 KEYWORD / PAT / AUTO 三类投放的分组表现。

1.3 分析逻辑

• 对比 AI 组 vs NON_AI 组的 ACOS 走势：AI 组 ACOS 应逐步下降并向 target_acos 收敛
• 对比两组销售额趋势：AI 组销售应增长或至少不下降
• 识别"剪刀差"现象：AI 组恶化 + NON_AI 组改善 = AI 托管策略可能存在问题
• 投放类型拆分：识别哪类投放（KEYWORD/PAT/AUTO）拖累 AI 组表现
• 输出结论：AI 托管整体效果是否达标，哪些方面需要深入分析

Step 2 · 分层下钻分析

目标：根据 Step 1 的对比结果，对数据表现差的广告活动按类型深入分析，找出浪费广告费的词/ASIN 并排名，同时排序 ACOS 低的优质词/ASIN。

2.1 手动广告 — 关键词表现分析

分析对象：MANUAL 投放类型下的搜索词/关键词

需要找出：

• 浪费广告费的词（高花费、无/低转化）→ 按花费降序排名
• ACOS低的优质词（低ACOS、有成单）→ 按ACOS升序排名

数据采集：

• get_search_term_performance(store_id, country_code, start_date, end_date, campaign_type='MANUAL', ai_group='AI', has_order=false, sort_by='spend', sort_order='desc') → 浪费词排名
• get_search_term_performance(..., has_order=true, sort_by='acos', sort_order='asc') → 优质词排名
• 支持按 campaign_type / ai_group / has_order 灵活筛选，支持 bucket_size 按时间分桶

分析逻辑：

• 筛选 has_order=false 的搜索词，按 spend 降序排列 → 浪费词排名
• 筛选 has_order=true 的搜索词，按 ACOS 升序排列 → 优质词排名
• 重点关注：成单词花费占比 vs 无单词花费占比（目标：成单词占比上升）
• 综合评估：ACOS低 + 花费高 = 最值得加码的对象

2.2 ASIN定投广告 — 目标ASIN表现分析

分析对象：PAT（Product Ads Targeting）投放下的定投目标ASIN

需要找出：

• 浪费广告费的定投ASIN（高花费、无转化）→ 按花费降序排名
• ACOS低的优质定投ASIN → 按ACOS升序排名

数据采集：

• get_pat_target_performance(store_id, country_code, start_date, end_date, ai_group='AI', has_order=false, sort_by='spend', sort_order='desc') → 浪费定投ASIN排名
• get_pat_target_performance(..., has_order=true, sort_by='acos', sort_order='asc') → 优质定投ASIN排名
• get_ad_perf_by_ai_group(..., include_targeting_breakdown=true) → 获取 PAT 整体聚合表现作为补充

分析逻辑：

• 当前可做：判断 PAT 整体是否亏损（如 PAT 花费 > 0 但销售 = 0 → 全部浪费）
• 补齐后可做：逐个定投ASIN排名，精确识别浪费源

2.3 AUTO广告 — 匹配模式表现分析

分析对象：AUTO 广告的4种匹配模式（close_match / loose_match / substitutes / complements）

数据采集：

• get_ad_perf_by_ai_group(..., include_auto_matchtype_breakdown=true) → 获取 close_match / loose_match / substitutes / complements 四种匹配模式各自表现
• 可同时传 include_targeting_breakdown=true 一次获取 KEYWORD/PAT/AUTO + AUTO四匹配模式

分析逻辑：

• 判断 AUTO 整体 ACOS 是否达标
• 识别哪种匹配模式在浪费钱（如 substitutes 可能大量花钱不转化）
• 对比 AI 组 vs NON_AI 组各匹配模式效率

2.4 低ACOS词和ASIN排序统计

目标：对 ACOS 低（性价比高）的关键词和ASIN做好排序统计，作为 Step 3 验证调价的数据基础。

排序逻辑：

• 关键词：从 2.1 的搜索词数据中，筛选 has_order=true，按 ACOS 升序排列
• ASIN：从 2.2 的定投ASIN数据中，筛选 has_order=true，按 ACOS 升序排列
• 综合评估：ACOS低 + 花费高 = 最值得加码的对象（流量最大化目标）

已通过 get_search_term_performance 和 get_pat_target_performance 完整实现。

Step 3 · 调价策略验证 🔑 需激活店铺站点

目标：验证调价行为是否符合"筛选出最佳性价比关键词和ASIN，并将其流量最大化"原则。

⚠️ 权限判断：Step 1.2 已通过 list_authorized_stores 获取了店铺激活状态。若 ai_tuning_enabled=true 且 enabled_strategy_count > 0，说明该店铺已激活，Step 3 可直接执行，不要再次提示用户激活。若未激活，preview_strategy_action、update_strategy_config、get_bid_adjustment_details、get_strategy_execution_logs、get_strategy_configs 接口会返回权限错误，此时才提示用户前往八头象官网激活。

3.1 验证逻辑

验证流程：

1. 取 Step 2 的浪费词/ASIN清单 + 优质词/ASIN清单
2. get_bid_adjustment_details(store_id, country_code, start_date, end_date, target_type='keyword', target_value='<词>') → 查询逐词调价历史，看 adjustment_direction 是否符合预期
3. get_current_bids(store_id, country_code, parent_asin, target_type) → 查询当前竞价，评估是否处于合理区间
4. 对比浪费词（应降）和优质词（应升）的调价方向，判断是否符合流量最大化原则
5. 不符合 → 进入策略参数诊断（3.2）→ 调参（3.3）

接口已支持：get_bid_adjustment_details 提供逐词/逐ASIN的历史调价明细（old_bid→new_bid + direction + strategy_code），get_current_bids 提供当前竞价查询。

数据读取铁律：

get_bid_adjustment_details 返回的是历史流水，不是当前状态！ 它反映"某天从 old_bid 调到 new_bid"这件事，new_bid 只代表那一次调整后的瞬态，之后可能被其他策略继续上调/下调。

• 当前 bid 状态必须以 get_current_bids 为准（实时快照，含 bid_status + last_adjusted_at + last_adjusted_by）
• 判断一个词"现在贵不贵" → 只看 get_current_bids；判断"策略怎么调的" → 才看 get_bid_adjustment_details
• 三方交叉验证：历史调价走势（bid_adjustment_details）+ 实时快照（current_bids）+ 搜索词表现（search_term_performance）必须一起看，任何单一数据源都可能误导

3.2 策略执行诊断

1. 拉全部策略配置：依次对以下 strategy_code 调 get_strategy_configs：focus_increase_impression、increase_impression、increase_impression_auto、control_impression、control_acos、control_budget、precision_boost。每个 code 通常返回多条 config（按 P30/P20/P10 分层 + MANUAL/ASIN/AUTO campaign_type）。
2. 逐条 preview 诊断：对每条 config_id 调 preview_strategy_action，记录 executor_status（SUCCESS/SKIPPED）、total_actions、动作类型（ADJUST_BID/CREATE_CAMPAIGN）、reason_code。统计：探索加价总动作数 vs 成单词加码总动作数 vs 降非成单词价总动作数。三者的比例应与目标一致；若探索>>成单词>控曝光=0，即执行偏差。
3. 对照五类问题诊断清单（见下方），逐项排查配置缺陷，生成诊断报告。

3.3 调参与验证

1. 生成补丁并执行：按诊断结果，对每条 config_id 用 update_strategy_config 传 patch.strategy_params（覆盖式，必须传完整 strategy_params，非merge），附 reason 写审计日志。参数模板见 references/strategy-params-template.md。
2. preview 验证：对改过的关键 config（尤其是原 SKIPPED 的）重跑 preview，确认转为 SUCCESS 且产生动作。若仍 SKIPPED，区分"配置问题"还是"数据无命中"（如 P10 要求>=2单但当前无词达标属数据相关，非配置错误）。

五类问题诊断清单

问题1 · 探索加价过多（与目标倒置）

• 现象：increase_impression / increase_impression_auto 的动作数远大于 focus
• 危害：预算被零单长尾词缓慢抬价消耗
• 处方：bid_max 不应一刀切到 0.15，需按当前竞价水平校准（见下方公式）。核心刹车靠 campaign_acos3d_gte 修复（ACOS 安全阀），bid_max 仅作天花板
  • bid_max 校准公式：bid_max = 当前平均竞价 + balanced风格$0.08 / aggressive$0.13 / conservative$0.03
  • ACOS 安全阀：修复 campaign_acos3d_gte 空区间 bug（gte=0），使策略仅在 campaign 3天 ACOS < lt 值时才触发。高 ACOS 时自动暂停探索，ACOS 回落后自动恢复
  • 实例：竞价$0.27 → bid_max=0.35（允许8次+$0.01探索）；ACOS=52.6%>20% → 策略暂停；ACOS降至<20%后自动恢复探索

问题2 · 成单词加码过弱

• 现象：focus 的 bid_increase_by 仅 0.01，或 P10/P20 被 impressions_check 卡死，或 acos_7d_lt 过严（如 0.05）
• 处方：bid_increase_by 提到 0.08~0.12（按档位）、impressions_check_enabled=false、acos_7d_lt 放宽到 0.20

问题3 · 控曝光全 SKIPPED

• 现象：control_impression 全部 skipped，非成单词价从未被降
• 原因：yesterday_impressions_gt 门槛过高（100~500）、no_order_clicks_30d_gte 过高、planned_7d_acos_gt 过严
• 处方：降门槛（昨日曝光>10~50、零单点击>=5）、放宽 acos_gt（15~22）、加大 bid_reduction_percent（15~25）

问题4 · 空区间 bug（gte == lt）

• 现象：某 config 的 strategy_params 里 campaign_acos3d_gte 与 campaign_acos3d_lt 相等（如均=0.2），构成空区间 [0.2,0.2) 永不触发
• 排查：grep 所有 config 的 *_gte 与对应 *_lt，凡相等即为 bug
• 处方：将 gte 置 0（使区间变为 [0, lt) 有效），或删除该 gte 条件
• 历史出现：increase_impression 的 ASIN 版、increase_impression_auto 均有此 bug
• 关键：若目标是收口探索，修 bug 后必须同步把 bid_max 压到合理水平，否则 bug 修好后 auto 版会恢复给非成单词加价，与目标矛盾

问题5 · 数据口径盲区

• 现象：weekly_snapshot 只覆盖搜索词维度，PAT 商品投放约 43% 预算无搜索词级数据
• 处理：用 get_ad_perf_by_asin 的 asin 维度补充 PAT 成单/非成单判断；缺口3补齐后可直接查询 PAT 定投ASIN级表现

每日单次调价约束（系统硬规则）

核心原则：每个投放目标（关键词/ASIN）每天只允许一次调价。先执行的策略抢锁成功后，该目标即被锁定，后执行的策略遇到已调价目标会 SKIPPED（抢锁失败）。

执行顺序由 execution_time 决定，不由 priority(P10/P20/P30) 决定：

• priority(P10/P20/P30) 仅影响门槛条件宽严（P10最严、P30最宽），不影响执行先后
• execution_time 决定执行先后
• 策略名中的数字(1/2/3)对应P10/P20/P30，不代表执行顺序

策略冲突分析方法：

1. 从 get_strategy_execution_logs(include_skipped=true) 提取目标ASIN的所有执行记录（含skipped）
2. 按 executed_at 排序，建立"时间线"：哪个策略先执行→是否APPLIED→是否锁定→后续策略是否SKIPPED
3. 统计"每日每目标实际调价次数"：applied记录中应无同日二次调价（0条>1次）
4. 判断"谁先抢锁"：execution_time早的策略先执行并锁定，不是priority编号小的
5. 诊断"曝光量不够"的根因：
   • 若加码策略先执行但bid_increase_by过弱（如+€0.01）→ 根因是加码力度不足，不是策略冲突
   • 若控曝光策略先执行抢锁 → 根因是execution_time排序问题，需调整execution_time使加码策略先执行
   • 若加码策略完全不触发（无符合条件的词）→ 根因是门槛条件过严

安全机制

• 调参前必须 preview：preview_strategy_action 是 dry-run，不写DB不调Amazon API，先验证再改。可用 patch 参数模拟改后效果
• update 是覆盖式：patch.strategy_params 会整体替换，必须传完整字段（先 get 拿原值，改目标字段后整体回传），否则丢字段
• 每次修改写 reason：update_strategy_config 的 reason 参数写入审计日志，便于追溯
• 渐进验证：改完每条后立即 preview 该 config，确认 SUCCESS；批量改后抽验原 SKIPPED 的关键 config
• 区分配置问题 vs 数据问题：preview 仍 SKIPPED 时，看是条件配错还是当前无数据命中（后者非配置错误）
• 当前状态 vs 历史流水：结论必须基于实时数据（get_current_bids / 表现数据），历史流水（bid_adjustment_details）只用于解释"发生了什么"，不能用于断言"现在是什么"。给用户操作建议前必须交叉验证当前快照

输出规范

• Step 1 报告：AI vs NON_AI 时间序列对比图 + 趋势分析结论
• Step 2 报告：浪费词/ASIN排名表 + 优质词/ASIN排序表 + 花费结构饼图
• Step 3 报告：调价验证结果 + 策略分组参数级调优清单 + 优先级行动表 + 配置Bug说明
• 执行摘要：改了哪些 config_id、改前改后 diff、preview 验证结果（动作数变化）
• 报告页脚：根据 list_authorized_stores 的 ai_tuning_enabled + enabled_strategy_count 动态生成。已激活 → "Step 3 可用"；未激活 → "请在八头象官网激活店铺站点"。禁止硬编码激活提示。
• 工作日志：追加到 .workbuddy/memory/YYYY-MM-DD.md

周期

建议每周一次，与 weekly_snapshot 节奏对齐。每轮调优后观察 1~2 周再复盘。