Server Side Tracking and Meta Conversions API Setup

Server side tracking moves part of your measurement from the visitor's browser to a server you control. Instead of a dozen third-party scripts each sending data straight to Meta, Google and TikTok, the browser sends events to your own tagging server on a subdomain such as data.yourstore.com. That server forwards clean, consistent events to each platform.

Brands usually come to us for this after seeing ad platforms report fewer purchases than the store actually took. Ad blockers, Safari's cookie limits and flaky tag loading on slow mobile connections all chip away at browser-only data. For stores spending meaningfully on paid social and search, server-side tracking closes part of that gap, and bidding learns from the difference.

What Our Server Side Tracking Setup Includes

• Server-side Google Tag Manager. A server container hosted on Google Cloud Run in your own Cloud project, or on Stape if you prefer managed hosting, mapped to a first-party subdomain.
• Meta Conversions API. Purchase, lead, add to cart, initiate checkout and view content events sent server to server, deduplicated against the pixel.
• Google Ads Enhanced Conversions. Hashed first-party customer data sent with conversions to improve matching, plus server-side Google Ads conversion tags where they fit.
• GA4 through the server container. GA4 events routed through your tagging server, so one browser request feeds several destinations.
• TikTok Events API and others. TikTok, Pinterest, Snapchat and Microsoft Advertising where you run spend on those platforms.
• Consent handling. Consent state passed from your cookie banner into the server container, so events are only forwarded where the visitor allowed it.
• Documentation and monitoring. An event flow diagram, a tag list and alerts for sudden drops in event volume.

How Does Server Side Tracking Work, Step by Step?

Server side tracking works by putting your own server between the visitor's browser and the ad platforms. The browser sends one request to your tagging server, the server reads it, then sends separate, cleaned-up requests to each platform. Here is the path a single purchase takes.

1. The browser collects the event. Your data layer or Shopify custom pixel records the purchase with order ID, value, currency, items and an event ID. The web container or Google tag packages it.
2. One request goes to your subdomain. Instead of calling Meta, Google and TikTok separately, the browser sends the event to a first-party address such as data.yourstore.com, which points at your tagging server.
3. A client claims the request. Inside the server container, a client (for example the GA4 client) reads the incoming request and turns it into event data the server tags can use.
4. Server tags transform and forward. Each tag checks consent, removes or hashes fields as configured, adds data such as the fbp and fbc values, and sends the event to its platform API.
5. Platforms deduplicate and match. Meta, Google and TikTok match the server event to the browser event using the shared ID, then to a user using the hashed customer data. That is what bidding learns from.

How Meta Conversions API Deduplication Works

Most brands keep the Meta Pixel in the browser and add the Conversions API alongside it. That means Meta receives many events twice, once from each source. Meta removes the duplicates when both events share the same event_name and the same event_id. If the IDs do not match, or the server event has no ID at all, Meta counts both and your reported purchases go up for no real reason.

In our setups the browser generates one event ID per action, sends it with the pixel event, and passes the same ID to the server container through the data layer. We also forward the fbp and fbc cookie values so Meta can connect the server event to the ad click, and we send customer details such as email and phone number hashed with SHA-256. We check each event's Event Match Quality score in Events Manager before sign-off.

For a Shopify-specific walkthrough of the options, read our guide to the Meta Conversions API on Shopify.

Ways to Send Server Events to Meta, Compared

There is more than one route, and the right one depends on your platform, your other ad channels and how much control you need.

How to Set Up Server-Side Tracking

To set up server-side tracking, you fix the browser data layer, provision a tagging server on a first-party subdomain, route events to it, build one tag per platform, then test and compare results. This is the order we follow.

1. Check the browser layer first (week 1). Server-side tracking only forwards what the browser and data layer give it. We audit your existing tags and GA4 setup, then fix the data layer before building anything on top.
2. Provision the server (week 1 to 2). We create the tagging server in your Google Cloud project or Stape account, map it to a first-party subdomain through DNS, and set scaling limits to match your traffic.
3. Route and build tags (weeks 2 to 3). We point the web container at the new server, then build GA4, Meta, Google Ads and TikTok tags in the server container. Each gets consent checks, event IDs and the customer data parameters you have agreed to share.
4. Test end to end (week 3). We use server container preview, Meta Test Events, Google Ads diagnostics and TikTok Events Manager to confirm each event arrives once, with the right value and match data, across desktop, mobile Safari and in-app browsers.
5. Compare and hand over (weeks 5 to 6). After two to three weeks we compare platform-reported conversions and match quality with the period before launch, then hand over documentation and alerting.

Server Side Tracking Deliverables and How We Judge Success

When the project ends you should be able to see, in each platform, that the setup works. These are the outputs we hand over and the checks behind them.

