Meta’s Conversions API is only as strong as the signals you send to it. Two small but mighty parameters—fbc and fbp—often determine whether your events can be accurately matched, attributed, and optimized inside Ads Manager. In this deep-dive guide for the Watsspace Digital Marketing Blog, we’ll explain exactly what fbc and fbp are, why they matter, how to format them correctly, and how to implement them in both browser and server environments. You’ll also find code examples, a practical checklist, and authoritative stats to benchmark your results.

What Are Meta’s fbc and fbp Parameters?

fbc and fbp are identifiers used by Meta to improve event matching for the Pixel and the Conversions API:

fbp is a browser identifier derived from the _fbp first-party cookie. It indicates the browser/session context for a user.
fbc is a click identifier derived from the fbclid parameter appended to URLs when a user lands on your site from a Meta ad. The Pixel can store it in the _fbc first-party cookie.

Sending these values consistently with your server-side events gives Meta stronger signals, which typically means better attribution, more stable performance, and more resilient optimization when client-side signals are limited.

Why fbc and fbp Matter for Conversions API

As privacy changes reduce the availability of client-side identifiers, server-side signals need all the context they can get. The combination of event_name, event_id, user_data (including fbc/fbp), and consent flags drive your Event Match Quality score in Events Manager.

Resilience after iOS 14.5: Opt-out rates for app tracking reached an estimated 80–95% in some apps. Flurry Analytics reported that global iOS opt-in rates remained around 20% through 2022, meaning many users are not providing IDFA-level signals.
Loss of third-party cookies: Chrome maintains the largest desktop browser share globally, often reported near 60–65%. StatCounter shows Chrome dominantly leading, making server-side and first-party data strategies crucial as third-party cookies phase out.
Performance lift: Advertisers who implement Conversions API alongside the Pixel frequently report measurable improvements in event match rates and downstream CPA/ROAS. Meta has shared case examples where blended Pixel + CAPI setups improved cost efficiency; many industry case studies cite 8–20% lifts in attributed conversions depending on the vertical and data quality. Meta Business Help Center

How fbp Works (The Browser ID)

fbp is designed to identify a browser instance via the first-party _fbp cookie set by the Meta Pixel. This cookie is generally set on the first pageview where the Pixel runs and typically persists for roughly 90 days (rolling) unless cleared earlier by the user or privacy controls.

Source: The _fbp cookie in the browser (first-party).
Use: Helps Meta tie server-to-server conversion events back to the correct browser session.
Format: A string that begins with “fb.” and includes a version and timestamp.

When you send server-side events, include fbp in the user_data object if available. This improves event matching even when other signals (like email or phone) are not present.

How fbc Works (The Click ID)

fbc represents the actual Facebook Click ID, derived from the fbclid query parameter that appears on landing page URLs for clicks from Meta ads. The Pixel may store it in the _fbc cookie when fbclid is present.

Source: The fbclid parameter in the landing page URL. The Pixel can convert it into an _fbc cookie.
Use: Provides a direct ad click reference, strengthening attribution for downstream events.
Condition: Only set when fbclid exists. If a user didn’t arrive via a Meta ad (no fbclid), you typically should not generate fbc artificially.

fbp vs fbc: Quick Comparison

Parameter	Purpose	Primary Source	Cookie Name	When Available	Example Format	Send If Missing?
fbp	Browser/session identifier	_fbp first-party cookie set by Pixel	_fbp	After Pixel runs on page	fb.1.1672531200123.1234567890	Optional but recommended; do not fabricate
fbc	Facebook Click ID from ad click	fbclid in URL; stored as _fbc cookie	_fbc	Only when user lands with fbclid	fb.1.1672531200123.ABCD1234efGhIJkLm	Send only when a valid fbclid exists

Formatting Requirements and Examples

Meta expects specific patterns for both parameters. Incorrect formatting is a common reason for Event Match Quality issues.

fbp format: fb.1.<creation_time_millis>.<random_number>
fbc format: fb.1.<creation_time_millis>.<fbclid>

Examples:

fbp: fb.1.1717099212345.987654321
fbc: fb.1.1717099212345.AQzXy1abcDEFghiJKlMNopQ

Notes:

Do not hash fbc or fbp. They are sent as plain strings in user_data.
Do not invent fbc if there was no Meta click. Only send when fbclid is present or when an _fbc cookie exists.
The prefix fb.1 represents the version and is part of the expected format.

Capturing fbp and fbc in Practice

