La méthode ultime pour définir un plan de taggage

Êtes-vous absolument certain.e de bien connaître vos utilisateurs et leurs comportements ?

D’identifier les fonctionnalités qui leur plaisent ou leur déplaisent ? De comprendre pourquoi ils abandonnent leur panier ? Ou comment les convertir en utilisateurs payants ?

Il est vrai que par défaut, les outils de tracking vous permettent d’accéder à un grand nombre d’informations. Néanmoins, celles-ci ne sont souvent pas spécifiques à votre activité.

À vous de jouer en créant en plan de taggage précis et adapté à vos besoins business ! C’est également l’occasion pour votre entreprise de se poser les bonnes questions sur le parcours utilisateur.

A la fin de l’article, on vous offre même un template de plan de taggage prêt à l’emploi !

Précision : dans cet article, nous parlons de plan de tracking, de plan de taggage et plus rarement de plan de marquage. Tous ces termes sont équivalents.

‍

‍

1. Événements, propriétés et attributs : les ingrédients d’un bon plan de taggage

‍

1. 1 Le plan de tracking, un document de planification garant de la cohérence des données

Chaque entreprise doit être en mesure de comprendre et d’évaluer la qualité de son parcours utilisateur, que ce soit sur le site web ou sur le produit.

Pour cela, elle collecte des données, ou événements, en fonction du comportement des utilisateurs, que l’on recense dans un document, généralement un Google Sheets.

C’est ce qu’on appelle un plan de taggage.

Le fait de lister dans ce document tous les événements et leur définition dans ce document permet d’assurer un niveau équitable de compréhension et d’analyse des données.

Il se positionne donc comme source de vérité et outil de collaboration pour toutes les personnes impliquées dans le parcours utilisateur : les équipes tech, produit, marketing, service client…

Généralement, ce document ressemble à ça :

Si on prend l’exemple de la métrique phare de tout marchand e-commerce : le taux de conversion. Le calcul est plutôt simple : il s’agit du ratio du nombre d’achats divisé par le nombre de visites. Pour mesurer le taux de conversion, nous devons donc collecter deux types d’actions ici : les achats d’une part, les visites d’autre part.

Et voilà, nous venons de définir deux premiers événements incontournables qu’il s’agit maintenant de traquer, qui vont constituer deux lignes du plan de taggage ! Facile non ?

Continuons !

‍

1.2 L’événement signale l’action d’un utilisateur

Les événements sont en fait des signaux qui rendent compte d’une action menée par un utilisateur sur une plateforme. On remarque trois types d’événements :

• Page vue : lorsqu’un utilisateur se rend sur une page d’un site ou sur un écran de l’application
• Clic : lorsqu’un utilisateur clique sur un bouton
• Action ou conversion : lorsqu’un utilisateur réalise une action (création de compte, installation d’app…) ou de conversion (achat, abonnement, lecture de vidéo, …)

Par exemple, vous venez de vous inscrire sur fnac.com. Quelques secondes plus tard, vous recevez un e-mail de bienvenue.

Au terme de l’inscription, un événement probablement appelé “sign up” a été déclenché sur le site. Votre adresse e-mail, précisée dans le formulaire d’inscription, a ensuite été envoyée vers l’outil de CRM, ce qui a déclenché l’envoi d’un e-mail de bienvenue.

‍

1.3 La propriété d’événement précise l’événement en question

Une propriété est un sous-élément de l’événement qui l’enrichit en apportant des informations complémentaires ou du contexte sur l’action prise par l’utilisateur.

Il existe deux types de propriétés d’événements :

• standard : présentes pour tous les événements (user_id, timestamp…)
• custom : présentes pour certains événements (prix d’un produit, titre d’une musique jouée sur un service de streaming audio)

Par exemple, imaginons un événement correspondant à un achat sur fnac.com. Voici la configuration qui pourrait être mise en place

• Event Name : purchase
• Standard Event Properties :
• date : date à laquelle l’événement est enregistré
• customer_id : identifiant unique de l’utilisateur interne au site
• platform : plateforme depuis laquelle l’action a été réalisée
• Custom Event Properties :
• purchase_id : identifiant unique de l’achat interne au site
• total_amount : montant réglé par l’utilisateur lors de son achat
• nb_items : nombre total de produits achetés
• payment_method : mode de paiement utilisé par l’acheteur

‍

1.4 L’attribut utilisateur apporte de l’information sur cet utilisateur

L’attribut utilisateur permet d’approfondir les analyses en recourant aux données :

