L’un des gros problèmes du modèle de données de Google Analytics est l’immuabilité des données historiques. Une fois qu’une ligne de données est écrite dans la table de données, elle y est pratiquement pour de bon. Ceci est particulièrement ennuyeux dans deux cas : les spams et les faux accès au commerce électronique. Le premier est un problème reconnu avec un protocole de collecte de données ouvert et public, le second est une gêne qui peut exploser en sabotage à part entière (vous pouvez utiliser le protocole de mesure pour envoyer des centaines de transactions énormes à la propriété GA de votre concurrent, par exemple) .

Dans cet article, je vais aborder un symptôme différent. J’ai déjà couvert ce sujet, et David Vallejo a également écrit un excellent article sur ce sujet.

Le problème est opérations en double. Il est très courant que votre site comporte une page de réception qui peut être revisitée via le cache ou l’historique du navigateur. En revisitant la page de reçu, il arrive souvent que les détails de la transaction soient écrits dans dataLayer (ou envoyé avec le ga() méthode) à nouveau, entraînant l’inflation de vos données de commerce électronique.

Un moyen plus simple de confirmer s’il s’agit d’un problème consiste à créer rapport personnalisé où vous inspectez les ID de transaction par rapport à la métrique Transactions. Idéalement, vous auriez une transaction par ID, sauf si vous avez décidé d’activer les mises à jour/mises à niveau des transactions dans votre collecte de données.

J’ai décidé de mettre à niveau ma solution pour utiliser customTask, car elle vous permet de vous passer de déclencheurs supplémentaires ou de logique variable. Nous allons configurer les choses avec Google Tag Manager, mais rien ne vous empêche de le faire également avec on-page analytics.js.

Comment ça fonctionne

Lorsque vous ajoutez le customTask variable à vos balises, elle s’active chaque fois que la balise tente d’envoyer un résultat à Google Analytics.

Lors de cette activation, la méthode recherche la clé &ti dans le modèle à succès. Cette clé correspond à la identifiant de transaction évaluer.

Ensuite, il examine le stockage de votre navigateur pour tous les ID de transaction déjà envoyés depuis le navigateur actuel.

Si l’ID de transaction dans le hit est trouvé dans le stockage du navigateur, cela customTask bloque le déclenchement du hit, ce qui empêche les informations dupliquées d’atteindre Google Analytics.

Si l’ID de transaction dans le hit est ne pas trouvé dans le stockage du navigateur, le customTask envoie le hit à GA normalement, mais il stocke également l’ID de transaction dans la liste des transactions déjà enregistrées. Ainsi, il bloque toute futur hits avec cet ID d’être envoyé.

REMARQUE! Cette fonctionnalité de blocage automatique ne fonctionne qu’avec le commerce électronique amélioré. Avec le commerce électronique standard, le customTask ne mettra à jour que le stockage du navigateur mais ne bloquera rien. Vous devrez utiliser des déclencheurs à la place (lisez la suite pour savoir comment procéder).

La variable customTask

Vous pouvez utiliser l’outil customTask Builder pour générer la variable nécessaire, ou vous pouvez simplement copier-coller le code ci-dessous dans un Variable JavaScript personnalisée, si vous le souhaitez. L’avantage d’utiliser l’outil de construction est que vous pouvez combiner ceci customTask avec toutes les autres configurations que j’ai ajoutées à l’outil.

Quoi qu’il en soit, voici à quoi devrait ressembler la variable JavaScript personnalisée :

