跳转到内容
Picaro.AI Picaro.AI Prompt Library

用 AMC 分析跨广告的客户行为

本页用 Amazon Marketing Cloud (AMC) 数据，拆解仅靠 ACoS / ROAS 看不到的问题：「每位客户给我们带来多少收益」「广告带来的客户几个月后是否还会购买」「哪些广告活动开始饱和」。分析横跨 SP / SB / SD / DSP，以客户为中心，并深入到 ASIN 组合、广告活动判断与预算分配。

本页基本信息

Section titled “本页基本信息”
项目内容
本页能做什么从 AMC 数据出发，从客户视角拆解 LTV / CAC / NTB / 留存率 / 广告类型归因，把 ASIN 组合、广告活动判断、预算分配的判断材料汇总成一览；同时生成 AMC 控制台用的 SQL 查询
适用对象AMC（Amazon Marketing Cloud）。横跨 SP / SB / SD / DSP，以客户维度分析广告触达的客户
所需数据・连接需连接 AMC 实例。聚合对象仅限 100 名以上用户的分群（AMC 隐私保护规范）。用户数不足的期间 / ASIN / 广告活动会返回「无法聚合」
执行范围绝大多数仅为分析（只读）。提示词 9・10 仅为生成在 AMC 控制台执行的 SQL 查询（Picaro 不会在 AMC 上执行 SQL）。两者均不修改广告设置

什么时候会用到

Section titled “什么时候会用到”
  • 想计算每位客户的 LTV / CAC / 真实 ROAS（含品牌光环）
  • 想查看品牌整体的月度健康度检查（NTB 比例 / 复购率 / LTV:CAC 走势）
  • 想把 ASIN 按角色分类（新客获取 / 回头客维系 / 考虑缩减・退出）
  • 想按获取月查看新客同期群的留存率与 LTV 增长
  • 想按广告类型（SP / SB / SD / DSP）比较 NTB 获取能力・CAC 以决定预算分配
  • 想生成在 AMC 控制台执行的 SQL 查询

执行前请确认

Section titled “执行前请确认”
  • 连接的账号与 AMC 实例 …… 确认目标账号是否已连接 AMC 实例。仪表板用户只需选择已连接账号即可运行，MCP 用户需在连接设置中完成 AMC 实例的映射。
  • 目标期间 …… 提示词 1〜8 受 AMC 一侧规范所限，使用者无法指定任意期间（由 run 固定，或由月度 report_month 固定。详见上方 :::caution）。实际聚合的期间会写在各提示词的输出中，请在那里确认。提示词 9・10（生成 SQL）不受这个约束，可以在生成的 SQL 中指定任意期间。
  • 100 名以上用户的条件 …… 聚合对象仅限 100 名以上用户的分群（AMC 隐私保护规范）。用户数不足的期间 / ASIN / 广告活动会返回「无法聚合」。这是规范，并非限制。
  • 提示词 9・10 的执行范围不同 …… 这两个仅生成在 AMC 控制台执行的 SQL 查询。Picaro 不会在 AMC 上执行任意 SQL。

提示词速查表

Section titled “提示词速查表”
想做的事可获得 / 生成的内容设置变更提示词
计算每位客户的 LTV / CAC / 真实 ROAS客户数・销售额・CAC・LTV（含 / 不含光环）・复购率・LTV:CAC 比的表仅分析提示词 1
查看品牌整体的月度健康度检查月度 NTB 比例・复购率・CAC・LTV・LTV:CAC 比与趋势判定仅分析提示词 2
按 ASIN 查看 NTB（新客）获取能力按 ASIN 的 NTB 比例・广告花费・ACoS 与扩量 / 缩减标签仅分析提示词 3
把 ASIN 按角色划分（新客获取 / 回头客维系 / 考虑缩减）ASIN 的三类分类与预算分配调整方案仅分析提示词 4
按获取月查看新客同期群的留存率与 LTV按获取月同期群的留存率・LTV 与趋势判定仅分析提示词 5
查看购买后的留存漏斗M+1 / M+3 / M+6 的留存率与按广告活动的留存判定仅分析提示词 6
按广告类型比较 NTB 获取能力与销售额按广告类型的 NTB 比例・CAC・ROAS 与预算分配建议仅分析提示词 7
按广告类型比较 M+1 回归率（客户的质）按广告类型的回归率与黏性型 / 一次性型分类仅分析提示词 8

分析基础指标

Section titled “分析基础指标”

先从全局出发，掌握每位客户的采算（LTV / CAC / 真实 ROAS）与品牌整体的健康状态。

提示词 1: 计算客户 LTV / CAC / 真实 ROAS

Section titled “提示词 1: 计算客户 LTV / CAC / 真实 ROAS”

计算通过广告获取的每位客户的 LTV（客户终身价值）、CAC（获客成本）、复购率，以及含品牌光环的 ROAS。不仅是「广告点击的 ASIN」，还会根据是否把该客户在同品牌内购买的其他 ASIN（品牌光环效应 = 广告对象 ASIN 以外、同品牌其他商品的连带销售额）计入销售额，返回两组数字。

适用场景 —— 想用每位客户的终身价值与获客成本、而非 ACoS 来衡量广告采算时。

执行前需要的信息 —— 无。会直接使用 AMC 的 run（执行）所固定的期间，使用者一侧无法指定目标期间。

目的：把握广告投资的长期客户价值投入产出，判断预算分配是否健全。


