How to Send Conversions to Google Ads, Meta & TikTok via sGTM

For years, the standard approach to multi-platform conversion tracking was simple and chaotic in equal measure: install a pixel for each platform. Meta Pixel in the website's head. Google Ads tag via GTM. TikTok Pixel in the theme. All three load in the user's browser, all three send their own conversion data independently, and the hope was that they'd all report roughly accurately.

That approach is broken. Not because the pixels don't work — they do — but because the environment they depend on has degraded to the point where browser-only tracking consistently misses 25–40% of conversions. Every missed event is a missed signal for the algorithm. Every misattributed purchase is a budget allocation based on wrong data.

A server-side GTM container solves this by becoming the single hub through which conversion data flows — received once, processed centrally, and distributed simultaneously to Google Ads, Meta, and TikTok via their respective server APIs. This guide explains how that architecture works, what each platform receives, how deduplication prevents double-counting, and what the setup process looks like in practice.

The Architecture: One Event In, Three Platforms Out

The core idea behind a server-side multi-platform setup is a hub-and-spoke model. Your website sends one event to your tagging server. Your server processes it and simultaneously forwards it to every connected platform. No duplicate client-side scripts, no separate pixels loading independently, no data inconsistencies between platforms.

Here's how the flow works for a purchase event:

1. A customer completes a purchase on your website
2. A purchase event is pushed to the data layer (or triggered by a Shopify webhook)
3. Your web GTM container captures the event and sends it to your server GTM container at your custom domain (e.g., https://track.yoursite.com)
4. The server container receives the event and processes it — enriching it with server-side data if needed (IP address, user agent, hashed customer data)
5. The server container fires three tags simultaneously: one to Google Ads Enhanced Conversions, one to Meta Conversions API, one to TikTok Events API
6. Each platform receives a matched, hashed conversion with the correct event parameters

Setting Up the Server Container

Before you can route data to any platform server-side, you need a running server GTM container with a custom domain. The custom domain is non-negotiable — requests going to googletagmanager.com are still blocked by ad blockers; requests going to your own domain are not.

Infrastructure Options

You have two main choices for hosting your server container:

• Managed hosting (recommended for most businesses): Services like Stape.io host your GTM server container for you, handle scaling, provide a custom domain, and maintain uptime. Setup takes minutes rather than days and eliminates the need for GCP or AWS knowledge.
• Self-hosted on Google Cloud Platform: GTM server containers were designed for GCP and can be deployed with a few clicks from the GTM interface. You have full control but are responsible for scaling, maintenance, and cost management. Better for enterprise setups with technical resources.

Either way, the end result is the same: a tagging server running at a URL you control, ready to receive events from your web container and forward them to platforms.

Sending Data to Google Ads Enhanced Conversions

Google Ads Enhanced Conversions sends hashed first-party data — customer email, phone number, name, address — alongside your standard conversion tags. This allows Google to match the conversion to a signed-in Google account, recovering attribution that would otherwise be lost when click IDs are stripped or cookies expire.

What the Server Tag Does

In your server container, you add a Google Ads Conversion tag. The key difference from the client-side version is that you also configure Enhanced Conversions parameters — pulling the hashed customer data from the event payload.

The critical data points for Enhanced Conversions are:

• Email address (SHA-256 hashed before sending)
• Phone number (SHA-256 hashed, in E.164 format)
• First name and last name (SHA-256 hashed)
• Physical address if available (SHA-256 hashed)

This data comes from your data layer — typically populated from what the customer entered during checkout. GTM server containers can hash this data automatically using built-in transformation rules, so you don't need to pre-hash it in your implementation.

Sending Data to Meta Conversions API (CAPI)

Meta's Conversions API is the server-side equivalent of the Meta Pixel. It sends conversion events directly from your server to Meta, bypassing the browser entirely. When run alongside the browser pixel with deduplication, it reliably recovers conversions that iOS privacy features, ad blockers, and Safari ITP would otherwise have prevented from reaching Meta.

What the Server Tag Sends

The Meta CAPI server tag in GTM requires a dataset ID (formerly Pixel ID) and an API access token from Meta Events Manager. The event payload should include:

• event_name: The standard Meta event name (e.g., Purchase)
• event_id: A unique identifier shared with the browser pixel for deduplication
• event_time: Unix timestamp of when the event occurred
• user_data: Hashed customer identifiers — email, phone, external_id, client_ip_address, client_user_agent
• custom_data: Purchase value, currency, content IDs (products purchased), content_type
• action_source: Should be set to website

The server-side tag also has access to the user's IP address and user agent — which the browser pixel captures automatically but which you need to pass explicitly in server-side calls. GTM server containers expose these from the incoming request, so they can be forwarded to Meta without manual extraction.

Event Match Quality

Meta scores how well your server events can be matched to users — this score is visible in Events Manager as Event Match Quality (EMQ). Higher EMQ means better attribution. The biggest driver of EMQ is including hashed customer data: email alone gives you a reasonable score; email plus phone plus external ID gets you to excellent. Aim for an EMQ of 7.0 or higher.

Sending Data to TikTok Events API

TikTok's Events API functions on the same principle as Meta CAPI — a server-to-server mechanism for sending conversion events directly to TikTok without depending on the browser pixel. For businesses advertising on TikTok, especially those targeting younger demographics with high mobile usage, this is increasingly important.

What the Server Tag Sends

The TikTok Events API tag requires an Access Token and Pixel ID. Key parameters in the payload:

• event: TikTok standard event name (e.g., PlaceAnOrder or CompletePayment)
• event_id: Shared with the browser pixel for deduplication
• timestamp: ISO 8601 format event time
• user: Hashed email (sha256_email), hashed phone (sha256_phone_number), IP, and user agent
• properties: value, currency, content_id (product IDs), content_type

GTM's server container has a native TikTok Events API tag template, which handles the API endpoint, authentication, and payload structure. You configure the mapping from your server-side data to TikTok's schema within the tag.

The Non-Negotiable: Deduplication

When you're running both client-side pixels and server-side API tags for the same event, deduplication is the mechanism that prevents each platform from counting the conversion twice. It is not optional — without it, every conversion gets recorded twice, your reported ROAS doubles, and your ad algorithms optimise based on inflated signals.

The event ID should be generated at the moment the conversion happens — typically a combination of the transaction ID and a timestamp — and passed to the data layer so both the client-side pixel and the server-side data stream pick it up from the same source. This ensures they both send the same ID to their respective platforms, allowing the deduplication to work correctly.

What Happens with Hashed Customer Data

All three platforms require that identifiable customer data — email addresses, phone numbers — be hashed using SHA-256 before transmission. This is a privacy protection: the platforms can match the hash to their own user records without ever receiving or storing the raw PII.

GTM server containers handle this automatically if you configure transformation rules. You pass the raw email address in your data layer, and the server container hashes it before including it in the outbound API call to Meta or TikTok. This keeps your implementation simpler and avoids the risk of accidentally sending unhashed PII to an ad platform.

Testing Your Multi-Platform Server Setup

Once the server container and tags are configured, testing before going live is essential. Here's the verification process for each platform:

• Google Ads: Use Google Tag Assistant and the Conversions page in your Google Ads account. Server-side Enhanced Conversions show a delay of up to 24 hours before appearing
• Meta: Use Events Manager → Test Events → filter by "server" source. You'll see your server events arriving in real time. Check the match quality score and confirm event_id deduplication is working (the event should show as matched to a browser event, not double-counted)
• TikTok: Events Manager → Test Events — same principle. Filter by server events and verify purchase events are arriving with correct parameters and deduplication is confirmed
• GA4: Use DebugView in GA4 to confirm purchase events are arriving from the server path. Check that event parameters (value, currency, transaction_id) are populated correctly

The Business Case: Why One Server Container Beats Three Separate Pixels

Beyond the technical benefits, there's a clear business case for consolidating to a single server-side hub:

• More conversions reported = better algorithm performance. Ad platform algorithms optimise on the signals they receive. More complete signals mean better targeting, better bid adjustments, and lower cost per acquisition over time
• Consistent data across platforms. When all three platforms receive events from the same source, attribution discrepancies between them decrease. Comparing ROAS across Google and Meta becomes more meaningful
• Single point of maintenance. When your product catalog changes, your checkout flow updates, or a new event needs tracking, you update one container — not three separate implementations
• Privacy compliance is easier to manage. With all data passing through your server, consent-based filtering is applied once and propagated to all platforms rather than needing to be configured separately in each pixel

Wrapping Up: The Single Container Approach Is the Modern Standard

Running separate browser pixels for Google Ads, Meta, and TikTok was fine when browsers were permissive and tracking was simple. That era is over. The combination of iOS restrictions, ad blocker adoption, cookie deprecation, and consent requirements means that browser-only tracking is structurally incomplete in a way that gets worse every year.

A single server-side GTM container that distributes clean, deduplicated conversion data to all three platforms simultaneously is how high-performing advertising businesses are approaching this now. It's not a minor upgrade — it's a different architecture that produces meaningfully more accurate data and better ad performance.

At Incisive Ranking, building multi-platform server-side setups is one of our core services. If you're ready to move from three separate pixels to one unified tracking infrastructure, we can design and implement it from end to end.