> For the complete documentation index, see [llms.txt](https://wishlistsuite-1.gitbook.io/wishlistsuite-help-doc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wishlistsuite-1.gitbook.io/wishlistsuite-help-doc/app-overview/integrations/meta-integration.md). # Meta Integration ### Overview Send wishlist activity straight to Meta for better ad targeting and reporting - no theme script, no code. ### How it works WishlistSuite connects to Meta entirely through the **Conversions API** - a direct, server-to-server connection. Every event is sent from our backend straight to Meta's Graph API. We never inject a pixel script into your theme, and nothing runs in your customers' browsers on our behalf. **The flow:** 1. A customer adds/removes a wishlist item, a reminder email goes out, or an order ships 2. Our server builds the event - identity signals plus product/price data 3. We POST it directly to Meta's Graph API 4. Meta matches the identity and feeds it into your Custom Audiences and ad reporting ### How to connect You'll need a Facebook Page and a Business account before Meta grants access to any of this (Meta's Business Suite requires at least one owned asset). Once you have those: 1. In **Meta Events Manager**: go to **Data Sources → Connect Data → Web → Meta Pixel**, and create a new pixel or reuse an existing one. 2. The **Pixel ID** shows right under the pixel's name on the Data Sources page. 3. Open the pixel → **Settings → Conversions API → Set up direct integration → Generate Access Token**. 4. Paste both the Pixel ID and Access Token into WishlistSuite's **Meta Pixel connect screen**. **What happens when you connect:** we validate the Pixel ID and token with a hidden test event (tagged so it never shows up in your real event stream). Once that succeeds, we fire one placeholder event for every event type in a single batch - so Meta's "new custom event" review queue sees all 9 at once, instead of them trickling in over days as real customers happen to trigger each one for the first time. *** ### The 12 events we send
EventFires whenProduct / value data
AddToWishlistProduct added to wishlistitem_id, item_name
RemoveFromWishlistItem removeditem_id, item_name
ViewWishlistWishlist page viewed-
ShareWishlistShare link usedcontent_type
WishlistItemPurchasedOrder contains a wishlisted productcurrency, value, item_id, quantity, price
PriceDropAlertPrice-drop reminder sentcurrency, value (new price), item_id, item_name, price
BackInStockAlertBack-in-stock reminder sentsame shape as above
LowStockAlertLow-inventory reminder sentsame shape as above
WishlistReminder"Kept too long" reminder sentcurrency, value, item_id, item_name, price (if cached)
SaveForLaterItem moved to "saved for later" from cartProduct ID, name
FrequentlyBrowsedAlertFrequently-browsed digest sentProduct, price, currency
SavedForLaterAlertSaved-for-later reminderProduct, price, currency
Every event also carries whatever identity signals are available for that customer (see below). **Guests never get `external_id` or hashed email** - there's no customer record to pull those from, so guest events rely purely on `fbp`/`fbc`/IP. *** ### The identity signals, ranked by strength Meta matches events to real accounts using whichever of these signals we have - not every event has all five. | Signal | Strength | What it is | | ---------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **fbc** | Strongest | Facebook Click ID - only exists if the visitor clicked directly on a Meta ad. Near-certain proof of which ad drove the visit. | | **em** | Strong | SHA-256 hashed email. Meta compares hash-to-hash against its own records - neither side sees the other's plaintext. Only available for logged-in customers with an email on file. | | **fbp** | Moderate | Facebook Browser ID - a cookie set on every page load by Meta's pixel script (or Shopify's Facebook & Instagram channel), regardless of traffic source. | | **external\_id** | Moderate | Our own internal customer ID, hashed before sending. Helps Meta stitch together repeat events from the same person over time. | | **ip** | Weakest | The visitor's IP address, used with User-Agent only as a last-resort fallback. Always sent as a baseline. | *** ### How Meta uses this data Identity resolution happens entirely on Meta's side - **we never get the result back.** 1. We send whichever signals we have for that event. 2. Meta matches the strongest one available: `fbc` first → `em` → `fbp` → IP + User-Agent as a last resort. 3. On a match, Meta privately resolves the event to a specific Facebook/Instagram account. That mapping is never sent back to us - not in any API response, dashboard, or export. We only ever see aggregate counts. 4. The matched account gets added to any Custom Audience built from this pixel (e.g. "people who added to wishlist in the last 30 days"). 5. Ads then get shown to those accounts on Facebook/Instagram - entirely inside Meta's platform. 6. Reporting rolls up in aggregate - "this campaign drove $X in wishlist-attributed purchases," never a named list of people. **Common misconception:** Events Manager's Overview tab only shows totals ("AddToWishlist fired 340 times") - never who. The only place raw event payloads are visible at all is the **Test Events** tab, and only for events tagged with a `test_event_code` during active testing. To look up which actual customer did something, that lives in WishlistSuite's own database - not Meta. *** ### Real limitations to know about **`fbp`/`fbc` depend on a separate integration.** WishlistSuite only *reads* these cookies - it never creates them. They only exist if the merchant has also turned on Shopify's native "Facebook & Instagram" sales channel (or manually installed Meta's pixel script). Without that second, separate thing active, `fbp`/`fbc` are null for every visitor, and match quality relies entirely on IP + `em` + `external_id`. **Guests are always weaker-matched.** No `external_id`, no `em` - ever. Guest events rely purely on whatever `fbp`/`fbc`/IP happens to be available. *** ### Testing it You don't need to wait for real customer traffic. On the configure page (**Integrations → Meta Pixel**), hit **Send Test Event**. It fires a real `AddToWishlist` event tagged with a merchant-entered `test_event_code`, and shows up instantly - with the full raw JSON payload - in Meta Events Manager's **Test Events** tab. This is the fastest way to confirm the whole pipeline end-to-end. *** ### FAQ **Do I need to add any code to my theme?** No. This is a server-to-server integration - nothing is injected into your theme by WishlistSuite. **Will this work if I haven't installed Shopify's Facebook & Instagram channel?** Yes, but match quality will be lower. Without it, the `fbp`/`fbc` cookies are never present, so Meta falls back to IP address, hashed email, and your internal customer ID. **Can I see which specific customer triggered an event in Meta?** No - Meta never sends back which account an event matched to, even to us. That level of detail (which customer did what) lives in WishlistSuite's own data, not Meta's. **Do guests get tracked the same way as logged-in customers?** Guests are tracked, but with weaker matching - they never have `external_id` or hashed email attached, since there's no customer record to pull those from. **How do I know the integration is actually working?** Use the **Send Test Event** button and check Meta Events Manager's Test Events tab - you'll see the full payload appear within seconds.