Digital marketing

A year of changes, no test: the log that makes them readable

Without the volume to test, the one thing that turns modifications into decisions is a dated register, kept at the moment of the change.

Published on 13 June 2026 — Algeria Agency

The article accompanying this one shows that most Algerian sites do not have the traffic to conclude anything from an A/B test. It shows it well, and then leaves the reader in front of a question it does not quite have room to treat: how does one decide, then?

The answer is a file. Not a tool, not a platform: one line per change, with its date. It is the only instrument available at this volume, and it is better than its reputation.

Be clear about what it is. It is not a cut-price test and it does not answer a test’s question. It never says "this version wins"; it says "here is what we did, when, and what happened next" — and that sentence is one no measurement tool will ever say for you.

This article describes the shape of the line, the moment it is written, how to read a year, and — most importantly — the three things this register will not prove, so that nobody makes it say more than it holds.

The log is not a cut-price test

The temptation is to present the register as the poor version of a test, for those without the traffic. That is a category error, and it leads to using it badly.

A test answers a narrow question: is this gap between two versions real or due to chance. It answers nothing else, and the companion article insists on that more than it insists on volume.

The register answers a different and wider question: what have we done to this site, in what order, and what moved around it. No test answers that one, including on a high-traffic site.

Large companies therefore keep both. They test what can be tested and log everything, because without the second document they could not interpret the measurements sitting between two tests.

The practical consequence is that a business without volume is not deprived of method. It is deprived of one method and holds the other — the less prestigious of the two, the one nobody makes a slide about, and the one that goes on being useful for years.

What a line holds, and what it does not

Five columns: the date, the page, what changed, who did it, and one sentence of reason. Nothing more. A twelve-column register is not more rigorous; it is simply abandoned after six weeks.

The "who" column surprises people and it earns its place. Eighteen months later the only way to get the context of a line is to ask the person who wrote it, so you have to know which person that was.

The reason is written in one line and in the past tense: "because three customers had asked the price by message." It does not have to be a good reason, it has to be a true one. A weak reason written honestly is worth more than a justification reconstructed afterwards.

What the line does not hold, deliberately, is what you expected the change to do. That is a considered divergence from the article in this same series on trialling a channel, where the conclusion is written before the spend because nothing will produce it afterwards.

Here the situation is reversed: the site is yours, the measurement exists, and a prediction column would do precisely the damage one wants to avoid. It turns every line into a bet to be won, and a register you want to have been right in is a register you stop feeding the day you are wrong.

It is written at the moment of the change, never after

This is the one rule of upkeep that decides the document’s value, and it is the one never respected.

A register filled in on Friday for the week just gone already contains date errors. Filled in at the end of the month, it holds only the changes somebody remembers — the large ones — and the small ones are precisely what you will be looking for in a year.

Reconstruction does not work, and it is not a question of discipline. Nobody recalls whether the form was shortened before or after the photograph was swapped, and the order is the information.

The practical constraint is therefore that writing must cost under thirty seconds, or it is deferred and then forgotten. A shared file kept permanently open, or a notebook beside the screen: sophistication of the medium is here the enemy of keeping it.

One simple way to get there: the line is written before the modification rather than after. The change does not count as done until it is recorded, exactly like a stock movement.

Reading a drop: the first question is a date

The moment the register repays its cost is always the same one: the numbers fall and nobody knows why.

Without a register the discussion runs off in three directions within ten minutes — competitors, the season, the algorithm — and none of those hypotheses is checkable. They are therefore settled by whoever speaks loudest.

With a register the first question is mechanical: what did we change in the three weeks before the drop? Most often the answer is there, and it is small. A form lengthened by one field. A photograph replaced by a heavier one. A price removed.

When the answer is not there the information is just as useful and far rarer: the cause is external. You then stop searching inside the site, which is the principal waste of a week of that kind.

Note that the register only gives that answer if the small lines are in it. That is why the previous section insists so much on the moment of writing: March’s drop is explained by a February line nobody would have judged worth noting.

One change at a time

