Without a record, every experiment is forgotten, and the same mistakes repeat with new people. A simple experiment log, with hypothesis, result and decision, turns trial and error into reusable knowledge and speeds up improvement in any account.
The essentials in a definition
An experiment log is a shared document where each test is described: hypothesis, design, metric, duration, result and decision. It avoids repeating tests, preserves team memory and turns trial and error into knowledge. It follows the logic of measuring and reviewing that NIST recommends in risk management, and depends on reliable measurement for results to count.
The cost of not recording
When someone leaves the team, they take with them what they learned. When an experiment fails and nobody records it, someone else repeats it. When an experiment works but nobody knows why, it cannot be replicated.
The result is an account that does not accumulate learning, only history.
What to record
Date, hypothesis (“if we do X, we expect Y because Z”), what was changed, success metric, duration, result, decision (keep, reject, refine) and ideas for the next step. If there is relevant context (promotion, site failure), add it.
One line per experiment is enough. Consistency matters more than detail.
A reusable experiment log
- Write the hypothesis before testing
- Record metric, duration and result
- Decide: keep, reject or refine
- Consult the log before each new test
Where and how
In a shared spreadsheet, a document or a management tool. The essentials are that it is accessible, searchable and up to date. Assign an owner. Review the log in monthly and quarterly meetings.
Tag experiments by theme (creatives, audiences, structure, measurement), to find patterns.
An account learns when the team remembers what it tested.
How to benefit
Before testing, consult the log so as not to repeat. When planning, use failed hypotheses as clues. When onboarding someone new, the log is the best training. Periodically summarise the main lessons in a short document.
Share what you learned with decision-makers: it demonstrates value and justifies budget for tests.
Decision table
| Field | What to record | Example |
|---|---|---|
| Hypothesis | What is believed and why | A question hook raises retention |
| Design | What changes, where and for how long | Two hooks, same audience, two weeks |
| Result | Numbers, effect and uncertainty | Retention +12%, but within variation |
| Decision and lesson | What is done and what was learned | Repeat with larger audiences |
Common mistakes to avoid
- Recording only wins. Failures teach as much as successes.
- Records without context. Without date, audiences and conditions, they cannot be reused.
- A document nobody consults. Build consultation into test planning.
How to measure the result
Count tests completed per quarter, the percentage with a decision taken and time between idea and decision, and check that records are consulted.
Limits and exceptions
A log is only useful if kept and consulted, and can become bureaucratic if it demands too much. A test’s results may not apply in another context, so include the conditions. Do not confuse a record with a guarantee: what worked once may not work again. Review the log periodically and remove what is outdated.
Illustrative example
Illustrative example: a team keeps a sheet with all tests of the past two years. When planning a campaign, it sees a similar test already failed for lack of volume. Instead of repeating, it proposes a variation with a bigger change. It saves budget, and the new test gives a clear conclusion, which is recorded for the future.
In practice: checkpoints
Record each experiment with the date, hypothesis, change, result and decision in one shared sheet, and mark the ones that should be repeated. Review the log monthly and before planning any new test, so the team stops paying twice for the same lesson.
Frequently asked questions
How much detail should I record?
Enough for someone else to understand what was done and why. One line per experiment already helps.
Which tool should I use?
A shared spreadsheet will do. What matters is keeping the habit.
Does recording failures make sense?
Yes. They avoid repeated mistakes and show what does not work.
Which tool should I use?
A spreadsheet or shared document is enough; what matters is the habit and consistency.
Who should fill it in?
Whoever designs the test, with review by another person on completion.
An experiment log (hypothesis, design, result, decision and lesson) turns trial and error into reusable knowledge and avoids repeating tests.
Sources and recommended reading
Last editorial review: October 2026. Informational content; always confirm current conditions in the official sources before deciding.