The critical step is reliably capturing these values from the browser and making them available to your server-side endpoint that posts events to the Conversions API.

Reading _fbp and _fbc Cookies in the Browser

Use small, robust utility functions to read first-party cookies.

// Get cookie by name
function getCookie(name) {
  const value = `; ${document.cookie}`;
  const parts = value.split(`; ${name}=`);
  if (parts.length === 2) return parts.pop().split(';').shift();
  return null;
}

// Return fbp and fbc values if available
function getMetaIds() {
  const fbp = getCookie('_fbp');
  const fbc = getCookie('_fbc');
  return { fbp, fbc };
}

// Example usage
const { fbp, fbc } = getMetaIds();
console.log('fbp:', fbp, 'fbc:', fbc);

When fbclid is present on the landing page, the Pixel typically writes the _fbc cookie automatically. If for any reason it doesn’t, you can create an _fbc cookie yourself—but only if fbclid is present.

Building fbc from the fbclid in the URL

If your landing pages include fbclid, you can normalize it into the correct fbc format and set a cookie. Be sure to comply with consent and regional privacy regulations—do not set tracking cookies before the user has granted consent where required.

function getParam(name) {
  const url = new URL(window.location.href);
  return url.searchParams.get(name);
}

function setCookie(name, value, days) {
  const d = new Date();
  d.setTime(d.getTime() + (days*24*60*60*1000));
  const expires = "expires=" + d.toUTCString();
  document.cookie = `${name}=${value}; ${expires}; path=/; SameSite=Lax`;
}

(function initFbc() {
  const fbclid = getParam('fbclid');
  if (!fbclid) return; // Only set _fbc when there is a real fbclid

  const creationTime = Date.now(); // milliseconds
  const fbc = `fb.1.${creationTime}.${fbclid}`;
  setCookie('_fbc', fbc, 90); // common practice ~90 days
})();

This ensures that downstream pages still have access to fbc even after the user navigates away from the initial landing URL.

Persisting Identifiers for Server Use

To send fbp and fbc with server-side events, you need them on your server:

Option A: Send them in a hidden field on your forms and include them with order confirmation payloads.
Option B: Use an authenticated session or local storage sync to post the values to your server via AJAX on pageview.
Option C: Implement server-side GTM or an edge-worker approach that copies the cookies via request headers.

Whichever route you choose, ensure you respect consent and avoid transmitting these IDs if users have opted out.

Sending fbp/fbc with the Conversions API

On the server, include both identifiers inside the user_data object when making your POST to Meta’s events endpoint. Also include event_name, event_time, and consider using event_id for deduplication with your Pixel.

Event Payload Structure

{
  "data": [
    {
      "event_name": "Purchase",
      "event_time": 1717099330,
      "event_id": "order_12345", 
      "action_source": "website",
      "user_data": {
        "fbp": "fb.1.1717099212345.9876543210",
        "fbc": "fb.1.1717099212345.AQzXy1abcDEFghiJKlMNopQ",
        "em": "2bb80d537b1da3e38bd30361aa855686bde0...", 
        "ph": "89b9e71d40ca...", 
        "client_user_agent": "Mozilla/5.0 ...",
        "client_ip_address": "203.0.113.9"
      },
      "custom_data": {
        "currency": "USD",
        "value": 129.99,
        "order_id": "12345"
      }
    }
  ],
  "test_event_code": "TEST123ABC"
}

Notes:

Do not hash fbc/fbp. Fields like em and ph should be SHA-256 hashed (lowercased, trimmed) unless you mark them as unhashed where allowed.
event_id should match between the Pixel and CAPI for the same event to enable deduplication.
Use test_event_code from Events Manager when validating your setup.

Node.js Example (Express + Fetch)

This example demonstrates sending a purchase event with both identifiers. Replace placeholders with your pixel ID and access token.

import express from 'express';
import fetch from 'node-fetch';

const app = express();
app.use(express.json());

