Define the gap before selecting the connection
An inquiry journey may contain a confirmed server or CRM outcome whose meaning is not fully represented by browser measurement. CAPI provides a transport route under the platform’s configuration; the business definition and data quality remain the team’s responsibility.
Start the integration brief with the CRM stages, available tools, permitted fields and receiving owners. Use those inputs to define and validate the implementation.
Choose a real milestone before its event name
A successfully stored inquiry differs from a button click. Qualification requires agreed criteria verified by sales; a contract requires the appropriate business record. Document these definitions before publishing events.
Select supported events appropriate to the account; do not mechanically reuse GA4 event names in Meta. A submitted form should not be presented as a purchase simply because that label looks more valuable in a dashboard.
What should a Meta CAPI and CRM integration actually deliver?
Before commissioning an integration, ask for a stage-to-event map, named owners and evidence from a test outside production lead reporting. A dashboard showing accepted events does not show whether the correct CRM outcome was sent, whether a retry duplicated it or whether the data use was permitted.
Agree the boundary between the CRM, integration service and Meta. Decide who corrects a failed delivery and who checks the business meaning. Do not send customer contact data through GA4 to make a reconciliation easier. Approve the implementation against event delivery and deduplication checks, then evaluate campaign outcomes from CRM.
On smaller screens, scroll the table horizontally to read all columns.
| Ask for | Evidence to inspect | What this does not prove |
|---|---|---|
| Stage-to-event map | Definition, trigger, source record and responsible owner | That every CRM stage belongs in Meta |
| Duplicate and retry test | One outcome retains its identity across repeated delivery | That a later qualification is the same event as initial receipt |
| Reconciliation and failure handling | Source count, accepted/rejected deliveries and retry owner for one defined period | Exact equality across systems with different scopes |
| Permitted data flow | Agreed fields, access and applicable consent checks | Permission to send personal data to Analytics |
An illustrative event identity example
Meta’s official SDK describes event_id together with event_name as identifiers used to recognize copies sent from server and browser. Use the identity example to define the event mapping, then complete the payload against the current reference and account setup.
On smaller screens, scroll the table horizontally to read all columns.
| Source | Illustrative event | Example identity | Meaning |
|---|---|---|---|
| Browser | Lead | demo-inquiry-001 | One copy of a confirmed inquiry |
| Server | Lead | demo-inquiry-001 | The same outcome, not another inquiry |
| Server retry | Lead | demo-inquiry-001 | Preserve the outcome identity |
| Later CRM milestone | Supported mapped event after verification | demo-inquiry-001-fit-01 | A distinct transition after registration |
Primary reference: Meta Business SDK: server event fields and deduplication identity
Check timing, origin and required fields
Use the actual occurrence time; Meta describes event_time as a Unix timestamp in seconds. A retry should not overwrite it with a new outcome time. action_source describes where the outcome occurred rather than labeling every sales result as a website action.
Complete the matching information and required fields against the reference and account configuration before sending production events. Keep access tokens out of the browser and avoid forwarding personal records or conversation text to inappropriate destinations.
Validate delivery before interpreting business performance
Use an appropriate test environment or event-testing tools rather than creating fake production inquiries. Trace one confirmed receipt with its browser and server copies, a retry and a separate qualification milestone. Check that browser success was not emitted before receipt was confirmed.
Inspect delivery logs, diagnostics and the underlying CRM state. Technical acceptance does not establish advertising attribution or optimization use. Neither does a diagnostic score establish commercial return without actual outcome evidence.
- Stable identity for one outcome; separate identity for a later stage.
- Accurate occurrence time and actual action origin.
- Error and retry logs without additional manufactured outcomes.
- Review the account’s current requirements before live activation.
Separate measurement repair from a sales claim
The review is useful when every event can be explained and its stage count reconciled with the source system. Then compare the same acquisition cohort and follow-up interval, distinguishing better measurement from better business performance.
Begin with the CRM stage map, permitted event fields and aggregate figures. Validate delivery and deduplication, and use the project's qualification and sales outcomes for commercial review.
Frequently asked questions
Choose the next step for your project review
- Compare CPQL and advertising spend per contract
- Review calculation definitions and limits
- Read the GPR Property experience in context
Share the project brief, target market and available budget. For existing campaigns, include aggregate spend, lead quality and follow-up outcomes for the same period to define the scope and deliverables.
Explore the service and discuss your project