Universal Analytics utilise deux composants (par défaut) pour attribuer une session de navigateur à une campagne spécifique : paramètres de requête dans l’URL et le chaîne de référence.

L’URL de la page est envoyée avec chaque accès à Google Analytics à l’aide du champ Emplacement du document, qui se traduit également par le &dl paramètre dans le Protocole de mesure.

La chaîne de référence est envoyée avec un hit à Google Analytics à l’aide du champ Référent du document, tant que le nom d’hôte du référent ne correspond pas exactement à celui de la page actuelle et que la chaîne de référence n’est pas vide.

Lors de l’attribution d’un hit à une session de campagne, Google Analytics vérifie d’abord le emplacement valeur pour les paramètres suivants :

• gclid – pour attribuer la session à Google Ads
• utm_source – pour attribuer la session à une campagne personnalisée

Si ces paramètres ne sont pas trouvés, Google Analytics examine les référent chaîne.

Oui, il existe des étapes supplémentaires pour l’attribution de la campagne (voir l’organigramme), mais ces deux étapes sont pertinentes dans le contexte de cet article.

Il existe deux contextes dans lesquels l’attribution de campagnes basées sur des URL et des chaînes de référence devient compliquée.

1. Si le site bloque Google Analytics sur la page de destination (en raison d’un consentement manquant), mais le rend ensuite disponible sur les pages suivantes (en raison d’un consentement accordé), l’URL de la campagne d’origine et la chaîne de référence ne sont plus disponibles.
2. Si le site est un demande d’une seule pageen particulier les balises basées sur Google Tag Manager deviennent sensibles au problème de référencement malveillant.

A cet effet, j’ai créé un nouveau template personnalisé : Conserver les données de campagne.

Ce modèle résout les deux problèmes énumérés ci-dessus. Cependant, vous devrez apporter des modifications supplémentaires à vos paramètres Google Analytics avant que la solution ne soit terminée.

Vous pouvez télécharger le modèle à partir de la galerie de modèles.

1. Stocker les données de campagne dans un cookie de session

Le premier problème est particulièrement gênant sur les sites qui utilisent systèmes de gestion du consentement de bloquer Google Analytics si le consentement n’a pas été accordé.

Si le consentement est accordé sur la page de destination, il ne devrait y avoir aucun problème. La page est rechargée avec les paramètres de campagne dans l’URL et la chaîne de référence intacts, et les balises Google Analytics peuvent les utiliser lors de l’attribution de la session à une campagne spécifique.

Toutefois, si l’utilisateur n’accorde son consentement qu’à après avoir navigué plus profondément dans le siteles balises qui se déclenchent sur ces pages n’auront plus accès à la campagne initiale qui a amené l’utilisateur sur le site, ce qui entraîne inflation du trafic direct.

Pour résoudre ce problème, la balise de modèle (en supposant que Google Tag Manager n’est pas bloqué également) écrit l’URL de la page actuelle dans un cookie si il a des paramètres de campagne. De même, la chaîne de référence est également écrite dans un cookie si son nom d’hôte ne contient pas le nom d’hôte de la page en cours.

Ensuite, lorsque les balises Google Analytics se déclenchent enfin, elles peuvent prendre l’emplacement et le référent d’origine de ces cookies pour attribuer la session à sa source correcte.

Configurer la balise Persist Campaign Data

Créez une nouvelle balise avec le Conserver les données de campagne modèle. Cochez la case à côté de Stocker les données de campagne dans un cookie de navigateur et vérifiez que les paramètres sont OK.

Par défaut, les paramètres d’URL suivants obligent la balise à définir le cookie d’URL de la campagne :

• utm_source
• utm_medium
• utm_campaign
• utm_term
• utm_content
• utm_id
• gclid

Naturellement, vous pouvez ajouter des paramètres supplémentaires à la liste si vous le souhaitez.

Tous ces paramètres n’ont pas la capacité de démarrer une nouvelle session (uniquement utm_source et gclid faire, en fait), mais l’hypothèse est que si vous avez défini des paramètres UTM, vous souhaitez les inclure avec vos résultats.

Ensuite, vous pouvez modifier le nom par défaut du cookie d’URL et du cookie de référence, si vous le souhaitez.