app.post('/server-purchase', async (req, res) => {
  try {
    const {
      fbp, fbc, email, phone, value, currency, order_id,
      client_ip, client_ua, event_id
    } = req.body;

    const hashedEmail = email ? sha256(email.trim().toLowerCase()) : undefined;
    const hashedPhone = phone ? sha256(phone.replace(/D/g,'')).toString() : undefined;

    const payload = {
      data: [
        {
          event_name: "Purchase",
          event_time: Math.floor(Date.now()/1000),
          event_id,
          action_source: "website",
          user_data: {
            fbp,
            fbc,
            em: hashedEmail,
            ph: hashedPhone,
            client_ip_address: client_ip,
            client_user_agent: client_ua
          },
          custom_data: {
            currency,
            value,
            order_id
          }
        }
      ]
    };

    const r = await fetch(`https://graph.facebook.com/v19.0/YOUR_PIXEL_ID/events`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ ...payload, access_token: 'YOUR_ACCESS_TOKEN' })
    });

    const json = await r.json();
    res.status(r.ok ? 200 : 400).json(json);
  } catch (e) {
    console.error(e);
    res.status(500).json({ error: 'Server error' });
  }
});

app.listen(3000, () => console.log('Server running on port 3000'));

In production, ensure that hashing and validation utilities are robust and that you handle consent before sending any user_data.

Python Example (requests)

import time
import hashlib
import requests

PIXEL_ID = "YOUR_PIXEL_ID"
ACCESS_TOKEN = "YOUR_ACCESS_TOKEN"

def sha256_str(s: str) -> str:
    return hashlib.sha256(s.encode('utf-8')).hexdigest()

def post_purchase(event_id, fbp, fbc, email, phone, value, currency, ip, ua):
    data = [{
        "event_name": "Purchase",
        "event_time": int(time.time()),
        "event_id": event_id,
        "action_source": "website",
        "user_data": {
            "fbp": fbp,
            "fbc": fbc,
            "em": sha256_str(email.strip().lower()) if email else None,
            "ph": sha256_str(''.join(filter(str.isdigit, phone))) if phone else None,
            "client_ip_address": ip,
            "client_user_agent": ua
        },
        "custom_data": {
            "currency": currency,
            "value": value,
            "order_id": event_id
        }
    }]

    payload = { "data": data, "access_token": ACCESS_TOKEN }
    url = f"https://graph.facebook.com/v19.0/{PIXEL_ID}/events"
    r = requests.post(url, json=payload)
    return r.status_code, r.json()

# Example usage:
# status, resp = post_purchase("order_12345", fbp, fbc, email, phone, 129.99, "USD", ip, ua)

Deduplication, Event Match Quality, and Measurement

Deduplication ensures you don’t double-count events sent by both the Pixel and the Conversions API. Use the same event_id value client-side and server-side for the same event (e.g., the same purchase), and Meta will keep only one record.

Event Match Quality (EMQ): This score (0–10) reflects how well Meta can match your events to users. Strong fbc/fbp coverage, alongside hashed email/phone and IP/UA where consented, raises EMQ. Meta Events Manager
Consistency: Pass fbp and fbc consistently for all eligible events, not just Purchases. Add to key events like AddToCart, InitiateCheckout, Lead, and CompleteRegistration.
Attribution stability: fbc links directly to the ad click, stabilizing reporting across attribution windows.

fbc and fbp are personal data under many privacy regimes because they can identify a device/browser or user journey. Treat them with the same rigor as other user identifiers.

Consent management: In regions covered by GDPR, ePrivacy, or similar laws, only set the _fbp and _fbc cookies after the user grants consent. If consent is withdrawn, stop sending and clear identifiers where required.
Data retention: Keep identifiers for only as long as necessary. While the cookies commonly persist up to ~90 days, ensure your internal storage aligns with your policies.
Transparency: Update your privacy policy to name the data collected, purposes, and partners (Meta), including cookie usage and opt-out instructions.
US state laws: For CCPA/CPRA and other state privacy laws, honor “Do Not Sell or Share” and GPC signals, and configure limited data use where appropriate.

Validation, Debugging, and Common Errors

Test carefully before moving to production. Meta provides tools for validation and troubleshooting.

Test Events: Use a test event code from Events Manager and send events from your server or via Postman. Confirm fbc/fbp are present in the event payload details. Meta Events Manager
Pixel Helper: Validate the Pixel is setting _fbp and, when applicable, _fbc.
Format errors: A very common issue is invalid formatting:
- fbp must match something like: fb.1.13-digit-timestamp.random
- fbc must match: fb.1.13-digit-timestamp.fbclid
Regex validation examples:
- fbp: /^fb.1.d{13}.d+$/
- fbc: /^fb.1.d{13}.[A-Za-z0-9_-]+$/
Missing fbclid: Don’t fabricate fbc if the user didn’t come from an ad. It’s acceptable to send only fbp in those cases.
Dedup conflicts: If event_id differs between Pixel and CAPI for the same purchase, you’ll see duplicates. Standardize how you generate event_ids.

