gtag.js

Trois choses.

Elle charge la configuration associée à un identifiant de mesure.

Elle expose une fonction unique pour envoyer des événements, des conversions et des paramètres de consentement.

Elle gère la transmission vers plusieurs destinations à partir d’un même appel, ce qui évite de dupliquer le code par produit.

Les deux coexistent et ne servent pas la même chose.

gtag.js est une bibliothèque posée dans le code du site. Toute modification demande une intervention technique et un déploiement.

Google Tag Manager est un gestionnaire : une seule balise posée, et le reste se configure depuis une interface sans toucher au site. Le fonctionnement est décrit côté conteneur GTM.

Le gestionnaire charge d’ailleurs gtag.js en interne pour les produits Google. Les deux ne s’opposent donc pas techniquement : le second automatise l’usage du premier.

Deux situations penchent pour gtag.js seul.

Un site à mesure très simple, une page vue et une conversion, où le gestionnaire ajoute de la complexité sans bénéfice.

Une application où la mesure est écrite dans le code par les développeurs, avec un plan de marquage tenu côté technique.

Dans tous les autres cas, le gestionnaire est préférable : il permet de corriger une mesure sans attendre un déploiement, ce qui est la contrainte la plus coûteuse en pratique.

Poser gtag.js dans le code et déclarer la même mesure dans le gestionnaire.

Les deux s’exécutent, chaque événement part deux fois, et les conversions doublent. C’est le cas de double comptage le plus fréquent après une migration.

Le contrôle se fait dans DebugView, où l’événement apparaît en double, et par le rapprochement avec les commandes réellement reçues.