Conversions API vs pixel: what each sees in a Telegram funnel

Conversions API vs pixel comes down to where the event happens. The Meta Pixel reports what a visitor does on a web page, and the Conversions API reports what your own server knows. For a Telegram funnel, the join and the deposit both happen where a page script cannot follow, so they go through the Conversions API, and the pixel stays on the landing page for what it can see. Scalegram is the Telegram CRM for IBs and forex affiliates, and it reports joins and broker-verified deposits to Meta server side with the click id from the ad attached.

The tracking basics for Meta are in the Meta ads Telegram tracking article. This one is the narrower question of which channel does what and how to run both without counting a conversion twice. If you are still choosing a tool, the Telegram tracker comparison comes first.

What the pixel does and where it stops

Meta describes the Pixel in its Pixel documentation as "a snippet of JavaScript code that allows you to track visitor activity on your website." It works by "loading a small library of functions which you can use whenever a site visitor takes an action."

That is a browser tool. It sees a page view, a button tap, a form submit, as long as the page loads and the script runs. A Telegram join is none of those. The visitor taps your invite link, the Telegram app opens, and the join happens inside it. No page of yours is on screen and no script of yours is running. The same goes for a deposit a lead makes at a broker a few days later.

What the Conversions API does

Meta's Conversions API overview says it is "designed to create a connection between an advertiser's marketing data...from an advertiser's server, website platform, mobile app, or CRM to Meta systems that optimize ad targeting, decrease cost per result and measure outcomes." The page adds that server events "are processed like events sent using the Meta Pixel."

So the difference is the sender. A pixel event is sent by the visitor's browser. A Conversions API event is sent by a system you run, and that system can be anything that knows the event happened: a bot that watched a join, a CRM that recorded a deposit.

Meta recommends both together

This is not a choice of one or the other. In its best practices page, Meta says to "use the Conversions API in addition to the Meta Pixel, and share the same events using both tools." It also says that "sharing events when they happen can help your campaigns achieve the best results."

For a Telegram sales funnel that gives a split of labor. The pixel on your Website records the page view and the tap on the Telegram button. The server reports the join, the email or account number the lead gave, and the deposit. The events that only the server can know are the ones the campaign was missing.

How the two channels avoid double counting

When the same conversion arrives from the browser and from the server, Meta needs a way to see it is one event. The deduplication page says: "We determine if events are identical based on their ID and name." The Pixel's eventID has to match the Conversions API's event_id, and the Pixel's event has to match the event_name.

There is a time limit. Per the same page, "events are only deduplicated if they are received within 48 hours of when we receive the first event with a given event_id." Meta also says that when you use both channels, "they must set up a deduplication method to ensure that the ad delivery system is able to differentiate between distinct and overlapping events."

The server event parameters page describes event_id as "any unique string chosen by the advertiser." That has a practical consequence for Telegram. A join has no browser twin, so there is nothing to deduplicate against. Deduplication matters for the events both sides can see, such as a registration on a Website that also reports it from the server.

The click id makes a server event usable

A server event on its own is a stranger to Meta. It needs something that ties it to the ad click. Meta's fbp and fbc page defines the click id as "a Meta-generated parameter that is passed with the URL of an advertiser's website when a user clicks an ad", carried in the fbclid query parameter. It gives the fbc format as version.subdomainIndex.creationTime followed by the fbclid, and says servers should "always send _fbc and _fbp browser cookie values" in the event parameters.

The rule for a Telegram funnel follows from that. Catch the fbclid at the click, keep it against the visitor, and attach it to every later event. Scalegram's tracked links and its Pixel read fbclid, gclid, ttclid and sccid and keep them with the UTM tags, which the UTM tagging guide walks through.

Telling Meta where the conversion happened

Every server event states where it took place. The server event page defines action_source as the field that "allows you to specify where your conversions occurred", with values including website, app, phone_call, physical_store, system_generated, business_messaging and chat. It describes chat as a conversion "made via a messaging app, SMS, or online messaging feature."

The same page notes that event_time "can be up to 7 days before you send an event to Facebook." A deposit confirmed on Thursday should be sent with Thursday's time, and it should be sent that week. A pile of events exported at the end of the month falls outside that window.

Which action_source fits a Telegram join or a broker deposit is your decision when you set up the reporting. Meta's list gives you chat for a messaging app and other for anything it does not name. Pick one, use it on every campaign, and the numbers stay comparable.

What Scalegram sends and when

A dedicated bot watches who joins the channel, and each join is reported server side to Meta, TikTok and Snapchat. The bot asks the lead for an email or account number and looks it up over a read-only API in the broker's own records. Only when the record shows the deposit does the report go out, with the stored click id. The deposit verification article covers the lookup itself.

The effect is that Meta optimizes on depositors it was told about, not on people who tapped a button. Scalegram stores no messages to do this. It sends no signals, gives no trading advice and promises no results, and how a campaign performs is still down to the offer and the audience.

Which setup to pick

If your funnel ends on a web page, the pixel alone can be enough. If it ends in Telegram and the sale is confirmed at a broker, you need the server side, and you need the click id stored from the first tap. Running both, with a shared event_id where the browser and the server report the same thing, is what Meta's own documentation recommends.

Scalegram is the right fit for an IB, forex affiliate or prop firm affiliate who sells in Telegram and wants Meta told about verified deposits. It is the wrong fit if all you want is a page-view pixel. Plans are on the pricing section, and how it works shows the chain from ad to deposit.

Sources

• Meta Pixel, Meta for Developers, checked 24 September 2026
• Conversions API, Meta for Developers, checked 24 September 2026
• Conversions API best practices, Meta for Developers, checked 24 September 2026
• Handling duplicate events, Meta for Developers, checked 24 September 2026
• Server event parameters, Meta for Developers, checked 24 September 2026
• ClickID, fbp and fbc, Meta for Developers, checked 24 September 2026

The pixel reports what a page can see. Everything after the tap has to be reported by whoever saw it happen.

— The Scalegram Team

Frequently asked questions