Le commerce électronique amélioré est certainement l’une des meilleures fonctionnalités d’interface utilisateur de rapport que Google Analytics a à offrir. Le commerce électronique amélioré, comme son nom l’indique, est un ensemble de dimensions, de mesures et de rapports, qui se combinent pour vous fournir une vue assez complète de la façon dont les utilisateurs interagissent avec vos produits dans votre boutique en ligne. Le principal inconvénient du commerce électronique amélioré est, comme pour toutes les bonnes choses, qu’il est compliqué à mettre en œuvre.

Heureusement, il y a Google Tag Manager. Théoriquement, vous pourriez implémenter Enhanced Ecommerce via Google Tag Manager sans jamais ajouter une seule ligne de logique fonctionnelle dans la base de code de votre site Web. Vous pouvez tout faire simplement grattage le modèle d’objet de document (DOM). Cependant, comme nous l’espérons, nous l’avons appris au fil des ans – GTM est un outil avec lequel la minutie l’emporte sur la rapidité.

Chaque fois que vous travaillez avec dataLayer, par exemple, vous investissez dans la stabilité de votre processus de collecte de données. Ainsi, même si je parlerai de DOM scraping plus loin dans le guide, l’accent sera mis ici sur une configuration où le l’extrémité avant produit des documents HTML et/ou JavaScript qui remplissent les valeurs de commerce électronique dans le dataLayer sans utiliser le DOM scraping ou d’autres hacks côté client pour faire le travail.

Il y a beaucoup d’informations dans cet article. Une grande partie est déjà couverte dans l’excellent guide du développeur de commerce électronique amélioré de Google, mais il y a beaucoup de des pièges que j’aurais pu couvrir dans des articles précédents (voir le chapitre Lectures complémentaires), ou que je n’aurais peut-être même pas écrit auparavant.

REMARQUE! C’est un la mise en oeuvre guider. Si vous voulez savoir comment fonctionne le commerce électronique amélioré ou comment mapper votre site en interactions pertinentes, vous voudrez consulter la documentation du centre d’assistance de Google.

Comment lire ce guide

Évidemment, il serait logique que vous lisiez le guide de haut en bas. Cependant, j’accepte pleinement que la loquacité de ma rhétorique puisse être ennuyeuse pour certains dans toute sa splendeur verbeuse. Aussi, parfois j’écris des trucs connards comme ça.

Ainsi, selon votre rôle dans le projet de mise en œuvre, il se peut que seuls certains chapitres soient pertinents pour vous. Cependant, ne négligez pas de consulter toutes les parties prenantes du projet ! Cela n’a aucun sens pour un développeur d’écrire du code sans comprendre à quoi il sert. De même, il n’est pas logique que la personne qui utilise Google Tag Manager utilise le dataLayer structures sans comprendre les limites des systèmes back-end ou front-end.

Si vous êtes un développeur, chargé de mettre en œuvre le dataLayer objetsvous aurez envie de lire les chapitres suivants (dans l’ordre):

1. Introduction
2. Remplir la couche de données
3. Un mot sur le scraping du DOM
4. Combinaison de différents types de données dans un seul hit EEC
5. Dimensions et statistiques personnalisées au niveau du produit
6. N’oubliez pas : soyez cohérent
7. Types de données : Actions et toutes ses sous-sections
8. Types de données : Impressions et toutes ses sous-sections
9. Types de données : Promotions et toutes ses sous-sections

Si vous êtes la personne chargée de configurer EEC via l’interface utilisateur de Google Tag Managervous devrez vous concentrer sur les chapitres suivants (dans l’ordre) :

1. Introduction
2. Différences (et similitudes) avec le commerce électronique standard
3. Envoyez les données à Google Analytics à l’aide de la couche de données
4. Envoyez les données à Google Analytics à l’aide d’une variable JavaScript personnalisée
5. Vue de page ou balise d’événement
6. Types de données : Actions et toutes ses sous-sections
7. Types de données : Impressions et toutes ses sous-sections
8. Types de données : Promotions et toutes ses sous-sections
9. Débogage de la configuration
10. Règles d’or du commerce électronique amélioré

