Why we write every ad change down twice

Every material change we make to a client's Meta or Google account gets written down twice, in two different places, on purpose. The first is a change log: the mechanical fact of what happened. Which setting, what it was before, what it is now, and when it changed. No commentary, no reasoning, just the record.

The second is a decision log: why the change was proposed in the first place, what alternative was considered and rejected, what result we expected to see, and what would count as this change having failed. We keep these separate rather than merging them into one combined note, and that separation is the actual practice worth explaining, because it's a deliberate tradeoff, not an accident of tooling.

A change log answers 'what happened,' and it answers it fast. If someone needs to do a quick technical audit of an account, checking whether anyone touched a given campaign this week, a change log is exactly the right tool: scannable, mechanical, unambiguous. What it cannot tell you is whether the change was a good idea. A budget shift from one ad set to another is just a number moving in a change log. It says nothing about whether that move made sense.

A decision log answers 'why,' which is the question that actually matters when you're trying to learn from a result or explain a call to a client. But it's slower to write and slower to read, which makes it a bad tool for a fast technical scan. If you combine the two into a single note, you tend to end up with something that's mediocre at both jobs: too slow and narrative for a quick audit, too thin on reasoning to be useful when you actually need to understand why a decision was made. Keeping them apart lets each one stay good at the thing it's actually for.

The real value of the decision log isn't at the moment the change is made, it's when the change is reviewed afterward. Having the original expected outcome and reasoning recorded, rather than reconstructed from memory after the fact, makes it possible to honestly judge what actually happened: did the change work for the reason we expected it to, did it work by coincidence, or did it not work and should it be reversed.

That distinction is easy to get wrong if you're relying on memory, because hindsight quietly edits what you remember predicting. Once you know the outcome, it's remarkably easy to convince yourself you expected it all along, even when the honest answer is that you didn't, or that you expected something else entirely. A decision log written at the time of the change is the only reliable check against that. It's not there to make anyone look right later. It's there to make it possible to be honest about being wrong.

A client or a founder can ask 'why was this changed' months after the fact and get the actual original reasoning, not a plausible-sounding explanation invented on the spot to justify whatever ended up happening. That's a meaningfully different thing to hand someone. One is a record. The other is a story constructed after the fact to fit the outcome, however well-intentioned.

This matters more, not less, as more of the initial analysis behind a change is AI-assisted. A written decision log, captured at the time a change is proposed, is a check on whether the reasoning given at the time actually matches what gets presented later as the reasoning. That check only works if the log is written down before the outcome is known, which is exactly why we treat it as a separate, mandatory record rather than something reconstructed on demand.