分析 Amazon DSP 的投放实绩

在这个页面，你可以分析 Amazon DSP（Demand-Side Platform）的投放实绩。DSP 是与 Sponsored Ads 不同的广告产品，管理单位和用语也不同，不是以广告活动 / 广告组，而是以 订单 / 订单项目 管理。本页仅面向投放 DSP 的账户。

本页基本信息

项目	内容
本页能做什么	把 Amazon DSP 的投放趋势确认、按订单 / 订单项目分解业绩、创意疲劳迹象检测、含 / 不含 DSP 的 TACoS 比较整理成一览
对象	仅限 Amazon DSP。Sponsored Ads（SP / SB / SD）为其他页面（参见下方 note）
所需数据・连接	已对接到 Picaro 的 DSP 报表数据（投放 DSP 的账户）。可获取的是订单 / 订单项目层级的展示・点击・订单数・销售额・CTR / CVR / ROAS・new-to-brand 的周度 / 月度趋势
无法获取的数据	创意单体的业绩、频次（frequency）、按受众的细分、CPM・交易（deal）等 DSP 详细指标无法获取
操作范围	仅分析（只读）。DSP 的出价・预算・创意替换等设置变更无法从 Picaro 执行，需在 Amazon DSP 控制台操作

Amazon DSP … 与 Sponsored Ads 不同的广告产品（Demand-Side Platform）。
订单（order） … 管理 DSP 的预算・期间等的单位（相当于 Sponsored Ads 的广告活动）。
订单项目（line item） … DSP 投放设置的单位（相当于 Sponsored Ads 的广告组）。
CTR（点击率）… 广告展示的次数中，被点击的比例。
CVR（购买率）… 点击中，最终转化为购买的比例。
ROAS（广告投入产出比）… 广告带来的销售额 ÷ 广告费。越高越高效。
NTB（品牌新客, new-to-brand）… 在过去一定期间内没有购买过本品牌的新客户。
TACoS（Total ACoS）… 广告费占总销售额的比率。用于衡量整体广告效率的指标。
创意疲劳 … 持续投放同一创意，随时间推移 CTR 逐渐下降的现象。

使用场景

想确认最近数月 DSP 投放整体的趋势，尽早发现正在恶化的指标
想按订单・订单项目分解业绩，寻找预算分配的审视要点
想检测持续投放后 CTR 下降（疑似创意疲劳）的订单项目
想把 DSP 对整体广告效率（TACoS）的影响，分「含 / 不含 DSP」来看

需要准备的信息

连接的账户 … 对象是投放 DSP 的账户。管理多个账户时，请先确认对象账户是否正确。
DSP 报表的对接 … 需要已把 DSP 报表数据对接到 Picaro。
对象期间 … 例如「最近 6 个月按月」「过去 12 周按周」。当天・前一天的数据可能尚未确定，选择已确定的近期区间更稳妥。
销售额的统计口径 … DSP 销售额按 DSP 归因口径，与仪表板的总销售额口径不同（参见上方 caution）。

快速参考

想做的事	能得到什么	设置变更	提示词
确认 DSP 整体投放趋势（月度 / 周度）	按指标的推移表与趋势判定	无变更	提示词 1
按订单项目分解业绩（订单为筛选条件）	附成效好坏判定的一览	无变更	提示词 2
检测创意疲劳（CTR 持续下降）的迹象	疑似疲劳订单项目的一览	无变更	提示词 3
比较含 / 不含 DSP 的 TACoS	含 / 不含 TACoS、差值与解读	无变更	提示词 4

提示词 1: 确认 DSP 整体投放实绩的推移

按月度或周度确认 DSP 投放整体的展示 / 点击 / 订单 / 销售额 / CTR / CVR / ROAS / new-to-brand（NTB: 品牌新客）的推移。

使用场景 —— 想按月度 / 周度掌握 DSP 投放整体的状态，尽早发现正在恶化的指标时。

需要准备的信息 —— 已对接 DSP 报表的账户。对象期间・粒度（默认最近 6 个月按月）。

输出最近 6 个月 Amazon DSP 的业绩趋势（月度）。
以表格展示展示 / 点击 / 订单 / 销售额 / CTR / CVR / ROAS / new-to-brand 的推移。
如有恶化的指标请指出。