【数据获取】
LTV・CAC・真实ROAS・复购率请从 get_amc_metric（metric_name="ltv"）取得。
这张表在同一行中同时持有销售额（含光环 total_sales／仅广告点击ASIN promoted_sales）・广告花费 total_spend・
购买者数 purchase_uv・新客数 ntb_buyers・复购率 rpr_pct，因此分母与分子在结构上是对齐的。
AMC 系工具不带期间参数，只返回 run 所固定的 report window。不要设想可以任意指定期间，
务必把返回的 report_start_date / report_end_date / run_id 写进输出。
只有在需要按获取月的LTV走势时，才并用 get_amc_metric（metric_name="cohort"），
并把 max_rows_per_table 指定为大于等于总行数，确认 truncated=false 之后再聚合。
当AMC返回403错误时，请写明「该账户没有AMC权限/合约」，不要写成功能本身不存在。


【算比率时的必须规则】
1. 所有比率都要写明分子・分母・对象期间・run_id。
2. 分母要区分「全部购买者（purchase_uv）」体系与「新客（ntb_buyers）」体系，
   不得构造跨体系的比（例：以全部购买者为分母的LTV ÷ 以新客为分母的CAC）。
3. 务必并列写出含光环（以total_sales为基准）与不含光环（以promoted_sales为基准）两种。
4. 用同一分母计算出的LTV:CAC比与ROAS在定义上是同一个值。不要把两者当作独立的两项验证来呈现。
5. 不要把AMC之外的工具（get_dashboard 等）的广告花费混进CAC的分子。若要参照，
   务必写明它与AMC的 total_spend 的偏离幅度与原因（是否计入DSP・统计对象的差异）。
6. 并用多个AMC工具时，要确认 run_id 与 report window 一致，
   不要把不一致的东西混进同一张表、同一个比。
7. 比较同期群时要对齐观测月数。观测期间短的同期群LTV偏低，
   是观测期间的差异而不是客户质量的差异。不要把观测月数不同的同期群合算后的值作为LTV呈现。
8. "below_reporting_floor" 是隐私阈值导致的不披露，并不是 0 件。不要当作 0 来聚合。
9. 报告比率改善时，务必并列写出分母・分子的实数，做成能判别变化是来自分母缩小还是分子增加的形式。
10. 未能取得的值请写明「无法取得」。不要用其他指标来代用。


【输出】
把仅广告点击ASIN（不含光环）与品牌整体（含光环）并列，
按分母的体系分别判定 LTV:CAC 比是否满足 {{视为健全的阈值（例: 3倍以上）}}。
若不同体系的判定出现分歧，请把「出现了分歧」这件事本身作为结论写明。


最后请输出以下 3 点。
1. 推荐行动 — 不健全时，连同优先度・预期效果・确信度・风险一起给出广告预算分配・定向调整方案（以不大幅损害广告带来的销售额与实数为 Guardrail）
2. 执行方式 — 预算分配的变更方案，要在用户确认并批准之后反映（本提示词不执行）
3. 测量 — 每个季度用「举措的效果测定」重新计算LTV:CAC比，若持续恶化则用「原因诊断」把CAC一侧（是新客数减少还是广告花费增加）与LTV一侧（是首购ATV还是复购率）切分开来深挖

可调整的条件 —— 无（无法指定目标期间）。视为健全的 LTV:CAC 比阈值可以更改（默认 3 倍以上）。实际使用的期间请在输出的 run_id / report_start_date / report_end_date 中确认。

返回内容 —— 汇总客户数・总销售额・广告来源 ASIN 销售额・含品牌光环销售额・CAC・LTV（含 / 不含品牌光环）・复购率・ROAS・LTV:CAC 比的表格。附带 LTV:CAC 比是否达到健康水平（3 倍以上）的判定说明。

此提示词中 AI 会做的事

  1. 聚合最近 90 天的 AMC 数据，提取广告触达的客户
  2. 以「仅广告点击 ASIN」和「品牌全域（含品牌光环）」两种口径计算每位客户的销售额
  3. 用同期广告花费除以客户数得到 CAC
  4. 计算 LTV ÷ CAC 并对健康度（以 3 倍以上为参考）作出说明
  5. 不足 100 名独立客户的分群按 AMC 规范作为「无法聚合」排除

设置变更 —— 仅分析（只读）。不修改广告设置。

下一步 —— 若要衔接客户视角的战略判断，用 制定广告策略；结果报表化用 生成报告。

提示词 2: 品牌获取的月度健康度检查

Section titled “提示词 2: 品牌获取的月度健康度检查”

用一张表查看「本月品牌整体是否健康」的仪表板。并列 NTB 比例 / 复购率 / LTV:CAC 的月度走势，并对恶化指标给出一条警告。

适用场景 —— 想每月用同一套指标监控品牌整体健康度时。

执行前需要的信息 —— 品牌名。无法指定目标期间。会自动以最近已确定的 6 个月（日历月完整包含在内、且数据导入已完成的月份）为对象。

目的: 为了按月监控 {{品牌名（例: Lululun）}} 的新客获取趋势、用于及早发现恶化，
请用AMC数据输出品牌的月度健康度检查。


【对象月的确定方法（先定下来）】
调用 get_amc_new_customer，确认响应的 report_start_date / report_end_date 与 selected_run_id。
对于 window 两端日历月未被完整包含的月份（首月・末月），以及用 get_data_ingestion_status(frequency=monthly)
查得未变成 completed 的月份，请**从表中排除**。被排除的月份放在表外标为「参考值・确定前」，
既不用于环比判定，也不作为「最令人担忧的月份」的候选。对象是已确定的最近6个月。