A good outcome is a pipeline where every platform receives the same order data once, match quality improves where consent allows it, and the gap between platform conversions and backend orders narrows and holds steady. We report the measured change; we do not promise a specific uplift, because it depends on your audience, browsers and consent rates.

Server-Side Tracking Mistakes We Fix

Many server-side setups we audit were built quickly and miss the points that make the work worth paying for.

• No first-party subdomain. The tagging server runs on its default cloud URL, so requests are still third-party and cookies get none of the first-party benefit.
• Missing or mismatched event IDs. The pixel and the server send different IDs, so Meta counts both and reported purchases inflate.
• Consent ignored on the server. The web container respects the banner but the server tags forward everything. That is a compliance problem, not a tracking gain.
• Under-provisioned hosting. Too few instances or no minimum instance setting means slow responses or dropped requests during a sale or a viral post.
• Everything routed, nothing tested. Events reach the server but arrive at platforms without value, currency or customer data, so the Conversions API adds volume without adding match quality.
• Preview settings left in production. Debug options that slow every request or expose test data stay switched on after launch.

Why Do You Need Server-Side Tracking?

You need server-side tracking when browser-only tags are losing or garbling the conversions your ad platforms bid on, especially when you spend across several platforms. Here is what it fixes, and what it cannot.

What it does well

• Sends events from your own domain, which ad blockers are less likely to block than well-known third-party script URLs.
• Lets the server set first-party cookies, which can last longer than cookies set by JavaScript in Safari, depending on how the server is hosted and mapped.
• Gives every platform the same order ID, value and currency, so reports stop disagreeing about basic facts.
• Lets you strip data, such as IP addresses, before it leaves your server.

What it does not do

• It does not override consent. If a visitor declines, ours respects that.
• It does not recover every lost conversion. Some visitors will always be untracked.
• It does not fix a broken data layer. Bad data sent from a server is still bad data.
• It is not free. Cloud Run or Stape hosting is a monthly cost that grows with traffic, billed to your account.

Server Side Tracking Use Cases by Business Type

Ecommerce stores

The main use is sending purchase, add to cart and checkout events with full value and hashed customer data to Meta, Google Ads and TikTok from one pipeline. Stores with heavy iPhone traffic from paid social usually see the clearest difference in match quality.

Lead generation and B2B

A server container can receive events from your backend or CRM as well as the browser. That lets you send a qualified lead or a closed deal to Meta and Google with the original click ID, days after the form was filled, so campaigns optimize toward leads that turned into revenue.

Subscriptions and SaaS

Trial conversions, first payments and renewals happen on the server anyway. Sending them through the same pipeline keeps values consistent and lets you report on paid conversions instead of signups.

Server-Side Tagging Tools and Platform APIs

Why Choose 95 Solutions for Server-Side Tracking

• Built by people who spend ad budgets. Mustafa has more than 11 years in digital marketing and runs paid social for fashion brands in-house, so we judge the setup by how bidding performs.
• Your infrastructure, your bill. The Cloud project or Stape account, the DNS record and the containers belong to you.
• Honest scoping. If the Shopify app or the Conversions API Gateway is enough, we will say so.
• Developers on the team. Custom backends, headless storefronts and direct API work are handled in-house.
• US contracts, overlapping hours. Fixed-price contracts in USD from our US LLC, during hours that overlap the US and UK business day.

Who Should Invest in Server-Side Tracking

A good fit

• Stores and lead generation businesses spending across Meta, Google and TikTok who want one consistent pipeline.
• Brands whose ad platforms report far fewer conversions than the backend records.
• Teams with a working browser setup who want better match quality and more control over shared data.

Probably not a fit

• Small stores running only Meta on Shopify, where the native app is usually enough.
• Sites whose browser tracking is still broken. Fix that first, often alongside conversion tracking setup.
• Anyone hoping to track visitors who declined consent.

Server-Side Tracking Pricing

Server-side tracking is a fixed-price project covering the server build, platform connections, testing and handover. The provider bills hosting to you directly. Ongoing monitoring can move onto a monthly plan within our analytics and tracking services.

The setup price depends on how many platforms receive events, whether the browser data layer needs work first, and whether events also come from a backend or CRM. A Shopify store sending GA4 and Meta is a smaller build than a headless store sending to five platforms with offline conversions. Hosting is a separate cost that grows with traffic, and we estimate it before you commit.

For custom backends, several storefronts or offline event feeds, request a custom quote and we will scope it.

Next Step for Your Server Side Tracking Project

Server-side tracking only pays off when the browser setup underneath is sound, so the first step is a check of what you have. Ask for a free tracking audit and we will review your pixels, GA4 events and platform diagnostics, then tell you plainly whether server-side tracking is worth it now, or whether the Shopify app or a browser fix comes first. You can also call or WhatsApp us. We reply within one business day, book a short call about your platforms and traffic, and send a written scope with the fixed price and a hosting estimate.