Article · Updated August 2026

Instrument product analytics without tracking everything

Q: How should I name events?

Use a consistent object-and-outcome convention such as source_connected or report_generated. Avoid names tied to button copy or page layout. Publish the trigger definition with the name.

Editorial cover: a dense field of possible events reduced to four deliberate signals

You do not need to track every click to understand whether a product works. You need a small event system that defines who entered, whether they reached the product’s value, whether value became payment and whether they returned.

Start with four event families:

entry;
first value;
commercial outcome;
meaningful return.

Then add diagnostic events only when a recurring decision cannot be answered without them.

Minimum measurement plan with four event families, entities and jobs

Begin with decisions, not the interface

Write a table before installing an SDK:

Recurring decision	Eligible entity	Required event	Observation window
Is acquisition bringing usable accounts?	New account	`account_created` plus source context	Weekly cohort
Do new accounts reach first value?	New eligible account	`first_value_completed`	Within a defined number of hours or days
Does value become payment?	Eligible account/customer	`trial_started` and authoritative paid state	Mature trial cohort
Do customers keep using the value?	Activated account	Repeated first-value or core-use event	Week or month boundary

If an event does not support one of the decisions, leave it out of version one.

Define the four event families

Entry

Entry defines cohort eligibility. Choose the point at which the person or account can reasonably begin the journey.

Examples:

account_created for an account-based SaaS;
workspace_created for a collaborative product;
app_first_opened for an anonymous mobile experience;
invitation_accepted for a member journey.

Do not silently switch between a device, user, account and workspace. Name the entity in the event specification.

First value

First value represents the product promise being delivered, not the tutorial ending.

Examples:

first external data source connected and a report rendered;
first invoice successfully sent;
first workout completed;
first automation run successfully;
first collaborator receives a useful result.

Prefer the completed outcome over the button tap that begins it. report_generated is more defensible than generate_clicked when the report can fail.

Commercial

Commercial events connect the product account to the billing or subscription source.

Examples:

trial started;
purchase completed;
first payment succeeded;
renewal failed;
refund or cancellation state changed.

Treat the billing source as authoritative. Product-side button events can diagnose the flow but should not declare a successful transaction.

Return

Return means the customer repeated the meaningful behaviour after a defined boundary. It is not any app open.

For a weekly reporting product, an account generating another report in a later week may be retained. For a yearly tax product, weekly use would be the wrong expectation. Define the cadence from the job.

Write an event contract

Every event needs more than a name.

Field	Example	Why it matters
Name	`source_connected`	Stable shared reference
Trigger	Connection test succeeds and usable data is available	Prevents click/success ambiguity
Entity	Account	Defines uniqueness and joins
Required properties	`source_type`, `connection_id`, `app_version`	Supports known diagnostics
Exclusions	Sandbox, internal accounts, reconnects	Protects the denominator
Owner	Product engineering	Someone must maintain the meaning
Version/change note	v2 from 12 Aug 2026	Explains discontinuity

Write the trigger in plain language before writing code. If two engineers would implement it differently, the contract is incomplete.

Design identity before funnels

Identity determines whether events form a journey.

Use a hierarchy:

anonymous identifier for activity before signup;
stable user identifier after authentication;
account or workspace identifier for business outcomes;
billing customer identifier for commercial joins.

Join anonymous history to an authenticated identity only when the product architecture and privacy rules permit it. Handle merges, invited members, account switching and deleted users deliberately.

An activation rate by device and a paid rate by account cannot be combined without a defensible bridge.

Choose capture deliberately

Autocapture can help explore a new interface, while explicit custom events provide stable business semantics. The useful split is:

Capture type	Good use	Risk
Autocaptured interaction	Temporary exploration, UI debugging, candidate-event discovery	Noisy, coupled to markup and easy to misread
Explicit product event	Stable first-value or workflow milestone	Requires engineering and contract ownership
Server-side event	Authoritative completion or state change	Can miss client context unless joined
Billing/store event	Payment, entitlement, renewal and refund truth	Entity and timing differ from product events