【月度表】
对每个已确定月，务必把以下项目排在同一行。不得只放比率。
- NTB获取数（分子: new_customers）及其环比
- 总客户数（分母: total_customers）及其环比
- NTB比例（= 分子 ÷ 分母）及其环比差(pp)
- 环比判定「改善／持平／恶化」要**以NTB获取数（实数）为基准**进行
- 在「比率变化的来源」列中写明，比率的变化是来自分子的增减还是来自分母的增减
  （例: 分子在减少，但分母减少得更多导致比率上升时，要写成「来自分母缩小的表面上升」，
   绝对不要表述为『改善』『健全』）
总客户数请用 get_amc_total_customer 取得，并**明确指定与 new_customer 相同的 run_id**，
再与 new_customer 一侧的 total_customers 对照是否一致。仅当分母无法取得时才写「无法算出（原因）」。


【无法按月取得的指标的处理】
- CAC / LTV / LTV:CAC比 因为AMC中没有月度明细，请把 get_amc_ltv_latest_snapshot 的最新快照另设一栏只呈现一次，
  并务必并记其 run_id 与 report window。
- 复购率在 get_amc_metric(metric_name=retention) 中只有按 ad_type 的快照，但若使用
  get_amc_metric(metric_name=cohort, max_rows_per_table=5000) 的 cohort_ltv（cohort_month × 经过月 time_slot）与
  cohort_summary 的 cohort_ntb_buyers，就能算出**按获取月的M1复购率**。计算时要对齐经过月，
  并排除 M1 窗口在 window 末尾被截断的同期群。累计 repeat_purchase_uv 因为观测期间长度不同，
  不要在同期群之间直接比较。
- retention 的母集团是「广告起因NTB」，与月度表的母集团（品牌整体NTB）不同。请另设一栏，并写明母集团的差异。
- 完全不使用推测值・假定值，无法算出的指标请写明「无法算出（原因）」。
  即使返回了条数，若明细为空也不要当作「有数据」。


【run_id 的写明】
AMC 的工具之间并不共享 run_id（把某个工具的 run_id 传给别的工具会返回 0 件）。
务必把所使用的各个工具的 selected_run_id 与 report window 写进输出。


【判定与下一步行动】
用NTB获取数的环比判定「改善／持平／恶化」，并举出 1 个最令人担忧的月份。
对该月份，确认NTB比例是否同时在上升，若在上升，务必附上分子・分母的实数变化，
并明示不得把比率的上升解读为健全化。
判定为恶化时，请用提示词 7（按广告类型比较 NTB 获取能力与销售额）深挖原因。30天后（在对象月变成已确定月的时点）
重新执行，若恶化仍在持续，请上升到「原因诊断」。

可调整的条件 —— 仅品牌名（无法指定目标期间。固定为最近已确定的 6 个月）。

返回内容 —— 按月的 NTB 比例・复购率・CAC・LTV・LTV:CAC 比 表，附趋势判定（改善 / 持平 / 恶化）与最需关注指标的小结。

此提示词中 AI 会做的事

  1. 按月聚合 AMC 数据
  2. 按月计算 NTB 比例 / 复购率 / CAC / LTV
  3. 判定各指标的月度趋势方向
  4. 通过 LTV:CAC 比的趋势判定综合健康度
  5. 提取恶化最严重的一项指标并警告
  6. 不足 100 名独立客户的月份单元按 AMC 规范不参与聚合

设置变更 —— 仅分析（只读）。不修改广告设置。

下一步 —— 纳入月度报告时用 生成报告。

判断 ASIN 组合

Section titled “判断 ASIN 组合”

从商品维度梳理哪些 ASIN 带来新客、哪些 ASIN 应当收紧。

提示词 3: 按 ASIN 分析 NTB（品牌新客）获取能力

Section titled “提示词 3: 按 ASIN 分析 NTB（品牌新客）获取能力”

按 ASIN 维度拆解「带来了多少品牌新客（NTB: New-to-Brand）」「其中是否对得起广告花费」。可判断某 ASIN 更擅长获取新客还是维系回头客。

适用场景 —— 想以新客获取能力来甄别应收紧和应扩量的广告候选时。

执行前需要的信息 —— 目标月份（可选・例: 2026-07）。按 ASIN 的 NTB 是月度（report_month）粒度，无法做「过去 30 天」这类按天数的指定。若指定的月份尚未确定，会改用实际能取得的最后一个已确定月份。

目的：把握按ASIN的NTB（新客）获取效率，用于广告预算的最优分配判断。


【取得与期间】
AMC的NTB by ASIN固定为月度（report_month），无法指定「过去30天」等任意期间。请取得最新run，并在开头写明 run_id / run_date / report_start_date / report_end_date。
目标月份取 report_end_date 已到达月末的**最后一个完整月**（设想为 {{目标月份（例: 2026-07）}}。若实际数据的最后完整月不同，则改用后者并写明差异）。在月中结束的月份作为部分月排除。
请在全量取得之后，于开头写明 LIST总件数 / 所选run件数 / 取得件数 / 是否truncated；若为部分取得，则不要进行排名。


【聚合规则（务必遵守）】
1. 1 行是 ASIN × ad_product_type × report_month。请**跨 ad_product_type 按 ASIN 合算**之后再做表（不合算的话同一个ASIN会分成多行）。
2. `below_reporting_floor` 不是ASIN，而是**不披露的聚合桶**。请**务必从按ASIN的表与排名中排除**，并**务必写明**它在目标月份的总购买数・NTB购买数・广告来源销售额中所占的**比例**。不得当作0件处理。
3. `ad_spend` 会因 ad_product_type 而缺测。请**实际数出并写明哪些 ad_product_type 的 ad_spend 恒为0**。ACoS 请**对齐分子与分母，仅用 ad_spend > 0 的行来计算（广告花费合计 ÷ 同一批行的广告来源销售额合计）**。若把全部 ad_product_type 的销售额作为分母，ACoS 会偏小。两种算法差异较大的ASIN请并记其差值。
4. `total_dsp_spend` 是品牌整体的单一常数。不要按ASIN摊分或加总。
5. AMC因隐私下限（distinct user 数的下限）**会导致部分ASIN根本不存在于 export 中**。请与广告实绩靠前的ASIN对照，**点名列出AMC中不存在的主要ASIN**，并写明其广告花费与销售额规模。


