Gestion du consentement via le pixel OpenAI

Le 24 août, les publicités ChatGPT commenceront à apparaître sur 31 marchés européens. Elles s'accompagneront du pixel de conversion d'OpenAI, qui sera probablement ajouté à un nombre croissant de sites web européens.

Pour les spécialistes du marketing, la configuration sera familière. Le pixel OpenAI suit un modèle similaire à celui de Meta et Google : un SDK basé sur le navigateur, des événements de conversion standard, une API de conversions côté serveur et la déduplication entre les événements du navigateur et du serveur.

Il inclut également un contrôle du consentement. Cela semble rassurant, mais il y a un hic : sauf modification de la configuration, le consentement est activé par défaut.

Fonctionnement du contrôle du consentement d'OpenAI

Le pixel fournit une commande de consentement simple. OpenAI exige que vous définissiez l'état de consentement du visiteur avant d'initialiser le pixel, puis que vous le mettiez à jour lorsque le visiteur fait un choix :

oaiq("consent", false);

oaiq("init", {
pixelId: "<VOTRE-ID-PIXEL>",

});

// Appeler cette fonction après que l'utilisateur a donné son consentement à la mesure.

oaiq("consent", true);

Si vous avez déjà utilisé Meta Pixel, le fonctionnement devrait vous sembler familier. Meta utilise fbq('consent', 'revoke') avant l'initialisation et fbq('consent', 'grant') ensuite. OpenAI utilise des booléens plutôt que des chaînes de caractères, mais le principe reste le même.

Malheureusement, le problème sous-jacent est également identique.

Le comportement par défaut est contraire aux exigences de consentement de l'UE

Selon la documentation d'OpenAI, le consentement est défini par défaut sur « true », sauf si vous le définissez explicitement sur « false » ou si le pixel détecte un refus enregistré précédemment.

Ceci est particulièrement important pour les sites web européens.

Si vous ajoutez le pixel en utilisant l'implémentation standard de démarrage rapide et sans apporter d'autres modifications, il se comportera comme si chaque visiteur avait déjà consenti à la mesure. L'activité de conversion peut donc commencer dès la première page vue.

La réglementation européenne sur la protection des données exige généralement l'approche inverse. Dans le cadre de la directive ePrivacy et du RGPD, le consentement doit généralement être obtenu avant que des technologies non essentielles ne stockent des informations sur l'appareil d'un visiteur ou n'y accèdent.

Autrement dit, le point de départ réglementaire est en réalité « non ». Le point de départ technique du pixel est, quant à lui, « oui ».

OpenAI est loin d'être un cas isolé. Meta et une grande partie de l'écosystème des technologies publicitaires fonctionnent de manière similaire. Cela ne fait que confirmer une leçon pratique : il incombe à l'annonceur de s'assurer que l'implémentation se déroule dans le bon ordre.

Un autre point mérite d'être examiné.

OpenAI affirme qu'en cas de consentement « false », aucune requête d'événement de mesure n'est envoyée et que les événements bloqués avant le consentement ne sont pas rejoués rétroactivement une fois celui-ci accordé.

Ce que la documentation ne semble pas garantir, c'est que le SDK lui-même ne se chargera pas, ni qu'aucune donnée ne sera écrite sur l'appareil du visiteur.

Le SDK est toujours hébergé sur l'infrastructure d'OpenAI. OpenAI documente également séparément l'utilisation d'un cookie propriétaire __oppref pour stocker la référence de clic oppref et la réutiliser lors des consultations de pages ultérieures.

Par conséquent, si votre implémentation repose uniquement sur oaiq("consent", false), il est conseillé de tester le comportement réel du navigateur avant le consentement plutôt que de supposer que l'indicateur de consentement empêche toute forme de stockage ou de communication.

La correspondance avancée automatique est également activée par défaut

Le pixel OpenAI prend également en charge la correspondance avancée. Celle-ci permet de hacher des identifiants tels que l'adresse e-mail, le numéro de téléphone, le nom et l'identifiant externe, puis de les envoyer avec les événements de conversion. Cela améliore la capacité d'OpenAI à associer les conversions lorsqu'un identifiant de clic est indisponible.

Vous pouvez fournir ces valeurs explicitement via un objet utilisateur. OpenAI propose également une correspondance avancée automatique, activée par défaut pour les pixels Web nouvellement créés.

Lorsqu'elle est activée, la correspondance avancée automatique permet d'identifier les informations client prises en charge disponibles sur votre site, de les normaliser, de les hacher à l'aide de SHA-256 dans le navigateur et d'envoyer le hachage résultant avec les événements de conversion. Aucune implémentation supplémentaire n'est requise.

OpenAI indique que les informations client sous-jacentes ne sont pas transmises en clair. Cette approche est nettement préférable à l'envoi d'identifiants bruts.

Cependant, elle ne rend pas les données résultantes anonymes au sens du RGPD. Le hachage est généralement une forme de pseudonymisation plutôt que d'anonymisation. Le hachage SHA-256 d'une adresse e-mail est déterministe : une même adresse e-mail produit systématiquement le même hachage. Une partie possédant déjà l'adresse e-mail peut la hacher indépendamment et comparer le résultat.

Cette capacité de correspondance est l'objectif principal de cette fonctionnalité.

Le considérant 26 du RGPD précise que les informations pseudonymisées peuvent rester des données à caractère personnel si elles peuvent encore être attribuées à une personne identifiable grâce à des informations complémentaires.

Les organisations doivent donc considérer la correspondance avancée automatique comme une décision délibérée en matière de protection de la vie privée. Une fonctionnalité qui collecte des informations client sur votre site web et envoie des identifiants dérivés à une plateforme publicitaire doit reposer sur une base légale appropriée et ne doit pas être acceptée simplement parce qu'elle est activée par défaut.