Google Analytics account aanmaken: van voorbereiding tot overdracht

Een Google Analytics account aanmaken begint met controleren wat je al hebt. Kies daarna een passende GA4-structuur, leg het beheer vast en maak alleen de ontbrekende onderdelen aan. Een account of webstream verzamelt op zichzelf nog geen websitegegevens. Daarvoor moet de meting worden ingericht en getest. Hieronder werk je van meetvraag naar een overdrachtsdossier waarmee een implementator verder kan.

Welke vragen kun je met GA4 onderzoeken?

GA4 kan helpen onderzoeken hoe bezoekers op je website komen, welke onderdelen ze gebruiken en welke gewenste acties worden gemeten. Denk aan bezoeken vanuit zoekmachines, het bekijken van een dienstenpagina of het afronden van een bestelling. Welke antwoorden je krijgt, hangt af van de inrichting en van de gegevens die daadwerkelijk binnenkomen.

Het vertrekpunt is een meetvraag. Een installatiebedrijf kan willen weten welke dienstenpagina’s voorafgaan aan een aanvraag. Een webshop kan onderzoeken waar gemeten winkelbezoeken overgaan in winkelmandacties. Een opleider kan bekijken welke informatie bezoekers raadplegen voordat ze een inschrijving starten. Deze vragen vragen elk om andere gebeurtenissen en controles.

GA4 verwerkt interacties als gebeurtenissen. Een paginaweergave is een ander signaal dan een verzonden formulier of een aankoop. Sommige interacties kunnen via bestaande meetfuncties worden verzameld; voor andere moet een implementator aanvullende inrichting verzorgen. Alleen een account openen bepaalt nog niet welke bedrijfsacties betrouwbaar worden vastgelegd.

Maak daarom onderscheid tussen een handeling en de betekenis ervan. Een klik op de verzendknop bewijst niet dat een aanvraag is ontvangen. Een bezoek aan een betaalpagina bewijst niet dat een bestelling is betaald. Je meetplan moet benoemen welk moment voldoende bewijs levert voor de vraag die je wilt beantwoorden.

Leg bij iedere vraag een meetbeperking vast

Geen rapport is automatisch een volledige weergave van alle bezoekers en transacties. Technische werking, ingestelde keuzes en de omstandigheden van een bezoek kunnen bepalen welke gegevens beschikbaar zijn. Noteer daarom naast de meetvraag ook een meetbeperking: wat kun je op basis van deze gegevens nog niet concluderen?

Bij een aanvraagformulier kan de beperking zijn dat je alleen succesvolle verzending meet, terwijl de commerciële beoordeling later gebeurt. Tien gemeten aanvragen betekenen dan niet tien geschikte klanten. Bij een webshop kan een gemeten aankoop verschillen van de uiteindelijke opbrengst na annuleringen of retouren. Houd die begrippen uit elkaar voordat je een dashboard laat bouwen.

Voor zoekverkeer koppel je meetvragen aan je SEO-strategie. Wil je meer geschikte aanvragen voor een specifieke dienst, dan is alleen het aantal bezoeken te beperkt. Leg ook vast welke pagina, actie en vervolgstap relevant zijn. Daarmee voorkom je dat de inrichting vooral gegevens oplevert waar niemand een besluit op baseert.

Google-account, Analytics-account, property en datastream

Deze vier begrippen beschrijven verschillende onderdelen. Je Google-account is de identiteit waarmee je inlogt. Dat kan een bestaande zakelijke Google-identiteit zijn. Het Analytics-account vormt een beheerniveau waarin properties staan. Een property begrenst een meetomgeving. Datastreams verbinden de afzonderlijke meetbronnen, zoals een website of app, met die property.

Een property is dus niet verplicht hetzelfde als precies één domein. De passende indeling volgt uit de dienstverlening, het gebruik van website en app, de toegang en de vragen die je wilt beantwoorden. Google beschrijft deze niveaus in de documentatie over de Analytics-structuur.

Een eenvoudige website met één eigenaar

Neem een fictieve meubelmaker met één website en één verantwoordelijke onderneming. Een werkbare structuur kan bestaan uit het Analytics-account van die onderneming, een property voor de website en een webstream voor de webmeting. De eigenaar logt in met een eigen Google-account en verleent anderen passende toegang.

Controleer eerst of zo’n structuur al bestaat. Als de property klopt, het beheer geregeld is en de webstream naar de juiste website verwijst, is opnieuw aanmaken meestal geen logische eerste stap. Je kunt dan direct onderzoeken welke installatie ontbreekt of welke gebeurtenis nog moet worden ingericht.

Een website en app voor dezelfde dienst

Bij een fictieve reserveringsdienst gebruiken klanten een website en een app. Als die contactpunten inhoudelijk bij dezelfde dienst horen, kan één property met afzonderlijke datastreams passend zijn. Voor een website gebruik je een webstream; voor apps zijn er afzonderlijke typen voor iOS en Android.

Daarmee is de gezamenlijke analyse nog niet geregeld. De implementator moet onderzoeken welke gebeurtenissen op elk contactpunt bestaan en hoe die worden ingericht. Een reservering die op de website start en in de app wordt afgerond, wordt niet vanzelf één herkenbaar traject doordat beide streams onder dezelfde property staan.

Zijn de eigenaren, toegangseisen of doelen juist verschillend, beoordeel dan of gescheiden properties beter passen. Kies niet automatisch één property per domein of één property voor alles. Schrijf op welke gegevens je samen wilt bekijken en waarom dezelfde mensen die gegevens mogen gebruiken.

Onderzoek eerst de bestaande omgeving

