Most broken attribution we look at is not broken in an interesting way. The pixel is right, the events are right, and the server-side token was never added, so half the funnel was thrown away by an ad blocker and nobody noticed because the numbers were plausible.
Here is the order to do it in, and what to check at each step.
One: connect the pixel at account level
Pixels are created on the Integrations page and nowhere else. That is the rule the whole configuration model rests on, described in the Integrations page: connections are written in one place, and every other screen selects from what already exists.
You add the pixel identifier and give the connection a name you will recognise in a dropdown six months from now. Name it after the offer or the client rather than after the platform. "Pixel 2" is how workspaces end up with four pixels and an unanswerable question about which one the good campaign was using.
You can connect several. Agencies run one per client, solo operators tend to run one per offer, and the architecture does not care either way.
Two: add the server token, which is the step people skip
A pixel identifier alone gets you browser events. Browser events are shredded by ad blockers and by privacy features on the phones a large share of your audience is holding, and there is no error message when one is lost. The fix is the platform's server-side channel, the Conversions API on Meta and the Events API on TikTok, which needs an access token alongside the pixel.
Add it. Everything that follows in Scalegram assumes both halves exist, because events fire from the browser where a page is involved and from the server where none is, which is the only way a join inside Telegram or a deposit confirmed hours later can reach the platform at all.
Tokens are masked once saved and can be replaced but not read back. The reasoning behind that, and the rest of the secret handling, is the same everywhere in the product.
Three: fire a test event and read what came back
Saving a token proves you typed something. It does not prove the platform accepted it. Use the test fire on the connection and read the platform's own response, not a green tick generated by our software.
Both platforms also accept a test event code, which routes test traffic into their testing view rather than into your live reporting. Use it while you are setting up, and remove it afterwards. A test code left in place is a genuinely nasty bug, because events keep firing and keep being visible to you in the testing tool while your actual campaigns receive nothing.
Every event Scalegram sends is logged with its name, value, identifier and the platform's actual response. When a number in Ads Manager looks wrong, start there rather than in the ad account. Half the time the log shows an event the platform rejected with a reason attached.
Four: attach the pixel where the traffic is
With the connection in place, you assign it. A tracking link picks the pixel it reports to. A bridge landing page on your own domain picks its own. A bot flow reports against the connection you selected for it. Nothing at this stage asks you for an identifier again, which is the point of doing step one properly.
Assign per link rather than globally when you run more than one offer. It costs nothing, and it means a client leaving or an offer being retired does not require unpicking shared reporting.
Five: check that identity is surviving the trip
Match quality lives on the identifiers captured at the click, plus browser context and hashed contact data where you have it. Emails collected on a bridge page are hashed before they are sent, so raw addresses never reach an advertising platform.
The check is straightforward. Run one real click through the link, join, and confirm the join event appears with attribution attached rather than as an anonymous event. If it arrives with nothing to match on, identity was dropped at the redirect and every later event in that chain is already lost. The full event set and what each carries is in conversion events.
What to do when you change ad accounts
Moving to a new advertising account is the moment setups break, because the pixel identifier changes, the token changes, and both changes are made in a hurry. Do it as a replacement on the existing connection rather than as a new one. Every link and page already points at that connection by name, so the switch takes effect everywhere at once and you avoid the state where half your traffic reports to a pixel nobody is spending against any more.
The mistakes that show up most
Browser and server events sent without a shared event identifier, so every conversion is counted twice and the campaign looks twice as good as it is. That is the single most common implementation bug in this niche and it is covered in pixels done right.
A test event code left switched on after setup. A token that was revoked when somebody left the business, never replaced, and never noticed because failures are silent. A pixel connected but never assigned to the link the campaign actually uses. And raw deposit amounts fed into value-based bidding, which is not a setup error so much as a decision to optimise toward whoever exaggerates.
None of these announce themselves. The habit that catches all of them is the same: after any change to a pixel, a token or a link, run one click through the whole path yourself and read the log.
"Nobody discovers a missing server token by looking at Ads Manager. The numbers stay plausible, just smaller, and you spend a quarter blaming your creative."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Connect pixels once on the Integrations page, name them after the offer or client, and assign them per link and per page.
- The server-side token is not optional; browser-only events are lost silently to ad blockers and phone privacy features.
- Test fire and read the platform's own response, then remove the test event code before going live.
- Verify one real click end to end, since identity lost at the redirect makes every downstream event unmatched.
Frequently Asked Questions
Do I need both a pixel and an access token?
In practice yes. The pixel covers events where a page exists, the token covers everything that happens after the browser is gone, which in a Telegram funnel is most of it.
Can I use one pixel across several offers?
You can, and the events stay separable because they carry the campaign identifiers and UTM parameters captured at the click. Separate pixels are still tidier when you may hand an offer or a client over later.
Where do I look when a conversion is missing?
The event log in your workspace, which records what was sent and what the platform replied. A rejection with a reason attached is far more useful than an empty column in Ads Manager.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.