Agence, transparence et contrôle : problèmes non résolus avec le balisage côté serveur

J’ai été un fervent partisan du balisage côté serveur, en particulier de la solution de gestion des balises côté serveur de Google.

J’admire la façon dont il cherche à rééquilibrer l’équilibre contrôler qui a généralement été en faveur des fournisseurs de marketing dont Bibliothèques JavaScript ont été libres de faire des ravages dans le navigateur de l’utilisateur.

En insérant un amortir entre l’utilisateur et le fournisseur, le propriétaire de la configuration du balisage côté serveur peut prendre le contrôle sur les données que les fournisseurs de marketing peuvent réellement traiter de l’utilisateur.

Cependant, malgré tout le bien que cela apporte à une organisation, il reste encore des problèmes non résolus avec la technologie.

Malheureusement, ces problèmes ne sont pas des problèmes qu’une solution de gestion des balises côté serveur pourrait résoudre de manière isolée.

Dans cet article, j’explore ces problèmes dans le but d’inspirer la discussion et, espérons-le, de me concentrer davantage sur les fonctionnalités qui aideraient avec le tiercé gagnant de agence utilisatrice, transparence des flux de donnéeset contrôler sur ce qui est traité par le proxy côté serveur.

Agence : l’utilisateur doit avoir le dernier mot

TL;DR En créant des bloqueurs de publicités moins efficacebalisage côté serveur érode l’agence de l’utilisateur sur leur expérience de navigation !

Si vous êtes LARP comme une mouche dans le plafond dans n’importe quel argumentaire de vente ou de mise en œuvre autour du balisage côté serveur, vous entendrez bientôt ce que beaucoup considèrent comme l’argument le plus convaincant :

En s’exécutant derrière un nom de domaine personnalisé, le balisage côté serveur peut être utilisé pour éviter que les bloqueurs de publicités et de contenu n’interfèrent avec la collecte de données.

j’utiliserai le terme bloqueur de publicités pour regrouper tous les différents types de bloqueurs de publicités/de contenu/de confidentialité dans le reste de la copie de l’article.

C’est un résultat indéniable du remplacement des communications directes par des domaines de fournisseurs (par exemple facebook.com) avec un sous-domaine personnalisé de la propriété Web principale de l’entreprise (par exemple sgtm.mycompany.com).

De nombreux bloqueurs utilisent encore des heuristiques qui examinent principalement le URL qui reçoivent des requêtes réseau du navigateur de l’utilisateur. Si ces URL correspondent à des modèles dans leur listes de blocageles requêtes réseau sont refusées.

En s’éloignant de facebook.com pour sgtm.mycompany.com, une partie clé du modèle est masquée. Il est très peu probable qu’une liste noire ait mycompany.comalors qu’il est presque certain que les bloqueurs de publicités reconnaissent facebook.com.

Oui, de nombreux bloqueurs examinent également d’autres parties de la demande, telles que le chemin ou alors paramètres de requêtemais ceux-ci sont également assez faciles à obscurcir avec la technologie de marquage côté serveur.

Que vous le fassiez intentionnellement (vous voulez réellement empêcher les bloqueurs de publicités de faire leur travail) ou involontairement (vous voulez déplacer votre collecte de données vers la première partie et le blocage des bloqueurs de publicités n’est qu’un effet secondaire de cela), vous devez respecter les choix technologiques de l’utilisateur lors de la collecte de données d’ingénierie.

Vous avez aucun moyen de savoir pourquoi l’utilisateur utilise un bloqueur de publicités.

Ils pourraient l’utiliser parce que ils ne veulent pas être suivis.

Ils pourraient l’utiliser parce que ils ne veulent pas voir de publicités.

Ils pourraient l’utiliser parce que ils veulent que le Web soit plus rapide.

Ils pourraient l’utiliser sans savoir qu’ils l’utilisents’ils utilisent un navigateur tel que Brave doté d’une fonctionnalité intégrée de blocage des publicités.

Pourquoi est-ce un problème difficile à résoudre ?

L’un des principaux avantages du balisage côté serveur est consolidation des flux de données. Vous pouvez réduire les problèmes de performances côté client et atténuer les privilèges accordés aux bibliothèques JavaScript des fournisseurs en ne collectant qu’un seul flux de données depuis l’appareil de l’utilisateur vers le point de terminaison de balisage côté serveur.

Le serveur prend ensuite ce flux et le ventiler aux vendeurs de marketing. De cette façon un seul Google Analytics 4 stream, par exemple, peut également être utilisé pour collecter des données pour Facebook, pour Google Ads, pour Taboola, etc.