REMARQUE! Si vous changez le nom de l’un ou l’autre des cookies, vous devoir modifiez les autorisations du modèle et autorisez le modèle à définir le ou les nouveaux noms de cookies.

La balise n’écrira les cookies que dans des conditions spécifiques :

1. Les URL cookie n’est écrit que si la chaîne de requête d’URL contient l’un des paramètres de déclenchement répertoriés. Si un tel paramètre est trouvé, l’URL complète est écrite dans le cookie d’URL de la campagne.
2. Les Référent cookie n’est écrit que si le nom d’hôte du référent ne contient pas le nom d’hôte de la page actuelle et que la chaîne de référence n’est pas vide. Si les deux conditions sont bonnes, la chaîne de référence complète est écrite dans le cookie de référence.

Ainsi, il est sûr de le mettre sur le Toutes les pages déclencheur, car peu importe s’il se déclenche sur chaque page.

Note! Vous voudrez peut-être le définir sur un déclencheur qui se déclenche une fois que le consentement de l’utilisateur a été établi – si l’utilisateur donne son consentement ou a déjà donné son consentement, la balise n’a pas besoin (et ne devrait pas) se déclencher, car alors vos balises Google Analytics seraient se déclenchent normalement et vous n’aurez pas besoin d’enregistrer l’URL et les données de référence dans les cookies.

Créer les variables de cookies

Vous aurez besoin de deux nouveaux, définis par l’utilisateur Biscuit propriétaire variables.

La première, {{Cookie – __gtm_campaign_url}}. La deuxième, {{Cookie – __gtm_referrer}}.

Assurez-vous de vérifier le Cookie de décodage URI boîte.

Créer le customTask

Pour mettre à jour vos balises Google Analytics, nous utiliserons un customTask. C’est un moyen simple de s’assurer que les cookies ne sont utilisés que s’ils existent, et c’est un excellent moyen de supprimer les cookies dès qu’ils ont été utilisés, afin qu’ils ne persistent pas inutilement.

REMARQUE! Vous n’avez pas avoir utiliser un customTask. Vous pouvez régler le location, pageet referrer champs manuellement sur la balise, si vous le souhaitez. Il vous suffit d’ajouter des valeurs de secours appropriées si les cookies n’existent pas, sinon vous risquez de corrompre vos données avec des location et referrer des champs.

Si vous avez également besoin des cookies pour autre chose, vous pouvez définir le customTask pour ne pas supprimer les cookies après que les valeurs ont été “utilisées”.

Créer un nouveau Variable JavaScript personnaliséenomme le {{customTask – définir l’emplacement et le référent à partir du cookie}}et ajoutez le code suivant dans :

