Sponsored Brands Attributed Purchases mapping

Equivalent to v3 Sponsored_Brands_Attributed_Purchases_report — 18 v3 columns mapped (with attribution-type restructured into metric variants)

Summary

This template replicates the v3 Sponsored Brands Attributed Purchases report on the Amazon Ads API v1 cross-product reporting endpoint (CreateReport). The grain is (date, campaign, purchased ASIN) with attribution split — but unlike v3 where 'Attribution type' is a row-level dimension, v1 encodes click-vs-view in metric variants, so the v1 layout is wider rows with click-only and total columns side-by-side.

Of the 18 v3 columns: 14 map cleanly to v1 fields, 1 is restructured (Attribution type → metric variants), and 3 are derived client-side (% of Sales NTB, % of Units NTB are derived; ACOS isn't applicable to this report).

The 17-field payload was validated against the packaged v1 catalog: zero unknown fields, zero missing required, zero incompatible pairs.

Why this report has the same constraints as SP Purchased Product

Like the SP Purchased Product report, this is a HALO-style report whose grain pins down the actual purchased ASIN (convertedProduct.id). v1's catalog explicitly marks metric.impressions, metric.clicks, and metric.totalCost as INCOMPATIBLE with the convertedProduct.* family — and that's why the v3 SB Attributed Purchases report omits Impressions/Clicks/Spend/CTR/CPC. v3 hid this constraint by giving you a sparse 18-column conversion-only report; v1 surfaces it via the validator.

This report's primary use case is decomposition: showing which Purchased ASINs an SB campaign drove sales for, and how much of that was new-to-brand. v1 covers this use case completely — but with one validator-detected restriction (the percent-of-sales NTB metric is blocked when grouping by purchased ASIN). The percent-of-purchases NTB variant survives, and the missing percentages are simple downstream divisions.

Layout difference: attribution type

In v3, 'Attribution type' is a column with values like 'Total' (all-attribution = click + view) and 'Click'. Each combination of (date, campaign, attribution type, purchased ASIN) is one row. So a single (date, campaign, ASIN) appears in TWO rows — one with the totals, one with the click-only numbers.

In v1 the same data is one wider row per (date, campaign, ASIN) with both metric.sales (total) and metric.salesFromClicks (click-only) populated together. This is the same shape v3 reports like SB Keyword and SB Search Term use for their click-only variants. It is generally cleaner for downstream warehouses — joins and pivots get simpler when click-vs-view is on the same row.

If your downstream consumers absolutely require the v3 long-format shape, rebuild it in the warehouse: take the v1 rows once with attribution_type 'Total' and col_value from sales, append them (UNION ALL) to the same rows with attribution_type 'Click' and col_value from salesFromClicks. Same for purchases and unitsSold.

Field list (grouped by role)

Time dimension (exactly one required)

• date.value

Level-of-detail dimensions

• campaign.id

• campaign.name

• campaign.currencyCode

• campaign.costType

• convertedProduct.id

• convertedProductMarketplace.value

Required supporting field

• budgetCurrency.value

All-attribution conversion (14-day)

• metric.sales

• metric.purchases

• metric.unitsSold

Click-only attribution variants

• metric.salesFromClicks

• metric.purchasesFromClicks

• metric.unitsSoldFromClicks

New-to-brand

• metric.newToBrandSales

• metric.newToBrandPurchases

• metric.newToBrandUnitsSold

• metric.percentOfPurchasesNewToBrand

Filter (limits the report to SB)

• adProduct.value = SPONSORED_BRANDS

v3 → v1 field mapping

Red row: Attribution type is restructured into metric variants. Yellow rows are derived client-side.

Critical differences from the v3 report

Operational notes

• Reproducing the v3 long-format attribution shape: UNION two SELECT statements over the v1 wide-format result. v3 'Total' = metric.sales; v3 'Click' = metric.salesFromClicks; v3 'View' (if present in your downstream consumers) = metric.sales − metric.salesFromClicks (or use metric.salesFromViews directly — also compatible with convertedProduct.id).

• Adding metric.salesFromViews / metric.purchasesFromViews / metric.unitsSoldFromViews: all three are compatible with convertedProduct.id and provide the view-only column directly. Add them if your warehouse prefers explicit view metrics over (total − clicks).

• Enriching with brand/category: convertedProduct.brand, convertedProduct.category, convertedProduct.subcategory, convertedProduct.parentProductId, convertedProduct.productGroup are all compatible with this metric set. Add convertedProduct.brand to roll halo purchases up by brand.

• Derivations: percentOfSalesNewToBrand = newToBrandSales / NULLIF(sales, 0); percentOfUnitsNewToBrand = newToBrandUnitsSold / NULLIF(unitsSold, 0). Persist raw inputs alongside the derived views.