Public pages use no advertising trackers. The secure portal uses an essential session cookie and the service providers described in our privacy policy.

Skip to main content
Privacy Resolve
How It WorksResourcesVerify a letterFor attorneys(888) 649-4500
Access Portal →
← Back to Resources
Remediation·October 22, 2026·4 min read

Meta Conversions API and Server-Side Tagging: The Data Still Reaches Meta

Moving a pixel to the Meta Conversions API or a server-side tag manager changes the route the data takes, not who receives it. What Meta and Google document.

PR
Privacy Resolve Editorial Team
Last reviewed October 22, 2026

A common piece of advice to companies worried about tracking is to "move it server-side." The idea is that if the visitor's browser no longer talks to Meta or Google directly, the problem goes away. Meta's and Google's own documentation describe something different: a server-side setup changes the route the data takes, not the company that receives it.

How a browser pixel works

A browser pixel is code that runs in the visitor's browser and sends each event, such as a page view or a click, straight to the vendor. The request leaves the visitor's browser addressed to facebook.com or google-analytics.com, and anyone watching the browser's Network panel can see it.

How the Meta Conversions API works

Meta describes the Conversions API as a connection between an advertiser's marketing data, including website events, sent from the advertiser's own server, and "Meta systems that optimize ad targeting, decrease cost per result and measure outcomes." Meta says server events "are processed like events sent using the Meta Pixel."

Meta's parameter documentation shows what a website event sent this way carries:

  • The page address: "The browser URL where the event happened," which Meta says is required for website events.
  • The IP address of the visitor's browser.
  • The visitor's browser details, its user agent.
  • The values of the _fbp and _fbc cookies the Meta Pixel keeps in the visitor's browser, which tie the event to that browser.
  • Hashed contact details, such as an email address or phone number, when the site sends them.

So the event Meta receives from the server describes the same visitor on the same page as the pixel event would.

Meta also recommends running the Conversions API alongside the Meta Pixel, which it calls a "redundant setup," and documents how to match the two copies of each event so they are counted once. On many sites the Conversions API is a second route to Meta, not a replacement for the first.

How server-side Google Tag Manager works

Google describes a server container as one that "runs on a server that you control." The visitor's browser sends its tag requests to that server, usually at a subdomain of the site's own domain, set as the server address in the Google tag's settings. The server turns each request into events, and tags inside the container send that event data on to the services the operator connects: Google Analytics, Google Ads, Meta through a Conversions API tag, and others.

Google puts it plainly: only the operator has access to the data in the server "until you choose to send it elsewhere," and the operator has full control over "where it is routed from the server."

What changes and what does not

What changes is visibility. The visitor's browser now sends its requests to the site's own domain, and the onward request to Meta or Google leaves from the server, where the visitor cannot see it.

What does not change is the recipient. The tags still carry the vendor's own measurement and pixel identifiers, and the server exists to pass the data on to that vendor. The relay changes the route, not the recipient.

This is why a privacy letter can name Meta or Google as a recipient even where the visitor's browser sent the request to the site's own domain. The server container's configuration and its logs show every destination it forwards to, and the company that runs the server holds them.

A server-side tag needs the same consent as a browser pixel. Meta's Business Tools Terms also tell advertisers not to send it information that "includes or is based on, directly or otherwise, health information." That applies whichever route the data takes.

When you run the Reject button test, filter for your own tracking subdomain as well as for facebook and google. Requests to your own endpoint after a refusal, carrying page addresses and cookie values, mean your server is still receiving the data it would forward.

What to do

  1. List every destination in your server container and every Conversions API connection, including ones set up "in one click" from Meta Events Manager or through a platform plugin.
  2. Pass the visitor's consent choice to the server, and make every server tag check it. A tag that fires on every event ignores the banner.
  3. Do not forward events from pages about conditions, doctors, appointments, intake, or patient portals to any advertising platform, by any route.
  4. Keep the server container's version history, configuration, and logs. If you have received a letter, they are part of the record.
  5. Do not treat a server-side move as a fix. If the data should not reach Meta from the browser, it should not reach Meta from your server. Our guide to removing the Meta Pixel from patient pages shows how to keep reporting without sending it.

Sources

Links checked on October 22, 2026. Quotations are from the pages as published that day.

General information only, not legal advice. Laws, deadlines, defenses, insurance terms, and outcomes vary by jurisdiction and facts. Verify the sender independently and consult qualified counsel before acting on a legal notice or making a payment.
Related reading
Remediation

Does Your Reject Button Actually Stop Tracking? A 5-Minute Test

October 22, 2026 · 3 min
Remediation

Google Consent Mode: Basic Versus Advanced, and What Still Gets Sent

October 22, 2026 · 4 min
Remediation

Removing the Meta Pixel from Patient Pages Without Losing Reporting

October 22, 2026 · 4 min