Server-side tracking for Facebook ads

Server-side tracking for Facebook ads is a setup where your server, not a script in the visitor’s browser, sends conversion events to Meta through the Conversions API. It recovers events that ad blockers and browser limits take from the Meta Pixel. It doesn’t change consent rules, Meta’s attribution settings or the conversions Meta models.

The term covers two separate things, and plenty of setups only do one. The first is where the event is sent from: your server instead of the browser. The second is where the identifiers live: a click cookie set by your server, on your domain, instead of one written by JavaScript. Meta’s setup options handle the first. Safari’s rules decide the second. Both are part of server-side tracking in the sense that matters for attribution.

What server-side tracking means on Meta

With the Pixel alone, the browser does all the work: the script loads, reads Meta’s cookies and reports the Lead when the form is sent. If the script never loads, nothing is reported.

With the Conversions API, your server sends the event: its name, its time, an event_id, and the customer information Meta uses to match it to a person (hashed email and phone, the click identifier, IP address, user agent). Meta says website events sent this way are linked to your Pixel and behave like Pixel events: they’re used for the same kinds of optimization and appear in Ads Manager and Events Manager (About Conversions API). The payload itself is in our Meta CAPI entry.

Server-side tracking options for Facebook ads, compared

Meta’s comparison of setup options lists a one-click Meta-enabled option, partner integrations (Google Tag Manager among them) and direct integration. The Conversions API Gateway is documented separately on Meta for Developers. In practice:

For lead gen, the method matters less than where the event starts. The Meta-enabled option and the Gateway both start from the Pixel: they forward what the Pixel collected in the browser. If an ad blocker stopped the Pixel script, there’s usually nothing to forward. The sturdier setup sends the Lead from the server that received the form, using identifiers it stored when the click arrived. That means a direct integration, or a tool that runs one for you.

What server-side tracking fixes, and what it doesn’t

Safari ITP: the cookie has to come from your server

WebKit’s tracking prevention rules treat cookies differently depending on who writes them:

• Cookies created by JavaScript are deleted after 7 days without user interaction with the site.
• When ITP detects a click ID in the URL (link decoration), cookies that JavaScript creates on that landing page are capped at 24 hours. fbclid is a click ID.
• Cookies set in an HTTP response escape those caps, unless the request goes to a subdomain that resolves through a CNAME to a third party, or to a third-party IP address. Then they’re capped at 7 days as well.

The Pixel is JavaScript, so the cookies it writes fall under the first two rules. A server container on sst.yourdomain.com that points to a hosting provider can fall under the third. None of those caps applies to a cookie set in the HTTP response of the landing page itself, by the host that serves it.

That’s the design behind first-party tracking in DropCPL: the landing page is served from the tracking domain, and the click cookie (first-party, HttpOnly) is set in the same response that renders it, with no redirect in between. The history of what broke and when is in tracking after iOS, and ITP has the short definition.

Consent and opt-outs

Moving the call to your server changes how the data travels. It doesn’t change whether you’re allowed to send it. Meta’s help center says the Conversions API, like the Pixel, isn’t designed to bypass Apple’s App Tracking Transparency or privacy rules in Europe such as the ePrivacy Directive, and that server events follow the same off-Facebook activity and partner-data controls as Pixel events (About Conversions API). If your consent banner holds the Pixel back until someone accepts, the server event for that visitor needs the same gate. How to build that gate is a question for your privacy counsel.

Attribution and modelled conversions

Server events land in the same attribution machinery as Pixel events. Meta’s default setting is 7-day click, 1-day view and 1-day engagement, and where results can’t be measured directly because of partial or missing data, Meta may use statistical modeling for some of them (Results). Server-side tracking makes Meta’s number better informed. It doesn’t turn Ads Manager into a count of the leads you received; your own first-party count does that job, as real CPL vs platform CPL explains.

Server-side tracking works best when the server that logs the click is the one that renders the landing page. DropCPL does both on your tracking domain, then sends the Lead to Meta through the Conversions API with an event_id and the fbc and fbp values. Start free →

Deduplication: the event_id the Pixel and the server share

Meta recommends the redundant setup, with the Pixel and the Conversions API sending the same events (Handling duplicate events). Two copies of one Lead then reach Meta, and it keeps one only when:

• the Pixel’s event name matches the server’s event_name (Lead and Lead),
• the Pixel’s eventID matches the server’s event_id,
• both arrive within 48 hours of the first event with that ID.

Browser: fbq('track', 'Lead', {}, { eventID: 'lead_7f3a91' })
Server:  { "event_name": "Lead", "event_id": "lead_7f3a91", "action_source": "website", "user_data": { ... } }

The simplest way to get matching IDs: let the server create the lead first, use the lead’s ID as event_id in the API call, and hand the same ID to the browser for the Pixel. Meta also supports deduplication on fbp or external_id, but that method generally works only when the browser event arrives first, and a server that sends the Lead the moment the form arrives will often beat the browser.

Without a shared ID, Meta can count one lead twice, and the CPL in Ads Manager looks better than it is. Meta Pixel and CAPI deduplication walks through testing it in Events Manager.

Match quality: what the server event has to carry

A server event that Meta can’t match to an account is attributed to nobody. Meta calls the successful ones matched events, and says the Conversions API lets you include customer information parameters that raise both your matched events and your Event Match Quality (About Conversions API).

For a Lead from a landing page form, send what you legitimately collected, formatted the way Meta’s customer information parameters specify:

• email and phone, normalized and hashed with SHA-256;
• the click ID (fbc) and the browser ID (fbp), not hashed;
• the visitor’s IP address and user agent, not hashed, captured when the form was submitted (the user agent is required for website events);
• an external_id, such as your lead ID, where Meta recommends hashing.

The click identifier is the one that ties the event to a specific ad click, and it’s the one most often missing. If fbclid wasn’t stored when the click arrived, no amount of server code recovers it later, which is one more reason to capture it on the server that renders the landing page. fbc and fbp cookies explained covers the format, and Meta Event Match Quality covers scores and fixes.

The setup we’d pick for lead gen on Meta

1. Serve the landing page from your own domain, and log the click (with fbclid and the ad ID) on the server that renders it.
2. Set the click cookie in that same response: first-party, HttpOnly, no redirect hop.
3. Post the form to the same server and create the lead there, with an ID.
4. Send the Lead to the Conversions API from that server, with the lead ID as event_id, plus hashed email and phone, fbc, fbp, IP address and user agent.
5. If the Pixel also fires, give it the same eventID.
6. Decide budgets on the leads you counted, and keep the Ads Manager figure as a diagnostic.