Send a Meta campaign to a website and the platform watches the whole funnel. Send the same campaign to a Telegram channel and the report ends at the click, because the browser closed and everything that mattered happened somewhere the pixel cannot see. The join. The conversation. The deposit that actually pays you.
Scalegram fires four events across that gap, and the design question for each one is the same: what proof do we have, and what identity does it carry back to the ad platform.
Click
Every campaign points at a tracking link rather than a raw Telegram URL. The link captures the click identifiers the platforms use for matching, records the UTM parameters the campaign carried, fires the click event, and forwards the visitor onward. The mechanics of the link itself are in tracking links.
This event is the least interesting of the four and the most important, because it is where identity enters the system. Everything downstream is only as good as what was captured here. Lose the click identifiers at the redirect, as plenty of naive setups do, and every later event arrives at Meta technically valid and impossible to attach to anyone.
Join
The join is the event Telegram advertising has always been missing. A person clicked, arrived, and became a member of the channel, group or bot conversation. Because the destination is yours, that transition is observable from your side rather than inferred from a click count.
The join carries the identity captured at the click forward with it, so the platform receives a real funnel step rather than a raw follower number. For anyone optimising a cold-traffic campaign into Telegram, this is the first event with enough volume to actually train delivery.
Registration
Registration is the qualifying step: a lead identified themselves in a way you can act on. A form completed on a bridge landing page hosted on your own domain, described in bridge pages, or an account created and matched to a contact record. Personal data is hashed before it goes anywhere, so an email improves match quality at the platform without the address itself leaving in readable form.
The event sits in the funnel where a lead form would sit on a website campaign, which makes it the sensible optimisation target while purchase volume is still too thin to train on.
Purchase, with a value
The last event is the one the business runs on, and it is the one where honesty gets expensive. A purchase fires with a value attached, sourced from a completed sale synced from a connected checkout or from a deposit confirmed through a broker affiliate connection, as covered in purchase sync.
The distinction that matters is between a number somebody typed and a number a connected system confirmed. Value-based bidding optimises delivery toward the profile of your highest-value converters, so feeding it self-reported amounts trains the campaign on whoever exaggerates most. The options for handling that, from clamps to holding the event until a deposit is confirmed, are set out in verified conversions.
Two limits worth stating. Some broker affiliate APIs report that a deposit happened without reporting an amount, so a verified deposit is not always a verified figure. And several are range queries rather than live feeds, which is why the data is cached locally instead of asked for at the moment somebody needs an answer.
Why the order of the four matters
The events are not four independent reports. They are one chain, and each link inherits identity from the one before it. A purchase that arrives with campaign identifiers attached does so because the join carried them out of the browser and into Telegram, and the join could only do that because the click captured them in the first place.
This is why a funnel that fires only the last event performs worse than operators expect. The platform receives a conversion it cannot place, and the campaign is optimised on whatever else it can find. Firing the full chain gives the delivery system enough intermediate volume to learn from while purchases are still rare, which matters most in the first weeks of a campaign when purchase counts are in single figures.
What every event carries
All four events travel with the same payload discipline. The click identifiers captured at first touch. The UTM parameters from the original campaign, carried through the redirect and through Telegram rather than dropped at the first hop. A value where one exists and is trustworthy. And an event identifier that lets the platform recognise a duplicate.
Deduplication is the part that breaks most implementations. Events are sent from the browser where a page exists and from the server where it does not, and unless both carry the same identifier the platform counts one conversion twice. A synced purchase has the same exposure: a sale that resyncs must be claimed once, or a routine background job inflates your reported revenue by simply running again. Scalegram claims each purchase once, however often the sync repeats.
The number this exists to produce
Chain the four together and you get something a media buyer can act on: cost per join, cost per registration and cost per paying customer, per link and per creative. Not cost per click, which tells you about your thumbnail rather than about your business.
The wider argument for the whole loop is in Telegram ads attribution, and the connection side, including where pixels and their server tokens are configured, is in connecting Meta and TikTok pixels.
"Anybody can fire a purchase event from a form. The work is making sure the value came from a system that confirmed it and that the same sale never counts twice."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- Scalegram fires four events across the Telegram gap: click, join, registration and purchase with a value.
- Identity enters at the click, so the click identifiers and UTM parameters captured there determine whether every later event can be matched.
- Purchase values come from a synced checkout or a confirmed broker deposit rather than from a number a lead typed.
- A shared event identifier and a once-only purchase claim keep browser fires, server fires and resyncs from counting the same conversion twice.
Frequently Asked Questions
Do UTM parameters survive the trip through Telegram?
Yes. They are captured at the tracking link and carried forward with the events that follow, so a purchase reported days later still names the campaign that produced it.
What if a broker reports a deposit with no amount?
Then you have a verified depositor without a verified figure. That is a real limit of some affiliate APIs, and it is an argument for fixed-value handling rather than for inventing a number.
Can the same purchase be reported twice?
No. A purchase is claimed once and later sync attempts are recognised and dropped, which is what keeps the conversion count in your ad reports usable.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.