Key takeaways
- A test without a logged verdict of scale, kill or iterate is not finished, and its budget was mostly wasted.
- Six fields cover every experiment: hypothesis, design, result, verdict, reason, and reuse rules.
- A monthly experiment review with a maintained blocked list is the specific mechanism that stops teams re-running killed tests.
- Institutional knowledge that lives only in people's heads leaves when they do. A versioned log keeps it in the system.
- For agencies, the log must be scoped per client. Findings from one account do not automatically transfer to another.
Most ad experiments end the same way. The test runs, the data comes in, someone says "interesting" in Slack, and the thread gets buried. Three months later a new hire proposes the same test. Nobody remembers why it was killed the first time.
A structured experiment log fixes this. It is not a spreadsheet for its own sake. It is the difference between a team that compounds learning over time and a team that starts from scratch every quarter.
Why most experiments produce no usable knowledge
The problem is not that teams do not run tests. Most performance marketing teams run plenty. The problem is that the verdict never gets recorded in a form anyone can act on later.
A test without a verdict is just noise. You spent budget, you got data, and then the data sat in a platform report that nobody will open in six months. The learning exists in one person's head, and when that person goes on leave or resigns, the learning leaves with them.
Three things cause this consistently.
No hypothesis at the start. If you did not write down what you expected to happen and why, you cannot evaluate whether the result was meaningful or just variance. A result without a prior hypothesis is a data point, not an experiment.
No verdict at the end. Scale, kill, or iterate are the only three outcomes that matter. If the test closes without one of those three words attached to it, the experiment is not done.
No reuse rule. Even when a verdict exists, teams rarely record the conditions under which the finding applies. A creative that failed on a cold prospecting audience might work on retargeting. Without that note, the team either over-generalizes the kill or re-runs the test unnecessarily.
The six fields every experiment log entry needs
Keep the structure simple enough that filling it in takes under five minutes. Complexity is why logs get abandoned.
1. Hypothesis
One sentence. "We believe that [change] will produce [outcome] because [reason]." The reason is the important part. It forces the team to commit to a mechanism, not just a hope.
Example: "We believe that leading with a price anchor in the first three seconds of the video will increase purchase conversion rate among retargeting audiences because price sensitivity is the primary objection at that stage."
2. Design
What exactly ran. Audience, placement, budget, duration, the variable being isolated. If you changed two things at once, note it, because the result is uninterpretable for either variable individually.
Include the minimum detectable effect you needed to call a winner. If you did not have enough volume to reach statistical significance, say so. A test that was underpowered is not a clean kill.
3. Result
The numbers, plainly. Primary metric first, secondary metrics after. Include the confidence level if you have it. Do not editorialize here. Just the data.
4. Verdict
One word: scale, kill, or iterate.
- Scale means the result was significant, positive, and you are moving it into standard rotation or increasing spend.
- Kill means the hypothesis was wrong and this direction is closed.
- Iterate means the result was directionally interesting but the design needs adjustment before you can call it.
If you cannot assign one of these three, the test is not finished.
5. Reason
Two to four sentences explaining why you assigned that verdict. This is the field that prevents the team from re-running the test. "We killed this because CTR was flat but more importantly CPL was 40 percent above target across all three audience segments, including the one we expected to respond." That sentence saves someone three weeks of work in six months.
6. Reuse rules
Under what conditions does this finding apply, and under what conditions does it not. A kill on broad match in a low-budget account is not necessarily a kill on broad match in an account spending $80,000 a month. Write the scope explicitly.
How to run a monthly experiment review
The log only works if someone reads it. A monthly review, thirty minutes, prevents the two failure modes: re-running killed tests and forgetting to scale winners.
Before the meeting. Pull every experiment that closed in the last thirty days. Each one should have all six fields complete. If a field is missing, the person who ran the test fills it in before the meeting, not during.
During the meeting. Go through each closed experiment. Confirm the verdict. Flag any iterate verdicts that have been sitting for more than sixty days without a follow-up design. Those are experiments that stalled, and stalled experiments are just killed experiments with extra steps.
The carry-forward list. At the end of the review, produce a short list of findings that should influence active campaigns right now. Not every finding is immediately actionable, but some are. A creative insight from last month should be in the brief for next month's shoot.
The blocked list. Separately, maintain a list of directions that are closed. When someone proposes a new test, the first check is whether it is already on the blocked list. This is the specific mechanism that stops teams from re-running the test they killed in March.
The compounding problem that logs solve
A single experiment is worth the budget it cost. A hundred experiments with logged verdicts are worth multiples of that, because each new test can be designed against the accumulated evidence of what has already been ruled out.
Consider the alternative. A team that has been running paid media for two years without a log is effectively starting over every quarter. The institutional knowledge lives in the heads of the two or three people who have been there longest. When one of them leaves, a meaningful portion of the account's reasoning leaves with them. The new hire does not have access to the blocked list. They run the test that was killed in March. They get the same result. They kill it again. Nobody notices the repetition because there is no record of the first time.
This is not a hypothetical. Based on conversations with performance marketing teams, re-running killed experiments is one of the most common sources of wasted test budget, particularly in accounts with high turnover or heavy agency involvement.
Practical notes on tooling
The format of the log matters less than the discipline of filling it in. A shared Google Sheet with one row per experiment and the six fields as columns works. A Notion database works. A dedicated testing tool works if your team will actually use it.
What does not work is a Slack channel called #experiments where verdicts get posted as messages and then scroll out of view. Slack is where experiments get discussed. The log is where they get recorded.
If your team uses a project management tool for campaign work, attach the experiment log entry to the relevant campaign or project. That way the verdict is findable from the work it influenced, not just from a standalone document that requires someone to know it exists.
For agencies, the log needs to be scoped per client. A finding from a direct-to-consumer brand in the apparel category does not automatically transfer to a B2B software client. The reuse rules field should make this explicit, but the structure of the log should enforce it. One log per client, not one log for the agency.
Where Almond fits
The failure mode that a manual log tries to solve, context that disappears the moment someone leaves or a quarter turns over, is exactly what Almond's Business Context Engine is built around. Every experiment, verdict and decision gets captured continuously from the sources where your team actually works: ad platforms, Slack, meeting notes, and email. The context is versioned, so you can always answer what the team knew and when. And because it is prioritized by relevance and recency, the blocked list is not something you have to remember to check. It surfaces when it matters.
The Workflow Builder includes prebuilt Google and Meta automations that run on this context layer, which means an automation will not scale a campaign your team decided to sunset on Monday, and it will not propose the test you killed in March.
If you want to see how your current account history holds up, early access includes a detailed 1:1 audit with the CEO. Work email only at almond.ai.
Frequently asked questions
- What should an experiment log include for paid media tests?
- At minimum: a one-sentence hypothesis with a stated reason, the exact test design including audience and budget, the raw result, a verdict of scale, kill or iterate, a brief explanation of why, and reuse rules that define the conditions under which the finding applies. All six fields should be complete before the experiment is considered closed.
- How do you decide whether to scale, kill or iterate on an ad test?
- Scale when the result is statistically significant, positive on your primary metric, and the conditions are repeatable. Kill when the hypothesis was clearly wrong across the relevant audience segments. Iterate when the result is directionally interesting but the design had a flaw, was underpowered, or changed too many variables at once to isolate the finding.
- How often should a performance marketing team review its experiment log?
- Monthly is the minimum that prevents re-running killed tests. The review should confirm verdicts on closed experiments, flag iterate verdicts that have stalled beyond sixty days, produce a carry-forward list of findings that should influence active campaigns, and update the blocked list of directions that are closed.
- Why do marketing teams keep re-running the same experiments?
- Because the verdict from the first run was never recorded in a findable place. Most experiment outcomes live in Slack threads, platform reports, or one person's memory. When that person leaves or the thread scrolls out of view, the institutional knowledge disappears. A structured log with a blocked list is the specific fix for this.
- What is the best tool for tracking ad experiments?
- The format matters less than the discipline. A Google Sheet with one row per experiment and six defined fields works. Notion, Airtable, or a project management tool attached to campaign work also work. Slack channels do not work as a log because verdicts scroll out of view. The key requirement is that the log is searchable and scoped per client or account.
Almond 2.0 early access
Get a 1:1 Meta and Google audit with the CEO.
Every waitlist member gets a 1:1 audit of their ad accounts. Work email only.