Het trackingplan voor start-ups

Wat een trackingplan is

Een trackingplan is één document met elk event dat je product vastlegt, de eigenschappen bij elk event, het precieze moment waarop het afgaat en de persoon die ervoor verantwoordelijk is. Het is het contract tussen de code die data uitstuurt en de dashboards die ze lezen. Behandel het als een levende specificatie die meebeweegt met het product, niet als een document dat je één keer schrijft en vergeet. De korte versie staat bij trackingplan; deze gids gaat over hoe je er een opstelt.

Waarom een plan beter werkt dan tracking zonder plan

Zonder plan woekert tracking. De ene engineer stuurt signup, de tweede Sign Up, een derde user_registered – drie namen voor één handeling, en elke funnel die de aanmelding raakt, splitst of breekt zonder dat iemand het merkt. Dat heet drift, en het is de belangrijkste reden dat niemand de analyses nog vertrouwt. Een plan legt de woordenschat vast voordat de code live gaat, zodat de cijfers die je over zes maanden ophaalt nog betekenen wat je denkt. Schone, consistente events zijn ook waar een experimentenroadmap op draait – je kunt een test niet meten tegen een metric die je op drie manieren vastlegt.

Benoem events als object_action en houd je eraan

De conventie die de meeste analysetools aanraden, is object_action: eerst het ding, dan wat ermee gebeurde – subscription_started, invite_sent, checkout_completed. Segment, Amplitude en PostHog beschrijven elk een variant (Segment gebruikt “Object Action”, PostHog snake_case in kleine letters, Amplitude een zelfstandig naamwoord plus een werkwoord in de verleden tijd). De precieze schrijfwijze doet er veel minder toe dan er één kiezen en daar nooit van afwijken. Twee regels leveren het meeste op: houd de werkwoordstijd consistent en bouw eventnamen nooit dynamisch op – een event met de naam plan_${name}_upgraded maakt één event per klant aan en is niet meer te bevragen.

De 8–10 events die je funnel in kaart brengen

Weersta de neiging om alles te tracken. Begin met het handvol events dat een gebruiker volgt van het eerste contact tot betalen – aanmelding, activatie en omzet – en leg die goed vast voordat je de diepte in gaat. Hieronder staat een startset voor een doorsnee B2B-SaaS; hernoem ze naar de zelfstandige naamwoorden van je eigen product. Elk event wordt een rij in je plan, en samen vormen ze je eerste first-party dataset – het ruwe materiaal voor elke funnel, elk cohort en elke retentiecurve die je gaat bouwen. Waar je elk event vastlegt – in de browser of op de server – is een aparte beslissing: server-side vs. client-side tracking behandelt die keuze.

Eigenschappen dragen het detail; eigenaren houden het schoon

Beperk je tot weinig, algemene events; stop de specifieke details in eigenschappen. Stuur in plaats van een apart event per abonnement subscription_started met de eigenschappen plan_name en amount_usd – één event, rijk beschreven, blijft te bevragen. Houd de set eigenschappen per event klein – een handvol die je echt bevraagt, is beter dan tientallen die je nooit gebruikt. Bepaal daarna het eigenaarschap: in de meeste kleine teams ligt dat bij een Growth Engineer of bij wie de instrumentatie bouwt, en elk nieuw event hoort via die persoon te gaan, zodat plan en code nooit uit elkaar lopen. Weet ten slotte waar de events terechtkomen. Ze naar een gehoste analysetool of CDP sturen is snel, maar zet je gedragsdata op de servers van een ander; ze first-party houden – zelf gehoste Postgres, je eigen datawarehouse – houdt ze van jou, en dat is de kern van de afweging tussen open source en SaaS voor engagementtools.