Many reddit threads around this specific topic. So I thought, this is what I want to write about.
In short: Meta can only optimize on the data (events) you feed it.
By default, all it gets is “someone started a chat,” so it finds more people who start chats, a different population from your buyers. You need someone to start the conversation, yes, but that is not the business goal that you want to achieve.
Optimizing your meta campaigns with the event “conversation_started” would simply mean that. You need to send events like qualified leads or purchases. So its delivery model can learn which chatters actually become buyers, instead of optimizing on the only event it gets for free: conversation started.
You optimize campaigns for the right goals using Signal Engineering. Let’s understand what happens after a click on CTWA.
What Meta Receives When Someone Clicks a CTWA Ad?
Before you can reason about optimization, you have to know exactly which fields Meta gets on which event. Most of the “our CTWA is broken” support tickets start here.
The Click, The Referral Object, And The Ctwa_clid
Walk the payload one step at a time.
A user taps your CTWA creative in Facebook or Instagram. WhatsApp opens on the destination business number pre-populated with your intro copy.
The user sends a first message. The WhatsApp Business Platform pushes that inbound message to your BSP’s webhook, and only on the first inbound message per user, Meta attaches a referral object to the payload.
The referral object carries ctwa_clid (the click ID for that specific tap), source_id (the ad that drove the click), the ad headline, and the ad type.
The ctwa_clid is the only durable link between a specific ad click and a specific WhatsApp conversation. It arrives on the first inbound message and does not repeat on subsequent messages from the same user.
If your stack does not capture and persist it there, it is gone.
One more window matters: ctwa_clid is valid for a 7-day post-click attribution window. Any CAPI event you fire tied to that click ID outside the 7-day window is discarded.
The Campaign Objectives And Optimization Goals Meta Supports For CTWA
Meta’s Click to WhatsApp Ads documentation is explicit about which objectives and optimization goals CTWA supports. Four campaign objectives are eligible, OUTCOME_ENGAGEMENT, OUTCOME_LEADS, OUTCOME_SALES, and OUTCOME_TRAFFIC, and each one exposes a different menu of optimization goals, the enum values Meta uses in the Marketing API and Ads Manager:
Read that table carefully. OUTCOME_LEADS, the objective most CTWA advertisers reach for, because the name matches their intent, allows exactly one optimization goal: CONVERSATIONS. You cannot pick an offline conversion event under this objective. That’s the “Meta only lets me optimize for chatters” trap, encoded directly into the API.
The only way out is OUTCOME_SALES with the OFFSITE_CONVERSIONS optimization goal, which requires CAPI events to feed Meta the purchase or qualified-lead signal it will then optimize on.
CONVERSATIONS is the only optimization goal Meta can measure on its own, it sees the WhatsApp thread open and counts it automatically, no setup required. Everything else, including OFFSITE_CONVERSIONS, only reaches Meta if you build the pipeline yourself: a class of custom conversion events sent through Conversions API for Business Messaging, with the payload carrying action_source: business_messaging and messaging_channel: whatsapp.
Sample of how a data looks like:
First Reply, Qualified Lead, Order Received, Purchase, none of these reach Meta unless you send them server-side. Meta cannot see inside a WhatsApp thread. It sees the tap and the first inbound message. That’s it.
The Fix Is OUTCOME_SALES + OFFSITE_CONVERSIONS (But You Have to Send Every Event Yourself To Meta)
CAPI for Business Messaging is the channel by which the offline events reach Meta. You take the ctwa_clid you captured on the first message, persist it against the user or the order, and post events back to Meta with action_source: business_messaging and messaging_channel: whatsapp so the delivery model can attribute them to the ad that started the thread.
That is the concept. The actual wiring, webhook capture logic, the persistence layer, the exact CAPI event payload field-by-field, event ordering, deduplication, and switching the campaign’s optimization event once you have Purchase volume - the implementation is a full separate blog, coming soon.
Why Does This Make the Algorithm Optimize for Chatters, Not Buyers?
Once you accept that conversation_started is the only event Meta logs automatically, the rest of the algorithm’s behavior stops being a mystery. It’s the system doing what the system does.
Because Meta Sees a Chatter and a $36K Buyer as Identicals
Take two users. Same ad, same day, both tap, both start a WhatsApp conversation.
- User A asks about the return policy, gets an answer, and ghosts. Never buy.
- User B asks a technical question, gets qualified by your team over four messages, and closes a $36,000 deal three days later.
If the only event Meta receives is conversation_started, it scores both users identically. Its lookalike model treats them as equally valuable seeds.
Its bid model treats the next tap that “looks like A” as worth the same as the next tap that “looks like B.” The model cannot tell A from B, because you never told it about B’s purchase. Everything that happens offline stays hidden to Meta.
(Just in case, if you want to start with offline conversion tracking)
Meta’s own H2 2024 global study found that CTWA campaigns optimized for purchases through messaging delivered roughly 10% lower cost per purchase compared to optimizing for conversations, and campaigns optimized for leads delivered roughly 24% lower cost per lead versus the same baseline.
Meta is telling you, in its own numbers, that the default setup isn’t the ceiling, it’s the floor.
This isn’t a marginal effect, and it isn’t a config error. It’s Meta’s own admission that the default configuration is structurally underperforming, and the gap widens with your basket size. High-ticket advertisers pay the biggest tax on this default.
When Meta receives only conversation_started events, it has nothing real to optimize toward, so it falls back to what it can see. Chatters, not buyers, is the output of the loop working exactly as designed.
One more constraint worth naming here: CTWA still needs roughly 50 optimization events per ad set per week to exit the learning phase. When you eventually switch off optimizing for CONVERSATIONS, you need enough volume on the new event to feed the model.
The Fix: Signal Engineering, Not Just More Events
Signal engineering isn’t sending Meta more events. It’s sending Meta the right events, stitched to one identity, all the way through to a value number Meta can actually optimize against.
The chain runs Meta → WhatsApp → website → CRM → back to Meta. Every stage after the click has to carry the same anchor forward and that anchor is the ctwa_clid you captured on the first inbound message.
Miss that anchor, and the chain can’t be rebuilt later; you’re back to four disconnected islands no matter how much you track downstream.
The Five Signals That Actually Need to Reach Meta
- The click (Meta): ctwa_clid, campaign, ad set, ad. This is captured automatically; it’s the anchor everything else ties back to.
- The chat (WhatsApp): not just conversation_started. Every meaningful stage of the thread: replied, engaged, qualified, or dropped off. Sent via CAPI for Business Messaging with action_source: business_messaging and messaging_channel: whatsapp.
- The website visit: if the conversation sends the buyer to your site to check pricing, a product, or a form, that browsing behavior has to tie to the same person and the same ctwa_clid, not sit in a separate, disconnected pixel pool.
- The CRM outcome: lead created, qualified, demo or site visit booked, negotiating, closed. This is the event that actually tells Meta a chat turned into a real buyer.
- The deal value: not “a deal happened,” but what it was worth. A $36,000 deal and a $1,800 deal are not the same signal, and Meta can’t tell them apart unless you send the number alongside the event.
Every one of these five needs a shared identity key, phone number or email, matched against the ctwa_clid or the chain breaks the moment the person leaves WhatsApp for your website or your CRM.
Mandatory parameters, sent back via Meta Conversions API, matched to the original click: ctwa_clid and/or match identifiers (phone, email), event time, and value along with currency, so Meta can optimize toward high-value deals instead of just any deal.
What Has to Be in Place Before This Works
- A CTWA campaign built on the “Send Message → WhatsApp” setup, that’s what makes Meta generate the ctwa_clid in the first place.
- WhatsApp Business API access through a provider, not a plain WhatsApp Business app, the click ID and chat-stage events only surface in the API-layer webhook.
- A tool connected to catch and store the ctwa_clid the moment the chat opens, this is the step most setups skip, and the ID is gone if nothing saves it at that exact handoff. This is the piece CustomerLabs is built to do.
- Website tracking in place, CustomerLabs on the site, so browsing sessions tie to the same person and the same click ID.
- Your CRM is connected as a source (Zoho, HubSpot, etc.), so deal stage and deal value flow into the same journey.
- A shared match key, phone and/or email, linking the WhatsApp thread, the website session, and the CRM record into one profile, with the click ID tying that profile back to the ad.
- Meta Conversions API connected for the trip back, so the full journey and its value post against the original click.
Once value is actually flowing, switch the campaign’s optimization goal from CONVERSATIONS to a value-based OFFSITE_CONVERSIONS goal. That’s the real shift: instead of chasing “anyone who’ll open a chat,” Meta starts chasing people who look like the ones who closed your highest-value deals, because you finally gave it a number to chase.
Expect the ad set to need 5–7 days to re-learn, and expect fewer conversions at first than a conversations-optimized campaign reported, that’s the point, not a regression.
Baseline Your Funnel Before You Touch the Optimization Event
Before switching anything, capture how your chats actually convert today. Over the last 7 to 30 days, work out, by campaign: how many chats started, and how many of those became qualified, booked a next step (demo, site visit, consultation), and closed, plus your average deal value.
The two rates that matter most are chat → qualified and qualified → closed, along with the cost behind each. Lock these numbers in writing before you launch the new setup, or you won’t have anything to measure the switch against.
Pick the Conversion Event and Get the Campaign Structure Right
- Conversion event: the deepest funnel stage that still has enough volume to learn on, qualified lead, demo booked, or closed sent via CAPI matched to the ctwa_clid. This is what stops Meta chasing chat-starters and starts finding people who actually progress.
- Send deal value, then switch to value optimization: with real deal value flowing back, Meta can chase your $36,000 bookings specifically, not your $1,800 ones, and not the chats that never close at all.
- Pick the right stage for your volume: bookings and closed deals are often too rare to learn early, especially for high-ticket or long-cycle businesses. Start the optimization event at a stage with enough weekly volume (qualified lead or demo booked, for instance), and move it deeper as volume grows, the same roughly-50-conversions-a-week rule that applies to exiting the learning phase generally.
- Audiences: build lookalikes from qualified and closed customers, not from every chat-starter, this is covered in more depth further down.
- Creative: keep the ad creative matched to the offer the qualified stage is built around, so the traffic Meta finds is already primed for that conversation.
P.S. You can integrate Whatsapp, Meta Account, And any crm of in stack at ease.
Report the Full Funnel, Not Just Chats Started
Add the journey events and your qualified/booking signal into your Meta reporting, Custom Metrics in Meta Ads Reporting is the mechanism, so you can see, per ad, how many chats became qualified leads, demos, or bookings, and what those were worth.
Judge the campaign on qualified leads, bookings, and deal value, not on chats started; chat volume is the easiest number to move and the least connected to revenue.
One more expectation to set going in: this signal arrives with a lag. High-ticket and long-cycle deals close over weeks, not days, so give the new setup time before judging it, and make sure your key conversion stage lands inside your attribution window or optimize on an earlier, deep-enough stage if it doesn’t.
If you’d rather not build the webhook-to-CAPI pipeline in-house, CustomerLabs runs the same ctwa_clid capture, CRM stitching, and CAPI event forwarding as a managed integration, so you can be sending Purchase and Lead events back to Meta without writing the plumbing yourself.
Book a demo to see your CTWA data flowing into Meta correctly, or start a 14-day free trial and connect it yourself.
