Ensemble des articles pour le mot clé Plan de taggage
nov
13

Tracking ecommerce Google Analytics avec Google Tag Manager et son dataLayer

Google a enfin sorti son outil de Tag management. Tout le monde est au courant. J’en ai donc profité pour faire quelques petits tests et je me suis rendu compte que peu de ressources étaient disponibles aujourd’hui concernant le tracking ecommerce et donc le tag transactionnel avec cet outil.

Avant de lire ce que je vais exposer rapidement, et surtout si vous ne savez pas ce qu’est Tag Manager, je vous invite à regarder cette petite vidéo d’introduction.

Depuis peu, lors de la configuration d’une balise de type Google Analytics, vous pouvez définir un type de suivi « Transaction ». Ce type de suivi correspond au tag ecommerce de Google analytics.

Durant mes recherches, je n’ai pas trouvé de code me permettant d’utiliser ce type de balise en utilisant le dataLayer (ou couche de donnée en français) de Google Tag Manager. J’ai trouvé beaucoup de ressources qui exposaient l’utilisation d’astuces et surtout de balises custom HTML. Or Google fournit tous les outils permettant l’utilisation du dataLayer pour gérer dynamiquement ce type de tracking.

Deux liens indispensables à la compréhension du code :

Une fois votre balise de type Google Analytics avec type de suivi « transaction » créée, vous pouvez définir une règle de déclenchement à lui appliquer afin qu’elle ne parte que sur la dernière page de votre tunnel d’achat. Prenons comme exemple la page /merci.php, voici la règle à définir :

Après avoir configuré tout cela, il ne vous suffira plus qu’à mettre le script suivant juste avant le script de votre conteneur. Ce code est un exemple à dynamiser à l’aide de vos chers collègues développeurs.

<script>
    dataLayer = [{
      'transactionId': '1234',
      'transactionDate': '13112012',
      'transactionType': 'Type 1',
      'transactionAffiliation': 'ACME Clothing',
      'transactionTotal': 25.60,
      'transactionShipping': 5.00,
      'transactionTax': 1.00,
      'transactionPaymentType': 'Paypal',
      'transactionCurrency': 'EUR',
      'transactionShippingMethod': 'Retrait magasin',
      'transactionPromoCode': '',
      'transactionProducts': [{
        'id': '12',
        'name': 'bottes rouge croco',
        'sku': '45622FRES',
        'category': 'chaussures > bottes',
        'price': 450.00,
        'quantity': 2
        },
        {
        'id': '14',
        'name': 'veste cuir noire',
        'sku': '456VESRTE',
        'category': 'vêtements > vestes',
        'price': 750.00,
        'quantity': 1
        }]
    }];
    
  </script>
									

Chaque produit du panier doit être un élément du tableau transactionProducts. Cela équivaut à l’exécution d’un _addItem par produit.

On remarque par rapport au code basique actuel que les variables city, state or province et country n’ont pas d’équivalent dans le dataLayer. Arrêtez-moi si je me trompe, mais il me semble que de toute façon ces variables ne sont actuellement pas personnalisables au niveau du tag transactionnel. Google analytics récupère automatiquement les propriétés pays / région / ville du visiteurs qu’il applique à la transaction. J’avais déjà fait quelques tests pour utiliser ces variables et y insérer d’autres données, sans succès.

Le contenu de la requête http sur la transaction :

City, country et region sont en undefined.

On remarque également que de nouvelles variables font leur apparition (et donc sûrement de nouvelles dimensions natives dans l’outil) : type de transaction, date de la transaction, type de paiement, mode de livraison, code promo.

Le contenu de la requête http sur un item :

Beaucoup de variables qui ont une valeur dans le dataLayer n’apparaissent pas encore aujourd’hui…

Tout cela me fait penser à tout ce que l’Universal Analytics pourrait apporter dans les prochains mois. Le Google Tag Manager est clairement fait pour la mise à disposition de nouvelles dimensions, qu’elles soient prédéfinies ou personnalisées.

Si vous avez des remarques, astuces ou conseils à partager, n’hésitez pas !