The discipline is well known and usually badly argued, which is what makes it easy to abandon.

The bad reason is statistical: "otherwise we will not know which one worked." It is true and it convinces nobody, because at this volume you will not know that with certainty either way.

The good reason is documentary. Two changes on the same day produce a register line that is unusable for ever, whereas two changes three weeks apart produce two lines that are still legible eighteen months later.

This differs from the single-lever rule the article on steering an advertising campaign defends, and the difference is worth stating. There the system relearns after every edit and the waiting is a property of the machine. Here nothing relearns: the discipline exists only so the document stays readable.

There is one accepted exception: the queue of obvious corrections the companion article describes — absent price, unclickable number, slow page. Those are not hypotheses but omissions, and they are all corrected on the same day, in one register line that lists them.

What the log will never prove

Three things, and they have to be said before somebody makes the document say more than it holds.

It does not prove causation. A rise after a change remains a possible coincidence, and on a small volume it often is one. The register establishes a chronology, which is necessary to an explanation and is never one.

It does not measure a magnitude. "Conversion went from three to four per cent" means nothing at a few dozen visits a day, for the reason the companion article develops in detail. The register tells you what to look at, not what a gain was worth.

It does not settle a choice between two options. If you have to choose between two wordings and the decision is reversible, the register will not help: take one, record it, move on. The cost of a long deliberation here exceeds the cost of being wrong.

These three limits are not weaknesses to be excused. A document whose reach is exactly known can be used in a meeting; a document whose reach is exaggerated is turned against you the first time somebody reads the same chronology differently.

The calendar overwhelms almost everything

The season produces swings in these figures larger than nearly every modification you will make, and it is the leading cause of a false conclusion.

Ramadan, Eid, the return to school, the summer holidays, the ends of months: each of those moments moves both traffic and intent, and a modification made near one inherits its effect.

The consequence is the most useful reading rule in this article: do not compare a month with the month before, compare a month with the same month a year earlier. Which presupposes a year of register, and is why the document only becomes genuinely useful from the thirteenth month.

Until then the register still serves — for March’s drop, and for memory — but it does not yet allow the comparison that matters. That has to be said at the outset, or it is abandoned in the sixth month as a disappointment.

So add your own commercial dates to the register as entries in their own right: a clearance, a closure, a three-week stock-out. These are events that explain curves, exactly as a page change does.

The changes you did not make

A register holding only your own modifications attributes everything that happens to your own modifications, which is this document’s most persistent illusion.

The outside world moves, and part of its movement is datable. A competitor opening two streets away. A supplier raising prices. A platform changing how it works. A three-day connection outage in your neighbourhood.

Technical changes done to you count double, because they are invisible and real at once: an update to your site made by the host, a module disabled, a certificate expiring overnight. Record them in the same place, with the same date.

The rule is simple: if you learned about it and can date it, it goes in the register. Twenty useless external lines are better than one missing line on the day it would have explained everything.

This is also what separates a register from a development log. The second records only work done on the product; this one records whatever could have acted on the figures, whatever its source.

The log outlives the provider

This is the argument directors grasp fastest, because most of them have lived it.

The companion article reports one site where the displayed price was removed, restored and removed again — three times in a few years, each time by a different provider and each time with conviction. Nobody was lying: nobody knew.

A register breaks that cycle for a mechanical reason. Whoever arrives reads it in twenty minutes and discovers that their idea has already been tried, when, and what followed. Without it they propose what they would propose on any site.

Two conditions for that to work, and they are administrative rather than methodological. The file has to be yours, on a space you control, and not inside the provider’s tool. And it has to be updated as a condition of the engagement rather than as a favour.

We write it into our own contracts for that reason, and we suggest you write it into every other. One line: the register is updated at each intervention and remains the client’s property.

The negative entries are the useful ones

A register in which everything worked is a falsified register, and that is how you recognise one.

Changes with no visible effect are the majority, and they carry the most economical information there is: they say that this particular lever is not worth the time spent on it, and they have said so once and for all.

