Avec les variables asynchrones récemment publiées dans Google Tag Manager côté serveur, il est temps d’approfondir flux d’enrichissement de données en utilisant une autre communiqué de l’équipe Google.
* roulement de tambour *
Nous avons une nouvelle API Google Cloud Platform !
C’est rapide. C’est élégant. C’est beau. C’est Firestore!
Firestore est un NoSQL, transactionnelet évolutif base de données qui offre des opérations d’écriture/lecture et de synchronisation des données en temps quasi réel.
En pratique, c’est un génial moyen d’enrichir et d’élargir les données que vous faites transiter par votre conteneur Serveur.
Qu’est-ce que Firestore
Firestore stocke les données dans documentschacun contenu dans un collection.
Les documents stockent des données à l’aide de types de données familiers, tels que cordes, Nombres, objets complexeset même sous-collections pour des configurations plus hiérarchiques.
Lors de l’interrogation des données, vous pouvez soit référencer directement un document par son chemin (par exemple order_history/416cda47-cb46-435c-9c9a-15527d76343f), ou tu peux mettre en doute la collection pour récupérer tous les documents qui correspondent à la requête (par exemple iso_time == "2022-02-10T09:21:27.718Z").
En tant que tel, Firestore a une grande utilité pour élargissement les flux de données dans le conteneur Serveur.
La requête entrante peut inclure une clé, telle que identifiant de transactionet cette clé peut ensuite être utilisée pour interroger le Firestore afin d’obtenir des données supplémentaires.
Grâce aux nouvelles variables asynchrones, tout cela peut être fait assez facilement (voir ci-dessous pour des exemples).
La nouvelle variable de recherche Firestore
Pour faciliter lire Données Firestore, il y a un nouveau Recherche Firestore variable dans Google Tag Manager côté serveur.
Cette variable vous permet d’extraire la valeur d’un clé/domaine dans un Firestore document.
Type de recherche
Les Type de recherche précise comment le bon document est récupéré. Si vous vous en souvenez, Firestore imbrique toutes les informations pertinentes dans un documentqui est hébergé dans un collection.
Vous pouvez récupérer le document directement en utilisant le Chemin du documentou vous pouvez rechercher le document avec Chemin de collecte et requête.
Spécifier le chemin du document est la méthode la plus rapide, car il s’agit d’une recherche directe pour récupérer un seul document.
Le chemin du document ressemble généralement à ceci :
collection_name/document_name
Par exemple, pour récupérer le premier document dans la capture d’écran ci-dessus, je spécifierais ceci comme chemin du document :
order_history/416cda47-cb46-435c-9c9a-15527d76343f
Alternativement, si vous ne pouvez pas accéder directement au document avec le chemin, vous pouvez également mettre en doute il. Vous devez d’abord fournir un chemin d’accès à la collection contenant le document. Ensuite, vous pouvez ajouter un ou plusieurs condition de requête en utilisant des clés dont vous savez qu’elles existent dans le document.
La requête ci-dessus rechercherait des documents intégrés dans le user_database collection. La variable récupèrerait le première document qui a le user_id champ défini sur tout ce qui est contenu dans le GTM {{User ID}} variable (peut être quelque chose de la demande entrante, par exemple) et a le user_status champ défini sur autre chose que inactive.
Étant donné que Firestore indexe les documents par défaut, les performances des requêtes sont proportionnelles à la taille du ensemble de résultats et non l’ensemble de données interrogé. Ainsi, le nombre de documents dans la collection n’a pas d’importance pour les performances de la requête, mais la largeur de votre requête est importante (c’est-à-dire le nombre de résultats qu’elle récupère).
La variable Firestore utilise le premier document qui correspond à la requête pour rendre la clé (voir ci-dessous). C’est quelque chose à considérer si votre requête est trop générale et renvoie plusieurs documents (non liés).
Chemin de la clé
En supposant que la recherche renvoie un document, le Chemin de la clé spécifie ensuite la valeur à récupérer.
Voici un exemple factice de document Firestore :
Pour aller chercher le transaction_idje définirais cela comme le Chemin de la clé. Pour aller chercher le value, je définirais cela. Pour récupérer l’ID du premier élément, je pourrais utiliser items.0.item_idetc.
Si aucune valeur n’est trouvée, le Valeur par défaut est renvoyé s’il est défini, ou undefined autrement.
Remplacer l’ID du projet
Par défaut, la variable recherche les collections et les documents dans le même projet Google Cloud qui exécute le serveur GTM.
Note! Cela nécessite que l’ID du projet soit défini dans le
GOOGLE_CLOUD_PROJECTvariable d’environnement du service cloud. Cette opération est effectuée automatiquement dans le déploiement d’App Engine. Si vous exécutez Cloud Run ou une autre pile, vous devez ajouter la variable d’environnement au service ou alors vous pouvez simplement saisir l’ID du projet dans le champ ID du projet.
Si vous voulez vous pouvez remplacer l’ID du projet et fournissez un autre ID de projet Google Cloud où la collection est stockée.
Pour ce faire, développez Plus de réglages dans l’étiquette et vérifiez Remplacer l’ID du projet.
Si vous fournissez un autre ID de projet, vous devez ajouter votre projet de serveur GTM compte de service au projet Firestore via IAM.
Si vous exécutez votre conteneur sur App Engine, localisez le Compte de service par défaut App Engine dans l’IAM de votre projet GTM Server et ajoutez-le en tant que nouveau rôle dans votre projet Firestore.
Si votre conteneur s’exécute sur Cloud Run, utilisez la Compte de service par défaut de Compute Engine au lieu.
Attribuer au compte de service un rôle de Utilisateur du magasin de données cloud pour donner au serveur GTM l’accès au Firestore de l’autre projet.
Exemple de procédure pas à pas
Dans cet exemple fictif, je vais vous montrer comment utiliser Firestore pour élargir un entrant Google Analytics 4 flux de données.
Comme vous pouvez le voir sur le flux de processus immaculé ci-dessus, il y a plusieurs pièces mobiles dans cette configuration.
- Tout d’abord, l’utilisateur fait un achat sur le site Internet.
- Dès l’achat, une entrée est faite dans le base de données locale (ou base de données de service) du magasin.
- Immédiatement, les détails de la commande sont écrits dans un Collection Firebaseaussi.
- Le serveur Web répond au site que l’achat a réussi, auquel cas le site envoie un Google Analytics 4 événement à la point de terminaison Google Tag Manager côté serveuravec le identifiant de transaction comme l’un des paramètres.
- Le point de terminaison côté serveur prend ensuite cet ID de transaction de la demande et utilise Variables Firestore pour extraire le reste des informations d’achat.
- Ces variables sont ensuite ajoutées à la balise Google Analytics côté serveur (et à d’autres balises qui ont besoin de ces informations), afin de compléter les paramètres requis qu’une balise bien formée Événement d’achat a besoin.
Comme il s’agit d’un exemple inventé, je vais sauter des étapes 1–3. C’est un peu une échappatoire, car l’ingénierie du flux de données du moteur de vente vers Firestore n’est pas simple à faire. Ça doit arriver immédiatement pour éviter la latence et les conditions de concurrence potentielles, où le conteneur du serveur essaie de rechercher des données qui n’existent pas (encore).
Collection Firestore
Dans Firestore, la collection finit par ressembler à ceci :
Il existe une collection appelée order_history, selon lequel chaque transaction est son propre document unique. J’utilise l’ID de transaction comme nom de chaque document pour faciliter la recherche.
Chaque document de transaction comporte les champs suivants. J’ai choisi ces champs et ces types pour nécessiter le moins de transformation possible dans le conteneur Server. Ainsi, les champs et les valeurs suivent de près ce qu’attend le schéma de commerce électronique de GA4.
currency– la devise locale de l’achat (ex.EUR).iso_time– horodatage de la commande (pour plus de commodité).items– un tableau de tous les éléments inclus dans la transaction.shipping– frais de port (ex.1.99).tax– combien d’impôts ont été payés (par exemple1.24).transaction_id– l’identifiant de la commande (duplicata du nom du document).value– la valeur totale de l’achat.
Configuration GTM côté serveur
Dans GTM côté serveur, j’ai un Google Analytics 4 balise d’événement configuré pour se déclencher lorsque l’événement avec l’ID de transaction arrive.
L’ID de transaction est envoyé en tant que paramètre d’événement personnalisé avec le nom custom_ti. Ainsi, je peux créer un Paramètre de requête variable pour cela comme ceci:
Cette variable renvoie la valeur de la &ep.custom_ti paramètre dans la requête GA4 entrante.
Ma balise Google Analytics 4 dans le conteneur Server ressemble alors à ceci :
Ici, vous pouvez voir que je code en dur le Nom de l’événement comme purchase. Ensuite, tous les champs que GA4 s’attend à inclure dans un appel d’achat sont ajoutés à la balise.
Les transaction_id est défini pour pointer vers le paramètre personnalisé dans la demande entrante, et tous les autres champs sont Firestore variables.
Chaque variable Firestore pointe vers la clé correspondante dans le document de commande. Voici comment les variables sont configurées :
Comme vous pouvez le voir, j’utilise le {{Request - ep.custom_ti}} variable (qui prend l’ID de transaction de l’URL de la demande) pour établir la Chemin du document (avec le order_history nom de collection codé en dur).
Cette C’est pourquoi j’ai défini l’ID de transaction comme nom de document lors de la création de la collection Firestore. Je peux faire des recherches directes plutôt que d’avoir à faire des requêtes.
Si je fait voulez faire une requête, voici comment je pourrais récupérer le bon document:
Cela récupèrerait le premier document qui a le transaction_id champ avec la même valeur que le ep.custom_ti paramètre dans la requête entrante.
Résultat
Lors du test, je dois d’abord vérifier que la requête entrante semble bonne :
Oui, il y a notre ep.custom_ti paramètre! Le nom de l’événement est custom_purchase mais cela n’est pas pertinent car nous le codons en dur pour purchase dans le conteneur Serveur.
Examinons maintenant tous les appels réseau sortants effectués par le conteneur Server lors du traitement de la requête entrante :
Euh, ça fait pas mal d’appels Firestore. Eh bien, il y en a une pour chaque clé extraite de Firestore. Heureusement ils reviennent tous 200 statut.
Je vais ensuite sélectionner le custom_purchase événement et vérifier ce que mes variables renvoient.
En regardant très bon! Toutes les variables ont des valeurs, et ces valeurs correspondent à ce qui a été écrit dans le document Firebase.
Voyons enfin ce que la balise GA4 a envoyé aux serveurs de Google.
Oui! Tous les champs sont correctement définis. OK, jetons également un coup d’œil rapide à la demande sortante.
Et voila. Si vous vous souvenez, j’ai seulement envoyé le identifiant de transaction au serveur. Il a été élargi avec les données du document Firestore, et la demande finale aux serveurs Google a été formatée comme un événement d’achat approprié.
Tout cela a été fait sans avoir à créer quelconque modèles personnalisés de client, de balise ou de variable.
Évidemment, ce n’est pas l’exemple le plus utile, car vous incluez généralement les données de transaction déjà dans le client. Mais comme exemple du fonctionnement de l’élargissement des données, je pense que c’est une configuration assez astucieuse.
Les nouvelles API modèles
En plus de la variable Firestore, un nouveau modèle d’API, Firestore, est sorti. Toutes ses méthodes sont compatibles avec Promise, bien sûr.
Firestore.read– utilisez-le pour récupérer un document ou alors collection de Firestore avec une recherche directe.Firestore.write– utilisez ceci pour écrire dans un document dans Firestore. Si le document n’existe pas, il est automatiquement créé dans la collection.Firestore.query– utilisez ceci pour récupérer document(s) qui correspondent à la requête donnée.Firestore.runTransaction– utilisez-le pour exécuter des opérations de lecture/écriture par lots et atomiques.
À titre d’exemple, voici ce qu’est un Firestore.query l’appel ressemblerait à :
const Firestore = require('Firestore'); const queries = [['user_id', '==', 'admin'], ['country', '==', 'FI']]; return Firestore.query('users', queries, { projectId: 'my-project', limit: 1, }).then((documents) => { return documents; }); Cela interroge la collection users pour un document (un, parce que limit est 1), qui a le user_id clé réglée sur admin et le country clé réglée sur FI.
En cas de succès, un tableau de documents correspondants (encore une fois, un seul) est renvoyé par le rappel.
Notez que pour que cela fonctionne dans une variable, l’appel d’API lui-même doit être renvoyé (return Firestore.query...), car il renvoie une promesse que le code d’exécution de GTM gérera ensuite de manière appropriée.
runTransaction peut sembler déroutant, mais c’est un moyen utile d’avoir un ensemble de écrivez opérations immédiatement après une série connexe d’opérations lire opérations. Ceci est pratique si le écrivez nécessite une entrée du lire. Les atomicité fait référence au fait que soit toutes les opérations sont un succès ou alors toutes les opérations échouent. En cas d’échec, jusqu’à deux les tentatives sont effectuées automatiquement. Si trois tentatives échouent au total, l’API rejette la promesse avec une erreur.
Les transactions sont un moyen de protéger vos configurations de lecture-écriture des autres, concurrent opérations d’écriture. Par exemple, lors de la lecture des données d’un document Firestore, si un autre processus modifie ces données, la transaction redémarre automatiquement pour s’assurer qu’elle s’exécute sur les données les plus récentes et les plus à jour.
En savoir plus sur ces API ici.
Résumé
Firestore pourrait être plus obscur pour les utilisateurs “occasionnels” de Google Tag Manager, du moins par rapport à quelque chose comme Google BigQuery.
Cependant, même si BigQuery est un excellent entrepôt de donnéesce n’est pas un transactionnel base de données, comme sa lire les opérations ne peuvent pas gérer le type de faible latence et de coût qu’une base de données NoSQL en temps réel comme Firestore peut supporter.
Les possibilités d’enrichissement des données sont illimitées. Naturellement, vous devez avoir un plan en place pour remplir ces documents Firestore, mais à des fins d’élargissement des données, vous pouvez faire des choses comme…
- Créez une table de hachage des identifiants propriétaires des utilisateurs pour vous assurer que ce qui est stocké sur leur appareil n’est pas ce qui est envoyé aux fournisseurs.
- Mettez temporairement en cache les informations qui doivent également être disponibles pour d’autres requêtes dans le conteneur du serveur. C’est plus déterministe que ce que
templateDataStoragedes offres. - Créez un système d’analyse en temps réel simple où le conteneur de serveur écrit les données du hit stream et un tableau de bord lit il.
- Créez un moniteur en temps réel pour résoudre rapidement les problèmes potentiels de collecte de données.
- Et bien sûr, le million de cas d’utilisation différents pour enrichir les données à l’aide d’une clé d’entrée de la requête entrante, similaire à ce que nous avons fait dans cet article.
Je suis ravi d’avoir une autre API Google Cloud extrêmement utile avec laquelle jouer dans le conteneur Server.
Que pensez-vous de Firestore ? Pouvez-vous penser à d’autres cas d’utilisation intéressants pour l’API ?
