Sponsored Products Search Term Report Grain

A Sponsored Products search term report grain mismatch can inflate campaign spend: joining one campaign total to several search-term rows repeats that total. Aggregate each report separately to the same scoped campaign-and-day key, check uniqueness, then compare. Kuudo’s Reporting Skill supplies the field-validation workflow; the agent performs the reconciliation.

Your team’s daily dashboard may group by campaign while its search-term review keeps ad groups and individual queries. Those choices belong in the comparison, along with your account, marketplace, and currency. The Amazon Ads Reporting Skill makes the requested dimensions explicit so an agent can distinguish duplicated campaign spend from a genuine reporting difference.

The practical question is: “Why did my campaign total grow after I joined the search-term report?” Start with the join. A reporting discrepancy and a duplicated metric require different repairs.

A report’s grain is the meaning of one row

Report grain is the complete set of dimensions that identifies a row, including its time unit. A campaign total for a day is coarser than separate search-term rows within that campaign. The Explorer recipe analyzes daily rows by campaign, ad group, and search term within the resolved account scope. Adding target, placement, or another dimension changes the row contract again; verify actual uniqueness rather than treating that tuple as a universal server key.

Use Amazon Ads MCP to retrieve the authorized account’s reports, with the Reporting Skill’s ad-hoc workflow defining the intended grain first. The Skill checks current field definitions and compatibility rather than assuming that a familiar report name establishes the dimensions.

Use IDs for relationships; retain names for readers. A renamed campaign should not become a new campaign in the comparison. If one report is daily and the other summarizes the whole period, regenerate or aggregate to a shared time grain before comparing them.

Joining finer rows can multiply campaign spend

A campaign metric repeats when one campaign row matches several search-term rows. Summing the repeated campaign column inflates the total even though neither source report changed. This is join fan-out: the relationship adds rows, and a subsequent sum counts the same coarser metric again.

Consider this illustrative single-account, single-marketplace, USD example for one day. Campaign A has $100 of spend. Its search-term report contains two rows, with $60 and $40 of spend.

The campaign did not spend $200. The join copied its $100 onto two rows. Keeping a campaign-total column on detailed rows can be useful for context, but that column is no longer additive across those rows.

The Reporting Skill explicitly requires a split-report workflow to state whether its join repeats coarser metrics. For a reconciliation, instruct the agent to aggregate each report independently to account, marketplace, currency, campaign ID, and day. Then require one row per comparison key on each side before joining. Additional scope needed to distinguish your accounts belongs in the key too.

Apply three checks before accepting the comparison:

• Compare source totals with aggregated totals before the join and corresponding columns afterward.
• If the intended key is not unique, inspect remaining dimensions or duplicate inputs.
• Preserve real activity: dropping duplicate-looking rows without understanding their grain can discard it.

Recompute rates from additive totals rather than averaging row percentages:

• Cost per click is total cost divided by total clicks.
• Advertising cost of sales (ACoS) is total cost divided by total sales.
• A zero denominator makes the rate unavailable.
• Budgets, rates, and amounts in different currencies are not additive.

Matching grain does not make every metric equal

The Sponsored Products search-term report covers terms associated with at least one ad click. Amazon states that its impression totals can therefore differ from Campaign Manager. A unique, correctly aggregated join cannot restore impressions excluded by the report’s scope. Amazon’s search-term documentation also notes inferred terms in some non-search contexts and ASIN-valued entries.

Amazon Agent Atlas grounds that distinction in Amazon’s report guidance. The agent should classify the remaining difference rather than force a match: first coverage and filters, then metric definitions and attribution, then report timing. Use Amazon’s campaign-report reference to check the selected grouping, not as a substitute for the current v1 field contract.

For monetary comparisons, ask the agent to confirm:

• The same currency and sales scope.
• The attribution basis, separately from the calendar date range.
• Any unknown attribution; an unsuffixed sales field does not establish a window.

Amazon’s attribution guidance explains that conversions can arrive later and a report date remains incomplete until its lookback window ends. Reports retrieved at different times may consequently disagree even when the join is sound. Record retrieval times and rerun comparable periods before treating the residual as an error.

A reconciliation report needs a validated field contract

The reconciliation deliverable is an analysis report with source totals, duplicate-key findings, aligned totals, and explained or unresolved differences. The Amazon Ads Reporting Skill supplies the ad-hoc reporting method; the reconciliation checks below are the agent request, rather than a named, bundled Sponsored Products reconciliation template.

The documented v1 search-term field set includes date.value, campaign.id, campaign.name, adGroup.id, adGroup.name, searchTerm.value, metric.impressions, metric.clicks, metric.totalCost, metric.sales, metric.purchases, and budgetCurrency.value. Cost and currency belong together. Validate the entire selected set for the comparison’s current reporting path, including the campaign-side fields; do not substitute legacy Console headers or assume a v3 field name works in v1.

With the Reporting Skill installed and Amazon Ads MCP connected, use this request:

Reconcile my Sponsored Products search-term and campaign reports.
Confirm the advertiser account, marketplace, currency, dates,
metrics, attribution basis, filters, and time grain with me.
Use the Reporting Skill's ad-hoc path and validate the fields.
Retain report IDs, retrieval times, and source totals.
Aggregate each report separately to the same campaign/day key,
including account, marketplace, currency, and other required scope.
Check key uniqueness before joining. Preserve unmatched rows.
Return source totals, aligned totals, duplicate-key findings,
and residual differences with their evidence or unresolved cause.
Do not change campaigns, budgets, bids, or targets.

Report creation starts an asynchronous read job. The agent checks its status through MCP; the client downloads the completed file from the returned signed URL. Access, compatible fields, and a client able to download and process the report are prerequisites. This guide documents the workflow; it does not report a customer-account execution.

What happens next: approve the comparison before mining terms

Review the reconciliation report before trusting search-term recommendations. Resolve fan-out first. Keep coverage differences and uncertain attribution visible. Only then move to the search-term mining workflow, whose Explorer Skill aggregates and segments terms for candidate review rather than performing this campaign reconciliation.

Retain the accepted grain contract and reports in the Amazon Agent Data layer. Reuse your comparison rules through Skills so the next review tests the same boundaries. Selling Partner MCP supplies seller-side operational and eligible reporting data; that is a different data context from these paid Sponsored Products reports.

Next, turn reconciled data into search-term candidates you can trace to their evidence.