Tag Management System : envisager le server-side ?

Cet article date de 2017, si vous vous intéressez spécifiquement à Google Tag Manager (GTM) Server Side, vous pouvez consulter notre article : GTM Server Side – L’évolution naturelle pour votre tagging ?

Pour compléter votre lecture, vous pouvez revoir notre webinar du 15 décembre dernier : GTM Server-Side : vers un tracking hybride client-serveur.

Apparus principalement depuis 2010, les TMS (Tag Management System) permettent une gestion centralisée de l’ensemble des tags d’un site ou d’une application.

Le principe ? Après intégration de la solution, les tags peuvent être paramétrés depuis une interface web. Une grande partie des tâches d’implémentation et de gestion des tags est ainsi effectuée directement par les équipes “métier”.

Comme montré par le baromètre des solutions de web analyse et tag management, au fil des années, ces solutions se sont démocratisées et le marché a gagné en maturité :

A ce jour, on distingue deux types d’éditeurs de solutions de TMS :

• Les solutions “cœur de métier TMS” ou “Premium”, à l’origine des Pure Players du TMS dont l’offre de service s’est étendue et enrichie. Par exemple : Ensighten, TagCommander, Tealium, …
• Les solutions “TMS par extension”, proposées par certains éditeurs en complément de solutions “utilisatrices de tags”, dans une logique de suite intégrée. Par exemple : Google Tag Manager, Adobe Dynamic Tag Management, Eulerian Tag Master, IBM Digital Data Exchange, Signal Tag Management, Qubit, …

Un panorama aussi large implique que toutes les offres de TMS du marché ne se valent pas, notamment en termes de capacités technico-fonctionnelles.

Une fonctionnalité, encore assez méconnue et capable de répondre de manière efficace à des besoins d’optimisation de la qualité des données comportementales collectées par nos clients, est le déclenchement des tags avec une logique “Server-Side”.

Le server-side : qu’est ce que c’est ?

Les outils de Tag Management reposent sur un même principe : les tags paramétrés (via l’interface du TMS) se déclenchent selon des règles, s’appuyant sur des variables présentes dans le datalayer du site (ex : un type de page) ou ailleurs (ex : valeur d’un cookie ou paramètre d’une URL). C’est à ce moment qu’on distingue deux architectures (Client-Side vs. Server-Side).

En Client-Side :

Les interactions générées par un visiteur avec un site Internet ou une application génèrent des requêtes depuis son navigateur vers le serveur de l’outil de TMS. A l’arrivée sur le site A, le navigateur de l’utilisateur envoie une requête sur le serveur de l’outil de TMS, qui, en réponse, télécharge « en cache » les règles d’exécution des tags pour la page concernée. La majorité des outils de TMS repose, par défaut, sur ce type d’architecture.
Ce modèle peut théoriquement poser des limites :

• L’utilisateur final télécharge des règles qui ne sont pas forcément utilisées. Ceci peut engendrer des problèmes sur le temps de chargement du site
• Il est nécessaire d’implémenter un container sur le support digital « tracké ». Or, il est souvent compliqué d’implémenter un container sur un environnement (site ou application) dont on n’est pas propriétaire

En Server-Side :

Un TMS “classique” charge les tags sur le navigateur du visiteur, et ces tags vont générer des requêtes (qu’on appelle des hits) aux serveurs de leur solution. Un TMS qui fonctionne en server-side va déporter ce travail vers le serveur de l’éditeur du TMS.

Ce type d’architecture est proposé en option par la plupart des éditeurs “cœur de métier” comme TagCommander, Tealium ou encore Ensighten.

Le server-side : pour qui ?

L’option server-side n’est pas à déployer systématiquement, mais elle est à envisager dans différents cas, suivant le support à tracker ou les problèmes actuellement rencontrés.

Les applications mobiles

En situation de mobilité, le device mobile n’étant pas connecté en permanence, l’application doit pouvoir stocker les données (hits) pour pouvoir les envoyer par paquets lorsqu’elle se reconnecte.

Les sites web

Deux problématiques sont souvent à l’origine de la mise en place d’une architecture server-side :

1. Un écart important des données transactionnelles remontées, entre l’outil d’analytics et le back-office
2. Une problématique de performance en raison du nombre de tags embarqués en client-side trop important.

Toutefois, il convient de prendre en compte plusieurs problématiques, notamment :

• Tous les tags ne sont pas compatibles avec le server-side (ex : certaines solutions médias basées sur des cookies third-party, les solutions d’A/B testing, …)
• Le déploiement technique ainsi que les phases de recette sont plus complexes

En conclusion, un server-side au cas par cas

Le passage en server-side doit s’opérer en prenant en compte les avantages et inconvénients de chaque solution, pour déterminer laquelle sera la plus adaptée au client.