Comme je l’ai dit, je souhaite toujours que vous passiez du temps à lire l’intégralité du guide. Je ne pense pas qu’il y ait d’informations non pertinentes pour quiconque travaille sur le projet, et il est logique de comprendre toute la complexité de la mise en œuvre plutôt que de se concentrer uniquement sur les éléments directement pertinents pour votre travail.

Introduction

La mise en œuvre du commerce électronique amélioré nécessite une vue d’ensemble des composants suivants :

• Les différents Types de données qui peut être envoyé à GA (Actions, Vues d’impressions, Vues promotionnelles).

• Comment le 'ecommerce' l’objet est compilé et poussé vers dataLayer (ou généré avec une variable JavaScript personnalisée).

• Comment ces données sont envoyées avec une balise à Google Analytics.

Ces trois composants sont nécessaires, et tous trois nécessitent une certaine compréhension du fonctionnement de Google Tag Manager, de la manière dont les balises et les déclencheurs interagissent avec dataLayer, et comment les données de commerce électronique amélioré sont envoyées à Google Analytics. Ceux-ci seront tous couverts dans ce guide.

Inutile de dire que si vous voulez un robuste la mise en œuvre, l’interaction et la coopération avec les développeurs front-end de votre site est un must absolu. En règle générale, les développeurs front-end utilisent des modèles de page et des variables côté serveur (à l’aide PHP ou alors React.js, par exemple) pour construire la structure HTML d’une page donnée. Sur les pages de commerce électronique amélioré, il est important qu’elles intègrent le front-end avec le système de commerce électronique que vous utilisez, afin que ce système produise dynamiquement les valeurs nécessaires pour que les développeurs front-end puissent passer dans le dataLayer.

Pour les interactions qui ont lieu après le chargement de la page, telles que les interactions avec le panier, les développeurs frontaux peuvent avoir besoin de mettre à jour le JavaScript du site pour remplir le dataLayer objet avec les valeurs nécessaires dans le client.

Ou vous pouvez simplement jeter la prudence au vent et tout supprimer du code HTML lui-même via Google Tag Manager. L’objectif de ce guide n’est pas de recommander un plan d’action spécifique, mais de mettre en évidence les différentes manières dont vous pouvez exécuter le projet de mise en œuvre du commerce électronique amélioré.

Différences (et similitudes) avec le commerce électronique standard

Si vous avez exécuté le commerce électronique standard via Google Tag Manager, il y a principalement Trois différences majeures entre cela et le commerce électronique amélioré.

• Commerce électronique standard ne collecte que les transactions (c’est-à-dire les appels “Achat” dans EEC) – il n’y a pas d’autres composants dans son entonnoir (en fait, il n’y a pas d’entonnoir).

• Commerce électronique standard utilise un autre category format.

• Commerce électronique standard ne prend pas en charge les dimensions et statistiques personnalisées au niveau du produit.

Une chose à laquelle il faut prêter attention est que vous pouvez collecter à la fois les hits de commerce électronique standard et de commerce électronique amélioré à une vue Google Analytics optimisée pour le commerce électronique ! Cela signifie que si vous laissez votre “ancien” suivi en place et que vous exécutez une implémentation de commerce électronique amélioré en parallèle, vous risquez de vous retrouver double comptage transactions.

Google Analytics Est-ce que dédupliquer les transactions identiques envoyées dans une session, mais il suffit que certains composants des deux méthodes de suivi différentes diffèrent pour que GA collecte les données deux fois.

catégorie de produit est collecté dans une dimension différente, selon la méthode que vous utilisez. Donc, si vous remplissez le category clé pour un produit utilisant l’une ou l’autre méthode, la dimension que vous recherchez dans GA sera différente.

Directives de mise en œuvre

Les chapitres suivants couvriront certains aspects de la mise en œuvre d’un commerce électronique amélioré. Comme je l’ai indiqué dans l’introduction, la façon dont les valeurs sont renseignées dans dataLayer dépendent de l’intégration entre le front-end de votre site et la plateforme de commerce électronique que vous utilisez. Certaines plates-formes telles que WooCommerce pour WordPress introduisent cette intégration à l’aide d’un plugin, d’autres telles que Magento la fournissent prête à l’emploi en tant que fonctionnalité.

