If you run tests without a clear system, you usually end up with opinions instead of learning. Here’s the simple experiment tracking setup I use to keep ideas, results, and next steps in one place.
Most business owners do experiments already. They change a headline, test a new offer, post at a different time, or run a small ad campaign and hope something improves. The problem is not a lack of ideas. The problem is that most experiments are undocumented, inconsistent, and impossible to learn from later.
I have made that mistake myself. I would test something, see a small lift, then forget exactly what changed, how long it ran, or whether the result was real or just a lucky week. A simple tracking system fixes that. It does not need to be complex, expensive, or built by a data team. It just needs to help you answer one question: what did we try, and what happened?
Start with a single experiment log
The easiest system is one table. That is it. You can build it in a spreadsheet or in Notion if you want something a bit cleaner and easier to search later.
Your log should include these columns:
Experiment name
Date started
Date ended
Owner
Channel or page
Hypothesis
What changed
Primary metric
Secondary metric
Result
Confidence
Decision
Notes
That may sound like a lot, but each field forces clarity. If you cannot state the hypothesis in one sentence, the test is probably too vague. If you cannot choose a primary metric, you will be tempted to cherry-pick the best-looking number afterward.
A good experiment name might be: “Homepage CTA changed from Book a Demo to Get Pricing.” A bad one is: “Website update.” The first is specific enough that anyone can understand it three months later.
Write a hypothesis before you launch
This is the part most people skip, and it matters more than any fancy dashboard.
I like a simple formula:
If we change X, then Y will happen, because Z.
For example: “If we shorten the contact form from 7 fields to 3, then lead submissions will increase by 15%, because users on mobile will face less friction.”
Now you have a clear prediction. When the test ends, you are not judging it based on mood. You are comparing reality with the original expectation.
This also helps you avoid random activity. A surprising amount of marketing work looks productive but is really just uncontrolled tinkering.
Track only one main metric per test
You can watch several numbers, but every experiment needs one primary metric. Otherwise, you can always find a number that makes the test look successful.
If you are testing a landing page, your primary metric might be conversion rate. If you are testing email subject lines, it could be click rate. If you are testing product pricing, it might be revenue per visitor.
Secondary metrics are still useful. They help you catch side effects. For example, a pop-up might increase leads but also increase bounce rate. That does not automatically make it a bad idea, but you need the full picture.
I try to define success in advance. Not “better performance,” but something measurable like “increase quote requests from 2.8% to 3.5% over 14 days.”
Keep the system lightweight enough to use
A tracking system that feels heavy will die fast. I have seen businesses spend more time designing the tracking process than running experiments.
My advice is simple: make updating the log take less than five minutes. Use dropdowns where possible. Standardize status labels like Planned, Running, Completed, Won, Lost, and Inconclusive. Add a short notes field for context.
If you want, you can pair the log with a simple analytics tool like Fathom Analytics to monitor traffic and conversions without creating a reporting monster. The goal is not to build a data warehouse. The goal is to create a repeatable habit.
Use a simple review rhythm
Tracking matters, but review is where learning happens.
I recommend a weekly or biweekly review with three questions:
What did we test?
What did we learn?
What should we try next?
That is enough. You do not need a dramatic presentation. You just need to stop good lessons from disappearing into Slack, email, or memory.
One useful trick is to tag experiments by theme: pricing, homepage, checkout, email, offers, ads. After a few months, patterns start to appear. You may notice, for example, that offer-related tests outperform design tweaks almost every time. That kind of insight helps you invest effort more wisely.
A practical example
Let’s say a fictional Toulouse business, La Boulangerie du Capitole, wants more custom cake orders from its website. The owner suspects the order page is too vague.
They create an experiment:
Hypothesis: If we replace the generic “Contact us for cakes” section with a dedicated page showing cake sizes, starting prices, photos, and a clear order form, then cake inquiries will increase by 20%, because customers will have more confidence and less uncertainty.
Primary metric: cake order form submissions.
Secondary metric: page bounce rate.
Duration: 3 weeks.
At the end of the test, submissions rise from 18 to 26, and bounce rate drops slightly. The decision is “Win.” In the notes, they add that visitors spent longer on the pricing section and that photo quality probably helped too.
That one record becomes useful later. When they decide to improve catering orders for offices in Compans or events near Wilson, they can reuse the same thinking: reduce uncertainty, show pricing guidance, and make the next step obvious.
Know when a result is inconclusive
Not every test produces a clean answer. That is normal.
Sometimes traffic is too low. Sometimes you changed too many things at once. Sometimes seasonality gets in the way. An inconclusive result is not a failure if you document it honestly.
I usually use three possible outcomes:
Win: the primary metric improved enough to justify the change.
Loss: the change underperformed or created a negative side effect.
Inconclusive: not enough data or too much noise to trust the result.
This keeps the system honest. You are building a knowledge base, not a trophy cabinet.
Build for learning, not perfection
The best experiment tracking system is the one your team will actually use. Start with one table, one hypothesis format, one primary metric, and one short review meeting. That is enough to create discipline.
Over time, you can add things like screenshots, links to pages, or a template for writing post-test summaries. If you need a fast test page for an offer or campaign, a no-code tool like Framer can make that easier without turning the experiment into a long web project.
But keep the principle simple: every test should leave a trail. If six months from now you cannot explain what changed and what happened, then the experiment was mostly wasted.
A small, boring system beats a clever system nobody updates. That has been true in every business I have worked with.
