PostHog instellen
voor product analytics zonder data scientist.
Eén vraag, volledig beantwoord: welke events zet je als eerste in PostHog voor een B2B-SaaS, en hoe bouw je daar een activatie-funnel op die je durft te laten zien. Inclusief de fouten die in de meting zelf zitten en de dingen die je beter niet meet.
Q1PostHog of Mixpanel?+
Q2Waar begin ik als er nog niets staat?+
Welke events definieer je als eerste
Een event is een gebeurtenis met een tijdstip, een persoon en een paar eigenschappen. De verleiding is om alles te vangen wat beweegt. Doe dat niet. Een event verdient zijn plek als er een beslissing van afhangt: als het cijfer twee keer zo hoog of twee keer zo laag zou zijn, zou je dan iets anders doen? Voor een B2B-SaaS blijven er dan ongeveer zeven over.
Spreek eerst één schrijfwijze af en wijk daar niet van af: eerst het object, dan de handeling, in de verleden tijd, met underscores. Dus workspace_created, niet Create Workspace en niet createWorkspace. PostHog corrigeert je naamgeving niet. Twee schrijfwijzen worden twee losse events, en dat merk je pas als een funnel op nul staat.
Event: wat er gebeurde (invite_sent). Property: de context bij die gebeurtenis (rol: beheerder). Person: de gebruiker aan wie PostHog de events hangt, via een distinct_id. Group: het bedrijf waar die gebruiker bij hoort. In B2B is het bedrijf vaak de eenheid die telt, niet de losse gebruiker.
| Event | Waar je hem vuurt | Properties | Waarvoor |
|---|---|---|---|
signup_completed | Server, nadat het account echt is weggeschreven | bron, plan, via_uitnodiging | Instroom en de eerste funnelstap |
workspace_created | Server, bij het aanmaken | via_sjabloon | De eerste stap van de inrichting |
data_connected | Server, na een geslaagde testaanroep van de koppeling | integratie | Vaak de echte activatiestap |
teammate_invited | Server, bij de verzonden uitnodiging | aantal | Signaal dat het geen eenmansaccount blijft |
invite_accepted | Server, bij het aangemaakte tweede account | dagen_na_uitnodiging | Verspreiding binnen het bedrijf |
rapport_gepubliceerd | Server, bij de succesrespons | duur, bron | Jouw kernhandeling: noem hem naar je eigen product |
subscription_started | Server, vanuit de webhook van Stripe | plan, interval | Omzet naast gedrag leggen |
Twee regels bij het vuren. Eén: vuur op de plek waar je weet dat het gelukt is. Een klik op "Opslaan" is geen opgeslagen rapport, de succesrespons van je eigen API wel. Twee: vuur server-side waar dat kan. Wat vanuit de browser vertrekt wordt door adblockers en tracking-preventie deels tegengehouden, en dat verlies is niet gelijk verdeeld over je gebruikers.
Koppel de gebruiker aan zijn persoon zodra hij inlogt, en zet het bedrijf er als group bij. Zonder dat laatste kun je in B2B alleen vragen beantwoorden die met "hoeveel gebruikers" beginnen, en niet die met "hoeveel klanten" beginnen. Group analytics zit niet in elke laag van PostHog, dus controleer dat vóór je je meetplan erop bouwt.
De activatie-funnel opzetten
Activatie is geen standaardstatistiek maar een keuze die jij maakt. Schrijf hem op als één zin, met een handeling en een tijdvenster: "een werkruimte is geactiveerd als er binnen zeven dagen een koppeling draait en één rapport is gepubliceerd." Zonder die zin betekent het percentage elk kwartaal iets anders.
1Insight aanmaken+
2Stappen kiezen+
signup_completed, workspace_created, data_connected, je kernhandeling. Laat stappen weg die iedereen sowieso passeert, want die verbergen waar het echt misgaat.3Tijdvenster zetten+
4Uitsplitsen+
5Doorklikken naar personen+
Zet er twee insights naast en niet meer: een retention-weergave (komen ze terug na die eerste week) en een trend op je kernhandeling per week. Een dashboard met tien grafieken leest niemand, ook jijzelf niet.
Waar het in de meting zelf misgaat
De meeste vreemde uitkomsten komen niet doordat gebruikers zich anders gedragen, maar doordat de meting stuk is. Loop deze lijst langs voordat je iets concludeert.
Wat je beter niet meet
- Autocapture als basis voor je funnel. Prima om rond te kijken, ongeschikt als fundament: je meet dan hoe je knoppen heten in plaats van wat er gebeurde.
- Scrolldiepte en elke muisklik. Kost opslag, levert zelden een beslissing op.
- Totalen zonder noemer. "Aantal events deze maand" stijgt vanzelf zodra je meer gebruikers hebt en zegt op zichzelf niets.
- Percentages op een handvol mensen. Met een paar personen per stap noem je aantallen, geen procenten, anders praat je over ruis.
- Omzet als waarheid in PostHog. De waarheid over geld staat in je facturatiesysteem. Stuur hooguit het abonnementsevent mee, zodat je gedrag en plan naast elkaar ziet.
- Alles "voor het geval dat". Elk event dat niemand kan uitleggen wordt over drie maanden verkeerd geïnterpreteerd.
PostHog naast GA4 en je eigen database
PostHog beantwoordt vragen over gedrag in je product. GA4 beantwoordt vragen over de kanalen ervoor en is de plek waar Google Ads zijn conversies vandaan haalt. Je eigen database beantwoordt vragen over geld. Die drie in één systeem willen persen is de duurste manier om alsnog niets te weten. Voor de marketingkant: GA4 instellen voor een SaaS.
Twee dingen controleer je bij de bron, omdat ze verschuiven en dit stuk ze niet actueel kan houden. Eén: waar de gratis laag ophoudt en wat daarboven per event of per opname gerekend wordt. Twee: hoe je aan de EU-kant blijft. PostHog heeft een EU-regio; zelf hosten kan met de open-source versie, maar PostHog stuurt teams zelf richting hun cloud, dus zelf hosten is een bewuste keuze met eigen beheerkosten. Beide staan in hun eigen documentatie en op hun prijspagina, en dat is de enige bron die klopt op de dag dat je kiest.
Veelgestelde vragen
Q1Hoeveel events heb ik nodig om te beginnen?+
Q2Client-side of server-side vuren?+
Q3Ik heb al een halfjaar verkeerd benoemde events. Hernoemen?+
Q4Hoe houd je dit bij met een klein team?+
Q5Hoe zit het met de AVG?+
Hoe we dit in een project opzetten
Het begint bij ons met een bestand van één pagina: de zeven events, hun eigenschappen, en de plek in de code waar ze gevuurd worden. Dat bestand staat in dezelfde repository als het product, zodat een wijziging in de meting door dezelfde review gaat als een wijziging in de code. Daarna één pull request die de capture-aanroepen toevoegt, een apart project voor staging, en twee weken later een half uur met het team om te kijken welke van de zeven niemand gebruikt. Die halen we eruit.
Wat we niet doen is een dashboard opleveren met cijfers waar niemand een beslissing aan hangt. Wil je dit voor je eigen product laten opzetten, dan staat op de pagina over marketingautomatisering wat dat inhoudt en hoe de prijs tot stand komt.