Uliana Lesiv
AuthorKey takeaways
Understanding how attribution works helps explain why reporting sometimes looks inconsistent.
The core idea behind attribution in Meta Ads is matching clicks to conversions. Meta connects two events:
To make this connection, Meta uses identifiers like fbclid (click ID from ads), fbc (stored click identifier), fbp (browser identifier cookie), and hashed user data (email, phone).
It works the following way:
When a user clicks a Meta ad, the URL includes a fbclid parameter. The sGTM tag (or fbevents.js if it's web tracking) converts it into an fbc cookie. At this point, Meta records the click event with a timestamp and ad metadata; the user is tagged for potential attribution.
If the user converts later (e.g., purchases), Meta receives the event through Meta Pixel (client-side tracking) and Conversions API/CAPIG (if configured). Each event includes signals such as browser data (fbp), click data (fbc), and user data (email/phone hashed). Meta tries to match this conversion to a previous ad interaction. If it succeeds, a conversion is attributed to a specific ad campaign.
That's a simplified explanation of how attribution works; of course, the logic of conversion attribution will depend on attribution settings and attribution windows configured in your account.
The attribution can be inaccurate, usually because some of the steps don't work properly (like Meta struggles to attribute the conversions because the conversion payload is missing required parameters). In the next section, we consider likely causes, their troubleshooting, and fixing in detail.
Probably the most obvious reason why the conversions aren't attributed correctly - the Meta Pixel (and Meta CAPI/CAPIG if you have it configured) doesn't fire or fires but with problems, as a result, you receive fewer or don't receive conversions in Meta at all.
Although it is a super basic cause, it's always worth starting with it. Below, we show how to troubleshoot this problem.
If you know that a large share of your leads/clients are using iOS, the cookie limitation (ITP) that Apple has applied since 2021 can impact the data tracking and, as a result, attribution within Meta.
Third-party cookies are largely unavailable in Safari. Without third-party cookies, attribution becomes less reliable unless alternative user identifiers are available:
_fcb) - Safari significantly impacts the lifespan of cookies, which can lead to losing the click ID value before a conversion occurs. When this happens, attribution accuracy drops.In the article below, we show how to figure out whether the data required for accurate attribution is sent to Meta and some options to prolong the lifespan of cookies.
As mentioned earlier, Meta relies on identifiers such as fbc and fbp to match conversions to ad clicks and browser sessions.
When these parameters are missing or not passed in the event payload, Meta loses matching signals. This typically results in lower Event Match Quality and unattributed or "other" conversions.
Webhooks are typically used for offline conversion tracking (conversions made via offline stores or phone calls, for example). Similar to online conversions, webhook's payload should include fbc/fbp parameters for accurate attribution in Meta. We've listed it as a separate problem because troubleshooting in case of a webhook differs.
❗Note: in the sections below, we show problems troubleshooting on the client- + server-side tracking configuration (not client-side with Meta Pixel only). Client- + server-side tracking is a more reliable way to track conversions in Meta that can also improve the attribution.
If you are considering switching or just would like to know more about server-side tracking for Meta, expand the collapse element below for details:
With server-side tracking, the conversion data is sent from your server to Meta using the CAPI, instead of relying only on browser-based tracking like the Meta Pixel.
In a client-side setup, the Pixel runs in the user's browser and tracks events (e.g., page views, add-to-cart events, purchases, etc.). However, this method relies on cookies and JavaScript execution. If a visitor uses ad blockers, the tracking scripts will be blocked.
Server-side tracking changes this by moving part of the tracking process to your backend. When a conversion happens, your server sends the event directly to Meta, including important data such as fbc and fbp that are essential for correct attribution.
Server-side configuration for Meta works in combination with the Meta Pixel (recommended combo by Meta). The Pixel captures real-time browser signals, and the server sends a more reliable confirmation of the event. These two sources are then connected using an event_id, which allows Meta to deduplicate events.
There are a few ways to configure server-side tracking for Meta:
👉 Stape's offer: Stape offers a free plan to get started with server-side tracking. It will be free of charge if you don't exceed 10,000 requests per month. Calculate the number of requests using Stape's calculator.
👉 Stape's offer: Stape provides a 7-day free trial and $8 per month/Pixel.
👉 Stape's offer: Stape provides a free option with up to 10K events per month.
For a more detailed comparison of server-side tracking options, refer to our guide on Meta tracking setup options comparison.
1. GTM Preview Mode
Why use it: GTM Preview Mode allows you to see what happens in the browser and on the server when a user interacts with your site. It helps you verify whether Meta Pixel events are firing correctly, check whether fbc/fbp, and debug the setup.
Why use it: it makes your troubleshooting way easier. You can quickly identify which tags fired or failed, inspect request payloads (including Meta events) with formatted JSON and URL parameters. If you run a website on Shopify, it will be especially helpful for debugging the checkout page.
3. Stape Logs
Why use it: compared to other server-side tracking solutions (like GCP or other infrastructure providers), which may offer incoming logs only (the requests your server-side GTM receives), Stape provides both incoming and outgoing logs (what is actually sent from your server to platforms) without the need to request the data via support.
In the context of Facebook attribution troubleshooting, Stape Logs will help you analyze whether the conversion sent to Meta actually contains fbc/fbp parameters. You can view the actual requests/events that were sent to Meta and their payload.
4. Stape Store (for webhooks)
Why use it: in Stape Logs, the POST request body isn't logged by default. To log it, you need to use the Logger tag. In this way, the full webhook payload will be stored in the Stape Store. So, within the Stape Store, you can debug the problem with the webhook configuration.
1.1 Run Preview mode in both web and server GTM containers.
1.2 Enable the Stape Chrome extension for easier debugging.
You can select the options that work for your case. Also, you can easily debug the checkout page for Shopify with this Chrome extension.
Check key features and use cases of Chrome extensions in our article.
1.3 Trigger the events on the website. You should see that Meta tags (Pixel and CAPI) are triggering:
In the web GTM container:
And in the server GTM container:
1.4 Look through the event IDs in the web and server GTM containers.
Meta recommends using both Meta Pixel and Meta CAPI for more accurate tracking, but without an appropriate setup (with a unique identifier), the events can be duplicated. We have the event_id variable configured as an identifier.
You should see that the event_id for the same event is identical in the web and server GTM containers. If you don't have it configured, refer to our guide on setting up Facebook event deduplication in GTM.
Web container Pixel tag:
Server container with Meta CAPI tag:
1.5 For more precise troubleshooting, check also the Stape Logs.
In this way, you can see whether some errors happen when users trigger the events. In some cases, the setup can work perfectly fine in a testing environment, but errors can occur in real life.
For your convenience, use filters: filter by platform and conversion you send to Meta, also specify the status, you are looking for requests with errors. The common errors are:
If there are some requests with errors, you can see their number over a specific date and click on More for the detailed troubleshooting. Also, you can download the report in CSV format to debug in Google Sheets, for example.
To avoid manual work, you can get reports on the request statuses for each platform using the Monitoring feature (available on Business plan or higher). It's an aggregate view of the requests sent to the platform, how many of them failed, and what the success rate is (percent of requests that were sent). Here is an example of what report you can see with Monitoring feature:
2.1 Navigate to Stape Logs.
2.2 Filter Outgoing requests.
Select the date, specify Facebook as the platform, and select the required event from the list (usually Purchase).
2.3 Analyze the requests that were sent to Facebook.
If there are not a lot of requests, the analysis can be done manually. Click on More next to the record. Search for:
fbc - is a specific ad click ID. It links a specific action (like a purchase) to a specific ad click. This is a key for accurate attribution.fbp - unique identifier for a specific browser. It identifies a user across different sessions on the same browser, even if they didn't click on an ad to get there.In most cases, you will see that the fbc parameter is missing, which causes incorrect attribution. Review other logs to quantify the impact on your data.
If you have a lot of requests, opt for Download as CVS. Be sure that all the logs are loaded before downloading them - click Load more at the bottom of the page.
Then, select one of the options:
fbc and fbp parameters.Use the formulas to figure out:
=COUNTIF(H2:H, "*")fbp parameter:=COUNTIF(H:H, "*fbp*")fbc parameter:=COUNTIF(H:H, "*fbc*")In this way, you can quantify how many transactions aren't attributed correctly. Here is an example of what you can receive:
So, what you're doing next:
fbp and/or fbc parameters, you've most likely didn't configure them within your GTM tags. Check our guide on Meta server-side tracking with Facebook CAPI to configure them.Trigger the event, click on it in the debugger, and go to the Event Data tab.
If there is no fbc or fbp there, it means that the Client couldn't extract this data from the HTTP request.
Keep in mind that the _fbc parameter is only captured when a user clicks on an ad. For example, if you recorded 100 purchases but Ads Manager shows only 30 clicks in that same period, you shouldn't expect all 100 purchases to include the _fbc value. At most, it would appear on 30 purchases, assuming every click resulted in a conversion.
On the other hand, if you still see 100 purchases and 30 clicks, and GA4 indicates that some conversions came from Facebook, but your logs contain no purchase events with _fbc, that points to a problem. In that case, _fbc is either not being stored correctly or not being passed along with the event data.
Note: if your server container is on a different third-party domain (for example, google-analytics.com instead of your example.com), the browser will not send cookies due to security policies. Using a custom domain resolves this issue by making the cookies "first-party."
fbc parameter from the URL before the tag fires. To lower the impact of ad blockers on your data, be sure you’ve configured the Custom Loader.Also, ITPs (Intelligent Tracking Prevention) in Safari can shorten the lifespan of cookies. If you don't have the Cookie Keeper configured yet, try to activate it. It can help extend the lifespan of these identifiers.
| For more details on how to configure accurate Facebook attribution, refer to our guide on actionable tips to improve Facebook conversion attribution. |
If you have a lot of offline conversions, you should have already configured webhooks to send the conversion data to sGTM and forward it to Meta.
If you notice problems with attribution in Meta, it's worth checking whether webhooks cause them.
You can't use the Stape Logs, since it contains only the original request; when it comes to webhooks, this isn't enough for debugging. For efficient debugging, you also need to send a POST body request. It can be done with the Logger tag.
The POST body request can be stored in the Stape Store (also should be configured).
Note: Stape Store is included at no extra charge for Pro and higher plans.
3.2 Analyze the webhooks' payload via Stape Store.
After configuring, you will get the logger collection.
In the fields, look for the details on the webhook payload. You are looking for the key identifiers that can help Meta attribute the conversion:
fbc/fbp parameters (whether they're sent)All this data is stored in the Event data. Here is an example of how it looks in practice:
Sometimes, these parameters are missing (e.g., you get no value), which can lead to inaccurate conversion attribution on Meta's end and a lower Event Match Quality score. However, this is not always an issue. For example, if the user clicked on an ad but a purchase was made through a different traffic source (not from a Meta ad), the _fbc parameter wouldn't be added to the webhook payload.
How to fix it?
Offline conversion attribution can be more precise if you:
fbc/fbp parameters along with a unique user identifier (such as email) on the web.fbc/fbp parameters and attach to the webhooks payload.But first of all, you need to be sure that while collecting data on the web, your tracking scripts will be less prone to being blocked. So, you would need to start by adding the Custom Loader, Cookie Keeper, and a custom subdomain as we described in Step 2.
Then, you need to configure the whole flow to add the fbc/fbp parameters to the webhook. There are a few ways to do:
fbc/fbp values to a hidden form field - so this data goes into CRM and then will be available in the webhook.If you use the Stape Store, you would need to do the following:
1. Configure the Stape Store Writer tag.
We explain in detail how to do it in our guide on Stape Store.
2. Create an identifier variable.
The variable should extract the email (or other user identifier) from the incoming webhook.
3. Configure the Stape Store Lookup variable.
That's a variable that extracts the unique identifier (such as email) from the incoming CRM webhook.
user_data.fbp.
Create the same variable but with a path to read fbc.
4. Map variables to the Meta tag.
In your Facebook Conversions API tag, find the User data section and map the Click ID and Browser ID fields to these two Lookup variables.
Guides:
Setups in Meta:
Meta attribution is not inherently broken, but it is highly dependent on the quality and completeness of the data you send to a platform. The key takeaway is that accurate attribution isn't just about configuring Meta Pixel or Conversions API; it's about ensuring the entire data flow works reliably from the moment a user clicks an ad to the moment a conversion is recorded.
Comments