Wat first-party data is, waarom het zwaarder weegt nu cookies korter leven, en hoe je er via server-side tagging en je CRM meer uithaalt.
First-party data is alles wat je zelf verzamelt in je eigen kanalen: gedrag op je site of in je app, bestellingen in je webshop, klantgegevens in je CRM, e-mailinteracties, klantenservicegesprekken.
Je kent de herkomst, je bepaalt zelf hoe lang je het bewaart en je kunt het koppelen aan een klant die je al hebt. Third-party data komt van een partij die het elders verzamelde en aan je verkoopt of beschikbaar stelt. Je weet daar zelden hoe het is opgebouwd en hoe vers het is.
Safari en Firefox blokkeren third-party cookies standaard. Chrome heeft het afschaffen ervan afgeblazen, maar de rest van het speelveld is niet teruggedraaid.
Belangrijker voor je metingen: trackingpreventie kort ook de levensduur van cookies op je eigen domein in. Zet je een cookie met JavaScript via document.cookie, dan houdt Safari die maximaal zeven dagen vast. Een bezoeker die na negen dagen terugkomt is in GA4 een nieuwe gebruiker, met een nieuwe sessiebron.
Gevolg: je terugkerende bezoekers worden onderteld, je attributievensters worden korter dan ze in werkelijkheid zijn, en kanalen met een lange oriëntatie krijgen te weinig krediet.
Met server-side tagging zet je het analytics-cookie vanaf je eigen subdomein, via een HTTP-header in plaats van JavaScript. Dat is de belangrijkste winst van server-side: de teller loopt niet meer elke week terug op nul.
Twee dingen die verkopers van die oplossing vaak weglaten. Je container moet op een subdomein van je hoofddomein draaien, niet op een los domein van je leverancier, anders is het cookie alsnog third-party. En een subdomein dat via CNAME naar de infrastructuur van een ander wijst wordt door Safari herkend, waarna dezelfde zevendaagse limiet geldt. Een A-record naar een server binnen je eigen omgeving voorkomt dat.
Daarnaast bepaal je in de container welk veld naar welk platform gaat. Je kunt een e-mailadres hashen voordat het vertrekt, of een veld helemaal tegenhouden. Welke hostingroute daarbij past, beschreven we in server-side GTM bij Taggrs of Stape.
Je hebt gegevens die de advertentieplatforms niet hebben: wie er daadwerkelijk kocht, voor hoeveel, en wat er later retour kwam.
Enhanced Conversions in Google Ads. Je stuurt gehashte klantgegevens mee met de conversie, zoals e-mailadres, telefoonnummer en naam met adres. Google matcht die met ingelogde gebruikers en dicht een deel van het gat dat cookieverlies achterlaat. Hashen gebeurt met SHA-256, na normalisatie: spaties weg, kleine letters.
De Conversions API van Meta. Dezelfde gedachte, vanaf je server. Stuur je zowel de pixel als de server-events, gebruik dan één event_id in beide zodat Meta kan ontdubbelen.
Offline conversies uit je CRM. Voor leadgeneratie is dit de grootste winst. Je importeert welke lead een offerte werd en welke offerte een order, met de gclid of een gebruikersidentifier erbij. Daarmee stuurt Google Ads op getekende deals in plaats van op ingevulde formulieren.
First-party data is geen vrijbrief. Voor het terugsturen van klantgegevens naar advertentieplatforms heb je een grondslag nodig, en in de praktijk toestemming. De statussen ad_user_data en ad_personalization uit Consent Mode gaan precies hierover: zonder toestemming hoor je die gegevens niet mee te sturen.
Zolang je data in losse platforms zit, stuur je op wat elk platform zelf rapporteert. Breng je bestellingen, retouren, inkoopprijzen en advertentiekosten samen in een warehouse, dan kun je andere vragen stellen.
Welke campagne levert klanten op die binnen een jaar terugkomen. Bij welke productgroep verdwijnt de marge door retouren. Welke kanalen vallen weg als je nieuwe klanten zwaarder weegt dan herhaalaankopen.
De koppeling die dat mogelijk maakt is meestal saai: een order-id dat je zowel in je gebeurtenisdata als in je backend terugvindt. Zorg dat die twee op elkaar aansluiten voordat je aan modellen begint.
Wil je hierover doorpraten?