How to Audit Amazon Ads Change History

Begin with a concrete symptom instead of opening the history tab and scanning everything. Name the advertiser, marketplace, campaign type, campaign or ad group, affected target or negative, observed time window, expected setting, current setting, and the business question. Examples include an unexpected budget, a bid that differs from an approved file, or a negative target that no longer appears. Capture the current screen and report inputs before editing so the investigation does not destroy the state it needs to explain.

Amazon states that Sponsored Products and Sponsored Brands change history can be viewed at individual campaign, ad-group, or all-campaign scope and can include campaign settings, targeting, and negative targeting. Choose the narrowest scope that contains the symptom, then widen only when the same actor or batch may have touched several entities. Use account and entity identifiers, not names alone, because names can be duplicated or changed. Record the console time zone and the investigator's time zone beside every timestamp.

Build a small evidence table with timestamp, entity ID, field, old value, new value, visible actor where available, approved ticket, source file or automation run, and review status. Normalize dates before sorting and keep raw exports unchanged. A campaign change can be valid but undocumented, documented but applied to the wrong entity, or correctly applied while a report still shows a different attribution window. Those are different defects. Do not label a change unauthorized until access and release records have been reviewed.

Amazon's campaign guidance separates campaign settings from ad-group products and targets, while the account-level Targeting page aggregates automatic, keyword, product, and audience targets. Use that hierarchy to interpret what the history row can actually explain. A campaign-level budget edit does not prove a target-level bid changed, and an account-level target view does not replace the entity's configuration record. Link every conclusion to the field and scope present in the source evidence rather than inferring a broader account change.

Align the change with complete reporting intervals, not the first chart movement that looks related. Record the edit time, campaign eligibility, moderation or launch state where relevant, reporting freshness, attribution window, inventory status, retail price, featured-offer status, and other known concurrent changes. A before-and-after chart can generate a hypothesis, but it cannot isolate one cause when several inputs moved. Keep the language factual: the setting changed before the metric changed, or the windows overlap, rather than saying the edit produced the result.

Use consistent comparison windows and preserve the untouched baseline. If a budget changed during a day, label that day mixed rather than treating it as a clean before or after period. If the account spans marketplaces, analyze each marketplace with its own currency, time zone, availability, and campaign settings. Amazon's guidance notes that global campaigns still allow country-level customization, which makes a single global name insufficient evidence of identical configuration. Hold conclusions when the required history or complete reporting window is unavailable.

Read the live campaign, ad group, target, negative, product, budget, dates, and bidding settings against the approved desired state. Check whether a later legitimate change superseded the row under investigation. If automation or a bulk upload participates, compare its current rule and last successful input. Never restore an old value merely because it appears earlier in history. The correct rollback target must be explicit, applicable to the current campaign structure, and approved by the owner of the business objective.

Test the proposed correction in a draft, paused copy, or narrow canary where the console supports it. Verify the saved value, eligibility state, and resulting history entry before expanding. Amazon notes that copied campaigns do not necessarily carry performance history, so a copy is a configuration test rather than a performance continuation. Document the rollback trigger, operator, time, entity IDs, new history row, and verification result. If the console cannot express the desired state, keep the affected scope paused and escalate through the supported account channel.

Schedule history reviews around high-risk launches, bulk changes, access changes, and unexplained configuration drift. Sample high-spend entities and a rotating long tail. Track undocumented valid edits, wrong-scope edits, failed uploads, duplicate automation actions, stale negatives, and unresolved rows separately. The count of history entries is not a quality metric. A quiet account can still be wrong, while a heavily optimized account can have many approved edits. Measure whether every material change has an owner, reason, evidence, and verification.

Close an investigation with one supported disposition: approved change, configuration defect repaired, report-timing mismatch, access question escalated, or insufficient evidence. Preserve the original question, source URLs, export fingerprints, relevant rows, decision, and reviewer. Do not report savings, lost sales, or causal impact unless account evidence supports those values. The operational outcome is traceability: another reviewer can reconstruct what changed and why without relying on memory, renamed campaigns, or screenshots detached from their entity IDs.