> For the complete documentation index, see [llms.txt](https://help.littledata.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.littledata.io/integrations/facebook-capi/meta-ads-tracking-guide.md).

# Meta Ads tracking for Shopify: the complete guide

How Meta Ads tracking works on Shopify: the Meta Pixel, the Conversions API, CAPI Gateway, the fbclid click ID and \_fbc cookie, Event Match Quality, deduplication, Pixel Helper checks and health and w

Meta Ads tracking is the set of tools that tell Meta which shoppers saw or clicked a Facebook or Instagram ad and what they did next on your store. Meta uses that data to attribute sales, optimize delivery and build audiences. The better the data, the cheaper your acquisition.

This guide explains each part of the stack and how they fit together on Shopify: the **Meta Pixel** in the browser, the **Conversions API (CAPI)** from the server, the identifiers Meta matches on (**fbclid**, `_fbc`, `_fbp`, hashed email and phone), **Event Match Quality (EMQ)**, deduplication, how to test your setup with **Meta Pixel Helper** and Events Manager, and what changes if Meta puts your store in its **health and wellness** category.

{% hint style="info" %}
Littledata's [Shopify to Meta Conversions API connection](https://www.littledata.io/shopify/meta-conversions-api) sends browser and server events with a shared event ID, captures the click ID and passes it to every server event, and tracks every Shopify order including express checkout and subscription renewals. See the [installation guide](/integrations/facebook-capi/how-to-install-shopify-to-conversions-api.md) to get started.
{% endhint %}

## How does Meta Ads tracking work?

Meta needs two things to credit a sale to an ad: an **event** (a purchase, an add to cart) and enough **identifiers** on that event to match it to a Facebook or Instagram account that saw or clicked the ad.

| Layer                  | What it does                                                                       | Where it runs                       |
| ---------------------- | ---------------------------------------------------------------------------------- | ----------------------------------- |
| Meta Pixel             | Sends browser events (PageView, ViewContent, AddToCart, Purchase) and sets cookies | Shopper's browser                   |
| Conversions API (CAPI) | Sends the same events, plus data the browser never sees, server to server          | Your server, Shopify, or a vendor   |
| Identifiers            | `fbc` (click ID), `fbp` (browser ID), hashed email, phone, name, IP, user agent    | Carried on every event              |
| Deduplication          | Matches the browser copy and the server copy of one event by `event_id`            | Meta, within 48 hours of first copy |
| Event Match Quality    | Scores how well your identifiers match events to people, 0 to 10                   | Meta Events Manager                 |

Browser tracking alone misses conversions. Ad blockers block the pixel, Safari caps script-set cookies, shoppers move from the Instagram in-app browser to Safari or a laptop, and express checkouts such as Shop Pay don't always fire the pixel. Meta's own answer is a **redundant setup**: send every event from both the browser and the server, and let Meta deduplicate. That's the setup Littledata builds for you, and it's why Meta CAPI is not a replacement for the Pixel but an enhancement of it. See [Meta Pixel vs Conversions API](#meta-pixel-vs-conversions-api) below.

## Meta Pixel vs Conversions API

The **Meta Pixel** is a JavaScript snippet on your store. It tracks views, clicks and conversions in the browser, stores a browser identifier in the `_fbp` cookie, and saves the click ID from an ad in the `_fbc` cookie. It's easy to install, reports in real time and powers retargeting audiences.

Its weaknesses are the browser itself. Cookies get blocked or deleted, ad blockers stop the script loading, Safari limits cookie lifetimes, and the Pixel doesn't always fire on Shopify's thank-you page or in express checkouts. Every one of those is a purchase Meta never sees.

The **Conversions API** sends the same events from a server straight to Meta, bypassing the browser. It survives ad blockers and privacy limits such as iOS 14, carries first-party data the browser never had (hashed email and phone, new vs returning customer, lifetime value, subscription status), and records 100% of Shopify orders. The costs are a slight delay compared with the Pixel and, if you build it yourself, the data engineering and server infrastructure to run it.

| Factor      | Meta Pixel                                         | Conversions API                                            |
| ----------- | -------------------------------------------------- | ---------------------------------------------------------- |
| Data source | Browser                                            | Server (Shopify orders, customer records)                  |
| Blocked by  | Ad blockers, ITP, consent, in-app browsers         | Nothing in the browser                                     |
| Identifiers | `fbp`, `fbc`, advanced matching if set up          | Everything the Pixel has plus hashed email, phone, address |
| Latency     | Real time                                          | Near real time                                             |
| Privacy     | Exposed to cookie and browser restrictions         | More control over what is shared, helps with GDPR and CCPA |
| Setup       | Paste code or install an app                       | Build it, run server-side GTM, or use a managed vendor     |
| Best for    | Browsing behaviour, retargeting, real-time signals | Reliable checkout and purchase events                      |

### Why you need both

Neither replaces the other. The Pixel sets the `_fbp` and `_fbc` cookies and gives Meta a browser-side signal for audiences; the Conversions API fills the gaps and adds the identifiers that lift match quality. Meta's own recommendation is a redundant setup, with each event sent from both and deduplicated on a shared event ID.

If you're happy with a free setup that goes blind from add-to-cart onwards, the Pixel alone may do. For anything where accurate purchase data matters, the Conversions API is the investment that pays back.

{% hint style="success" %}
See how [Jaxxon saw a 75% uplift in revenue](https://www.littledata.io/case-studies/jaxxon) after switching to Littledata's Meta connection.
{% endhint %}

Littledata's [Shopify to Meta Conversions API connection](https://www.littledata.io/shopify/meta-conversions-api) sends both sides for you: the browser copy from the Littledata Pixel and the server copy from Shopify's order data, with one event ID so Meta counts each purchase once. Benefits include higher Event Match Quality scores, dynamic product ads built on accurate product data, and revenue in Meta that matches revenue in Shopify. For the wider story on cookies and attribution, read [the truth about cookies and attribution](https://blog.littledata.io/2023/06/28/the-truth-about-cookies-and-attribution).

## Four ways to send Conversions API events from Shopify

Every CAPI setup posts to the same Meta endpoint. They differ in where the data comes from and who maintains the pipeline.

### 1. Shopify's Facebook & Instagram sales channel

Shopify's own app has three data-sharing levels. **Standard** is pixel only. **Enhanced** and **Maximum** add the Conversions API for the Purchase event. It's free and fine for very small stores, but only Purchase is sent server-side, subscription renewals are missed, customer identifiers are incomplete and there's no lifetime value or new-customer signal. See [how Littledata's connection compares](/integrations/facebook-capi/meta-capi-faq.md#how-is-littledata-better-than-shopifys-facebook-instagram-channel).

### 2. Meta Conversions API Gateway (CAPIG)

The **Conversions API Gateway** is Meta's no-code server application. You deploy it into your own AWS or Google Cloud account (or a partner hosts it), point a subdomain such as `gateway.yourstore.com` at it, and the Pixel sends each browser event to the Gateway as well as to Meta. The Gateway converts those browser events to CAPI events and forwards them server to server. It generates its own `event_id`, so deduplication works within that Pixel-and-Gateway pair.

Meta charges no fee of its own. You pay the cloud bill (or the partner) and you own the cloud maintenance.

The limitation is in the name: it's a *gateway*, not a new data source. The Gateway can only relay what the Pixel already captured.

* If an ad blocker stops the Pixel, there is nothing to forward.
* It can't add identifiers the browser never saw, or backend data such as new-customer status, margin or subscription state.
* It can't recover purchases the Pixel missed on express checkout.
* It is Meta-only, and Shopify runs checkout pixels in a sandbox, so test Purchase events carefully.

A forgotten Gateway is also a common cause of duplicate events. It keeps relaying until someone disconnects the Pixel in Events Manager and deletes the cloud stack. Run **one server-side sender per pixel**.

### 3. Server-side Google Tag Manager (sGTM)

sGTM gives you a server container on Google Cloud that can forward events to many platforms. You pay hosting (Google estimates roughly $45 a month per server, with at least two recommended), build and maintain the tags, and align event IDs across web and server yourself. It needs GTM and cloud skills.

{% hint style="warning" %}
Littledata's Meta connection is not compatible with server-side GTM sending to the same pixel. Both would send server events with different event IDs. Disable the sGTM Meta tag when you connect Littledata.
{% endhint %}

### 4. Managed server-side tracking (Littledata)

Littledata hosts the pipeline for you. Orders come from Shopify webhooks rather than the browser, so purchases are recorded whether or not the Pixel fired, including Shop Pay, Apple Pay, POS and subscription renewals. The [Littledata Pixel](/sources/shopify/littledata-pixel.md) (a Shopify custom web pixel) sends the browser copy of each event with the same event ID as the server copy, so Meta deduplicates cleanly. Events carry every customer identifier Meta accepts except external ID, gender, date of birth and Meta's own login and lead IDs. On top of the standard events you get `predicted_ltv`, new vs returning customer purchases, Subscribe and Recurring Purchase events, Shopify Markets parameters and optional profit per order.

| Approach             | Data it can send                       | Purchases the Pixel missed | Who maintains it | Deduplication                             |
| -------------------- | -------------------------------------- | -------------------------- | ---------------- | ----------------------------------------- |
| Shopify F\&I channel | Purchase only, limited identifiers     | Partly                     | Shopify          | Own `sh-` event IDs                       |
| CAPI Gateway         | Whatever the Pixel captured            | No                         | You (cloud)      | Own event IDs, within the Gateway pair    |
| Server-side GTM      | Whatever reaches the container         | Only if fed another way    | You (GTM, cloud) | You align IDs                             |
| Littledata           | Shopify orders, customers, LTV, profit | Yes                        | Littledata       | Shared event ID across browser and server |

Whichever you choose, pick one. See [turning off Shopify's CAPI integration](/integrations/facebook-capi/disable-capi-shopify.md) and the [installation guide](/integrations/facebook-capi/how-to-install-shopify-to-conversions-api.md) for how Littledata asks you to disable duplicate senders.

## What are fbclid, \_fbc and \_fbp?

### fbclid: the Facebook click ID

When someone clicks a Facebook or Instagram ad, Meta appends `fbclid` to the landing URL:

```
https://yourstore.com/products/linen-shirt?utm_source=facebook&fbclid=IwAR2F4-dbP0l7Mn1IawQQGCINEz7PYXQvwjNwB_qa2ofrHyiLjcbCRxTDMgk
```

It identifies the **click**, not the campaign, and it's case sensitive, so never modify it. UTMs and `fbclid` arrive together: UTMs tell your analytics which campaign a session came from, while `fbclid` lets Meta tie a later conversion to that exact click. You want both.

### \_fbc: the click ID stored as a cookie

The Pixel saves the click ID in a first-party cookie called `_fbc`, and CAPI sends the same value back to Meta as the `fbc` parameter. The format is:

```
fb.subdomainIndex.creationTime.fbclid
fb.1.1554763741205.IwAR2F4-dbP0l7Mn1IawQQGCINEz7PYXQvwjNwB_qa2ofrHyiLjcbCRxTDMgk
```

| Part           | Meaning                                                                                  |
| -------------- | ---------------------------------------------------------------------------------------- |
| `fb`           | Version prefix, always `fb`                                                              |
| subdomainIndex | Domain level the cookie was set on. `1` for `yourstore.com`, `2` for `www.yourstore.com` |
| creationTime   | Unix time in milliseconds when the cookie was stored                                     |
| fbclid         | The click ID from the landing URL, unchanged                                             |

Send `fbc` **unhashed**, and only for shoppers who actually arrived with an `fbclid`. Never generate a placeholder or copy one shopper's click ID onto another.

### \_fbp: the browser ID

`_fbp` is Meta's browser identifier, set by the Pixel on any visit whether or not an ad was clicked. The format is `fb.subdomainIndex.creationTime.randomNumber`, for example `fb.1.1596403881668.1116446470`. `_fbp` says *which browser*; `_fbc` says *which ad click*. Both are sent unhashed as `fbp` and `fbc`.

### Why the click ID is the most valuable identifier

An email tells Meta *who* bought. The click ID tells Meta who bought, **which ad they clicked and when**. Meta weights `fbc` and email as its highest-priority identifiers for match quality, and events Meta can't match to a person can't be used for attribution or delivery optimization. See the [EMQ guide](/integrations/facebook-capi/meta-event-match-quality.md#what-drives-emq-scores) for the full priority table.

### What breaks the click ID before the purchase

The click ID is created on the landing page and needed on the purchase event, sometimes days later. Anything that separates the two loses it.

* **In-app browsers.** Tapping an Instagram ad opens your store inside Instagram's browser, which has its own cookie store. When the shopper comes back later in Safari or on a laptop, `_fbc` isn't there.
* **Safari's cookie caps.** Since ITP 2.1, Safari expires script-set cookies after 7 days, and after 1 day on the landing page when the referrer is classified as a tracker and the URL has a query string. The Pixel sets `_fbc` with JavaScript, so a Safari shopper returning after a week arrives without it.
* **Redirects and link shorteners.** Every hop between the ad and the final page has to preserve the query string. Shorteners, geo redirects and old 301s often don't. Test by adding a harmless `?qs_test=1` to an ad URL and checking it survives.
* **Apple's Link Tracking Protection.** From iOS 17, Safari strips some tracking parameters from links in Messages, Mail and Private Browsing. Apple doesn't publish the list, so plan for `fbclid` to be stripped there.
* **Stripping fbclid too early.** Caching, analytics and canonical-URL hygiene are all fair reasons to clean the URL, but only after the Pixel and your own capture have read it.

### How to keep the click ID

Meta's own recommendations are to capture `fbclid` server-side as early as possible, build `fb.1.<first seen in ms>.<fbclid>` once, set `_fbc` from your server as an HTTP cookie with a 90-day expiry, store it against the session and the customer record, and send `fbc` with **every** Conversions API event.

Littledata captures both identifiers in the browser and attaches them to its server-side events, including the Purchase that Shopify's webhooks report, so an order placed through Shop Pay or with the Pixel blocked still carries the click. The `fbp` browser ID is stored against the customer for up to a year, so it can be sent even if the cookie is lost. The `fbc` click ID is kept for the session in which the click happened, so later orders such as subscription renewals don't include it. See [fbp and fbc parameters in how it works](/integrations/facebook-capi/how-it-works-shopify-to-meta-conversions-api.md#fbp-and-fbc-parameters) and [how Littledata improves EMQ](/integrations/facebook-capi/meta-event-match-quality.md#how-littledata-improves-emq). Meta treats click IDs older than 90 days as expired, which is why you sometimes see an [expired fbclid warning](/integrations/facebook-capi/common-meta-errors.md#expired-fbclid-warning-in-the-meta-dashboard) in Events Manager. It's harmless.

### Check your click ID coverage

Click ID coverage is the share of your events that carry `fbc`. As a rule of thumb it should roughly match Meta's share of your traffic. In Events Manager, click into the Purchase event's match quality score to see the share of events with each parameter.

| What you see                                        | What it usually means                                                 |
| --------------------------------------------------- | --------------------------------------------------------------------- |
| Purchase coverage close to Meta's share of traffic  | Click IDs are surviving the journey                                   |
| Meta drives most traffic, few purchases carry `fbc` | Clicks are lost between the ad and the order                          |
| Landing events carry `fbc`, purchases mostly don't  | The ID is captured but not carried into later sessions or devices     |
| Coverage well above Meta's share of traffic         | Check `fbc` isn't attached to visitors who never arrived with a click |
| Low coverage, mostly organic or affiliate traffic   | Expected                                                              |

Missing `fbc` on events from non-ad traffic is normal. See [FBC parameter missing for some events](/integrations/facebook-capi/common-meta-errors.md#fbc-parameter-missing-for-some-events).

## Event Match Quality (EMQ)

Event Match Quality scores, from 0 to 10, how well the identifiers on your server events let Meta match them to real people. Purchase matters most because it's the optimization signal.

| Event                            | Target score |
| -------------------------------- | ------------ |
| Purchase                         | 8.5+         |
| Add to Cart / Checkout Initiated | 6.5+         |
| Page View                        | 5.5+         |

Three things drive the score: **data completeness** (email and `fbc` weigh most, then phone, external ID, `fbp` and country), **processing speed** (real-time beats batched) and **event accuracy** (duplicates and gaps are penalized). Lower scores on top-of-funnel events are normal because email and address aren't known yet.

Littledata sends hashed email, phone, name, city, state, zip and country, plus `fbp`, `fbc`, IP address and user agent on every server event. Read the full [EMQ guide](/integrations/facebook-capi/meta-event-match-quality.md) and [low EMQ score troubleshooting](/integrations/facebook-capi/common-meta-errors.md#low-emq-score).

## Deduplication: why one purchase can count twice

When Meta receives a browser event and a server event with the same `event_name` and the same `event_id` for the same pixel, within 48 hours, it keeps one. That's how a redundant setup avoids double counting.

Deduplication only works when both copies share an ID. **Meta cannot deduplicate across tools.** Shopify's sales channel uses its own IDs (they start with `sh-`), a CAPI Gateway generates its own, sGTM uses whatever you configured, and Littledata uses its own shared ID across the Littledata Pixel and its server events. Two senders on one pixel means inflated purchase counts and a lower EMQ.

Symptoms of a duplicate sender:

* Meta reports **more** purchases than Shopify for the same day. That should never happen.
* In Events Manager Overview, the server line for Purchase is double (or half) the browser line.
* Pixel Helper shows the same event twice for one action with different event IDs.

Fix: inventory everything that can send Meta events (the Facebook & Instagram app's data sharing, Shopify Campaign Autopilot in **Growth → Autopilot** if it's connected to the same Meta dataset, app and custom pixels in **Settings → Customer events**, pixel code in the theme, old GTM containers, a forgotten Gateway) and leave one. See [does Meta deduplicate Littledata's events against other apps?](/integrations/facebook-capi/meta-capi-faq.md#does-meta-deduplicate-littledatas-events-against-other-apps)

## How to check your Meta tracking with Pixel Helper and Events Manager

### Meta Pixel Helper (now Meta Ads Data Advisor)

Meta Pixel Helper is Meta's free Chrome extension. Meta has renamed it **Meta Ads Data Advisor**; existing installs update automatically and the diagnostics still work.

1. Install it from the Chrome Web Store (search for Meta Ads Data Advisor), pin it, and turn off ad blockers on your own store. A separate Chrome profile for testing is a good idea since the new version asks to read data on all sites.
2. Open your store and click the icon. The panel lists every pixel on the page. Check the ID matches your dataset in Events Manager. **Two of your own pixel IDs on one page means a duplicate install.**
3. Walk the funnel: product page, add to cart, checkout, then a test order. Click each event to see its parameters. Purchase must carry `value` and `currency`; catalog ads need `content_ids` or `contents`.
4. Read the status. A pixel can show **Active** while its events carry warnings, so click into each event. Common culprits are duplicate pixel code, base code outside `<head>`, missing parameters and blocked requests.

On a Littledata store the browser copy of checkout and purchase events comes from the [Littledata Pixel](/sources/shopify/littledata-pixel.md), which runs inside Shopify's web pixel sandbox. Meta doesn't document how the extension handles sandboxed pixels, so treat its results as possibly incomplete and confirm in Events Manager. Shopify's warning that the [Littledata Pixel is not subscribed to any events](/integrations/facebook-capi/common-meta-errors.md#littledata-pixel-not-subscribed-to-any-events) is expected.

### What Pixel Helper can't show

The extension only sees what your browser sends. Conversions API events go from a server straight to Meta, so it can't show them individually, nor deduplication, match quality or how your counts compare with Shopify. For those, use Events Manager:

* **Test events.** Events Manager → Data sources → your pixel → **Test events**. Browser events appear as you browse; server events appear when they're sent with the test code. Events usually show within 20 minutes.
* **Overview → Connection method.** Shows each event's volume from browser and from server, before deduplication. For AddToCart and Purchase the two lines should move together. The server line is often a little higher because it catches what the browser misses.
* **Event deduplication tab.** Inside an event's details, shows the share of events deduplicated and how often each key arrived from each source.
* **Event Match Quality.** Overview → click the score for any event to see which parameters it carries.

### Shopify Pixel Helper

Shopify has its own tester. In **Settings → Customer events**, open a pixel's menu and click **Test**. Green means Shopify received the event and the pixel's callback ran; red is an error. Shopify's event names differ from Meta's (`checkout_completed` maps to Purchase). Run it alongside Meta's extension.

### A launch checklist

1. Inventory every possible Meta sender and disable all but one. That includes Shopify Campaign Autopilot (**Growth → Autopilot**) if it's connected to the same Meta dataset.
2. In a clean browser profile, walk the funnel with Pixel Helper and note pixel IDs and event IDs.
3. Place a test order and watch it arrive in Test events.
4. The next day, compare yesterday's Purchase count with Shopify, matching time zone. Meta should never be higher.
5. Check EMQ for Purchase and click ID coverage.
6. After any theme change, check **Online Store → Themes → Customize → App embeds**. A new theme can silently switch tracking off.

### Why is my pixel not tracking purchases?

* No completed checkout yet. Purchase fires on the thank-you page, so place a test order.
* Consent. A third-party cookie banner that doesn't sync with Shopify's Customer Privacy API can stop pixels firing even after acceptance.
* Data sharing or an app embed switched off after an app update or theme change.
* Ad blockers block web pixels. Server events aren't affected, which is the whole point of CAPI.
* Shopify can pause a marketing pixel it judges to be oversharing under its default Optimized setting. Check the pixel's activity log in Customer events.

## Meta's health and wellness restrictions

Meta assigns a category to any website or dataset that sends data through its Business Tools (Pixel, CAPI, SDKs). **Health and wellness** is a category with extra data-sharing restrictions, and Meta's definition reaches further than most brands expect: supplements, skincare with active claims, fitness, sexual wellness and anything implying a condition or an outcome.

### The three tiers

| Restriction                            | What Meta restricts                                        | Effect on a store                                                                               |
| -------------------------------------- | ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Core Setup                             | Custom parameters and everything in a URL after the domain | URL-based audiences stop updating, auto advanced matching may be off, custom events need review |
| Restriction on certain standard events | "Specific mid and lower funnel events"                     | AddToCart, InitiateCheckout, Purchase may be unavailable for optimization                       |
| Full restrictions                      | All events, in some or all regions                         | Only Awareness, Engagement or Traffic objectives                                                |

Standard parameters such as `value`, `currency` and `content_ids` are not custom parameters, so Core Setup on its own does not block Purchase.

### How to check if your dataset is restricted

1. Check email and Events Manager notifications.
2. Events Manager → **Datasets** → your dataset → **Settings** → **Dataset categories** / **Manage data source categories**.
3. In the same tab, look for **Core setup** under Data restrictions. If Meta turned it on, you can't turn it off.
4. **Diagnostics** shows an "Event parameters blocked" message with the parameters Meta dropped.
5. If the category is wrong, **View details → Request review**. Appeals rarely succeed, so plan as if the restriction stays.

Ad policies (what your creative can claim, age targeting for weight loss products) are a separate system from data restrictions. An ad can pass review while the dataset sits in Core Setup. Review both.

### Does server-side tracking fix it?

Not by itself. The Conversions API is one of the Business Tools, and the category sits on your dataset and domain, not on the Pixel. Moving an event server-side changes the transport, not the content: a product title with a health keyword is still in the payload. A new pixel on the same domain receiving the same events is usually flagged again within days, and renaming Purchase to a custom event doesn't help because Meta categorizes the data, not the event name.

What server-side tracking through Littledata does do is keep purchases flowing when Meta throttles or blocks browser Pixel events, so your reporting and optimization signal degrade less. See [what the Meta ad policy means for health and wellness stores](/integrations/facebook-capi/common-meta-errors.md#what-does-the-new-meta-ad-policy-mean-for-health-wellness-stores).

### What a compliant payload looks like

**Stop sending** fields that describe the product or a condition: `content_name` with health keywords or ingredients, `content_category` values such as "Supplements", `content_type` values other than `product` or `product_group`, custom properties naming an outcome, URL paths and UTM campaign names that name a condition, and custom event names referencing a condition. If you send `content_ids`, use opaque IDs rather than SKUs that spell out an ingredient.

**Keep sending** the identifiers Meta matches on and the value: hashed `em` and `ph`, unhashed `fbc`, `fbp`, IP address and user agent, `external_id`, `value` and `currency`. These describe who converted and for how much, not what they bought. Because automatic advanced matching may be unavailable under Core Setup, sending them from the server matters more.

Filter **per destination**, not at the source. Your analytics and warehouse still need product names. With Littledata, the [Event Editor](/event-editor/overview.md) controls what each destination receives, so you can strip product names from Meta events while GA4 and Klaviyo keep them. The step-by-step setup is in [Redact product details from Meta events](/event-editor/common-setups/redact-product-details-from-meta-events.md).

This is data minimization, not evasion. It doesn't lift a category Meta has assigned, and it isn't legal advice. Meta tells advertisers to agree a data-sharing compliance plan with their own counsel.

If Meta's dashboard becomes unreliable for your category, [GA4 through Littledata](/integrations/shopify-to-google-analytics.md) isn't subject to these restrictions and gives you a cross-channel view of the same orders.

## Why Meta's numbers don't match GA4 or Shopify

Even with perfect tracking, Meta's purchase and revenue figures differ from GA4 and Shopify. Meta's attribution is user-based rather than session-based, counts any ad interaction as a click, credits view-through conversions by default, and its attribution setting changes delivery, not just reporting. GA4 is multi-channel and session-based; Shopify records every order with no attribution model at all.

Purchase **event counts** should be close across all three once deduplication is right. **Attributed conversions and revenue** will not match, by design. Read [why Meta attribution differs from GA4](/integrations/facebook-capi/why-is-meta-attribution-different-from-ga4.md) and the [FAQ on Meta vs Shopify numbers](/integrations/facebook-capi/meta-capi-faq.md#why-dont-the-numbers-in-shopify-match-meta).

## Going further with Littledata's Meta connection

Once the basics are right, the extra signals Littledata sends let you optimize for customers rather than orders:

* [New and returning customer purchase events](/integrations/facebook-capi/meta-ads-custom-events-verifying-new-and-returning-customer-purchase.md) to bid separately for acquisition and retention
* [Maximize conversion value based on customer LTV](/integrations/facebook-capi/maximize-conversion-value-based-on-ltv.md) using the `predicted_ltv` parameter
* [Track subscription purchases in Meta Ads](/integrations/facebook-capi/how-to-track-subscription-purchases-in-meta-ads.md) with the standard Subscribe and Recurring Purchase events
* [Profit Signal](/sources/profit-signal/how-to-check-profit-signal-in-meta.md) to send `net_revenue` alongside order value
* [Redact product details from Meta events](/event-editor/common-setups/redact-product-details-from-meta-events.md) for health and wellness stores
* [Event Editor recipes](/event-editor/recipes.md) such as [VIP purchases](/event-editor/common-setups/vip-loyalty-purchases-meta-ads.md), [excluding B2B orders](/event-editor/common-setups/keep-b2b-orders-out-of-ad-conversions.md) and [quiz-answer lookalikes](/event-editor/common-setups/quiz-answer-lookalikes-meta-ads.md)
* [Import Meta Ads cost into GA4](/google-analytics/setup/import-meta-ads-cost-ga4.md) for cross-channel ROAS

## Frequently asked questions

#### Do I still need the Meta Pixel if I have the Conversions API?

Yes. Meta recommends a redundant setup with both, deduplicated on a shared event ID. The Pixel also sets the `_fbp` and `_fbc` cookies that server events rely on. Littledata sends both sides for you.

#### Is the Conversions API Gateway free?

Meta charges no fee for the Gateway. You pay AWS or Google Cloud to run it in your account, or a partner that hosts it, and you own the maintenance. It only relays what the Pixel captured.

#### Should I hash fbc and fbp?

No. Meta marks both as "do not hash". Email, phone, name and address are hashed with SHA-256. Littledata handles the hashing rules for every parameter.

#### How long does the \_fbc cookie last?

Set by the Pixel with JavaScript, Safari caps it at 7 days (1 day in some landing cases). Meta recommends setting it from your server as an HTTP cookie with a 90-day expiry. Click IDs older than 90 days are treated as expired.

#### Why does Pixel Helper show an event twice?

Compare the event IDs. If they differ, two sources are sending the event, often Shopify's Facebook & Instagram app (IDs start with `sh-`) plus another tool. Remove one.

#### Can I use Littledata's Meta connection alongside Shopify's Facebook & Instagram channel?

Keep the app installed for your catalog and Shops, but turn its data sharing off. Meta can't deduplicate its events against Littledata's, so running both double counts purchases. See [turning off Shopify's CAPI integration](/integrations/facebook-capi/disable-capi-shopify.md).

#### Will a new pixel fix a health and wellness restriction?

Not on its own. Meta categorizes the domain and the data, so a new pixel receiving the same events from the same domain is usually flagged again. What changes the outcome is what the events contain.

## Related articles

* [Shopify to Meta Conversions API installation guide](/integrations/facebook-capi/how-to-install-shopify-to-conversions-api.md)
* [How it works: Shopify to Meta Conversions API](/integrations/facebook-capi/how-it-works-shopify-to-meta-conversions-api.md)
* [Meta Event Match Quality (EMQ) scores explained](/integrations/facebook-capi/meta-event-match-quality.md)
* [Troubleshooting common Meta errors](/integrations/facebook-capi/common-meta-errors.md)
* [FAQ: Meta Conversions API](/integrations/facebook-capi/meta-capi-faq.md)