Begin de inventarisatie bij de mensen die de website beheren. Vraag of er al een Analytics-account, property of meetinrichting bestaat. Laat de verantwoordelijke de namen en identificaties uit de omgeving noteren. Een oude factuur met het woord Analytics bewijst niet dat je toegang hebt tot de juiste property.

Controleer vervolgens of de ingelogde Google-identiteit toegang heeft tot de bedoelde omgeving. Zie je niets, dan zijn er meerdere mogelijke verklaringen: je gebruikt een andere identiteit, toegang ontbreekt of de omgeving bestaat nog niet. Alleen de laatste verklaring rechtvaardigt op zichzelf een nieuwe aanmaakroute.

Gebruik een korte inventarisatie met drie bewijspunten. Wie kan de property openen? Welke website of app hoort erbij? Wie kan het toegangsbeheer verzorgen? Noteer per punt een concreet antwoord of schrijf onbekend. Een lege cel lijkt gemakkelijk op afgerond werk, terwijl onbekend duidelijk maakt dat onderzoek nodig is.

Er staat al een onbekende Analytics-tag op de website

Een bestaande tag is een aanwijzing, geen bewijs dat de inrichting bruikbaar is. Laat een technisch beheerder vaststellen waar de meetinstructie vandaan komt en naar welke bestemming die verwijst. Denk aan een plugin, een platformkoppeling, een tagmanager of een aanpassing in het thema. Wijzig tijdens deze inventarisatie nog niets.

1. Noteer de gevonden bestemming en de plek waar de meting wordt beheerd.
2. Vergelijk die bestemming met de properties en streams waartoe de onderneming toegang heeft.
3. Komt de bestemming overeen, onderzoek dan of de bestaande route kan blijven.
4. Is de bestemming onbekend, vraag de vorige beheerder om uitleg en overdracht.
5. Blijft het eigendom onduidelijk, leg de blokkade vast voordat je een nieuwe inrichting laat aansluiten.

Een extra tag toevoegen om te kijken of het werkt, kan dubbele meting veroorzaken. Een onbekende tag verwijderen kan bestaande rapportages onderbreken. De juiste vervolgstap hangt daarom af van het onderzoek. Vraag bij een bredere technische inventarisatie om dit punt mee te nemen in een SEO-audit, met een afzonderlijk oordeel over de meetinrichting.

Spreek beheer en toegang af voordat je begint

Wijs binnen de onderneming een verantwoordelijke aan voor de Analytics-omgeving. Dat hoeft niet dezelfde persoon te zijn als degene die de installatie uitvoert. De verantwoordelijke moet kunnen beoordelen wie toegang nodig heeft, welke omgeving bij het bedrijf hoort en wat er gebeurt wanneer een medewerker of leverancier vertrekt.

Gebruik persoonlijke toegang voor medewerkers en leveranciers, in plaats van één gedeeld wachtwoord als overdrachtsmethode. Leg vast welke zakelijke identiteit wordt gebruikt en wie het beheer kan overnemen. Neem geen wachtwoorden of herstelcodes op in een meetwerkblad dat naar verschillende partijen gaat.

Maak de toegang zo gericht als de taak vraagt. Een partij die één property inricht, heeft niet vanzelf toegang tot alle properties nodig. Toegang op accountniveau werkt door naar onderliggende properties. Een ruimere geërfde rol kun je niet beperken door op propertyniveau simpelweg een smallere rol toe te kennen.

Koppel rollen aan het werk dat iemand uitvoert

Een Administrator kan gebruikers en instellingen beheren. Een Editor kan propertyinstellingen wijzigen, maar beheert daarmee geen gebruikers. Een Marketer werkt aan onder meer doelgroepen, gebeurtenissen en belangrijke gebeurtenissen. Een Analyst werkt met gedeelde verkenningen. Een Viewer kan rapporten bekijken en eigen verkenningen gebruiken. Controleer de benodigde bevoegdheid voor de concrete taak.

Deze rollen vervangen geen afspraken over toegang tot de website, tagmanager of andere gekoppelde systemen. Iemand kan een property mogen aanpassen en tegelijk geen publicatierecht in WordPress hebben. Omgekeerd kan een websitebouwer een tag installeren zonder de Analytics-omgeving te kunnen beoordelen. Neem beide kanten op in de planning.

Ook beperkingen op kosten of opbrengsten zijn iets anders dan het intrekken van toegang. Vraag bij twijfel welke effectieve rechten iemand heeft, inclusief overerving. De officiële uitleg over rollen en beperkingen helpt om een gevraagde rol te beoordelen. Controleer de feitelijke toegang voordat je de taak als uitvoerbaar markeert.

Voorbereidingsblad voor een ondernemer met twee merken

Het volgende voorbeeld is volledig fictief. Ondernemer Noor beheert de merken Linde Werkplaats en Maan Atelier. Het eerste merk heeft een bestaande informatieve website. Het tweede krijgt een webshop. Noor gebruikt al een zakelijke Google-identiteit. De namen, situaties en keuzes hieronder illustreren het werkblad; ze beschrijven geen uitgevoerd klantproject.

Het doel is per omgeving tot één bruikbare uitkomst te komen: bewaren, een nieuwe property voorbereiden of eerst eigendom ophelderen. Vul elke rij op basis van controle in. Een vermoeden blijft een open vraag. Het blad maakt de besluitvorming zichtbaar, maar maakt zelf geen account aan en bewaart geen voortgang.

De tweede rij betekent niet dat een nieuw merk altijd een nieuwe property vereist. In dit voorbeeld wil Noor de webshop afzonderlijk beheren en beoordelen. Het bestaande Analytics-account kan daarvoor passend zijn als eigendom en toegang overeenkomen met die keuze. De derde rij laat zien waarom meteen alles vernieuwen een onzorgvuldige oplossing kan zijn.

