Server-Side Tracking

Server Side Tracking is a software architectural pattern where events are sent through a server to your marketing tools (e.g. Google Ads, Meta for Business, etc.) instead of directly from your frontend (i.e. website). There are two fundamental approaches: ➡️ Proxy Server-Side (e.g. Google Tag Manager Server, Meta Signals Gateway): acts as a customizable relay that requires hosting (e.g. GCP, AWS, Stape.io, etc…) and extensive configuration

• Stateless - no memory between requests
• Simply relays events from browser to destinations
• Cannot retry requests after failures or enrich user data natively

➡️ Full Server-Side (e.g. OneView): acts as a platform that handles data collection, compliance enforcement, deduplication, and advertising integrations out of the box

• Stateful - maintains memory and user context
• Stores user journeys, click IDs, and hashed user data
• Can retry failed events and enrich use data natively

---

​

Comparison

OneView offers a complete Server Side Tracking solution capable of both enforcing consent and storing Click IDs, providing the benefits of true server-side tracking.

​

Features

​

Apple® ITP Compliance

Intelligent Tracking Prevention (ITP) is WebKit (Safari) technology that:

• blocks all third-party cookies
• restricts first-party cookies to a 7-day lifetime, unless they are set by the webserver

This means that tracking data for Safari users gets reset every 7 days, breaking attribution for longer customer journeys. Hosting your tracking server on a subdomain (e.g. data.example.com) is not enough to comply with Apple® ITP. This technique is called CNAME Cloaking and is explicitly targeted by ITP. OneView achieves full ITP compliance when using a reverse proxy or traffic mirroring setup. With these configurations, you have full control over the OneView master cookie, ensuring client_id persistence beyond the 7-day ITP limit.

How do I implement traffic mirroring with OneView?

Check out the implementation guides.

---

​

Apple® LTP Compliance

Link Tracking Protection (LTP) is a WebKit (Safari) technology that automatically detects and removes link decorators from URLs, including:

• gclid (Google Ads)
• fbclid (Meta/Facebook)
• msclkid (Microsoft Ads)
• ttclid (TikTok)

This breaks every traditional form of pixel-based tracking (either client or proxy server-side), because it removes the key identifier required by those pixels / server tags. OneView achieves full LTP compliance by providing UTM-based attribution fallback, and Enhanced Conversions for all supported integrations

How does OneView achieve LTP compliance?

OneView solves LTP compliance through two complementary methods that work even when the browser or a plugin strips all tracking parameters:

1

UTM-First Attribution

OneView uses a UTM-first attribution model that remains fully functional across Safari, Brave, Firefox, and all high-privacy scenarios. Instead of relying on platform-specific click IDs, OneView attributes conversions using UTM parameters that are LTP-compliant.

Configure custom UTM fallback values for each integration in OneView

You can customize the utm_source fallback value for each Media Partner, ensuring accurate attribution even when click IDs are removed.

2

Enhanced Conversions Recovery

When consent is granted and the Media Partner supports it, OneView automatically sends Enhanced Conversions via each platform’s Conversion API. This allows ad networks to recover attribution data using:

• First-party customer data (hashed emails, phone numbers)
• Browser and device information
• Conversion event details and timing

This dual approach ensures maximum attribution coverage across all privacy scenarios.

See which platforms support this dual attribution approach in our integrations overview.

---

​

Apple® AFP Compliance

Advanced Fingerprinting Protection (AFP) is a WebKit (Safari) technology that standardizes device information to reduce the uniqueness of browser fingerprinting. This prevents the generation of unique user identities based on device configurations such as screen resolution, fonts, and GPU specifications, making it harder to track users across sessions without cookies. OneView does not rely on browser fingerprinting for user identification, making AFP compliance a non-issue. Instead, OneView uses:

• a single master cookie on the frontend, to store the anonymous client_id
• identity resolution using your Identity graph, built on consenting users

Which both operate independently of browser fingerprinting techniques.

---

​

Ad-Blockers and VPNs

Ad-blockers and VPNs actively block tracking by:

• Filtering requests to known analytics and advertising domains
• Blocking JavaScript files with tracking capabilities