PostHog’s own guidance recommends starting with a specific product or feature, tracking its use with autocapture or custom events, visualizing what is useful and expanding only after gaps become clear (PostHog).

For a critical event, prefer the system that knows the outcome. Capture report_generated on the server after success rather than only generate_clicked in the browser.

Keep properties small

Add a property when a known recurring question requires it.

Useful property classes:

product version or release;
platform and environment;
plan or offer ID;
acquisition source carried from the account;
feature variant;
error or completion state;
non-sensitive content category.

Avoid sending free-form personal data, tokens, secrets, full URLs with sensitive query strings or unbounded payloads. Review the vendor’s privacy controls, retention, data location and deletion process before collection.

A minimum plan for a founder-reporting product

The following is a fictional example.

Event	Trigger	Entity	Required properties	Decision
`account_created`	Account persisted	Account	acquisition source, platform	Cohort entry
`source_connection_started`	Valid connection flow begins	Account	source type	Diagnose setup intent
`source_connected`	Usable source data confirmed	Account	source type, duration, result	Setup completion
`dashboard_rendered`	First complete dashboard displayed	Account	connected sources, freshness	First value
`trial_started`	Subscription source confirms trial	Customer/account	product, offer, store	Commercial entry
`payment_succeeded`	Billing source confirms payment	Customer/account	product, currency, transaction	Paid conversion
`dashboard_rendered` in later week	Same event after week boundary	Account + week	project count	Retained value

Only seven named events are required, and two reuse the same core outcome across time. Add an intermediate event if the funnel shows a material loss between connection start and successful first value.

Validate the instrumentation

Before using a rate:

trigger each event in a clean test account;
verify it fires once at the specified outcome;
inspect the entity and required properties;
test retries, refreshes and back navigation;
test anonymous-to-account identity;
compare billing events with the authoritative transaction source;
exclude internal and sandbox traffic;
document the production release time.

Then run data-quality checks:

Check	Example failure
Uniqueness	One completion fires three times after a retry
Completeness	Mobile clients omit the event on one app version
Validity	`source_type` contains new unrecognized values
Order	Paid event precedes trial start because timestamps use different clocks
Identity	Events split across anonymous and account IDs
Freshness	Webhook delivery is delayed or stopped

A dashboard should show source freshness or instrumentation health beside the decision metric.

Know when to add another event

Add an event when:

the same question has recurred at least twice;
the current funnel locates a loss but cannot separate the plausible handoffs;
the event represents an outcome, not curiosity;
the entity and trigger can be defined;
someone owns its maintenance;
the privacy and operating cost are acceptable.

Do not add an event solely because a generator can produce tracking code. Automation can implement a plan; it cannot choose the product’s first value for you.

Know when to use replay or error monitoring

Product events, replay and error monitoring answer different questions.

Events measure how often a defined action occurs.
Replay observes what happened in selected recorded sessions.
Error monitoring diagnoses technical failures and stack traces.

Use the funnel to locate the affected step, replay to observe selected cases and errors to confirm technical failure. The comparison in session replays or funnels explains the sequence.

Frequently asked questions

How many product events should a small SaaS track?

There is no universal number. Begin with entry, first value, commercial and return events, plus only the intermediate events required by recurring diagnostics.

Should I use autocapture?

Use it deliberately for exploration and low-level interaction context. Use explicit outcome events for stable business metrics. Do not let captured clicks silently become your semantic model.

Should events be client-side or server-side?

Capture the event where the outcome is known. Client-side is useful for exposure and interaction. Server or source events are usually stronger for completed work and payment state.

How should I name events?

Use a consistent object-and-outcome convention such as source_connected or report_generated. Avoid names tied to button copy or page layout. Publish the trigger definition with the name.

Does fewer tracking mean less insight?

Not when the selected events answer the decisions. A small trustworthy schema can support more action than a large undocumented stream.

Sources

Keep reading

Article

Session replays or funnels: which explains the drop-off?

Article

Find where your activation funnel leaks

Article

Privacy-friendly analytics for a small SaaS