Vul identiteit, eigendom en namen afzonderlijk in

Noteer eerst de bestaande Google-identiteit waarmee de bevoegde persoon werkt. Vul daarna de accountnaam, propertynaam en streamnaam in, met de bijbehorende identificaties zodra die bekend zijn. Zet bij ieder niveau wie het beheer verzorgt en op welk bewijs dat antwoord berust. Zo blijft een herkenbare naam gescheiden van aantoonbare toegang.

Kies namen die ook bij een overdracht begrijpelijk blijven. Linde Werkplaats kan de ondernemingsnaam als accountnaam gebruiken en een propertynaam die het merk en gebruik beschrijft. Vermijd namen als nieuw account, test van bureau of website definitief. Die zeggen later weinig over de inhoud en verantwoordelijke partij.

Leg bij een testomgeving expliciet vast dat deze geen productieomgeving is. Een naam is daarbij slechts een hulpmiddel. De implementator moet nog steeds controleren welke bestemming in de echte website staat. Twee properties met bijna dezelfde naam kunnen technisch verschillende gegevens ontvangen.

Bepaal tijdzone, valuta en meetdoelen

Noteer de gekozen tijdzone en valuta voordat iemand de property-inrichting afrondt. Voor Noors fictieve Nederlandse merken kan een Nederlandse rapportagetijdzone en euro als valuta passend zijn. De keuze moet aansluiten op de bedrijfsvoering en op de manier waarop cijfers later worden vergeleken, bijvoorbeeld met bestellingen uit de webshop.

Een ingestelde valuta bewijst nog niet dat elke aankoop met de juiste waarde en valuta wordt verstuurd. Dat blijft onderdeel van de gebeurtenisinrichting. Ook een passende tijdzone voorkomt niet alle verschillen tussen systemen. Noteer bij latere vergelijkingen welke datumdefinitie en rapportageperiode je gebruikt.

Schrijf vervolgens per merk één bedrijfsdoel en enkele meetvragen op. Voor Linde kan dat zijn: begrijpen welke diensteninformatie voorafgaat aan een ontvangen aanvraag. Voor Maan: onderzoeken hoe productweergaven, winkelmandacties en aankopen samenhangen. Deze formuleringen helpen bepalen welke gebeurtenissen nodig zijn en welke gegevens buiten de opdracht vallen.

Beoordeel gegevensdeling als een eigen beslissing

Gegevensdeling is een afzonderlijk onderdeel van de voorbereiding. Laat de verantwoordelijke de beschikbare instellingen lezen en per keuze bepalen wat bij de onderneming past. Noteer de keuze, de reden en wie deze heeft beoordeeld. Neem niet zonder onderzoek de instellingen van een ander bedrijf over.

Gegevensdelingskeuzes zijn geen vervanging voor een beoordeling van toestemming, informatievoorziening of de technische werking van de website. Als daar vragen over openstaan, wijs een verantwoordelijke aan en beschrijf wat nog moet worden uitgezocht. Het aanmaken van een account levert geen verklaring op dat de volledige inrichting aan alle verplichtingen voldoet.

Maak van een open vraag een uitvoerbare opdracht

Een open punt heeft pas praktisch nut als duidelijk is wie het oplost en welk antwoord nodig is. Schrijf daarom niet alleen tracking controleren. Maak ervan: de websitebeheerder vergelijkt de actieve bestemming met de webstream van Maan Atelier en noteert of deze overeenkomen. De uitkomst kan vervolgens worden beoordeeld.

Gebruik in je eigen kopie van het werkblad vier aanvullende kolommen: vraag, verantwoordelijke, bewijs en besluit. Bij bewijs past bijvoorbeeld een gecontroleerde identificatie of een beschreven testwaarneming. Bij besluit noteer je bewaren, aanpassen, aanvullend onderzoeken of accepteren. Voeg geen wachtwoorden toe om een bewijsveld te vullen.

Een open vraag over gegevensdeling hoort bij degene die die keuze namens het bedrijf beoordeelt. Een vraag over een formuliertrigger hoort bij de technisch uitvoerder. Door die verdeling hoeft een ondernemer geen technische oorzaak te raden en hoeft een ontwikkelaar geen zakelijke beleidskeuze in te vullen.

Bespreek het blad op het moment dat een antwoord beschikbaar is. Werk vervolgens de status bij en bewaar de reden voor het besluit. Zo kun je later terugvinden waarom een bestaande property behouden is, terwijl voor een ander merk een afzonderlijke omgeving is voorbereid.

Zes controlepoorten voor het aanmaken van je omgeving

De volgende poorten vormen een statische stappenwijzer. Ze helpen je aanmelden, accountkeuze, property-inrichting en streamkeuze beoordelen. Het zijn controlepunten voor je eigen werk, geen letterlijke schermvolgorde. De officiële GA4-aanmaakinstructie beschrijft de productstappen. Gebruik die naast je ingevulde voorbereiding.

Geef iedere poort de status klaar, niet klaar of niet van toepassing. Klaar betekent dat de genoemde controle-uitkomst zichtbaar is en door de bevoegde persoon is beoordeeld. Niet klaar betekent dat je de ontbrekende invoer of bevoegdheid opschrijft. Een volgende poort mag een onopgeloste eigendomsvraag niet verhullen.

Poort één: aanmelden met de bedoelde identiteit

Doel: vaststellen dat de juiste persoon in de juiste zakelijke context werkt. Invoer: de gekozen Google-identiteit en de naam van de verantwoordelijke. Bevoegde eigenaar: de persoon die namens de onderneming de toegang mag organiseren. Gebruik de bestaande identiteit als die hiervoor geschikt is.