Alors maintenant, si l’utilisateur utilise une extension qui bloque Facebook mais pas Google Analytics, vous devez d’abord vérifier si l’utilisateur le navigateur bloquerait le flux Facebook, puis passer ces informations au serveur avec le hit GA4, puis dans le serveur assurez-vous que le flux Facebook est bloqué afin que le le choix de l’utilisateur est respecté.

C’est gênant.

Votre site peut également avoir un Politique de sécurité du contenu en place qui vous empêche de faire la demande fictive à facebook.com afin de vérifier s’il serait bloqué par une extension.

Quelles sont les solutions potentielles ?

• Les bloqueurs de publicités pourraient exposer de manière standardisée quels fournisseurs ou terminaux sont actuellement bloqués, calé, ou restreint d’une autre manière dans le navigateur. Le site Web pourrait lire ces informations, puis les utiliser pour concevoir les déclencheurs sur le serveur. Cependant, je ne suis pas sûr que les bloqueurs de publicités pouvez d’accord sur une norme comme celle-là, et je ne pense pas qu’ils soient même disposés à la poursuivre, car les mêmes informations pourraient être utilisées pour éviter encore plus efficacement l’heuristique du bloqueur de publicités.

• Le site Web pourrait effectuer une simple vérification (par exemple avec un mannequin ads.js fichier) si l’utilisateur utilise quelconque type de bloqueur de publicités, puis le site pourrait bloquer de manière proactive l’intégralité du flux de données vers le conteneur du serveur. Il s’agit bien sûr d’une mesure drastique, car la configuration du balisage côté serveur peut être utilisée pour de nombreuses choses qui ne sont absolument pas liées au suivi, aux publicités ou aux types de choses que les bloqueurs de publicités ciblent généralement.

• Identique à l’approche précédente mais au lieu de bloquer l’ensemble du flux, le site Web pourrait classer les flux qui sont typiquement bloqués par les bloqueurs de publicités et n’empêchent ceux-ci de s’activer que si l’utilisateur utilise un bloqueur de publicités. Ceci est problématique car il n’y a pas de classification standardisée de ce que les différents bloqueurs de publicités peuvent faire.

• La décision de bloquer de manière proactive les flux de données pourrait être liée à des mécanismes tels que le Global Privacy Control et la notion de « consentement » sous RGPD et la directive ePrivacy, par exemple. Mais cela est problématique car certaines des justifications de l’utilisation d’un bloqueur de publicités n’ont rien à voir avec données personnelles ou alors données d’utilisateur ou réglementation légale.

En cela, le plus vous pouvez être proactif, mieux c’est. S’il est possible de bloquer les flux qui seraient généralement ciblés par un bloqueur de publicités, fais ainsi. Vous atténuerez également vos risques de collecte de données que vous ne devriez pas être autorisé à collecter en premier lieu.

Transparence : la règle Vegas du balisage côté serveur

TL;DR Le déplacement des flux de données côté serveur rend plus difficile de valider si les données sont collectées et traitées légalement et selon les souhaits et les choix de l’utilisateur.

Les Règle de Vegas du balisage côté serveur se déroule comme suit :

Que se passe-t-il sur le serveur, séjours dans le serveur.

Il s’agit d’une pierre angulaire de la architecture client-serveur d’Internet. Il n’y a aucune obligation pour l’un de révéler quoi que ce soit à l’autre au-delà de ce qui est envoyé dans les demandes et les réponses qui circulent entre les deux.

Cela pose également un problème majeur pour le remplacement balisage côté client avec balisage côté serveur (jusqu’à un certain point).

L’un des avantages de conserver les flux de données dans le navigateur (ou l’appareil de l’utilisateur) est qu’ils peuvent être surveillé et vérifié en place.

Non, la plupart des internautes n’ont pas les compétences ou les outils nécessaires pour effectuer ce type d’audit, mais il existe de nombreuses organisations et d’innombrables personnes qui effectuent ce travail au nom de l’internaute « type ».

Par exemple, si un site Web demande le consentement de l’utilisateur pour accéder aux informations stockées sur l’appareil (sous les auspices de la Directive ePrivacypar exemple), il est assez facile de surveiller les flux de données dans le navigateur pour voir s’ils utilisent le stockage de l’appareil.

Si cette logique est déplacée vers le serveur, cette transparence est perdue.

Ceci n’est pas un nouveau problème! Chaque fois que le traitement des données se produit en dehors du navigateur, comme dans le CRM de l’entreprise ou dans le service d’un fournisseur, l’utilisateur ne peut que confiance (ou espèrent) que leurs choix et leurs droits sont respectés.

