Scalegram lets you connect Meta and TikTok pixels to your tracking links and deposit verification pages in a paste-and-test screen. The screen is simple; what happens underneath follows four rules that decide whether your numbers mean anything.
Rule One: Fire Twice, From Browser and Server
Browser-only pixels are shredded by iOS privacy features and ad blockers; server-only events match poorly without browser context. The correct answer is both at once: the browser pixel fires where a page exists, and the Conversions API (Meta) or Events API (TikTok) fires from the server with the captured click identifiers. Scalegram does this for every event on every surface.
Rule Two: One Event, One Identifier
Firing twice means the platform receives the same conversion twice, unless both carry the same event identifier so it deduplicates them into one. Scalegram generates and shares that identifier automatically across the browser and server fire. This is the single most common implementation bug in the wild, and it is the first thing to check in any event log where numbers look too good.
Rule Three: Hash Everything Personal
Emails captured on bridge pages are hashed before they are sent anywhere; raw addresses never reach Meta or TikTok, and never sit in event logs. You get the match-quality benefit of an email identifier without shipping personal data to advertising platforms. It is both the compliant answer and the professional one.
Rule Four: Feed the Match, or Starve the Campaign
Match quality lives on identifiers: click identifiers captured at the link, formatted correctly, plus browser context and hashed contact data where consented. Scalegram captures these on first touch and attaches them to every event downstream. Lose them at the redirect, as naive setups do, and the platform receives technically valid events it cannot connect to any user, which quietly starves the campaign's optimisation.
Trust, but verify: the event log. Every event Scalegram sends is logged with its name, value, identifier and the platform's actual response, next to a test-fire button that reports what the platform said, not just "saved". When something looks off in Ads Manager, the answer is one page away, in your workspace.
What You Configure
Per workspace: multiple pixels, each with its identifier and API token (masked after saving, replace-only), assignable per link and per page, with optional test event codes. Agencies run one pixel per client; solo operators run one per offer. The architecture does not care, and the numbers stay clean either way. The wider strategy sits in closing the black hole.
"Nine out of ten broken funnels we audit have the same bug: browser and server events with no shared identifier, so every conversion counts twice. Dedup is not a detail. It is the difference between data and fiction."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Fire every event from browser and server together: iOS and ad blockers kill browser-only, poor matching kills server-only.
- Deduplicate with a shared event identifier, or every conversion counts twice and your data becomes fiction.
- Hash all personal identifiers: raw emails never reach ad platforms or logs.
- Preserve click identifiers from first touch through every event, or optimisation quietly starves.
Frequently Asked Questions
Why do my platform numbers and Scalegram numbers differ slightly?
Attribution windows, consent states, and platform modelling all cause small gaps. What matters is that events arrive, deduplicate correctly, and carry strong identifiers. The event log shows exactly what was sent and what each platform answered.
Can I test without polluting real campaign data?
Yes. Both platforms support test event codes, and Scalegram has a per-pixel field for them plus a test-fire button, so you can watch a test event arrive in the platform's testing view before going live.
Are my API tokens safe in Scalegram?
Tokens are treated as secrets: masked immediately on save, never viewable again, replaceable only. The event log stores summaries and responses, never credentials and never raw personal data.