function() {   return function(customModel) {     // Set to the cookie variables     var storedLocation = {{Cookie - __gtm_campaign_url}};     var storedReferrer = {{Cookie - __gtm_referrer}};     // Set to the cookie names     var storedLocationCookieName = '__gtm_campaign_url';     var storedReferrerCookieName = '__gtm_referrer';     // Set to the root domain of your site (e.g. domain name without any subdomain, "mysite.com")     var domainName = 'simoahava.com';     // Choose whether to delete a cookie after its value is used (true/false)     var deleteCookieToggle = true;      var deleteCookie = function(name) {       document.cookie = name + '=; path=/; domain=' + domainName + '; expires=Thu, 01 Jan 1970 00:00:00 GMT';     };          if (typeof storedLocation !== 'undefined') {       customModel.set('location', storedLocation);       customModel.set('page', document.location.pathname + document.location.search);       if (deleteCookieToggle === true) { deleteCookie(storedLocationCookieName); }     }     if (typeof storedReferrer !== 'undefined') {       customModel.set('referrer', storedReferrer);       if (deleteCookieToggle === true) { deleteCookie(storedReferrerCookieName); }     }   }; } 

Il y a certaines choses que vous devrez peut-être modifier.

Changer la storedLocation et storedReferrer variables pour pointer vers les bonnes variables de cookies propriétaires de Google Tag Manager que vous avez créées, si vous vous êtes écarté des valeurs par défaut utilisées dans ce guide.

Changer la storedLocationCookieName et storedReferrerCookieName aux noms de cookies corrects, si vous vous êtes écarté des valeurs par défaut utilisées dans ce guide.

Met le domainName au domaine racine correct (nom de domaine sans aucun sous-domaine inclus).

Met le deleteCookieToggle pour false si vous ne souhaitez pas que la tâche supprime les cookies une fois que leurs valeurs ont été “utilisées”.

Cette customTask fixe le location etreferrer champs si les cookies respectifs existent, puis (éventuellement) supprime les cookies pour ces champs qui ont été définis. Si un cookie n’existe pas, son champ n’est pas défini.

Si la location est réglé, le customTask fixe également le page champ au chemin de la page actuelle et à la chaîne de requête. Si ce n’était pas le cas, la balise prendrait le chemin de la page à partir du location ainsi, ce qui gonflerait les pages vues de la page de destination plutôt que de les incrémenter pour la page sur laquelle l’utilisateur se trouve réellement.

Ajouter le customTask à vos balises Google Analytics

Enfin, ajoutez le customTask variable que vous venez de créer dans vos balises Google Analytics. Vous n’avez besoin que de le faire se déclencher sur la première balise qui se déclenche sur la page, mais pour plus de sécurité, il peut être judicieux de l’ajouter à votre variable de paramètres Google Analytics, puis de l’attacher à toutes vos balises.

Le nom du champ est tâche personnalisée et la valeur est {{customTask – définir l’emplacement et le référent à partir du cookie}}.

Données de campagne en magasin – résumé

Si l’utilisateur arrive sur votre site avec des paramètres de campagne dans l’URL et/ou un référent externe au domaine de votre site Web, voici ce qui se passe :

1. Les Conserver les données de campagne la balise crée de nouveaux cookies si nécessaire ; un pour l’URL de la page (si elle avait des paramètres de campagne) et un pour la chaîne de référence (s’il s’agit d’un domaine externe).
2. Une fois que l’utilisateur a donné son consentement, vos balises Google Analytics utilisent un customTask lequel fixe le location et referrer des champs des cookies, puis supprime les cookies.
3. Ainsi, l’URL de la campagne et la chaîne de référence sont conservées pour les balises Google Analytics qui peuvent ne se déclencher que plus tard dans la navigation du site, lorsque les paramètres d’URL d’origine et la chaîne de référence ne sont qu’un souvenir.

Il y a quelques mises en garde à noter.

1. Si vous avez déjà un customTask ensemble, vous devez modifier qu’il inclue le customTask code de ce guide. Voir ceci pour l’inspiration.
2. Il pourrait y avoir un condition de course où la balise Persist Campaign Data se termine après la balise Google Analytics s’est déclenchée, entraînant la création de cookies mais non leur utilisation (puis leur suppression). Un moyen simple d’éviter ce problème consiste à s’assurer que la balise Persist Campaign Data ne se déclenche que si l’utilisateur a ne pas donné son consentement. De cette façon, il ne se déclenchera que si Google Analytics a été bloqué.
3. Les biscuits sont cookies de session ainsi, si l’utilisateur ferme le navigateur puis le rouvre pour continuer la navigation, les données stockées sont perdues.
4. Suivi inter-domaines est quelque chose qui est très probablement perdu si vous retardez le déclenchement de vos balises au-delà de la page de destination – cette solution ne résoudra pas ce problème. Vous pouvez prendre l’ID client du paramètre de l’éditeur de liens, mais puisque vous ne validez pas le paramètre de l’éditeur de liens, les données seraient vulnérables au partage de lien (et tous les utilisateurs qui suivent le lien partagé seraient comptés comme le même utilisateur par Google Analytics) .

2. Poussez l’emplacement d’origine dans dataLayer

Le problème de référencement malveillant est un scénario dans lequel les balises déclenchées sur une application d’une seule page utilisent l’emplacement “virtuel” pour l’attribution de la campagne (manquant souvent les paramètres de campagne d’origine) et donc Google Analytics revient au référent à la place. Il en résulte des sessions où les appels envoyés sur la première page font partie d’un google / cpc session, mais dès que l’utilisateur navigue vers d’autres parties du SPA, la campagne passe à la source de référence, telle que google / organic.

REMARQUE! Veuillez comprendre que ces mesures ne doivent être prises que si le site est un application d’une seule page ou a des composants d’application d’une seule page. Il n’y a pas de mal à installer cela sur un site normal, mais c’est juste du travail supplémentaire et de l’encombrement dans le conteneur.

Pour résoudre ce problème, vous avez besoin des éléments suivants.

Configurer la balise Persist Campaign Data

Créer un nouveau étiqueter avec le Conserver les données de campagne modèle. Cochez la case à côté de Pousser l’emplacement d’origine dans dataLayer et vérifiez que les paramètres sont OK.

Configurez cette balise pour qu’elle se déclenche sur Toutes les pages déclencheur.

Cette balise, lorsqu’elle se déclenche, fait une chose très simple. Il écrit l’URL actuelle dans le dataLayer à l’aide de la clé originalLocation.

Il est important que cette balise ne se déclenche que une fois que lors du chargement initial de la page (d’où le déclencheur Toutes les pages).

Créer la variable de couche de données

Ensuite, créez une variable de couche de données nommée {{Emplacement d’origine}}et réglez-le pour qu’il pointe vers le originalLocation clé. Il est important de définir son Valeur par défaut à {{URL de la page}}.

Les Valeur par défaut c’est tres important. Il est plus que probable qu’une balise Google Analytics se déclenche avant originalLocation est poussé dans dataLayerla variable renvoie simplement l’URL de la page actuelle (qui doit être la même que originalLocation) en cas de survenance d’une telle condition de concurrence.

Mettez à jour vos balises Google Analytics

Maintenant que la balise de modèle se déclenche sur le déclencheur Toutes les pages et que la variable de couche de données est prête, vous devez modifier chacune de vos balises Google Analytics. Le moyen le plus simple de le faire est d’utiliser la variable Paramètres de Google Analytics.

REMARQUE! Il est vital que chaque balise Google Analytics a cette modification. S’il y a même une seule balise qui se déclenche sans le fixe emplacementil est possible que les données de votre campagne soient endommagées.

Vous devez ajouter deux champs à la variable :

Nom de domaine: location
Évaluer: {{Original Location}}

Nom de domaine: page
Évaluer: {{Page Path}}

La valeur de page devrait être celui que vous utilisez actuellement pour vos pages vues virtuelles sur votre application monopage. Il peut s’agir d’une variable de couche de données, d’une variable d’état d’historique ou simplement de l’URL de la page actuelle ou du chemin de la page actuelle, comme dans l’exemple ci-dessus.

Ces deux champs doivent être définis dans vos balises.

Comment ça fonctionne

Une fois que vous l’avez configuré, voici ce qui se passe.

1. Lorsque l’utilisateur arrive sur la page, l’URL de la page est stockée dans le originalLocation Variable de couche de données.
2. Lorsqu’une balise Google Analytics se déclenche, elle prend le emplacement champ de cette variable. C’est parce que le emplacement champ est utilisé pour l’attribution de la campagne, et la page de destination contient tous ces paramètres.
3. Les page est défini de sorte qu’un chemin de page virtuel puisse être défini pour les vues de page de votre application à page unique.

Ainsi en envoyant toujours l’URL du chargement initial de la page comme valeur du emplacement domaine, le problème de renvoi escroc est résolu.

Résumé

Le modèle Persist Campaign Data résout deux problèmes liés au suivi des campagnes dans Google Analytics.

1. Suivi Google Analytics retardé / différé, où les premiers hits de la session sont envoyés après l’utilisateur a quitté la page de destination.
2. Suivi d’application sur une seule page, où les sessions de campagne sont attribuées de manière incorrecte à la chaîne de référence plutôt qu’aux paramètres de l’URL.

Vous pouvez, bien sûr, utiliser les fonctionnalités pour d’autres choses également. Les paramètres de campagne persistants peuvent avoir des utilisations au-delà du suivi de Google Analytics, et l’identification de l’URL du premier chargement de page d’un SPA pourrait également être utilisée pour mieux comprendre les modèles de navigation.

Comme toujours, j’ai hâte de vous entendre dans les commentaires. Voyez-vous des problèmes avec l’une ou l’autre approche? Avez-vous des suggestions pour améliorer le modèle ou sa mise en œuvre ?