Cependant, il existe de nombreuses plates-formes et configurations de commerce électronique personnalisées qui nécessitent un bricolage pour qu’elles produisent les valeurs dans des variables que vos développeurs frontaux peuvent ensuite utiliser.

Le chapitre suivant, par exemple, indique simplement ce que le générique dataLayer l’objet doit ressembler. La façon dont vous finissez par remplir les valeurs dans les clés requises dépend de vous, mais cela se fait généralement de l’une des manières suivantes :

1. Les dataLayer.push() est écrit directement dans le modèle de page par le mécanisme côté serveur dont vous disposez pour produire les modèles.

2. Les dataLayer.push() est généré dynamiquement par votre serveur Web ou la plate-forme de commerce électronique en utilisant généralement une combinaison de requêtes JavaScript et HTTP.

3. Les paires clé-valeur sont remplies en grattant la page HTML à l’aide de Google Tag Manager.

Remplir la couche de données

Le commerce électronique amélioré nécessite un syntaxe spécifique pour les objets poussés vers dataLayer ou généré avec une variable JavaScript personnalisée. Par exemple, un dataLayer.push() avec l’objet de commerce électronique minimum requis pour un achat ressemble à ceci :

window.dataLayer = window.dataLayer || []; window.dataLayer.push({   event: 'eec.purchase',   ecommerce: {     purchase: {       actionField: {         id: '1'       },       products: [{         id: 'p'       }]     }   } }); 

Notez que Google Tag Manager ne réagit qu’aux dataLayer.push() commandes. Aucune autre méthode de tableau ne fera quoi que ce soit dans GTM, il est donc impératif de ne pas improviser avec cela. Toutes les interactions avec dataLayer faut faire avec push().

Dans le push, toutes les touches répertoriées sous et y compris ecommerce sont requises. Les event la clé est quelque chose que je recommande fortement d’ajouter à chaque dataLayer.push() chose.

Maintenant, vous devrez remplir les clés de l’objet avec les valeurs pertinentes. Par exemple, la valeur de ecommerce.purchase.actionField.id devrait être un identifiant unique de la commande elle-même. Vous pouvez en générer un au hasard à l’aide de JavaScript, mais en général, vous voudrez utiliser le même ID de commande inclus dans la transaction réelle. De cette façon, vous pourrez par la suite augmenter les détails de cette transaction à l’aide de l’importation de données, par exemple.

De même, vous devrez collecter des détails sur les produits de la transaction et envoyer également des informations sur les variantes, les marques et les catégories sous forme de métadonnées.

La manière dont vous procédez dépend vraiment de l’intégration à votre système de commerce électronique. Il est impossible de donner des instructions génériques, car chaque plate-forme de commerce électronique diffère dans la manière dont elle fournit les valeurs que vous pouvez exploiter dans d’autres codes sur site. Mais si vous avez déjà un système de commerce électronique en place, je vous recommande de lire sa documentation et d’essayer de savoir comment vous pouvez demander ou accéder à ces valeurs et variables à partir de ce système.

Envoyez les données à Google Analytics à l’aide de la couche de données

Lorsque vous sélectionnez le Utiliser la couche de données option dans les paramètres de commerce électronique amélioré d’une vue de page Google Analytics ou d’une balise d’événement (ou d’une variable de paramètres Google Analytics), vous demandez à la balise d’examiner la couche de données et d’extraire les paires clé-valeur de la ecommerce objet poussé plus récemment dans dataLayer.

Cela semble assez simple. Tout ce que vous avez à faire est de vous assurer que l’objet poussé dans dataLayer suit exactement la syntaxe correcte, et qu’il est poussé dans dataLayer avant (ou dans le même push que) le tag qui accède aux données via Utiliser la couche de données les feux.

Cependant, il y a deux choses importantes à noter ici.

1. Les dataLayer.push() devoir être parfaitement formé. Il n’y a aucun moyen de le modifier en déplacement si vous activez l’option “Utiliser la couche de données”. Il est donc absolument vital que vous spécifiiez et auditiez l’objet qui est poussé dans dataLayer pour la collecte de données de commerce électronique améliorée.

