CJM
Signals

Verify Meta CAPI signals

Understand Meta events, matching enrichment, destination Pixels, consent, and dataset quality.

Use Signals → Meta CAPI to verify the server-side events CJM actually sent to Meta. This page is a delivery log, not the place where you connect Meta or choose the destination Pixel.

Before expecting events here:

  1. connect Meta under Setup → Channels;
  2. add the required Meta Pixel and enable Offline Conversion under Setup → Offline Conversion for automatic CJM signals;
  3. for a custom Pixel-event mapping, create an active Server Tracking rule;
  4. implement consent so adUserData and adPersonalization can be granted.

Events sent automatically

CJM conditionCustom CJM eventMeta standard event
At the first MQL qualification, Fit is at least 60CjmMqlHighFitSubmitApplication
At the first MQL qualification, Intent is at least 60CjmMqlHighIntentSubmitApplication
First entry into SQLCjmSqlContact
Opportunity with positive valueCjmOpportunityContact
Won with positive valueCjmWonPurchase
Lead capturedLead
Pixel page loadPageView
Other supported Pixel interactionViewContent

The custom names shown are the current defaults. The event list presents them with friendly CJM labels. If both Fit and Intent become high in the first MQL qualification, both custom events can be sent, while the standard SubmitApplication is sent once.

In the current processor, every automatic Meta path uses the Pixels that are active or in test mode and have Offline Conversion enabled. This includes web engagement and Lead events, not only CRM stage changes. A Server Tracking rule is different: it sends to the single Meta Pixel selected in that rule.

Data included when available

For Lead, MQL, and pipeline milestones, CJM can add:

  • email, phone, first name, last name, and CJM Profile ID;
  • _fbp, _fbc, client IP, and browser user agent;
  • Meta Lead ID for deterministic Lead Ads matching;
  • campaign and ad identifiers resolved from the relevant session or stored attribution;
  • city, region, postal code, and country;
  • CJM score and qualification; value for the relevant commercial milestone.

Meta's SDK normalizes and hashes contact and location fields before delivery. Browser identifiers, IP, user agent, and Meta Lead ID follow the format required for matching and are not treated as contact fields.

Automatic web engagement is intentionally lighter: it sends the event name, event ID, source URL, available _fbp/_fbc, IP, user agent, and Profile ID when one exists. A Server Tracking rule can additionally send Profile contact data, a fixed or Profile-derived value, and ecommerce transaction/product data when supplied by the source event.

These fields improve the chance that Meta matches a server event to the right person and campaign. They are not guaranteed to exist, and their presence does not guarantee attribution.

CJM sends nothing to Meta unless both adUserData and adPersonalization are granted. This applies to web activity, Lead events, automatic milestones, and Server Tracking rules. An absent or unspecified value also blocks delivery.

CJM deduplicates retries using the event ID, Meta event name, and delivery mode. For ecommerce data, a transaction ID becomes the order ID when present; otherwise CJM can use the Profile ID. When the browser Pixel and CAPI both send the same action, consistent event IDs are still necessary for Meta's own browser/server deduplication.

Read the Meta CAPI page

  1. Open Signals and select Meta CAPI.
  2. Choose the date range.
  3. Add filters for Status, originating CJM Event, or Pixel.
  4. Select a row to see the event name, origin, destination Pixel, linked Lead, value, payload, response, and error.

Triggered by indicates a configured MQL/SQL/Opportunity/Won origin when the event name matches that configuration. Unmapped means the stored Meta event name does not match one of those automatic names; it commonly represents a standard Meta event, web engagement, Lead, or a custom Server Tracking event.

Review dataset quality

Select View quality runs to inspect the quality snapshots available for the chosen period. Choose a run, then compare each event's Match %, Coverage %, Dedupe %, Freshness (h), Sent, Success, and Failed.

Use these values together:

  • low match or coverage suggests that useful identifiers are often missing;
  • a weak dedupe result suggests checking browser/server event-ID consistency;
  • high freshness means Meta is receiving the data later;
  • failed counts require inspecting the corresponding Signal rows and Meta configuration.

A quality run is a saved snapshot retrieved for that date. It is separate from the live event list and may not be available for every selected range.

If a Meta signal is missing

Check, in order:

  1. the source event reached CJM;
  2. both advertising consent signals were granted;
  3. the Meta connection is Active and the intended Pixel is not inactive;
  4. Offline Conversion is enabled on that Pixel for automatic signals, or the relevant Server Tracking rule is Active and points to that Pixel;
  5. a web event has a source URL;
  6. the event was not a retry already deduplicated by CJM.

For browser/server matching, also review event deduplication.

On this page