可调整的条件 —— 对象期间・粒度（例：过去 12 周按周）。

返回内容 —— 月（或周）× 指标的推移表，以及正在恶化・改善指标的趋势判定。销售额为 DSP 归因口径的数值。

设置变更 —— 仅分析（只读）。不改动 DSP 设置。

下一步 —— 如有在意的指标，用提示词 2 按订单 × 订单项目分解业绩。

提示词 2: 按订单 × 订单项目分解业绩

按 DSP 的管理单位 订单项目（投放设置的单位，相当于广告组）逐个分解业绩，识别成效好坏。订单（相当于 Sponsored Ads 的广告活动）可以作为筛选条件使用，但分解的轴是订单项目层级。

使用场景 —— 想识别成效好 / 坏的订单项目，梳理出预算分配的审视要点时。

需要准备的信息 —— 对象期间（默认过去 3 个月）。也可限定到特定订单（作为筛选条件）。

请将最近 {{对象期间（例：过去3个月）}} 的 DSP 投放，按订单项目层级做业绩分解（订单仅作为筛选条件使用，不做一览获取）。

【步骤】
1. 获取路径
   - 按订单项目的明细，用 `call_picaro_api` 调 POST `/dsp-report/dsp-performance`
     （body: amazon_account_id, frequency, from_date, to_date）。
     响应 `data[]` 中 `type="Line item"` 的数组即为明细。
   - **不要用 `get_dsp_trend` 来取明细。** 该工具只返回期间桶，
     `dsp_line_item_ids` 是筛选条件，并不是按订单项目为轴的输出。
2. 务必计算覆盖率并在开头写明（该 API 既不返回 total_count 也不返回 truncated 标志）
   - **把对象期间按每 1 个月拆开获取。**一次指定多个月时，响应会因传输上限
     被 silently 截断，导致明细缺失。
   - 对每个月计算「Line item 行的广告费合计 ÷ 同期间 `get_dsp_trend` 的 spend」，
     作为覆盖率写明。低于 95% 的月份要写明「明细存在缺失」，并且
     不把该月作为判断依据。
3. 确认并写明指标的单位与定义
   - **ROAS 的单位**: `get_dsp_trend` 的 `totals.roas` 是比率，而 `rows[].roas` 与
     `/dsp-report/dsp-performance` 的 `roas` 是百分比（100 倍）。统一换算成倍率来表述。
   - **不使用 CVR**: DSP 的 CVR 分子包含浏览后（view-through）订单，而分母是点击数，因此
     会超过 100%。它无法作为转化率解释，所以不用于判定，改用 CPA 与 ROAS 判定。
   - **归因模型**: 用 `/dsp-report/dsp-structure` 取得浏览后经由/点击经由的明细，
     并写明浏览后（view-through）的比例。不要把 DSP 的 ROAS 与点击归因媒介（SP/SB/SD）并排放进同一张表。
4. 判定标准（不要简单套用「ROAS 前/后 N%」）
   - 首先**把广告费为 0 的订单项目从判定对象中排除**（存在已停止、只剩残留归因的行，
     它们在 ROAS 升序中占据末位，但不可能成为减额对象）。排除掉的行数与销售额另行列出。
   - 再进一步**只把广告费占期间合计 3% 以上的行**作为决策对象（广告费只有几日元〜几千日元的行，
     ROAS 会飙到数万%，无法据以判断）。要写明对象行覆盖了广告费的百分之多少。
   - 把对象行的 ROAS **与整个期间的 ROAS（销售额合计÷广告费合计）比较**，判定好转/不振。
   - 每算出一个比率，都要写明分子与分母。
5. 解析要执行对象的 ID
   - `/dsp-report/dsp-performance` **不返回订单项目 ID，只有名称**，而名称可能重复。
   - 用 `call_picaro_api` POST `/bigquery/dsp-report/filter-data` 取得 ID・名称一览，
     再向 `get_dsp_trend` 传 `dsp_line_item_ids=["<ID>"]`，以广告费・销售额是否与明细行一致来
     确定 ID。**未能唯一确定的行要写明这一点。**
6. 对好转、不振分别给出「预算增额/减额 X%」的具体方案。

