| name | cookieless-alternatives |
| description | Evaluating and implementing cookie-less tracking alternatives for a post-cookie era. Covers the Privacy Sandbox APIs (Topics, Attribution Reporting, Protected Audiences), server-side analytics, and privacy-preserving measurement techniques. |
| license | Apache-2.0 |
| metadata | {"author":"mukul975","version":"1.0","domain":"privacy","subdomain":"cookie-consent-compliance","tags":"cookieless, privacy-sandbox, topics-api, attribution-reporting, protected-audiences"} |
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:
- Chrome observes the user's browsing activity (top-level page visits) locally on-device
- Each week, the browser classifies visited sites into topics from a taxonomy of approximately 470 advertising-relevant categories
- 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)
- Topics are selected with 5% random noise (a random topic is returned instead of the true one)
- 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:
if ('browsingTopics' in document) {
const response = await fetch('https://ads.pinnacle-ecommerce.com/topics', {
browsingTopics: true
});
const topics = await response.json();
}
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:
- Advertiser adds users to interest groups via JavaScript on their site
- Interest group data (ad creative URLs, bidding logic) stored locally in the browser
- When a publisher's ad slot runs an auction, the browser executes on-device bidding
- Winning ad is rendered in a fenced frame (isolated from the publisher page)
- 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
}, 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:
class FrequencyCapOperation {
async run(data) {
const count = await this.sharedStorage.get('pinnacle-widget-pro-views') || 0;
if (count >= 3) {
return 1;
}
await this.sharedStorage.set('pinnacle-widget-pro-views', count + 1);
return 0;
}
}
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
<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