Na aanmelden controleer je welke Analytics-accounts en properties zichtbaar zijn. Vergelijk die lijst met de inventarisatie. De controle-uitkomst is een bevestigde identiteit met een overzicht van relevante omgevingen, of de vaststelling dat benodigde toegang ontbreekt. Kun je een verwachte property niet zien, dan staat deze poort op niet klaar totdat dat verschil is verklaard.

Poort twee: een bestaand of nieuw Analytics-account kiezen

Doel: de passende beheeromgeving bepalen. Invoer: inventarisatie, eigendomsafspraak, accountnaam en beoordeelde gegevensdelingskeuzes. Bevoegde eigenaar: degene die de accountkeuze en het beheer namens de onderneming kan vastleggen. Bekijk eerst of een bestaand Analytics-account bruikbaar is.

Maak alleen een nieuw account als daar een onderbouwde reden voor is en de uitvoerder de benodigde bevoegdheid heeft. De controle-uitkomst is een herkenbaar account waarvan beheer en bedoeling vaststaan. Staat het account uitsluitend onder onduidelijk beheer van een vertrokken partij, noteer dan niet klaar en organiseer eerst opheldering.

Poort drie: de property-inrichting vastleggen

Doel: afbakenen welke gegevens en contactpunten bij elkaar horen. Invoer: propertynaam, gekozen tijdzone, valuta en onderbouwing van de structuur. Bevoegde eigenaar: de zakelijke verantwoordelijke voor deze meetomgeving; de uitvoerder heeft passende Editor-bevoegdheid nodig voor de betreffende inrichting.

Controleer bij een bestaande property of de instellingen passen voordat je een nieuwe maakt. De controle-uitkomst is een identificeerbare property met vastgelegde instellingen en een omschreven gegevensbereik. Ontbreekt bevoegdheid of is onduidelijk of de app bij deze property hoort, dan blijft de poort niet klaar. Een aannemelijke naam is onvoldoende bewijs.

Poort vier: bedrijfsinformatie en meetdoelen koppelen

Doel: zorgen dat de inrichting aansluit op de onderneming. Invoer: de gevraagde bedrijfsinformatie, bedrijfsdoelen en je concrete meetvragen. Bevoegde eigenaar: iemand die de bedrijfscontext kan bevestigen. Vul de informatie in op basis van de werkelijke organisatie en activiteit.

Controleer daarna of elke gekozen doelrichting ook een begrijpelijke meetvraag heeft. De controle-uitkomst is een korte lijst vragen met de daarvoor benodigde gebeurtenissen. Het kiezen van een bedrijfsdoel maakt die gebeurtenissen niet automatisch correct meetbaar. Is nog onbekend wat een succesvolle aanvraag betekent, markeer de definitie als niet klaar voor implementatie.

Poort vijf: een passende datastream voorbereiden

Doel: het juiste contactpunt aan de property verbinden. Invoer: het streamtype, een herkenbare naam en bij een webstream de bedoelde website-URL. Bevoegde eigenaar: de verantwoordelijke voor de website of app, samen met de uitvoerder die de stream kan inrichten.

Controleer bij een website de URL, streamnaam en keuzes voor verbeterde meting. Beoordeel die keuzes tegen de meetvragen; zie ze niet als bewijs dat alle gewenste acties beschikbaar zijn. De controle-uitkomst is een passende stream in de juiste property. Als de bedoelde website nog onzeker is, blijft de poort niet klaar.

Poort zes: de inrichting overdraagbaar maken

Doel: de accountaanmaak afsluiten met een uitvoerbare vervolgopdracht. Invoer: identificaties, implementatieroute, toegangsafspraken en testacties. Bevoegde eigenaar: de opdrachtgever die de overdracht accepteert, samen met de implementator die bevestigt dat de technische taak duidelijk is.

De controle-uitkomst is een overdrachtskaart met een verantwoordelijke per open punt. Accountaanmaak kan klaar zijn terwijl installatie nog niet klaar is. Geef die statussen afzonderlijk weer. Zolang niemand heeft vastgesteld dat een testgebeurtenis op de bedoelde bestemming binnenkomt, is meetvalidatie niet afgerond.

Beoordeel de aanmaak als iemand anders deze uitvoert

Laat een specialist de gekozen accountstructuur uitleggen aan de hand van jouw merken en meetvragen. Vraag vervolgens om de property en stream in de bedoelde omgeving te tonen. Zo controleer je dat de inrichting bestaat en bij de opdracht past, zonder zelf iedere technische stap te hoeven uitvoeren.

Controleer ook je eigen toegang. Een afbeelding van een instelling bewijst niet dat jouw zakelijke identiteit de property kan openen. Laat de verantwoordelijke zelf aanmelden en de relevante omgeving terugvinden. Als gebruikersbeheer bij iemand anders ligt, moet duidelijk zijn wie dat is en hoe wijzigingen worden aangevraagd.

Vraag bij oplevering welke onderdelen nog niet zijn uitgevoerd. Een specialist kan de structuur correct hebben aangemaakt terwijl websitepublicatie wacht op een andere partij. Noteer dan afzonderlijk wie de installatie verzorgt en welk bewijs bij de volgende overdracht nodig is. Dat voorkomt dat een afgeronde deeltaak wordt aangezien voor een werkende meting.

Meet-ID, tag en configuratie zijn verschillende zaken

Het meet-ID identificeert bij webmeting de bedoelde bestemming. De Google-tag is onderdeel van de techniek waarmee gegevens kunnen worden verstuurd. De configuratie bepaalt hoe de gekozen implementatie werkt en welke gebeurtenissen met welke gegevens worden aangeboden. Het ene onderdeel kan daarom niet als bewijs voor het andere dienen.