• sociodémographiques : âge, genre, pays d’origine, pays de résidence, catégorie socioprofessionnelle, etc.
• de contact : identifiant, adresse e-mail, numéro de téléphone mais attention de bien respecter les règles sur l’utilisation de ces données !
• quant aux appareils utilisés : plateforme, type d’appareil, version du système d’exploitation, version du site ou de l’app, etc.
• liées au statut de l’utilisateur sur la plateforme : date d’inscription, date de validation du profil, statut de souscription (pensez à un utilisateur de Spotify qui peut être gratuit ou premium), etc.
• relatives au comportement de l’utilisateur sur la plateforme : nombre de transactions réalisées sur un site e-commerce par exemple

Attention, les attributs utilisateurs ne se collectent pas nécessairement au moment d’un événement puisqu’ils n’en dépendent pas toujours.

Pour conclure cette première partie sur les définitions, considérons que je clique sur le bouton “À regarder plus tard” sur une vidéo Youtube. Voici à quoi ressembleraient l’événement, les propriétés et les attributs :

• Événement de clic sur “À regarder plus tard”
• Ajoute l’événement à la base de données
• Déclenche l’ajout de la vidéo dans la liste “À regarder plus tard”
• Propriétés :
• user_id
• vidéo : “Les origines des chiens”
• appareil : Mac
• timestamp : 1644681198
• Attribut utilisateur :
• Classe d’âge : 30+
• Segment : utilisateur fréquent

‍

2. Du besoin business à l’intégration : comment mettre en place un plan de taggage ?

‍

2.1 Le tracking : côté client et côté serveur

On différencie deux types de tracking :

• Le tracking client qui collecte des données via des balises, comme celles de Google Tag Manager ou de Segment. Il est plus facile à mettre en place mais moins précis.
• Le tracking serveur qui collecte des données via une communication avec le serveur web. S’il permet de récupérer des données plus détaillées, il est aussi plus complexe à mettre en place.

Si la finalité du tracking est la même, à savoir distribuer des données vers des outils tiers, la façon de mettre en place le tracking et les données envoyées diffèrent.

Par exemple, sur Whatsapp, les deux types de trackings peuvent coexister :

• Serveur : vous appuyez sur l’icône d’appel, un événement est enregistré dès lors que l’infrastructure réseau connecte les 2 numéros.
• Client : vous appuyez sur l’icône d’appel, un événement est enregistré suite à votre clic.

‍

2.1.1 Le tracking côté client

Dans le cadre du tracking côté client, la distribution de données s’effectue grâce à des balises. Il s’agit de l’un des moyens les plus fréquents de transmettre des données depuis des pages Web.

Ce type de tracking permet notamment de collecter des informations sur le “contexte” des utilisateurs. Cela donne un accès direct aux données spécifiques à l’utilisateur, comme l’appareil, les cookies, les paramètres URL, le référent et l’adresse IP.

Le recueil et l’analyse des données vous permettent d’utiliser ces informations pour personnaliser vos messages par exemple lors d’un ciblage publicitaire ou un message par région via l’IP. Les URL permettent, quant à elles, d’analyser les campagnes de marketing et l’engagement des clients.

Les outils de tracking côté client sont généralement assez faciles à utiliser. Ils ne nécessitent pas de compétences techniques particulières sauf si vous voulez intégrer des variables complexes ou si vous travaillez sur une app.

‍

2.1.2 Le tracking côté serveur

On parle de tracking côté serveur, ou server-side dès lors que la distribution des données se fait par une balise ou un pixel envoyant les données au serveur Web, d’où elles sont transmises à des outils d’analytics ou de marketing.

Concrètement, les données côté serveur correspondent à des données de fonctionnement de votre produit. La distribution des données est ici un objectif secondaire.

Étant critique pour l’entreprise de s’assurer du fonctionnement du produit, les données en découlant seront précises et fiables. Le moindre problème sera immédiatement remonté à l’équipe produit qui devra régler le problème.

‍

2.1.2 Lequel choisir ?

Les deux types de tracking peuvent généralement être utilisés.Néanmoins :

• Un événement ne faisant pas appel au serveur ne pourra pas être remonté via un tracking server-side, comme le remplissage de certains champs dans un formulaire avant abandon de la page.
• Certaines informations sont par nature présentes en tracking client comme l’UTM, l’IP, les appareils, etc.
• Le tracking client peut être bloqué, par des ad-blockers notamment.
• Si la donnée recueillie est nécessaire à d’autres services de votre entreprise, il vaut mieux opter pour la précision et choisir un tracking server-side. Par exemple, lorsqu’un utilisateur est inscrit à un site de comparateur de prêts immobiliers, mieux vaut avoir une donnée précise pour l’appeler avec tenant un discours personnalisé.

