What is product analytics?
Product analytics connects actions inside software to questions about its usefulness. You might investigate whether new accounts complete a first report, which steps block that result, and whether the accounts return when the task arises again. Website traffic explains discovery; product behavior helps you investigate what happens after someone arrives.
Amplitude’s product analytics guide describes behavioral analysis across activation, engagement, retention, and conversion. You can apply that general approach with different tools. The important work is defining the decision and collecting dependable observations before choosing a dashboard layout.
This guide uses an original fictional reporting app called ReportDesk. Its customers connect a data source, generate a report, and deliver it to a colleague. A generated report can still be empty or abandoned, so our example treats a successful delivery as the first useful result. That is an example-specific definition that a real team would need to validate with customers.
Start with five decisions you can act on
Write the question and the possible action together. If an answer would not change a product decision, postpone the extra instrumentation. Our fictional founder wants to decide whether to improve the connection step, the report workflow, or the return experience.
Keep account-level and person-level questions separate. A B2B account may contain several people who divide the work. If one teammate connects the source and another delivers the report, a person-level funnel could miss a successful account. Use an account-level funnel when that matches how customers receive value.
| Decision | Observation | Possible next action |
|---|---|---|
| Where is first value blocked? | Accounts progressing from signup to connection to delivery | Observe the step with missing or failed attempts |
| Does the first result take too long? | Elapsed time from account signup to successful delivery | Inspect delays and distinguish waiting from active work |
| Do customers repeat the useful task? | Accounts delivering again in a defined later window | Investigate whether the expected reporting cadence matches use |
| Does a feature help a relevant segment? | Eligible accounts using the feature and their later behavior | Interview users before attributing an outcome to the feature |
| What precedes paid adoption? | Observed behavior before subscription start | Investigate the path without treating correlation as proof |
Create an event contract before adding dashboards
An event contract states when an event fires, which service owns it, its required properties, and what must never be included. Prefer an observable completed action over a vague name such as engaged. In our example, report_delivered fires only after the app records a successful delivery; clicking a send button belongs to a different event if it is needed.
Use stable internal identifiers for the person and account. Define how anonymous activity joins to an authenticated person, how account membership is checked, and how logout or account switching affects attribution. Do not merge records simply because two people share a display name.
Record occurrence time separately from receipt time when deliveries can arrive late. A unique event ID helps identify repeated deliveries. Define how to filter staff, test accounts, and failed operations. Keep report contents, email bodies, access tokens, and other unnecessary payload data out of the tracking plan.
Choose tools against these requirements: account grouping, export access, identity behavior, retention analysis, data controls, and the team's ability to maintain the integration. For one concrete implementation, our PostHog activation guide explains the event and identity checks behind a first funnel.
Work through the downloadable account dataset
The original JSON download contains 29 synthetic events for ten accounts that all signed up on October 1. The fictional observation window ends on October 15, so every account has the same fourteen-day opportunity to complete the measured actions. These values are teaching data, not ShowMeYourSaaS performance or an industry benchmark.
Six accounts connected a source and four delivered their first report during days 1–7. Three of those accounts delivered another report during days 8–14. Two accounts started a subscription by the end of day 14. Count distinct accounts meeting each definition rather than adding all event rows.
The connection rate is 6 / 10 = 60%. First-value activation is 4 / 10 = 40%. The connection-to-delivery step is 4 / 6, approximately 66.7%. Week-two repeat delivery among the original signup cohort is 3 / 10 = 30%; among the four initially activated accounts it is 3 / 4 = 75%. Both repeat figures are valid descriptions of different denominators.
Paid adoption by day 14 is 2 / 10 = 20%. Nothing in this small synthetic table establishes that delivering a report caused a purchase. It also leaves out people who evaluated the product without signing up. Label the cohort, account unit, event definition, and observation window beside every percentage.
Signup accounts: 10 Connected a source in days 1–7: 6 Delivered first report in days 1–7: 4 Delivered again in days 8–14: 3 Started a subscription by day 14: 2 First delivery / all signup accounts = 4 / 10 = 40% Repeat delivery / all signup accounts = 3 / 10 = 30% Repeat delivery / initially activated accounts = 3 / 4 = 75% These percentages use different denominators; keep the labels.
Validate the data at the boundary
Follow a small set of permitted test accounts through the workflow and compare application records with the analytics export. Check a successful completion, a failed attempt, a refresh, a repeated delivery, an account switch, and a delayed event. Confirm that a retry does not become a second customer action.
Reconcile totals with a source that represents the same event. Compare subscription-start records with the billing state transition you defined, rather than a checkout button count. If totals differ, inspect timing, exclusions, and identity rules before declaring one system wrong.
Assign an owner to each event and review the contract when a feature changes. An onboarding redesign may make an old event technically valid while changing its meaning. Record the version and effective date so historical comparisons remain interpretable.
Turn the first report into one investigation
In the fictional example, two connected accounts never delivered a report. Start by inspecting their permitted test traces or inviting relevant users to explain the attempt. A missing event could mean an abandoned task, an application failure, a delayed delivery, or broken tracking. The chart identifies a question; further evidence explains it.
Review repeat behavior on a cadence that fits the customer's task. Weekly reporting software and annual compliance software need different return windows. Our cohort analysis guide explains how to compare groups with equal opportunities to return.
Use the conversion optimization guide when the evidence points to the signup journey. Keep a short decision record: observation, uncertainty, proposed change, expected outcome, and review date. This makes product analytics part of product work rather than a recurring exercise in reading charts.
Download the tracking plan and sample events
The editable tracking plan includes five decision questions, event definitions, identity rules, exclusions, and a validation checklist. The JSON workbook contains the 29 synthetic events, cohort boundaries, and expected account counts so you can reproduce the worked example in your own analysis tool. Sources checked October 27, 2026.