【输出】
请按ASIN做表，列出 总购买数・NTB购买数・NTB比例・广告来源销售额・广告花费・ACoS（按上述第3条的算法）。
把NTB比例低于{{下限（例: 20%）}}且ACoS超过{{上限（例: 30%）}}的ASIN作为「缩减候选」，把NTB比例前10且ACoS在基准内的ASIN作为「扩量候选」。**若符合条件的为0件，请写明「0件」，不得擅自放宽阈值。**


最后请输出以下3点。
1. 推荐行动 — 缩减候选削减广告花费{{削减率（例: 20%）}}，扩量候选优先加强出价，并连同优先度・预期效果・确信度・风险一起提出（以Orders减少{{容许值（例: -10%以内）}}为Guardrail）。同时以**不披露桶的比例与AMC中缺失的ASIN**为依据，写明本判断力所不及的范围。
2. 执行方式 — 广告花费的增减要在用户确认并批准之后反映（本提示词只生成建议，不执行）
3. 测量 — 30天后用「举措的效果测定」重新取得NTB比例与ACoS，改善则Keep，恶化则Revert。**重新取得时要固定run，把ACoS的算法与本次对齐，并确认比例的改善不是来自分母（总购买数）的缩小。**

可调整的条件 —— 目标月份（以月度 report_month 为单位。无法按天数指定期间）。NTB 比例的下限・ACoS 的上限・广告花费的削减率等阈值。

返回内容 —— 按 ASIN 的 总购买数・NTB 购买数・独立客户数・NTB 独立客户数・NTB 比例・广告来源销售额・广告花费・ACoS 表。附「建议缩减」「建议扩量」标签。

此提示词中 AI 会做的事

  1. 从 AMC 数据提取按 ASIN 的购买数与新客数
  2. 计算 NTB 比例（NTB 客户 ÷ 全部客户）与每位 NTB 的广告花费
  3. 按 NTB 获取效率（NTB ÷ 广告花费）对 ASIN 排序
  4. 分别给出前 10 名 ASIN（有扩量空间）与末位（建议缩减）
  5. 不足 100 名独立客户的 ASIN 按 AMC 规范不参与聚合

设置变更 —— 仅分析（只读）。不修改广告设置。

下一步 —— 若要整理 ASIN 的分类规则，用 用标签与命名规则给广告分类；按角色梳理用 提示词 4。

提示词 4: 按角色划分 ASIN（新客获取 / 回头客维系 / 缩减・退出考虑）

Section titled “提示词 4: 按角色划分 ASIN（新客获取 / 回头客维系 / 缩减・退出考虑）”

将各 ASIN 分为「擅长获取新客的 ASIN」「有助于维系回头客的 ASIN」「ROI 较差、需考虑缩减・停止・退出的 ASIN」三类。用于梳理整个 ASIN 组合中各自的角色。第三类不是「应立即停止的 ASIN」，而是以数据为依据、考虑缩减・停止・退出的候选。

适用场景 —— 想梳理整个 ASIN 组合的角色、制定预算分配方针时。

执行前需要的信息 —— 目标期间（默认过去 90 天）。

基于最近 90 天的 AMC 数据，将正在 SP / SB / SD 投放的 ASIN 分为
「擅长获取新客的 ASIN」「有助于维系回头客的 ASIN」
「ROI 较差、需考虑缩减・停止・退出的 ASIN」三类。
明确分类标准（NTB 比例 / 广告 ROI / 复购数），
并附上各类前 5 名 ASIN 及其指标。
给出预算分配的调整方案。

可调整的条件 —— 目标期间（为吸收季节因素建议 90 天以上）。

返回内容 —— 按 ASIN 的 类别・NTB 比例・广告 ROI・复购数・建议行动 表。附各类前 5 名 ASIN 列表与预算分配调整方案。

此提示词中 AI 会做的事

  1. 按 ASIN 提取 NTB 比例 / 广告 ROI / 复购数
  2. 以三轴打分自动分为三类（先明确标准再判定）
  3. 提取各类前 5 名 ASIN
  4. 提议应将预算倾向哪一类 ASIN
  5. 不足 100 名独立客户的 ASIN 按 AMC 规范不参与聚合

设置变更 —— 仅分析・提议（只读）。不修改广告设置。

下一步 —— 制定预算分配的具体方案用 制定广告策略；结果报表化用 生成报告。

按获取月分析留存率

Section titled “按获取月分析留存率”

按获取月份、按经过月份，追踪购买过一次的客户是否持续复购。

提示词 5: 按获取月分析新客同期群的留存率与 LTV

Section titled “提示词 5: 按获取月分析新客同期群的留存率与 LTV”

把「同一个月首次购买的新客」作为一个同期群，按获取月份聚合其后在 M+1 / M+3 / M+6 的持续购买情况。可视化「越是最近获取的客户留存越高还是越低」「何时流失」。

适用场景 —— 想按月度趋势确认不同获取时期客户黏性是否变化时。

执行前需要的信息 —— 无。按获取月的同期群会直接沿用 AMC 的 run（执行）所持有的期间，使用者无法指定任意期间（仅在想切换 run 时，才可以从可用的 run_date 一览中选择）。