Security and Data Quality Tips

Data quality and integrity drive match rates and optimization outcomes. Treat fbc/fbp like any other critical analytics signal.

Integrity: Use server-side validation to ensure fbp/fbc conform to patterns before sending.
Transport: Always send Conversions API events over HTTPS.
Access control: Restrict who can access server logs that might include fbc/fbp; rotate access tokens and keep them in secure vaults.
Latency: Avoid long delays between ad click and conversion event submission. Meta recommends sending conversion events as quickly as feasible.
Consistency: Use the same domain settings and ensure cookies are set with appropriate path, SameSite, and secure flags where applicable.

Realistic Implementation Patterns

Depending on your stack and resources, you can implement fbc/fbp capture in several ways.

Direct Pixel + Server Endpoint:
- Pixel sets _fbp and sometimes _fbc.
- Your site captures them (e.g., via hidden inputs on checkout).
- Your server posts to CAPI on order confirmation.
Server-Side Tagging (SST):
- Use a server container or edge proxy that receives browser events.
- Read fbp/fbc from request cookies and forward them to CAPI.
- Smoothly handle consent gating and data minimization.
Headless/SPA setups:
- Persist fbp/fbc in a secure storage layer and pass them with API calls.
- Ensure client-side navigation doesn’t lose first hit’s fbclid-derived fbc.

Code Snippets You Can Reuse

Below are small utilities to safely capture and validate fbc/fbp before sending them to your server.

// Extract fbp/fbc with validation
function validateFbp(val) {
  return /^fb.1.d{13}.d+$/.test(val);
}
function validateFbc(val) {
  return /^fb.1.d{13}.[A-Za-z0-9_-]+$/.test(val);
}
function getSafeMetaIds() {
  const fbp = getCookie('_fbp');
  const fbc = getCookie('_fbc');
  return {
    fbp: fbp && validateFbp(fbp) ? fbp : null,
    fbc: fbc && validateFbc(fbc) ? fbc : null
  };
}

Server-side express middleware to attach identifiers from cookies if present:

function parseCookieHeader(cookieHeader) {
  const out = {};
  if (!cookieHeader) return out;
  cookieHeader.split(';').forEach(pair => {
    const [k, ...rest] = pair.trim().split('=');
    out[k] = decodeURIComponent(rest.join('=') || '');
  });
  return out;
}

function metaIdMiddleware(req, res, next) {
  const cookies = parseCookieHeader(req.headers.cookie || '');
  req.metaIds = { fbp: cookies['_fbp'] || null, fbc: cookies['_fbc'] || null };
  next();
}

Frequently Asked Questions About fbc and fbp

Do I need both fbc and fbp? No, but having both often yields better match rates. fbp helps even when there was no ad click. fbc is very valuable when it exists because it’s a direct click reference.
Should I hash fbc/fbp? No. These are sent as clear strings. Only hash PII fields such as email or phone.
What if the user deletes cookies? Then fbp/fbc may be lost. This is expected. Your implementation should be robust to missing values.
Is fbc required for all events? No. Only send it when the user arrived via a Meta ad with a valid fbclid (or your Pixel set _fbc).
Does fbp replace cookies? No. fbp itself is a value from a first-party cookie. It helps inform Meta’s matching for server-side events.
Where can I see if these are being received? In Events Manager under diagnostics and the Test Events tool. Meta Events Manager

Benchmarks, Research, and What “Good” Looks Like

You can use the following references to gauge whether your fbc/fbp implementation is paying off:

Event Match Quality (EMQ): Aim for a score above 6 for your key events. Improvements in fbc/fbp completeness typically move this number. Meta Events Manager
Attribution window stability: After implementing CAPI with fbc/fbp, many advertisers see less volatility in 1-day click/7-day click reporting and more events attributed in Ads Manager vs. analytics platforms with stricter tracking prevention. Meta Business Help Center
Performance lift: Case studies commonly cite 8–20% increases in matched events and/or improvements in CPA/ROAS when CAPI runs alongside the Pixel with high-quality user_data. Actual results vary by sector, traffic mix, and consent rates. Meta Business Help Center
iOS tracking opt-in: Flurry Analytics has reported iOS app tracking opt-in rates around 20% in aggregate, underscoring the importance of server-side and first-party identifiers. Flurry Analytics
Market context: Chrome’s dominant share, often near 60–65% globally, means browser privacy changes strongly influence results. StatCounter

