Winkeleigenaren die betaald verkeer naar Shopify sturen stellen steeds dezelfde vraag: wat moet een trackingaudit eigenlijk controleren? De meeste antwoorden noemen tools. Installeer deze pixel, kijk even naar dat dashboard. Ze vertellen niet wat die controle bewijst of welke vragen daarna nog openstaan.
Een bruikbare checklist draait om controles, niet om tools: een zinvolle vraag, de bron waarin je het antwoord zoekt, hoe je die bron verifieert en, wat meestal ontbreekt, wat je daarna nog niet weet. Die vierde kolom maakt deze checklist de moeite waard. Een geslaagde regel perkt een probleem in; hij sluit het niet af.
Lees de kolommen zo: de eerste twee vertellen wat je controleert en waar. De derde geeft de concrete handeling: een rapport ophalen, een tool openen of een veld bekijken. De vierde beschrijft de uitkomst. Een checklist met drie kolommen laat je vinkjes zetten zonder te weten wat een groen vinkje nog openlaat. Alles hieronder gebruikt alleen leestoegang, in dezelfde volgorde als mijn methode: bestaande gegevens en bewaard testbewijs bekijken. Heeft een regel nieuw bewijs nodig, markeer hem dan als niet geverifieerd. Een nieuwe checkouttest of test met consentkeuzes is een aparte stap buiten deze checklist waarvoor je expliciete toestemming nodig hebt.
Welke scope en toegang heeft een Shopify-trackingaudit nodig?
Voordat je platforms vergelijkt, moet vaststaan waar de audit naar mag kijken en over welke periode. Als je deze stap overslaat, kan het oordeel een systeem omvatten dat nooit tot de afgesproken scope behoorde.
Vergelijkingstabel — scrol horizontaal om alle kolommen te bekijken
| Vraag | Gecontroleerde bron | Hoe je dit verifieert | Wat na deze controle onbekend blijft |
|---|---|---|---|
| Omvat de scope echt één winkel, één probleem en een afgesproken set systemen? | De schriftelijke scope die vóór het verlenen van toegang is afgesproken | Vergelijk de genoemde systemen met wat daadwerkelijk wordt gecontroleerd | Of de echte oorzaak in een systeem buiten de scope zit. Dit bevestigt alleen wat je bekijkt |
| Geeft de toegang alleen leesrechten en dekt die wat nodig is? | GA4 viewer role, Google Ads read-only, Meta Events Manager, Shopify staff account | Log in met de toegekende rol en lees het toegangsniveau dat het platform zelf toont | Of de toegang tijdens de reconciliatie toch onvoldoende blijkt |
| Over welke bestelperiode zijn gegevens beschikbaar? | Shopify-bestellingsexport via Admin of Orders API voor de afgesproken periode | Controleer aantal en datumbereik van de export rechtstreeks in Shopify admin | Of hetzelfde patroon vóór deze periode bestond. Een baseline van 30 dagen belooft geen volledige historie |
| Welke pixels en tags zijn daadwerkelijk geïnstalleerd, niet alleen volgens herinnering? | Shopify admin → Settings → Customer events, plus eventuele GTM-containers | Open elke vermelding in Customer events en vergelijk die met de beschrijving van de winkeleigenaar | Waarom elke vermelding er staat en wie haar beheert. Dit bevestigt aanwezigheid, niet wie haar toevoegde of of ze nog nodig is |
Komt het purchase-event uit een bron die nog werkt?
Shopify heeft meer dan eens veranderd waar een purchase-tag mag draaien. Een audit op de oude plek vindt daardoor niets verkeerds: er is niets meer om te vinden. De pixel in de sandbox, het uitgefaseerde Additional Scripts-veld en niet-geteste express-checkoutroutes staan beschreven op de hoofdpagina over Shopify-tracking. De regels hieronder laten zien wat van toepassing is.
Vergelijkingstabel — scrol horizontaal om alle kolommen te bekijken
| Vraag | Gecontroleerde bron | Hoe je dit verifieert | Wat na deze controle onbekend blijft |
|---|---|---|---|
| Bereikt het purchase-event GA4 vanuit een echte bestelling? | Bestaand GA4-DebugView-bewijs van een eerder toegestane testbestelling | Bekijk de bewaarde purchase-parameters en koppel ze aan die testbestelling. Is het bewijs niet bewaard, markeer deze controle dan als niet geverifieerd | Of elke betaalroute, zoals Shop Pay en andere express checkouts, hetzelfde event afvuurt. Het bewijs dekt alleen de geteste bestelling |
| Draait de purchase-tag op een plek waar Shopify dat toestaat? | Shopify admin → Settings → Customer events, met app pixels en custom pixels | Open elke actieve pixel en vergelijk de events waarop die is geabonneerd met wat de Web Pixels API beschikbaar stelt | Of een vermelde pixel ook goed is geconfigureerd. Aanwezig betekent niet correct |
| Staat er nog een purchase-tag in een uitgefaseerd veld? | Checkout settings → Additional Scripts | Open het veld rechtstreeks. Shopify maakte het voor niet-Plus-winkels alleen leesbaar. Scripts worden niet meegenomen naar de geüpgradede Thank you- en Order status-pagina’s; wat daar nog staat draait dus niet in een geüpgradede winkel | Hoelang de tag al stil was vóór de controle. De winkeleigenaar krijgt geen melding wanneer een script in dat veld stopt |
| Bestaat er een serverkopie van dezelfde bestelling? | Servercontainer of afleverlog van de Conversions API, gekoppeld per bestelling | Vergelijk de bestelreferentie van het server-event met het browser-event van dezelfde bestelling | Of de serverroute ook bestellingen dekt die de browser mist. Daarvoor is een grotere steekproef nodig |
Wordt één aankoop op elk platform één keer geteld?
Als een platform meer bestellingen rapporteert dan Shopify heeft verzonden, is dat eerst een deduplicatievraag en pas daarna een volumevraag. Elk platform dedupliceert op zijn eigen identifier. Controleer dit dus per platform en neem het niet aan omdat het totaal toevallig aannemelijk lijkt.
Vergelijkingstabel — scrol horizontaal om alle kolommen te bekijken
| Vraag | Gecontroleerde bron | Hoe je dit verifieert | Wat na deze controle onbekend blijft |
|---|---|---|---|
| Telt GA4 één purchase per bestelling? | De parameter transaction_id op het purchase-event | Vergelijk de waarde met het echte bestel-ID, in DebugView en in een export van de volgende dag | Of een bepaalde betaalroute een lege of herhaalde waarde oplevert die in die ene testbestelling niet voorkwam |
| Worden de browser- en server-events van één aankoop in Meta samengevoegd tot één conversie? | Test Events en het tabblad Diagnostics in Meta Events Manager | Bevestig dezelfde event_id en eventnaam op beide kopieën van één purchase, ontvangen binnen Meta’s opgegeven deduplicatievenster | Of dezelfde discipline voor event_id bij elke bestelling geldt, niet alleen bij de gecontroleerde steekproef |
| Is per bestelling maar één purchase-route actief? | Shopify sales channels plus de configuratie van custom pixel of GTM | Controleer in de configuratie dat het native Shopify-kanaal en een custom pixel niet allebei dezelfde purchase versturen | Als beide actief zijn: of GA4 de overlap met transaction_id volledig dedupliceert of een deel mist |
| Komt het aantal gereconcilieerde bestellingen overeen met Shopify’s administratie? | Shopify-bestellingsexport gekoppeld aan GA4-purchase-export op transaction_id. Meta en Google Ads bieden geen feed per bestelling en worden daarom op totalen vergeleken | Koppel bestellingen regel voor regel op een gedeelde identifier in plaats van alleen totalen te vergelijken | Waarom een bestelling ontbreekt of dubbel voorkomt. De koppeling toont welke regels niet overeenkomen, niet het mechanisme erachter |
Wat verklaren consent en rapportage, en wat niet?
Niet elk verschil tussen een platform en Shopify-bestellingen is een defect. Consentkeuzes, gemodelleerd verkeer en platforms die alleen totalen rapporteren veroorzaken verschillen die er in een dashboard net zo uitzien als een bug. Dit gaat over de technische implementatie, niet over juridisch advies.
Vergelijkingstabel — scrol horizontaal om alle kolommen te bekijken
| Vraag | Gecontroleerde bron | Hoe je dit verifieert | Wat na deze controle onbekend blijft |
|---|---|---|---|
| Blokkeert of laat de consentbanner tags toe volgens de configuratie? | Consent Mode v2-signalen (ad_storage, analytics_storage) | Bekijk bestaande request-captures voor elke consentkeuze en controleer cookieless versus volledige payloads. Markeer als niet geverifieerd als die captures ontbreken | Of Google’s modellering geweigerd verkeer nauwkeurig herstelt. Dat gebeurt in Google’s systemen en is hier niet zichtbaar |
| Past het aandeel Unassigned-verkeer bij de consentopzet van deze winkel? | GA4 Traffic acquisition-rapport, regel Unassigned | Lees het percentage rechtstreeks uit het rapport voor de onderzochte periode | Er bestaat geen vaste grens waarboven Unassigned voor elke winkel te hoog is. Deze controle rapporteert het cijfer, niet een oordeel erover |
| Weerspiegelt Meta’s Event Match Quality wat de winkel daadwerkelijk verstuurt? | Meta Events Manager Overview, EMQ-score en uitsplitsing van parameters | Lees de score en eventuele ontbrekende of onjuist gevormde parameters voor de onderzochte pixel of dataset | EMQ meet de volledigheid van gegevens, niet advertentieprestaties. Een lage score betekent niet dat de campagne faalt |
| Rapporteert Google Ads conversies over dezelfde periode als Shopify de bestellingen toont? | Google Ads-conversierapport versus Shopify-bestellingen met hetzelfde datumbereik | Vergelijk de totale aantallen voor de periode, omdat Google Ads geen feed per bestelling biedt | Welke bestellingen achter een verschil zitten. Een vergelijking van totalen toont dat een verschil bestaat, niet welke bestellingen het betreft |
Conclusie en volgende stap
Een checklist als deze levert twee eerlijke uitkomsten op. Beide zijn geldig.
Geen defect gevonden binnen de onderzochte scope. De uitgevoerde controles vonden geen fout in de onderzochte systemen, bestellingen en periode. Leg daarbij ook de niet-geverifieerde regels en resterende beperkingen vast. Dit bewijst niet dat alle betaalroutes, de historische dekking of de attributie kloppen. Het stelt evenmin vast dat elk gerapporteerd cijfer correct is.
Verder onderzoeken. Eén of meer regels eindigen in de vierde kolom met een gat dat niet door consent, modellering of rapportage op totalen wordt verklaard. Bijvoorbeeld een herhaalde transaction_id, een pixel die stilviel of een server-event zonder bijpassend browser-event. Dat is een aanwijzing dat een specifieke oorzaak te vinden is, niet het bewijs dat je die al hebt gevonden.
In beide gevallen zou ik de bevindingen vastleggen zoals in het uitgewerkte voorbeeld van deze diagnosemethode: wat is gecontroleerd, wat het bewees en wat niet. Dat voorbeeld gebruikt een fictieve winkel, in hetzelfde formaat als bij een echte winkel.
Als een controle iets oplevert dat je niet kunt verklaren, is de volgende stap om het te beschrijven, niet om iets te kopen. Neem contact op met de winkel-URL, de regel die faalde en wat je zag. Als de oorzaak of scope echt een nadere blik met alleen leestoegang vraagt, verder dan wat je zelf met bovenstaande toegang kunt controleren, is daar de Health Check voor. Dat is alleen de volgende stap als zelf controleren zijn grens heeft bereikt.