Google+
mai
15

Un plan de taggage web analytics

« Dis-donc « l’analytics », tu peux nous faire un petit plan de taggage pour notre nouvelle section du site ? On t’a budgété une demi journée ça devrait te suffire non ? »

Tous les consultants web analytics en agence ont entendu ce genre de phrase. De nombreux chefs de projets ont appris par coeur ce petit refrain lorsqu’ils ont la responsabilité d’un nouveau site ou d’un nouveau projet :
1 – Tu vendras à ton client un plan de taggage
2 – Tu demanderas à ton consultant web analytics le fameux plan de taggage.
3 – Tu laisseras l’IT se débrouiller avec le livrable.

Tout ceci parait très simple en apparence, jusqu’au jour où un chef de projet junior pose la candide question à son aîné qui le forme : « Mais au fait c’est quoi un plan de taggage? Qu’est qu’on vend à notre client au juste ? ». Et bien pour être honnète j’ai rarement vu un chef de projet expérimenté bien expliquer ce qu’est un plan de taggage (ou plan de marquage).
J’ai du coup posé la question à Google et j’ai trouvé des petites explications très intéressantes mais je voulais ici ajouter quelques précisions et partager un peu mon expérience.

Pourquoi un plan de taggage ?

Souvent la première question que l’on se pose, surtout si l’on a un peu touché au web analytics avec Google Analytics, c’est : « pourquoi est-ce que l’on a besoin d’un plan ? »
Après tout le marqueur est un petit bout de code JavaScript que l’on colle dans une page et a priori on a envie de tracker toutes les pages, donc il suffirait de coller le tout dans une partie commune à toutes les pages, comme le footer, et on aurait pas besoin de s’embéter avec un plan…
Seulement la réalité est légèrement plus complexe si l’on souhaite enregistrer correctement tous les comportements des visiteurs sur son site. En fait il existe un certains nombres de cas pour lesquels le marqueur automatique ne suffit pas ou n’est pas précis.

Pour rappel un marqueur automatique prend en général par défaut l’URL de la page sur laquelle il se trouve.

- Deux pages différentes ont la même URL. Cette situation peut arriver notamment avec les formulaires dont les données sont envoyées par une méthode POST. Le résultat de l’action se trouve à la même URL que le formulaire de départ. Dans l’outil web analytics on ne pourra pas distinguer l’audience arrivant sur le formulaire de celle qui l’a validé.

- L’URL de la page n’est pas facilement déchiffrable. En fait souvent dans une optique d’optimisation du référencement naturel on se retrouve avec des URLs facile à lire pour l’utilisateur comme pour l’analyste mettant le nez dans un outil d’analyse, mais il arrive aussi que certaines pages qui n’ont pas pour vocation d’être indexées dans Google suivent juste la logique technique du framwork ou du CMS qui régit la construction des pages. Dans ce cas, on se retrouve au moment de l’analyse avec des noms de page que l’on ne comprend pas et qu’il faut aller vérifier manuellement.

- La logique de répertoire de l’URL ne correspond pas à la logique hiérarchique du site. Disons que dans le cas de Google Analytics, le séparateur hiérachique de l’URL (le « / ») est transformé naturellement en niveau hiérarchique dans le site par l’application, cependant il arrive fréquemment que cette logique de regroupement ne corresponde pas au regroupement que l’on souhaite appliquer aux visiteurs qui visitent le site. J’ai l’exemple extrême d’un site contenant quelques dizaines de produits avec des URLs du type : monsite.fr/nomduproduit.aspx . Au moment de l’analyse si l’on veut savoir rapidement combien de visiteurs ont vu au moins une page produit avant de mettre un article au panier, il faut passer par de laborieuses manipulations.

- On veut suivre des évènements particuliers qui n’ont pas d’URL propres : validation d’un mini formulaire AJAX, vue d’une vidéo, clic sur un bouton de notation, navigation dans une animation Flash, etc. Il faudra dans ce cas lancer un tag particulier au moment du clic.

- La page, le visiteur ou la visite possède un attribut particulier qui n’est pas enregistré automatiquement par l’outil web analytics et que l’on souhaite suivre.