2. Lorsqu’une balise avec “Utiliser la couche de données” se déclenche, elle n’accède vraiment qu’à la le plus récent ecommerce pousser. Ainsi, si vous avez divisé les impressions de produit en plusieurs poussées, puis déclenché la balise lorsque la dernière est terminée, si la case “Utiliser la couche de données” est cochée, seul l’objet des dernières impressions est envoyé à Google Analytics.

Le point (2) peut sembler contre-intuitif, mais il a en fait du sens. Si GTM ne présentait pas ce comportement, alors tous ecommerce les poussées effectuées sur une seule page seraient associées à toutes les charges utiles de commerce électronique amélioré ultérieures. En envoyant uniquement l’objet poussé le plus récemment, ce comportement peut être évité.

C’est précisément à cause de ce comportement que je recommande à nouveau vivement de incluez toujours le event clé dans chaque objet de commerce électronique amélioré. Pourquoi? Parce qu’alors vous pouvez utiliser Déclencheurs d’événements personnalisés pour déclencher vos balises de commerce électronique amélioré au bon moment, et l’objet le plus récent auquel ils accèdent sera toujours celui qui a déclenché la balise. De cette façon, vous ne perdrez aucune donnée à cause de poussées qui n’ont déclenché aucune balise.

Cependant, vous voudrez peut-être également consulter la section suivante.

Envoyez les données à Google Analytics à l’aide d’une variable JavaScript personnalisée

L’un de mes principaux problèmes avec le dataLayer La syntaxe d’objet pour Enhanced Ecommerce dans Google Tag Manager est sa rigidité. L’option “Utiliser la couche de données” nécessite que vous suiviez une syntaxe très spécifique et peu maniable.

Cela signifie qu’il peut s’avérer très difficile de mettre les données dans le bon format en premier lieu. Mais vous devez également mettre en place un processus afin de pouvoir le mettre à jour dans un délai minimal et de pouvoir l’auditer pour vous assurer qu’aucune donnée n’est perdue.

Donc, heureusement, Google Tag Manager vous permet également d’envoyer les données à l’aide d’une variable JavaScript personnalisée.

L’utilisation de la variable a une logique très simple. Tout ce que la variable doit faire est retour un valide ecommerce chose. En d’autres termes, la variable doit renvoyer exactement la même chose que les développeurs pousseraient dans dataLayer dans un monde parfait.

Et comment est-ce utile? Eh bien, vous pourriez avoir les données de commerce électronique poussées dans dataLayer dans quelconque format, puis utilisez la variable JavaScript personnalisée pour la transformer en un format valide ecommerce chose. De cette façon, vous n’avez pas besoin de confondre les choses avec un dataLayer spécification, mais plutôt la plate-forme de commerce électronique peut pousser les données dans dataLayer dans le format qui lui convient le mieux. Ensuite, avec un peu de magie JavaScript, vous pouvez extraire ces données via la variable JavaScript personnalisée dans votre balise.

Ou, si vous souhaitez suivre la route de grattage DOM, vous pouvez effectuer tout le grattage dans la variable JavaScript personnalisée et lui faire renvoyer une valeur valide. ecommerce objet avec toutes les paires clé-valeur en place.

Vous pouvez également modifier un valide ecommerce objet dans le dataLayer au cas où vous auriez besoin d’y ajouter des mises à jour dynamiques (telles que des dimensions personnalisées au niveau du produit). Par exemple, me voici en train d’ajouter une dimension personnalisée de portée produit à tous les produits d’un objet Achat :

