MEASUREMENT

Website analytics for SaaS: measure decisions, not dashboard noise

Build a practical SaaS measurement plan: acquisition, activation, verified payments and data quality, with a worked example and a weekly review template.

Start with the decision you need to make

Website analytics is the collection and interpretation of recorded website activity. For a SaaS founder, its job is not to produce the largest possible chart. It should help decide where to attract customers, which journey to improve and whether an apparent improvement survives a check against paid outcomes.

Start by writing three questions: Which channels bring suitable prospects? Where do those prospects fail to reach useful product value? Which observed journeys lead to verified payments? These questions require different evidence. A pageview can help answer the first; it cannot, by itself, answer the third. A short measurement plan is more useful than installing every event available.

Separate four layers of evidence

Acquisition describes the recorded arrival: a landing page, source, campaign and timestamp. Activation describes a meaningful product outcome, such as a first completed report, not merely opening a menu. Payments describe confirmed financial events. Data quality describes the gaps and limitations in all three.

Keep these layers separate even if one dashboard displays them together. Google Analytics distinguishes users, sessions and events; repeated pageviews are not additional people. Payment systems have their own identifiers and states. A useful report names the unit rather than labeling every number “conversions.”

Acquisition         Activation            Money
recorded arrival -> useful product result -> verified payment
      |                    |                       |
missing source       missing event          refund or retry
      +---------------- data quality ---------------+

Create a minimum viable measurement contract

For each business question, specify an event, an authoritative producer and the denominator used in its report. For account creation, the application database may be the source of truth. For payment success, use confirmed provider records rather than a thank-you-page visit. Keep marketing measurement subject to the permissions and privacy controls appropriate to your implementation.

An event contract should also say what must not be sent. Exclude passwords, payment details, email addresses and free-form customer content from generic analytics properties. Choose a small set of categorical labels. A page category such as “pricing” usually answers a marketing question better than a complete URL containing customer identifiers.

  • Acquisition question: which observed source brought eligible landing visits? Count sessions or visitor identifiers consistently.
  • Activation question: how many new accounts achieved the defined outcome within seven days? Use an account cohort and a fixed observation window.
  • Revenue question: which verified new-customer receipts have an eligible acquisition association? Show missing associations separately.
  • Quality question: were all expected events and payments processed, and when was each dataset last updated?

A synthetic example: volume is not the decision

Imagine a fictional scheduling SaaS. In a completed acquisition cohort, Community brought 500 eligible visitors, 50 signups and 10 new paying customers. Search brought 200 eligible visitors, 30 signups and nine new paying customers. Every signup has had the same 14 days to convert; all figures are invented solely to illustrate the method.

Community has more customers in total, but Search has a higher observed visitor-to-paid rate: 9 / 200 = 4.5%, versus 10 / 500 = 2%. Neither fact identifies a winner for the business. Community might cost almost nothing; Search might require expensive content. One source may retain customers longer. With only 19 purchases, a few additional customers could materially change the comparison.

The immediate decision is not “stop Community.” Inspect intent and activation by source, record the resources each channel requires, and collect another comparable cohort. If the next experiment targets onboarding, compare onboarding outcomes—not just the overall visitor total.

Make the weekly report small enough to use

Use one completed reporting window and state its timezone. Add a freshness timestamp for each source and distinguish preliminary from settled data. Compare like durations and weekdays; label launches, outages, tracking changes and price changes. Otherwise a chart can turn an implementation change into a marketing story.

Review five items: acquisition by source, new-account activation, verified new-customer payments, renewals and refunds, and measurement exceptions. Keep currencies separate unless you have an explicit conversion policy. A payment total is not MRR, profit or bank payouts. Those questions need their own definitions.

Write one action under the report. For example: “Test whether the empty-state explanation helps new accounts finish their first report.” Record the hypothesis and expected signal before shipping. Analytics should shorten the path from uncertainty to a test, not create more dashboards to maintain.

Know when the data cannot answer

A funnel can locate a recorded drop-off; it cannot tell you whether the person was confused, interrupted or never a suitable customer. Pair the numbers with direct usability testing or voluntary feedback. Do not manufacture certainty from a tiny sample.

For the next layer, read the related conversion-funnel guide for cohort definitions and the revenue-attribution guide for joining traffic to money. First verify your measurement path with the installation checklist. A confidently drawn chart over broken events is worse than an honest empty report.

References

Educational guidance. Worked examples are illustrative, not customer results or a promise of traffic, revenue or search visibility. Check the cited sources and your own implementation.
Explore the synthetic demo →