The site measured everything client-side: with no server-side layer, GA4 hits were exposed to blockers, ITP, and third-party cookies, and there was no way to prove the skill without a client asking for it first.
Two paths: pay for an intermediary SaaS like Stape, or deploy the server-side container directly on the same Google Cloud account already running the GEO/AEO pillar.
A server-type GTM container on Cloud Run with a custom domain, managed certificate, and scale-to-zero. A CSP bug silently blocking the connection, found and fixed already in production.
Real traffic confirmed end to end, from the browser through sgtm.cristhianvelasquez.com to GA4, verified in Cloud Run logs and in GA4 realtime.
Context
Selling server-side tagging without a verifiable one running in production isn’t defensible. It was built on Google Cloud’s own infrastructure instead of an intermediary SaaS like Stape, for cost (0€ indefinitely on Cloud Run’s free tier versus a paid plan that grows with traffic) and as a technical argument in front of a client auditing the setup.
How it was actually solved
Why Cloud Run directly and not Stape
Stape simplifies the dashboard and the maintenance, but bills by traffic and adds one more external vendor to manage. Cloud Run with GTM’s automatic provisioning gives 2 million free requests a month, runs on the same Google Cloud account already carrying the GEO/AEO pillar, and with request-based billing and scale-to-zero the real cost stays at 0€ as long as traffic doesn’t spike far above current levels.
The bug that never showed up in any server log
With the certificate issued, the container published, and the GA4 client configured, real traffic still wasn’t arriving, only manual test requests. The cause never appeared in Cloud Run’s logs because the request never left the browser: the site’s Content-Security-Policy didn’t include sgtm.cristhianvelasquez.com in connect-src, so the browser blocked the fetch before sending it. gtm.js loaded fine with a 200, which made everything look like it was working. Only the browser console showed the real error.
Real cost: what keeps it at 0€ and what would break it
With minimum instances at zero and request-based billing, the service costs nothing at rest and uses a tiny fraction of the free tier at current traffic. The only things that would break it: raising minimum instances to one or more (an always-on instance, around 35-40€ a month), or an anomalous traffic spike with no scaling cap. That’s why maximum instances stays capped and a budget alert is active.
A tagging server that returns 200 on every direct test against its API can still receive zero real events if the browser blocks the connection before it leaves. Verifying a server-side setup has to include real browser traffic with DevTools open, not just synthetic pings to the API.
FAQ
Why Cloud Run instead of a managed provider like Stape?
Cost and technical argument: Cloud Run’s free tier comfortably covers traffic for a site this size, with no paid plan to grow into, and it demonstrates direct infrastructure ownership instead of relying on an intermediary SaaS.
What fails most often in this kind of setup?
Not the certificate or the GTM container itself, but the layer almost nobody checks when setting it up: the site’s Content-Security-Policy. If connect-src doesn’t include the tagging server’s domain, the browser blocks the connection silently and nothing shows up as an error on the server side.