Mais comme le but du balisage côté serveur est de déplacer les flux de données du côté client vers le côté serveur, ce problème est magnifié au-delà de tout ce que nous avons vu auparavant.

Pourquoi est-ce un problème difficile à résoudre ?

Le principal défi ici est qu’il y a pas de mécanisme existant pour révéler les machinations côté serveur dans l’appareil de l’utilisateur. Il n’y a pas d’outil d’audit que l’utilisateur peut lancer dans le navigateur Web, par exemple, qui montrerait ce qu’il advient des flux de données une fois qu’ils quittent l’appareil de l’utilisateur.

Et même s’il y avait un outil comme ça, le serveur peut choisir librement quelles informations divulguer jusqu’à l’origine de la demande. Il n’y a donc aucun moyen de croire que les informations reflètent fidèlement ce qui s’est passé sur le serveur, et la société qui gère le serveur peut avoir de bonnes raisons de masquer certaines informations, en particulier si elles concernent des données commerciales sensibles.

Quelles sont les solutions potentielles ?

• Le fournisseur de balisage côté serveur (Google, par exemple) pourrait intégrer à l’application un mécanisme qui rapporte à l’origine de la requête (dans la réponse HTTP) ce qui s’est passé dans l’environnement du serveur. Un outil comme Tag Assistant pourrait alors le lire et le signaler à l’utilisateur. Le principal problème de cette approche est l’augmentation sortie réseau les coûts, car la taille de la réponse HTTP augmente avec ces nouvelles métadonnées. De plus, cela nécessite que l’utilisateur (ou la personne effectuant l’audit) installe une extension de navigateur et faire confiance aux données qu’il révèle.

• L’entreprise qui gère le conteneur de serveur doit clairement documenter les types de flux de données qui ont lieu sur le site Web et dans le serveur. Cependant, l’utilisateur n’a aucune raison de croire que ce document est exact, constamment mis à jour ou qu’il reflète le statu quo en tenant compte des intérêts de l’utilisateur.

• L’application de balisage côté serveur pourrait activer une “vue d’audit” accessible au public que les utilisateurs avertis pourraient charger afin de voir ce qui se passe dans le conteneur du serveur. Cependant, cela pourrait entraîner des problèmes lorsque l’entreprise souhaite masquer certaines de ces informations car elles sont critiques pour l’entreprise ou autrement sensibles. Cela entraînerait également une augmentation des coûts pour l’entreprise, car le service Web destiné au public devrait être maintenu et pris en charge par l’environnement du serveur.

Pour l’instant, la meilleure approche consiste à être aussi proactif que possible dans la description des flux de données qui se produisent dans le serveur. Il est également très important de comprendre que ce n’est pas parce que quelque chose ne peut pas être audité qu’il est hors de portée de conformité légale.

Dans l’Union européenne, par exemple, vous avez l’obligation légale de respecter le droit à la vie privée des personnes concernées de l’UE, et le transfert de vos flux de données vers le serveur ne vous en dispense pas.

La transparence est un trait proactif lorsqu’il s’agit de flux de données côté serveur. Tu devrais y aller hors de ton chemin pour que vos visiteurs et clients se sentent (et savoir) leur droit de contrôler leurs données personnelles est respecté.

Contrôle : Il n’y a pas de “trop ​​de granularité”

Quand cela vient à contrôlerl’entreprise qui gère l’environnement de balisage côté serveur doit avoir Achevée et le total dire ce qui se passe dans l’environnement du serveur.

C’est le seul façon qu’ils peuvent vraiment respecter l’utilisateur agence et le besoin de plus transparence.

Ainsi, la notion de contrôler l’emporte sur tous les autres aspects du balisage côté serveur. Si le contrôle est compromis, l’ensemble raison d’être du balisage côté serveur s’effondre.

C’est quelque chose que la solution de gestion des balises côté serveur de Google ne fait pas fournissent actuellement à un degré satisfaisant.

Par exemple, les modèles intégrés dans le conteneur (le Google Analytics 4 modèle, pour un), sont ne pas open source et ne peuvent pas non plus être ouverts dans l’éditeur de modèles personnalisés.

Cela signifie que même si vous contrôlez le flux de données depuis le client au serveurvous n’avez pas la capacité de contrôler ou de valider ce qu’il advient de ces données avant qu’elles ne soient envoyées aux fournisseurs.

De même, vous pourriez avoir besoin de contrôler la façon dont la demande réseau entrante est analysée dans un « objet de données d’événement » que les balises peuvent digérer. Malheureusement, il n’y a aucun moyen d’interjecter du code dans le processus où le conteneur du serveur analyse une requête entrante et le traite pour les balises.

La plupart contrôles ad hoc que vous avez lors de l’exécution d’une instance GTM côté serveur ne sont pas assez granulaires.

