Ask a brand owner if they have a tracking problem and the answer is usually “no, we’re server-side.” They have Conversions API enabled, or they run Elevar, or wetracked.io, or a server-side GTM container someone set up in 2023.

Then you open Events Manager and the Purchase event has a match quality score of 6.5.

Both things are true at once. The events are genuinely being sent from a server. And the data inside them is thin enough that the platform still cannot connect most of them to a real click.

This is the part the category gets wrong. “Server-side” describes where an event is transmitted from. It says nothing about where the identity inside that event was collected. And identity is the entire game.

Three links in the chain, and most tools only fix one

Every conversion event has to survive three separate steps before it becomes useful to the ad platform.

1. Capture. A user arrives with a click identifier attached to the URL: fbclid for Meta, gclid for Google, ttclid for TikTok. Something has to read that parameter and hold onto it.
2. Persist. That identifier has to survive the gap between the click and the purchase. Same session, next day, or eleven days later.
3. Transmit. The purchase event, carrying that identifier plus whatever other user data you have, has to reach the platform’s API.

Nearly every tool marketed as “server-side tracking” solves step 3. Some solve step 2. Almost none solve step 1, because step 1 happens in the browser, and the browser is exactly where the losses occur.

An event that clears step 3 perfectly but fails step 1 is still an unmatched event. It arrives at Meta on time, from a server, correctly formatted, and carrying no way to identify who it belongs to.

What Meta is actually matching on

To understand why a server-side event can be nearly worthless, look at what the Conversions API payload is scored on.

The key fields:

• fbc: the click identifier, formatted as fb.1.<timestamp>.<fbclid>. This is the single strongest match signal, because it points at one specific ad click.
• fbp: the browser identifier cookie, set by the pixel.
• em, ph, fn, ln, ct, st, zp, country: hashed customer data from checkout.
• external_id: your own stable customer or session identifier.
• client_ip_address and client_user_agent: the end user’s IP and user agent, not your server’s.

Here is the important detail about fbc. In a standard setup, that value does not come from your server. It comes from a cookie named _fbc, which the Meta pixel’s JavaScript writes into the browser after reading fbclid from the URL.

Follow the dependency. No pixel JavaScript execution means no _fbc cookie. No fbclid in the URL means no _fbc cookie. And a server-side tool that reads _fbc at checkout is reading a value that a browser script had to successfully create earlier.

Your “server-side” event’s most important field was collected client-side.

Where the popular setups actually break

To be clear, the tools below are real products that solve real problems. The issue is not that they are badly built. It is that they inherit a capture layer they do not control.

Shopify data layer plus order webhook (the Elevar pattern). Elevar’s own documentation describes how their data layer stores attribution values including UTMs, fbclid and gclid, writing them into Shopify order notes so their server-side destinations can use them later. Order processing then moves out of the browser via Shopify webhooks. The webhook half is genuinely robust. But the click identifier only reaches the order note if the data layer script ran and the parameter was present in the URL when it did. If the parameter was stripped before page load, or the script was blocked, the order note is missing the one field that mattered.

Server-side GTM with GA4 as transport. This is the most common enterprise setup and the most misunderstood. In Meta’s GTM-based CAPI configuration, the GA4 web tag is the transport layer: your browser container sends events to the server container, which forwards them to Meta. wetracked.io’s own setup guide states this dependency outright, noting that if GA4 is missing conversions, Meta CAPI will miss them too. A blocked GA4 web tag means an empty server container. You have built a server-side pipeline whose input is a client-side tag.

Native Shopify Conversions API. Shopify’s built-in Meta integration sends server events, but the identity attached is limited to what Shopify’s own customer event layer collected in the browser. Same dependency, fewer levers to pull.

Pixel plus CAPI “redundant events.” The standard advice is to run both and let deduplication sort it out. That advice is correct as far as it goes, and it is what most vendors recommend. But it only helps when the browser event fires. When it does not, you are back to a lone server event with whatever identity it managed to inherit. And when deduplication is misconfigured, meaning mismatched event_id values or inconsistent event names between the two sources, you get double-counted purchases, which corrupts optimization in the opposite direction.

The failure modes nobody puts in the sales deck

Cookie lifespan. Safari’s Intelligent Tracking Prevention caps cookies written by client-side JavaScript at seven days. When a user arrives through a cross-site navigation carrying a tracking parameter in the URL, that cap tightens further. A _fbc cookie set by the pixel is subject to those limits. Your considered-purchase customer with a fourteen-day window converts as an unmatched event.

Link tracking protection. iOS strips known tracking parameters from URLs in an expanding set of contexts. When it does, the click identifier is gone before your page has rendered a single byte. No browser-based capture method can recover it, because there is nothing left to read.

Server IP substitution. If your server-side tool sends its own cloud IP in client_ip_address instead of the end user’s, you have not just failed to help. You have actively degraded the match, because every one of your conversions now appears to originate from the same handful of data center addresses.

Timestamp drift. Webhook-driven events fire at order creation, which can be seconds to minutes after the actual purchase moment. Meta uses event_time in its matching logic. Consistent drift makes matching harder and can push events outside expected windows.

Consent gating. Many consent management platforms block the data layer script until the user accepts. Server-side transmission does not exempt you from consent obligations, and it also does not recover the identity the blocked script never collected.

What actually fixes capture

If the problem is that identity collection depends on the browser, the fix is to collect identity before the browser gets involved.

That means intercepting the click identifier at the edge, in middleware that runs on the request itself, before the HTML is served and before any script, extension, or blocker has an opportunity to act. At that point the fbclid is still in the request URL. You read it, format it into the fb.1.<timestamp>.<fbclid> structure Meta expects, and set it as a first-party cookie via HTTP response header rather than JavaScript, which puts it outside the ITP client-side script cap.

From there, identity is stitched server-side: click identifier to session to eventual order, held outside the browser where cookie policy and blockers have no reach. The purchase event goes out through the Conversions API carrying the click ID, the real end-user IP, the real user agent, and hashed checkout data, deduplicated internally rather than left to matching rules between two independent event sources.

This is how Nvektor is built, and it is why accounts on it reach Event Match Quality scores of 9.3 rather than the mid-range scores typical of setups that transmit server-side but capture client-side.

A twenty-minute audit you can run yourself

1. Open Events Manager, select your dataset, and check the match quality score on Purchase. Note it.
2. In the same view, look at the parameter breakdown. What percentage of your server events include fbc? This is the number that matters most and the one most people never look at.
3. If you run pixel and CAPI together, confirm both sources share event_id values and that Meta reports events as deduplicated rather than as two separate counts.

If you are server-side and your fbc coverage is low, you do not have a transmission problem. You have a capture problem, and no amount of better delivery will fix it.

Nvektor captures click identifiers at the edge before the browser can lose them, stitches identity server-side, and sends deduplicated CAPI events to Meta, Google and TikTok. To get a read on your current match quality, reach us at hello@nvektor.com.