Where Meta lead ads go missing between the form and the first call

A lead ad works differently from a form on your site. The person never leaves the feed: Meta prefills their name, email and phone from the profile, they tap twice, and the lead is created inside Meta. Nothing has been sent anywhere yet. Everything after that tap is delivery, and delivery is where leads go missing.

Your leads are not missing, they are somewhere nobody opens

Before blaming the integration, find out whether the leads exist. There are three places to look, and only one of them is where work actually happens.

• –Leads Center in Meta Business Suite: the complete list, always current, and the one screen nobody has open during the workday.
• –The form's export in Ads Manager: the same leads as a file you download by hand, one form at a time.
• –Whatever destination you connected: a CRM, a webhook, an email notification, or nothing at all.

If nobody ever connected a destination, nothing is broken and reconnecting fixes nothing: the leads are sitting in the Leads Center exactly as designed, getting older. Meta's own documentation puts the download window at 90 days, and after that the row is gone whether you exported it or not. Downloading later is not a backup plan, it is a deadline.

Leads access is its own permission, separate from being an admin of the Page. A tool can authenticate, show as connected, and still return zero leads, because the system user it runs as was never granted leads access to that Page in Business Settings.

The shape of the loss tells you where it broke

From the outside the symptoms look alike: fewer leads than expected. What separates them is when the loss started and whether it takes every lead or only some.

Email as the transport

Email is the quickest destination to set up and the least reliable one. The message is machine-generated, comes from an address you have never replied to, and lands in a shared inbox that belongs to nobody. To a filter, that is a fair description of spam. Check spam and quarantine before deciding the leads never arrived, then move off email: a notification is fine, a system of record it is not.

The authorization that quietly expired

When a connection runs for weeks and then stops dead, start with the token. A long-lived user token from Meta lasts about 60 days, and the Page token derived from it works only while that user token is valid. It can go earlier: the person who authorized it changes their password, loses admin rights on the Page, removes the app, or the business revokes its permissions. Nothing turns red in the CRM, the rows just stop, and that is the fingerprint: leads end on a specific day and hour instead of tapering off.

Partial delivery

When some leads arrive and some do not, the connection is alive and the transport is dropping. New leads are pushed by webhook, Meta retries when your endpoint fails to answer, and it does not retry forever. Leads created during an outage stay in the Leads Center and never get pushed anywhere. Compare counts by day, not by month: a monthly total hides a four-hour gap completely.

Duplicates

There are two kinds, and they need opposite handling. A delivery duplicate is one lead delivered twice: both rows carry the same lead id from Meta, so deduplicate on that field and drop the second. A human duplicate is the same person submitting twice, which is easy when the form is prefilled and takes two taps. Match those on normalized phone and email inside a time window, then merge rather than delete: the ad behind the second submission may not be the ad behind the first.

Why the wait costs more here than on your site

Filling a form on a website takes typing and a decision to leave the feed first. Two taps mid-scroll take neither: the person invested nothing and by evening may not remember which business was yours. Rather than borrow anyone's number for this, store the minute the lead arrived and the minute of the first attempt to reach it, bucket the gap (under five minutes, under an hour, same day, later), and compare your connect rate across the buckets.

Record where the lead came from, and record the ids

The payload Meta returns carries more than a name and a phone number. It has the creation time, the form, the platform the person was on, whether the lead was organic, and the three identifiers that matter: ad id, ad set id and campaign id.

Store the identifiers, not only the names. Names are read at query time and they change: somebody renames a campaign mid-flight, and the label on last month's leads changes with it. The id does not move. Three things become possible once it is on the record.

• –Cost per qualified lead, by ad. Ads Manager knows what a form fill cost. Only your pipeline knows which fills became conversations, and the join between the two is the ad id.
• –A reason to switch an ad off. The ad with the cheapest cost per lead and no bookings behind it is the most expensive ad in the account, and nothing inside Ads Manager can show you that.
• –Conversions API. When a lead turns into a customer, sending that event back is what lets optimization aim at revenue instead of form fills. For an instant form lead the lead id itself is an accepted identifier, so the match does not depend on a cookie.

Open the call with the ad, not with the form. "You submitted a request" gets a confused pause. "You tapped our ad about the spring service special a few minutes ago" gets recognition. To say the second sentence, you need the ad on the lead record.

Aevin subscribes to the page's lead forms itself: the lead lands in the pipeline when the form is submitted, with its ad, ad set and campaign ids on the record and the wait since it arrived visible on the card.

How to tell the source has gone missing

Source data does not fail loudly. It starts arriving empty while everything else keeps working, so it goes unnoticed for weeks and takes a month of attribution with it. Three counts catch it.

1. 1.Daily counts side by side: leads in the ad account against rows in the pipeline for the same day. Equal is healthy, fewer rows means delivery is dropping, more rows means duplicates or another channel writing into the same place.
2. 2.The share of rows with no ad id. The API supplies one for every paid lead, so a rising share of blanks means something upstream stopped passing the field: a new form, a changed mapping, a route somebody added.
3. 3.Everything landing under one source. If a hundred leads this week all say Facebook, or all point at one campaign while four are running, the field is being defaulted rather than captured.

The hardest failure to notice is the one that produces nothing at all: a broken pipe and a slow Tuesday look identical from the pipeline. So alert on absence, not only on volume. If spend continued and no lead has arrived in several hours, treat it as a break until proven otherwise.

A path that does not lose leads

None of this needs a new stack. It needs deciding once where a lead lives and what travels with it.

1. 1.One destination, not four. Pick the place where the work happens and make it the only record. Email alerts can stay as a heads-up, they cannot be the record.
2. 2.Grant leads access to a system user, not to a person's account. People change roles, lose Page admin and leave; a system user does not.
3. 3.Deduplicate at intake: first on the lead id, then on normalized phone and email within a window.
4. 4.Write the ad id, ad set id, campaign id and creation time on every row as it arrives. Attribution backfilled later never actually gets backfilled.
5. 5.Route by recency, not by fairness. The newest lead outranks whatever is in the queue, because it is the only one still in the moment.
6. 6.Check two numbers weekly: account leads against pipeline rows, and the share of rows with no source.

Every one of those checks is a count, a timestamp or a ratio of empty fields. None of them needs judgment, which is why they should run on a schedule instead of in the week somebody finally asks where the leads went.