GuideIntermediate

Product Analytics Instrumentation

Knowing which metric to watch is useless if the data behind it is recorded badly. This guide covers the other half: how a product ends up measured. You write the tracking plan from the decisions that need to be made, name and version every event with a schema that is validated on the way in, connect the anonymous visitor with the user who signs up, compute funnels and retention in SQL over your own events table, control a feature with an open feature flag SDK, log experiment exposure so the analysis is valid, clean the data (duplicates, lost events, bots, broken clocks), and decide whether recording sessions is worth its privacy cost. You learn it by instrumenting **Turnito**, a fictional booking app for barbershops, tattoo studios, and salons in Latin America and the United States. You are asked to "measure onboarding" and find that the existing `track("click")` calls answer nothing. Ten simulated weeks of Turnito flow through your collector: more than 130,000 events with the problems real data has. The naive funnel says there are more bookings than shared links, the onboarding checklist experiment looks like a win until a sample ratio check exposes a logging bug, and the session replay stores a client's phone number nobody meant to record. Everything runs on your laptop with Docker: Postgres 18, flagd (the OpenFeature flag server), and Python with `uv`. You use no accounts and no external services. The data is synthetic and deterministic: every query returns exactly what the guide shows.