As ad-blockers, browsers, and privacy laws keep evolving, your tracking setup might be silently breaking without you noticing. Marketing teams that rely purely on client-side tags are feeling it—data gaps, inconsistent conversions, and shrinking retargeting audiences. The solution isn’t to panic or pile on more scripts. It’s to evolve.
That means moving toward first-party data collection and Server-Side Tagging—technologies that keep your measurement reliable, accurate, and compliant even when the client layer gets messy.
In today’s tutorial, we’ll walk through how to deploy Meta conversion tags using Server-Side Google Tag Manager (sGTM). Before we start, make sure you already have a basic server-side setup in place: a container hosted (for example) on Google Cloud Run, accessible through your own subdomain like gtm.yoursite.com. You don’t need to configure anything yet; as long as you can preview your site through the server container, you’re ready.
Why Track with Server-Side GTM
Modern browsers and ad-blocking technology are doing exactly what they’re designed to do—protect users. Unfortunately, that same protection often blocks legitimate measurement and disrupts your analytics pipeline. Meanwhile, the pressure to improve Marketing Efficiency Ratio (MER) and Return on Investment (ROI) keeps rising. In other words: you can’t afford to guess.
Server-Side tracking fixes this by routing data through your controlled server environment before sending it to destinations like Google Analytics 4 or Meta. Because the requests come from your own domain, you maintain first-party context, minimize data loss, and decide exactly what gets shared.
Beyond stronger data fidelity, Server-Side GTM gives you cleaner governance. You can filter, enrich, or redact data on the way out—so your implementation stays stable even as browsers and ad-blockers evolve.
One key note: Server-Side GTM still relies on a client-side container to collect initial events. A client script is always required. If your goal is a completely client-free setup, you’ll need a more comprehensive data pipeline tool such as Segment (by Twilio).
Configuring Server-Side Container
Now that we have all the introductory information out of the way, it is time to move to the implementation. The first thing we need to do is to head to the client-side Google Tag Manager create a Google Tag. This tag is going to act as the bridge between the client-side container and the server-side container. So essentially, what this tag will do is transmit to our server-side container, through a mean we will discuss soon, all the data we collect.
Adding a Google Tag
Head over to your Google Tag Manager client-side container, click on Tags and then New. In Tag Configuration, choose Google Tag. Add your Google ID as your Google Analytics 4 Measurement ID which looks as follows G-XXXXXXXXXX. For the trigger, you can choose anything you would like. We going to choose Window Loaded. Now, it’s time for the main configuration. In the Configuration Parameter section, add the following parameters:
- send_page_view and set its value to true
- server_container_url and set its value to your container’s Server container URL.
What these parameters will ensure two things, the first being tracking page views and the second is sending the collected data to the pointed URL. What we just did is ensures that whatever data we are capturing is being sent to our server-side container. The next step is to configure our server-side container.
Configuring Clients & Tags in sGTM
Configuring Clients
Head to server-side container the click on Clients and then New to create a new client. A client is an adapter between the software running on a user’s device and your server container. It will allow us to receive whatever data we are forwarding from our client-side container. In the client configuration section, pick Google Analytics: GA4 (Web). Name your tag and click Save.You do not have to change any of the default configuration parameters. If you do make any change, please make sure you know what consequences the changes may have as this can seriously harm your data tracking accuracy.
Configuring Tags
Now that our client is configured, it is time to configure our tag and send data to Meta. This part should be be familiar as it is the same as configuring tags in client-side Google Tag Manager. Create a new tag and in the tag configuration section, click Discover more tag types in the Community Template Gallery. The tag we are going to choose is Conversions API Tag. Yes, we are going to implement Facebook Conversion API using sGTM, how cool is that? No more pesky development time.
In the Conversions API tag, once added to the workspace, you will have to add two details being Pixel ID and API Access Token. The token is required to use the Conversions API. You can read more about generating a token here. Now it’s time to add a trigger. Again, this part should be familiar.
In the trigger configuration section, choose Custom. And then choose All Events. What this means is we are basically telling GTM to capture all events forwarded to our server-side container and send those events to Meta through the API. As holistic as this tracking method is, it is not effective. Events such as scroll and user engagement will be forwarded to Meta and they do not have an equivalent in the platform not are they useful to track to optimize campaigns performance. We need a more refined measurement. The way to achieve that is by modifying the trigger to Some Events instead of All Events. Next, we need to limit the trigger’s behavior by adding two conditions:
- Client Name with the value GA4 Client (or whatever name you gave the client we configured in the earlier step)
- Event Name and set is value (using Regex Match)
add_to_cart|begin_checkout|lead|purchase|view_cart|view_item|page_view
| Variable | Condition | Value / Expression |
|---|---|---|
{{Client Name}} | equals | GA4 Client |
{{Event Name}} | matches RegEx | add_to_cart|begin_checkout|lead|purchase|view_cart|view_item|page_view |
What we are basically doing here is limiting the trigger to fire the tag and communicate only when we are certain that one the data comes from our configured tag and two the event is an add to cart, checkout, lead, purchase, view cart, view item or page view. All these events have relevant equivalents in Meta and are key events for both e-commerce and lead-based businesses. Next, it is time to test the implementation.
Server-Side Tagging
Route events through your domain, cut noise from blockers, and keep MER/ROI honest. Follow the step-by-step guide or get a hands-on review.
Testing the implementation
Testing a server-side implementation is tad tricky. Since we are working with 2 different workspaces, we are going to publish our client-side container and preview our server-side one.
Once your client-side workspace is live, preview your server-side container. Navigate to your website and perform actions that trigger the events you’ve configured—add items to cart, initiate checkout, or complete a purchase. In the server-side preview mode, you should see events flowing into the debugger. Click on any event to inspect its details.
Look for your Conversions API tag in the Tags Fired section. If it fires successfully, you’ll see a green checkmark. Click on the tag to view the full request payload being sent to Meta. This includes the event name, timestamp, user data (hashed), and any custom parameters you’ve mapped.
To verify that Meta is receiving these events, head to your Meta Events Manager. Navigate to your pixel and check the Test Events section. You should see events appearing in real-time with a “Server” indicator showing they came through the Conversions API rather than the browser pixel. The event match quality score will also appear here—aim for a score above 6.0 for optimal attribution.
If events aren’t appearing, check the following:
- Verify your API Access Token is valid and has the correct permissions
- Ensure your Pixel ID matches exactly
- Confirm that your trigger conditions are being met in the debugger
- Check that your client-side events are using the correct naming convention
Monitoring and Optimization
Once your implementation is live, ongoing monitoring is essential. Meta’s Events Manager provides several tools to help you evaluate your tracking quality:
Event Match Quality (EMQ): This score indicates how well Meta can match your server events to user profiles. Higher scores mean better attribution and larger retargeting audiences. To improve EMQ, include as many customer information parameters as possible (while respecting privacy regulations): email, phone, external ID, client IP address, and user agent.
Event Deduplication: When running both browser pixel and Conversions API simultaneously, you risk counting the same conversion twice. Use the event_id parameter to deduplicate events. Generate a unique ID for each conversion on the client side and include it in both the pixel and API calls. Meta will automatically recognize duplicates and count them only once.
Conclusion
Server-side tracking represents a fundamental shift in how we approach digital measurement. By moving conversion tracking from the browser to your own infrastructure, you gain control, and reliability. The implementation we’ve covered, routing Meta conversions through Server-Side GTM—solves real problems marketing teams face every day: incomplete data, blocked requests, and declining match rates. But more importantly, it positions your tracking infrastructure for the future. As privacy regulations evolve and browser restrictions tighten, first-party data collection through controlled server environments will become not just advantageous, but essential.