De meeste funnels meten het product, niet de gebruiker
Open een doorsnee analysetool en je ziet funnels die zijn opgebouwd uit precies die events die het engineeringteam toevallig heeft geïnstrumenteerd: route_loaded, account_created_v2, modal_opened. Technisch kloppen ze, maar voor productbeslissingen heb je er bijna niets aan, want ze beschrijven wat de software deed, niet wat de gebruiker probeerde te doen. Een funnel die je codebase meet, vertelt je wanneer een component werd gerenderd; een funnel die intentie meet, vertelt je waar iemand het opgaf.
De oplossing: bouw je funnels achterstevoren op vanuit waargenomen gedrag — en toets elke stap aan echte opnames voordat je ook maar één cijfer vertrouwt. Zo pak je dat aan.
Benoem stappen naar gebruikersintentie
De beste funnels lezen als een user story: komt op prijzen → begint met aanmelden → maakt workspace aan → installeert snippet → ziet eerste opname. Elke stap beschrijft voortgang vanuit het perspectief van de gebruiker. Interne labels als account-created-v2 of dashboard-route-loaded zijn handig in code, maar ze verbergen de intentie zodra je als team naar het product kijkt.
Als een funnel in gebruikerstaal is benoemd, ziet iedereen het gat sneller. Maken veel gebruikers wel een workspace aan maar installeren ze de snippet niet, dan is de volgende vraag vanzelfsprekend — en heb je geen analist nodig om het te vertalen. Een simpele test: als een nieuwe collega je funnelstappen niet hardop kan voorlezen en meteen het doel van de gebruiker snapt, zijn de stappen benoemd voor engineers, niet voor beslissingen.
Toets elke stap aan opnames
Voordat je een funnel als waarheid aanneemt, bekijk je sessies rond elke overgang. De meest voorkomende funnelfouten zitten niet in de grafiek — ze zitten in de eventdefinities die hem voeden:
- Vuurt te vroeg: het event wordt getriggerd zodra een component rendert of een route laadt, niet wanneer de gebruiker de actie daadwerkelijk afrondt — waardoor die stap wordt opgeblazen en het lek eronder verborgen blijft.
- Vuurt te vaak: een retry, re-render of dubbele verzending telt dezelfde gebruiker twee keer, waardoor de conversie er beter uitziet dan ze is.
- Vuurt om de verkeerde reden: het event legt een neveneffect vast in plaats van de bedoelde succestoestand.
Sessieopnames zijn de snelste manier om eventdefinities te betrappen die in een dashboard kloppen maar in de praktijk niet. Bekijk drie sessies per overgang; sluit het event aan op wat de gebruiker duidelijk van plan was, dan kun je de stap vertrouwen. Zo niet, herstel dan eerst de definitie voordat je iets met de data doet.
Lees de uitval af en ga hem dan bekijken
De taak van een funnel is niet om een getal te tonen — het is om je te wijzen op de opnames die dat getal verklaren. Lekt een stap, ga dan niet herontwerpen op onderbuikgevoel. Filter op gebruikers die die stap haalden en toen afhaakten, bekijk vijf van hun sessies, en meestal vind je een van een handvol oorzaken:
- Een validatiefout of uitgeschakelde knop zonder uitleg.
- Een verplicht veld of een recht dat de gebruiker niet had en niet kon regelen.
- Een moment van verwarring — de volgende actie stond niet waar ze keken.
- Helemaal niets mis: ze kregen wat ze nodig hadden en vertrokken tevreden (een “lek” dat er geen is).
Dat laatste geval laat zien waarom funnels op zichzelf misleiden. Het getal zegt “uitval”; de opname zegt “geslaagd.” Alleen samen vertellen ze de waarheid.
Houd één activatiefunnel heilig
Kleine teams houden het best bij één kernactivatiefunnel en bespreken die wekelijks. Weersta de neiging om een tiental overlappende funnels te maken — die versnipperen de aandacht en laten iedereen de grafiek kiezen die zijn eigen project vleit. Eén scherpe funnel geeft je een gedeeld ritme: wat is er deze week veranderd, waar bewoog de conversie, en welke sessies verklaren die beweging?
Rondom die ene heilige funnel kun je prima kortstondige wegwerpfunnels opzetten voor specifiek onderzoek, en ze daarna archiveren. De discipline zit in één cijfer dat het hele team vertrouwt en waar het steeds op terugkomt, niet in zoveel mogelijk dashboards.
Veelgestelde vragen
Moeten funnelstappen paginaweergaven of events zijn?
Events, bijna altijd. Paginaweergaven beschrijven navigatie, geen prestatie — een gebruiker kan de “gelukt”-pagina laden zonder dat het gelukt is, of iets voltooien in een single-page app zonder ook maar één navigatie. Definieer stappen als de events die echte gebruikersintentie weergeven.
Hoeveel stappen moet een funnel hebben?
Zo weinig als nodig om het verhaal te vertellen — meestal vier tot zes. Elke stap moet een betekenisvol beslismoment zijn. Converteren twee opeenvolgende stappen altijd samen, voeg ze dan samen; het gat ertussen leert je niets.
Waarom lijkt mijn funnelconversie slechter dan de werkelijkheid?
Meestal vuurt een stap te vroeg of telt hij dezelfde gebruiker meerdere keren, of je ontdubbelt niet op gebruiker. Toets elk event aan opnames en controleer of je unieke gebruikers meet en niet ruwe events.
Heb ik session replay nodig om funnels goed te gebruiken?
Je kunt funnels ook zonder gebruiken, maar dan blijf je gissen naar oorzaken. Juist door elke uitval te koppelen aan de opnames erachter verandert een funnel van statusrapport in een bron van oplossingen. Zie session replay zonder ruis.