Web Analytics for SaaS: A Decision-First Measurement Plan

Web analytics is the collection, processing, and interpretation of website interaction data for a defined decision. A decision-first measurement plan starts with what the team may change, who or what is eligible, and which observable outcome would inform that change. It then specifies events, properties, identity, consent, validation, reporting, and ownership. A tag installation or dashboard alone is not a measurement plan.

Start with the decision, not the tracking plan#

“Measure the website” is not a decision. “Decide whether the enterprise comparison page helps qualified accounts begin an evaluation” is. The second statement identifies an object, a population, a possible action, and an outcome that can be translated into evidence.

Google’s event documentation describes events as the way Google Analytics measures interactions. Events and their parameters are useful primitives, but a long event list does not establish why the data is collected or how a result will change work.

Web analytics and product analytics overlap technically. Web analytics often emphasizes acquisition, pages, sessions, and website outcomes. Product analytics often follows people or accounts through feature behavior, activation, and retention. An event-based web tool can answer product questions, and a product platform can ingest website events. The correct boundary is the decision and data contract, not the vendor category.

Build the plan in eight linked steps#

The steps are ordered because later choices depend on earlier ones. If the counting unit changes from sessions to accounts, the denominator changes. If the outcome is redefined, the event contract and historical comparison may break. If consent suppresses collection for part of the population, the report cannot be treated as a complete census.

Events are records; key events are declarations#

Google Analytics distinguishes several implementation categories, including automatically collected, enhanced-measurement, recommended, and custom events. The category describes how an event enters that product. It does not say whether the event is useful for the organization’s decision.

Google also lets a property owner mark an event as a key event when it represents an important action. That label is governance, not validation. A generate_lead event can fire when a form submits even if the form is a test, the email is invalid, the visitor is ineligible, or the backend rejects the record.

An event contract should include:

Identity determines what can be counted#

A browser identifier is not a person. A login is not necessarily a unique buyer. An account can contain many users, and one user can use several devices. Sessions are constructed according to tool rules and do not represent every research or buying journey.

Google’s collection overview describes device, activity, and client-identifier inputs used by its system. That makes reported users and sessions analytical constructs produced from available signals. Consent choices, browser behavior, deletion, login state, tag failures, and cross-device use can all change what is observable.

Publish the identity rule beside each metric. “Accounts that reached pricing and later created a qualified opportunity within 30 days” is materially different from “sessions that clicked a demo button.” Neither is inherently correct; they answer different questions with different blind spots.

Privacy is part of measurement design#

Google’s data-safeguarding policy prohibits sending information that could identify a person to Google Analytics and places responsibility for collection and use on the customer. That product rule is a minimum implementation boundary, not a complete legal program.

Before creating a property, ask whether it is needed for the decision, whether a less sensitive aggregate would work, who can access it, how long it is retained, and how deletion is handled. Do not place email addresses, full names, phone numbers, or free-text fields into analytics payloads merely because the interface accepts strings.

Google’s consent-mode documentation describes default consent states and updates that influence tag behavior. The exact legal basis and interface depend on jurisdiction and organizational facts. Analytics engineering should implement the approved decision; it should not invent the legal policy.

Validate from the browser to the decision#

Testing only whether an event appears in a debugger is insufficient. Run a trace through each layer:

1. Interface: did the intended action occur, including error and cancellation paths?
2. Payload: did exactly one correctly named event carry allowed, non-sensitive properties?
3. Consent: did collection behave correctly before, after, and without a valid choice?
4. Transport: did blockers, retries, navigation, or network failure duplicate or lose the record?
5. Processing: did the analytics product transform identity, traffic source, and time as expected?
6. Report: does a known test population produce the expected numerator and denominator?
7. Destination: if joined to CRM or warehouse data, did the join preserve eligibility and time order?

Keep automated checks for event schemas and critical flows, plus periodic reconciliation against an appropriate operational system. Differences do not automatically mean analytics is wrong: a CRM lead, backend account, browser event, and billed customer can have legitimate timing and definition differences. The reconciliation must explain them.

Write one compact measurement contract#

For each important decision, record these lines:

• Decision and owner: what can change, who decides, and when.
• Population and unit: who is eligible and whether counting uses people, accounts, sessions, or events.
• Exposure: what must be observable before a unit enters the comparison.
• Outcome: the event or state, source of truth, and allowed delay.
• Metric: numerator, denominator, window, identity, attribution, and exclusions.
• Quality: expected test cases, monitoring, known blind spots, and break response.
• Privacy: purpose, properties, consent behavior, access, retention, and deletion.
• Decision rule: what result supports a change, blocks it, or requires more evidence.

This artifact keeps instrumentation proportional. If a property does not support the decision, quality check, segmentation, or approved diagnostic, do not collect it “for later.” Extra data carries semantic, privacy, and maintenance cost.