Track the steps that show a target customer received value, the failures that blocked them and whether they returned when the job recurred. An MVP usually needs a small, reliable event vocabulary before it needs a dashboard full of charts. Choose events by the decisions they will inform.
A signup proves someone completed registration. It does not prove your product helped them. If you have not defined the customer job yet, start with how to scope and ship an MVP.
Write the decision before the event
Imagine an illustrative proposal tool for small consultancies. Its core job is preparing a proposal and sending it to a prospect. The team wants to know whether customers can complete that job without support.
The relevant sequence might be account created, first proposal started, first proposal sent, and a second proposal sent on a later occasion. Pricing-page visits are useful for acquisition analysis, but they cannot answer whether the editor works.
For each proposed metric, write what you will do if it improves, declines or stays flat. If nobody can name a decision, postpone the metric. This prevents building instrumentation around the easiest clicks to count.
Define a small event contract
| Event | Meaning | Useful properties | Source |
|---|---|---|---|
account_created | A usable account was committed | Acquisition channel, signup method | Server |
proposal_started | A new proposal was persisted | Template identifier, workspace identifier | Server |
proposal_sent | The product completed its sending step | Proposal identifier, plan, new or repeat user | Server or delivery workflow |
proposal_send_failed | A send attempt failed | Error category and retryability | Server |
pricing_viewed | The pricing page was viewed | Campaign and page version | Browser |
This is an implementation example, not a required schema or vendor API. Define exactly what “sent” means. An email accepted by a provider, a delivered email and a proposal read by its recipient are separate facts. Name separate events when those distinctions affect a decision.
Give events a version when their meaning changes. Changing proposal_sent from provider acceptance to recipient delivery without recording that change makes historical comparisons misleading.
Keep product truth on the server
Browser events are useful for navigation and interaction, but they may be blocked, duplicated or interrupted. Record purchases, bookings, completed exports and other authoritative state transitions where the application commits them.
If a background worker sends the event, reuse a stable business-event identifier on retries. Decide how duplicates are detected in ingestion or analysis. For valuable events, an outbox can record the state change and pending event within one database transaction; the worker later delivers it. That adds work, so reserve it for events whose loss would materially distort decisions or operations.
Keep the product functional when the analytics service fails. A tracking outage should not prevent sending a proposal. See reliable webhook design for related delivery and retry problems.
Make identity changes deliberate
An anonymous visitor may later sign up, join another organisation or use a second device. Agree when you identify the person and how you connect pre-signup activity, if permitted and needed.
Use internal identifiers rather than email addresses as analytics identifiers where possible. These identifiers may still be personal data; replacing a name with an ID does not automatically make tracking anonymous. Keep user and organisation identifiers distinct so a consultant working in two accounts does not merge their commercial activity into one customer record.
Exclude staff, automated checks, test workspaces and demo data from the product metrics used for decisions. Keep an explicit property for those cases instead of relying on someone remembering which email addresses are internal.
Read a funnel with a clear denominator
Suppose 40 eligible accounts start a proposal and 12 send one during a defined observation period. That is a 30% start-to-send conversion for those accounts and that period, not a universal product conversion rate.
Use consistent units: people, accounts or sessions. Do not divide account-level completions by session-level starts. Specify an allowed time between steps and exclude accounts that have not yet had enough time to complete the sequence.
Break the funnel down only when the sample supports it. Five people in a campaign cohort can reveal a usability problem through interviews, but a small percentage change in that group is weak evidence for a broad product decision. Pair the chart with support notes and observed task completion.
Measure retention at the product's natural frequency
A daily task manager and an annual compliance workflow should not share a daily-active-user target. Define a return event that represents the repeated job, then choose an interval that matches when customers need it.
For the proposal example, returning to send another proposal may matter more than reopening the dashboard. Track cohorts with enough observation time. A user who signed up yesterday cannot yet count as a failed monthly return.
Separate product retention from paid retention. A customer might pay an invoice while barely using the software, or use a free plan heavily without becoming a viable customer. Both observations matter, but they answer different questions.
Limit the data you collect
Avoid sending proposal text, customer contact details, access tokens, uploaded documents or full request payloads into analytics. Error messages and page URLs can also contain sensitive values. Use an allowlist of properties and inspect actual network payloads.
Treat automatic capture and session replay as deliberate choices. Configure collection, masking, retention and access before enabling them on real users. PostHog's event documentation explains its capture options, while its privacy controls describe collection and processing controls. A vendor setting does not decide your legal obligations; obtain advice for the jurisdictions and data involved.
Validate before reading the dashboard
Walk through a fresh account, an existing account, a failed action, a retry and a staff account. Confirm each event has the expected identity and properties, appears the expected number of times, and uses the intended time zone.
Compare important analytics counts with application records over a fixed period. They may differ for understood reasons, but investigate unexplained gaps before changing the product. Keep a short event dictionary, a named owner and a record of changes.
Review the resulting evidence at an agreed decision point. If users repeatedly start but cannot finish the core task, investigate that path before adding another feature. Apex's product team can include this measurement plan in the MVP scope.