Analyze Amazon DSP delivery performance

On this page you can analyze Amazon DSP (Demand-Side Platform) delivery performance. DSP is a separate ad product from Sponsored Ads, with different management units and terminology: it is managed by orders / line items, not campaigns / ad groups. This page is exclusively for accounts that are running DSP.

About this page

Item	Details
What you can do	List, in one place, the Amazon DSP delivery trend, order / line-item performance decomposition, creative-fatigue signal detection, and the TACoS comparison with / without DSP
Applies to	Amazon DSP only. Sponsored Ads (SP / SB / SD) are covered on separate pages (see the note below)
Data & connection needed	DSP report data linked to Picaro (for accounts running DSP). What you can retrieve is impressions, clicks, orders, sales, CTR / CVR / ROAS, and new-to-brand at the order / line-item level, as weekly / monthly trends
Not available	Creative-level performance, frequency, audience-level breakdowns, and detailed DSP metrics such as CPM and deals cannot be retrieved
Scope	Read-only (analysis only). DSP settings such as bids, budgets, and creative swaps can’t be changed from Picaro; those are done in the Amazon DSP console

Amazon DSP … a separate ad product from Sponsored Ads (Demand-Side Platform).
Order … the unit that manages a DSP budget, schedule, and so on (equivalent to a Sponsored Ads campaign).
Line item … the unit of DSP delivery settings (equivalent to a Sponsored Ads ad group).
CTR (click-through rate) … the share of impressions that resulted in a click.
CVR (conversion rate) … the share of clicks that led to a purchase.
ROAS (Return on Ad Spend) … ad-attributed sales ÷ ad spend. Higher is more efficient.
NTB (new-to-brand) … a customer who had not bought your brand within a defined prior period.
TACoS (Total ACoS) … ad spend as a share of total sales. A measure of overall ad efficiency.
Creative fatigue … the phenomenon where CTR gradually declines over time as the same creative keeps being served.

When to use this

You want to check the overall trend of DSP delivery over the last few months and catch deteriorating metrics early
You want to decompose performance by line item and find where to revisit budget allocation
You want to detect line items whose CTR is dropping as delivery continues (suspected creative fatigue)
You want to isolate DSP’s impact on overall ad efficiency (TACoS) by viewing it with and without DSP

Before you run

Connected account … DSP-running accounts are the target. If you handle multiple accounts, confirm the target account is correct first.
DSP report linkage … DSP report data must be linked to Picaro.
Target period … e.g. “the last 6 months, monthly” or “the past 12 weeks, weekly”. Same-day and previous-day data may not be final, so a recently finalized period is safest.
Sales aggregation basis … DSP sales are on the DSP attribution basis, which differs from total sales on the dashboard (see the caution above).

Quick reference

Goal	What you get	Changes	Prompt
Check the overall DSP delivery trend (monthly / weekly)	A metric-by-metric trend table with a trend judgment	No change	Prompt 1
Decompose performance by line item (orders are a filter condition)	A list with good / poor performance judgments	No change	Prompt 2
Detect signs of creative fatigue (sustained CTR decline)	A list of line items with suspected fatigue	No change	Prompt 3
Compare TACoS with / without DSP	With / without TACoS, the difference, and commentary	No change	Prompt 4

Prompt 1: View the overall DSP delivery trend

Review the monthly or weekly trend of impressions / clicks / orders / sales / CTR / CVR / ROAS / new-to-brand (NTB: new-to-brand customers) across all DSP delivery.

When to use — when you want to grasp the overall state of DSP delivery monthly / weekly and catch deteriorating metrics early.

What you need — an account with DSP report linkage. The target period and granularity (default is the last 6 months, monthly).

Show the Amazon DSP performance trend for the last 6 months, monthly.
Put the trend of impressions / clicks / orders / sales / CTR / CVR / ROAS / new-to-brand in a table.
Point out any deteriorating metrics.

What you can change — the target period and granularity (e.g. the last 12 weeks, weekly).