This creates a constant “cat-and-mouse game” where tracking implementations continuously try to circumvent blocking mechanisms. The result? Unreliable data collection, poor user experience, and potential compliance issues. OneView fixes this issue at its root. We guarantee complete data coverage for customers using traffic mirroring. This approach generates page_view events at the server level - basically treating OneView as a log sink. This creates a complete picture of user interactions that’s invisible to any browser-based mechanism.

How do I implement traffic mirroring with OneView?

Check out our traffic mirroring implementation guide to configure your reverse proxy for complete data coverage.

---

​

Retries & Network Errors

Network interruptions cause permanent data loss in traditional tracking because:

• Server timeouts result in failed requests
• Temporary connectivity issues drop events
• Endpoint unavailability loses conversion data
• No retry mechanism exists for failed transmissions

Proxy solutions can’t match this - they’re stateless by design. The browser itself cannot guarantee it will always retry a failed event: you get irrevocably inconsistent data across your marketing platforms. This is the leading cause of your dashboards reporting different numbers for the same event. OneView operates a high-throughput global queue system that automatically retries failed requests. Once an event is accepted, you’re guaranteed that it will eventually reach its destination, even if downstream services experience extended outages (up to 7 days).

---

​

Duplicated Events

Event duplication occurs when:

• Page refreshes trigger multiple tracking calls
• Back-button navigation re-fires events
• Multiple tracking implementations overlap
• Single-page applications double-track route changes

OneView provides built-in deduplication using the Idempotency-Key field. When you send the same event with the same idempotency key, OneView automatically prevents duplicates from being processed, ensuring clean data across all downstream integrations.

How do I implement idempotency keys with OneView?

Include an Idempotency-Key with each event request using a unique identifier like user_id + event_type + transaction_id to prevent duplicate processing.

---

​

Privacy Compliance I (GDPR, CCPA)

While having flexible PII handling options seems convenient, it creates unnecessary risks since sensitive data can be accidentally transmitted or stored in plaintext. OneView takes a zero-tolerance approach to privacy. We enforce automatic PII hashing that cannot be disabled - eliminating human error and ensuring consistent compliance across all data processing. This is especially critical with ad_user_data and ad_personalization consent requirements. With OneView, you simply need to:

• Send the correct consent status for each conversion event
• Include PII data, which can be either:
  • Pre-hashed by you (if you prefer to hash before sending)
  • Sent in plaintext (OneView hashes it instantly at the edge, before data reaches your home region)

All personally identifiable information - including emails, phone numbers, names, and addresses - is automatically hashed using SHA-256 before any processing or storage occurs.

What PII does OneView automatically hash?

OneView does not inspect custom fields for PIIs. Please check the implementation guides.

OneView automatically detects and hashes emails, phone numbers, names, addresses, IP addresses, and any other field containing personally identifiable information before processing or storage.

---

​

Privacy Compliance II (ePrivacy)

Traditional implementations require complex consent management systems to handle multiple cookies from different vendors and services. OneView simplifies privacy compliance by using only one master cookie instead of multiple tracking cookies. This dramatically reduces consent management complexity, as you only need to handle consent for a single cookie rather than managing consent for dozens of different tracking pixels and their associated cookies.

---

​

Website Performance

Performance impacts from multiple tracking scripts include:

• Increased HTTP requests and bandwidth usage
• JavaScript Total Blocking Time, on the main thread
• Reduced Core Web Vitals scores
• Slower Time to Interactive and First Contentful Paint

Even deferred, scripts consume processing resources and impact user experience, leading to higher bounce rates, especially on mobile. OneView delivers excellent website performance by requiring only one script on the frontend (or none at all with implementations such as traffic mirroring). All heavy processing and integration work happens on OneView’s servers, dramatically improving your Lighthouse score.

How much can OneView improve my website performance?

Typical improvements:

• 20-40 point increase in Lighthouse performance scores
• 50-70% reduction in Total Blocking Time
• Significant improvements in Core Web Vitals metrics

Your actual improvement depends on:

• Number of tracking scripts you can remove
• Current resource usage of those scripts
• Your existing website optimization level

Most customers with 5+ tracking pixels see dramatic performance gains within days of switching to OneView.