Een meet-ID doorgeven installeert geen meting. Een tag aantreffen bewijst niet dat deze naar de juiste property stuurt. En een ontvangen paginaweergave bewijst niet dat een aankoop de vereiste transactiegegevens bevat. Controleer steeds de hele keten voor de specifieke meetvraag: actie, verzending, bestemming en inhoud.

Verwar een identificatie van een tagmanagercontainer niet met het GA4-meet-ID. Als beide systemen in gebruik zijn, noteer je beide afzonderlijk met hun functie. Vraag de implementator welk onderdeel hij nodig heeft en waar dat wordt toegepast. Kopieer geen willekeurig nummer omdat het in dezelfde technische overdracht staat.

Bepaal de implementatieroute voor WordPress of Shopify

Begin ook hier met diagnose. Laat vaststellen welke plugins, platformkoppelingen, tags en eerdere aanpassingen al actief zijn. Kies vervolgens een route die bij de werkelijke website past. Bij WordPress kan een bestaande integratie relevant zijn; bij Shopify kan een aanwezige platformkoppeling bepalend zijn. Dat vraagt controle van die specifieke omgeving.

Leg vast wie de wijzigingen uitvoert en wie mag publiceren. Vraag welke bestaande meetroute wordt behouden, aangepast of uitgezet en waarom. Voeg niet standaard een extra plugin of losse code toe. De keuze moet rekening houden met de aanwezige inrichting en het risico dat dezelfde gebeurtenis langs meerdere routes wordt verstuurd.

De uitvoering eindigt met testen op de echte bestemming. Neem bij veranderingen aan thema, formulieren of checkout ook een controle van de meetgebeurtenissen op. Wanneer meting onderdeel is van een breder websiteonderzoek, kan technische SEO helpen om verantwoordelijkheden en technische aandachtspunten in samenhang te beoordelen.

Maak een overdrachtsdossier voor de meetinrichting

De implementator heeft meer nodig dan een accountnaam. Je dossier moet duidelijk maken wat gemeten moet worden, waar de gegevens thuishoren en hoe jullie vaststellen dat de opdracht is uitgevoerd. Houd het compact genoeg om te gebruiken, maar concreet genoeg om aannames zichtbaar te maken.

Gebruik per website of app één overdrachtskaart. Bij een gezamenlijke property kun je meerdere kaarten maken die naar dezelfde property verwijzen. Zo blijft per contactpunt duidelijk wie iets uitvoert. Bewaar ook de datum van controle, zodat een latere beheerder weet op welke situatie de kaart betrekking heeft.

• Omgeving: bedoelde website of app, productie of test, en verantwoordelijke eigenaar.
• Bestemming: accountnaam, propertynaam, streamnaam en gecontroleerde identificaties.
• Beheer: zakelijke beheerder, uitvoerder en benodigde toegang per systeem.
• Implementatieroute: aanwezige techniek, gekozen route en eventueel te vervangen onderdeel.
• Meetvraag: bedrijfsdoel, gebeurtenis en afbakening van de gewenste actie.
• Testactie: handeling, omstandigheden, uitvoerder en afgesproken controle.
• Verwachte waarneming: bestemming, gebeurtenis en relevante gegevens die moeten binnenkomen.
• Open vraag: ontbrekende beslissing, eigenaar van de vraag en status.

Beschrijf een aanvraag als controleerbare gebeurtenis

Schrijf bijvoorbeeld: een aanvraag telt wanneer het formulier succesvol is verwerkt en de bezoeker de afgesproken bevestiging krijgt. Laat de implementator onderzoeken welk technisch signaal daar betrouwbaar bij past. Of een bevestigingspagina, formulierreactie of andere bron geschikt is, hangt af van de website.

Beschrijf ook wat niet mag meetellen. Een klik zonder ingevulde velden, een foutmelding of een herhaald bezoek aan een bevestigingspagina kan anders hetzelfde signaal opleveren. Neem deze gevallen op als afzonderlijke testacties. Daarmee maak je het verschil tussen zichtbare interactie en een bruikbare bedrijfsgebeurtenis concreet.

Vraag welke gegevens met de gebeurtenis worden meegestuurd. Voor de beoordeling van een formulier is het doorgaans zinvoller de formulierfunctie te kennen dan de ingevulde berichttekst. Laat gegevenskeuzes bewust beoordelen en neem geen echte klantinhoud op in het gedeelde testdossier.

Beschrijf bij een webshop ook de transactiegegevens

Bij webshops vraagt een aankoop meer dan een gebeurtenis met de juiste naam. De inrichting moet de relevante transactie-identiteit, waarde, valuta en artikelgegevens uit een passende bron halen. Productweergaven, winkelmandacties en checkoutstappen hebben daarnaast hun eigen betekenis. Laat per gewenste gebeurtenis vastleggen welke bron de gegevens levert.

De officiële documentatie voor e-commercemeting beschrijft deze gebeurtenissen en gegevens. Gebruik die voor de technische uitwerking en debugcontrole. De aanwezigheid van een tag of een werkende algemene paginaweergave bevestigt niet dat de webshopgebeurtenissen correct zijn ingericht.

Maak de opdracht passend bij je e-commerce SEO. Als je productpagina’s wilt beoordelen, zijn alleen totale aankopen onvoldoende om de onderzoeksvraag goed af te bakenen. Bepaal welke productinteracties nodig zijn, zonder daarom meteen iedere mogelijke gebeurtenis te laten implementeren.

Kies welke gebeurtenis als eerste wordt ingericht

Begin met de gebeurtenis die het duidelijkst bij je belangrijkste bedrijfsdoel hoort en waarvan het succesmoment goed te beschrijven is. Voor een dienstenwebsite kan dat een ontvangen aanvraag zijn. Voor een webshop kan het een afgeronde aankoop zijn. Dit is een prioriteitskeuze voor de opdracht, geen algemene verplichting.

