The automatic provisioning process of the Google Tag Manager server-side tagging service is extremely useful. With just a few clicks of the button, you can have a fully functional (albeit limited to testing use) server-side tagging endpoint on the Google Cloud Platform (GCP). For a video overview of the automatic deployment, see this video. However, the automatic provisioning process creates a new Google Cloud Platform project and, at the time of writing, always deploys the App Engine application (on which the tagging server runs) in the us-central-1 GCP region.
Facebook has now officially released their Conversions API tag template for server-side tagging in Google Tag Manager. With this tag template, you can create a server-side tag that fires with any Client designed to parse requests into a unified event model. One such Client already exists, and every single Server container has it built-in: the GA4 Client. If you haven’t yet deployed a Server container, check out this video walkthrough for more details on how to do it.
Ever since it was released that server-side tagging in Google Tag Manager would run on the Google Cloud Platform stack, my imagination has been running wild. By running on GCP, the potential for integrations with other GCP components is limitless. The output to Cloud Logging already introduces interesting pipeline opportunities, but now it gets even better. It’s finally possible to write directly to Google BigQuery from a Client or tag template!
One of the largest costs in a server-side tagging can be logging. Google warns about this in their official documentation, and it’s definitely something to keep a keen eye on if your server-side endpoint processes enough data per month. How much should it process for logging to become an issue? It depends, but you could start seeing some impact once the endpoint processes >1 million incoming requests per month. The best way to find out if logging is a problem is to visit the Billing dashboard in your server-side tagging Google Cloud project and check what the portion of Log Volume is in your monthly costs.
Core Web Vitals is described on the dedicated web.dev resource as (emphasis mine): “Core Web Vitals are the subset of Web Vitals that apply to all pages, should be measured by all site owners, and will be surfaced across all Google tools.” Recommended Core Web Vitals thresholds - from https://web.dev/vitals/ The Core Web Vitals measurement as suggested by Google are: Largest Contentful Paint (LCP), which measures the time it took to load the largest image or text block in the viewport.
At one point in the turbulent year of 2020, you might have gasped in surprise when looking at the preview interface of Google Tag Manager. No, I’m not talking about the new preview mode interface. Instead, I’m referring to how the Click Element and Form Element built-in variables would now display a CSS path string rather than the expected [object HTMLDivElement] (or equivalent). There was good and bad in this update.
With the introduction of server-side tagging in Google Tag Manager, the variety of things you can do with your own server-side proxy is mind-boggling: Reduce client-side bloat by consolidating data streams and distributing them to vendor endpoints server-side. Improve data security by adding safeguards and validations to prevent harmful data from being sent to vendor endpoints. Enrich data server-side, by combining the incoming data stream with data from APIs and data stores that you own and control.
- OLDER POSTS
- page 1 of 28