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:
- connect Meta under Setup → Channels;
- add the required Meta Pixel and enable Offline Conversion under Setup → Offline Conversion for automatic CJM signals;
- for a custom Pixel-event mapping, create an active Server Tracking rule;
- implement consent so
adUserDataandadPersonalizationcan be granted.
Events sent automatically
| CJM condition | Custom CJM event | Meta standard event |
|---|---|---|
| At the first MQL qualification, Fit is at least 60 | CjmMqlHighFit | SubmitApplication |
| At the first MQL qualification, Intent is at least 60 | CjmMqlHighIntent | SubmitApplication |
| First entry into SQL | CjmSql | Contact |
| Opportunity with positive value | CjmOpportunity | Contact |
| Won with positive value | CjmWon | Purchase |
| Lead captured | — | Lead |
| Pixel page load | — | PageView |
| Other supported Pixel interaction | — | ViewContent |
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.
Consent and duplicate protection
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
- Open Signals and select Meta CAPI.
- Choose the date range.
- Add filters for Status, originating CJM Event, or Pixel.
- 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:
- the source event reached CJM;
- both advertising consent signals were granted;
- the Meta connection is Active and the intended Pixel is not inactive;
- Offline Conversion is enabled on that Pixel for automatic signals, or the relevant Server Tracking rule is Active and points to that Pixel;
- a web event has a source URL;
- the event was not a retry already deduplicated by CJM.
For browser/server matching, also review event deduplication.