Decisions and the data we owe ourselves

One chart to draw before any other: tables down the side, months across the top, a filled cell wherever a table has rows. It takes an hour and it saves months, because it turns "we cannot answer that" from an argument into a picture. Read this one and you know immediately that any question about logins is a two-month question, any question about promotion types is a 2025 question, and any question about what changed on the platform has no table at all.

Two kinds of row have no name on them. The first is the guest checkout: 6.3 percent of order lines in 2020 carried no customer id, 11.9 percent in 2026. Every retention number computed from this data excludes them, and the blind spot grows every year as more customers choose not to sign in. The second is the orphaned promotion: promo codes were stamped on orders from 2020, but the table that says what each code was starts in January 2025, so four years of promotions are ids that point at nothing.

Neither gap needs new technology. A hashed email or phone at guest checkout gives a customer an identity that survives not signing in, and it is a decision each merchant has to take for their own customers. A promotion table that keeps every code for its whole life is a decision the two marketing teams have to take between them. Ask who owns it before asking what it costs.

Sixty-nine days of login data, from July to September 2026, is all the behavioural history the platform has. Read it for what it is: a snapshot. Login to purchase converts at 16.8 percent on the key servers against 26.9 percent on the rest - consistent with everything c2 found, and a useful place to point product effort. What it cannot tell you is whether that gap is new, seasonal or permanent, because there is no earlier summer to compare with. A chart like this carries its date in the title so nobody quotes it as a trend.

Every long chart of the platform carries the same nine vertical lines: the fulfilment change, the merchant-success cut, a checkout release, a few pricing changes. Those nine rows were written down from memory during the diagnosis, because nowhere in the company is there a record of what changed on the platform and when. Releases live in a deployment tool that keeps ninety days. Incidents live in chat. Business decisions live in slide decks. None of it joins to a month on a revenue chart.

This is the highest-leverage gap in the whole diagnosis, and it is not a technology gap. An event log is a table with five columns - date, what changed, scope (which server, which merchant), owner, link to the decision - and it fails for one reason only: writing to it is nobody's job. Treat it as a data product with an owner and a contract. Engineering owns release and incident events. The leadership team owns decision events. The metric layer joins both to every chart automatically.

• A gap is an ownership gap before it is a tech gap. Ask "whose table is this" before "which tool".
• Memory is data too. The nine remembered rows are the first nine rows of the log. Start from them.
• The log earns its keep on the next diagnosis. Every future "why did the number move" starts by reading it. Without it, every diagnosis starts from interviews.

The order matters. c2 established that the March fulfilment change reached the customer and the June merchant-success cut compounded it, so the first two rows are the two levers in that order. The next seven are the growth findings, each traceable to a chart you have already seen.

None of these needs a platform migration. Each is a table, a field or a rule, and each is owned by a domain from the ownership map. The first row is the one that pays for all the others.

These are the questions the availability table marked "no". Each becomes a row with the same five columns, because collecting data nobody owns produces a table nobody trusts. The first row is the one that would have turned the cost story from an allocation into a fact.

Promotions do two things at once and the company only measured one. Customers acquired through a promotion place a first basket of 91.8 against 84.7 for organic customers - the promotion works, on the day. But 63.4 percent of them ever order again against 71.5 percent of organic customers. Acquisition promos buy baskets, not customers. That does not make them wrong; it makes them a basket tool that should be measured as one, with the repeat cost written next to the basket gain.

The promotion-type view is honest about its own limit: it covers twenty months, because the table that names each promotion did not exist before. That is the orphaned-id gap from Part 1 showing up as a shorter chart. Fix the ownership and the chart grows backwards.

If the monthly review opens with one chart, this is it. Active customers this month equal new plus retained plus resurrected; the churned bar below the line is what left. It cannot be gamed by a growth number, because growth is the top of the stack and churn is the bottom, on the same axis. Had it been on the wall in 2024, the key-server churned bar would have grown two quarters after the cost decision and someone would have asked why.

• Per server, then platform. The blended version is the one that hid the break. Ten small versions, then the total.
• Merchants get the same chart. c2 showed the merchant version; both belong on the same wall.
• Frozen history. Last month's bars do not change when this month's data lands.

It is 2027. The event log exists. Nobody writes to it. Why? Because writing to it was nobody's job: it was a page in a wiki, engineers were asked nicely, and the third week of a busy quarter was the last time anyone opened it. The fix that survives the pre-mortem is a required field in the release gate - a deployment does not go out without a log row, and a decision is not minuted without one. The log fills itself because the thing people already have to do now produces it.