_fbp (Facebook Browser ID) and _fbc (Facebook Click ID) are the two most critical first-party cookies used by Meta to match conversions to ad impressions. To recover them in server-side tracking, your server gateway must capture the fbclid URL parameter on arrival, write it into a secure first-party HTTP-only cookie with a 90-day expiration, and attach both cookies to all outbound CAPI payloads.
1. Why Modern Browsers Erase Ad Click Cookies
When a user clicks an ad on Instagram or Facebook, Meta appends a unique click parameter to the URL: `?fbclid=IwAR...`. The client-side pixel reads this parameter and creates an `_fbc` cookie.
However, Apple's Safari Intelligent Tracking Prevention (ITP) caps client-side JavaScript cookies created from URLs with click parameters to just 24 hours. If the user deliberates, compares prices, and purchases 48 hours later, the click cookie is gone, and Meta cannot attribute the sale to your ad campaign.
- 24-Hour Safari Expiration: High-ticket consideration cycles broken by aggressive ITP cookie deletion.
- Missing Click Attribution: Ad campaigns show 0 ROAS despite generating real sales.
- Cross-Device Disconnect: Inability to link mobile ad clicks with desktop purchases.
2. Comparative Analysis: Standard Tracking vs CAPI Control
The table below outlines the architectural and financial differences between passive conversion tracking and active signal governance:
| Cookie Identifier | Creation Source | Default Client-Side Lifespan | CAPI Control Server-Side Lifespan |
|---|---|---|---|
| _fbp (Browser Cookie) | Set on initial domain visit | 7 days (Safari ITP) | 90 days (HTTP-only server cookie) |
| _fbc (Click ID Cookie) | Created from `?fbclid=` parameter | 24 hours (Safari ITP cap) | 90 days (Cryptographically preserved at edge) |
| Attribution Impact | Direct link to specific ad impression | Lost on 40%+ of Safari purchases | 100% recovered attribution match |
3. Edge Server-Side Cookie Setting Architecture
CAPI Control intercepts the incoming HTTP request at the edge, parses the `fbclid` query parameter, and issues an HTTP `Set-Cookie` header that Safari treats as an immutable first-party server cookie:
// Edge Worker: Server-Side _fbc Cookie Injection
export function handleIncomingClick(request) {
const url = new URL(request.url);
const fbclid = url.searchParams.get("fbclid");
const response = new Response(request.body);
if (fbclid) {
const timestamp = Math.floor(Date.now() / 1000);
const fbcValue = `fb.1.${timestamp}.${fbclid}`;
// Set HTTP-only, secure, first-party cookie with 90-day lifespan
response.headers.append("Set-Cookie",
`_fbc=${fbcValue}; Path=/; Max-Age=7776000; Secure; SameSite=Lax; HttpOnly`
);
}
return response;
}
How to Deploy CAPI Control to Fix This Today
- Step 1: Verify that your store's server is capturing and setting `_fbc` via HTTP headers.
- Step 2: Deploy CAPI Control to automatically persist `_fbp` and `_fbc` for 90 days.
- Step 3: Ensure outbound CAPI payloads include both cookie values.
- Step 4: Watch attributed ROAS increase by 15% to 25% on campaigns with long consideration cycles.
Frequently Asked Questions
What is the exact format of the `_fbp` cookie?
It follows the format `fb.{subdomain_index}.{creation_timestamp}.{random_number}`, for example: `fb.1.1712345678.987654321`.
Does Safari ITP cap server-set HTTP-only cookies?
No! Server-set HTTP cookies delivered via an A-record on the same first-party IP address bypass Safari's 24-hour JavaScript cookie caps, preserving up to 90 days of attribution.
What happens if an ad click doesn't have an `fbclid`?
If there is no click parameter, only the `_fbp` browser cookie is sent, which Meta still uses for demographic and device matching.
Ready to steer Meta & Google toward your most profitable traffic?
Drop in CAPI Control in under 2 minutes. Transmit 100% of conversion signals free forever, or activate autonomous signal AI agents to get 3x better ad traffic.