Le tracking server-side est plus robuste mais aussi moins flexible. Il prend généralement plus de temps à être mis en place puisqu’il aura des implications sur d’autres équipes, particulièrement les développeurs.

Vous avez probablement ici envie d’ouvrir un Google Sheets et de vous lancer dans la liste de vos événements à collecter. Patientez encore un peu !

Pour que votre plan de taggage soit efficace, il faut assurer une sélection des événements à traquer pour deux raisons :

• Si le tracking est trop complexe, il faudra multiplier les mises en place et par conséquent la maintenance.
• Si les points de données se multiplient, cela ajoute en quelque sorte du bruit dans les données et rend les analyses beaucoup plus compliquées. En effet, certains chiffres peuvent tendre à indiquer une tendance alors que d’autres pourraient laisser supposer l’inverse.

Il faut donc bien suivre les étapes du schéma ci-dessous pour assurer la cohérence du tracking et limiter les risques d’erreur.

Dans cet article, nous nous focalisons sur les deux premières étapes.

‍

2.2 Partir du besoin business et établir un KPI framework

Commençons par définir les KPIs à mesurer. Ces derniers permettront de définir les événements à mettre en place.

En effet, il est important que les indicateurs soient alignés avec la stratégie de l’entreprise et ses objectifs.

Ainsi, si l’objectif de l’entreprise est d’augmenter les ventes de 25% au prochain semestre, les indicateurs retenus doivent vous permettre d’identifier les facteurs de succès de votre stratégie.

Imaginons que vous deviez analyser l’évolution de vos ventes sur toute l’année.

• Ont-elles augmenté ou diminué sur la période ?
• Quelle évolution cela représente-t-il par rapport à l’an dernier ?
• Pouvez-vous accéder à une granularité plus fine telle que les ventes par produit ?

Les indicateurs doivent en fait servir de base à vos plans d’actions. Sinon, ils ne sont pas pertinents et vous perdez du temps à les suivre.

Si l’on reprend l’exemple juste au-dessus : vous constatez que vos ventes ont augmenté de seulement 15%. Vos données vous permettent de comprendre l’écart avec vos objectifs : les indicateurs choisis révéleront des actions à continuer ou à arrêter pour accentuer la hausse des ventes.

Ces indicateurs sont ensuite intégrés dans un KPI framework. Il s’agit en fait d’un plan de mesure, qui englobe les KPIs à suivre en fonction de votre besoin business. Il vous permet d’éviter les écueils énoncés précédemment et de vous concentrer sur l’essentiel du tracking.

C’est donc sur cette base que s’appuie le plan de taggage. Ce type de document se décompose en 3 parties :

1. Les objectifs business
2. Les KPIs
3. Les événements à traquer

En voilà un exemple :

En complétant ce type de fichier – utilisé par exemple chez Aircall, vous arrivez naturellement à définir les KPIs et donc les événements à traquer.

Il est fréquent d’appuyer ce KPI framework sur d’autres frameworks de métriques, à l’image du funnel AARRR dont nous vous parlons dans cet article.

‍

2.3 Traduire le KPI framework en plan de tracking

• Outils : check !
• KPIS : check !
• Événements : check !

Ça y est, vous voilà enfin à l’étape du plan de taggage.

Afin d’intégrer ces événements, il convient désormais de définir leurs spécifications.Le plan de tracking doit préciser:

• le nom de l’événement
• ce qu’il fait
• les propriétés qu’il doit spécifiquement prendre en compte
• les types de réponses attendus

Dans la pratique, la création du KPI framework est immédiatement suivie de la création du tracking plan. En effet, il peut y avoir des allers-retours entre ces documents, notamment quant à la granularité des informations à récupérer.

‍

3. Téléchargez votre modèle de plan de tracking !

On vous a préparé un template prêt à l’emploi et complètement gratuit !

Vous pourrez le retrouver ici !

Vous avez maintenant complété votre plan de taggage ! Celui-ci servira de base à l’intégration de vos balises et de vos tags.

Pour découvrir comment réaliser ces intégrations avec l’aide de Google Tag Manager, inscrivez-vous à la formation Emil Tracking & Product Analytics.

‍