Deux façons de conserver les données via Google Tag Manager

Le web est sans état. Il est fondamentalement aveugle à votre passé et il fait un mauvais travail pour prédire ce que vous pourriez faire à l’avenir. Lorsque vous accédez à un site Web, le navigateur demande la page au serveur Web, puis procède à son rendu pour vous. Il s’agit d’un processus clinique détaché, et tout personnalisé ou alors avec état le transfert de données est laissé à la sophistication de votre serveur Web.

L’apatridie a des implications pour nous, soucieux de l’analyse Web et de la mesure de nos visiteurs. Dans Google Tag Manager, c’est un éléphant omniprésent dans la pièce. En effet, beaucoup souffrent de ne pas pouvoir déclencher des balises, par exemple retour visiteurs, ou après cinq pages vues, ou si le source primaire de la session était AdWords. GTM est (pour l’instant) aveugle à ce type de pensée, car il s’agit simplement d’une machine JavaScript fonctionnant dans un environnement sans état. Toute notion de Etat doit être injecté manuellement dans la machine.

Et comment est-ce fait? Biscuits et le API de stockage Web.

Cookies du navigateur

Les cookies dans le navigateur sont le moyen de facto de conserver des informations sur le Web. Ils existent depuis longtemps (plus de 20 ans !) et ils sont pris en charge par à peu près tous les navigateurs – hérités et modernes. Pour un rappel sur ce que sont les cookies et leur fonctionnement, consultez cet article de Wikipedia. Les caractéristiques les plus pertinentes des cookies de navigateur sont :

1. Limitation de taille de 4 Ko (par cookie)

2. Non crypté dans une seule chaîne, stocké dans document.cookie

3. Envoyé au serveur avec chaque requête HTTP

4. Peut être défini avec une date d’expiration

La limitation de taille devient rapidement un problème avec les charges utiles volumineuses, et le fait qu’elles soient envoyées au serveur non chiffrées à chaque requête peut être un obstacle pour ceux qui ont des problèmes de sécurité.

API de stockage Web

L’API Web Storage est une innovation plus récente, et cela est représenté par le manque de prise en charge d’Internet Explorer 7 et des versions antérieures (mais peu importe !). L’API a deux interfaces : localStorage et sessionStorage. La principale différence est que ce dernier persiste pendant la durée de la session du navigateur (c’est-à-dire qu’il est vidé lorsque l’instance du navigateur est fermée), et le premier persiste indéfiniment.

Les fonctionnalités de l’API de stockage Web sont :

1. Ne peut être lu que côté client dans le navigateur. Aucune donnée n’est envoyée au serveur.

2. Stocke un maximum de 5 Mo par domaine

3. Stocke les données dans une table de hachage, ce qui signifie que vous pouvez effectuer des requêtes exactes sans avoir à analyser les données

Fondamentalement, l’API Web Storage est une évolution logique de la persistance, prenant le meilleur des cookies et ajoutant de meilleures fonctionnalités d’accès et de gestion des données. Le gros inconvénient est le manque de communication côté serveur, donc si vous comptez sur les cookies pour transmettre des informations au serveur Web, la migration vers l’API Web Storage ne serait pas logique à moins que vous n’envoyiez manuellement les données au serveur (par exemple via POST demande).

Cookies et GTM

Google Tag Manager, heureusement, nous fournit déjà une interface pour interroger les valeurs des cookies : la 1st Party Cookie Variable. Lorsque vous définissez la variable sur un nom de cookie, elle renverra toujours la valeur stockée dans ce cookie particulier. Ceci est d’une grande aide, car vous n’avez pas besoin de passer par le processus plutôt fastidieux d’analyse de l’intégralité de la chaîne de cookies pour la paire nom-valeur que vous recherchez.

Cependant, la configuration d’un cookie doit toujours être effectuée manuellement. Le moyen le plus simple de définir un cookie consiste à ajouter le code suivant dans une balise HTML personnalisée :

document.cookie = 'cookieName=cookieValue'; 

Cela créerait un cookie avec le nom cookieName et la valeur cookieValeur. Cependant, l’utilisation de ce code seul entraînerait l’expiration du cookie à la fin de la session de navigateur (c’est-à-dire lorsque le navigateur est fermé), et le cookie serait défini sur le chemin et le courant domaine seul. La combinaison chemin et domaine est particulièrement importante, car le cookie ne serait accessible que via la page sur laquelle il a été défini.

C’est pourquoi il est d’usage de créer une fonction d’assistance, avec laquelle vous pouvez fournir certains paramètres importants. Pour créer ce type d’assistant dans le contexte de GTM, je suggère d’utiliser un Variable JavaScript personnalisée nommé {{JS – setCookie}}:

function() {   return function(name, value, ms, path, domain) {     if (!name || !value) {       return;     }     var d;     var cpath = path ? '; path=' + path : '';     var cdomain = domain ? '; domain=' + domain : '';     var expires = '';     if (ms) {       d = new Date();       d.setTime(d.getTime() + ms);       expires = '; expires=' + d.toUTCString();     }     document.cookie = name + "=" + value + expires + cpath + cdomain;   } } 

Cette petite fonction pratique en fait Retour une autre fonction, qui prend un certain nombre de paramètres :

• Nom: Obligatoire. Le nom du cookie.

• évaluer: Obligatoire. Valeur pour le cookie.

• ms : Délai d’expiration du cookie en millisecondes. S’il n’est pas défini, la valeur par défaut est Session.

• path : Chemin du cookie. S’il n’est pas défini, la valeur par défaut est le chemin actuel.

• domaine : domaine du cookie. S’il n’est pas défini, la valeur par défaut est le domaine actuel.

Pour utiliser cette variable dans un script, vous devez utiliser la syntaxe suivante :

{{JS - setCookie}}('session', 'true', 1800000, '/', 'simoahava.com'); 

Cela créerait un cookie avec le nom session et la valeur vraiqui persiste pendant 30 minuteset est écrit sur la page racine du domaine racine.

Si vous voulez laisser un paramètre de côté, vous devrez le remplacer par undefined, si vous souhaitez toujours envoyer l’un de ces derniers paramètres. Par example:

{{JS - setCookie}}('session', 'true', undefined, undefined, 'simoahava.com'); 

Définirait un cookie avec le nom sessionévaluer vraiqui serait un cookie de session, écrit sur la page actuelle du domaine racine.

Phew! C’est une bouchée de code. Mais il fait bien son travail. Combinez cela avec l’excellente 1st Party Cookie Variable, et vous avez réussi à créer un cookie setter/getter agréable et pratique.

API de stockage Web et GTM

Vous pouvez créer un ensemble sophistiqué de variables JavaScript personnalisées pour localStorage et sessionStorage aussi, mais pourquoi s’embêter ? Ils sont très simples à interagir avec.

Pour définir une paire clé-valeur dans le stockage, vous pouvez utiliser la syntaxe suivante :

if (window['Storage']) {   // localStorage persists indefinitely   localStorage.setItem('session', 'true');    // sessionStorage persists until the browser is closed   sessionStorage.setItem('session', 'true'); } else {   // Fallback for when the browser doesn't support Web Storage API   {{JS - setCookie}}('session', 'true'); } 

Tout d’abord, vous devez vérifier si le navigateur prend en charge l’API Web Storage. C’est juste un simple if...else bloc. Vous voyez ce que j’ai fait avec le repli ? C’est exact! j’ai utilisé le {{JS – setCookie}} méthode que nous venons de créer ! Quelle belle suite.

Web Storage accepte uniquement les chaînes en tant que valeurs, vous devez donc vous assurer que tout ce que vous stockez peut être converti en toute sécurité en une chaîne. Ne vous inquiétez pas, l’API de stockage effectue le casting pour vous, si vous ne parvenez pas à enregistrer explicitement un type String.

Malheureusement, pour l’instant, GTM n’a pas de variable pratique que vous pouvez utiliser pour récupérer des éléments du stockage (j’espère que cela changera bientôt !). Mais pour récupérer une valeur, c’est aussi simple que d’en définir une :

if (window['Storage']) {   var localSession = localStorage.getItem('session');   var sessionSession = sessionStorage.getItem('session'); } 

C’est vrai, c’est le getItem() méthode de l’API qui vous permet d’accéder aux clés stockées. Il revient null si l’article n’est pas trouvé.

Et c’est ainsi que vous roulez avec l’API Web Storage. Vous vous débrouillez avec BEAUCOUP moins de code et la recherche de valeur est bien plus intuitive qu’avec les cookies, bien que GTM vous enlève une grande partie du fardeau avec son impressionnante variable de cookie de première partie.

Résumé

Pour de nombreuses interactions, la persistance des données dans le navigateur est très importante. Cependant, toute la persistance ne doit pas être laissée au client, car les serveurs font un travail bien meilleur et plus robuste de stockage des données basées sur l’utilisateur et l’utilisation. C’est pourquoi Google Analytics est passé des calculs côté client (ga.js et versions antérieures) aux algorithmes côté serveur (Universal Analytics). Et c’est pourquoi si vous avez vraiment des besoins urgents et critiques pour conserver des informations, vous voudrez peut-être discuter avec vos développeurs de la possibilité de les stocker dans un magasin de données ou une base de données appropriés, en exposant les informations dans le dataLayer quand et où cela est pertinent.

Mais pour la persistance simple et étendue à la session, les deux méthodes décrites dans ce guide devraient être très utiles. Je recommande fortement d’utiliser l’API Web Storage, mais malheureusement, vous devrez peut-être introduire une solution de repli avec les cookies du navigateur, car de nombreux imbéciles utilisent encore des navigateurs obsolètes.