Par exemple, vous pouvez configurer une stratégie qui détermine les API que les modèles du conteneur de serveur peuvent utiliser (peuvent-ils, par exemple, définir des cookies ou envoyer des requêtes HTTP). Mais vous ne pouvez pas le faire étiquette par étiquette sans modification des modèles.

Alors même si je fête contrôler en tant que cadeau ultime de la mise en place d’un environnement de balisage côté serveur, une grande partie de ce contrôle est encore une illusion.

Pourquoi est-ce un problème difficile à résoudre ?

En fait, je ne pense pas que ce soit un problème difficile à résoudre, et j’espère en toute confiance que Google travaillera à l’améliorer dans un avenir (proche).

Contrôler dans un environnement de balisage côté serveur, c’est un gâteau qui est partagé avec de nombreux participants affamés.

• Google car le fournisseur de services contrôle le fonctionnement du service.

• La société qui gère le serveur a le contrôle sur la façon dont les flux de données sont configurés.

• L’utilisateur dont les données sont collectées a (ou devrait avoir) le contrôle sur les données qui lui appartiennent et qui sont traitées.

• Fournisseurs de technologies marketing prennent le contrôle lorsqu’ils créent des modèles et des points de terminaison côté serveur pour la collecte de données.

En fin de compte, la société qui gère le serveur devrait avoir le dernier mot sur la manière dont ce contrôle est distribué.

Quelles sont les solutions potentielles

Si nous convenons que le contrôle de l’environnement côté serveur doit être régi par la société qui gère/possède le serveur, nous arrivons aux conséquences suivantes :

• Google doit fournir un service doté de suffisamment de bascules granulaires pour contrôler tous aspects du flux de données. Ça signifie bonne gestion des demandes, gestion des données événementielles, contrôles d’autorisation balise par balise, API de consentement, contrôle d’accès au stockageet ainsi de suite.

• Fournisseurs de technologies marketing besoin de créer des modèles qui ne nécessitent pas de collecte de données au-delà du minimum absolu requis pour exécuter un service. De nombreuses entreprises demandent des produits très sensibles et collants données personnelles (telles que les adresses e-mail) à livrer via des appels de serveur à serveur. C’est très risqué et les fournisseurs de marketing doivent chercher de manière proactive à minimiser ce type de collecte de données.

• Administrateurs de conteneur de serveur besoin d’apprendre comment la solution de gestion des balises elle-même fonctionne et comment l’environnement Cloud qui héberge le service est configuré. Ce dernier est particulièrement poignant – le balisage côté serveur est, pour beaucoup, le premier point de contact avec un service Cloud évolutif. Cela s’accompagne d’une énorme courbe d’apprentissage que de nombreux administrateurs ne sont pas prêts à affronter.

• Internautes réguliers ont besoin d’une formation sur ces types de technologies afin qu’ils puissent mieux se préparer à gérer les données collectées à partir de leurs navigateurs et appareils. C’est bien sûr un défi de taille, et il devrait jamais être la responsabilité de l’utilisateur d’apprendre quelque chose en tant que mesure de prévention. Si tel est le résultat, la collecte de données doit être strictement opt-in.

Le mot contrôler n’a pas de connotations positives ou négatives par défaut. Le balisage côté serveur concerne contrôlermais c’est la compréhension mutuelle entre les parties énumérées ci-dessus si ce contrôle est utilisé pour le bien ou pour le mal.

Résumé

La technologie de marquage côté serveur me frustre sans fin.

D’une part, je suis incroyablement enthousiasmé par ses perspectives. Il délivre tant d’avantages aux organisations qui souhaitent mieux prendre soin de leurs utilisateurs, de leurs flux de données et de leurs relations avec leurs fournisseurs marketing.

D’autre part, il est paralysé par le limites de l’environnement en ligne dans lequel il fonctionne. architecture client-serveur d’Internet est résilient aux exigences (ou attentes) modernes de transparence. La poussée pour collecte de données de première partie (ce qui peut être considéré comme une chose nette positive) signifie que les contrôles traditionnels des utilisateurs pour la gestion des flux de données (par exemple, les bloqueurs de publicités) sont moins efficaces.

Je ne sais pas si d’autres partagent ces points de vue, mais à mon avis, les suggestions que je propose dans cet article devraient aboutir à un environnement universellement meilleur pour toutes les parties concernées.

Pour ceux qui veulent ne fais pas de malsoutenant agence utilisatriceen choisissant transparence sur l’opacité, et l’augmentation granularité du contrôle devraient être des priorités lors du développement de l’environnement en ligne vers un statu quo plus sain.