What product analytics infrastructure is and why it matters
Product analytics infrastructure is the system of event tracking, data pipelines, and analysis tools that turns raw user behavior into product decisions. It's the difference between "I think users like the new feature" and "63% of users who saw the new feature completed the onboarding flow, compared to 41% in the control group." Every data-driven product decision — from A/B test analysis to retention curves to funnel optimization — depends on this infrastructure being correct, complete, and queryable.
Most product teams inherit a messy analytics setup: events named inconsistently (click_button vs buttonClicked vs btn_click), properties missing from critical events, duplicate tracking from multiple SDKs, and no documentation of what events exist or what they mean. This isn't a technical debt problem — it's a decision quality problem. Bad tracking data produces bad insights, which produce bad product decisions, which compound over time. The PM who fixes analytics infrastructure doesn't just fix tracking — they fix every decision that depends on data.
The PM's role isn't implementing the tracking code — it's owning the tracking plan: deciding what events to track, what properties to attach, what naming conventions to enforce, and what data quality standards to maintain. You're the editor of the data dictionary, not the author of the JavaScript snippets.
Event tracking architecture
A well-structured tracking plan has three layers. The event layer captures what happened: page_viewed, button_clicked, purchase_completed. The property layer captures context: which page, which button, what was purchased, from which campaign. The identity layer connects events to users across devices and sessions: anonymous IDs, user IDs, device IDs, and the stitching logic that connects them.
The most common architectural decision is Customer Data Platform (CDP) vs. direct integration. A CDP (Segment, RudderStack, mParticle) sits between your product and your analytics tools. You send events once to the CDP, and it routes them to every downstream tool (Amplitude, Mixpanel, data warehouse, ad platforms). Direct integration means connecting each tool individually — simpler for one tool, unmaintainable for five. If you use more than two analytics-adjacent tools, a CDP pays for itself in reduced engineering maintenance.
Building and maintaining a tracking plan
Event Naming Convention Core Method
Use when: starting a new product or cleaning up an existing tracking mess.
Choose one convention and enforce it religiously. The most common pattern is Object-Action in snake_case: page_viewed, button_clicked, form_submitted, purchase_completed. The object is the thing being acted on, the action is what happened. This reads naturally ("a page was viewed") and groups related events alphabetically in your analytics tool.
Rules to establish: (1) Always past tense for the action (clicked not click), (2) Always snake_case (no camelCase, no spaces), (3) No product-specific jargon in event names — use generic terms that survive redesigns (cta_clicked not hero_blue_button_clicked), (4) Prefix with product area for multi-product companies (checkout_form_submitted). Document every event in a shared tracking plan spreadsheet or tool (Avo, Amplitude Data, Iteratively).
Tracking Plan Audit Technique
Use when: inheriting an existing analytics setup or suspecting data quality issues.
Export your current event list from your analytics tool. For each event, answer: (1) Is anyone looking at this event? (Check dashboards, saved reports, alerts.) (2) Is the event named consistently with your convention? (3) Are the required properties present on every event instance? (4) Is the event firing from the right trigger? (Test it yourself.) Events that fail on #1 are candidates for removal. Events that fail on #2-4 need fixing. Most audits find that 30-50% of tracked events are unused, misnamed, or broken.
Property Standardization Core Method
Use when: event properties are inconsistent across events or teams.
Create a global property dictionary — a list of standard property names with definitions and expected values. For example: page_name (string, the human-readable page title), source (enum: organic, paid, referral, direct), experiment_id (string, the ID of any active experiment), user_plan (enum: free, pro, enterprise). Every event that involves a page should use page_name, not pageName on one event and current_page on another. This consistency is what makes cross-event analysis possible.
Practical tip
Track events at the moment of user intent, not at the moment of system response. Track checkout_started when the user clicks "Buy now," not when the payment processor responds. Track search_performed when the user submits the query, not when results render. This way, even if the system fails (payment error, search timeout), you still have the intent data — which is often more valuable than the outcome data.
Analytics tool selection
Analytics Stack Decision Matrix Framework
Use when: choosing analytics tools for a new product or evaluating a switch.
The modern analytics stack has four components: (1) Product analytics (Amplitude, Mixpanel, PostHog) — funnels, retention, user behavior. (2) Web analytics (GA4, Plausible, Fathom) — traffic sources, page views, sessions. (3) Session replay (FullStory, Hotjar, PostHog) — watch actual user sessions to understand qualitative behavior. (4) Data warehouse (BigQuery, Snowflake, Redshift) — store raw event data for custom analysis.
Early-stage products need #1 only (pick one product analytics tool). Growth-stage products add #2 and #3. Enterprise products add #4 for custom analysis and compliance. The trap is buying all four too early — you'll spend more time configuring tools than analyzing data.
Evaluate tools on: data model flexibility (can you track custom events and properties?), query performance (how fast are funnel queries on your data volume?), collaboration features (can PMs self-serve or do they need an analyst?), pricing model (per-event, per-user, or flat?), and data export (can you get raw data out if you switch tools?).
Data quality and governance
Data Quality Scorecard Core Method
Use when: assessing whether your tracking data is trustworthy enough for decisions.
Score your data quality across five dimensions:
- Completeness — are all critical events tracked? Check against your user journey map; every key interaction should have a corresponding event.
- Accuracy — do events fire at the right time with correct properties? Spot-check by performing actions yourself and verifying in the analytics tool.
- Consistency — are naming conventions followed? Export your event list and check for deviations.
- Timeliness — how quickly do events appear in your analytics tool? For A/B tests, delays over 1 hour can delay decisions.
- Uniqueness — are there duplicate events from multiple SDKs or re-renders? Check event counts against expected volumes.
Score each dimension 1-5 and set a threshold: 4+ on all dimensions means you can trust the data for decisions. Below 3 on any dimension means you should fix the data before making decisions from it.
Tracking Plan Review Process Technique
Use when: new features ship and need tracking, or tracking debt accumulates.
Add a tracking plan review to your feature development process. Before a feature ships, the PM specifies which events to add (with names, properties, and triggers). An engineer implements the tracking. A QA step verifies events fire correctly in staging. After launch, the PM confirms events appear in the analytics tool with expected volumes. This takes 30 minutes per feature — far less than the hours spent debugging bad data after the fact.
Common mistake
Tracking everything "just in case." Every event adds code complexity, increases data storage costs, and makes the analytics tool harder to navigate. If you can't name the dashboard or analysis where an event will be used, don't track it. You can always add tracking later; removing tracking that's already being depended on is much harder.
Identity resolution and user stitching
Identity Resolution Strategy Technique
Use when: users interact across devices, sessions, or authentication states.
Users generate events before they log in (anonymous browsing), after they log in (authenticated), and sometimes across multiple devices (phone, desktop, tablet). Identity resolution stitches these separate event streams into a single user profile. The basic approach: assign an anonymous ID on first visit, then when the user logs in, call identify(userId) to merge the anonymous history with the known user.
Complications arise with: shared devices (a family computer produces one anonymous ID for multiple users), account switching (a user logs into two accounts on the same device), and privacy regulations (GDPR requires you to delete all data for a user, including stitched anonymous history). Design your identity model before you have millions of events — retrofitting identity resolution is one of the hardest analytics infrastructure problems.
Real-world examples
Case study
Amplitude's own analytics journey
Amplitude, the analytics company, has published extensively about their own internal tracking evolution. Early on, they tracked thousands of events with no naming convention. As they scaled, they invested in a formal taxonomy, implemented automated data quality checks that alert when event volumes deviate from expected ranges, and built internal tooling to validate tracking plan compliance at build time. Their key insight: the analytics product is only as good as the data that goes into it.
Why it works: They treated analytics infrastructure as a product in itself — with its own roadmap, quality standards, and dedicated ownership. The PM who owns the tracking plan has the same authority as the PM who owns a user-facing feature.
Case study
PostHog: Open-source analytics with built-in governance
PostHog combines product analytics, session replay, feature flags, and A/B testing in one platform. Their approach to analytics infrastructure is notable because they built data governance into the tool itself: event definitions with descriptions and tags, automated detection of unused events, and a built-in tracking plan that engineers reference when implementing events. By co-locating the tracking plan with the analytics tool, they reduced the "tracking plan is a spreadsheet nobody reads" problem.
Why it works: Governance works when it's embedded in the workflow, not layered on top of it. If engineers have to check a separate spreadsheet, they won't. If the tracking plan lives in the same tool where they see the data, they will.
Common pitfalls
No single owner of the tracking plan
When "everyone owns tracking," no one does. Naming conventions drift, properties go missing, and events accumulate without documentation. Assign one PM or analyst as the tracking plan owner with authority to reject non-compliant implementations.
Confusing pageviews with engagement
Web analytics tools count pages viewed, but that tells you nothing about value delivered. A user who views 10 pages and bounces is less valuable than one who views 2 pages and completes a purchase. Instrument business outcomes, not just navigation events.
Migrating analytics tools without a tracking plan
Switching from Mixpanel to Amplitude (or vice versa) without first documenting your tracking plan means you'll recreate the same mess in a new tool. Clean your tracking plan first, then migrate the clean version.