Event-based web analytics: how to collect data you can trust

Event-based web analytics records not just page views but specific user actions: sign-up, add to cart, payment, feature usage. For the data to be trustworthy you need a tracking plan with a single naming and property scheme, server-side sending for important events, respect for user consent and regular quality checks. Without these, analytics quickly turns into a set of numbers nobody can explain.

Here is how to write a tracking plan, when to send events from the server, how to handle consent and how to check data.

How does event analytics differ from page views?

Page views answer "where do users go"; events answer "what do they do". In modern interfaces many actions happen without a page change: filters, modals, form steps. Only events capture them.

Approach	What it records	Questions it answers
Page views	URLs opened	Traffic sources, popular sections
Events	Actions with context	Where users drop out of a funnel, which features they use
Server events	Facts in the system	How many payments, subscriptions, refunds really happened

How do you write a tracking plan?

A tracking plan is a document recording, for each event, its name, when it fires, its properties and the question it answers. It lets developers, analysts and marketers speak one language and avoid duplicates.

{
  "event": "checkout_completed",
  "when": "After a successful payment, sent from the server",
  "properties": {
    "order_id": "string",
    "revenue": "number",
    "currency": "USD",
    "items_count": "integer",
    "payment_method": "card | wallet | invoice",
    "is_first_order": "boolean"
  },
  "question": "What share of users who start checkout complete payment, and by which method"
}

Plan rules:

1. Event names follow one format: object plus past-tense action.
2. One action, one event; details go in properties, not the name.
3. Every event answers a specific question.
4. The plan lives next to the code and changes through review.

Photo: Unsplash

When should events be sent from the server?

Send from the server the events that matter for money and must not be lost: payments, subscriptions, refunds, sign-ups. Browser events get lost to blockers, closed tabs and poor connections, while the server knows the fact for certain.

• from the client — views, clicks, interface interactions, form steps;
• from the server — payments, completed orders, plan changes, cancellations;
• linking — both sources share a user or session ID so the whole journey connects;
• background sending — server events go through a queue without slowing the user's response.

For large event volumes your own store is convenient — see ClickHouse for analytics.

How do you handle user consent?

Analytics cookies and sharing data with third-party services require user consent and compliance with personal data laws. The consent banner must actually control whether trackers load, not just sit on the page.

• before consent, only cookies essential for the site load;
• analytics trackers load after consent to that category;
• names, phone numbers, emails and other direct identifiers never go into events;
• raw event retention is limited;
• users can withdraw consent.

More on requirements in personal data on a website: GDPR and 152-FZ.

How do you check data quality?

Check data quality like code: with tests and monitoring. Otherwise, six months later you discover half the events stopped firing after a redesign and decisions were made on incomplete data.

• reconcile server payment events with orders in the database;
• alert on sudden drops or spikes in event counts;
• check events in the test environment before release;
• validate properties against the plan's schema;
• keep a changelog of the tracking plan.

On which metrics to watch, see product metrics after launch and A/B testing.

In short

• Events show what users do, not just which pages they open.
• A tracking plan sets shared names, properties and a question for every event.
• Send money-related events from the server so they are never lost.
• Load trackers after consent and never pass direct identifiers.
• Check data quality by reconciling with the database, monitoring and tests.