Meta Conversions API for Click-to-Message Ads

If you run click-to-message ads you have probably noticed that the reporting stops at the interesting part. Meta can see that someone clicked the ad and opened a conversation. What happened inside that conversation is invisible to it, which means the ad that produced a sale looks identical to the ad that produced a browser who asked one question and left.

That gap has a cost beyond reporting. Ad delivery optimises towards the outcomes it can see, so if all it can see is conversations opened, that is what you will get more of: conversations, not customers.

What the Conversions API is

The Conversions API is a server-side way of telling Meta that something happened. Instead of a browser pixel firing on a thank-you page, your server sends the event directly. For messaging businesses this matters more than it does for websites, because there is no thank-you page: the conversion happened in a chat, on a platform, inside an app.

What MuChat sends

Every conversion MuChat records is sent to Meta as an Instagram business messaging event. That includes conversions recorded by a flow step, through the API, from a sale made in a DM, and ones you record manually after the fact, which matters for businesses where the final yes happens on a phone call.

• The Instagram account the conversation belongs to, and the person's Instagram id.
• Hashed contact details, email or phone, where you hold them.
• An event id, so the same event reaching Meta twice is counted once.

Mapping your conversions to Meta's events

Meta understands a set of standard events, such as Purchase and Lead. Your business probably has its own names for things: consultation booked, quote accepted, deposit paid, sample requested. In MuChat, each conversion event you define maps to one of three outcomes: a standard event, a custom event, or not sent at all.

That third option matters more than it looks. Not every internal milestone deserves to be optimisation signal. Sending everything teaches the ad system that everything is equally valuable, which is the same as teaching it nothing. A good rule: send the events you would defend in a budget meeting, and keep the rest for your own reporting.

Custom events are the middle ground. They reach Meta and can be used for analysis without being confused with a purchase, which is useful for the steps that predict revenue without being revenue.

What changes once the loop is closed

1. 01Reporting stops lying by omission. Sales that happen in a DM appear against the ad that produced them.
2. 02Optimisation has something real to work with, because the events describe outcomes rather than clicks.
3. 03You can compare ads by what they produced rather than by how many conversations they opened.
4. 04The gap between channels narrows: DM selling stops looking worse than web selling purely because it was unmeasured.

Deduplication, and why the event id matters

Each conversion MuChat records is sent with its own event id, so if the same event reaches Meta twice, through a retry for example, Meta counts it once rather than as two sales. What the id cannot do is merge two separate recordings of one sale: if a flow step records a purchase and someone also records it by hand, that is two conversions. Pick one place to record each kind of sale, and your reporting stays honest.

The pixel, and where it still applies

There is also an optional browser pixel for MuChat-hosted link-in-bio pages. That covers the ordinary web case: someone lands on a page rather than a conversation. It is a complement to the Conversions API, not a replacement, and it only applies to pages MuChat hosts for you.

Setting it up honestly

Two things are worth deciding before you switch anything on. Which of your conversion events genuinely represent value, and what you will do with the reporting once it is accurate. A cleaner attribution picture is only useful if it changes a budget decision; if you would spend the same either way, this is a reporting exercise rather than a growth one.

What good looks like after a month

A month in, the reporting should be boring in a useful way. The conversions you send should roughly match what your own records say you sold, allowing for the people who bought without ever clicking an ad. If Meta reports far more than you recognise, a sale is probably being recorded in two places or an event is mapped too generously. If it reports far fewer, the events are probably being sent without the contact details needed to match them.

Either way the fix is in the mapping rather than in the ads, and it is worth resolving before you change a budget on the strength of the numbers.

What this does not do

Sending conversions does not make a bad ad work, and it does not recover attribution for conversations that happened before you switched it on. It also does not tell you why someone bought. It closes one specific gap: the platform buying your ads can finally see the outcome of the conversations those ads produced.

When you have decided which events count, connect your Meta dataset in Settings, map each one, and leave it a week before drawing conclusions. Early numbers after any attribution change look dramatic and mean little. Setup lives in /help/getting-started, and /product/flow-builder shows where a conversion step sits inside a flow.