X

#GTMTips : envoyer des requêtes Google Analytics à un point de terminaison personnalisé


Lorsque vous utilisez Google Analytics sur le Web, vous implémentez très probablement l’un des tags analytics.js, global site tag (gtag.js) ou Universal Analytics via Google Tag Manager.

Ces bibliothèques finissent toutes par faire la même chose : compiler une requête HTTP riche en charge utile vers un point de terminaison à https://www.google-analytics.com.

Que se passe-t-il si vous souhaitez que les bibliothèques JavaScript fassent leur travail, mais qu’au lieu d’envoyer les données aux serveurs de Google, vous les envoyez vers un nouveau point de terminaison personnalisé ?

Peut-être utilisez-vous déjà la nouvelle fonctionnalité de Google Tag Manager Balisage côté serveur et vous souhaitez rediriger la collecte de données Universal Analytics de votre site via votre nouveau proxy côté serveur ?

Ou peut-être que vous utilisez Snowplow Analytics et que vous souhaitez également tirer parti de sa capacité à digérer les charges utiles de Google Analytics.

Une récente mise à jour de gtag.js et Gestionnaire de balises Google a rendu beaucoup plus facile la redirection de la charge utile. Dans cet article #GTMTips, nous allons jeter un œil à ce nouveau champ et à son fonctionnement.


X


La newsletter Mijoter

Abonnez-vous à la newsletter Simmer pour recevoir les dernières nouvelles et le contenu de Simo Ahava dans votre boîte de réception !

Astuce 116 : Redirigez la charge utile de Google Analytics vers un point de terminaison personnalisé

Dans Google Tag Manager, le Analytique universelle modèle ainsi que le Variable Paramètres de Google Analytics avoir un nouveau réglage sous Configuration avancée.

Le Définir l’URL de transport paramètre développe un champ de texte dans lequel vous pouvez maintenant taper un URL de base chaîne.

Un valide URL de base est une chaîne d’URL qui commence par http:// ou https:// et fait pas terminer par /.

En règle générale, vous n’auriez ici qu’un nom d’hôte de base, en supposant que votre domaine de collecteur est hébergé sur un sous-domaine mappé spécifiquement pour la collecte des données. Un exemple serait ceci :

https://collector.simoahava.com

Il est également possible d’intégrer le tracker dans un chemin, ce serait donc aussi bien qu’une URL de base :

https://www.simoahava.com/collector

Quelle que soit la façon dont vous le construisez, la charge utile sera envoyée au URL de base + /collect. Une requête pourrait donc ressembler à ceci :

https://collector.simoahava.com/collect?v=1&t=pageview&tid=UA-12345-1...

Parfois, si vous avez activé les fonctionnalités de publicité, le point de terminaison peut être URL de base + /r/collect. Dans certains cas, le point final peut également être URL de base + /j/collectvous devez donc configurer votre serveur ou service pour en tenir compte lors de la configuration des API du collecteur.

NOTE! Dans un conteneur Serveur, le extractEventsFromMpv1 L’API intercepte automatiquement toutes les variations de chemin possibles de /collectvous n’avez donc rien à configurer manuellement si vous créez votre propre client de balisage côté serveur personnalisé.

gtag.js

Le gtag.js bibliothèque prend également en charge cette fonctionnalité.

Dans gtag.js, le champ est nommé transport_urlet il est défini dans la configuration du tracker :

gtag('config', '<MEASUREMENT_ID>', {
  transport_url: 'https://collector.simoahava.com'
});

Tous les hits qui utilisent ce tracker enverront désormais leurs charges utiles à https://collector.simoahava.com au lieu du point final représenté par le MEASUREMENT_ID.

analytics.js

Si vous avez une ligne analytics.js implémentation, il existe un champ nommé transportUrl que vous pourrait utiliser à cet effet :

ga('create', 'UA-12345-1', {name: 'ss', transportUrl: 'https://collector.simoahava.com'});

Cependant, c’est un peu une relique et n’a pas de soutien officiel à l’avenir. Le transportUrl ne traite pas, par exemple, les chemins personnalisés (/r/, /j/) correctement, ce qui peut entraîner des problèmes lors de l’utilisation d’intégrations d’annonces dans votre point de terminaison côté serveur.

Il n’y a pas de mot officiel si analytics.js sera un jour corrigé pour avoir la parité des fonctionnalités avec transportUrldonc votre meilleure option pour le moment est d’utiliser soit gtag.js ou Gestionnaire de balises Google.

Résumé

Avec l’introduction de Balisage côté serveur dans Google Tag Manager, avoir un moyen de rediriger l’appel Google Analytics des serveurs GA vers votre propre point de terminaison personnalisé est une nécessité. C’est pourquoi la fonctionnalité d’URL de transport a été publiée, et elle devrait beaucoup aider à créer votre propre flux d’événements vers votre conteneur côté serveur.

Cependant, Universal Analytics existe depuis si longtemps que le format de charge utile (protocole de mesure) qu’il utilise a été intégré dans d’innombrables pipelines d’analyse. C’est un schéma si familier que si je devais créer un pipeline personnalisé pour la collecte de données d’analyse, j’inclurais certainement un processeur pour le format du protocole de mesure.

Ce paramètre devrait s’avérer utile pour toute personne travaillant avec une configuration de balisage côté serveur, où les appels sont transmis par proxy via un conteneur Google Tag Manager Server plutôt qu’envoyés directement aux serveurs de Google. Ou peut-être avez-vous créé quelque chose qui intègre la charge utile GA directement dans BigQuery, ou peut-être utilisez-vous Snowplow Analytics ; Quoi qu’il en soit, cette fonctionnalité vous facilitera un peu la vie, au cas où vous souhaiteriez déléguer la fonctionnalité de suivi JavaScript aux propres bibliothèques de Google.