- Les cannaux d’acquisition de traffic et les campagnes sont particuliers à chaque site et entreprise, il faut donc plannifier et classifier toutes les actions marketing afin qu’elles remontent avec le bon libéllé dans l’outil web analytics.

- La mise en place d’objectifs, d’évènement de succès (ou d’échecs) sont aussi à planifier afin d’avoir un suivi simplifié de la performance.

Pour ces principales raisons dès que l’on a des exigences importantes en terme de mesure il faut confier cette tâche à un professionnel qui saura tirer partie de l’outil choisi.

Comment construit-on un plan de taggage ?

Et bien puisque le plan de taggage découle d’une exigence de mesure, il faut construire au préalable ce que l’on appelle en anglais les « Business Requirements » ce que je traduis maladroitement en français par « spécifications de mesure »… Si quelqu’un a une meilleure suggestion de traduction je suis preneur.
Ces business requirements sont en fait une liste de questions clés auxquelles l’analyste devra répondre a minima. Ces questions sont en général un peu toujours les mêmes et avec l’expérience il devient plus facile de construire les business requirements. Ce document est celui qu’il faut faire valider à son client (interne si chez l’annonceur ou externe si en agence) c’est celui qui délimite le périmètre de la mesure que l’on a défini. Si le client pose par la suite une question qui sort de ce périmètre il faudra dans certains cas affiner le taggage.

Une fois ce document établi, le plan de taggage en lui même n’est qu’une solution technique que le consultant web analytics ou l’expert en implémentation apporte aux questions que se pose le marketing.
Cette solution technique consiste en général en trois étapes assez simples :
- Définir la liste des variables (attributs des visiteurs, visites, pages, évènements) que l’on va utiliser dans les tags, en établissant sa nomenclature.
- Décrire rigoureusement où l’on va placer les différents tags.
- Quel paramétrage particulier on va appliquer dans l’outil de mesure : déclaration de variables personnalisées, ajustement des attributs de ces variables, définition d’objectifs dans l’outil, mise en place des entonnoirs de conversion.

Du coup c’est quoi ce fameux plan de taggage ?

Au final le plan de taggage est (souvent) un document excel dans lequel on retrouvera l’arborescence du site avec les tags à placer en face. Dans une autre partie on trouvera aussi la définition précise des différents tags (marqueurs de page, marqueurs de clics, codes de suivi) afin de documenter pour le développeur qui devra placer les tags sur le site.

On retrouve une petite description dans cet article sous la section « Ca ressemble à quoi un plan de marquage? ».

Et qui doit faire le plan de taggage ?

Il faut bien comprendre que le plan de taggage est la synthèse entre des exigences d’analyse marketing et une réalité technique de mesure sur le site. Il est donc normal que l’on retrouve soit des développeurs, des consultants techniques ou des web analystes faire des plans de taggage dans certaines entreprises.
Le web analyste n’a parfois pas tout le bagage technique pour tirer au mieux parti des possibilités des outils alors que le développeur (ou consultant technique) n’a pas toujours le recul nécessaire des réalités de l’analyse dans l’interface pour prévoir efficacement la finesse du tag à mettre en place.

On voit bien qu’il est important dans tous les cas qu’une personne ayant de l’expérience en analyse participe (ou dirige) l’élaboration des spécifications de mesure et qu’une personne comprennant très bien la technique (et notamment le JavaScript) exécute le plan de taggage. Evidemment mon avis sur la question est qu’il est parfait d’avoir un expert ayant de l’expérience des deux cotés. Il est extrèmement enrichissant d’avoir à la fois l’experience technique pour être un meilleur analyste, et l’expérience de l’analyse pour être un très bon implémenteur. (hou le joli barbarisme…)

Et ensuite on fait quoi avec le plan de taggage ?

Bon c’est là que les ennuis commencent… après le plan vient la mise en place des marqueurs et la phase de recettage. Je ferai certainement un billet à part sur les joies du recettage que j’intitulerai sobrement : « Comment perdre des amis en agence… »

Google+