【数据边界】
・用 `get_data_ingestion_status` 确认 DSP report 的确定日，不要把未确定日（当天等）纳入期间。
・DSP 的广告费使用 `/dsp-report/dsp-performance` 的 `spend`，并**写明是从哪个工具取得的**。
　不要使用 `get_amc_ntb_by_asin` 的 ad_spend（DSP 行为 0）与 `total_dsp_spend`（全行相同的常数）。

【Guardrail】
・不执行预算变更等写入操作。
・Guardrail KPI: 除 CPA / Orders 外，务必输出**覆盖率**与**浏览后（view-through）归因比例**。

最后请输出以下 3 点。
1. 推荐行动 — 每个对象订单项目的增额/减额幅度・理由（ROAS/CPA，附分子分母）・优先度（按广告费影响排序）・确信度・风险。要把「DSP 含浏览后归因、无法测量增量性（incrementality）」写进确信度的依据
2. 执行方式 — 在用户确认并批准提案内容的基础上，作为出价变更来反映。交出之前要先用步骤 5 确定 ID
3. 测量 — 执行 14 天后用同一路径重新取得 ROAS 与 CPA，用「举措的效果测定」判定：改善则 Keep，恶化则 Revert

可调整的条件 —— 对象期间／作为对象的订单（筛选条件）范围。

返回内容 —— 订单项目 × 销售额 / ROAS / CTR / CVR × 好坏判定与检讨要点的表（订单仅作为筛选条件使用）。提案仅为检讨材料，实际的预算・投放变更在 Amazon DSP 控制台进行。

设置变更 —— 仅分析・仅建议（只读）。

下一步 —— 实际的预算・投放变更在 Amazon DSP 控制台手动进行。

提示词 3: 检测创意疲劳的迹象

DSP 会向同一受众反复投放横幅 / 视频等创意，因此容易出现 CTR 随时间逐渐下降的「创意疲劳」。Picaro 无法获取创意单体的业绩，因此从 订单项目层级的 CTR 周度趋势 检测疲劳迹象。

使用场景 —— 想找出持续投放后 CTR 下降的订单项目，考虑替换创意时。

需要准备的信息 —— 无（可直接使用）。降幅基准（示例为 25%）可调整。

输出过去 12 周 DSP 各订单项目的 CTR 周度趋势。
将 CTR 从峰值周下降 25% 以上、且最近连续 3 周下降的订单项目
列为「疑似创意疲劳」清单。
并列写出投放期间的长度。

可调整的条件 —— 降幅基准（例：25%）／对象期间（例：过去 12 周）。之所以取 25%，是因为周度 CTR 受季节、星期结构影响本身就会有一到两成左右的波动，只有超过该幅度的持续下降才作为疲劳迹象处理。

返回内容 —— 订单项目 × 峰值周 CTR × 最近 CTR × 降幅 × 连续下降周数 × 投放期间的表。疑似疲劳的订单项目，可作为在 Amazon DSP 控制台进行创意替换、轮换审视的检讨对象。

设置变更 —— 仅分析（只读）。

下一步 —— 疑似疲劳的订单项目，其创意替换、轮换审视在 Amazon DSP 控制台进行。

提示词 4: 比较含 / 不含 DSP 的 TACoS

对于投放 DSP 的账户，把 TACoS（广告费占总销售额的比率）分「含 DSP」与「不含 DSP」两种口径来看，可以分离出 DSP 对整体广告效率的影响。

使用场景 —— 想把 DSP 对整体广告效率的贡献，分「含 / 不含 DSP」的 TACoS 来看时。

需要准备的信息 —— 无（可直接使用）。对象期间（例：上个月、过去 3 个月按月）。

目的: 为了判断 DSP 对广告投入产出整体（TACOS）的影响，并检讨 DSP 的预算分配，
请比较 {{对象期间（例：当月MTD）}} 与 {{比较期间（例：上月同天数窗口）}} 的 TACOS（含 DSP／不含 DSP）。

