Put utm_source, utm_medium and utm_campaign on an ad's destination URL, point that URL at a t.me address, and check what arrives. The channel opens and the parameters are gone. Telegram does not forward a query string into the app, there is no page to read it on, and no cookie is set on any domain you own. The tagging convention that works everywhere else in marketing stops at the door.
That is the whole problem, and the fix is not clever. It is a hop. The click has to land somewhere you control for long enough to record what it was carrying.
The link is where the values get caught
A Scalegram tracking link sits between the ad and Telegram. When someone opens it, the parameters on the URL are read and stored against that click, together with the timestamp, country, device and referrer, and the Meta or TikTok click identifiers that make a server-side event matchable later. Then the visitor goes on to the channel, group or bot, usually without noticing anything happened.
From that moment the UTM values are not on a URL any more. They are a record. Nothing downstream depends on Telegram passing them along, because Telegram never will.
Carrying the values into Telegram itself
Storing the click is half the job. The other half is tying it to the person who arrives, and there are three ways to do it, in descending order of certainty.
- Send the traffic to a bot. The click identifier travels in the bot's start parameter, so the first message the bot receives already carries the click it came from. This is the only method that resolves to an individual rather than to a group of people. Point serious paid campaigns at a bot.
- Use a per-campaign invite link for a channel or group. Joins resolve to the campaign, not to the person, which is enough for comparing creatives and not enough for attributing a single deposit.
- Fall back to the first-party cookie. The click identifier is stored on the link domain, and a bridge page on that same domain reads it back later when the lead returns to verify a deposit. Same browser, same domain, chain reconnected.
What the contact record ends up holding
When the arriving person is matched to a click, the campaign values are written onto their contact record and stay there. Weeks later, when that person buys or funds an account, their record still says which source, medium and campaign produced them. This matters more than it sounds, because the gap between a Telegram click and a Telegram purchase is often measured in weeks of conversation, and no ad platform attribution window is patient enough to wait that long on its own.
The practical result is that your client list can be filtered by campaign. Not "Telegram traffic" as one undifferentiated pile, but the leads from one angle, one creative set, one media buyer. That is a reporting question a spreadsheet can answer once the values are on the rows.
Only the campaign values, the click context and the contact record are stored. The text of the conversation that follows is not saved at all, which is a deliberate limit in Scalegram and not an oversight. Attribution and message archiving are different products, and only one of them is worth the risk.
The values ride along on the events too
Every conversion Scalegram fires carries the attribution it was born with. A join, a bridge page submission, a synced purchase with its value: each one goes out with the stored click identifiers attached, from the server as well as the browser, sharing one event identifier so the platform counts it once. The pixel mechanics are covered separately, but the point for tagging is simple: a campaign value captured at the link is still attached to the purchase event fired a month later, because both are reading the same stored record.
Naming conventions, and the boring discipline that saves you
Two habits pay for themselves. Keep everything lowercase, because utm_source=Meta and utm_source=meta will sit in your reports as two different sources and nobody notices for a fortnight. And put the thing that varies most into utm_content rather than into the campaign name, so you can group creatives without rewriting the campaign layer every time you test a hook.
Use a separate slug per angle as well. Media buyers running several angles at once tend to want one link and one subdomain per angle, so that a rejected destination takes down one campaign rather than the account.
Where the values show up day to day
Three places, and they answer different questions. The contact record answers "where did this person come from", which is the one you want open when a lead you have been talking to for a month suddenly buys. The client list filtered by campaign answers "what did this angle actually bring in", counted in people rather than in clicks. And the per-link statistics answer "what did this cost", reading as a funnel from clicks through to verified deposits and total value once you enter the spend.
The list view is the one most operators underuse. Filter to a campaign, sort by stage, and the shape of the traffic is obvious in a few seconds. A campaign with two hundred contacts all sitting in the first stage is not a good campaign with a follow-up problem. It is a targeting problem wearing a follow-up problem's clothes, and the tags on the rows will usually tell you which objection is doing the damage. That is a conversation you can only have because the campaign value is written on the row.
Teams see this through their own permissions. Access is granted per area, with read, add, write and delete controlled separately, so a media buyer can be given the reporting without being given the ability to delete contacts. For an agency running several clients from one workspace that separation is the difference between a shared tool and an accident waiting to happen.
What this does not fix
UTMs describe where a click came from. They do not tell you whether the person on the other end was worth having. A campaign can produce a wall of cheap joins with beautiful tags and no depositors. The tagging layer only becomes useful once there is a real conversion at the end of it, which is why the value side of the loop, covered in verified conversions, matters more than the naming side.
Trading is high risk, and no funnel design changes that. Attribution tells you which advertising works. It says nothing about whether any given client will make money, and no one running this stack should pretend otherwise.
"A UTM that only exists in Ads Manager is a label. A UTM sitting on the contact record six weeks later, next to a deposit, is an answer."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- Telegram drops query strings, so UTM values have to be captured on a link you control before the redirect.
- A bot destination is the only method that ties a campaign to an individual person rather than to a group of joins.
- Campaign values are written onto the contact record and stay attached to purchase events fired weeks later.
- Keep tags lowercase and put the fast-changing variable in utm_content, or your reports will split into duplicates.
Frequently Asked Questions
Do UTM parameters work with a plain t.me link?
No. Telegram does not carry a query string into the app and there is no page on your domain to read it, so the values are lost at the click. They have to be captured by a tracking link first.
Where do the captured UTMs end up?
On the click record, then on the contact record once the arriving person is matched, and attached to every conversion event fired for that person afterwards.
Does Scalegram store the conversation to work out attribution?
No. Scalegram stores no message content at all. Attribution is built from the click record, the contact record and the events, never from reading chats.
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.