Server-side GTM is the technical foundation for privacy-resilient e-commerce tracking. This guide provides the hands-on implementation details that developers and analytics engineers need to deploy, configure, and maintain a production-ready sGTM setup.
Infrastructure Setup on Google Cloud
The first decision is choosing your hosting platform. Google Cloud Platform offers two options: App Engine and Cloud Run. We recommend Cloud Run for most e-commerce implementations because of its auto-scaling capabilities, pay-per-request pricing, and simpler maintenance.
Here is the step-by-step infrastructure setup:
Create a GCP project. Log into the Google Cloud Console and create a new project dedicated to sGTM. Enable billing and set a budget alert at your expected monthly cost (typically €50-200/month for standard e-commerce traffic).
Deploy the sGTM container. In Google Tag Manager, create a new Server container. GTM provides an automatic provisioning option that creates the Cloud Run service for you. Alternatively, deploy manually using the sGTM Docker image (gcr.io/cloud-tagging-10302018/gtm-cloud-image) with the container configuration key provided by GTM.
Configure scaling. Set minimum instances to 1 (to avoid cold start latency) and maximum instances based on your peak traffic. For a site with 500K monthly sessions, 3-5 maximum instances is typically sufficient. Each instance handles approximately 1,000 requests per second.
Set environment variables. The sGTM container requires a CONTAINER_CONFIG environment variable with the base64-encoded configuration from GTM. Optionally set PREVIEW_SERVER_URL to enable GTM Preview mode for server-side debugging.
Custom Domain and DNS Configuration
Running sGTM on a subdomain of your main site is critical for first-party cookie benefits. If your site is example.com, your sGTM endpoint should be something like collect.example.com or track.example.com.
DNS setup. Create a CNAME record pointing your chosen subdomain to the Cloud Run service URL. In Google Cloud, you can map a custom domain directly to the Cloud Run service using the Domain Mappings feature, which also provisions a managed SSL certificate.
SSL certificate. Google Cloud automatically provisions and renews SSL certificates for mapped custom domains. Verify that HTTPS is enforced — all tracking data should be transmitted over encrypted connections.
CDN considerations. Do not place a CDN (like Cloudflare) between your site and sGTM unless you configure it to pass through requests without caching. Caching tracking requests would cause data loss or duplication.
The subdomain choice matters for cookie scope. A cookie set by collect.example.com has access to the .example.com domain, making it readable by your main site. This enables seamless session continuity between client-side and server-side tracking.
GA4 Client and Tag Configuration
The GA4 Client in sGTM listens for incoming requests from client-side GA4 tags and parses them into event data that server-side tags can use.
Add the GA4 Client. In your server container, add the built-in GA4 Client. No additional configuration is needed — it automatically recognizes GA4 request formats.
Create the GA4 Server-Side Tag. Add a GA4 tag that forwards events to Google Analytics. Set the Measurement ID to match your GA4 property. Enable "Send to HTTP request" to use the server-side API rather than the Measurement Protocol.
Configure event forwarding. By default, the GA4 tag forwards all events. You can add event filtering to exclude internal traffic, bot traffic, or specific events that should not reach GA4.
Set first-party cookies. The GA4 Client can set a first-party cookie (_ga equivalent) from the server. Enable the "Set cookie" option and configure the cookie domain to .example.com. Server-set cookies bypass ITP limitations, extending cookie lifetime from 7 days to your configured duration (typically 2 years).
Update client-side GTM. In your client-side GA4 Configuration tag, set the "Server Container URL" field to https://collect.example.com. This redirects all GA4 traffic through your sGTM server. The rest of your client-side setup remains unchanged.
Meta Conversions API Setup
The Meta Conversions API (CAPI) sends events from your server directly to Meta, providing a redundant signal alongside the Meta Pixel.
Install the Meta CAPI tag. In your server container, add the "Facebook Conversions API" tag from the Community Template Gallery. Configure it with your Meta Pixel ID and API access token (generate this in Meta Events Manager).
Map event data. Configure the tag to map incoming GA4 events to Meta standard events: purchase, AddToCart, ViewContent, InitiateCheckout, etc. Map the event parameters: value, currency, content_ids, content_type, and num_items.
Send user data for matching. Meta CAPI performance depends on user data quality. Hash and send the user's email address (em), phone number (ph), first name (fn), last name (ln), and IP address. The Meta CAPI tag handles SHA-256 hashing automatically for PII fields.
Implement deduplication. Since you are running both the Meta Pixel (client-side) and CAPI (server-side), you must deduplicate events. Set the same event_id in both the client-side pixel event and the server-side CAPI event. Meta uses this ID to deduplicate, counting each conversion only once.
Test with the Events Manager. Use Meta's Events Manager Test Events tab to verify that server events are arriving with correct parameters and high match quality scores. Aim for a match quality score of 7 or higher.
Consent Mode v2 Implementation
Consent Mode v2 is required for serving ads in the European Economic Area. It signals user consent status to Google tags, enabling compliant tracking and conversion modeling for unconsented users.
Set consent defaults. In your client-side GTM, fire a Consent Initialization trigger that sets default consent states before any tags load. For EEA users, set ad_storage, analytics_storage, ad_user_data, and ad_personalization to denied by default.
Update consent on CMP interaction. When the user interacts with your consent management platform (e.g., Cookiebot, OneTrust), update the consent state using gtag('consent', 'update', ...) with the user's choices.
Forward consent to sGTM. The GA4 Client in sGTM automatically reads the consent state from incoming requests. Server-side tags can then check consent before firing. For unconsented users, GA4 sends cookieless pings that enable Google's behavioral modeling.
Verify in GA4. Check the GA4 real-time report and the consent status column in DebugView to confirm that consent signals are flowing correctly. Users who denied consent should appear as "Consent denied" with limited data collection.
Monitoring and Maintenance
A production sGTM setup requires ongoing monitoring to ensure data quality and infrastructure health.
Set up Cloud Monitoring alerts. Create alerts for: error rate exceeding 1%, latency exceeding 500ms (p95), instance count reaching maximum, and unexpected cost spikes. These alerts catch issues before they impact data quality.
Log analysis. Enable Cloud Logging for your sGTM service and regularly review error logs. Common issues include malformed incoming requests, failed API calls to GA4 or Meta, and DNS resolution failures.
Data quality checks. Compare GA4 event counts between client-side and server-side tracking weekly. A significant discrepancy (more than 5-10%) indicates a configuration issue. Also compare sGTM-reported conversions against your e-commerce backend to validate accuracy.
Container versioning. Keep your sGTM container image updated to the latest version. Google releases updates that include bug fixes, new features, and security patches. Use Cloud Run's revision management to deploy updates with zero downtime.
Cost monitoring. Review Cloud Run billing monthly and optimize instance configuration if costs exceed expectations. Common optimizations include reducing minimum instances during low-traffic hours and adjusting memory allocation based on actual usage.