function() {   // Create a copy of the variable to avoid   // modifying the source object by reference   var ecom = JSON.parse(JSON.stringify({{Data Layer Variable - ecommerce}}));   try {     ecom.purchase.products.forEach(function(prod) {       prod.dimension10 = {{get discount}}(prod.id);     });   } catch(e) {}   return {     ecommerce: ecom   }; } 

Avec cet exemple simple, je mets à jour un parfaitement valide ecommerce objet (représenté par {{Variable de couche de données – commerce électronique}}), en ajoutant un nouveau champ à chaque produit.

Comme vous pouvez le voir, je fais un copie de la variable d’origine avec le JSON.parse(JSON.stringify(obj)) méthode. Étant donné que JavaScript copie les objets par référence, toute modification que vous apportez au ecom la variable se refléterait dans l’objet d’origine stocké dans dataLayer. Cela peut avoir des effets négatifs si la variable est exécutée plusieurs fois, en particulier si vous exécutez des calculs sur n’importe quel champ (les calculs seraient répétés encore et encore).

Un supplémentaire chose importante à noter. Les variables de couche de données sont, par défaut, Version 2. Cela signifie qu’ils fusionneront tous les ecommerce pousse dans un grand ecommerce chose. Ainsi, lorsque vous créez la variable pour ecommercevous voudrez peut-être utiliser Version 1. Lisez cet article pour plus d’informations.

Vue de page ou balise d’événement

Que vous souhaitiez utiliser une vue de page ou une balise d’événement et la façon dont vous configurez vos déclencheurs d’événements personnalisés dépend entièrement de vous.

Personnellement, je toujours utiliser les balises d’événement. Pourquoi? Parce que si vous utilisez une balise Page View, vous ne savez pas quels événements Enhanced Ecommerce ont été collectés dans Google Analytics. Cela peut rendre difficile le débogage d’une implémentation cassée. En utilisant des événements, je peux toujours consulter le rapport Top Events pour voir tous les hits Enhanced Ecommerce envoyés à GA.

Vous pouvez même ajouter des éléments tels que l’ID de commande en tant qu’étiquette d’événement de ces appels, de sorte que vous puissiez vraiment commencer le débogage si l’événement de la commande a été envoyé mais qu’aucune transaction n’a été réellement reçue dans les rapports de commerce électronique.

Si vous utilisez une balise d’événement, la définition de la nonInteraction champ est, encore une fois, à vous. Personnellement, je l’ai réglé sur true lorsque l’événement est envoyé avec le chargement de la page, et false dans tous les autres cas.

Mais vous faites exactement ce qui vous convient le mieux. Parfois, vous voudrez peut-être éviter les événements si vous approchez de la limite de 500 appels par session. Pas une bonne raison, mais une raison quand même.

Un mot sur le scraping du DOM

Gratter le DOM fait référence à l’habitude d’accéder à la représentation HTML dynamique de la page (le Document Object Model) directement avec JavaScript et de remplir les paires clé-valeur Enhanced Ecommerce avec les valeurs trouvées sur la page. Sur une page de reçu, par exemple, vous voyez souvent le numéro de commande, la valeur totale de la transaction, tous les produits, les frais d’expédition, etc. Vous pouvez donc tout aussi bien les supprimer de la page plutôt que de passer par un projet de spécification compliqué avec vos développeurs front-end.

function() {   var orderId = document.querySelector('#order span.id').textContent,       revenue = document.querySelector('#order span.total').textContent,       products = [].map.call(document.querySelectorAll('#order .product'), function(prod) {     return {       id: prod.getAttribute('data-id'),       name: prod.innerText     };   });   return {     ecommerce: {       purchase: {         actionField: {           id: orderId,           revenue: revenue         },         products: products       }     }   }; } 

Ce n’est pas joli, et cela s’accompagne de beaucoup de bagages et de dettes techniques. D’une part, vous introduisez un énorme maillon faible dans votre suivi. Si quelque chose change sur la page, par exemple en raison d’un test A/B, il est possible que votre scraper tombe en panne.

De plus, il est assez courant de ne pas inclure tous les détails sur les produits sur la page de reçu. En règle générale, seuls le nom, l’ID, le prix et les taxes de l’élément de campagne suffisent. Cela signifie que vous manquerez toutes les autres métadonnées vitales telles que la catégorie de produit, la marque, la variante, etc.

En d’autres termes, le scraping pourrait être le moyen le plus simple d’obtenir rapidement des données, et pour cela, c’est un excellent outil. Mais utilisé seul pour assurer la qualité des données de l’ensemble de votre processus de commerce électronique amélioré ? Pas tellement.

Combinaison de différents types de données dans un seul hit EEC

Le commerce électronique amélioré dans Google Tag Manager vous permet d’envoyer plusieurs types de données dans un seul appel de commerce électronique amélioré. C’est parce que tous les types de données sont…