Beoordeel daarna de aanvullende gebeurtenissen op hun nut voor een besluit. Een winkelmandactie kan helpen onderzoeken waar het aankoopproces stokt. Een klik op een algemene afbeelding heeft misschien geen duidelijke vervolgactie. Als niemand kan uitleggen wat een waarneming zou veranderen, hoeft die gebeurtenis niet automatisch in de eerste inrichting.

Maak ook onderscheid tussen noodzakelijke gegevens en interessante extra details. Leg bij ieder gegeven vast welke vraag ermee wordt beantwoord. Dit maakt de technische opdracht afgebakend en helpt bij de beoordeling van gegevenskeuzes. Breid de inrichting later gericht uit wanneer een nieuwe onderzoeksvraag dat vraagt.

Vier diagnoses als de meting niet klopt

Behandel een afwijking als een onderzoeksvraag. Schrijf eerst op wat je verwachtte, welke handeling je uitvoerde en wat je zag. Kies daarna de kleinste controle die mogelijke oorzaken onderscheidt. Verander niet tegelijk de property, de tag en het formulier, want dan wordt onduidelijk welke wijziging iets heeft opgelost.

Diagnose één: er komt niets binnen

Je hebt een property en webstream, maar ziet na een test geen gebeurtenis. Controleer eerst of de website daadwerkelijk meetinstructies bevat en of de gekozen implementatie is gepubliceerd. Alleen een stream aanmaken is daarvoor niet genoeg. Laat vervolgens de bestemming vergelijken met het vastgelegde meet-ID.

Onderzoek ook de omstandigheden van de test. Welke pagina, browser en toestemmingssituatie werden gebruikt? Was dit de echte website of een testomgeving? Kon de implementator vaststellen dat er een verzending plaatsvond? Deze vragen helpen onderscheid maken tussen geen uitvoering, geen verzending en kijken op de verkeerde plek.

Als installatie ontbreekt, plan je de gekozen route. Als verzending wordt tegengehouden of verkeerd gericht is, onderzoek je dat onderdeel. Controleer na de aanpassing opnieuw dezelfde testactie. Een gebeurtenis in Realtime kan ontvangst helpen bevestigen, maar zegt nog niets over alle pagina’s, bezoekers en bedrijfsacties.

Diagnose twee: één actie geeft een dubbelsignaal

Een test levert twee vergelijkbare gebeurtenissen op terwijl je één handeling uitvoerde. Controleer eerst of het werkelijk dezelfde bedoelde gebeurtenis betreft. Verschillende stappen in een formulier kunnen terecht verschillende signalen geven. Vergelijk naam, tijdstip, bestemming en inhoud voordat je concludeert dat sprake is van dubbele meting.

Onderzoek daarna of meerdere routes dezelfde gebeurtenis versturen. Een plugin en een tagmanager kunnen naast elkaar actief zijn. Ook kan een inrichting dezelfde trigger meermaals uitvoeren. Laat de implementator aanwijzen welke route bij de afgesproken gebeurtenis hoort en welke andere route het signaal mogelijk herhaalt.

Pas vervolgens alleen het aangetoonde probleem aan. Test dezelfde actie opnieuw en neem ook een herhaalde paginaweergave of terugkeer naar de bevestiging mee als dat relevant is. Een verdwenen dubbelsignaal in één test is nuttig bewijs voor die situatie, geen garantie dat alle andere gebeurtenissen eveneens goed zijn.

Diagnose drie: gegevens komen in de verkeerde property

De testactie lijkt te worden verstuurd, maar verschijnt niet in de afgesproken omgeving. Vergelijk het meet-ID van de implementatie met de identificatie van de bedoelde webstream. Controleer ook welke property in Analytics geopend is. Gelijkende namen maken een verkeerde selectie gemakkelijk.

Leg vast of sprake is van een verkeerde technische bestemming of alleen een verkeerde rapportweergave. Bij het eerste moet de implementator de configuratie beoordelen en aanpassen. Bij het tweede volstaat mogelijk het openen van de juiste omgeving. Verwijder niet meteen een property omdat daar onverwachte gegevens staan.

Na correctie voer je een nieuwe, herkenbare testactie uit en noteer je waar die wordt ontvangen. Beschouw eerdere gegevens niet automatisch als hersteld door de wijziging. Beschrijf vanaf welk gecontroleerd moment de bestemming klopt en welke onzekerheid over de eerdere meetperiode blijft bestaan.

Diagnose vier: de bedrijfsgebeurtenis ontbreekt

Paginaweergaven komen binnen, maar een aanvraag of aankoop ontbreekt. Daarmee is een deel van de meetketen aantoonbaar actief. Onderzoek nu de specifieke bedrijfsactie: wordt het afgesproken succesmoment bereikt en levert de website daar een bruikbaar signaal voor? De algemene tagcontrole beantwoordt die vraag niet.

Vergelijk de gebeurtenisdefinitie met de technische trigger. Misschien wordt een knopklik gemeten terwijl het succesmoment ontbreekt. Misschien verschijnt de bevestiging op een plek die de bestaande inrichting niet afdekt. Bij een aankoop kunnen bovendien benodigde gegevens ontbreken, ook wanneer er wel een gebeurtenis wordt verzonden.

Laat de ontbrekende inrichting gericht aanvullen en test zowel de geslaagde als de mislukte actie. Controleer daarna naam, bestemming en inhoud. Pas wanneer die aansluiten bij de afgesproken definitie, kun je de gebeurtenis gebruiken voor het bedoelde onderzoek. Markeer resterende beperkingen in het dossier.

