Cookie-less Tracking Alternatives

Overview

The deprecation of third-party cookies by browsers and increasing consent-driven restrictions on first-party cookies are driving the advertising and analytics industries toward alternative measurement and targeting approaches. Google's Privacy Sandbox initiative, launched in 2019 and iteratively developed through 2024-2026, provides a suite of browser APIs designed to replace cross-site tracking functionality with privacy-preserving alternatives. Alongside browser-based solutions, server-side analytics and probabilistic measurement methods offer additional paths. This skill evaluates each alternative's privacy properties, technical requirements, and readiness for production use.

Privacy Sandbox APIs

Topics API

Purpose: Interest-based advertising without cross-site tracking.

How It Works:

1. Chrome observes the user's browsing activity (top-level page visits) locally on-device
2. Each week, the browser classifies visited sites into topics from a taxonomy of approximately 470 advertising-relevant categories
3. When an ad tech company calls the Topics API on a publisher's site, the browser returns up to 3 topics (one from each of the last 3 weeks)
4. Topics are selected with 5% random noise (a random topic is returned instead of the true one)
5. A caller only receives topics that it has also observed the user being interested in (on other sites where the caller was present)

Topics Taxonomy Examples:

Topic ID	Category	Level
1	Arts & Entertainment	1
57	Arts & Entertainment / Movies	2
86	Business & Industrial / E-Commerce	2
243	Shopping / Apparel	2
332	Sports / Team Sports / Football	3

Implementation for Pinnacle E-Commerce Ltd:

// Check if Topics API is available
if ('browsingTopics' in document) {
  // Observe: register this page visit for topic classification
  // The fetch call with {browsingTopics: true} both observes and retrieves
  const response = await fetch('https://ads.pinnacle-ecommerce.com/topics', {
    browsingTopics: true
  });
  const topics = await response.json();
  // topics = [{ topic: 86, version: "chrome.2:2:1", configVersion: "chrome.2", taxonomyVersion: "2", modelVersion: "1" }]
}

Privacy Properties:

• No cross-site identifier shared
• Topics are coarse-grained (470 categories, not granular interests)
• 5% noise prevents deterministic profiling
• Users can view and clear their topics in Chrome settings
• Sites can opt out via Permissions-Policy: browsing-topics=()

Limitations:

• Chrome-only (no Safari, Firefox support)
• Coarse targeting compared to cookie-based audiences
• Adoption depends on ad tech ecosystem support

Attribution Reporting API

Purpose: Measuring ad conversions without cross-site tracking.

Two Modes:

Mode	Report Type	Data	Noise	Delay
Event-level	Per-conversion	Source: 64-bit ID; Trigger: 3 bits (8 values) for clicks, 1 bit for views	Yes (noise applied to trigger data)	2 days (click), 1 day (view)
Aggregatable	Aggregate summary	Source + trigger combined into histogram buckets	Additive Laplace noise	10-60 minutes (batched)

Event-Level Attribution Flow:

1. User clicks ad on publisher.com
   → Browser stores: source_event_id=12345, destination=pinnacle-ecommerce.com

2. User converts on pinnacle-ecommerce.com
   → Browser matches: trigger_data=2 (e.g., "purchase")

3. After 2-day delay, browser sends report:
   {
     "source_event_id": "12345",
     "trigger_data": "2",
     "source_type": "navigation",
     "randomized_trigger_rate": 0.0024
   }
   → Sent to reporting origin (ads.pinnacle-ecommerce.com)

Aggregatable Attribution Flow:

1. Ad impression/click registered with source keys
2. Conversion triggers aggregation keys
3. Browser generates encrypted aggregatable report
4. Reports sent to aggregation service (Trusted Execution Environment)
5. Aggregation service applies differential privacy noise
6. Summary report returned: { "campaign_A_purchases": 1247 ± 23 }

Implementation for Pinnacle E-Commerce Ltd:

Source registration (on ad click):

<a href="https://www.pinnacle-ecommerce.com/product/widget-pro"
   attributionsrc="https://ads.pinnacle-ecommerce.com/register-source">
  Buy Widget Pro
</a>

Source registration response header:

Attribution-Reporting-Register-Source: {
  "destination": "https://www.pinnacle-ecommerce.com",
  "source_event_id": "12345678",
  "expiry": "604800",
  "aggregation_keys": {
    "campaignCounts": "0x159",
    "geoValue": "0x5"
  }
}

Trigger registration (on conversion):

<img src="https://ads.pinnacle-ecommerce.com/register-trigger" attributionsrc>

Trigger registration response header:

Attribution-Reporting-Register-Trigger: {
  "event_trigger_data": [
    { "trigger_data": "2", "priority": "100" }
  ],
  "aggregatable_trigger_data": [
    { "key_piece": "0x400", "source_keys": ["campaignCounts"] }
  ],
  "aggregatable_values": { "campaignCounts": 32768 }
}

Protected Audiences API (formerly FLEDGE)

Purpose: Remarketing and custom audience targeting without third-party cookies.

How It Works:

1. Advertiser adds users to interest groups via JavaScript on their site
2. Interest group data (ad creative URLs, bidding logic) stored locally in the browser
3. When a publisher's ad slot runs an auction, the browser executes on-device bidding
4. Winning ad is rendered in a fenced frame (isolated from the publisher page)
5. No cross-site data leaves the browser; auction happens locally

Interest Group Join (on pinnacle-ecommerce.com):

navigator.joinAdInterestGroup({
  name: "widget-pro-viewers",
  owner: "https://ads.pinnacle-ecommerce.com",
  biddingLogicUrl: "https://ads.pinnacle-ecommerce.com/bidding.js",
  ads: [
    {
      renderUrl: "https://ads.pinnacle-ecommerce.com/ads/widget-pro-retarget.html",
      metadata: { "product": "widget-pro", "discount": "10%" }
    }
  ],
  userBiddingSignals: { "viewed_product": "widget-pro", "visit_count": 3 },
  trustedBiddingSignalsUrl: "https://ads.pinnacle-ecommerce.com/signals",
  trustedBiddingSignalsKeys: ["widget-pro-bid"],
  dailyUpdateUrl: "https://ads.pinnacle-ecommerce.com/update-ig",
  lifetimeMs: 2592000000  // 30 days
}, 2592000000);

Privacy Properties:

• User profile data never leaves the device
• Auction runs in browser, not on ad server
• Fenced frames prevent information leakage to publisher
• K-anonymity requirements on ad creatives (must be shown to sufficient users)
• Users can view and leave interest groups in Chrome settings

Shared Storage API

Purpose: Cross-site data access with restricted output gates.

Allows writing data from multiple sites into a shared storage partition, but reading is restricted to privacy-preserving output gates:

• Select URL (choose from a predefined list)
• Private Aggregation (contribute to aggregate histograms)
• Fenced Frames (render content without leaking data)

Use Case for Pinnacle E-Commerce Ltd: Frequency capping across sites — count how many times a user has seen an ad without cross-site cookies:

// On publisher site, inside shared storage worklet
class FrequencyCapOperation {
  async run(data) {
    const count = await this.sharedStorage.get('pinnacle-widget-pro-views') || 0;
    if (count >= 3) {
      // User has seen this ad 3 times — show fallback
      return 1; // Index of fallback URL
    }
    await this.sharedStorage.set('pinnacle-widget-pro-views', count + 1);
    return 0; // Index of ad URL
  }
}

Server-Side Analytics Alternatives

Cookieless Server-Side Measurement

Solution	Cookies	PII Collection	Hosting	Consent Required
Server log analysis	None	IP address (anonymize)	Self-hosted	No (operational necessity)
Plausible Analytics	None	No PII	EU cloud or self-hosted	Varies by jurisdiction
Fathom Analytics	None	No PII	Canadian/EU hosting	Varies by jurisdiction
Umami	None (optional)	No PII	Self-hosted	Varies by jurisdiction
Matomo (cookieless mode)	None	Fingerprint hash (session only)	Self-hosted	Check with local DPA

Plausible Analytics Configuration for Pinnacle E-Commerce Ltd

<!-- Single script, no cookies, ~1KB -->
<script defer data-domain="pinnacle-ecommerce.com"
  src="https://plausible.io/js/script.js"></script>

What Plausible Collects (per pageview):

• Page URL (path only)
• Referrer (domain only)
• Browser (derived from User-Agent)
• Operating system
• Device type (desktop/mobile/tablet)
• Country (from IP, IP discarded immediately)

What Plausible Does NOT Collect:

• Cookies
• Persistent identifiers
• IP addresses (hashed for daily unique counting, hash rotated daily)
• Cross-session tracking
• Personal data

Comparison Matrix

Capability	Third-Party Cookies	Topics API	Attribution Reporting	Protected Audiences	Server-Side Analytics
Interest-based targeting	Full granularity	~470 topics	No	Retargeting only	No
Conversion measurement	Deterministic	No	Yes (with noise/delay)	Limited	Server-side only
Cross-site tracking	Yes	No	No	No	No
Works in Safari	No (blocked)	No	No	No	Yes
Works in Firefox	No (blocked)	No	No	No	Yes
Consent required	Yes	Evolving	Evolving	Evolving	Depends on config
Production-ready	Legacy	Yes (Chrome)	Yes (Chrome)	Yes (Chrome)	Yes

Key Legal and Technical References

• Google Privacy Sandbox Documentation — Topics API, Attribution Reporting, Protected Audiences specifications
• W3C Private Advertising Technology Community Group — Standards development for privacy-preserving advertising
• ePrivacy Directive 2002/58/EC, Article 5(3) — Legal basis for consent requirements; exemptions may apply to some alternatives
• GDPR Recital 47 — Legitimate interest considerations for analytics
• UK ICO Guidance on Analytics Cookies (2019, updated 2023) — Analytics cookies require consent under PECR
• CNIL Topics API Analysis (2023) — French DPA assessment of Privacy Sandbox proposals
• CMA (UK Competition and Markets Authority) Privacy Sandbox Commitments — Google's commitments regarding Privacy Sandbox development
• IAB Tech Lab Privacy Sandbox Task Force — Industry evaluation of Privacy Sandbox APIs