What you get back — a month (or week) × metric trend table, plus a trend judgment of which metrics are deteriorating or improving. Sales figures are on the DSP attribution basis.

Changes — analysis only (read-only). No DSP settings are changed.

Next steps — if a metric concerns you, decompose it to the order × line-item level with Prompt 2.

Prompt 2: Order × line item performance decomposition

Break down performance by line item — DSP’s management unit (the delivery-setting unit, equivalent to an ad group) — and identify what is performing well and what is not. An order (equivalent to a Sponsored Ads campaign) can be used as a filter condition, but the axis of the decomposition is the line item.

When to use — when you want to identify well- and poorly-performing line items and surface where to revisit budget allocation.

What you need — the target period (default is the past 3 months). You can also narrow to specific orders (as a filter condition).

Decompose DSP delivery for the past {{PERIOD (e.g. last 3 months)}} at the line item level (use orders only as a filter condition; do not fetch a list of them).

[Procedure]
1. Retrieval path
   - For the per-line-item detail rows, use `call_picaro_api` with POST `/dsp-report/dsp-performance`
     (body: amazon_account_id, frequency, from_date, to_date).
     In the response, the entries in `data[]` with `type="Line item"` are the detail rows.
   - **Do not use `get_dsp_trend` to fetch detail rows.** That tool returns period buckets only, and
     `dsp_line_item_ids` is a filter condition, not a line-item axis in the output.
2. Always compute the coverage rate and state it up front (this API returns neither total_count nor a truncated flag)
   - **Split the target period into one-month chunks when fetching.** If you request several months at once, the
     response is silently truncated at the transfer limit and detail rows go missing.
   - For each month, compute "the total ad spend of the Line item rows ÷ the spend from `get_dsp_trend` for the same
     period" and state it as the coverage rate. For any month below 95%, write explicitly that "detail rows are
     missing" and do not use that month as a basis for judgment.
3. Confirm and state the units and definitions of the metrics
   - **ROAS units**: `totals.roas` from `get_dsp_trend` is a ratio, while `rows[].roas` and the `roas` from
     `/dsp-report/dsp-performance` are percentages (100×). Normalize to a ratio before reporting.
   - **Do not use CVR**: DSP's CVR counts view-through orders in the numerator while the denominator is clicks, so it
     exceeds 100%. It cannot be interpreted as a conversion rate, so do not use it for judgments — judge on CPA and ROAS.
   - **Attribution model**: fetch the view-through / click-through breakdown with `/dsp-report/dsp-structure` and
     state the view-through share. Do not put DSP's ROAS in the same table as click-attributed media (SP / SB / SD).
4. Judgment criteria (do not simply apply "the top / bottom N% by ROAS")
   - First, **exclude line items with zero ad spend from the judgment set** (there are rows that are already paused and
     carry only residual attribution; they occupy the bottom when sorted by ascending ROAS but cannot be candidates for
     a spend cut). Report the number of excluded rows and their sales separately.
   - Then, **treat only rows accounting for 3% or more of the period's total ad spend** as decision targets (rows with a
     few yen to a few thousand yen of spend swing to ROAS in the tens of thousands of percent and cannot support a
     judgment). State what share of ad spend the target rows cover.
   - Judge the target rows' ROAS as strong or weak **by comparing it against the ROAS for the whole period
     (total sales ÷ total ad spend)**.
   - Every time you produce a ratio, state its numerator and denominator.
5. Resolve the IDs of the objects you will act on
   - `/dsp-report/dsp-performance` **returns no line item IDs, only names**, and names can be duplicated.
   - Fetch the ID / name list with `call_picaro_api` POST `/bigquery/dsp-report/filter-data`, then pass
     `dsp_line_item_ids=["<ID>"]` to `get_dsp_trend` and settle the ID by checking that ad spend and sales match the
     detail row. **For any row you could not identify uniquely, say so explicitly.**
6. For both the strong and the weak side, present a concrete proposal of the form "increase / decrease the budget by X%".

