Meta Conversions API Parameters: How to Send fbc and fbp Correctly

If you send events to Meta from your server, through the Conversions API (CAPI), Meta has to work out who each event belongs to. Two small values do a lot of that work: fbc (the click ID) and fbp (the browser ID). They are easy to get wrong, and a wrong value is as useless as no value at all.

This guide explains both values, where to read them, how to build fbc yourself when there is no cookie, and how to check that Meta is actually receiving them.

What fbc and fbp are

First, the two ways to send events to Meta:

• The Meta Pixel is code that runs in the visitor’s browser. It sends events like Purchase or Lead straight from the page.
• The Conversions API sends the same kind of events from your server, your store platform or your CRM. It doesn’t depend on the visitor’s browser, and it can send events that never happen on a web page, like a sale closed by phone.

A server event has no browser attached, so it must carry details that let Meta match it to a person. Meta calls these customer information parameters. Most of them, like email and phone, must be hashed: turned into a fixed code with SHA-256 so the raw value isn’t sent. Four of them are sent as plain text instead: the two IDs in this guide, plus the visitor’s IP address (client_ip_address) and browser details (client_user_agent). The two IDs:

Parameter	Meta’s name	What it identifies	Example
fbc	Click ID	One click on a Meta ad	fb.1.1554763741205.IwAR2F4-dbP0…
fbp	Browser ID	One browser on your site	fb.1.1596403881668.1116446470

Meta’s parameters page marks fbc, fbp, client_ip_address and client_user_agent all as “Do not hash”, and says the IP address must never be hashed.

How much do they matter? Meta’s server-side GTM guide ranks each customer parameter by how much it helps Event Match Quality. The click ID is “High”, next to email. The browser ID is “Medium”. Event Match Quality is Meta’s score out of 10 for how well your server events can be matched to a Meta account, as its Dataset Quality API page describes.

Where the values come from

fbc starts in the URL. When someone clicks a Meta ad, Meta adds fbclid= to the landing page address. Meta’s fbp and fbc page says the pixel automatically stores this click ID in the _fbc browser cookie once it is available. Your server can read that cookie with each request.

fbp starts in the pixel. The pixel saves a unique ID in an _fbp cookie for your domain. It uses first-party cookies, meaning cookies that belong to your own site. No pixel, no _fbp.

No cookie? Read the URL. If the _fbc cookie isn’t there, for example because your site has no Meta Pixel, Meta says you can still send fbc as long as the landing page URL had an fbclid. Read it from the part of the page address after the ? on your server. Meta also highly recommends setting the _fbc cookie yourself from your server in that case, and suggests a 90-day expiration time. Only do this for visitors who have agreed to marketing tracking, where your consent rules require it. A cookie your server sets is still a cookie, so it needs the same consent as one the pixel sets. Ask your privacy adviser if you are unsure.

Meta notes that these values can change across browser sessions, so read the latest cookie value when you send each website event.

A word on consent: if your cookie banner keeps the Meta Pixel switched off until a visitor agrees, visitors who say no won’t have _fbc or _fbp cookies. That is expected. Don’t try to work around a visitor’s choice. Ask your privacy adviser how your banner should treat server-side events too. For the Google side of this topic, see Consent Mode v2 for small businesses.

How to send them in an event

fbc and fbp go inside user_data, the block of each server event that describes the person, next to the other customer details. A trimmed example, using the sample values from Meta’s documentation:

{
  "event_name": "Purchase",
  "event_time": 1792422000,
  "event_id": "ORDER-1001",
  "action_source": "website",
  "event_source_url": "https://www.example.com/checkout/thank-you",
  "user_data": {
    "em": ["62a14e44f765419d10fea99367361a727c12365e2520f32218d505ed9aa0f62f"],
    "fbc": "fb.1.1554763741205.IwAR2F4-dbP0l7Mn1IawQQGCINEz7PYXQvwjNwB_qa2ofrHyiLjcbCRxTDMgk",
    "fbp": "fb.1.1596403881668.1116446470",
    "client_ip_address": "168.212.226.204",
    "client_user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) …"
  },
  "custom_data": { "value": 142.50, "currency": "USD" }
}

The fbc and fbp values are Meta’s own samples, which is why their click times (2019 and 2020) are much older than the event. In a real event, the click comes shortly before the purchase.

Three details in that example trip people up:

• em is hashed; fbc, fbp, client_ip_address and client_user_agent are not. If your code hashes everything in user_data, add an exception for all four.
• event_time is in seconds, but fbc’s time is in milliseconds. Meta’s server event page defines event_time as a Unix timestamp in seconds. The time inside fbc uses milliseconds. Same idea, different units, in one event.
• Website events need two more fields. Meta requires event_source_url and client_user_agent for website events sent through the Conversions API.

Building fbc from an fbclid

Most store platforms and tag setups read the _fbc cookie for you. You only build fbc yourself when your server has the fbclid but no cookie. Meta’s format is:

fb.<subdomain index>.<creation time>.<fbclid>

Step by step, with Meta’s own example click ID:

1. Start with fb. This part is always the same.
2. Add the subdomain index. It says which domain level the cookie was set on. Meta’s rule is simple: if you build the value on a server and don’t save an _fbc cookie, use 1.
3. Add the creation time. This is when you first saw the fbclid, counted in milliseconds since January 1, 1970 (the usual way computers store time, called Unix time). Today that is a 13-digit number like 1554763741205. A 10-digit number is seconds and is wrong here.
4. Add the fbclid exactly as it appeared. Meta says the click ID “is case sensitive”. Don’t change capital letters, decode characters or trim it.

Result:

fb.1.1554763741205.IwAR2F4-dbP0l7Mn1IawQQGCINEz7PYXQvwjNwB_qa2ofrHyiLjcbCRxTDMgk

The fbc and fbp builder does these steps for you from a landing page URL. It converts a seconds timestamp to milliseconds, and its check mode tests a column of fbc and fbp values from your server logs, all in your browser.

One more format to know: Meta offers free code, the Parameter Builder Library, that builds these values for developers. Values it makes end with an extra part, called an appendix. It is 8 characters, or 2 in older versions. That is expected; send it as is.

Leads and CRM events

For a lead business, the sale often happens days or weeks after the click, in your CRM. By then the visitor’s browser and cookies are long gone. So the rule is: capture fbc and fbp when the lead arrives, and store them with the lead.

A simple setup:

1. Add two hidden fields to your lead form, such as fbc and fbp.
2. Fill them when the form loads, from the _fbc and _fbp cookies. If there is no _fbc cookie but the page URL has fbclid, build the fbc value from it, using the time of that first visit. Do this only for visitors who agreed to marketing tracking, where your consent rules require it. A visitor who declined has no cookies for a reason.
3. Save them in plain text fields in your CRM. Some CRMs and spreadsheets change case or turn characters into codes. Test with a real value and compare it character by character.
4. Send them with every later event for that lead, such as a qualified lead or a closed sale, along with the hashed email and phone.

Watch the time limit. Meta’s server event page says event_time can be up to 7 days before you send the event. If even one event in a request is older, Meta returns an error for the entire request and processes none of the events. So send CRM events soon after they happen, and don’t batch old ones with new ones. For sales in a physical store, Meta’s offline events guide asks for physical_store as the action source. Pick the action source that truly describes where the event happened; Meta asks you to confirm it is accurate.

fbp and deduplication

Many sites send the same Purchase twice: once from the pixel and once from the server. That works, as long as Meta can tell the two copies apart. Meta’s deduplication guide describes two ways:

• Best: the event ID. The pixel event’s eventID and the server event’s event_id must match, along with the event name. Meta keeps one copy when both arrive within 48 hours. An order number works well.
• Alternative: fbp or external ID. Meta can also use the event name with fbp and/or external_id, sent the same way from the browser and the server. This only works when the browser event arrives first: Meta keeps a server event if it hasn’t received a matching browser event in the past 48 hours.

So a correct fbp helps twice: with matching and with deduplication. For the browser side, the pixel event code generator for Meta writes the fbq() call with the eventID in the right place, plus the matching server event. Our pixel event codes cheat sheet covers other platforms.

Mistakes that lower match quality

Three of the biggest mistakes were covered above: hashing values that must stay plain, creation times in seconds instead of milliseconds, and an fbclid that was lowercased or edited on its way into your CRM. Four more to check:

• Making up an fbc when there was no click. No fbclid means no fbc. Don’t reuse an old click ID for a new visitor or fill the field with a placeholder. Send fbp and the other customer details instead.
• Using the sale date as the click time. The creation time is when the click was first seen, not when the lead converted. Store the time at the first visit along with the fbclid.
• Cutting off the appendix. A five-part value from the Parameter Builder Library is valid. Removing the last part to make it “look right” changes the value.
• Swapping the two fields. Both start with fb.1., so they are easy to mix up. In fbc, the last part is the long click ID with letters. In fbp, it is a plain number.

How to check it is working

1. Check the values first. Paste a sample of fbc and fbp values from your server logs into the fbc and fbp checker. Every row should pass the format check before you look in Events Manager.
2. Send a test event. In Events Manager, open your dataset and the Test events tab to get a test code. Send one event with test_event_code at the top level of the request, and check that it shows the click ID and browser ID. Meta’s using the API page says to use that field only for testing, so remove it before going live.
3. Watch Event Match Quality. A few days after launch, open the event in Events Manager. The score is out of 10 and is only available for web events, per Meta’s Dataset Quality API page.
4. Look for the “FBC coverage” warning. Meta’s diagnostics use this name when the fbc click ID is present on too small a share of events. If you see it, check where your server loses the value: a missing cookie read, a form that doesn’t save it, or a CRM field that changes it.

If the warning stays after a fix, test one lead or order end to end: from the ad click, through the form and the CRM, to the event in Events Manager.