Marketing campaign post mortem: a blameless method built on the change timeline

What is a marketing campaign post mortem?

A marketing campaign post mortem is a short document written after something went wrong in a campaign: conversions fell, spend ran over, leads stopped or tracking broke. It explains what happened, what it cost, why it happened and what will change so it doesn't happen again.

The format comes from site reliability engineering. Google's SRE book describes a postmortem as a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root causes and the follow-up actions that prevent it from recurring. Marketing teams can borrow the structure almost unchanged, because ad accounts, tags and websites fail in a similar way: someone ships a change, something downstream breaks, and nobody connects the two for days.

A post mortem is not the same as a campaign retrospective. A retrospective reviews a whole campaign once it ends: what worked, what to repeat, what to drop. A post mortem looks at one incident and its cause. Both are useful; this article covers the incident review. For the wider diagnosis method behind it, see marketing root cause analysis.

When should you run a campaign post mortem?

Run one when an incident crosses a threshold you agreed on in advance, not when someone is upset. Google's SRE book recommends defining post mortem triggers before incidents happen and gives examples such as user-visible degradation beyond a threshold, data loss, a rollback, a resolution time above a threshold and a monitoring failure, where the incident was found by hand.

Translated to marketing, sensible triggers are:

• Performance: a key metric (conversions, leads, ROAS, CPA) moves beyond an agreed range for two or more days without a planned reason.
• Money: spend runs over the agreed budget, or budget goes to traffic you never meant to buy.
• Data: conversions were lost, double-counted or misattributed for any period.
• Rollback: a change had to be reverted, such as a landing page, a bid strategy or a tag container version.
• Detection: the client or your boss noticed the problem before the team did.

Atlassian, for example, writes post mortems for its severity 1 and 2 incidents and treats them as optional for the rest. A similar two-level rule works for agencies and in-house teams: required for incidents a client noticed or that cost money, optional for the rest. Any stakeholder should be able to ask for one.

What should a marketing post mortem template include?

Keep the template short enough that people fill it in. Atlassian's incident template covers summary, lead-up, fault, impact, detection, response, recovery, timeline, five whys, root cause, recurrence, lessons learned and corrective actions. For a campaign incident, these fields are enough:

The change timeline is the field most teams skip and the one that decides whether the review is worth anything. Without it, the root cause is a guess dressed up as a finding. If you don't keep a record of changes yet, start with a marketing change log template and fill it in for the two weeks before the incident.

How do I prove which change caused the incident?

Line up every change from the days before the metric moved, rule out tracking first, then test one hypothesis at a time. Atlassian's blameless guidance makes the same point: agree on a shared timeline of what actually happened before you analyse causes.

Collect changes from every source, not only the ad account:

• Edits your team made in Google Ads and Meta Ads: budgets, bid targets, audiences, creatives.
• Platform automations: auto-applied recommendations, automated rules, scripts.
• Website releases, landing page and checkout changes.
• Tracking: Google Tag Manager versions, consent banner updates, conversion action edits.
• CRM and product changes, plus external events such as holidays or outages.

In Google Ads, open "Change history" in the Campaigns menu. It covers the past 2 years and shows the user who made each change, with automated changes listed under names such as "Google Ads system". For tags, the GTM version history shows who published which version. The Google Ads change history guide explains the filters.

With every change on one timeline, the incident usually stops being a mystery: you see that a tag was published the evening before conversions fell, and that the bid target moved the day before that. In Changeline, Google Ads edits can be imported automatically with before → after values and their source, and the team logs everything else on the same project timeline.

Example: on Monday a client asks, "Why did Google Ads purchases fall 40% over the weekend?" The team lines up the changes from the previous days. Thursday: target ROAS raised from 400% to 500%. Friday: a new checkout goes live and a GTM version is published. Saturday: purchases drop. A test shows the purchase tag no longer fires on the new confirmation page, so tracking explains the drop. The ROAS change goes into the review as a factor to watch once data is back. Names and numbers are illustrative.

To prove the cause rather than assume it, check three things: the timing fits (the metric moved after the change, not before), the scope matches (only the campaigns, pages or devices the change touched moved) and, where possible, fixing or reverting the change brings the metric back.

How do I run a blameless post mortem meeting?

Focus the meeting on the system, not on the person who made the change. Google's SRE book puts it plainly: "You can't 'fix' people, but you can fix systems and processes." The person who raised the bid target or published the tag acted on the information they had; the useful question is why the process let the change go live unchecked.

A 30-minute agenda that works for most campaign incidents:

1. Agree on the timeline
2. Confirm impact and detection
3. Ask why five times
4. Agree actions and owners

Start with the timeline because it removes most of the disagreement: once everyone sees the same dated changes, the discussion moves from opinions to evidence. Then use the five whys: start from the impact and keep asking why until you reach something that, if changed, stops this kind of incident. Atlassian defines the root cause as "the thing that needs to change in order to stop this class of incident from recurring". "The analyst forgot to test the tag" is not a root cause; "tag changes go live without a test on the conversion page" is.

Invite the people who made the changes and the account owner. If a client noticed the incident, send them a short written summary afterwards instead of bringing them into the internal discussion. The guide to explaining a conversion drop to a client covers that message.

How do I turn post mortem findings into actions that stick?

Give every action an owner, a due date and a place where it is tracked, and review open actions at the next team meeting. Atlassian tracks each action as a work item in the owning team's backlog, separates priority actions (which fix the root cause) from improvement actions, and sets a completion target of 4 or 8 weeks for priority actions, depending on the service.

Good marketing actions are specific and bounded, for example:

Store finished post mortems where the team will find them, next to the change log for that client. Google's SRE book warns that "an unreviewed postmortem might as well never have existed", and the same applies to one nobody can find. Over a year, the collection shows which kinds of changes cause most of your incidents, which is the best input for your change process. A marketing change log is the natural home for both. On Changeline's paid plans, the change report turns any period into a PDF of the changes logged or imported, which you can attach to the review.