[Data boundary]
- Confirm the finalized date of the DSP report with `get_data_ingestion_status`, and do not include unfinalized days
  (today and so on) in the period.
- For DSP ad spend use `spend` from `/dsp-report/dsp-performance`, and **state which tool you took it from**.
  Do not use `ad_spend` from `get_amc_ntb_by_asin` (DSP rows are 0) or `total_dsp_spend` (a constant that is identical
  on every row).

[Guardrail]
- Do not perform write operations such as budget changes.
- Guardrail KPIs: in addition to CPA / Orders, always output the **coverage rate** and the **view-through attribution share**.

Finally, output these three things.
1. Recommended actions — for each target line item, the size of the increase / decrease, the reason (ROAS / CPA, with
   numerator and denominator), the priority (in order of ad-spend impact), the confidence level, and the risks. Include
   in the basis for the confidence level that DSP includes view-through attribution, so incrementality cannot be measured
2. How to execute — reflect the proposal as a bid change only after the user has reviewed and approved it. Settle the
   IDs per step 5 before handing it over
3. Measurement — 14 days after execution, re-fetch ROAS and CPA through the same path and, under "measuring the impact
   of an action", judge Keep if improved and Revert if worse

What you can change — the target period / the range of orders (as a filter condition) to cover.

What you get back — a table of line item × sales / ROAS / CTR / CVR × good / poor judgment and points to consider (orders are used only as a filter condition). Suggestions are input for consideration; actual budget and delivery changes are made in the Amazon DSP console.

Changes — analysis and proposal only (read-only).

Next steps — actual budget and delivery changes are made manually in the Amazon DSP console.

Prompt 3: Detect signs of creative fatigue

Because DSP serves creatives such as banners / videos repeatedly to the same audience, it is an ad product prone to “creative fatigue” — where CTR gradually declines over time. Picaro can’t retrieve creative-level performance, so fatigue signals are detected from the weekly CTR trend at the line-item level.

When to use — when you want to find line items whose CTR is falling as delivery continues, to consider swapping creatives.

What you need — nothing (use as is). The decline threshold (25% in the example) can be adjusted.

Show the weekly CTR trend by DSP line item for the past 12 weeks.
List line items whose CTR has dropped 25% or more from its peak week
and has declined for 3 consecutive recent weeks as "suspected creative fatigue."
Include how long each has been serving.

What you can change — the decline threshold (e.g. 25%) / the target period (e.g. the past 12 weeks). It is set at 25% because weekly CTR naturally fluctuates by 10–20% with seasonality and day-of-week mix, so only sustained declines beyond that are treated as fatigue signals.

What you get back — a table of line item × peak-week CTR × recent CTR × decline rate × consecutive declining weeks × serving duration. Line items with suspected fatigue become candidates for creative swaps or rotation reviews in the Amazon DSP console.

Changes — analysis only (read-only).

Next steps — swapping creatives or reviewing rotation for suspected-fatigue line items is done in the Amazon DSP console.

Prompt 4: Compare TACoS with and without DSP

For accounts running DSP, viewing TACoS (ad spend as a share of total sales) both “with DSP” and “without DSP” isolates the impact DSP has on overall ad efficiency.

When to use — when you want to isolate how much DSP is contributing to overall ad efficiency by viewing TACoS with and without DSP.

What you need — nothing (use as is). The target period (e.g. last month, the last 3 months, monthly).

Goal: to judge the impact DSP has on overall ad efficiency (TACoS) and to review the DSP budget allocation,
compare TACoS (with DSP / without DSP) between {{TARGET_PERIOD (e.g. current month MTD)}} and
{{COMPARISON_PERIOD (e.g. the same day-count window last month)}}.

