Conversies na campagne-einde correct volgen

Omzet per kalenderdag koppelt een bedrag aan de dag waarop het binnenkwam, niet aan wat het veroorzaakte. Bij een campagne ontstaat daardoor verschuiving: sommige klanten beslissen na het zien van een advertentie of mail pas dagen later. Hun aankoop landt dan in de periode na de campagne en wordt daar niet meer aan toegeschreven.

Twee gevolgen zijn herkenbaar. De campagneperiode kan er slechter uitzien dan ze is, terwijl de periode erna meeprofiteert zonder dat je het merkt. En een vergelijking tussen twee campagnes van verschillende lengte of seizoen wordt oneerlijk als je ze op kalenderdagen afzet. Een cohort kan dat verminderen door een groep te volgen vanaf een vast startmoment, op voorwaarde dat je die groep betrouwbaar kunt herkennen en koppelen aan latere conversies.

Een cohort is de groep personen die in een afgebakend venster voor het eerst met je campagne in aanraking kwam. De observatieduur is de vaste periode waarin je die groep daarna volgt. Leg beide vast vóór je naar de cijfers kijkt, anders kies je achteraf wat flatteert.

1. Bepaal het cohortvenster: bijvoorbeeld iedereen die tijdens de campagne via een bepaald kanaal binnenkwam. Controleer vooraf of je die personen of bezoeken in je eigen gegevens kunt herkennen (bijvoorbeeld via campagneparameters in de link) en zo later aan hun conversie kunt koppelen.
2. Kies één observatieduur en gebruik die voor elke campagne die je vergelijkt. Welke duur logisch is hangt af van hoe lang jouw klanten over een beslissing doen; een duur die voor een webshop past, hoeft niet te passen voor een dienstverlener met offertes.
3. Schrijf de definities op in een document dat je later kunt terugvinden.
4. Tel pas na afloop van de volledige observatieduur. Een cohort dat nog loopt is onvolledig en mag je niet met een afgerond cohort vergelijken.

De duur is jouw keuze op basis van je eigen verkoopproces. Er bestaat geen universele termijn die voor elk bedrijf klopt.

Een cohortanalyse is niets waard als de onderliggende metingen ontbreken. De Google Analytics-documentatie beschrijft een gebeurtenis als een manier om een specifieke interactie op je website of in je app te meten, zoals een paginaweergave, een klik of een aankoop (uitleg over gebeurtenissen in Google Analytics). Ze onderscheidt automatisch verzamelde gebeurtenissen, gebeurtenissen van verbeterde meting, aanbevolen gebeurtenissen en aangepaste gebeurtenissen. Aanbevolen en aangepaste gebeurtenissen moet je zelf implementeren om ze in Analytics te zien.

Controleer dus drie dingen:

• Welke handeling geldt voor jou als conversie, en is daar een gebeurtenis voor ingesteld?
• Is die gebeurtenis gemarkeerd als belangrijke gebeurtenis, zodat ze in je rapporten als zodanig verschijnt? Waar je dat in jouw account instelt, controleert de beheerder in de interface, want schermnamen en opties kunnen wijzigen.
• Komt de gebeurtenis binnen? De documentatie noemt het Realtime-rapport en het rapport DebugView als manieren om te zien of een gebeurtenis en haar parameters zijn verzameld. Dat is een testcontrole voor één gebruiker. Een gebeurtenis (zoals een aankoop) bewijst nog geen echte aanvraag of betaling: vergelijk de aantallen periodiek met de bestellingen of aanvragen in je eigen systeem. Offline opgeslagen gebeurtenissen die meer dan 2 kalenderdagen na activering binnenkomen, worden volgens de documentatie genegeerd.

Voor webshops beschrijft de ontwikkelaarsdocumentatie van Google Analytics dat je ecommercegebeurtenissen kunt instellen om winkelgedrag te verzamelen, zoals het bekijken van een product, het toevoegen aan een winkelmandje, het starten van de checkout en een aankoop (handleiding ecommerce-meting in Google Analytics). Die documentatie raadt onder meer aan om bij het meesturen van een waarde de valuta op gebeurtenisniveau in te stellen en om elke ecommerceparameter waarover je gegevens hebt mee te sturen, ook als die optioneel is.

Voor je campagnevergelijking betekent dit dat je overal dezelfde structuur hanteert. Gebruik dezelfde gebeurtenisnaam, dezelfde valuta en dezelfde parameters voor elke campagne. Wijzig je halverwege de implementatie, noteer dan de datum, zodat je weet welke cohorten onderling vergelijkbaar zijn. Zet de debugmodus aan om na elke wijziging te zien of de gebeurtenissen met de juiste parameters binnenkomen. Stuur geen persoonsgegevens mee in parameters of URL's.

Gebruik deze checklist voordat je een conclusie trekt over een campagne.

• Is het cohortvenster vooraf vastgelegd en voor beide campagnes gelijk gedefinieerd?
• Is voor beide dezelfde observatieduur volledig verstreken?
• Gebruikten beide campagnes dezelfde conversiegebeurtenis en dezelfde parameters?
• Veranderde er tijdens de periode iets aan je website, prijzen of meting dat de vergelijking verstoort?
• Hebben beide cohorten voldoende gebeurtenissen om iets uit af te leiden, of gaat het om enkele gevallen?
• Heb je rekening gehouden met seizoen, feestdagen of andere campagnes die tegelijk liepen?

Zijn er meerdere nee-antwoorden, stel je conclusie dan uit of formuleer ze voorzichtig. Een cohortvergelijking toont een verband in jouw gegevens, geen bewezen oorzaak.

Een fictief voorbeeld met uitsluitend invoer en verwachte controles. Stel dat je twee campagnes vergelijkt met dezelfde definitie: cohort is iedereen die via de campagne binnenkwam, observatieduur is voor beide gelijk en vooraf gekozen. Campagne A loopt in een rustige maand, campagne B in een drukke maand.

Invoer: per cohort het aantal personen en het aantal conversiegebeurtenissen binnen de observatieduur. Verwachte controles: bereken per cohort de conversies gedeeld door het aantal personen in dat cohort, zodat de groottes vergelijkbaar worden. Controleer daarna of campagne B niet gewoon profiteert van de drukke maand door ook een periode zonder campagne uit hetzelfde seizoen te bekijken. Concrete uitkomsten volgen uit jouw eigen gegevens; dit voorbeeld toont enkel de werkwijze.

De bronnen beschrijven hoe je gebeurtenissen instelt en controleert, niet hoe je een cohortrapport bouwt of welke observatieduur voor jou geschikt is. Hoe je dit in je eigen account configureert, controleert de beheerder in de interface.

Wil je bekijken welke signalen je website publiek toont? Doe dat via Marketing Scan. Een publieke scan meet zichtbare signalen en controleert niet of je meting volledig juist is ingesteld.