A checklist should prevent expensive mistakes, not create ceremonial compliance

Campaign launches fail in surprisingly ordinary ways.

The wrong country remains selected.

A conversion event fires twice.

The final URL points to an expired promotion.

A new campaign is created under an automated rule that immediately changes its budget.

A product feed contains the wrong price.

A test launches without a documented hypothesis, and three weeks later nobody can explain what was being tested.

None of these failures requires a sophisticated algorithm.

They require operational discipline.

This checklist is designed as a preflight system for professional paid media teams. It covers business constraints, measurement, campaign configuration, creative, landing pages, feeds, automation, experimentation, launch-day monitoring and post-launch documentation.

The key design choice is severity.

Not every unchecked item should block a launch.

A missing naming label is not equivalent to a broken purchase event.

The workbook uses four severity levels

P0 — Launch blocker.
The issue can create material financial, measurement, compliance or customer-experience damage.

Examples: wrong geography, broken conversion tracking, duplicated purchase event, checkout failure, unapproved legal claim.

P1 — Resolve before launch unless explicitly accepted.
The campaign can technically launch, but the issue creates meaningful operating risk.

Examples: missing audience-control documentation, incomplete UTM preservation, unreviewed account-level exclusions.

P2 — Near-term backlog.
Important for quality, but it does not normally justify stopping a clean launch.

P3 — Hygiene.
Documentation and maintenance items.

This is deliberately different from a generic checklist that gives every row the same checkbox.

Operational risk is not democratic.

Why severity matters

Imagine a campaign with 39 of 40 checks complete.

That sounds excellent.

If the one missing item is “test conversion reaches ad platform,” the launch is not 97.5% ready.

It is blocked.

The workbook’s Summary sheet therefore counts unresolved P0 and P1 checks separately and produces a launch state:

BLOCKED, CONDITIONAL or READY.

This is a simple mechanism with a useful consequence: completion percentage cannot hide a critical defect.

Start with business QA, not platform QA

The first checks occur before the campaign is built.

The team should document:

  • primary business objective;
  • primary KPI;
  • allowable CAC or ROAS threshold;
  • budget owner;
  • maximum spend;
  • conversion action;
  • conversion-value logic.

This catches a subtle but common problem: a campaign can be technically flawless and economically undefined.

If nobody knows the maximum acceptable CAC, “optimize performance” is not an actionable operating instruction.

If finance expects new-customer acquisition and the campaign optimizes all purchases equally, the setup can be correct in-platform and wrong for the business.

Measurement is a launch dependency

Tracking is often tested near the end.

It should be specified near the beginning.

The checklist requires explicit checks for:

  • primary conversion action;
  • event/transaction ID;
  • deduplication;
  • value and currency;
  • browser/server relationship;
  • consent;
  • test conversion reaching analytics;
  • test conversion reaching the ad platform.

Analytics Mania’s GTM readiness checklist is a useful benchmark because it treats planning, data layer, tags, ecommerce and server-side implementation as parts of one QA process. Optmyzr and Adalysis likewise maintain extensive account-audit systems covering conversion tracking and structural errors.

Those sources are educational/vendor references. The Radar checklist is intentionally broader because campaign launch risk extends beyond the ad account.

Creative QA should validate the promise

Creative approval is not only checking aspect ratio.

The team should verify:

  • the promise matches the landing page;
  • claims are defensible;
  • legal language is present;
  • product shown is available;
  • geographic restrictions make sense;
  • asset variants are actually the intended production files.

A beautiful ad that promises something the landing page cannot deliver is a conversion-rate problem and a trust problem.

The checklist therefore treats destination consistency as a critical check.

Landing-page QA is financial QA

A media buyer may not own the site.

They still need evidence that the conversion path works.

For a high-spend launch, test:

  • desktop load;
  • mobile load;
  • form submission or checkout;
  • promo code;
  • price;
  • shipping logic;
  • UTM preservation;
  • click identifiers where relevant;
  • post-purchase confirmation.

A campaign that launches into a broken form can spend thousands before a dashboard catches it.

The launch process should discover the problem with a controlled test transaction.

Feed QA requires business context

For Shopping, PMax, retail media and catalog-based paid social, feeds are part of launch readiness.

Check:

  • price;
  • availability;
  • product identifiers;
  • product-to-landing-page mapping;
  • category/custom-label logic;
  • promotion status.

A feed can be accepted and still be commercially wrong.

If a campaign is supposed to promote high-margin inventory and the custom-label logic is wrong, platform diagnostics may not flag anything.

That is why the checklist includes both technical and business QA.

Automation can conflict with the launch

Modern accounts contain invisible actors.

Rules, scripts, portfolio strategies and third-party automation can modify a newly launched campaign.

Before activation, ask:

  • Which rules apply?
  • Which scripts scan this account?
  • Is a third-party optimizer connected?
  • Are automated recommendations allowed to apply?
  • Can a campaign inherit an unexpected budget or bid behavior?
  • Is another system pacing spend?

This is an increasingly important failure mode.

The campaign that was approved at 09:00 may not be the campaign that exists at 14:00.

Experiments need QA too

A campaign can launch successfully and produce an unusable experiment.

Before a test begins, document:

  • hypothesis;
  • treatment;
  • control;
  • primary KPI;
  • success threshold;
  • minimum run condition;
  • contamination risk.

Without those, the team can end the test by looking for the metric that makes the result look favorable.

The checklist treats experiment design as part of launch readiness because weak experiment setup wastes budget even when campaign delivery works perfectly.

Evidence is more valuable than “done”

For P0 and P1 checks, attach evidence.

Examples:

  • screenshot of geography;
  • test transaction ID;
  • preview URL;
  • tracking debug evidence;
  • legal approval;
  • feed diagnostic;
  • experiment spec.

A checklist row marked “Passed” by the same person who configured it is weaker than a check with inspectable evidence.

The objective is not bureaucracy.

It is reducing dependence on memory.

Launch day is part of the checklist

The workbook includes launch-day and post-launch phases because preflight cannot catch everything.

Monitor immediately after activation:

  • spend pacing;
  • disapprovals;
  • landing-page availability;
  • conversion signal volume.

Then run a 24-hour anomaly review and a 72-hour diagnostic review.

The first review asks: Is something broken?

The second asks: Is the system behaving plausibly?

Do not make major strategic judgments from a few hours of data unless the failure is obvious.

Failure mode: automating the entire checklist

Vendors such as Optmyzr and Adalysis can automate many account-health checks and run them continuously. That is valuable, especially across many accounts.

It should not eliminate human preflight.

Software can detect that a campaign targets all countries.

It may not know that the global launch is intentional.

Software can identify a tracking anomaly.

It may not know which event finance has designated as authoritative.

Automate deterministic checks.

Keep business interpretation explicit.

Failure mode: too many checks

A 300-row checklist can become less safe than a 40-row one if operators mechanically click through it.

The checklist included here is intentionally compact enough to operate.

Add checks when your organization repeatedly experiences a failure that the current process did not prevent.

Remove checks that no longer represent meaningful risk.

The checklist should evolve from incidents.

Download the checklist

The workbook includes:

  • the full preflight checklist;
  • severity dropdowns;
  • owner and status fields;
  • evidence field;
  • due date;
  • launch-readiness summary.

Use it as a controlled launch gate.

A professional team should be able to answer, before a campaign starts:

What can still go wrong, who owns it, and what evidence says we are ready?

Download the Campaign Launch & QA Checklist (XLSX)

More from Radar