function() {   // customTask Builder by Simo Ahava   //   // More information about customTask: https://www.simoahava.com/analytics/customtask-the-guide/   //   // Change the default values for the settings below.    // transactionDeduper: Configuration object for preventing duplicate transactions from being recorded.   // https://bit.ly/2AvSZ2Y   var transactionDeduper = {     keyName: '_transaction_ids',     cookieExpiresDays: 365   };    // DO NOT EDIT ANYTHING BELOW THIS LINE   var readFromStorage = function(key) {     if (!window.Storage) {       // From: https://stackoverflow.com/a/15724300/2367037       var value = '; ' + document.cookie;       var parts = value.split('; ' + key + '=');       if (parts.length === 2) return parts.pop().split(';').shift();     } else {       return window.localStorage.getItem(key);     }   };    var writeToStorage = function(key, value, expireDays) {     if (!window.Storage) {       var expiresDate = new Date();       expiresDate.setDate(expiresDate.getDate() + expireDays);       document.cookie = key + '=' + value + ';expires=' + expiresDate.toUTCString();     } else {       window.localStorage.setItem(key, value);     }   };    var globalSendHitTaskName   = '_ga_originalSendHitTask';    return function(customTaskModel) {      window[globalSendHitTaskName] = window[globalSendHitTaskName] || customTaskModel.get('sendHitTask');     var tempFieldObject, dimensionIndex, count, ga, tracker, decorateTimer, decorateIframe, iframe;      customTaskModel.set('sendHitTask', function(sendHitTaskModel) {        var originalSendHitTaskModel = sendHitTaskModel,           originalSendHitTask      = window[globalSendHitTaskName],           canSendHit               = true;        var hitPayload, hitPayloadParts, param, val, regexI, trackingId, snowplowVendor, snowplowVersion, snowplowPath, request, originalTrackingId, hitType, nonInteraction, d, transactionId, storedIds;        try {          // transactionDeduper         if (typeof transactionDeduper === 'object' && transactionDeduper.hasOwnProperty('keyName') && transactionDeduper.hasOwnProperty('cookieExpiresDays') && typeof sendHitTaskModel.get('&ti') !== 'undefined') {           transactionId = sendHitTaskModel.get('&ti');           storedIds = JSON.parse(readFromStorage(transactionDeduper.keyName) || '[]');           if (storedIds.indexOf(transactionId) > -1 && ['transaction', 'item'].indexOf(sendHitTaskModel.get('hitType')) === -1) {             canSendHit = false;           } else if (storedIds.indexOf(transactionId) === -1) {             storedIds.push(transactionId);             writeToStorage(transactionDeduper.keyName, JSON.stringify(storedIds), transactionDeduper.cookieExpiresDays);           }         }         // /transactionDeduper          if (canSendHit) {           originalSendHitTask(sendHitTaskModel);         }        } catch(e) {         originalSendHitTask(originalSendHitTaskModel);       }      });    }; } 

Il y a un objet de configuration dans la variable transactionDeduper que vous pouvez modifier, si vous le souhaitez. L’objet de configuration doit avoir à la fois keyName et cookieExpiresDays.

Ensemble keyName à ce que vous voulez le nom du cookie ou le localStorage clé pour être. La valeur par défaut est _transaction_ids.

Ensemble cookieExpiresDays au nombre de jours pendant lesquels le cookie doit exister. Un cookie n’est utilisé que si le navigateur de l’utilisateur ne prend pas en charge localStorage. Si localStorage est utilisé, aucune expiration n’est définie.

La logique principale se produit vers la fin du bloc de code, où j’ai encadré la solution avec // transactionDeduper et // /transactionDeduper .

C’est vraiment très simple et cela suit le processus que j’ai décrit dans le chapitre précédent.

Si vous utilisez Commerce électronique amélioréensuite ceci customTask s’occupera de tout pour vous. Si l’ID de transaction se trouve dans la liste des ID stockés, il empêchera simplement le hit de partir vers Google Analytics.

Si vous utilisez Commerce électronique standardles customTask n’écrira que l’ID dans le stockage, et vous devrez gérer vous-même la logique de blocage.

Dans tous les cas, vous devez ajouter ceci customTask variable à toutes les balises Enhanced Ecommerce et/ou Transaction qui ont le pouvoir d’envoyer des informations d’achat à Google Analytics. Pour savoir comment ajouter le customTask à vos balises, consultez ce guide ou suivez les instructions de l’outil customTask Builder.

Déclencheurs et variables pour le commerce électronique standard

En raison de la façon dont le commerce électronique standard est divisé en transaction et item hits, la logique de blocage serait extrêmement difficile à automatiser dans customTask. C’est pourquoi vous devrez créer un exception déclencheur pour votre balise de transaction, qui empêche la balise de se déclencher si l’ID de transaction se trouve dans la liste des ID stockés.

Variable de couche de données pour l’ID de transaction

Créer un Variable de couche de données pour transactionIdcomme ça:

Variable de cookie propriétaire pour la liste des ID de transaction

Créez une variable de cookie propriétaire pour la liste d’ID de transaction, à l’aide de la keyName vous avez configuré dans le customTask. Voici à quoi ressemblerait une configuration par défaut :

Variable JavaScript personnalisée pour vérifier si l’ID se trouve dans la liste

Enfin, créez une variable JavaScript personnalisée qui renvoie true si l’ID de transaction se trouve dans la liste.

function() {   // Change this to match the keyName you added to customTask:   var keyName = '_transaction_ids';      var ids = JSON.parse((!!window.Storage ? window.localStorage.getItem(keyName) : {{Cookie - _transaction_ids}}) || '[]');   return ids.indexOf({{DLV - transactionId}}) > -1; } 

Nommez la variable quelque chose comme {{JS – ID de transaction envoyé}}.

Le déclencheur d’exception

La dernière étape consiste à créer un déclencheur qui empêche votre balise de transaction de se déclencher. Il doit utiliser le même un événement comme balise de transaction. Ainsi, si la balise de transaction se déclenche sur un déclencheur de vue de page, le déclencheur d’exception doit également être un déclencheur de vue de page (en savoir plus sur les exceptions ici).

Dans les conditions de déclenchement, vérifiez si {{JS – transactionId sent}} est égal à true. Ainsi, l’exception bloquera la balise à laquelle elle est attachée si l’identifiant de la transaction se trouve dans la liste des identifiants déjà enregistrés.

Voici un exemple de ce à quoi ressemble l’exception avec un déclencheur d’événement personnalisé et comment l’exception est ajoutée à la balise.

Dernières pensées

Ma quête pour améliorer la qualité des données de Google Analytics en utilisant customTask continue.

Empêcher l’envoi de hits si certaines conditions se présentent est agréable et élégant à parcourir customTaskpuisque vous n’avez pas à vous soucier des déclencheurs compliqués qui encombrent votre interface GTM.

Cependant, chaque customTask utilisé augmente l’opacité de votre configuration, donc le compromis est que vous ne saurez pas ce que font les balises individuelles en un coup d’œil sans explorer leurs champs définis (et comprendre ce que customTask fait en premier lieu).

Comme toujours, faites-moi savoir ce que vous pensez de cette solution dans les commentaires, et faites-moi savoir aussi si vous avez des suggestions pour l’améliorer ! Merci.