Fictief rekenvoorbeeld: twintig tests beoordelen

Noor wil voor Maan Atelier controleren of een nieuwe aankoopmeting op de afgesproken manier werkt. Het onderstaande rekenvoorbeeld is volledig fictief. Het gaat om gecontroleerde testhandelingen en verwachte signalen, niet om echte klanten, omzet of behaalde resultaten. De aantallen zijn gekozen om afwijkingen begrijpelijk te maken.

In het testplan staan twintig handelingen: twaalf succesvol afgeronde testbestellingen en acht afgebroken betaalpogingen. De afgesproken definitie verwacht alleen bij de twaalf afgeronde bestellingen een aankoopgebeurtenis. Per bestelling is in dit voorbeeld één artikel van vijfentwintig euro opgenomen. De verwachte gezamenlijke testwaarde is dus twaalf maal vijfentwintig: driehonderd euro.

Stel dat de controle vijftien aankoopgebeurtenissen laat zien. Het verschil met de verwachting is vijftien min twaalf: drie gebeurtenissen. Die afwijking betekent niet dat er drie extra bestellingen zijn. Je moet onderzoeken welke testhandelingen bij de vijftien signalen horen en of er dubbele of onterecht geactiveerde gebeurtenissen tussen zitten.

Veronderstel vervolgens dat drie afgeronde bestellingen elk tweemaal zijn verstuurd en de overige negen eenmaal. Dan ontstaan zes plus negen, samen vijftien signalen. Als elk signaal vijfentwintig euro draagt, is de opgetelde signaalwaarde driehonderdvijfenzeventig euro. Dat is vijfenzeventig euro boven de verwachte testwaarde. Dit is een illustratie van een fout, geen voorspelling van rapportgedrag.

Controleer daarom de transactie-identiteit en de feitelijke verwerking, in plaats van alleen de totaaltelling. Ook de acht afgebroken pogingen verdienen aandacht: die horen volgens deze definitie geen aankoop op te leveren. Een juiste totaalsom kan immers fouten verbergen wanneer ontbrekende en onterechte signalen elkaar toevallig compenseren.

Vul de testmatrix per handeling in

Geef elke test een herkenbare referentie in je eigen werkblad. Noteer de uitgevoerde actie, het verwachte resultaat, de ontvangen gebeurtenis, relevante transactiegegevens en de conclusie. Gebruik voor de conclusie drie mogelijkheden: overeenstemming, afwijking of onvoldoende bewijs. Koppel aan de laatste twee altijd een vervolgvraag.

Bij een afwijking vraagt Noor bijvoorbeeld: waarom hebben deze drie transacties twee verzendingen? Bij onvoldoende bewijs vraagt zij: kunnen we vaststellen welke stream deze gebeurtenis ontving? Zo ondersteunt het werkblad concrete besluiten over aanvullend onderzoek, correctie of acceptatie. Het vervangt geen technische debugcontrole.

Bepaal vooraf wanneer een test wordt geaccepteerd

In Noors voorbeeld is alleen het juiste totaal geen voldoende acceptatiecriterium. Per afgeronde bestelling moet de bedoelde gebeurtenis op de afgesproken bestemming aantoonbaar bij die bestelling horen. De waarde, valuta en artikelinformatie moeten overeenkomen met de testinvoer. Afgebroken betaalpogingen moeten buiten de afgesproken aankoopdefinitie blijven.

Voeg een negatieve test toe: een handeling waarbij juist geen aankoop wordt verwacht. Daarmee onderzoek je of de inrichting te vroeg activeert. Voeg daarnaast een herhaaltest toe wanneer bezoekers de bevestiging opnieuw kunnen openen. Laat de implementator uitleggen hoe de inrichting in die situatie met dezelfde transactie omgaat.

Bij een mislukte test wijzig je de verwachting niet om de uitkomst passend te maken. Onderzoek eerst of de zakelijke definitie, technische uitvoering of testopzet onjuist was. Als de definitie werkelijk moet veranderen, leg dan de reden vast en voer de relevante tests opnieuw uit.

Wanneer is de overdracht klaar voor rapportage?

Scheid drie afrondingen: de omgeving bestaat, de installatie is uitgevoerd en de afgesproken meting is gevalideerd. Bij iedere afronding hoort ander bewijs. Een propertyoverzicht onderbouwt de eerste. Een vastgelegde publicatie onderbouwt een uitvoeringsstap. Een gedocumenteerde test met de juiste bestemming en inhoud onderbouwt de gecontroleerde werking.

Laat de implementator na installatie een ontvangende controle uitvoeren. Google noemt Realtime als hulpmiddel om verzameling te controleren na het plaatsen van een geschikte tag. Voor de inhoudelijke beoordeling van gebeurtenissen kan daarnaast debugonderzoek nodig zijn. Spreek af wie de technische waarneming vertaalt naar de oorspronkelijke meetvraag.

Een enkele testgebeurtenis bewijst alleen iets over die actie onder die omstandigheden. Je hebt daarmee niet aangetoond dat alle verkeersbronnen, apparaten, formulieren of betaalroutes goed werken. Kies aanvullende tests op basis van de werkelijke varianten op de website en noteer welke varianten nog niet onderzocht zijn.

Maak vervolgens een eerste plan voor SEO-rapportage. Zet bij ieder cijfer de definitie en de start van de bruikbare meetperiode. Geef aan welke wijzigingen vergelijking met eerdere perioden bemoeilijken. Daardoor kan degene die rapporteert onderscheid maken tussen een verandering in bezoekersgedrag en een verandering in meetinrichting.

Accepteer alleen het onderdeel waarvoor bewijs bestaat

