Een webshop die alleen het aankoopevent naar GA4 stuurt, beschikt over een omzetcijfer en verder niets. Geen afhaakpercentage per stap, geen producten die bekeken maar niet toegevoegd zijn, geen analyse van de prestaties van de lijsten. De waarde van GA4 op een webshop komt van de volledige keten, niet van de laatste schakel.
Zeven events volstaan om die keten te reconstrueren.
De zeven events
- view_item_list: weergave van een productlijst, categorie, zoekresultaten, aanbevelingsblok. Hiermee vergelijkt u de prestaties van de locaties onderling.
- select_item: klik op een product vanuit een lijst. Gekoppeld aan het vorige geeft dit het klikpercentage per lijst.
- view_item: raadpleging van een productpagina. De basis van al de rest.
- add_to_cart: toevoeging aan de winkelwagen. Afgezet tegen view_item geeft dit het toevoegpercentage, de nuttigste indicator op productniveau.
- begin_checkout: start van het bestelproces. De grens tussen navigatie en aankoop.
- add_payment_info: keuze van de betaalmethode. Het laatste meetpunt voor de validatie, en het punt dat betalingsgerelateerde afhakers isoleert.
- purchase: gevalideerde bestelling, met het detail van de artikelen.
Een achtste verdient toevoeging wanneer het eenvoudig aan te sluiten is: remove_from_cart, dat de producten signaleert die worden verwijderd op het moment dat de verzendkosten zichtbaar worden.
De artikelstructuur
Al deze events delen dezelfde structuur voor de beschrijving van de artikelen, en de samenhang ertussen maakt het verschil tussen bruikbare data en een onleesbaar rapport.
Vijf parameters tellen per artikel: de identifier, de naam, de categorie, de stuksprijs en de hoeveelheid. Twee andere zijn nuttig: het merk en de variant.
De identifier is het kritieke punt. Hij moet strikt dezelfde zijn in alle events, en vooral identiek aan die in uw productfeed richting Google. Een webshop die in het ene event de referentie stuurt en in het andere de interne identifier, krijgt twee aparte productfiches in de rapporten, voor hetzelfde artikel.
De variant moet expliciet worden behandeld. Beslis of de identifier op het product of op de variant slaat, en houd die regel overal aan. Beide keuzes zijn te verdedigen, de vermenging niet.
Google Tag Pro: Plug & PlayE-commercetracking die geen conversies meer laat liggen.€190,00
Prijzen exclusief of inclusief btw
Een vraag zonder universeel antwoord, die vóór de aansluiting moet worden beslist.
De meest gangbare conventie in Europa is prijzen inclusief btw sturen, omdat dat is wat de klant betaalt en wat op de bestelling staat. Het alternatief, exclusief btw, vergemakkelijkt de afstemming met de boekhouding.
Wat meer telt dan de keuze: dat de waarde van de bestelling op dezelfde manier wordt berekend, en dat u weet welke conventie u heeft aangehouden wanneer u zes maanden later GA4 met uw backoffice vergelijkt.
Twee elementen om uit de transactiewaarde te weren: de verzendkosten en de belastingen worden in aparte parameters gedeclareerd, niet in het totaalbedrag. Ze meetellen blaast de productomzet kunstmatig op.
De klassieke fouten
De aankoop dubbel geteld. De herladen of uit de cache gehaalde bevestigingspagina stuurt het event opnieuw. Veruit de meest voorkomende anomalie, en ze vervalst de omzet naar boven. De bescherming: de bestelling als reeds verzonden markeren, server-side of in lokale opslag, en het event nooit twee keer laten afgaan voor dezelfde transactie-identifier.
De transactie-identifier ontbreekt of is niet uniek. Zonder die kan GA4 niet ontdubbelen. Gebruik de bestelreferentie, nooit een tijdstempel.
De verzendkosten in de waarde. Zie hierboven.
Het aankoopevent afgevuurd voor de validatie van de betaling. Bij een omgeleide betaling kan de bestelling mislukken na het versturen van het event. Het afvuren moet gebeuren op de echte bevestigingspagina, na terugkeer van de betaalprovider.
Naamloze lijsten. Dragen al uw lijsten dezelfde naam, dan zult u nooit weten of uw aanbevelingsblokken werken.
De toestemming
Zonder toestemming mag geen van deze events met identifiers vertrekken. De consent mode laat toe een geaggregeerde meting te behouden bij afwezigheid van toestemming, op voorwaarde dat hij correct is aangesloten en dat de signalen worden doorgegeven voordat de tags laden.
Een praktisch punt dat vaak te laat wordt ontdekt: blokkeert uw cookiebanner de scripts tot de toestemming, dan gaan de events die in die tussentijd afgaan verloren. Voorzie een wachtrij die ze na acceptatie opnieuw afspeelt, in plaats van ze te laten vallen.
Controleren
Drie controleniveaus, in deze volgorde.
De datalayer. Inspecteer in de browserconsole de inhoud ervan bij elke stap en controleer de aanwezigheid en de vorm van de parameters. Daar ziet u de inconsistente identifiers en de slecht geformatteerde prijzen.
De debugmodus van GA4. Die toont de events in realtime met hun parameters, en signaleert de geweigerde. Plaats een volledige bestelling terwijl u dit scherm observeert.
De cijfermatige afstemming. Vergelijk na twee weken het aantal bestellingen en de omzet van GA4 met uw backoffice.
De normale afwijking met de backoffice
Zoek geen perfecte gelijkheid, die bestaat niet. Een afwijking van 5 tot 15% minder in GA4 is te verwachten, en ze is verklaarbaar: geweigerde toestemming, adblockers, privénavigatie, telefonisch opgenomen bestellingen, en klanten die de pagina verlaten voor het versturen van het event.
Wat u moet alarmeren is een afwijking van meer dan 25%, of een positieve afwijking, waarbij GA4 meer bestellingen telt dan uw backoffice. Het tweede wijst vrijwel altijd op een dubbele telling.
De Google Tag Pro module voor PrestaShop sluit deze keten aan op PrestaShop 8 en 9: de e-commerce-events met een samenhangende artikelstructuur, de bescherming tegen het dubbel versturen van de aankoop, en de koppeling met de toestemming.