A qui la faute ?

Edit du 25/09/2020 : nous avons constaté ce jour un changement majeur dans le fonctionnement des tags AdSense : lors de nos tests le chargement de la CMP n’est désormais plus soumis à un timeout qui conduisait à des erreurs 2.1a. Sirdata remercie vivement les équipes Google d’avoir tenu compte de cette demande de correction. Communication officielle

Google prend désormais part au Transparency & Consent Framework v2.0 de l'IAB Europe, la solution d'aide à la conformité à ePrivacy et au RGPD, et annonce respecter ses Règles et spécifications.

Nous en sommes heureux car Google fait partie de nos partenaires privilégiés et que nous faisons nous-mêmes partie du TCF depuis l'origine. Sirdata est enregistrée comme Vendor (ID 53) et comme CMP (ID 92) depuis le lancement du standard.

Google diffuse et transmet la cha√ģne de TC (TC String) pour toutes les demandes d'annonces depuis la mi-ao√Ľt 2020 et a produit des consignes d'interop√©rabilit√© qui visent √† satisfaire les exigences actuelles des r√®gles de Google, en particulier celles des R√®gles de Google relatives au consentement de l'utilisateur dans l'UE et de ses r√®gles interdisant la r√©cup√©ration de l'empreinte num√©rique √† des fins d'identification (par exemple, celles contenues dans ses Conditions requises pour la diffusion d'annonces par des tiers).

Afin de laisser aux √©diteurs le temps de g√©rer les erreurs et les mauvaises configurations li√©es au lancement du Transparency & Consent Framework v2.0, Google produit des rapports d'erreurs d√©tect√©es et autorise un d√©lai de gr√Ęce de 90 jours pour r√©soudre les erreurs.

C'est dans ce cadre qu'à notre connaisance, de nombreux éditeurs utilisant une CMP compatible avec le TCF v2 ont reçu des alertes de la part de Google dans leur console AdSense et ou Ad Manager.

Malgré la qualité de nos solutions, nos partenaires n'ont pas été épargnés. Dans la plupart des cas, il s'agit des alertes 1.1 et 2.1a que nous étudions ci-dessous :


I- Erreur 1.1

Selon la documentation Google, les erreurs de classe 1 emp√™chent toujours la diffusion d'annonces en r√©ponse aux demandes et ne donnent lieu √† aucun d√©lai de gr√Ęce.

Ces erreurs prévalent toujours sur les autres types d'erreur, même si une requête donnée en comporte plusieurs.

Voici la définition de l'erreur 1.1 et des erreurs proches :

L'"erreur" 1.1 survient lorsque les tags publicitaires de Google sont appelés sans (avant) que l'utilisateur ait donné son consentement pour Google en tant que Vendor (ID 755 dans le TCF).

Cela peut résulter :

  • D'une non-pr√©sentation de Google comme partenaire de l'√©diteur dans la CMP (Vendor)
  • D'un choix de l'utilisateur de rejeter le Vendor Google

Lorsqu'un site charge un script AdSense (adsbygoogle.js) sans consentement pour Google (Vendor ID 755 dans le TCF), il contrevient aux Règles de Google relatives au consentement de l'utilisateur dans l'UE, qui imposent le recueil du consentement pour les cookies et pour le traitement de données personnelles par Google et ses partenaires, permettant de servir des publicités personnalisées ou non.

En revanche, il ne s'agit pas d'une erreur d'intégration de la CMP mais d'un problème de conditionnement des tags publicitaires de Google.

Google reconna√ģt, √† propos des CMP, que ce type de "solutions peuvent √™tre configur√©es de diff√©rentes fa√ßons..." et qu'"il est important de noter que de telles configurations ne contr√īlent pas automatiquement la collecte de donn√©es ou les cookies."

Le TCF est architectur√© sur le principe de Privacy by Design et permet un conditionnement √† toutes les √©tapes par chaque acteur concern√© : un Vendor a la facult√© de requ√™ter l'API de la CMP pour d√©terminer son statut de consentement et doit agir en cons√©quence. Le conditionnement de chargement des tags est une bonne m√©thode, mais le conditionnement de fonctionnement de ces m√™mes tags par eux-m√™mes est beaucoup plus s√Ľr.

C'est pourquoi le TCF n'exige pas d'un √©diteur de site (Publisher) qu'il conditionne les appels les tags, mais qu'il mette via sa CMP un signal √† la disposition de chaque Vendor pour lui permettre de contr√īler ce qu'il peut faire ou non et agisse en cons√©quence.

Les Policies du TCF précisent en effet :

Le TCF requiert que les √©diteurs permettent √† chaque Vendor de contr√īler son statut gr√Ęce √† la TC String ("tcString") obtenue aupr√®s de l'API de la CMP ou via un Vendor en amont qui lui-m√™me l'a obtenue aupr√®s de la CMP, et ainsi de suite.

De m√™me, gr√Ęce √† cette TC String, un Vendor pourra contr√īler le statut d'un autre Vendor en aval pour d√©terminer s'il b√©n√©ficie d'un consentement pour les traceurs et d'une base l√©gale √©tablie pour la finalit√© poursuivie avant de lui transmettre une donn√©e.

C'est ce que fait Google lorsqu'il décode la TC String pour déterminer à quels partenaires il va transmettre une bid request : il n'enverra par exemple aucune donnée à un partenaire qui ne bénéficie pas du consentement pour les cookies en France.

Nous nous sommes intéressés au fonctionnement des scripts de Google... Afin d'activer AdSense sur son site un éditeur doit charger le script suivant :

Pour intégrer la demande relative au consentement de Google, nous avons, avec nos partenaires, suivi les exemples de code d'annonce de la section de l'aide Google relative à ses Règles relatives au consentement de l'utilisateur dans l'Union européenne :

Nous avons implémenté ces recommandations et lançons automatiquement la commande suivante à l'initialisation de la CMP, pour mettre en pause AdSense avant de finir de charger la CMP et interagir avec l'utilisateur si nécessaire :

Puis, une fois la CMP chargée et les choix de l'utilisateur établis, nous lançons la commande suivante pour permettre à Google de récupérer le signal de consentement conformément aux spécifications du TCF :

Malgré cette mise en pause et sans information de consentement donnée par la CMP, le script adsbygoogle.js va charger d'autres scripts lui permettant d'accéder à ses cookies publicitaires :

Ce dernier script interagit pr√©cis√©ment avec la CMP afin de r√©cup√©rer le statut de choix de l'utilisateur et v√©rifier que ce dernier a bien donn√© son consentement au moins √† Google (TCF Vendor ID 755) et au moins au d√©p√īt des cookies (Purpose 1 du TCF).

Voici la fonction gr√Ęce √† laquelle Google utilise l'information r√©cup√©r√©e aupr√®s de la CMP :

et o√Ļ la fonction Gy est d√©finie ainsi :

Comprendre :

  • Si tcData n'existe pas (gestion du consentement hors TCF) la publicit√© est servie
  • Si le RGPD ne s'applique pas (utilisateur non localis√© en Europe par exemple) la publicit√© est servie
  • Si la TC String est √©gale √† "tcunavailable" la publicit√© est servie
  • Si l'utilisateur a donn√© son consentement au Vendor 755 ET √† la Purpose 1 (OU bien si la Purpose 1 n'est pas obligatoire selon l'√©diteur et que ce dernier est en Allemagne) la publicit√© est servie

Alors l'URL d'appel de la bannière est construite et comporte différentes variables dont potentiellement gdpr (1 ou 0 suivant que l'utilisateur est soumis au RGPD ou non), gdpr_consent (la TC String, si gdpr=1), et tcfe (le code erreur de Google) le cas échéant :

S'il n'y a pas d'erreur et que le test de consentement pour Google et les cookies est positif alors ce script déclenche l'appel publicitaire via une url de ce type :

https://googleads.g.doubleclick.net/pagead/ads?client=ca-pub-XXXXX&slotname=YYYYYYYY&gdpr=1&gdpr_consent=CO5Gj0RO5HNPHBcABBENA1CoAP_AAH_AAAqIGMtd_X9fb2vj-_5999t0eY1f9_63v-wzjgeNs-8NyZ_X_L4Xr2EyvB36pq4KmR4ku3bBAQFlHOHcTQmQwIkRqTKsbk2Mr7NKJ7LEilsbM2dIGG9Pn8XTOYAR5k7Ed_3h3nUowAIGMkEmGpfAQJCWMBJNmlUKIEIVxIVAOACihGFo0sNCRwU7K4CPUECABAagIwIgQYgoxZBAAAAAEFEQAkAwIBAARAIAAQArQEIACJAEFgBIGAAACgGhYARRAIBIAZGBUUggAEAAAAAA&addtl_consent=1~1671.1248.587.62.89.1201.338.253.272.1236.1126.2572.448&format=375x200...

La réponse comporte alors le code bannière.

Dans cet appel, on retrouve :

  • Le param√®tre gdpr qui doit √™tre √©gal √† 1 pour un utilisateur localis√© en Europe
  • Le param√®tre gdpr_consent qui est la forme encod√©e des choix effectu√©s par l'utilisateur. La valeur est appel√©e la TC String et peut √™tre d√©cod√©e sur le site https://iabtcf.com/#/decode

S'il n'y a pas d'erreur et que le test de consentement pour Google et les cookies est négatif alors ce script déclenche l'appel publicitaire via une url de ce type :

https://googleads.g.doubleclick.net/pagead/ads?client=ca-pub-XXXXX&slotname=YYYYYYYY&gdpr=1&gdpr_consent=CO5LH6oO5LWrcBcABCENA1CgAAAAAAAAAAqIGVwHwCQgGvAPQAfwBOwCqwFbAK7AV-AscBZQC0gFqgLXAW-AukBdwC8QF6gL6AX-AwEBgYDBoGEAYVAw0DD4GIgYxAxoDJQGTgMpAZWBlcBUA14B6AE7AK2Av2AsoBbQC6QF3gL6AYIAwYBhIDDYGHgYgAxIBiwDGAGPQMhAySBk4GUAAA&addtl_consent=1~1671.1248.587.62.89.1201.338.253.272.1236.1126.2572.448&format=375x200...

Cet appel n'obtient pas de code bannière en réponse.

La différence entre les deux appels se situe notamment dans la TC String que Google reçoit dans le paramètre gdpr_consent et qui, une fois décodée, lui indiquera dans le premier cas qu'il a le consentement pour les cookies, mais pas dans le deuxième.

Dans le premier cas, il y aura une réponse :

Mais pas dans le deuxième :

Il convient de noter que, dans les deux cas, l'appel de bannière qui est initié par le script show_ads_impl_fy2019.js donne accès à Google à ses cookies :

A ce titre, Google réalise ce traitement sans justifier d'un consentement préalable pour les cookies dans le TCF, et ne peut s'appuyer sur la Special Purpose 1 (Ensure security, prevent fraud, and debug) pour se prévaloir d'une base légale.

Le script adsbygoogle.js int√©gr√© par l'√©diteur va donc d√©clencher l'insertion d'un second script qui va permettre d'op√©rer les contr√īles dans le cadre du TCF : si le test sur son ID (755) ou encore celui sur la Purpose 1 √©chouent alors ce script de Google d√©tecte l'absence de consentement... Et d√©clenche malgr√© tout l'appel d'un troisi√®me tag qui comporte des traceurs et des donn√©es personnelles.

Bien que la réponse soit vide, l'appel en lui-même est problématique : même si Google veut se réfugier derrière l'obligation qu'il impose à l'éditeur de recueillir un consentement avant d'intégrer le premier script (adsbygoogle.js), il ne peut ignorer que l'utilisateur n'a pas donné son accord lors de l'exécution du second.

En initiant les appels de cette manière pour a minima loguer et déclarer par la suite des erreurs de classe 1, nous pensons que Google n'a pas correctement mis en place les mesures d'Accountability qui s'imposent.

En déployant une CMP compatible avec le TCF v2 et en travaillant avec des Vendors qui s'engagent à respecter les signaux, les éditeurs font un effort de conditionnement et de conformité.

Le fait que le script de Google ignore l'issue du test c√īt√© client et d√©clenche le dernier appel malgr√© le signal re√ßu d'absence de consentement n'est pas conforme aux Policies du TCF selon nous. Google ma√ģtrise pourtant ce type de conditionnement puisqu'il le met en oeuvre dans le cadre de son propre programme Google Consent Mode qu'il a lanc√© le 3 septembre 2020. Pur hasard de calendrier...

D'un point de vue contractuel, les erreurs 1.1 sont imputables à l'éditeur qui ne conditionnent pas ses tags et appelle Google sans consentement, et ce indépendamment du TCF et de l'implémentation de notre CMP.

En th√©orie, un tel conditionnement suffit √† faire dispara√ģtre l'erreur 1.1... Dans la pratique, il existe malheureusement des situations que l'√©diteur ne ma√ģtrise pas et qui perturbent le conditionnement des tags adsbygoogle.js ou gpt.js : il suffit qu'un script tiers injecte un de ces deux tags sur la page et cela d√©clenche les appels de publicit√© de mani√®re incontr√īl√©e malgr√© l'effort de l'√©diteur.

Pour toutes ces raisons, nous pensons raisonnablement que Google ne respecte pas les Policies du TCF en déclenchant ses tags d'appels bannières alors même que la CMP lui indique qu'il ne bénéficie pas du consentement nécessaire.

Si Google veut logguer les implémentations de ses tags sans consentement, nous suggérons qu'ils ne traitent aucune donnée personnelle dans le même temps et utilisent pour ce faire des tags sur un domaine distinct de ses activités publicitaires et qui n'emporte pas de cookies.

Nous sommes heureux clients et utilisateurs satisfaits de nombreux services de la galaxie Google (moteur de recherche, suite Google Pro, Google Cloud, Marketing Suite...). Dans tous ces domaines et en particulier dans la publicité digitale, Google propose une technologie parmi les meilleures au monde et semble placer l'efficacité au dessus de tout.

Dans nos propres d√©veloppements, nous priorisons l'int√©r√™t de l'utilisateur. Ce qui nous conf√®re une certaine habilet√© dans la compr√©hension et la mise en Ňďuvre des interactions entre technologie et vie priv√©e. Nous aurions appr√©ci√© √™tre inform√©s de ces protocoles de tests que nous jugeons mal formul√©s lorsque nous avons pr√©par√© l'arriv√©e de Google √† l'occasion de la transition vers la v2 du TCF.

Nous serions heureux d'aider Google à clarifier la documentation et les messages d'erreur communiqués aux éditeurs pour apporter une plus grande transparence sur les responsabilités de chacun.

En effet, malgré l'effort rédactionnel de Google et la densité d'informations produites sur le consentement, nous pensons donc que les éditeurs n'ont pas pleinement conscience de ce qu'attend Google.

Ils ne semblent pas tous percevoir non plus la portée des changements réglementaires et l'articulation des différentes lois (Informatique et Libertés par exemple), Directives (ePrivacy...) et Réglements (RGPD...).

A défaut de comprendre, le réflexe est en général de reproduire ce que font les leaders de l'Adtech sur leurs propres actifs et c'est ainsi qu'ils peuvent s'inspirer du moteur de recherche de Google qui affiche à un nouvel Internaute une page de résultats de ce type :

En plus des résultats de sa recherche, l'Internaute se voit afficher :

  • Un message d'information lui expliquant que Google a recours √† des cookies et l'invite √† les accepter
  • Des publicit√©s ("annonces")

Une rapide consultation de la console permet de constater que des cookies ont été déposés au chargement de la page sans que l'Utilisateur ait cliqué sur le bouton "J'accepte", et en particulier les cookie NID et ANID sur le domaine google.com :

Ces cookies servent, selon les Règles de confidentialité et conditions d'utilisation de Google, notamment à enregistrer les recherches effectuées par les internautes sur le site de Google et leurs visites sur le site Web d'un annonceur afin de leur afficher par la suite des annonces personnalisées sur Google :

D'autres cookies sont déposés, dont l'un est nommé "CONSENT" et prend, au premier chargement de la page (avant les messages de consentement de Google) dans notre test, la valeur suivante :

Puis une fois le consentement donné sa valeur change pour "YES" :

Des cookies publicitaires ou pouvant servir à de la publicité sont déposés sans (avant) que l'utilisateur ait donné son consentement à Google, ce qui correspond selon nous à la définition de l'erreur 1.1.

Nous sommes convaincus que les méthodes et outils de Google sont respectueux de la vie privée et du cadre réglementaire. Mais nous comprenons que des éditeurs à qui Google demande de ne pas procéder de la sorte et à qui ces "erreurs" sont reprochées soient perplexes voire perdus.

Google ne devrait pas, selon nous, se contenter de demander le recueil du consentement préalable à l'utilisation de ses tags publicitaires à ses partenaires éditeurs. Il serait plus prudent d'implémenter intégralement le TCF, et ses méthodes, et ainsi conditionner les appels finaux de bannières en fonction des choix des Internautes, et ce même si les scripts initiaux sont injectés systématiquement, par erreur ou par mimétisme...


II- Erreur 2.1a

Selon la documentation Google les erreurs de classe 2 sont li√©es au d√©lai de gr√Ęce 0 qui s'applique comme suit : Pendant les 30 premiers jours du d√©lai de gr√Ęce, les √©diteurs pourront r√©soudre les probl√®mes de mauvaise configuration sans cons√©quence sur la mon√©tisation.

Pendant les 60 jours restants du d√©lai de gr√Ęce, des annonces non personnalis√©es seront diffus√©es, quels que soient les param√®tres des annonces personnalis√©es et non personnalis√©es existantes.

Une fois le d√©lai de gr√Ęce √©coul√©, aucune annonce ne sera diffus√©e en r√©ponse aux demandes d'annonces.

Pour comprendre ce code erreur, il faut prendre connaissance du fonctionnement du TCF et en particulier des statuts possibles de la CMP :

Lors d'une s√©quence de chargement correcte le statut (cmpStatus) de la CMP doit donc d√©buter √† "stub" lorsqu'elle est initi√©e, passer √† "loading" (bient√īt d√©pr√©ci√©) lorsqu'elle charge, et enfin √† "loaded" une fois charg√©e.

Si pour une raison ou une autre, elle conna√ģt un probl√®me au chargement ou apr√®s, alors, cmpStatus sera d√©fini √† "error".

Ainsi avec l'erreur 2.1a, Google informe les éditeurs du nombre de fois :

  • O√Ļ la CMP a √©t√© en erreur
  • O√Ļ la CMP est rest√©e bloqu√©e √† l'initialisation
  • O√Ļ la CMP est rest√©e bloqu√©e lors du chargement

Pour certains éditeurs, le nombre d'erreurs était cependant très élevé, beaucoup plus élevé que les taux d'erreurs ou de blocages mesurés lors de nos tests.

Nous avons donc investigué plus avant et isolé deux problèmes fondamentaux : le premier est lié aux tags de Google et le second à des tags de tiers.

1) Implémentation par Google du TCF

Les tags de Google ont été adaptés comme expliqué ci-dessus afin de décoder les signaux du TCF (prioritaires sur les autres signaux de Google sauf si plus permissifs).

Il ressort de nos investigations que Google a semblé préférer l'efficacité au respect du choix de l'utilisateur en paramétrant un timeout de 500 millisecondes pour le chargement de la CMP parmi tous les scripts de la page : au bout de ce délai, le script mentionné au premier point (adsbygoogle.js) coupe le processus et renvoie l'erreur tcfe=1 et la valeur "tcunavailable" pour le paramètre gdpr_consent.

Ce timeout n'est pas le délai accordé à la CMP seule mais à tous les scripts qui s'exécutent dans la fenêtre accordée de 500 millisecondes, ce qui est trop peu, et chaque chargement de CMP interrompu est comptabilisé comme une erreur 2.1a par Google.

Nous pensons que le timeout est à l'origine de l'essentiel des erreurs qui constituent cette classe et que notre CMP n'est pas en erreur dans la plupart des cas rapportés.

Le problème est que les serveurs de Google qui reçoivent cet appel ne liront pas les signaux de consentement mais l'information "tcunavailable", la réponse peut comporter une publicité.

Lors de nos tests, nous avons vu des bannières qui ont recours à des cookies et de la donnée personnelle :

Un clic sur l'ic√īne d'information ne laisse pas de place au doute : les publicit√©s sont personnalis√©es.

Cela correspond √† l'explication fournie par Google : "durant la p√©riode de gr√Ęce malgr√© cette erreur 2.1a des publicit√©s personnalis√©es seront affich√©es pendant 30 jours, puis des publicit√©s non personnalis√©es durant encore 60 jours".

Du point de vue de l'éditeur et pour Google l'effort est louable : les revenus de chacun sont maintenus au moins en grande partie. Mais du point de vue de l'Internaute, c'est plus problématique : lors de nos tests, toutes ces publicités personnalisées ont été affichées alors que nous avions refusé au préalable les cookies et tous les Vendors dont Google.

Des Fournisseurs de technologie publicitaire partenaires de Google sont également susceptibles d'avoir reçu et traité de la donnée personnelle malgré eux.

Le script de Google n'attend pas la fin du chargement et l'eventStatus "tcloaded" à cause de l'atteinte du timeout. Pour cette raison il ne reçoit pas systématiquement le signal de la CMP ni la TC String correspondante mais utilise malgré tout ses traceurs et de la donnée personnelle. Donc potentiellement sans consentement voire malgré un refus comme dans nos tests.

Compte tenu des statistiques habituelles, on peut estimer que 10 à 15% des erreurs 2.1a comptabilisées au global ont masqué des refus et permis de déclencher à tort une publicité ciblée. Compte tenu du poids de Google dans la publicité en ligne (2 millions d'éditeurs adhérents), même si tous n'ont pas encore implémenté une CMP compatible TCF v2, cela représente probablement des centaines de millions voire des milliards d'impressions !

Nous estimons donc qu'en l'état ce timeout peut représenter un danger très important pour le respect de la Vie Privée.

Nous estimons également qu'en interrompant le processus avant le chargement de la CMP et en ne recevant ainsi pas le statut de consentement, Google ne respecte pas les Policies du TCF et en particulier ces articles :

2) Les tags de tiers

Le second problème est lié à des tags tiers sur les pages (ni un tag de l'éditeur, ni la CMP, ni Google) qui perturbent voir corrompent le fonctionnement du TCF. Beaucoup de petites erreurs vont déclencher des latences mais dans certains cas c'est plus grave : l'API de la CMP est écrasée par un API fictive qui vient modifier ou générer des signaux de consentement.


III- Impacts business et évolution

Suggestion aux éditeurs

Beaucoup d'√©diteurs √©changent entre eux et avec nous au sujet des r√®gles relatives √† la vie priv√©e. Non que Google n'a pas inform√© qu'il est n√©cessaire de recueillir un consentement pour les cookies et Google pr√©alablement √† toute invocation de leurs tags publicitaires, mais plut√īt que la fa√ßon dont l'information a √©t√© r√©dig√©e et mise √† disposition des √©diteurs ne leur a pas permis d'appr√©hender correctement leurs obligations.

Le marché se trouve actuellement dans une temporalité particulière : de nombreux éditeurs qui ont, à tort ou involontairement, invoqué ces dernières années des publicités personnalisées et basées sur des cookies pour 100% de leur trafic découvrent qu'il faut s'équiper d'outils ou de mesures de conformité et que l'impact économique est très important.

Des baisses de 10% à 50% des revenus nous sont communiquées.

Ainsi de nombreux éditeurs qui n'ont finalement pas le sentiment de devoir impérativement mettre en oeuvre ces dispositifs sont tentés de continuer à invoquer systématiquement les tags publicitaires ciblés, voire de revenir en arrière après avoir déployé une CMP par exemple.

Ce serait une grave erreur, et nous sugg√©rons aux √©diteurs qui y songent d'oublier cette id√©e et d'accepter de perdre une partie de leurs revenus aujourd'hui plut√īt que la totalit√© demain.

En effet avec la publication prochaine par la CNIL de sa nouvelle Recommandation Traceurs nous entrons dans une nouvelle √®re de contr√īles. Le d√©p√īt de cookies sans consentement est visible dans la console des navigateurs sans aucun logiciel additionnel n√©cessaire et expose particuli√®rement les acteurs en cause, c'est-√†-dire les Responsables de Traitements.

Dans la relation qui lie Google aux √©diteurs, Google semble √™tre la plupart du temps (co-)Responsable de Traitement, ce qui signifie qu'en cas de contr√īle CNIL l'√©diteur qui permet √† Google de d√©poser des cookies sera inqui√©t√© mais Google aussi.

Nous pensons qu'√† l'√©vidence Google ne peut pas prendre un tel risque et va mettre en place des mesures pour √©viter un tel sc√©nario. Dans l'information que Google d√©livre aux Internautes une mention appara√ģt d'ailleurs :

Google annonce fermer unilatéralement des centaines de milliers de comptes qui, entre autres, utilisent de façon abusive les informations personnelles des Internautes.

Il serait très facile de détecter quels éditeurs ne respectent pas les règles, et les plus exposés selon nous, sont ceux qui utilisent à la fois les outils publicitaires et les outils d'analytics.


Retrouvez l'article de Mind Media à ce sujet :

Beno√ģt Oberl√© (Sirdata) : ‚ÄúGoogle doit mieux respecter les policies du TCF‚ÄĚ
Benoît Oberlé, fondateur et président de l’entreprise française Sirdata, spécialisée dans la collecte et l’utilisation des données à des fins de marketing, estime que Google, acteur central dans l’écosystème publi‚Ķ