目的: 为了把握新客的黏着趋势、用于获取举措的继续／调整判断，请用AMC的按获取月同期群
输出 {{cohort_metric}} 的持续指标与累计销售额。


【数据源与run的固定】
请使用 get_amc_metric(metric_name="cohort", max_rows_per_table=5000)，并务必在开头写明响应的
selected_run_id / report_start_date / report_end_date / generated_at。
这个工具接受 run_date 参数（省略时自动选择最新run）。若传入不存在的 run_date，会在
metadata.tables[*].available_runs 中列出可选的 run_id / run_date / report 期间返回，
想固定run时请从中选择。但没有任何参数可以指定任意的分析期间。
report 期间由run一侧决定，因此不要说成是自己指定了期间，请把run返回的期间原样
声明为分析对象期间。 别的 metric（retention 等）的run采番序列不同，可能不存在与 cohort 相同的
run_date（把 cohort 最新run的 run_date 传给 retention 会返回0件）。因此
不要把它与本分析的数值混进同一张表。若必须混用，请并记两者的 run_id 与期间，
并写明无法比较。


【行数的核对】
核对请以「所选run的 row_count 与 returned_rows 一致，且 truncated 为 false」来进行。
metadata.tables.*.list_row_count 是每周run累积下来的LIST整体行数，并不是所选run的总行数。
请不要把它作为核对对象。仅在不一致或 truncated=true 时写明「未确定」。


【同期群规模】
cohort_ltv.cohort_ntb_buyers 为 null。同期群规模请务必用 cohort_month join
cohort_summary.cohort_ntb_buyers 来取得。


【频次合算的处理】
请把 purchase_frequency（{{frequency_buckets}}）按 cohort_month × time_slot 合算，并给出合算前后的行数。
但不要把 repeat_purchase_uv 的合算值当作独立客户数。
桶是互斥还是累计，工具规范中没有记载、无法判别。持续指标请写明定义为
「repeat 购买UV合算 ÷ 同期群NTB数」，不要断定为「留存率」。
销售额（repeat_product_sales）的合算用加法即可。


【🔴 观测期间被截断的处理（最重要）】
1. 各同期群的最后一个 time_slot 是被 report_end_date 截断的部分期间。不要作为确定值使用，
   请从聚合中排除。（要明示排除掉的 slot）
2. 请排除获取月本身成为部分月的首尾 cohort_month（落在 report 期间两端的月份）。
   其同期群规模无法与其他月份比较。
3. 不要把观测期间不同的同期群并排放在同一张表里。 不要制作把全部 time_slot 合算的「累计LTV」
   按获取月顺序排列的表。越是最近的同期群数值越小，是因为观测窗口更短，并不是黏着变差。
4. 比较务必对齐在「获取后第N个月的时点」上进行（N = {{align_months}}）。
   完整 time_slot 数不足N的同期群不要放进表里，请写明「观测期间不足」。


【输出】
请把满足上述条件的表，按 获取月 × 同期群规模 × 各第N个月时点的 repeat 购买UV率 × N个月累计销售额÷NTB
呈现出来。被排除的同期群・被排除的 time_slot・无法算出的指标，请作为「无法取得（原因）」在表外列出。
推测值・概算值・对缺测的0填充一律不要进行。
由于没有相当于 below_reporting_floor 的标志，小单元的不披露与0无法区分。请不要断定为0。


【判定】
请在对齐观测时点的比较之上，判定获取月较新的同期群其黏着指标是高于还是低于较旧的同期群。
不要以期间未对齐的数值为依据来陈述恶化・改善。 若判定所需的观测期间尚未凑齐，
请写明「无法判定（观测期间不足）」，并说明何时才能判定。


【Next Action】
仅当对齐观测时点后确认到恶化时，才用提示词6（分析购买后的留存漏斗）深挖按广告活动的原因。
但 retention 系的表不具备 cohort_month 轴，且是不同run・不同期间，
因此请在确认它无法用于按同期群的原因分解之后再实施。


【确定数据的边界】
请不要把导入尚未完成的月份（get_data_ingestion_status 中为 fully_missed / in_progress）
当作确定值处理。

可调整的条件 —— 无（无法指定目标期间）。所使用的 run 的期间一定会写在输出中。

返回内容 —— 按获取月的 同期群规模・首购后 1 / 3 / 6 个月的销售额・同期群 LTV 与月度趋势判定。同期群规模不足 100 名客户的月份按 AMC 规范不显示。

此提示词中 AI 会做的事

  1. 按获取月把「通过广告首购的新客」分组
  2. 聚合各同期群在 M+1 / M+3 / M+6 产生的销售额
  3. 将跨月的同期群 LTV 走势趋势化（改善 / 恶化 / 持平）
  4. 不足 100 名独立客户的同期群按 AMC 规范不参与聚合

设置变更 —— 仅分析（只读）。不修改广告设置。

下一步 —— 若要按广告活动查看各经过月的留存率，用 提示词 6；报表化用 生成报告。

提示词 6: 分析购买后的留存漏斗

Section titled “提示词 6: 分析购买后的留存漏斗”

按时间槽（M+1 / M+3 / M+6 等）聚合「首购后 N 个月有多少 % 客户回归」。按获取广告活动拆分，可判断「哪个广告活动带来更易留存的客户」。

适用场景 —— 想查看客户在哪个时点最易流失、哪个获取广告活动带来更易留存客户时。

执行前需要的信息 —— 目标期间（默认过去 6 个月）。但 AMC 一侧未必能按这个期间筛选，实际聚合的期间会写在输出中。

目的：识别更易留存的获取广告活动，用于下期的预算分配判断。