[Data retrieval (always do this in this order, and do not compute TACoS yourself)]
1. Total sales, ad spend, and TACoS come from Picaro. Do not make the user type in total sales.
   Call `/bigquery/advertising-metrix` (call_picaro_api, POST, frequency=daily or monthly)
   **separately** for the target period and for the comparison period, and use the following as returned.
   - total_sales (total sales, excluding tax)
   - ad_spend (ad spend; does not include DSP)
   - tacos_with_dsp / tacos_without_dsp (values computed by the backend; both share the same total sales as the denominator)
   - ad_revenue / acos (for the guardrail)
   Do not cover the two periods with previous_value from a single call. previous_value is
   "the immediately preceding window of the same number of days", not the previous calendar month, and the
   period label in period_tooltip can be out of step with what it actually is. Always call once per period and
   confirm that the from_date / to_date in the response match what you requested.
2. Check the ingestion state of the target period with `get_data_ingestion_status`, and if it includes
   unfinalized days, write "a provisional figure that includes unfinalized days". Do not treat the current
   month as a finalized month, since it is mid-month.
3. For DSP's actual delivery (impressions, spend, ROAS, new-to-brand) use `get_dsp_trend`.
   Note, however, that **frequency=monthly does not return the incomplete current month** (period_count=0 /
   status=empty / warnings=["dsp_no_rows"]). To look at the current month, use frequency=weekly and state that
   the week buckets do not line up with calendar-month boundaries (the missing days at the start and end of the month).
   **Even when the rows are empty, do not conclude "DSP spend is 0" or "DSP is not running."** Distinguish
   not-retrieved, 0, and null.
   Also, cvr / ctr / roas in rows[] are on a different scale from totals (rows are percentages, totals are ratios),
   so take ratios from the totals side.

[Conditions for the comparison (required)]
- Align the two periods to **windows of the same number of days at the same calendar position** (e.g. days 1–N of this
  month vs. days 1–N of last month). Do not compare a whole month directly against a partial month. If you cannot
  align them, do not compare — write down why.
- Confirm that TACoS with DSP and TACoS without DSP are values that use **the same total sales (denominator)**, and
  do not add DSP attributed sales to total sales.
- Cross-check: confirm that (tacos_with_dsp − tacos_without_dsp) × total_sales ≒ DSP ad spend. If they do not match,
  do not present the figures — report the mismatch.

[Output (required items)]
1. The actual number of days in the target and comparison periods, and the ingestion status (finalized / unfinalized)
2. A table per period: total sales / ad spend (without DSP) / DSP ad spend / TACoS (without DSP) / TACoS (with DSP) /
   DSP contribution in points (= with − without) / ad-attributed sales / ACoS
3. **A determination of whether the change in the ratio came from the denominator or the numerator** (required):
   - Show the rate of change of total sales and the rate of change of ad spend side by side
   - Compute "TACoS with the denominator held at the comparison period's level", contrast it with the actual change,
     and separate out the denominator-driven part from the numerator-driven part
   - Do not report a TACoS deterioration caused by a shrinking denominator (total sales) as a deterioration in ad efficiency
4. Verdict: against the criterion {{TACOS_DEGRADATION_THRESHOLD (e.g. 0.5pt)}}, say whether the DSP budget should be
   held / increased / cut, and why. Even when the threshold is met, if the deterioration is denominator-driven, state
   that explicitly and do not conclude that DSP is the cause.
5. Guardrail: a change proposal that keeps ACoS and ad-attributed sales from deteriorating. Also note the impact on
   DSP's ROAS and on new-to-brand (new-customer acquisition).
6. State the constraints on the figures: TACoS is rounded to 2 decimal places; the tax treatment of ad spend is
   undetermined, so one of ACoS and TACoS straddles a different tax basis (JP accounts); and even finalized periods
   can be re-counted by re-crawl / backfill.

Reflect a DSP budget change as a bid change only after the user has reviewed and approved the proposal. Re-measure the
following month and judge Keep or Revert under "measuring the impact of an action".

What you can change — the target period (e.g. last month, the last 3 months, monthly).

What you get back — for each period, TACoS with DSP / TACoS without DSP / the difference, plus commentary on DSP’s contribution.