Analytics implementations tend to grow the same way: someone installs a script, someone else adds events for a campaign, a third person adds more for a launch, and two years later there are 140 event names, four of which are variations on signup_click and none of which anyone trusts.
The fix is not a better tool. It is building the schema backwards, from the small number of decisions the data is supposed to inform.
Start with the questions
Write down the questions someone actually asks in a monthly review. On most B2B sites there are about six, and they are unglamorous:
- Where did the people who did something valuable come from?
- Which pages do people read before they convert, and in what order?
- Which pages are read a lot and convert nothing?
- Where in the form or booking flow do people stop?
- Is the trend up or down against the same period last year?
- Which content brought back someone who had already been here?
Now design the smallest schema that answers those six. It will be dramatically smaller than what you have, and every field in it will have a named use.
If you cannot name the decision an event informs, you are not collecting data. You are accumulating it.
The schema that covers it
| What to record | Why | Common mistake |
|---|---|---|
| Pageview with path, referrer and a coarse timestamp | Answers questions 1, 2, 3 and 5 on its own | Recording the full URL with query parameters, which fragments every report. |
| Ten to fifteen named events for meaningful actions | Separates reading from doing | An event per button. Name the outcome, not the element. |
| Form and booking step reached | Answers question 4, the highest-value one | Only recording completion, which tells you nothing about where people stop. |
| A session identifier that expires | Lets you order pages within a visit | A permanent identifier, which turns a measurement question into a consent question. |
| Scroll depth on long pages only | Distinguishes read from opened | Firing it on every page, which triples volume for no new information. |
Name events for outcomes, not elements
hero_cta_click breaks the moment the hero is redesigned, and it does not survive being compared against last year. booking_started keeps its meaning through three redesigns, because it names the thing the visitor did rather than the thing they clicked.
The test is whether the name still makes sense to someone who has never seen the page. If it needs the page open to interpret, it is an element name wearing an event name’s clothes.
Consent is a design constraint, not a banner
In the EU the rule about storing or reading information on a device applies whoever owns the data. A first-party cookie is still a cookie. So the decision is upstream of the banner: if measurement can work without writing to the device, the consent conversation gets much simpler and the data gets more complete, because the share of people who decline stops being a hole in your numbers.
That is a real trade-off, not a free lunch. Without a device identifier you lose reliable long-window returning-visitor detection. Whether that matters depends on whether anyone was going to act on it — which is the same question as before.
Two things worth deleting
Vanity totals. Sessions and pageviews with no denominator move for reasons that have nothing to do with your work — a bot wave, a link on an aggregator, a seasonal shift. Reported alone they generate confident explanations for noise.
Data with no retention limit. Every month of raw behavioural data you keep past its usefulness is a month of liability with no offsetting benefit. Pick a window, write down the reason, and enforce it in the storage layer rather than in a policy document.
Analytics is built to this shape — first-party, on your domain, no device storage by default, and a small schema you can read in one screen. It writes to the same visitor record that Chat and Bookings use, which is what makes question two answerable at all. What we will and will not keep is set out on the evidence standard page.