Geavanceerde technieken en inzichten via SST
Server-side Tagging (SST) is een onmisbare techniek geworden voor data specialisten en online marketing campagnes. Sinds 2020 is het mogelijk om via Google Tag Manager (GTM) naast de reguliere client-side tagging ook gebruik te maken van SST. En natuurlijk is deze techniek ook beschikbaar voor andere tag management systemen. GTM is vanaf het begin van haar bestaan in mijn optiek toch wel het paradepaardje van de Google Stack geworden. In de basis is het zeer gebruiksvriendelijk en doet het goed wat het moet doen. Maar ook voor de geavanceerde gebruiker heeft het heel veel mogelijkheden. Hetzelfde geldt ook voor de release van SST.
In deze blog zal ik ingaan op de mogelijkheden die wellicht minder bekend zijn maar voor de iets meer ervaren data specialist goed van pas zullen komen. Het zal dus iets dieper gaan dan de standaard SST implementatie en meer gericht zijn op mogelijkheden binnen het Google Cloud Platform.
GCP is een zeer uitgebreide aanbieder van clouddiensten die een scala aan oplossingen aanbiedt op het gebied van data, hosting en software. Ook de marketing tools binnen de Google Stack worden steeds meer verweven in GCP. Daarom is het zeker de moeite waard om je eens te verdiepen in dit platform. Omdat het aantal services binnen GCP overweldigend is, zou ik aanbevelen om gericht een specifiek onderwerp uit te kiezen en daarmee aan de slag te gaan. Je kan anders makkelijk verdwalen in de enorme omvang van het platform.
Het grote voordeel van GCP is dat zodra je een SST container hebt ingesteld, je deze vervolgens kunt koppelen met andere diensten in het platform. Hieronder volgen enkele voorbeelden.
Firestore is een NoSQL database, wat betekent dat dit type database niet per se relationele tabellen hoeft te hebben. Dus een meer ongestructureerde opzet in vergelijking met bijvoorbeeld BigQuery. Je bent flexibeler bij het opzetten van de database en dit is ook makkelijker voor iemand met beperkte technische database kennis. Het uitlezen van de data is ook makkelijker, en de data die verstuurd wordt naar de Firestore data hoeft ook niet vooraf gemodelleerd te worden. Het is ook nog eens supersnel in de dataverwerking wat het ideaal maakt om te koppelen met bijvoorbeeld realtime data vanuit je GTM container.
Dataverrijking voor GA4 kan zeer nuttig zijn als je bijvoorbeeld niet alle data intern beschikbaar hebt voordat je deze verstuurd naar GA4. De situatie kan zich voordoen dat je externe databronnen nodig hebt en wil vermengen met bijvoorbeeld je purchase of conversie event naar GA4. Interne data uit je CMS systeem zoals revenue, transaction ID en product name heb je natuurlijk beschikbaar vanuit je CMS. Maar voor additionele data die niet beschikbaar zijn in je CMS kan je Firestore inzetten. Omdat Firestore ook beschikbaar is binnen GCP kan je dit koppelen aan je SST container.
Een concreet voorbeeld zou kunnen zijn dat een lokaal bedrijf uit Eindhoven wil weten in welke wijken bezoekers wonen die een aankoop doen. Ze willen dit dan vervolgens in een mooi rapport gieten samen met andere data uit GA4. In feite creëer je op deze manier een nieuwe dimensie in GA4 naast de al bestaande dimensies zoals land en stad.
Via de website van https://data.overheid.nl is er al heel veel data beschikbaar die openbaar is voor gebruik. In dit specifiek geval was er een dataset aanwezig die alle postcodes koppelt met desbetreffende wijken in Eindhoven.
Je kan deze data gratis downloaden en gebruiken. Dit artikel gaat niet in op de vraag hoe je data uit bijvoorbeeld Excel files kunt importeren in Firestore, maar daar zijn tal van mogelijkheden beschikbaar voor.
Gegevens zijn gemakkelijk te lezen in de Firestore datase
Het koppelen van de Firestore data met de GTM server container is niet moeilijk. GTM heeft hiervoor namelijk een standaard lookup variabele beschikbaar die de verbinding legt. In het geval van de postcode wordt deze opgevangen door de server container vanuit de web container. Vervolgens gaat de lookup variabele zoeken in de Firestore database en retourneert de desbetreffende wijknaam van het record. Let wel op dat hetzelfde Google account toegang moet hebben tot de GTM container en Firestore.Â
Mocht je willen connecten met een externe Firestore database dan kan dat ook in de ‘More settings’ optie in de lookup variabele. En je zal dan een Service account moeten aanmaken in GCP.
GTM heeft een ingebouwde Firestore lookup functie beschikbaar
In het geval van online marketing is Google Ads natuurlijk een onmisbare schakel voor succes. Campagnes beoordeelt en bijgestuurd aan de hand van de conversies die hieruit voortvloeien. Dit is het geval voor zowel de rapportages van marketeers, maar ook de attributie en algoritmes in Google Ads zelf. Daardoor is een betrouwbare conversiemeting van essentieel belang. Het komt vaak voor dat er wijzigingen zijn in bijvoorbeeld de techniek van de website of in GTM. Om er zeker van te zijn dat de Google Ads pixels goed blijven werken, is monitoring belangrijk. Echter zit er altijd een vertraging in de rapporten van Google Ads. Gelukkig kan je ook realtime je pixels monitoren met behulp van GTM.
In je GTM server container kan je templates toevoegen. Deze zijn door andere gebruikers gemaakt en toegevoegd aan de SST template library. Ze zijn voor verschillende doeleinden beschikbaar maar het template dat we hier gebruiken, heeft als specifieke eigenschap dat het alle uitgevoerde tags uitleest die zijn afgevuurd door de server container en deze logt in een BigQuery table. In dit geval gebruiken we het template ‘Server Container Monitor’ van de publisher ‘gtm-templates-simo-ahava’.
Het template is hier geactiveerd als tag in GTM
Zodra je dit template toe gaat voegen als tag in GTM, zijn er enkele zaken waarmee je rekening dient te houden. Ten eerste heb je een BigQuery tabel nodig waar de data naar toe wordt verzonden. Als je al een GCP account hebt, kan je BigQuery eenvoudig hier activeren. Je zal dan ook een tabel moeten aanmaken met de juiste velden, ik zal hieronder de tabel weergeven zodat je de velden zelf kan instellen. Het is belangrijk dat de velden in de tabel de juiste eigenschappen hebben zodat de GTM tag goed zijn werk kan doen bij het wegschrijven van de data.
Tabel in BigQuery met velden
Zorg ervoor dat je Google account toegang heeft tot zowel GTM als het GCP project waarin je deze tabel aanmaakt. Vervolgens kan je in de tag settings de naam van de tabel invullen en het project ID in GCP.
Indien je de tag wilt laten triggeren op ‘All events,’ dan zal deze alle events gaan loggen in de BigQuery tabel die worden uitgevoerd. Dit is niet altijd wenselijk, en in ons geval willen we alleen Google Ads pixels loggen.
Daarom kan je tags uitsluiten. Open de tag die je niet wil loggen en vul vervolgens bij ‘Additional Tag Metadata’ onderstaande value in. De logger zal dan deze tag negeren.
Voor alle tags die je wel wil loggen, is het nog belangrijk dat je een ‘tag name’ invult bij de desbetreffende tag. Hierdoor zal de logger de naam van de tag loggen in plaats van een onhandige code als tagnaam in je BigQuery tabel.
Als je klaar bent met instellen, zal je merken dat de BigQuery tabel gevuld gaat worden met logging van alle tags uit je server container. Dit is ook inclusief de status van de tags. Normaal gesproken zullen de meeste ‘succes’ laten zien. Mocht je veel ‘failure’ zien, dan is dit een teken om te kijken waarom de pixels niet goed worden afgevuurd.
Met wat SQL skills kan je met een query een mooi overzicht maken van je tabel zoals onderstaand voorbeeld. Hierin staan de Google Ads pixels gegroepeerd per datum, uur en minuut voor een strakke monitoring.
Zodra je monitoring fase voorbij is, kan je besluiten om de logger in GTM te pauzeren, anders kan de BigQuery tabel veel data gaan bevatten en kunnen de kosten hiervoor stijgen. Â
Resultaat van GTM logger in BigQuery tabel
Zodra een GTM server container live is, zal logging automatisch beschikbaar worden in GCP, zowel voor Cloud Run als App Engine servers. De logs explorer in GCP is een zeer handige tool om alle requests naar je server container te monitoren.Â
Bij een typische GA4 implementatie zal de web container GA4 payloads versturen naar de server container. De server container zal deze payload verwerken in een event model, en de ingestelde tags in de server container kunnen dit event model inlezen en verzenden naar het desbetreffende platform (bv. GA4, Google Ads, Meta etc.).
Iedere request van de web container naar de server container is inzichtelijk in de Logs Explorer. Hiermee heb je dus een concreet inzicht van wat er allemaal gebeurt qua tracking op je website, en dat real-time.
Ga naar de Logs Explorer in GCP (handigste manier is om dit in te typen in de bovenste zoekbalk) en zorg ervoor dat je het goede SST project hebt geselecteerd.
Nu zie je alle logs van je server container. Waarschijnlijk zitten hier ook wat Ping requests in waar je niet zoveel aan hebt. Zoek daarom op ‘/g/collect’ in de zoekbalk ‘Search all fields’. Nu zie je alleen de GA4 requests naar de server container die bij de standaard SST implementaties het belangrijkste zijn.
Logs van alle GA4 requests naar de server container
Wat je nu ziet zijn alle events die bezoekers genereren en de server container ontvangt. Let op, events die niet naar de server container worden gestuurd maar alleen de web container behandelt vallen hier niet onder. Als je een log entry opent zie je alle details van het desbetreffende request.
Gezonde entry logs hebben de Severity status ‘Default’ of ‘Info’. Maar er kunnen ook statussen zijn ‘Error’ en ‘Warning’. Deze kan je filteren aan de linkerkant onder het kopje ‘Severity’. Het is dus slim om periodiek dit te checken of er wellicht logs entries zijn met dit soort statussen.Â
Consent Mode
Om te zoeken in de logs kan je ook de query balk gebruiken. In onderstaand geval wordt er gekeken naar requests met de tekst ‘gcs=G100’ in de URL. Dit is een parameter die Google gebruikt voor haar Consent Mode. In dit geval betekent G100 een afwijzing van Analytische en Marketing cookies. Met andere woorden, je kan zien welke bezoekers alle cookies weigeren.
Consent mode in de logs explorer
Log Based Metrics
Het mooie van ingevoerde queries is dat je van het resultaat ook een metric kan maken. Net boven de log entries vind je het knopje ‘Create metric’. Deze metric wordt nu een counter van het aantal keren dat het query resultaat voorkomt.
Een goed voorbeeld zou kunnen zijn een metric te maken van het aantal keren dat een bepaalde error voorkomt. Bijvoorbeeld alle requests met een http status groter dan 400. Zodra je een metric hebt aangemaakt zal deze verschijnen in het overzicht van ‘Log-based metrics’.
Indien je doorklikt op de optie ‘View in metrics explorer,’ heb je een grafiek met tijdslijn die betrekking heeft op deze ingestelde metric.
Alerts
Tot slot is het mogelijk om van de aangemaakte metrics ook alerts in te stellen. In het metrics overzicht kan je namelijk ook kiezen voor de optie ‘Create alert from metric’. Vervolgens kan je een zogenoemde ‘Alerting Policy’ aanmaken.
Er zijn vele mogelijkheden om deze alerts specifiek in te stellen inclusief een threshold (minimaal aantal voorkomens van de metric) en Rolling window (tijd dat de alert terugkijkt om te zien of metric voorkomt).
Instellen van een nieuwe alert
Gelukkig zijn er genoeg ‘Notification channels’ beschikbaar die je kan instellen zodra de alert getriggerd wordt. Het is heel handig dat je ook de integratie hebt met Google Chat zodat je bijvoorbeeld deze alerts kan aansluiten op een apart Google Chat groep waar data specialisten en/of developers lid van zijn.
Hopelijk laat deze blog zien dat SST niet alleen gaat over het beschermen van 1st party cookies maar dat het veel meer voordelen heeft voor met name data specialisten die extra inzicht en controle willen. Overweldigd door alle voordelen en inzichten, maar ook benieuwd naar meer? We nemen je er graag in mee. Neem contact met ons op voor een vrijblijvende kennismaking!Â