【数据获取（务必按此顺序进行，不要自行计算 TACOS）】
1. 总销售额・广告费・TACOS 都从 Picaro 取得。不要让用户手动输入总销售额。
   对对象期间与比较期间**分别单独**调用 `/bigquery/advertising-metrix`
   （call_picaro_api, POST, frequency=daily 或 monthly），并原样使用以下字段。
   - total_sales（总销售额・不含税）
   - ad_spend（广告费。不含 DSP）
   - tacos_with_dsp / tacos_without_dsp（BE 返回的计算值。两者的分母是同一个总销售额）
   - ad_revenue / acos（用于 Guardrail）
   不要用一次调用的 previous_value 来代替 2 个期间。previous_value 是
   「同天数的紧邻前一窗口」，并不是上一个日历月，而且 period_tooltip 的期间标签
   有时与实体不符。务必按期间分别单独调用，并确认响应的 from_date / to_date
   与所请求的一致。
2. 用 `get_data_ingestion_status` 确认对象期间的导入状况，若包含未确定日，
   请写明为「含未确定日的暂定值」。当月因为处在月中，不要当作已确定月处理。
3. DSP 的投放实况（展示・费用・ROAS・new-to-brand）使用 `get_dsp_trend`。
   但 **frequency=monthly 不会返回尚未结束的当月**（period_count=0 /
   status=empty / warnings=["dsp_no_rows"]）。要看当月时请使用 frequency=weekly，
   并写明周桶与日历月边界不一致（月初・月末的缺失天数）。
   **即使行为空，也不要断定为「DSP 费用 0」「未投放 DSP」。** 要区分未获取・0・null。
   另外 rows[] 的 cvr / ctr / roas 与 totals 数量级不同（rows 是百分比，totals 是比率），
   因此比率请使用 totals 一侧的值。

【比较的条件（必须）】
- 2 个期间要对齐成**同一天数・同一日历位置的窗口**（例: 当月 1〜N 日 vs 上月 1〜N 日）。
  不要把整月与月中直接比较。无法对齐时就不要比较，并写出理由。
- 确认含 DSP 的 TACOS 与不含 DSP 的 TACOS 是使用**同一个总销售额（分母）**得出的值，
  并且不要把 DSP attributed sales 加到总销售额上。
- 验算: 确认 (tacos_with_dsp − tacos_without_dsp) × total_sales ≒ DSP 广告费，
  若不一致则不要给出数值，而是作为不一致来报告。

【输出（必填项）】
1. 对象期间・比较期间的实际天数，以及导入状态（已确定／未确定）
2. 按期间的表: 总销售额 / 广告费（不含 DSP）/ DSP 广告费 / TACOS(不含 DSP) / TACOS(含 DSP) /
   DSP 贡献 pt（= 含 − 不含）/ 广告带来的销售额 / ACoS
3. **判别比率变化来自分母还是来自分子**（必须）:
   - 并列写出总销售额的变化率与广告费的变化率
   - 计算「把分母固定在比较期间水平时的 TACOS」，与实际变化对照，
     把来自分母的部分与来自分子的部分分离开来呈现
   - 不要把分母（总销售额）缩小导致的 TACOS 恶化，报告成广告效率的恶化
4. 判断: 对照判断标准 {{TACOS恶化的阈值（例：0.5pt）}}，给出 DSP 预算应当维持／增额／缩减
   中的哪一个，以及其依据。即使触及阈值，若恶化来自分母，也要写明这一点，
   不要断定 DSP 是原因。
5. Guardrail: 在 ACoS 与广告带来的销售额不恶化的范围内的变更方案。同时并列写出对 DSP 的 ROAS 与
   new-to-brand（新客获取）的影响。
6. 写明数值上的限制: TACOS 是保留到小数点后第 2 位的四舍五入值；广告费的税务口径尚未确定，
   ACoS 与 TACoS 中有一方会跨越税基准（JP 账户）；已确定的期间也可能因
   re-crawl/backfill 被重新计入。

DSP 预算的变更，请在用户确认并批准提案内容的基础上作为出价变更来反映。下个月重新测量，
用「举措的效果测定」判断是 Keep（维持）还是 Revert（回退）。

可调整的条件 —— 对象期间（例：上个月、过去 3 个月按月）。

返回内容 —— 各期间的含 DSP TACoS / 不含 DSP TACoS / 差值，以及关于 DSP 贡献的解读。