Skip to content

Data & Analytics

Analytics instrumentation: decide the events before you collect them

Tracking added one tag at a time ends up with three names for the same click, events nobody can explain and no way to connect a website visit to the job it became. Instrumentation starts from a tracking plan: the questions you need answered, the events and properties that answer them, how a visitor becomes a known lead, and what you don't collect at all.
Discuss your systemSee the tracking plan ↓
/water-heatersGet a quoteCall EastsideTracking planpage_viewedpage✓quote_startedservice✓call_clickedlocation✓Submit_Form_v2(no properties)not in plan · reportedquote_submittedservice, location✓visitor a-7f3 → lead L-2207

The tracking plan

Every event exists because a question needs it. This is the whole plan for a service business's website.
page_viewedA page loadspage, referrer, campaign
quote_startedThe first field of the quote form is filledservice, page
quote_submittedThe server accepts the formservice, location, lead_id
call_clickedA phone link is tappedlocation, page
job_bookedThe CRM marks the lead booked, sent from the serverlead_id, service, value

What a plan decides

  1. 01

    Names

    One object, one past-tense verb

    quote_submitted, never “Submit_Form_v2” or “form-success”. A name is chosen once and kept.

    a new name every time a page is redesigned.

  2. 02

    Properties

    Typed, with allowed values

    service is one of your services, location one of your locations. Free text is the exception.

    the same property spelled three ways.

  3. 03

    Identity

    When a visitor becomes a lead

    Anonymous until they submit a form or call; then the visit history joins the lead, and later the customer.

    joining on guesses, like an IP address.

  4. 04

    Consent

    What waits for permission

    Events that need consent wait for it; the rest stay strictly necessary.

    tags that load before the visitor has chosen.

  5. 05

    Boundaries

    What's never collected

    No form contents in analytics, no card details, nothing you couldn't explain to the customer.

    “just in case” collection.

Three events, as captured

quote_submitted · browser

fired
Oct 2, 14:08:11
visitor
a-7f3
properties
service: water heater · location: Eastside
lead_id
L-2207, added by the server
consent
analytics: granted

What instrumentation hands off

In

Questions
what you need to know
Site and app actions
clicks, forms, calls
Server events
bookings, payments
Tracking plan
name → validate → identify

Out

Clean events
named once, typed
Identity links
visitor → lead → customer
Plan violations
reported, not kept

Worth doing properly when decisions depend on it

Good fit

  • You spend on ads or content and need to know what turns into work.
  • Your current analytics has duplicate or unexplained events.
  • You're launching a site or app and can start clean.

Not the right fit

  • You only need page views. The defaults of most analytics tools cover that.
  • Nobody will look at the data.

Where events are used

Next to instrumentation

Questions about analytics instrumentation

Do you use Google Analytics?

If you already do, we work with it. For product and web behaviour we often start with PostHog. Starting candidates, not requirements; the plan matters more than the tool.

What is server-side tracking?

Sending important events, like a booking, from your own systems instead of the visitor's browser, so ad blockers and closed tabs can't lose them.

How does consent fit in?

The plan marks which events need consent, and those wait for it. The rules you follow are the ones you and your advisers set for where you operate.

Will it slow the site down?

A planned setup usually loads less than an accumulated one, because every tag has to earn its place.