Wat cookie-sync is¶

Twee partijen kennen jou allebei, elk onder een eigen nummer. De ene noemt je A-4821, de andere X-99f0. Zolang die nummers los blijven, heeft elke partij een half dossier dat het andere half niet kan vinden. Cookie-sync is het moment waarop ze elkaars nummer voor dezelfde persoon uitwisselen. Vanaf dan weet partij A dat haar A-4821 dezelfde mens is als de X-99f0 van partij B. Ze kunnen hun profielen op elkaar leggen.

Het is een koppeltabel, meer niet. Aan de ene kant het interne id van de ene partij, aan de andere kant dat van de andere. Zodra die tabel gevuld is, gedragen twee ondernemingen die formeel niets met elkaar te maken hebben zich als één geheugen.

Waarom het bestaat¶

Cookie-sync lost een technisch probleem op dat inherent is aan het web. Een cookie is per definitie gebonden aan het domein dat hem heeft gezet. De cookie die partij-a.example op jouw browser plaatst, is voor partij-b.example onleesbaar. Dat is de kern van de same-origin-gedachte. Voor de advertentieketen is dat lastig, want daar werken tientallen partijen samen aan hetzelfde bod op dezelfde persoon.

De oplossing is een uitwisselingsronde. Wanneer je een pagina laadt, laten de betrokken partijen je browser een reeks verzoeken afvuren waarin ze elkaars id's ophalen en aan elkaar knopen. Dit gebeurt in de milliseconden voordat een advertentie geladen wordt, vaak als opstap naar een biedronde. Zie Real-time bidding biedt jouw toestel in een veiling aan, in milliseconden voor waar dit vervolgens in uitmondt.

Hoe het over de lijn eruitziet¶

Cookie-sync is zichtbaar in het netwerkverkeer, en dat is precies waarom het als bewijs bruikbaar is. In een HAR zie je een keten van omleidingen waarin het id van de ene partij als parameter in de URL van de andere staat. Het patroon is herkenbaar:

GET https://partij-a.example/sync?redir=partij-b.example&uid=A-4821
  -> 302 Location: https://partij-b.example/match?partner=a&partner_uid=A-4821
  -> 302 Location: https://partij-a.example/setmap?their_uid=X-99f0

De eerste partij stuurt haar eigen id mee en wijst de browser door. De tweede partij ziet dat id, plakt haar eigen id erbij, en stuurt de browser terug zodat beide kanten de koppeling kunnen opslaan. Het label voor deze bevinding is gemeten: de id's staan letterlijk in de vastgelegde verzoeken. Ik lees ze uit de HAR, niet uit een verondersteld gedrag. Zie Netwerkverkeer lezen via HAR-files.

Het equivalent in apps¶

Op het web draait dit om cookies. In apps bestaat hetzelfde mechanisme met andere identifiers. Daar is er vaak een stabiel apparaat-id, zoals de reclame-identifier van het besturingssysteem, en daarnaast installatie-id's die een SDK zelf toekent. Partijen wisselen die uit op dezelfde manier: ik ken dit toestel als dit nummer, ken jij het ook, dan zijn onze dossiers van dezelfde persoon.

Het maakt voor de aard van de koppeling weinig uit of de sleutel een cookie of een apparaat-id is. Zie Een resetbare identifier is alsnog een sleutel: ook een reclame-id die je in theorie kunt resetten, functioneert tot dat moment als een vaste sleutel waarmee losse partijen dezelfde persoon herkennen.

Er is wel een verschil in duurzaamheid. Een cookie kun je wissen, en dan is de koppeltabel aan jouw kant leeg. Een apparaat-id blijft over browsers en apps heen gelijk, tenzij je hem bewust reset. Daardoor reikt de herkenning in apps vaak verder dan op het web. Twee onverwante apps die dezelfde reclame-id zien, kunnen langs dezelfde weg vaststellen dat het om hetzelfde toestel gaat, ook zonder dat ze ooit direct met elkaar praten. Zie Onverwante apps sturen je profiel dezelfde veiling in voor hoe die gedeelde herkenning vervolgens in één advertentieveiling samenkomt.

Waarom dit meer is dan de som van losse trackers¶

De reden dat cookie-sync ertoe doet, zit in wat het met de rest van de waarnemingen doet. Stel dat ik op een site tien trackers meet. Zonder koppeling zijn dat tien partijen met elk een eigen, beperkt beeld. De ene weet dat je deze pagina bezocht, de andere dat je op een knop klikte, een derde welk toestel je gebruikt. Los van elkaar zijn dat scherven.

