Meta Conversions API for CRM: Send Site Visits and Bookings Back to Meta for Better Leads

When a campaign is optimised for leads, Meta learns from one signal: the form was submitted. It has no idea what happened next. A buyer with a real budget and a person who tapped through out of boredom look identical at that moment, so the system simply goes looking for more people who behave like form submitters.

In Indian real estate this shows up as low-intent and fake leads. Prefilled forms make it easy to submit by accident, and people who submit casually are often the cheapest to reach, so the algorithm leans toward them. Your telecallers then spend their day separating buyers from noise, which is the slow and expensive part of the whole process.

It is worth pushing back on the common advice to just add more form questions. That can help, but it only filters at the door. It does not teach Meta anything about who actually turns into a site visit or a booking. Feeding the outcome back does, because it gives the algorithm a reason to prefer one kind of person over another.

There is also a quieter cost. Every junk lead that reaches a telecaller delays a call to a real buyer, and in property, speed to first call matters. So the damage from optimising on the wrong signal is not only wasted ad spend, it is also wasted sales hours.

The idea is simple. Every time a lead moves to a new stage in your CRM, you send that change to Meta as an event. According to Meta's Conversions API for CRM documentation, the integration is built so that Meta can learn which leads become qualified and optimise delivery toward similar people.

Each event needs a few required fields. The event_name is your own stage name, for example 'Site Visit'. The event_time is when the change happened and must be after the lead was created. The action_source is 'system_generated', and custom_data carries an event_source of 'crm' plus a lead_event_source, which is simply the name of your CRM.

To tell Meta which lead the event belongs to, you identify it with the Meta lead_id from the instant form, and/or a hashed email and phone number. The lead_id is the cleanest match, which is why losing it at import time is the most common mistake. Also send every stage as it happens, including the initial lead stage, so Meta sees the whole journey and not only the happy endings.

Think of it as a running commentary on each lead. The form submission is the first line, and every stage change adds another. Over time Meta can see which kinds of people produce a long commentary that ends in a booking, and which produce a single line and silence.

Your stage names become the event names, so they need to be deliberate. A five-stage pipeline of New, Contacted, Site Visit, Negotiation and Booked maps neatly, and each stage tells Meta something different about lead quality.

The early stages are volume signals. The later ones are quality signals, and those are the ones you ultimately want the algorithm to chase. Keep the names identical every time, because 'Site Visit' and 'Site visited' would be read as two different events.

One practical point: a site visit is usually the best stage to watch first. Bookings are rare in any single campaign, so they take time to build up a useful number of events, while site visits happen more often and still reflect real intent.

Timing is worth knowing before you start. Events typically show up within about 30 minutes, and Meta measures CRM match quality over 24 to 48 hours. So do not judge the setup on the first afternoon, and do not change three things at once while you wait.

Once enough events are flowing, you can switch the campaign to the 'conversion leads' optimisation goal. Until then the campaign keeps running on regular lead optimisation, which is fine. The goal is to build the signal first and change the objective second.

If you are working with a developer or a CRM vendor, hand them the list of required fields and your agreed stage names on day one. Delays usually come from stage names being decided halfway through the build.

Here is the catch. This optimisation currently supports Meta's native Instant Forms, meaning lead ads, and not website forms. If your landing page form is where most leads come from, sending stage updates for those leads will not switch on the conversion leads goal in the same way.

That is not a reason to rebuild everything. It is a reason to be honest about which campaigns this applies to. Many developers run both: Instant Form campaigns for quick volume and landing page campaigns for detail-rich enquiries. The first group is where the Meta Conversions API loop pays off most directly.

For website forms, the answer is a separate tracking setup, which is a different conversation. Our conversion tracking work covers both sides so each campaign type sends the right signal.

Most failures here are boring ones. A missing ID, a renamed stage, or a batch of events sent three weeks late will quietly weaken the signal. Run through this list before you change any campaign goal.

If your CRM already handles this, even better. ArthaLeads imports Facebook and Instagram lead ads automatically and lists Meta Conversions API among its integrations, so the lead and its stage updates live in one place instead of a spreadsheet someone updates on Fridays.

Start small. Pick one Instant Form campaign, confirm your lead_id is being saved, lock your stage names, and send events for a couple of weeks before touching the optimisation goal. That alone will show you how clean your pipeline data really is.

If your sales stages are inconsistent or half-filled, fix that first. The Meta Conversions API only passes along what your CRM knows, and a CRM that is updated late teaches Meta late. For real estate teams, the real estate workflow is usually the place to tighten.

If you want help with the build, the Vistrow team sets up conversion tracking end to end, from lead capture to event checks. You can request a growth audit and we will look at where your signal breaks.