## 取得
1. 请按广告活动粒度取得AMC的留存指标（务必全量取得，不要只用开头的样本做聚合）。
2. 同时，请取得与留存**同一run的**按广告活动的归因（广告花费・ROAS・NTB购买数）及其月度明细。
3. **AMC的指标可能会因指标不同而选中不同的run・不同的聚合期间。** 请从响应中读取每张表的run与聚合期间（开始日・结束日），并务必写在开头。**不要把聚合期间不一致的表相互结合或比较。**
4. 若无法把期间限定为{{目标期间（例: 过去6个月）}}，请直接采用实际返回的聚合期间，并写明「所要求的期间无法指定，实际期间为◯◯〜◯◯」。


## 件数的验证
5. 请把按广告活动的表的行数，与同一run的按品牌（按广告类型）的表的人数合计相核对，给出覆盖率。**不要把元数据的累计行数（list_row_count）作为分母**（那是每周run的累计，并不是所选run的总行数）。若合计超过100%，请写明可能存在重复计入。


## 表的制作
6. 请把首购后1/3个月的留存客户数（定义为首购者中在该期间内再次购买的人数）・留存率，做成按获取广告活动的表。留存率请直接使用AMC返回的值，不要自行重新计算。
7. 若M6留存率・平均复购间隔在对应表的schema中不存在，请写明「无法算出」，并**不要代用**。仅能按品牌维度取得的指标，不要挪用到按广告活动的判定上。


## 判定（务必应用3道护栏）
8. 以下各项均**不作为判定对象**，请另行报告排除理由与规模。
   - 低于聚合下限的不披露桶行（不是广告活动名，而是「reporting floor」等聚合行）。**不要当作0人，请给出实数**，并给出按广告类型的占比。它不是单个广告活动，因此不能成为预算操作的对象。
   - 广告活动名为空的行
   - NTB购买者数不足{{最小NTB（例: 500）}}的行（样本过小，留存率不稳定）
9. **观测期间截断的护栏（必须）**：若留存率的表中没有获取月，则整个聚合期间的客户都混在一行里，**最近获取的客户还没有时间观测到3个月后，却已经进入分母，从而压低M3留存率。** 请用月度明细算出各广告活动「最近3个月获取的NTB占比」，超过{{最近偏斜上限（例: 30%）}}的广告活动请**作为「判定保留」，务必从预算缩减对象中排除**。请同时并记留存良好组与留存不良组各自的中位数，以显示截断对判定的扭曲程度。若用于该诊断的月度数据范围短于留存率的聚合期间，请写明该推定偏向上限。
10. 在剩下的对象中，把M3留存率在{{下限（例: 10%）}}以上的作为「留存良好」，低于该值的作为「留存不良」。


## 输出
最后请输出以下3点。
1. 推荐行动 — 连同优先度・预期效果・确信度・风险一起，给出留存不良广告活动的预算缩减方案。**预期效果要用从同一run的归因结合得到的实际广告花费以金额呈现**。缩减率等带假定的数值要写明「这不是AMC的返回值，而是假定」。**即使留存率低、但ROAS显著高的广告活动请另设一栏，作为不应缩减、而应优先考虑增加复购引导的对象处理**。归类为「判定保留」的广告活动不要纳入缩减方案，请连同重新判定的时点另表呈现。
2. 执行方式 — 预算缩减方案要在用户确认并批准之后反映。本提示词不做任何预算・出价的变更。
3. 测量 — 30天后用「举措的效果测定」重新取得M3留存率与NTB购买数，若NTB购买数下降超过-10%则判断Revert。**重新取得时run会推进、聚合期间会整体平移，因此不会是与上次相同母集团的比较。** 请把两个时点各自比较的run・聚合期间都记录下来，在明示期间差异之后再作判断。请把本次的run・期间・数值以表格形式留作基线。

可调整的条件 —— 目标期间（例如 2025-10 起。若无法按指定取得，会改用实际的聚合期间）／按获取广告活动拆分还是 仅整体 查看。

返回内容 —— 按首购后经过月份的 留存客户数・留存率・平均复购间隔 表。按广告活动拆分时，附「易留存 / 不易留存」标签给出前列・末位。

此提示词中 AI 会做的事

  1. 从 AMC 数据提取首购客户
  2. 按时间槽（M+1 / M+3 / M+6 等）聚合是否复购
  3. 可视化留存率曲线（流失点）
  4. 指定按广告活动拆分时，按获取路径聚合并对留存率差异排序
  5. 不足 100 名独立客户的分群按 AMC 规范不参与聚合

设置变更 —— 仅分析（只读）。不修改广告设置。

下一步 —— 若要比较更易留存的广告类型，用 提示词 8；报表化用 生成报告。

按广告类型比较

Section titled “按广告类型比较”

比较 SP / SB / SD / DSP 中哪种更高效地带来新客，作为预算分配的判断材料。

提示词 7: 按广告类型比较 NTB 获取能力与销售额

Section titled “提示词 7: 按广告类型比较 NTB 获取能力与销售额”

按 SP / SB / SD / DSP 广告类型比较「带来多少购买者」「其中 NTB 比例多少」「广告来源销售额多少」。可作为广告类型间预算转移的判断材料。

适用场景 —— 想比较哪种广告类型更高效地带来新客、决定预算投向时。

执行前需要的信息 —— 无。默认会返回约 2 年的滚动累计数据，使用者无法指定期间（短期动向另用月度表确认，但那边没有广告花费，因此算不出 NTB ROAS / NTB CAC）。

目的：比较按广告类型的NTB（新客）获取效率，用于预算分配的调整判断。


