Il existe plusieurs raisons impérieuses de considérer le déplacement des balises des fournisseurs côté client des navigateurs et des périphériques vers un serveur. Dans cet article, nous examinons comment évaluer une balise fournisseur côté client pour la déplacer potentiellement vers une propriété de transfert d’événement.
Cette évaluation n’est nécessaire que si vous envisagez de supprimer une balise du fournisseur côté client et de la remplacer par la distribution de données côté serveur dans une propriété de transfert d’événement. Cet article suppose que vous connaissez les principes de base de collecte de données, et transfert d’événement.
Adobe Experience Platform Launch est désormais une suite de technologies destinées à la collecte de données dans Adobe Experience Platform. Plusieurs modifications terminologiques ont par conséquent été apportées à la documentation du produit. Reportez-vous au document suivant pour consulter une référence consolidée des modifications terminologiques.
Les fournisseurs de navigateurs modifient leur manière de traiter les cookies tiers. Les fournisseurs et technologies publicitaires et marketing nécessitent souvent l’utilisation de nombreuses balises côté client. Ces défis ne sont que deux raisons évidentes pour lesquelles nos clients ajoutent de la distribution de données côté serveur.
Tag
dans cet article signifie code côté client, généralement du code JavaScript provenant d’un fournisseur qui est utilisé pour la collecte de données dans le navigateur ou le périphérique lorsqu’un visiteur interagit avec le site ou l’application. Website
ou site
ici fait référence à un site web, à une application web ou à une application pour un appareil mobile. Une "balise" à ces fins est également souvent appelée pixel.
La première étape consiste à définir les cas d’utilisation implémentés avec la balise du fournisseur côté client. Prenons l’exemple du pixel Facebook (Meta). Le déplacer de notre site vers le API des conversions de métadonnées avec l’extension de transfert d’événement , vous devez d’abord documenter les cas d’utilisation spécifiques.
Pour le code du fournisseur côté client actuel :
Il est utile de créer une liste, une feuille de calcul, un diagramme ou tout autre enregistrement des données et de la séquence d’événements pour documenter cette évaluation, même si elle est réservée à votre propre usage. Veillez à inclure des étiquettes pour les sources de données, d’où provient-elle ? Destinations : où cela nous mène-t-il ? Et les transformations : qu’en est-il entre la source et la destination ?
Dans notre exemple, nous effectuons le suivi des conversions avec le pixel Facebook lorsque les visiteurs interagissent avec notre site après avoir affiché une publicité Facebook. Ils peuvent également interagir avec notre site après avoir affiché des publicités associées sur une autre plateforme sociale. Pour afficher ces conversions dans les outils publicitaires et les rapports Facebook, les données requises doivent être envoyées à Facebook. Ces données peuvent inclure des événements de conversion tels que des téléchargements, des inscriptions, des mentions J’aime ou des achats.
Avec la balise côté client existante, que se passe-t-il avec les données de notre cas d’utilisation lorsqu’elle s’exécute ou s’exécute sur notre site ? Pouvons-nous capturer les données dont nous avons besoin dans le client, sans la balise du fournisseur, afin de pouvoir les envoyer au transfert d’événement ? Lorsque vous utilisez tags Pour d’autres systèmes de gestion des balises, la plupart des données d’interaction des visiteurs sont disponibles pour la collecte et la distribution. Mais les données dont nous avons besoin pour notre cas d’utilisation sont-elles disponibles lorsque nous en avons besoin, là où nous en avons besoin, et dans le format dont nous en avons besoin, sans la balise du fournisseur côté client ? Voici quelques autres questions relatives aux données à prendre en compte :
La plupart des balises du fournisseur côté client ne nécessitent pas de nombreux points de données pour un cas d’utilisation particulier, mais il est utile de noter les cas d’utilisation et les données requises lors de ces évaluations.
Nous connaissons maintenant les cas d’utilisation spécifiques à mettre en oeuvre, les données requises et la séquence d’événements de la source à la destination. Pour déterminer si le cas d’utilisation est adapté au transfert d’événement, nous pouvons désormais examiner les détails de l’API du fournisseur.
Bien que de nombreux fournisseurs activent des API pour le transfert serveur à serveur, il existe également de nombreux fournisseurs qui ne disposent actuellement pas d’API adaptées à ces fins.
Voici quelques étapes que nous pouvons suivre pour examiner les points de terminaison de l’API du fournisseur.
Le fournisseur dispose-t-il d’API conçues pour le transfert serveur à serveur des données d’événement ? Tout d’abord, recherchez les exigences relatives à ces points de terminaison d’API spécifiques :
En d’autres termes :
La balise est probablement un bon candidat pour passer du client à nos serveurs dans une propriété de transfert d’événement si nous pouvons répondre oui à ces questions.
Si le fournisseur ne dispose pas des points de terminaison d’API pour prendre en charge nos cas d’utilisation, alors, de toute évidence, cette balise de fournisseur n’est pas un bon choix pour utiliser le transfert d’événement à la place de la balise de fournisseur côté client.
Que se passe-t-il s’ils disposent d’API, mais nécessitent également un identifiant visiteur ou utilisateur unique avec chaque appel API ? Comment accéder à cet ID si le code (balise) côté client du fournisseur n’est pas en cours d’exécution sur le site ?
Certains fournisseurs changent leurs systèmes pour le nouveau monde sans cookies tiers. Ces modifications incluent l’utilisation d’autres identifiants uniques, comme une UUID ou autre ID généré par le client. Si le fournisseur autorise un ID généré par le client, nous pouvons l’envoyer du client au réseau Platform Edge avec le SDK Web ou mobile, ou peut-être l’obtenir à partir d’un appel API dans le transfert d’événement. Lorsque nous envoyons des données à ce fournisseur dans une règle de transfert d’événement, nous incluons simplement cet identifiant si nécessaire.
Si le fournisseur nécessite des données (comme un identifiant unique spécifique au fournisseur, par exemple) qui ne peuvent être générées ou accessibles que par sa propre balise côté client, alors cette balise du fournisseur n’est probablement pas un bon candidat pour le déplacement. Il est déconseillé d’essayer de rétroconcevoir une balise côté client avec l’idée de déplacer cette collecte de données vers le transfert d’événement sans les API appropriées.
La variable Connecteur Adobe Experience Platform Cloud L’extension peut effectuer des requêtes HTTP selon les besoins avec des fournisseurs disposant des API appropriées pour le transfert de données d’événement serveur à serveur. Bien que les extensions spécifiques à un fournisseur soient intéressantes et que d’autres extensions soient actuellement en cours de développement, nous pouvons aujourd’hui mettre en oeuvre des règles de transfert d’événement à l’aide de l’extension Cloud Connector, sans attendre d’autres extensions de fournisseur.
L’investigation et le test des points de terminaison de l’API du fournisseur est plus facile avec des outils tels que Postman, ou des extensions d’éditeur de texte telles que Visual Studio Code Tourner le client, ou Client HTTP.
Cet article fournit une séquence d’étapes permettant d’évaluer une balise côté client du fournisseur et de la déplacer potentiellement côté serveur dans une propriété de transfert d’événement. Pour plus d’informations sur les sujets connexes, voir les liens suivants :