OneTag
Si la donnée transite par les servers Commanders Act, est-ce que ça signifie que vous la stockez ?
La donnée ne demeure sur nos servers que le temps d'être formaté et processée pour renvoie vers vos partenaires.
Qu'est-ce que je dois faire pour faire avoir un tel fonctionnement ?
Un OneTag par event
Il faut poser un OneTag par évènement à tracker (les templates de tag sont dans la librairie TagCo).
On y mappera les variables requises pour les partenaires sans avoir à se préoccuper des différences entre les partenaires.
Un Base Tag et un conecteur par partenaire
Pour chaque partenaire on ajoutera sa libraire dans un tag web et un connecteur par partenaire (FB, GA, AT, etc.)
Les connecteurs consistent en de simples champs à remplir avec l'id partenaires, un token, l'id de catégorie de privacy du partenaire.
Un déploiement et c'est prêt :)
Mais... pour la privacy, si les OneTag remonte de la donnée pour des partenaires de catégories de privacy distinctes, comment je catégorise mes OneTag ?
Les OneTag ont un rôle technique et fonctionnel de collecte du consentement de l'utilisateur et de vecteur de la donnée.
C'est au niveau du connecteur (côté server) que l'id de catégorie du partenaire va être comparé au consentement collecté par le OneTag afin de permettre ou d'empêcher l'envoie de la donnée vers le partenaire.
Les OneTag peuvent donc être rangés dans la catégorie fonctionnelle ou technique de votre CMP.
Comment les OneTag récupèrent ils le consentement de l'utilisateur ? Je ne vois rien dans ces tags qui semble jouer ce rôle
Avec TRUST Commander, vous n'avez rien à faire ! Le code du container récupère automatiquement les id de catégories consenties par l'utilisateur et l'injecte directement dans les events OneTag.
Si vous n'avez pas TRUST ce n'est pas un problème ! Il suffira d'ajouter une propriété à vos events qui récuperera les id consentie de votre CMP.
Est-ce qu'il faut faut savoir coder pour poser les OneTag ? Si je ne sais pas coder, je fais comment ?
Par défaut vous n'avez rien à coder !
Les OneTag sont pré-templatés dans la libraire TagCommander.
Vous n'aurez qu'à mapper vos tags (cad sélectionner des variables dans des menus déroulant) et renseigner des id sur les connecteurs partenaire.
Certaines customisations peuvent cependant nécessiter quelques ajustements du code. En général c'est assez simple à mettre ne place.
Et si je dois customiser mes OneTag ? Quelles customisations je peux ou doit faire ? Est-ce que c'est complexe à customiser ?
Les OneTag sont templatés pour les envois d'évènements standard (page vue, ajout panier, achat, etc.).
Des customisations sont cependant possible :
- nom d'event custom
- nom de variables custom
- filtre d'event custom
- id de consentmeent custom
Ces customisations ne demandent qu'un simple ajout de proriétés aux OneTag, c’est-à-dire à une courte ligne de code.
Les indications relatives à ces customisations sont disponibles dans nos documentations.
Si j'ai déjà des events partenaires en Clientside est-ce qu'ils ne vont pas faire doublons avec les OneTag ?
L'envoie d'event en serverside permet de se passer de l'envoie en clientside.
Si toutefois vous souhaitez conserver les deux setup ça n'est pas un problème. Dans un tel cas les events seront dédupliqués côté partenaire et l'event server sera même suceptible d'apporter un incrément à la quantité d'event navigateur reçus.
Afin que les events server et navigateurs soient dédupliqués il faudra alors qu'ils aient le même id d'écvènement.
C'est pour ça que lorsque les OneTag sont déclenchés, un id d'event va être généré automatiquement.
Une légère adaptation de vos event partenaires en Clientside devra être faite afin qu'ils récupèrent, dans une propriété, ce même id d'évènement. Pour ça une courte ligne de code suffit.
Qu'Est-ce que vous nous conseillez ? serverside only ? Clientside only ? Les deux ?
Plusieurs setup sont possible.
Server-Only : Vous n'envoyez vos events qu'en serverside.
Avantage --> Ce setup a l'avantage de minimiser les hits et les appels server.
Redundant Setup : Vous envoyez vos events en server side et en clientside. Cela necessite un id d'evènement commun aux event server et navigateurs. Les OneTag le permettent.
Avantage --> Les events server apporteront un incrément à la quantité d'event reçus.
Desavantage --> Ce setup est optimal mais plus onéreux.
Borwser-Only : C'est le setup classique. Pas besoin de OneTag.
Desavantage --> dans le sens pris vers un monde sans cookie ce type de setup risque d'être vite obsolète.
Comment pouvez vous garantir la protection des données personnelles avec les OneTag ?
Au-delà de récupérer automatiquement le consentement de l'utilisateur, les OneTag embarque dans chacun des events, à votre convenance, les user-properties disponibles dans votre datalayer.
Côté server CA, les user-properties sont automatiquement et sans exception, hashées en SHA256.
Est-ce qu'on peut utiliser les OneTag sur GTM ?
Oui !
Nous avons un template de OneTag pour GTM.
Ce template permet l'envoie d'évènements standards mais aussi l'envoie d'events customisés.
Si l'on souhaite se débrouiller seul pour poser les OneTag, est-ce possible ? Vous avez une doc ?
Tout est documenté pour que vous puissiez être autonome.
Voici à titre d'exemple la doc des events OneTag de reference
https://community.commandersact.com/platform-x/developers/tracking/events-reference
Comment puis-je être assuré de la qualité des remontées des events envoyés par les OneTag ?
La qualité des envois d'event se mesure suivant 3 critères :
- La quantité des events server comparés aux events navigateurs
- La deduplication des events
- Le gain de données embarquées dans les events (user-properties notament)
Pour cela nous recommandant un setup Serverside + Clientside pendant un laps de temps suffisant pour pouvoir compare les remontées d'events et évaluer cette qualité.
Dernière mise à jour
Comment ça marche les OneTag ?
Les OneTag sont posés sur les containers web de votre site. Ils envoient vos events avec toute la donnée requise vers nos servers d'où ils sont redirigés, en serverside et automatiquement, vers les partenaires de votre choix.