BloqLabs - Ad Tracking Test Page

The Future of Digital Advertising

The digital advertising landscape is undergoing a fundamental transformation. With the deprecation of third-party cookies and increasing privacy regulations, advertisers are rethinking how they measure campaign effectiveness and track user engagement across the web.

HTML5 ads have become the standard for display advertising on the Google Display Network (GDN). Unlike traditional image banners, HTML5 creatives offer rich interactivity, animation, and dynamic content capabilities that drive significantly higher engagement rates.

However, tracking the performance of these ads across third-party inventory presents unique challenges. Since the ads are rendered on domains outside of the advertiser's control, traditional analytics implementations that rely on first-party cookies or domain-bound data streams simply cannot be used.

The Measurement Protocol Approach

Google Analytics 4 introduced the Measurement Protocol, a server-side API that allows developers to send events directly to GA4 without relying on client-side JavaScript tags. This opens up new possibilities for tracking in environments where traditional web analytics cannot reach.

By routing tracking events through a lightweight backend proxy, advertisers can maintain complete control over their measurement data while keeping sensitive API credentials secure on the server side. The ads themselves only need to know the endpoint URL, nothing about the GA4 configuration.

The key principle is simple: the ad fires events to your server, and your server forwards them to GA4. The ad never communicates directly with Google Analytics.

This architecture provides several important benefits. First, the GA4 API secret is never exposed in client-side code. Second, the backend can validate and sanitize incoming data before forwarding it. Third, the system works independently of the host domain, making it suitable for ads served across thousands of different websites.

Understanding Viewability Standards

The Media Rating Council (MRC) and the Interactive Advertising Bureau (IAB) have established clear standards for what constitutes a viewable ad impression. These standards are critical for ensuring that advertisers only pay for ads that were actually seen by users.

IAB Viewability Requirements

• Display ads: At least 50% of the ad's pixels must be in the viewable area of the browser window
• Time threshold: The ad must remain visible for a continuous period of at least 1 second
• Large format ads: For ads larger than 242,500 pixels (e.g., 970x250), only 30% needs to be viewable
• Video ads: At least 50% visible with the video playing for at least 2 continuous seconds

Implementing viewability tracking in HTML5 ads requires the use of the Intersection Observer API, which provides an efficient way to monitor when an element enters or exits the viewport. This is far more performant than older approaches that relied on scroll event listeners and manual position calculations.

When an ad creative is loaded inside an iframe on a third-party website, the Intersection Observer can still detect visibility changes relative to the viewport. The observer fires a callback whenever the intersection ratio crosses a defined threshold, such as 0.5 for the 50% visibility requirement.

The implementation starts a timer when the ad reaches 50% visibility. If the ad remains visible for a full second, the impression event fires. If the user scrolls away before the second is up, the timer resets. This ensures that only genuinely viewable impressions are counted.

Privacy-First Ad Tracking

Modern ad tracking must respect user privacy while still providing meaningful measurement data. The approach used in this system is designed from the ground up with privacy in mind.

What We Do NOT Track

• No cross-domain session stitching
• No user-level attribution across domains
• No GA cookies or fingerprinting
• No personal information collection
• No browsing history tracking

What We DO Track

• Anonymous impression counts per ad creative
• Click-through events
• Campaign and creative identifiers
• Viewability status
• Page location where the ad was displayed

The client_id used in tracking is a random UUID stored in localStorage. It provides basic deduplication capabilities but cannot identify individual users across different websites or browsing sessions. If localStorage is unavailable due to privacy settings, a new random ID is generated for each page load.

This approach aligns with modern privacy regulations including GDPR and CCPA, as no personally identifiable information is collected or transmitted. The tracking data is purely aggregate and campaign-focused.

Scaling Across Campaigns

One of the greatest strengths of the Measurement Protocol approach is its scalability. The same backend infrastructure serves all campaigns, all creatives, and all ad sizes. The only thing that changes between different ads is the tracking configuration embedded in the creative itself.

Each ad creative carries its own metadata: the ad ID, campaign name, creative variant, and size. These parameters are sent along with every tracking event, allowing for granular analysis in GA4. Custom dimensions can be configured to enable breakdown reporting by any combination of these parameters.

Campaign Management Best Practices

1. Use consistent naming conventions across campaigns (e.g., brand_season_year)
2. Include creative variant identifiers to support A/B testing
3. Tag ad sizes in the ad_id for quick size-based analysis
4. Use the placement parameter to track which website categories perform best
5. Monitor viewability rates across different placements to optimize media buying

The backend server is stateless and lightweight, meaning it can handle thousands of concurrent tracking requests without any database or session management overhead. Each request is validated, transformed, and forwarded to GA4 in a single pass.

For high-traffic campaigns, the server can be horizontally scaled behind a load balancer. Rate limiting protects against abuse while ensuring legitimate tracking events are never dropped. IP anonymization can be applied at the server level for additional privacy compliance.

Technical Implementation Details

The backend is built with Express.js and consists of a single POST endpoint. Incoming requests are validated against a strict schema: the client_id, event_name, and ad_id fields are required, while campaign, creative, placement, and other parameters are optional.

Event names are whitelisted to prevent abuse. Only recognized event types (ead_impression and ead_click) are accepted. Any other event name is rejected with a 400 error, ensuring that the GA4 property only contains clean, expected data.

The GA4 Measurement Protocol payload is constructed server-side. The measurement_id and api_secret are appended as query parameters to the GA4 endpoint URL, while the event data is sent in the request body. This ensures that the API secret never appears in any client-side code or network request visible to the browser.

Error Handling

The system is designed to fail gracefully at every level. If the backend is unreachable, the ad continues to function normally without any visible error to the user. If GA4 rejects a payload, the backend logs the error for debugging but still returns a success response to the ad to avoid unnecessary retries.

The sendBeacon API is preferred for sending tracking data because it is guaranteed to deliver the request even if the user navigates away from the page. The fetch API serves as a fallback for older browsers that do not support sendBeacon.

Analytics and Reporting

Once events flow into GA4, they can be analyzed using the standard GA4 reporting interface. Custom dimensions must be registered for the ad-specific parameters (ad_id, campaign, creative, placement) to enable proper breakdown reporting.

The GA4 Realtime report provides immediate feedback during campaign launches, allowing teams to verify that tracking is working correctly before scaling up media spend. The DebugView feature is invaluable during initial setup and troubleshooting.

For advanced analysis, GA4 data can be exported to BigQuery, enabling SQL-based queries across the full event dataset. This is particularly useful for calculating custom viewability metrics, cross-campaign performance comparisons, and long-term trend analysis that goes beyond what the GA4 interface can provide.

Typical questions that can be answered with this data include: Which creative sizes have the highest viewability rates? Which campaign generates the most clicks per impression? How does performance vary across different publisher categories? What time of day sees the highest engagement?

Future Considerations

As the digital advertising ecosystem continues to evolve, this tracking architecture is well-positioned to adapt. The Measurement Protocol is a stable, well-documented API that Google actively maintains as part of the GA4 platform.

Potential future enhancements include integration with Google Ads conversion tracking, support for video ad formats, expanded viewability metrics (such as time-in-view distribution), and automated alerting for tracking anomalies.

The modular architecture makes it straightforward to add new event types, additional parameters, or alternative analytics destinations without modifying the ad creatives themselves. The tracking.js file serves as the single point of configuration for all measurement logic.