Een oplevering kan gedeeltelijk bruikbaar zijn. Stel dat de aankoopmeting is gecontroleerd, maar de aanvraag voor een maatwerkproduct nog ontbreekt. Je kunt dan vastleggen dat het aankooponderdeel is geaccepteerd en dat de aanvraagmeting openstaat. Geef daarbij aan welke onderzoeksvragen daardoor wel en nog niet beantwoord kunnen worden.

Beschrijf een open punt zo dat een andere uitvoerder ermee verder kan. Vermeld de betreffende pagina of route, de testactie, de verwachte gebeurtenis en de waargenomen afwijking. Voeg het tijdstip en de gebruikte omgeving toe. Daarmee kan iemand de situatie gericht proberen te reproduceren, zonder het hele onderzoek opnieuw te beginnen.

Wijs ook een eigenaar aan voor het vervolg. Als een technisch probleem een besluit van de ondernemer vereist, noteer dan welke keuze nodig is. Bijvoorbeeld: moet een algemene contactaanvraag afzonderlijk worden onderscheiden van een offerteaanvraag? De implementator kan de mogelijkheden toelichten, maar de zakelijke betekenis hoort bij de opdrachtgever.

Laat de rapportage aansluiten op deze gedeeltelijke acceptatie. Gebruik een nog niet gecontroleerde gebeurtenis niet ongemerkt als basis voor een bedrijfsbesluit. Benoem de ontbrekende controle bij de betreffende vraag en werk de status bij zodra aanvullend bewijs beschikbaar is. Bewaar daarbij de oorspronkelijke testuitkomst, zodat wijzigingen later vergelijkbaar blijven.

Vergelijk Analytics zorgvuldig met je eigen administratie

Na ingebruikname kunnen Analytics en je websiteadministratie verschillende aantallen laten zien. Begin de vergelijking met dezelfde periode en dezelfde definitie. Vergelijk je ontvangen aanvragen met knopklikken, dan onderzoek je verschillende handelingen. Vergelijk je bestellingen met betalingen na annuleringen, dan vergelijk je eveneens andere uitkomsten.

Controleer daarna of de systemen hetzelfde moment als uitgangspunt nemen. Een bestelling vlak bij een daggrens kan de vergelijking bemoeilijken als instellingen of datumdefinities verschillen. Vraag eerst welke gegevens worden vergeleken, voordat je het verschil volledig toeschrijft aan een defecte tag.

Gebruik verschillen als aanleiding voor gericht onderzoek. Zoek bijvoorbeeld uit of een bepaalde betaalroute ontbreekt of een formulier na een websitewijziging anders reageert. Analytics vervangt daarmee je administratie niet. Het kan, binnen de vastgestelde meetbeperkingen, helpen gedrag en herkomst te onderzoeken naast je andere bedrijfsgegevens.

Plan een controle na relevante websitewijzigingen

Leg bij overdracht vast welke veranderingen aanleiding geven om opnieuw te testen. Denk aan een vervangen formulier, een andere checkout, een nieuw domein of het verwijderen van een plugin die de meting verzorgt. De precieze controle volgt uit het onderdeel dat verandert.

Bewaar daarvoor een kleine set herkenbare testacties uit het oorspronkelijke dossier. Na een formulierwijziging herhaal je bijvoorbeeld een geslaagde verzending en een foutieve invoer. Vergelijk de waarneming met de vastgelegde verwachting. Zo beoordeel je de wijziging op werking, zonder de volledige accountstructuur opnieuw te ontwerpen.

Veelgestelde vragen over een Google Analytics account aanmaken

Is mijn Google-account hetzelfde als mijn Analytics-account?

Nee. Je Google-account is je inlogidentiteit. Een Analytics-account is een beheeromgeving met properties. Je identiteit kan toegang hebben tot één of meerdere omgevingen. Controleer daarom eerst welke zakelijke identiteit je gebruikt en welke bestaande properties daarmee zichtbaar zijn.

Moet ik voor iedere website een nieuwe property maken?

Nee. Een property kan een website en/of app vertegenwoordigen, met passende datastreams. De keuze hangt af van eigendom, toegang en meetvragen. Onderzoek eerst de bestaande structuur en leg uit waarom gegevens samenhoren of juist afzonderlijk beheerd moeten worden.

Is mijn website direct meetbaar nadat ik een webstream aanmaak?

Nee. Een webstream bereidt de bestemming voor. De website heeft daarnaast een passende implementatie nodig. Controleer na installatie met een afgesproken testactie of de juiste gebeurtenis in de bedoelde omgeving aankomt en de benodigde gegevens bevat.

Wat doe ik als een vorige leverancier de toegang beheert?

Vraag eerst om de accountgegevens, propertyidentificatie en een overdracht van passend beheer. Noteer wat al bevestigd is en wat ontbreekt. Maak niet automatisch een vervangende omgeving aan zolang onduidelijk is welke bestaande meting actief is en wie daarover beslist.

Bewijst één ontvangen test dat mijn volledige meting klopt?

Nee. Die test ondersteunt alleen een conclusie over de gecontroleerde handeling en omstandigheden. Andere formulieren, betaalroutes of gebeurtenissen kunnen anders werken. Leg vast wat is getest, welke inhoud is gecontroleerd en welke onderdelen nog aanvullend onderzoek nodig hebben.

Leg je meetvraag en open punten voor aan Niblah

Wil je hulp bij de meetinrichting rond je WordPress-website, Shopify-webshop of SEO? Gebruik het contactformulier van Niblah en vermeld je website, de bestaande Analytics-situatie en de eerste bedrijfsactie die je wilt onderzoeken. Geef aan of je vraag gaat over structuur, installatie of een afwijkende test. Daarmee is duidelijk welk onderdeel eerst beoordeeld moet worden.