A Meta ad sends the user to a Telegram channel or account. From that click onwards, the pixel sees nothing: not the join, not the conversation with the closer, not the broker sign-up, not the deposit. A campaign optimised on what the pixel measures therefore learns to find people who click, not people who go all the way through the funnel.
Why the pixel is not enough
The pixel is a script that runs in a browser, on a page you control. Telegram is not that page. A channel join, a private message or a deposit with the broker all happen in environments where no Meta script runs.
The Conversions API addresses this without involving the browser: the event is sent server to server, from the tool that actually knows about the join, the lead or the deposit. ScaleGram sends these events to Meta through the Conversions API (Graph API v23.0), server-side. Meta receives an event along with identifiers it can match to its own users and, when the original click is known, to a specific ad.
That does not settle everything. What is sent, when, and with which data changes what Meta can attribute. That is what the following sections cover.
The default mapping between the CRM and Meta
Each stage tracked in the CRM maps to a Meta standard event. The default configuration is as follows:
- Channel join: Subscribe, enabled.
- Join request: Subscribe, disabled.
- Bot start: Lead, disabled.
- First private message: Contact, disabled.
- Lead: Lead, enabled.
- Broker sign-up: CompleteRegistration, disabled.
- Deposit: Purchase with value, enabled.
Each rule can be changed per pixel. You can therefore keep one pixel that only receives deposits and another that receives the whole funnel, depending on how you use them in Ads Manager.
Two pairs need attention. The join request and the join both send Subscribe; enabling both means reporting two different stages under the same name. The bot start and the lead both send Lead, with the same effect. For each Meta event, pick the stage that genuinely represents the signal you want optimised.
Choosing the campaign objective is then a trade-off. Subscribe arrives early and often, but it measures a join, not an intention to deposit. Purchase is the event closest to what pays you, but it arrives later and less often. No setting removes this trade-off.
The deposit is only sent once it is confirmed
The Purchase event is only sent for a confirmed deposit. Three situations trigger it: a deposit created directly with the confirmed status, a deposit moving from "pending" to "confirmed", or the CellXpert sync bringing in a net deposit that had not already been entered in the CRM. A pending deposit produces nothing on the Meta side until it has been confirmed.
The deposit is sent with its value and a currency. The default currency is the workspace's commission currency, otherwise USD. The value is only sent if the pixel rule provides for it. Without a value, Meta receives a Purchase that counts as a conversion but cannot be used to optimise on an amount.
The CellXpert case covers a common gap: a deposit the closer did not enter but that the broker's affiliate platform records. If it is already in the CRM, it is not sent a second time.
The sign-up depends on a stage you designate
CompleteRegistration is disabled by default, and no pipeline stage is designated as the sign-up stage. For the broker sign-up to be sent to Meta, you therefore need to enable the rule on the pixel and choose, in the Tracking screen, the pipeline stage that means the lead has signed up.
The event is then sent when the lead enters that stage, or when a sign-up is matched by the CellXpert sync. It is sent only once per lead. A lead that leaves the stage and comes back does not generate a second CompleteRegistration.
The choice of stage has consequences. If your pipeline mixes "sign-up link sent" and "account opened", Meta will receive a sign-up at a point where the lead has not done anything yet. The designated stage must correspond to an actual sign-up with the broker, not an intention.
What is sent to Meta with each event
Email, phone, first name, last name and external ID are hashed with SHA-256 before sending. The fbc and fbp parameters, which come from the ad click and Meta's cookies, are sent unhashed, as Meta expects. The IP address and user agent from the click are also attached.
An event with no fbc, no fbp, no email and no phone is not sent. It is discarded with the reason no_identifier. Meta would not be able to link it to anyone in any case. In practice, a member who arrived without an identified click and never provided an email or phone number will produce no events, whatever stage they reach.
Match quality therefore depends on what you collect in the conversation. A lead from whom the closer obtained an email or phone number gives Meta more ways to recognise them than a lead known only by a Telegram username.
Where events go and retries on failure
Events are sent to the pixels of the lead's original campaign. If no campaign is linked, they go to the workspace's default pixels. A lead that is wrongly attached to its campaign will therefore send its events to the default pixel, which can distort your reading if several ad accounts are in use.
Failed sends are logged, then retried at 1, 5, 30, 120 and 720 minutes. After that, they are abandoned. An expired access token or a misconfigured pixel for more than half a day loses the events from that period. Checking the send log after any configuration change saves you from discovering the problem a week later in Ads Manager.
Check before changing the campaign objective
A test event code can be set per pixel. Events then appear in Meta's test events tool, which lets you check that a join, a lead or a deposit arrives with the right name, the right value and the right currency before switching a campaign to that objective.
Each event carries a unique event_id, which Meta uses for deduplication. If the same event reaches it twice, Meta can discard the duplicate instead of counting two conversions.
Remember to remove the test code once the check is done. As long as it is set, events from that pixel are treated as test events.
What Meta will not be able to attribute
The Conversions API passes on what happened. It does not recreate a click that was never recorded. When a user joins the channel through its public link, after seeing it shared elsewhere or copying it from an ad, there is no original click. Meta can receive the event if an email or phone number comes with it, but it cannot link it to an ad.
Meta's numbers and the CRM's numbers will therefore never fully match. Meta ignores conversions with no attributable click and keeps deposits rejected after they were sent. The CRM records both. When deciding whether to cut or keep a campaign, the confirmed deposits and commissions tracked in the CRM remain the reference; Meta's reports show what the algorithm is learning from, not what the campaign actually produced.