Changes that made something worse are worth more still, provided they are recorded as such on the day they are undone. The reversal line matters as much as the original: without it, the register describes a site that does not exist.

Writing therefore has to carry no stakes. A register read out in a meeting to apportion responsibility stops being honest within two weeks, and becomes the most dangerous document in the file — false and dated.

The phrasing that helps: the register records what was done, not who was right. It is the same distinction an operations log makes, and it is what allows somebody to write down their own failure in it.

When the log says stop changing the page

After a year the commonest reading is not "here is what works". It is "we have changed this page eleven times and nothing moved".

That conclusion is a result, and it is probably the most profitable one the document will produce. It says the constraint is not on the page, and that attention should stop being spent there.

What it does not say is where the constraint is. The usual candidates are elsewhere: the price, the time taken to answer messages, whether the product is actually available, or simply that too few people arrive at all. The article on conversion and the one on diagnosing a social page treat those in order.

A register that triggers that conclusion has saved a year of the next one, and it is the only return on this document one can state honestly.

One matter of hygiene remains: the register is kept even once the page is no longer being changed, because the external lines keep arriving and the explanation for the next drop will be among them.

What we do, and what we refuse

What we do is short. We open the file with you, to the five columns described above, we record the changes we make ourselves on the day we make them, and we read the year back with you once a year, on the same date.

We refuse to call a sequential change a test, in a report or in a meeting. The word is precise and it gets used to lend weight to an observation that has none; the companion article explains what the word commits you to, and borrowing it would be selling a rigour the method does not have.

We also refuse to keep the register ourselves. It is the natural request — it would make us harder to replace — and that is exactly the reason to refuse: a document whose value is that it outlives the provider cannot be hosted by the provider.

And there is one thing you can do this morning without us, and it is the only genuinely urgent act in this article: open the file and write the first line, dated today. Everything before today is lost and nothing will recover it — which is precisely why this page carries no chart.

Frequently asked questions

Is a spreadsheet really enough?

Yes, and it is preferable. The register needs no function a spreadsheet lacks, and dedicated tools add one more reason to abandon the document — an account to manage, a subscription to renew, an export to make when the provider leaves. The only criterion that matters is that the file is yours and openable in ten years.

When does it become useful?

Immediately for explaining a drop — you then search the three preceding weeks — and from the thirteenth month for the comparison that matters, a month against the same month a year earlier. That delay has to be known on day one, or the document is judged disappointing around the sixth month and abandoned just before it starts to serve.

What exactly do we record when we fix ten small things in one day?

One line listing them, dated that day. Those are omissions corrected rather than hypotheses, so nothing is lost by grouping them — the queue of obvious corrections is described in the companion article. The one-change-at-a-time discipline applies to what is debatable, not to what is broken.

Should we record changes made by other people?

Yes, and that is what separates this document from a development log. A host’s update, a disabled module, a competitor opening, a three-week stock-out: if you learned of it and can date it, it goes in. A register holding only your own modifications ends up attributing everything that happens to them.

Does the register replace an A/B test?

No, it answers a different question. A test says whether a gap between two versions is real; the register says what you did, when, and what moved around you. Companies with the volume keep both, because without the second they cannot interpret the measurements sitting between two tests.

What if nobody keeps it up?

The problem is almost always the cost of writing rather than willingness. If a line takes more than thirty seconds it will be deferred and then forgotten: simplify the medium before restating the rule. The approach that holds best is to write the line before the modification, and to treat an unrecorded change as not done.

Where we come in

The five headings take a minute and the first row writes itself. What is missing twelve months later is somebody who knows what the register lets you conclude.

We add your commercial dates: promotions, closures, stockouts.
We read the first twelve months with you, row by row.
We mark the rows from which nothing may be concluded at all.
We leave the file with you, including if we stop working together.

A register under six months old is not ready to be read: keep filling it in, and call us when it has a year behind it.

See the A/B Testing page Talk it over on WhatsApp

Let us talk about your project

A free audit, no commitment: we look at your online presence and tell you what is holding it back.

Request the free audit Write to us