
Campaign Audits
Part of Programmatic campaign optimisation
Recording the effect of a trader's optimisation change
Log a trader's reason, saved setting and baseline, then review delivery and mature outcomes without claiming false causality.
Record a trader's optimisation change with the decision, a baseline, the saved setting and a later outcome review. Platform history shows what was edited; a performance chart beside that edit cannot, on its own, establish what it caused.
Write the decision before editing
State the problem and expected mechanism. For example: “Eligible bids for this approved inventory appear to lose on price; a bounded bid increase should improve wins while keeping cost per qualified enquiry within the agreed limit.” This is an illustrative hypothesis, not a campaign finding.
Record affected campaign, insertion-order and line-item IDs; previous and proposed values; authorised range; owner; reason. Add deal, audience or creative IDs when they define the change. Name the reporting time zone and planned edit time, particularly when trader and advertiser daily cut-offs differ.
Save a baseline report for a defined period before editing. Keep spend, delivery, the primary outcome and the denominators behind rates. Record the event definition, attribution settings, cost basis and extraction time so another reader can reconstruct the comparison.
Record the saved and observed change
After saving, inspect the setting and record its value and save time. Check later delivery for the first evidence of effect; do not assume the save time is the exact effective serving time.
Note concurrent manual and system changes. Record any relevant platform-history entries alongside the edit.
Field / Entry to make
- Decision
- Problem, hypothesis and expected direction
- Scope
- Exact IDs and inventory or audience affected
- Setting
- Previous value, saved value, save time and observed delivery change
- Baseline
- Report dates, extraction time, spend, delivery and outcome
- Concurrent events
- Creative, page, tracking, budget or platform changes
- Review
- Date, success measure, guardrail and decision owner
Keep the reason and decision in a shared record alongside the platform history.
Before vs After: Key Metrics for Evaluation
- Cost per Qualified Enquiry (CPQE)
- Baseline: $A | Post-change: $B
- Win Rate (%)
- Baseline: C% | Post-change: D%
- Attribution Setting
- Last-click (default)
Review without overclaiming
Choose a later period that is reasonably comparable in weekday pattern, market, inventory and measurement definition. Allow for customer action and reporting delay. Check the platform's data freshness guidance and treat recent reports as provisional.
Check the proposed mechanism first. If the edit was meant to address auction loss, did the available bid and win evidence move in the expected direction? Then assess cost, placement mix and sufficiently mature outcomes. A bid can increase wins while reducing efficiency.
List material alternative explanations, such as a simultaneous creative change, supply shift, offer ending, site fault or event update. When several conditions changed, report the observation and its uncertainty. A controlled experiment can support a stronger causal assessment when its design and eligibility fit the question; a routine before-and-after log is not one.
Close the entry as keep, revise, reverse or inconclusive, with the evidence and next review date. An inconclusive record prevents an unverified change from becoming a claimed success.