【一次数据源】
请使用 get_amc_metric(metric_name="ads_attribution", max_rows_per_table=5000)。
这张表以广告类型（ad_product_type）为行粒度，用单一数据源・单一期间返回比较所需的值。
不需要从别的工具收集广告花费再手工对齐窗口。
使用的字段: ad_product_type / purchase_uv / ntb_uv / ntb_uv_pct / ntb_purchases / ntb_purchase_pct /
cost（广告花费）/ product_sales / ntb_sales / ntb_sales_pct / roas / ntb_roas / cpp_uv / ntb_cpp_uv（NTB CAC）/ atv / ntb_atv / clicks_uv


【run与期间的写明（必须）】
AMC没有任意期间的参数，只会返回run上固定的期间。请务必在开头写明 selected_run_id /
report_start_date / report_end_date / generated_at，并写上「这不是指定期间，而是
约两年的滚动累计」。行数的核对请用所选run的 row_count /
returned_rows / truncated 来做，不要把每周run累积的 list_row_count 作为分母。


【输出】
请按广告类型（SP / SB / SD / DSP）把以下内容做成表。所有比率都要并记分子与分母的实数。
- 购买者数（purchase_uv）/ NTB购买者数（ntb_uv）/ NTB比例（ntb_uv_pct）
- 广告花费（cost）/ NTB来源销售额（ntb_sales）
- NTB ROAS（ntb_roas） ← Primary KPI。直接使用MCP返回的值，不要自己用 ntb_sales ÷ cost 重新计算
- NTB CAC（ntb_cpp_uv） ← 并记的辅助KPI。同样直接使用返回值
- 参考: 整体ROAS（roas）/ ATV（atv）/ NTB ATV（ntb_atv）


【判定】
请把NTB ROAS低于整体平均{{下限（例: 70%）}}的广告类型作为「缩减候选」提出
（NTB ROAS是越高越好的指标）。同时并记NTB CAC超过整体平均{{上限（例: 130%）}}的类型，
两个指标判定不一致的类型请写明「判定不一致」，且不要纳入缩减候选
（因为NTB来源销售额的大小与获客单价的低廉说的是两回事）。


【约束的写明（必须）】
1. 广告类型并不互斥（同一位客户可能在多个类型中被判定为NTB）。
   只能用于类型之间的相对比较，不要把4个类型加总来谈品牌整体。请把这个约束写进输出。
2. 这里的NTB是「广告起因NTB」，与品牌整体的新客数母集团不同。不要混用。
   若要并记品牌整体的NTB销售额作为参考，请使用 get_amc_new_customer 的 ntb_revenue，
   并附上其 run_id 与 window 不同、无法与上表直接结合的说明。
3. 因为是约两年的累计，最近的举措变更几乎不会反映到这个数值里。想看短期动向时，
   请另表使用 ads_attribution_monthly（report_month 粒度。按 ad_product_type 返回 purchase_uv / ntb_uv / ntb_sales），
   并写明月度表中没有 cost，因此算不出月度的NTB ROAS / NTB CAC。
   report_end_date 未到达月末的月份作为部分月排除。
4. 禁止推测值・代用。无法取得的指标请写明「无法取得（原因）」。


【按ASIN的深挖不在本提示词范围内】
按ASIN的NTB效率请用提示词3（按 ASIN 分析 NTB（品牌新客）获取能力）确认。
按ASIN的表（NTB by ASIN）的 ad_spend 会因广告类型而整块缺失，
因此不要用于按广告类型的费用比较。


最后请输出以下3点。
1. 推荐行动 — 连同优先度・预期效果・确信度・风险一起给出缩减候选的预算再分配方案。
   请写明金额依据用的是「约两年累计的实绩广告花费」，既不是「预算额度」也不是「最近的月额」。
   Guardrail: NTB获取数下降超过{{容许下降率（例: -15%）}}时不建议转移。
2. 执行方式 — 预算转移方案要在用户确认并批准之后反映（本提示词不做任何预算・出价的变更）
3. 测量 — 按灵敏度区分指标。NTB获取数可以用 ads_attribution_monthly 在{{短期评估期间（例: 30天）}}判定。
   NTB ROAS / NTB CAC 因为是约两年累计，在短期内不会变动，请在{{长期评估期间（例: 3个月）}}之后再取得。
   重新取得时要记录 run_id 与 report 期间，在相同宽度的窗口之间比较后再判定改善/恶化。

可调整的条件 —— 无（无法指定目标期间。因为是约 2 年累计，最近的举措变更几乎不会反映）。用于 NTB ROAS / NTB CAC 缩减候选判定的阈值可以更改。

返回内容 —— 按广告类型的 购买者数・广告来源销售额・NTB 比例・每位 NTB 的 CAC・NTB ROAS 表与预算分配建议。未投放 DSP 的账号仅返回 SP / SB / SD。

此提示词中 AI 会做的事

  1. 按广告类型拆分 AMC 数据，聚合购买者与销售额
  2. 计算 NTB 比例与每位 NTB 的 CAC
  3. 按 NTB ROAS（NTB 销售额 ÷ 广告花费）对广告类型排序
  4. 检查预算分配是否偏斜（过度集中于某一类型）
  5. 不足 100 名独立客户的广告类型按 AMC 规范不参与聚合

设置变更 —— 仅分析・提议（只读）。不修改广告设置。

下一步 —— 战略层面的分配用 制定广告策略。

提示词 8: 按广告类型比较 M+1 回归率（留存率）

Section titled “提示词 8: 按广告类型比较 M+1 回归率（留存率）”

用首购 1 个月后的回归率比较「哪个广告类型带来更易留存的客户」。衡量的是仅看 NTB 数量看不到的「客户的质」。

