An LLM will tell you what to do with your data. But only you know that three weeks ago you changed a plugin. Without that, a recommendation can be technically correct and completely misleading at the same time.
April 2026. A store owner asks the LLM about conversion rates across channels and wants to know where to focus the budget. The answer looks great – concrete numbers, a clear recommendation.
A recommendation that looks great
Conversion rate by channel – April 2026
| Channel | Sessions | Transactions | Conversion |
|---|---|---|---|
| 28,340 | 2,664 | 9.4% | |
| Paid Search | 72,410 | 5,213 | 7.2% |
| Direct | 21,780 | 1,329 | 6.1% |
| Organic Search | 89,250 | 5,177 | 5.8% |
| Paid Social | 54,120 | 2,111 | 3.9% |
| Organic Social | 15,690 | 361 | 2.3% |
Email and Paid Search clearly stand out from the other channels – conversion of 9.4% and 7.2% respectively, with significant session volume in Paid Search (72k). Organic Social and Paid Social convert the weakest.
Recommendation: strengthening email communication to active segments and increasing the Google Ads budget in the ranges with the highest CVR will deliver a proportionally higher return than investing in Paid Social at this stage.
The recommendation looks solid. But there’s one problem: these numbers aren’t comparable with any previous month – and the LLM doesn’t know it.
On March 31, 2026, the store changed the plugin responsible for counting sessions in Google Analytics 4. The old method counted every visit. The new one – only engaged sessions, i.e. those with at least 10 seconds of activity or an interaction. The change was technical and deliberate. But no one wrote it down.
A 9.4% conversion for Email and 7.2% for Paid Search in April looks great – but it rose by the same amount in every channel. The denominator changed (fewer sessions), not the numerator (transactions). The recommendation “focus on Email and Paid Search” may be right, but it doesn’t follow from any improvement in those channels’ effectiveness.
When, a week later, someone asked for a comparison of March and April, the LLM saw something alarming.
The same anomaly without context
March vs April 2026
| Metric | March 2026 | April 2026 | Change |
|---|---|---|---|
| Sessions (total) | 598,003 | 281,494 | −52.9% |
| Transactions | 17,944 | 15,021 | −16.3% |
| Conversion rate | 3.00% | 5.34% | +78% |
I see an anomaly here. Sessions dropped by more than half overnight, but transactions – only by 16%. Mathematically that raises conversion by 78%, which almost certainly doesn’t reflect a real improvement in the store’s effectiveness. Such a sudden and symmetric drop in sessions with stable transactions suggests a change in how things are counted, not a real loss of traffic.
Was there any change to the analytics configuration or tracking plugins in this period?
The LLM correctly identifies the anomaly. But without an answer it can’t go further. It doesn’t know which numbers are reliable, from when to count the new baseline, or whether the recommendation from the earlier conversation was based on the right data.
Now the same user comes back – with an entry from the event log that someone finally found.
The same question with the event log
A note before the analysis: the event log shows that on 31.03.2026 the way sessions are counted changed. The session and conversion data for March and April measure two different things – comparing those months on these metrics is invalid. Below I show only what we can safely read.
| Metric | March 2026 | April 2026 | Assessment |
|---|---|---|---|
| Sessions | 598,003 | 281,494 | not comparable |
| Conversion rate | 3.00% | 5.34% | not comparable |
| Transactions | 17,944 | 15,021 | −16.3% · comparable |
| Avg. order value | 161.40 EUR | 158.90 EUR | −1.5% · comparable |
The number of transactions fell by 16% – that’s a real change, not a measurement artifact. Partly seasonal. Average order value essentially unchanged. The April session data becomes the new baseline – comparisons with the following months will now be consistent.
The same analysis, the same data – a completely different quality of answer. The difference is one two-sentence entry, pasted before the question.
How to keep such a log
You don’t need a separate tool. A text file, a spreadsheet or Notion will do – anything the whole team can access and from which you can copy a snippet in seconds. Each entry has four elements: the date, the category, the description and the metrics it affects.
// Example:
31.03.2026 | TECH – Changed the GA4 session plugin. Only engaged sessions from this date. – Affects: sessions, conversion, bounce rate.
Six categories are enough for most stores:
When you ask about a period that includes one of the logged events – copy the relevant entry and paste it at the start of the message, before the question. You don’t need anything more: the LLM reads the category, links the date with the query’s range and adjusts its interpretation.
If you don’t remember whether there was an event in a given period – ask the LLM about anomalies before asking your actual question. It will often point out the spot where something changed and ask for context. As it did in the second mockup above.
Starting point
An event log isn’t an analytics tool – it’s a condition for correct analysis. The LLM sees the numbers but not the store’s history. A plugin change, a new campaign, a discontinued product – that’s context only you have. A text file and the habit of one entry per change are enough. The analytics does the rest.
DataOrganizer · MCP
One MCP plugin and your store data is available in every conversation.