Een gemeten sync tussen die partijen legt de scherven op elkaar. Nu weet de partij die je klik zag ook welk toestel je gebruikt, want ze deelt een sleutel met de partij die dat wist. Het profiel dat ontstaat, is rijker dan wat één partij ooit alleen kon opbouwen. Dat is waarom ik een sync zwaarder weeg dan een losse tracker: het verandert de aard van de verzameling. Zie Het risico zit in de optelsom, niet in het losse veld, waar ik uitwerk dat het risico zelden in één stroom zit. Het zit meestal in wat de stromen samen mogelijk maken.

Het maakt ook de biedketen begrijpelijk. Real-time bidding werkt alleen als tientallen partijen weten dat een binnenkomend bodverzoek over dezelfde persoon gaat die zij al kennen. Cookie-sync is de infrastructuur die dat mogelijk maakt. Zonder de koppeling zou elke partij een anonieme, losse impressie zien. Met de koppeling zien ze een herkenbaar persoon met een geschiedenis. In de OpenRTB-standaard is die herkenning terug te vinden als het meesturen van gebruikers-id's in het bodverzoek, en die id's zijn bruikbaar dankzij een eerdere sync.

Wat het bewijst¶

Cookie-sync is hard bewijs van herkenning. Het laat zien dat partijen die los van elkaar lijken te staan, achter de schermen dezelfde persoon volgen en dat ook onderling afstemmen. Dat is een sterkere bevinding dan een losse tracker. Een losse tracker toont dat één partij je ziet. Een sync toont de koppeling zelf, het punt waarop twee waarnemingen tot één dossier worden gesmeed.

Voor mijn werk is dat het waardevolle deel. Een lijst van tien trackers zegt dat tien partijen aanwezig waren. Een gemeten sync tussen twee ervan zegt dat die twee samen meer weten dan elk apart. Dat tilt de bevinding van "veel partijen" naar "een gedeeld profiel".

Wat het niet bewijst¶

Het bewijst geen bod en geen verkoop. Dat twee partijen hun nummers matchen, betekent dat ze je kunnen herkennen. Het betekent niet dat er op dat moment een advertentie is verhandeld of dat er geld is gevloeid. Herkenning en transactie zijn twee aparte claims, en ik houd ze streng uit elkaar.

Die scheiding is niet academisch. Als ik zeg "hier is een advertentie op je verkocht" moet ik het bod kunnen tonen, met de biedstroom en de partijen erin. Als ik alleen de sync heb, zeg ik "deze twee partijen kunnen je als dezelfde persoon herkennen", en meer niet. Wie de sterkere claim maakt op basis van het zwakkere bewijs, geeft de tegenpartij precies de opening waar ze op wacht. Zie Een naam in de code is nog geen tracker voor hetzelfde principe aan de meetkant.

Wat het juridisch raakt¶

Een gemeten sync raakt aan artikel 26 van de AVG, de bepaling over gezamenlijke verwerkingsverantwoordelijken. Op het moment dat twee partijen gezamenlijk bepalen dat ze dezelfde persoon herkennen en hun profielen koppelen, is de vraag gerechtvaardigd of ze samen verantwoordelijk zijn voor die verwerking. Ik trek die juridische conclusie niet zelf in het meetrapport. Ik lever de meting die de vraag scherp maakt.

Een sync kan soms onschuldig lijken, bijvoorbeeld om dubbele advertenties te voorkomen of om frequentie te beperken. Dat kan. Het doel van de koppeling meet ik niet, en dat geef ik toe. Wat ik meet is dat de koppeling bestaat en dat de twee partijen daarna dezelfde persoon kunnen aanwijzen. Het legitieme doel dat een partij aanvoert, verandert die technische werkelijkheid niet. De herkenning is er, ongeacht waarvoor ze wordt ingezet.

Dat is precies waarom cookie-sync het mechanisme is dat losse waarnemingen tot een dossier smeedt. Het verklaart hoe een handvol op zichzelf onschuldig ogende trackers samen een compleet beeld kan opleveren. Zie Het risico zit in de optelsom, niet in het losse veld.

Zie ook Een resetbare identifier is alsnog een sleutel, Real-time bidding biedt jouw toestel in een veiling aan, in milliseconden en Onverwante apps sturen je profiel dezelfde veiling in.