Meta Ads reports enquiries, but the sales team knows more: who fits the requirements, who has started a discussion and who actually purchased. When this information remains only in the CRM, the advertising report does not provide a complete picture of lead quality.
Sending CRM events helps connect advertising with subsequent outcomes. This requires agreed status definitions, an integration and checks on how events are received and used. Connecting a service alone does not guarantee better leads.
A “Meta → CRM” integration retrieves new enquiries for handling. A “CRM → Meta” integration reports what happened after the enquiry. These are different directions, and a working first integration does not confirm that the second works.
Meta uses Conversions API to transmit events. Its official lead generation guide describes connecting a CRM, Conversions API and the conversion leads goal for instant forms. The availability of this optimisation and the setup requirements must be checked for the specific campaign and account. Meta lead generation guide.
The workflow for a website form may differ from that for an instant form. Instructions for one option should not be treated as universal. If you are choosing where to collect enquiries, read “Meta lead form or landing page”.
Start with business logic rather than technical event names. Define which facts the CRM should record:
These names describe the business process, not a ready-made set of API events. A specialist must map them to the supported schema of the chosen integration.
Qualification must be consistent across sales staff. “I liked the contact” is not a verifiable criterion. Use the requirement, market, project scale and other attributes relevant to your ability to provide the service.
Do not transmit a sent commercial proposal as a completed sale. If payment is the basis, its confirmation should trigger the corresponding event.
A lead must have a persistent internal identifier. Also retain available source information and permitted matching data.
For instant form enquiries, retain Meta’s lead identifier instead of substituting the CRM record number. In the official SDK, lead_id refers to Facebook Lead Ads leads; fields for contact details and other identifiers are also available. The fields used depend on the workflow. User data structure in the Meta Business SDK.
Do not invent missing identifiers or transmit the entire customer record “just in case”. Before sending data, define the permitted fields, the basis for their use and any necessary notices or consent. Check the normalisation and hashing requirements for each field. Hashing does not automatically make data transmission permissible.
Specify the following in the technical brief:
Meta’s official SDK includes event_name, event_time, event_id, action_source, user_data and other fields. Required parameters must be checked for the integration being used; the upload date should not simply replace the time of the event itself. Meta event structure.
For monetary values, agree on a consistent definition: revenue, the amount paid or another measure. Do not mix an assigned qualified lead value with an actual payment in a sales report. The additional event data includes the fields value and currency. Additional data in the Meta Business SDK.
The same fact may be sent several times: through the browser Pixel, a server integration and repeated CRM processing.
If the same event is sent from the browser and the server, align its name and ID: Meta uses event_name together with event_id to identify such matches. When resending the same fact, retain its identifier rather than generating a new one. Identifier description in the official SDK.
Different stages for the same lead are still different facts. Receiving an enquiry and a later payment should not share one event record merely because they relate to the same customer.
Hypothetical example: an enquiry with internal number 104 is created on Monday, qualified on Tuesday and paid on Friday. Each stage retains a separate identifier. Resending Friday’s payment after a failure uses the same payment ID. A specialist chooses event names according to the current integration schema.
When accepting the integration, establish the following separately:
A successful API response confirms request processing but does not guarantee attribution of every sale to advertising. An event’s presence in the system does not mean that the campaign is already using it to guide ad delivery.
Test several control enquiries. Compare the CRM log, submitted events, integration responses and available Events Manager diagnostics. Also check retries and the absence of an event when its condition has not been met. Test records must not distort operational assessment.
First establish reliable transmission of accurate data. Then assess cost per qualified lead and customer using lead cohorts with comparable observation periods.
Do not expect the integration to fix an offer, an unsuitable audience or slow handling. If the problem lies in the enquiries themselves, use our plan for improving Meta Ads lead quality. For an economic assessment, see our article on CPL and customer acquisition cost.
As part of advertising setup and management, agree separately on the event map, CRM responsibilities, technical integration and verification process. Discuss the scope of work using our commercial proposal.