适用场景 —— 不仅看新客获取数，还想以带来的客户是否留存（客户的质）来比较广告类型时。

执行前需要的信息 —— 无。始终返回约 24 个月的滚动累计数据，使用者无法指定期间。

请用{{品牌/账户}}的AMC广告归因数据，比较经由SP/SB/SD/DSP获取的NTB客户的M+1（获取1个月后）回归率。


【前提：期间无法选择】
AMC的retention表不接受期间指定，始终以1行返回约24个月滚动的累计值。无法取得任意期间（如90天）的回归率，因此不要试图缩小期间。取而代之，请把实际返回的 run_id・report_start_date・report_end_date 原样明示，并在开头写上「这不是指定期间，而是约24个月的累计」。


【步骤】
1. 取得按广告类型的NTB获取数・M+1回归客户数・M+1回归率。回归率直接使用MCP返回的值，不要自行重新计算。要明示取得件数/总件数・是否truncation。总行数的核对用所选run的row_count/returned_rows/truncated来做，不要使用属于每周run累计的list_row_count。
2. NTB CAC从广告归因表的NTB单价（ntb_cpp_uv）取得。**要确认并写明它取自与回归率相同的run_id・相同的report期间。**因为每个metric的run与窗口都不同，不要把不同run的数值并排放在一起。
3. 【必须】检查观测期间偏差。累计表中没有获取月的维度，在report_end_date之前不久获取的NTB还没有观测完M+1。请用月度归因表的NTB数，按广告类型算出「最近2个月的获取数 / 全期间的获取数」＝截断率，并务必并记以下两项。
   - 原始回归率（下限）
   - 假定被截断同期群的回归为0、并把它们从分母中剔除后的修正后回归率（上限）
   作为核算，请确认月度NTB数的合计与累计NTB数大致一致。若不一致，说明月度表未覆盖全期间，请写明该情况并放弃修正。
4. 比较原始排名与修正后排名，**发生对调的配对请写明「无法判定」**。只把排名不变的配对用于结论。
5. 判定留存率最高的广告类型。若差距不足1pp则写「实质同等」，不要仅以留存率为依据断定优劣。此时请把NTB CAC一并作为判断依据。


【数据质量的必查项】
・不要把「Below reporting floor」等聚合行当作0。它持有实数，请确认它是否被计入聚合并写明。
・不要把ad_type栏为空的行凭推测归入某个特定类型。请写明件数，保持未分类并排除。
・不要把回归客户数为0的行断定为实绩0。请确认是否属于截断・新广告活动・聚合下限之一。
・若有对象为0件的广告类型，请写明「符合0件」，在断定为实绩0之前先确认数据取得状况。无法取得的广告类型请明示「无法取得」，仅用其他类型进行判定。
・**广告类型并不互斥**（同一位客户可能在多个类型中被判定为NTB）。只能用于类型之间的相对比较，不要把4个类型加总来谈品牌整体。请把这个约束写进输出。
・这里的NTB是「广告起因NTB」，与品牌整体的新客数母集团不同。不要混用。
・当月是部分月，不要作为走势的最后一点。请确认数据导入状况，不要把未确定月当作确定值。


【约束】
・本结果仅为分析。不执行预算变更。不调用写入类工具。


最后请输出以下3点。
1. 推荐行动 — 写明向留存率高的广告类型转移预算的金额参考（{{转移率（例: 10%）}}）・理由・优先度・预期效果・确信度・风险。写明金额依据用的是「实绩广告花费」而不是「预算额度」，并附上预算额度需另行确认。若要用平均CAC外推预期效果，请先给出转移目标的支出规模会变成几倍，然后声明「这是未计入边际CAC恶化的上限值，并非预测」。Guardrail: NTB获取数下降超过{{容许下降率（例: -15%）}}时不建议转移。
2. 执行方式 — 把这个分配变更建议交给「调整预算」类别的批准・执行提示词。写明移交时的交接事项。
3. 测量 — 要按灵敏度区分指标。NTB获取数可以用月度归因在{{短期评估期间（例: 30天）}}判定。M+1回归率因为是约24个月累计，在短期内不会变动，请在**{{长期评估期间（例: 3个月）}}之后**重新取得。重新取得时务必记录run_id与report期间，在相同宽度的窗口之间比较，并每次重新计算截断修正后再比较。改善则判定Keep・恶化则判定Revert。

可调整的条件 —— 无（无法指定目标期间。因为是约 24 个月累计，最近的举措变更几乎不会反映）。预算转移率的参考值可以更改。

返回内容 —— 按广告类型的 NTB 获取数・1 个月后回归数・回归率，附「黏性型」「一次性型」分类。未投放 DSP 的账号仅返回 SP / SB / SD。

此提示词中 AI 会做的事

  1. 按广告类型提取 NTB 客户
  2. 判断各 NTB 是否在 M+1 之前完成第二次购买
  3. 按广告类型对回归率排序
  4. 分为「黏性型（回归率高）」「一次性型（回归率低）」
  5. 不足 100 名独立客户的广告类型按 AMC 规范不参与聚合

设置变更 —— 仅分析（只读）。不修改广告设置。

下一步 —— 向黏性型较多的广告类型分配预算用 制定广告策略；报表化用 生成报告。

生成 AMC 控制台用的 SQL

Section titled “生成 AMC 控制台用的 SQL”

不是让 Picaro 分析，而是生成用于自己在 AMC 控制台执行的 SQL 查询。只有这里的执行范围是「仅生成 SQL」（Picaro 不会在 AMC 上执行 SQL）。

相关分类

Section titled “相关分类”