Edge Cases and Advanced Considerations

A few less common but important scenarios can affect fbc/fbp behavior and quality.

Cross-domain journeys: If your funnel spans multiple domains, ensure your fbp/fbc are preserved on the conversion domain. Consider passing them via query parameters upon redirect or using first-party server-side tagging on each domain.
Subdomains: Set cookie domain to the parent domain (e.g., .example.com) when legitimate, so that checkout.example.com and www.example.com share the same values.
SPA frameworks: Ensure virtual pageviews don’t interrupt cookie writing. On first render with fbclid present, write _fbc synchronously after consent.
Offline conversions: For phone or in-store conversions that originated from web traffic, retain the fbp/fbc (where lawful) with the lead/customer record for later Conversions API uploads.
Rate limiting and batching: For high-traffic sites, send events in batches and monitor Graph API rate limits. Keep event_time close to real-time for best results.

Quality Assurance Checklist for fbc/fbp

Consent respected: Cookies set only after lawful consent (where required). Document your logic.
Cookie presence: Confirm _fbp appears on first pageview with Pixel; _fbc appears only when fbclid is present.
Correct formatting: Validate with regex before sending to your server.
Server receive path: Ensure fbc/fbp are passed to your server endpoint via form fields, headers, or AJAX.
Event payloads: Inspect server logs (sanitized) to verify user_data includes fbp/fbc.
Test Events: Use a test event code and confirm events in Events Manager.
Deduplication: Confirm the same event_id is used client and server for the same transaction.
Monitor EMQ: Track scores pre- and post-implementation; investigate dips promptly.
Diagnostics: Resolve warnings about invalid or missing fbc/fbp promptly.

Common Mistakes to Avoid

Hashing fbc/fbp: These values must not be hashed. Doing so will break matching.
Fabricating fbc: Only set fbc when a real fbclid exists. Making one up degrades data integrity.
Ignoring consent: Setting these cookies without lawful basis in regulated regions risks non-compliance.
Inconsistent event_id: If you don’t share event_id between Pixel and CAPI, you risk duplicates.
Missing user agent/IP: Where lawful, include client_user_agent and client_ip_address to bolster match quality.

Simple Troubleshooting Flow

Check Pixel: Is the Pixel firing? Is _fbp set? When fbclid exists, is _fbc set?
Test URL: Manually append ?fbclid=test123 to a landing URL (in a dev environment) to verify _fbc creation after consent.
Inspect cookies: Confirm formatting starts with fb.1 and includes a 13-digit timestamp.
Server logs: Confirm user_data.fbp/fbc are arriving at your server and in CAPI payloads.
Events Manager: Use Test Events to verify receipt; review Diagnostics for formatting errors.
Compare attribution: Track changes in EMQ and matched events week over week.

Sample End-to-End Flow

Here’s a minimal outline of how data should travel in a robust setup:

User clicks a Meta ad and lands on your site with fbclid in the URL.
User consents to tracking; your site sets _fbp and constructs _fbc using the fbclid.
User completes a purchase; your client-side code collects fbp/fbc (and any PII, hashed as required) and posts them to your server along with event_id.
Your server sends the Purchase event to Conversions API with user_data including fbp/fbc, IP, UA, and hashed PII where lawful.
Pixel also sends the Purchase with the same event_id; Meta deduplicates and attributes correctly.

Key Takeaways and Action Plan

Implement both fbp and fbc: fbp is broadly useful; fbc is crucial when users arrive from Meta ads.
Format precisely: Both must begin with fb.1; include a 13-digit timestamp; use fbclid for fbc.
Respect privacy: Gate cookie creation and data transmission behind consent.
Deduplicate reliably: Share event_id between Pixel and CAPI to prevent double counting.
Monitor EMQ: Use Events Manager diagnostics to validate and iterate.

A Final Word on Strategy

fbc and fbp are not just technical niceties; they’re strategic levers. In a world of signal loss and tightening privacy standards, these two parameters help your server-side conversion data carry the context Meta needs to optimize your campaigns. Combined with hashed PII, accurate event_ids, and consent-aware capture, they can materially improve your Event Match Quality and make your reporting and optimization more resilient.

If you take one step today, ensure your site is correctly setting and persisting _fbp, deriving _fbc from fbclid when present, and passing both from browser to server right into your Conversions API payloads. Then measure the lift in Event Match Quality and matched conversions—those metrics will tell you you’re on the right track.

Check out other posts

Meta Conversions API fbc and fbp Parameters