How Tragly Works
A live explanation of the server-side tracking architecture and event flow.
The Problem with Client-Side Tracking
Traditional analytics rely on JavaScript running in the browser. This creates three compounding problems:
Ad Blockers
25–40% of traffic blocked. Events never reach GA4 or Meta.
ITP / Safari
Apple's Intelligent Tracking Prevention limits cookies to 7 days.
Page Speed
Multiple tracking scripts slow down the page and hurt Core Web Vitals.
The Tragly Solution — Event Flow
With Tragly, one lightweight pixel collects the event, and the Tragly server does the forwarding — out of the browser's reach.
Visitor's Browser
Clicks, scrolls, purchases
Tragly Server
First-party, EU-hosted
Destinations
GA4 · Meta · TikTok · Webhook
Sample event payload (what Tragly receives from the pixel):
What Happens on the Server
1. Receive & Validate
- ✓ Tracking ID validated
- ✓ Bot detection (user-agent, IP)
- ✓ Rate limiting (DDoS protection)
- ✓ Payload size limit (250 KB)
2. Enrich
- ✓ Geo-lookup (country, city) from IP
- ✓ User-agent parsing (device type)
- ✓ Session attribution (_tragly_cid)
- ✓ Timestamp normalization (UTC)
3. Store
- ✓ SQLite database (EU, Frankfurt)
- ✓ WAL mode for concurrent reads
- ✓ 90-day auto-deletion (configurable)
- ✓ Available in dashboard instantly
4. Forward
- ✓ Parallel dispatch to all enabled forwarders
- ✓ Automatic retry with exponential backoff
- ✓ Failed events logged to dead-letter queue
- ✓ Admin-visible in Dead Letters panel
Ready to see it live?
Tragly is in managed pilot. Request access and we'll onboard your agency personally — tracking live within a day.