The ad platform reports one number, the form tool another, the CRM a third. The tempting conclusion is that one of them is wrong. Usually they’re counting different things.
The fix is to match records one by one, using IDs you control, and give every difference a reason. Below is a full worked example with fictional records.
Six things that get called “a lead”
| Count | What it is | Where it lives |
|---|---|---|
| Logged event delivery | One conversion event your site or server sent to the ad platform | Your own event log (tag manager, server logs) |
| Platform-credited result | A conversion the platform attributed to a campaign under its own attribution and modeling rules | Ads Manager / Google Ads reports |
| Form submission | One press of submit, accepted by the form system | Form tool log |
| CRM contact | One person record | CRM |
| Graded candidate | A contact graded Qualified, Nurture or Disqualified | CRM grade field |
| Signed agreement | A signed franchise agreement (track people and units separately) | CRM deal record |
The first two are not the same. Your log shows what you sent. The platform’s report shows what it credited, after its own deduplication, attribution windows and modeling. Fourteen deliveries sent doesn’t mean fourteen leads credited. You reconcile your own log record by record. The platform’s credited total is compared separately, as an aggregate.
The worked example
Fictional franchisor, one week, one campaign. These figures are invented for teaching.
- Your event log shows 14 event deliveries (browser and server).
- The form tool shows 12 accepted submissions.
- The CRM shows 9 new contacts.
Every submission gets a submission_id when the form accepts it. That ID is sent with the event as the business_event_id, and stored in the CRM as an external ID. It’s the join key for everything below.
| Row | delivery_id | business_event_id | event_name | transport | submission_id | crm_contact_id | What happened |
|---|---|---|---|---|---|---|---|
| 1 | D101 | S01 | Lead | browser | S01 | C501 | Clean match |
| 2 | D102 | S02 | Lead | browser | S02 | C502 | Clean match |
| 3 | D103 | S03 | Lead | browser | S03 | C503 | Browser and server both sent… |
| 3 | D104 | S03-srv | Lead | server | S03 | C503 | …but the server sent a different ID (S03-srv), so ID-based deduplication isn’t established for this pair |
| 4 | D105 | S04 | Lead | browser | S04 | C504 | Clean match |
| 5 | D106 | S05 | Lead | browser | S05 | C505 | Same mismatch as row 3… |
| 5 | D107 | S05-srv | Lead | server | S05 | C505 | …second delivery |
| 6 | D108 | S06 | Lead | browser | S06 | C506 | Clean match |
| 7 | D109 | S07 | Lead | browser | S07 | C506 | Same person resubmitted the next day; the CRM matched them to the existing contact |
| 8 | D110 | S08 | Lead | browser | S08 | (none) | Accepted by the form; the CRM integration returned an error |
| 9 | D111 | S09 | Lead | browser | S09 | C507 | Clean match |
| 10 | D112 | S10 | Lead | browser | S10 | (excluded) | Internal test, excluded from the CRM, but sent to the platform as a normal event |
| 11 | D113 | S11 | Lead | browser | S11 | C508 | Clean match |
| 12 | D114 | S12 | Lead | browser | S12 | C509 | Clean match |
Reconciliation:
- 14 deliveries = 12 submissions + 2 extra server deliveries (rows 3 and 5)
- 12 submissions = 10 distinct non-test people + 1 resubmission (row 7) + 1 test (row 10)
- 10 distinct people = 9 CRM contacts + 1 unresolved delivery failure (row 8)
Three things to fix:
- Rows 3 and 5: the browser and server events carry different IDs. The pair doesn’t meet the ID match that Meta’s recommended deduplication method relies on, so you can’t assume the platform counted it once. See the next section.
- Row 8: the record never reached the CRM. It stays an unresolved failure until it’s recovered. After the integration is repaired, log the recovery as a separate state: recovered contact ID, when, and by whom. Until then, report it as one unresolved failure, not a recovered one.
- Row 10: the test was kept out of the CRM, but it still went to the ad platform as a real conversion. Send test events through the platform’s test mode, or exclude them from production delivery, so tests don’t train the campaign.
The resubmission in row 7 is working as designed. Keep both submissions in the log and one person in the CRM.
Deduplication: mapping your log to Meta’s fields
business_event_id is a field in your own log. It means nothing to Meta until you send it in the fields Meta reads. Meta’s documentation (checked 28 Oct 2026) describes two methods:
| Method | What has to match | Notes |
|---|---|---|
| Event ID + event name (Meta’s recommended method) | Pixel eventID = Conversions API event_id, and pixel event name = Conversions API event_name | Deduplicated if the duplicates arrive within 48 hours of the first event with that event_id, sent to the same Pixel ID |
| fbp and/or external_id | event_name plus fbp and/or external_id, used consistently | The browser event has to arrive first. Duplicates from the same source (browser-only or server-only) aren’t removed |
For this example, send business_event_id (S03) as the pixel’s eventID and as the server’s event_id, with the same event name (Lead) on both. Rows 3 and 5 fail the ID-match condition because the server sent S03-srv and S05-srv, respectively. This log alone does not establish the platform’s eventual credited count.
To check it, use Meta’s event diagnostics or test events tool together with your own log. Don’t use the Ads Manager lead count, because a test submission won’t necessarily show up as an attributed lead. Check attribution reporting separately, afterwards. Other platforms use their own fields; map each one from its own documentation.
Joining records
Join on the submission_id that you stored on both sides. It’s the shared key used in this example. Any stable identifier stored on both sides works the same way. Where an old record lacks one, fall back to email plus submission time and set the confidence by how much else agrees: fallback, high if phone, landing page and campaign also match; fallback, low if only email and an approximate time match; ambiguous if two candidates could fit. Don’t assume you can export every modelled or attributed platform conversion at record level. Most platforms don’t expose that.
How to run this on your own data
- Fix the window. Same dates and time zone in every system. Note when you exported, because a CRM sync can lag.
- Export record-level data from your event log, the form tool and the CRM, each including
submission_id. - Join on
submission_id. Use the fallback only where you have to, and label its confidence. - Give every unmatched row a reason from a fixed list: extra delivery, resubmission, test, delivery failure, sync delay, unknown. “Unknown” is allowed and stays visible until it’s investigated.
- Compare the platform’s credited total separately. If it differs from your distinct-people count, note the attribution settings and look into it. Some gaps can be explained. Some stay open, with their limits written down.
- Fix causes, then retest with a marked test submission.
What to report
Report events and people as separate lines. For the example week:
14 event deliveries; 12 submissions; 10 distinct candidates (9 in the CRM, 1 unresolved delivery failure). Platform-credited results reported separately under its attribution settings.
Then grade them. The candidate in row 8 isn’t in the CRM yet, so only 9 can be graded until that record is recovered. If 4 of the 9 are Qualified, report “4 Qualified of 9 graded; 1 not yet graded (unresolved delivery)”, not “4 of 10”.
Start here
Pick last week. Export the three systems at record level, including submission_id. Fill in the reconciliation log. Every row ending as “unknown” is something to investigate.
Download: reconciliation-log.csv, the 14 delivery rows above with every field.
Related: Source tracking from click to CRM · Qualifying candidates
Source (checked 28 Oct 2026): Meta: Handling duplicate Pixel and Conversions API events
Work through your own numbers
Franchise inquiry leak audit. Enter your own records and assumptions. The tool does not store your inputs; its example figures are fictional.
Put it to work on your recruitment system
Bring your recruitment page and anonymized stage counts to a diagnostic. We’ll identify what to test and how to measure it.
Discuss your franchisor recruitment system