Comment GTM et gtag utilisent les Service Workers pour l’analyse des données
En septembre 2024, Google a introduit l’utilisation des Service Workers dans Google Tag Manager (GTM) pour améliorer les performances et la fiabilité des mesures:
| "Google Tag Manager peut utiliser un service worker pour améliorer les performances et la fiabilité des mesures. Pour vous assurer que le service worker se charge correctement, consultez les consignes sur la Content Security Policy. |
Puis, en mars 2025, Google a annoncé une extension de cette fonctionnalité:
| "La balise Google utilise désormais des service workers, lorsqu’ils sont disponibles, pour envoyer des données à Tag Manager côté serveur. Cela améliore les performances et la fiabilité des mesures." |
Cet article explique comment GTM et gtag gèrent les Service Workers, ce qu’est un Service Worker, comment la communication fonctionne entre eux, et pourquoi certaines requêtes analytics peuvent ne pas apparaître dans l’onglet Network de DevTools.
Qu’est-ce que les Service Workers?
Les Service Workers sont des scripts d’arrière-plan qui fonctionnent séparément du thread principal d’un site web. Ils permettent des opérations comme la mise en cache, le support hors ligne et les requêtes réseau en arrière-plan, sans bloquer l’interface utilisateur.
Dans le contexte de GTM et gtag, les Service Workers servent à déplacer la tâche d’envoi des données de mesure depuis la page web, par exemple les hits GA4 ou Ads. Cela rend le suivi plus rapide et plus stable, même pendant les événements de déchargement de page ou sur les réseaux lents. Dans ce contexte, le Service Worker ne stocke pas les événements pour les envoyer plus tard.
Comment GTM et gtag utilisent les Service Workers
Deux types de Service Workers peuvent être enregistrés, selon votre configuration:
1. Service Worker depuis le domaine first-party de votre server-side GTM (sGTM).
Utilisé pour les requêtes GA4 envoyées aux conteneurs côté serveur.
2. Service Worker depuis le domaine googletagmanager.com.
Utilisé surtout par les produits Ads, comme Google Ads et Floodlight, pour les requêtes form-data et user-data.
Les deux versions suivent un modèle de communication similaire avec plusieurs éléments du navigateur.
Flux de communication
Quand gtag ou GTM s’exécute, il crée une iframe invisible (src=”about:blank”). Cette iframe charge ensuite une autre iframe, sw_iframe.html. Cette deuxième iframe installe le script du Service Worker (sw.js).
Ces éléments communiquent avec l’API postMessage() du navigateur pour envoyer les informations, et avec le message listener pour les recevoir. Cela forme le flux suivant:
gtag/GTM ↔ iframe (about:blank) ↔ iframe (sw_iframe.html) ↔ sw.js (Service Worker)Ce pont permet à gtag ou GTM, qui s’exécute sur la page principale, de transmettre les données d’événement au Service Worker. Le Service Worker décide ensuite comment et quand les envoyer.
Si vous inspectez la page du site web dans l’onglet Elements de DevTools, vous pouvez voir les iframes.
Démonstration réelle des messages échangés entre l’iframe et le Service Worker:
- Service Worker depuis le domaine first-party de server-side GTM (sGTM).
- Service Worker depuis le domaine googletagmanager.com.
1. Service Worker chargé depuis le domaine first-party de sGTM
Ce Service Worker est utilisé pour les requêtes GA4 envoyées à un conteneur server-side GTM.
Le script GA4 gtag (G-{Measurement ID}, etc.) se charge de transmettre les événements au Service Worker.
Il vérifie si un événement doit être envoyé via le Service Worker selon plusieurs conditions:
- L’événement n’est pas envoyé directement vers analytics.google.com/g/collect ou www.google-analytics.com/g/collect, par exemple avec le paramètre server_container_url configuré.
- La page n’est pas en cours de déchargement, avec l’événement beforeunload. Pendant le déchargement, certaines requêtes comme l’événement user_engagement passent le Service Worker.
- Le navigateur n’est pas un environnement restreint, comme WebView, Google App sur iOS, ou les navigateurs intégrés à Facebook et Messenger.
- Plus précisément, il vérifie que le Browser User Agent ne contient aucune des chaînes suivantes: "; wv" OU "FBAN" OU "FBAV" OU (("GSA" OU "GoogleApp") ET ("iPhone" OU "iPad")).
- Le Service Worker est actif et prêt, avec l’état 2.
- Ce contrôle est effectué par la méthode .delegate(), que vous pouvez voir ici.
Si toutes les conditions sont remplies, l’événement est envoyé via le Service Worker. Sinon, il est envoyé directement depuis la page principale avec fetch, XHR, sendBeacon ou Image, dans cet ordre.
Si les deux premières conditions sont remplies, le paramètre richsstsse est ajouté à l’URL de l’événement (vous pouvez en savoir plus à ce sujet). Ce paramètre permet au navigateur de traiter la réponse, par exemple, d’envoyer les requêtes demandées par sGTM pour la synchronisation des cookies tiers.
2. Service Worker chargé depuis le domaine googletagmanager.com
Ce Service Worker semble gérer les événements des produits Google Ads et Floodlight.
Certaines requêtes passent par lui, par exemple:
- Google Ads User-Provided Event, avec des requêtes vers https://www.google.com/ccm/form-data/{Conversion ID}/... et https://www.google.com/pagead/form-data/{Conversion ID}/....
- Auto-captured User-data Event, avec des requêtes vers https://www.google.com/ccm/form-data/{Conversion ID}/... uniquement.
Le script gtag du produit Ads chargé sur la page (AW-{Conversion ID}, DC-{Floodlight Config ID}, etc.) se charge de transmettre les événements au Service Worker.
Les conditions d’utilisation de ce Service Worker sont similaires:
- Le tag est configuré pour envoyer des données utilisateur et le paramètre interne send_user_data_hit est l’un des suivants:
- user_data_web: utilisé par Auto-captured User-data Event
- user_data_lead: utilisé par Google Ads User-Provided Event
- La page n’est pas en cours de déchargement, avec l’événement beforeunload.
- Le Service Worker est actif et prêt, avec l’état 2.
- Ce contrôle est effectué par la méthode .delegate(), que vous pouvez voir ici.
Si l’une de ces conditions n’est pas remplie, le hit est envoyé depuis la page principale comme d’habitude.
La méthode .delegate
gtag et GTM incluent tous les deux une méthode appelée .delegate. Elle effectue le dernier contrôle avant de décider si l’événement doit être envoyé via un Service Worker ou depuis la page principale.
La logique est la suivante:
k.delegate = function (a, b, c) {
this.getState() !== 2
? (this.H.C( // Path 1: Not Ready - Sends event from main page.
this.C,
{
state: this.getState(),
hg: this.initTime,
ng: Math.round(Ab()) - this.initTime
},
void 0,
a.commandType
),
c({ // Call the failure callback
failureType: this.C
}))
: this.N.wo(a, b, c); // Path 2: Ready - Sends events from Service Worker.
};
Quand le state est 2, la requête est envoyée via le Service Worker. Sinon, elle est envoyée depuis la page principale.
Le Service Worker et la page principale échangent des messages heartbeat à intervalle régulier, actuellement toutes les 5 secondes, pour garder ce state à jour. La variable state représente l’état de disponibilité du Service Worker:
| Etat | Signification |
|---|---|
| 0 | État initial au chargement de la page |
| 1 | Tentative d’établissement de la communication entre la page principale et le Service Worker |
| 2 | Le Service Worker est prêt et la connexion avec la page principale a réussi |
| 3 | Nouvelle tentative après une erreur |
| 4 | Erreur fatale, échec ou canal de communication fermé |
Comment vérifier si les Service Workers sont utilisés
Vous pouvez vérifier l’utilisation des Service Workers de plusieurs façons.
1. Onglet Network de DevTools
Filtrez les requêtes avec sw.js ou sw_iframe.html.
Note:
Service Worker chargé depuis le domaine first-party de sGTM.
Service Worker chargé depuis le domaine googletagmanager.com.
2. Onglet Application de DevTools
Ouvrez DevTools, allez dans l’onglet Application, puis Service Workers. Cliquez sur See all registrations et cherchez votre domaine.
- Si vous utilisez GA4 pour envoyer des données à sGTM, vous verrez le Service Worker servi depuis le domaine first-party de votre sGTM.
Si vous utilisez des produits Ads de Google, vous verrez le Service Worker servi depuis googletagmanager.com.
3. Onglet Network de DevTools
Les requêtes gérées par un Service Worker affichent une icône d’engrenage à côté de l’URL. Ces requêtes représentent les hits envoyés depuis le processus d’arrière-plan, et non depuis la page principale.
Pourquoi vous ne voyez pas certains événements dans l’onglet Network
Si vos événements GA4 ou Ads n’apparaissent pas dans l’onglet Network de la page principale, ils sont probablement envoyés par le Service Worker. Ils apparaîtront tout de même dans la fenêtre Google Tag Manager's preview and debug mode, et vous pourrez les inspecter à cet endroit.
- Suivez les étapes indiquées ici.
- Après avoir trouvé le Service Worker souhaité, cliquez sur Inspect pour ouvrir sa propre fenêtre DevTools.
- Allez dans son onglet Network. Vos requêtes GA4 ou Ads manquantes y apparaîtront.
Vous pouvez voir jusqu’à deux Service Workers: un pour votre domaine sGTM et un autre pour le domaine de Google. Chacun gère différents types d’événements, comme expliqué plus haut.
Conclusion
L’intégration progressive des Service Workers dans GTM et gtag montre que Google avance vers une façon plus stable d’envoyer et de gérer les événements. En déplaçant l’envoi des événements vers des scripts d’arrière-plan, Google améliore les performances, la fiabilité et la précision de la collecte de données, surtout dans des cas comme les départs rapides de page ou les connexions instables. Cela signifie aussi que certaines requêtes n’apparaîtront plus dans l’onglet Network classique.
Pour les spécialistes de l’analytics digital, cela signifie:
- Ne partez pas du principe que des hits absents dans l’onglet Network indiquent un problème de suivi.
- Vérifiez l’activité des Service Workers avant de déboguer.
Comme cette fonctionnalité continue d’évoluer, il est important de comprendre comment gtag et GTM utilisent les Service Workers pour déboguer correctement et garder des données fiables.
Commentaires