Boekingsdomein en hoofdwebsite als één meetreis

Begin met een blad, niet met een tool. Schrijf de route op die een bezoeker aflegt: de pagina waar die binnenkomt, de pagina waar die beslist om te boeken, het boekingsdomein en de bevestigingspagina. Markeer elke plek waar het domein verandert. Dat zijn je overgangen, en elke overgang is een afzonderlijk risico.

Noteer per overgang het type element: gewone link, knop met script, formulier, ingebedde widget of een doorverwijzing via een server. Zo'n element kan zich anders gedragen als het gaat om parameters in de url. Een ingebed boekingsvenster gedraagt zich bovendien anders dan een volledige paginawissel.

Koppel daarna aan elke stap de gebeurtenis die je wilt zien. Een gebeurtenis meet volgens de uitleg over Analytics-gebeurtenissen een specifieke interactie, zoals een paginalading, een klik op een link of een aankoop. Schrijf dus bij elke stap één verwachte gebeurtenis op. Zonder die lijst kun je later niet zeggen wat ontbreekt.

De ontwikkelaarsgids voor gebeurtenissen deelt gebeurtenissen in vier groepen in: automatisch verzameld, verbeterde meting, aanbevolen en aangepast. Een gebeurtenis die je zelf met gtag verstuurt, moet onder de Google-tag op de pagina staan, want gebeurtenissen erboven worden volgens de gids niet verwerkt. Dat is een concrete controle op elk domein.

Wat de aangeleverde fragmenten niet beantwoorden, is of je twee domeinen als één reis samenvoegt en hoe je dat instelt. Veronderstel dus niets. Je beheerder of webbouwer controleert in de documentatie en de instellingen van jullie eigen opzet hoe domeinen worden gekoppeld. Exacte schermnamen en rechten kunnen wijzigen, dus verzin die niet vooraf.

Gebruik de test hieronder om te meten wat er werkelijk gebeurt. De test bewijst alleen het gedrag van jouw opzet op het moment van testen, niet een algemene regel.

1. Open een nieuw privévenster zonder extensies die scripts blokkeren en ga naar de landingspagina op de hoofdwebsite.
2. Zet de foutopsporingsmodus aan voor jouw browsersessie. De bron zegt dat DebugView extra configuratie vraagt. De beheerder controleert hoe dat in jullie opzet gebeurt.
3. Open DebugView en het Realtime-rapport in een ander venster. DebugView toont de gebeurtenissen van één gebruiker, het Realtime-rapport de gebeurtenissen van de afgelopen 30 minuten.
4. Klik op de overgangslink naar het boekingsdomein. Kopieer de volledige url zodra de nieuwe pagina laadt en noteer of er extra parameters achter staan.
5. Doorloop op het boekingsdomein één stap in de reis, bijvoorbeeld een beschikbaarheid bekijken.
6. Kijk in DebugView of de gebeurtenissen van beide domeinen in dezelfde stroom van deze ene testgebruiker verschijnen, of dat het boekingsdomein als aparte gebruiker opduikt.
7. Noteer per stap: verwachte gebeurtenis, gezien ja of nee, parameters aanwezig ja of nee.

Herhaal de test voor elk type overgangselement dat je in de eerste sectie hebt opgelijst, want een knop met script kan anders reageren dan een gewone link.

Een bezoeker kan op de hoofdwebsite een keuze maken en op het boekingsdomein opnieuw een toestemmingsvraag zien. Of de keuze meegaat, hangt af van hoe jullie toestemmingstool is opgezet. Dat weet je niet vooraf. Test daarom beide keuzes, en laat de beoordeling van wat wettelijk vereist is aan een juridisch adviseur.

Gebruik je testblad om een van deze uitkomsten te kiezen, niet om meteen alles te herbouwen.

• De url krijgt een extra parameter en beide domeinen verschijnen in dezelfde DebugView-stroom: dit is een aanwijzing dat de overgang in deze ene test werkte, geen bewijs. Herhaal de test en test de andere overgangselementen.
• De url blijft schoon en het boekingsdomein verschijnt als aparte gebruiker: de koppeling werkt in deze test niet. Laat de beheerder de koppeling van domeinen in jullie opzet nakijken.
• De parameter staat er, maar het boekingsdomein stuurt geen gebeurtenissen: controleer of de Google-tag er staat en of eigen gebeurtenissen onder de tag geplaatst zijn.
• Een widget of formulier verwijdert de parameter: gebruik voor dat element een andere overgangsvorm of laat de leverancier de url-afhandeling uitleggen.
• De bevestigingspagina meldt een aankoop zonder valuta of items (een aankoopgebeurtenis bewijst bovendien niet dat de boeking of betaling is afgerond): de gids voor e-commerce raadt aan de valuta op gebeurtenisniveau mee te geven bij waardegegevens en de itemsmatrix volgens het voorgeschreven formaat te vullen. Elk item heeft minstens item_id of item_name nodig.

Een fictief voorbeeld, alleen met invoer en verwachte controles. Invoer (fictief, zonder persoonsgegevens, in een veilige testomgeving): een hoofdwebsite met twee overgangselementen naar een boekingsdomein, namelijk een knop in de hoofdnavigatie en een link in een prijstabel. Het boekingsdomein heeft een eigen toestemmingsbanner en een bevestigingspagina met een aankoopgebeurtenis.

Verwachte controles: voor elk van de twee elementen noteer je de url na aankomst, of beide domeinen in dezelfde DebugView-stroom staan, wat er gebeurt bij geweigerde toestemming en of de aankoopgebeurtenis valuta en items bevat. Wat je dan invult in de kolom 'resultaat' is jouw bevinding, geen verwachting. Geef dat blad aan de beheerder met de vraag welke overgang afwijkt, en herhaal de test na elke aanpassing.

Wil je weten welke signalen van je website publiek zichtbaar zijn, bekijk ze dan via Marketing Scan. Een publieke scan meet alleen wat van buitenaf zichtbaar is en bewijst geen volledige meetopstelling, dus de test hierboven blijft nodig.