The Post-Privacy Sandbox Reality: Why Google Retired PAAPI and Topics, and What Publishers Should Deploy Instead

Executing navigator.runAdAuction() inside a browser tab never scaled to the latency tolerances of modern programmatic exchanges. Across billions of

3D highway-junction illustration where a central data superhighway splits into two illuminated suspension bridges for partitioned crystals and golden first-party vaults while a decommissioned side ramp is sealed off.

Executing navigator.runAdAuction() inside a browser tab never scaled to the latency tolerances of modern programmatic exchanges. Across billions of production impressions tested between 2023 and 2025, spinning up isolated V8 worklet environments to execute buyer generateBid() and seller scoreAd() JavaScript functions on the client device consistently added 180ms to 450ms of execution overhead, starved the browser main thread on mid-tier Android hardware, and degraded core web vitals like Interaction toNext Paint (INP). When multiplied across multi-slot page layouts and video instream placements, on-device component auctions fractured auction timeout curves and depressed effective yield compared to server-to-server OpenRTB 2.6 auctions.

On October 17, 2025, following its decision to maintain user choice for third-party cookies in Chrome, Google officially retired Protected Audience API (PAAPI), Topics API, Attribution Reporting API, Shared Storage, Private Aggregation, and SDK Runtime, while continuing to support CHIPS and FedCM. That milestone ended a five-year engineering experiment that attempted to relocate real-time ad selection, remarketing cohort management, and conversion attribution from cloud-hosted ad exchanges into the local browser binary. For publisher engineering and AdOps teams, the retirement of these APIs removes significant client-side complexity, eliminates speculative wrapper modules, and refocuses the technical roadmap on proven server-side and hybrid addressability protocols.

Rather than building for a hypothetical browser-hosted auction model, sell-side monetization architectures in 2026 operate across a cleanly bifurcated ecosystem. Chrome traffic remains predominantly cookie-enabled with partitioned state enhancements, while Apple Safari (macOS and iOS WebKit), Mozilla Firefox, and native mobile/CTV environments require deterministic first-party identity and contextual curation. At Sky Boosts, our privacy-resilient monetization stack combines Google Ad Manager (GAM) MCM, Prebid.js 11.x, Prebid Server, and OpenRTB 2.6 curation to maximize bid density across both halves of this ecosystem without bloating the client browser.

Google's original January 2020 Privacy Sandbox proposal rested on a single foundational premise: third-party cookies (SameSite=None cross-site state) would be unconditionally deprecated across Chromium within two years, requiring browser-native APIs to replicate remarketing, behavioral interest targeting, and cross-site conversion measurement. Over the subsequent five years, that timeline slipped repeatedly as the UK Competition and Markets Authority (CMA), the IAB Tech Lab Task Force, tier-1 DSPs, and sell-side platforms audited the functional and economic gaps between OpenRTB server auctions and browser-mediated worklets.

Testing revealed structural deficits that incremental API patches could not resolve. In server-side programmatic auctions, an SSP evaluates thousands of concurrent bid requests within a 100ms to 200ms SLA, applying real-time QPS throttling, dynamic floor elasticity, multi-size creative validation, competitive brand-safety filtering, and video pod deduplication before returning a unified clearing price. Moving those mechanics into PAAPI required splitting the auction into a server-side contextual pass and a client-side interest-group pass. Because PAAPI worklets could not access real-time server state without relying on constrained Key-Value (KV) trusted servers running inside Trusted Execution Environments (TEEs), buyers faced severe feature parity gaps, including broken frequency capping across devices, inability to enforce real-time pacing budgets, and opaque debugging surfaces.

The pivot unfolded in three distinct stages between mid-2024 and late 2025:

  1. July 2024 (The User-Choice Shift): Google abandoned its plan to forcibly deprecate third-party cookies for all Chrome users, proposing instead an informed user-choice experience that would allow users to configure cross-site tracking preferences at the browser level.
  2. April 2025 (Retention of Current Chrome Controls): Following extensive industry consultation and regulatory feedback, Google confirmed it would not introduce a new standalone prompt for third-party cookies, preserving the existing Chrome privacy settings and effectively maintaining third-party cookie addressability across standard Chrome browsing sessions.
  3. October 17, 2025 (Formal API Retirement): With third-party cookies retained in Chrome and ecosystem adoption of the Privacy Sandbox ad-targeting APIs trailing near zero outside of subsidized CMA testing cohorts, Google formally retired the six core ad-targeting and measurement technologies across web and Android.

For publishers, this sequence validated a critical architectural principle: open-web standards succeed when they reinforce interoperable server-to-server protocols like OpenRTB 2.6, not when they lock auction execution inside a single browser vendor's runtime engine.

The Sunset of Protected Audience (PAAPI), Topics, Attribution Reporting, and Shared Storage in Chrome M152-M154

Following the October 2025 announcement, the Chromium engineering team initiated the formal Blink intent-to-deprecate and code-removal lifecycle across Chrome milestones M152 through M154. Understanding the exact failure modes of these retired APIs is essential for publisher engineering teams conducting tag audits and wrapper upgrades in 2026.

The retired suite encompasses six specific surfaces:

  • Protected Audience API (PAAPI, formerly FLEDGE): Exposed via navigator.joinAdInterestGroup(), navigator.leaveAdInterestGroup(), and navigator.runAdAuction(). In Chrome M152-M154, the underlying interest group SQLite storage tables and auction worklet threads are stripped from Chromium. Legacy buyer or SSP scripts that fail to perform strict feature detection (typeof navigator.runAdAuction === 'function') before invocation will throw TypeError exceptions on the page.
  • Topics API: Exposed via the JavaScript call document.browsingTopics() and the Sec-Browsing-Topics HTTP request header coupled with Observe-Browsing-Topics: ?1 response headers. Topics attempted to condense a user's weekly browsing history into five coarse taxonomy IDs (out of roughly 469 categories) with a 5% random noise injection rate. Media buyers consistently rejected Topics signals because the taxonomy lacked commercial granularity and the 5% deliberate noise rate corrupted high-CPM audience segments.
  • Attribution Reporting API (ARA): Designed to measure click-through and view-through conversions via Attribution-Reporting-Eligible headers and browser-generated event-level or aggregatable summary reports. With third-party cookies intact in Chrome and server-side conversion APIs (CAPI) dominating performance marketing, ARA's delayed, noise-injected reporting pipelines saw minimal production demand.
  • Shared Storage and Private Aggregation: Provided unpartitioned cross-site write access coupled with restricted read outputs via URL selection (sharedStorage.selectURL()) or noisy histogram reports (privateAggregation.contributeToHistogram()).
  • SDK Runtime (Android Privacy Sandbox): Designed to isolate mobile ad SDKs in a separate Android process (SdkSandboxManager) stripped of standard app permissions and persistent device identifiers. Mobile mediation stacks and the GMA Next-Gen SDK continue to rely on standard OS-level sandboxing, IDFA/GAID controls, and first-party app signals instead.

Publishers must immediately audit their Content Security Policy (CSP) and Permissions-Policy HTTP response headers. During 2023 and 2024, many AdOps teams appended sprawling permissions policies to delegate Sandbox access to dozens of SSP origins:

Permissions-Policy: browsing-topics=(), run-ad-auction=(), join-ad-interest-group=(), attribution-reporting=(), shared-storage=()

Removing these obsolete directives from CDN edge configurations (Cloudflare Workers, Fastly VCL, or AWS CloudFront Functions) reduces HTTP response header payload bytes on every document request and prevents browser console warnings in Chromium M152+.

Cleaning Up Dead Code: Why Prebid.js 11.0 Removed All PAAPI and Topics Modules

The most immediate operational benefit of the Privacy Sandbox retirement for web publishers arrived with the release of Prebid.js 11.0. Because client-side header bidding runs directly on the publisher's page, every kilobyte of JavaScript compiled into prebid.js impacts Time to First Ad Request and main-thread responsiveness.

To eliminate dead execution paths and streamline wrapper orchestration, Prebid.js 11.0 officially removed paapi, paapiForGpt, topLevelPaapi, and topics modules from the Prebid codebase following Chrome's retirement of those Privacy Sandbox APIs. In Prebid 8.x through 10.x, compiling these modules into a publisher build introduced substantial runtime overhead:

  1. topics Module Overhead: On initialization, the module invoked document.browsingTopics({ skipObservation: true }), awaited the asynchronous Promise resolution, mapped the returned taxonomy version and topic IDs into ortb2.user.data objects, and injected extra iframe trackers for participating bidders.
  2. paapi, paapiForGpt, and topLevelPaapi Overhead: These modules intercepted bid responses containing ext.igi (Interest Group Auction Intent) payloads, parsed igb (Interest Group Buyers) and igs (Interest Group Sellers) configurations, constructed complex auctionConfig objects, and either routed component auctions into Google Publisher Tag (GPT) slots or executed standalone top-level PAAPI auctions inside fenced frames (<fencedframe>).

When upgrading to Prebid.js 11.x, publishers must strip legacy paapi and topics blocks from pbjs.setConfig() calls. Leaving deprecated module references in build scripts (such as gulp bundle --modules=...) will cause build warnings or silent configuration drops. Below is a clean, production-grade Prebid.js 11.x initialization pattern that replaces retired Sandbox modules with high-value First-Party Data (ortb2), Seller-Defined Audiences (SDA), and deterministic User ID modules:

window.pbjs = window.pbjs || { que: [] };

pbjs.que.push(function () {
  pbjs.setConfig({
    debug: false,
    enableTIDs: true,
     bidderTimeout: 1200,
    userSync: {
      filterSettings: {
        iframe: {
          bidders: '*',
          filter: 'include'
        }
      },
      userIds: [
        {
          name: 'sharedId',
          storage: {
            type: 'cookie',
            name: '_pubcid',
            expires: 365
          }
        },
        {
          name: 'pairId',
          params: {
            liveramp: { storageKey: '_lr_pairId' }
          }
        }
      ],
      auctionDelay: 50
    },
    ortb2: {
      site: {
        domain: 'publisher-example.com',
        cat: ['IAB13-1', 'IAB13-4'],
        content: {
          data: [
            {
              name: 'publisher-example.com',
              ext: { segtax: 6 },
              segment: [{ id: '214' }, { id: '218' }]
            }
          ]
        }
      },
      user: {
        data: [
          {
            name: 'publisher-example.com',
            ext: { segtax: 4 },
            segment: [{ id: '42' }, { id: '188' }]
          }
        ]
      }
    }
  });
});

By removing the paapi and topics modules during the Prebid 11.x upgrade, engineering teams typically reduce compiled wrapper weight by 18 KB to 32 KB (minified/gzipped) and eliminate the asynchronous race conditions that previously delayed GPT display() and refresh() calls when component auctions stalled.

What Survived in Chrome: CHIPS (Partitioned Cookies) and FedCM

While Google retired the six ad-targeting and measurement APIs in October 2025, two critical Privacy Sandbox infrastructure primitives survived and remain fully supported in Chromium: CHIPS (Cookies Having Independent Partitioned State) and FedCM (Federated Credentials Management). Both technologies survived because they solve genuine browser security and state-management problems without attempting to replace server-side OpenRTB infrastructure.

CHIPS introduces the Partitioned attribute to the standard HTTP Set-Cookie header. When a third-party service (such as an SSP user-sync endpoint, a fraud-verification sensor from HUMAN or Pixalate, or an embedded video player) sets a cookie with the Partitioned directive, Chrome keys that cookie in a double-keyed storage jar bound to both the top-level site (top-frame site) and the embedded origin (frame site).

Set-Cookie: __Host-ssp_freq_cap=v1_884920_3; Secure; Path=/; SameSite=None; Partitioned; Max-Age=2592000

For programmatic monetization, CHIPS provides a durable, privacy-safe fallback for Chrome users who manually block unpartitioned third-party cookies in browser settings or browse under enterprise security policies. With Partitioned cookies, sell-side infrastructure and verification vendors can maintain accurate per-publisher frequency capping, session-depth tracking, ad-pod sequence deduplication, and bot-mitigation telemetry within a publisher's domain without tracking the user across unrelated websites. Note that Chromium enforces strict security rules on CHIPS: the Partitioned attribute requires Secure and SameSite=None, and utilizing the __Host- prefix ensures the cookie is bound strictly to the host with Path=/ and no Domain attribute.

FedCM (navigator.credentials.get({ identity: ... })) provides a browser-mediated flow for federated authentication and cross-domain single sign-on (SSO). Before FedCM, media conglomerates operating 10 to 50 distinct brand domains relied on hidden third-party cookie bounce redirects or iframe message passing to recognize when a subscriber logged into Brand A visited Brand B. Safari ITP, Firefox ETP, and strict Chrome profiles break those redirect chains via bounce-tracking mitigations.

By adopting FedCM alongside our publisher solutions, multi-domain media groups can authenticate users across their owned-and-operated properties through a native browser credential exchange. Once authenticated via FedCM, the publisher generates a persistent, deterministic first-party identifier that feeds directly into Google Ad Manager's PublisherProvidedId (PPID) API and Prebid's ortb2.user.ext.eids array, unlocking authenticated first-party addressability across the publisher's entire portfolio.

Monetizing the Bifurcated Web in 2026

The retirement of PAAPI and Topics brought clarity to what had been a deeply fragmented engineering roadmap. The open web did not transition into a single browser-controlled sandbox; instead, it crystallized into a structurally bifurcated environment requiring dual-track addressability routing. On one track sits Google Chrome across desktop and Android, representing roughly 65% to 70% of global web pageviews, where traditional third-party cookies (SameSite=None), Prebid user-sync iframes, and Google AdX cookie matching remain fully operational. On the second track sits the ID-less ecosystem, comprising Apple Safari (macOS and iOS WebKit with Intelligent Tracking Prevention), Mozilla Firefox (Enhanced Tracking Protection), privacy browsers, and non-opted-in iOS/tvOS app inventory, representing 30% to 35% of volume and an even higher share of high-HHI (Household Income) consumer spend.

Fork-in-the-road architecture diagram splitting publisher traffic between Chromium 3P Cookies plus CHIPS storage and Safari/iOS PPID plus Curated Audiences while barricading the retired PAAPI and Topics bridge.

Monetizing this bifurcated reality requires dynamic signal conditioning rather than a one-size-fits-all wrapper setup. If a publisher relies exclusively on legacy third-party cookie matching, Safari and iOS eCPMs collapse by 45% to 65% due to unmatched bid requests and aggressive DSP bid shading on unauthenticated impressions. Conversely, if a publisher strips out cookie syncing or throttles user-sync iframes in Chrome out of outdated Privacy Sandbox assumptions, they forfeit top-of-waterfall remarketing demand from tier-1 DSPs and Google AdX. Through Sky Boosts' hybrid mediation architecture across Web, Mobile App, and CTV, we dynamically route identity, contextual signals, and floor rules according to the exact capabilities of the client environment.

Architectural Dimension Chrome (Desktop & Android Web) Safari / Firefox / iOS WebKit & ID-Less Apps
Primary Identity Mechanism Unpartitioned 3P Cookies + CHIPS + Deterministic 1P IDs (eids) Deterministic 1P IDs (PPID, PAIR) + Curated First-Party Cohorts
Audience Signal Standard DSP Cookie Graphs + IAB Seller-Defined Audiences (SDA) IAB Seller-Defined Audiences (segtax: 4) + Content Taxonomy 3.0 (segtax: 6 / 7)
Google Ad Manager (GAM) Integration Standard AdX Cookie Match + PPID + Publisher Provided Signals (PPS) GAM PPID + PPS (Taxonomy Curation) + Secure Signals
Prebid 11.x User Sync Strategy Active iframe/pixel sync (auctionDelay: 50ms) + ortb2 enrichment Suppress redundant 3P pixel syncs; prioritize 1P local storage/first-party cookies + Prebid Server
Dynamic Floor & Bid Shading Defense High bid density supports aggressive dynamic floors Curated PMP/Deal IDs + SDA enrichment required to prevent DSP ID-less bid shading

With PAAPI and Topics gone, three interoperable standards created by the IAB Tech Lab and supported natively by Google Ad Manager, Prebid, and tier-1 DSPs form the cornerstone of post-Sandbox monetization: Publisher Provided Identifiers (PPID), Seller-Defined Audiences (SDA), and PAIR (Publisher Advertiser Identity Reconciliation).

First, Seller-Defined Audiences (SDA) solves the exact use case Topics API failed to address, without relying on browser-vendor black boxes. Under the IAB Tech Lab SDA specification, publishers classify their own first-party behavioral audiences (using IAB Audience Taxonomy 1.1, segtax: 4) and real-time page context (using IAB Content Taxonomy 3.0, segtax: 6 or 7) and pass those standardized segment IDs directly in the OpenRTB 2.6 user.data and site.content.data (or app.content.data) objects. Simultaneously, publishers map those identical taxonomy nodes into Google Ad Manager using Publisher Provided Signals (PPS) via googletag.pubads().setPublisherProvidedSignals(). Because SDA and PPS operate entirely through the existing OpenRTB 2.6 and GPT pipelines, they work identically on Safari, Firefox, Chrome, iOS apps, and CTV SSAI streams.

Second, GAM PPID (setPublisherProvidedId) and IAB Tech Lab PAIR replace browser-side remarketing worklets for high-value authenticated and semi-authenticated users. A publisher's PPID (which must be an obfuscated hash or UUID between 32 and 150 alphanumeric characters, free of cleartext PII) enables Google Ad Manager 360 and AdX to enforce cross-device frequency capping, audience segmentation, and programmatic guaranteed deal delivery on Safari and iOS where third-party cookies are absent. When paired with PAIR, publishers and advertisers reconcile logged-in first-party datasets (such as hashed emails or phone numbers) inside clean rooms using commutative double-encryption, emitting an ephemeral array of pairId keys inside user.ext.eids. Because PAIR IDs are scoped specifically to the publisher-advertiser relationship and rotated cryptographically, they cannot be reverse-engineered into a cross-site tracking profile, satisfying both strict WebKit privacy policies and enterprise advertiser security audits.

Below is a production-ready implementation showing how to unify GAM PPID, GAM Publisher Provided Signals (PPS), and Prebid.js 11.x OpenRTB 2.6 ortb2 enrichment (including SDA and PAIR eids) inside a single synchronized client-side orchestration script:

window.googletag = window.googletag || { cmd: [] };
window.pbjs = window.pbjs || { que: [] };

// Deterministic 1P Session/Subscriber Hash (SHA-256 hex, 64 chars)
const publisherFirstPartyPPID = 'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855';

// Standardized IAB Audience Taxonomy 1.1 & Content Taxonomy 3.0 IDs
const iabAudienceSegments = ['42', '188', '412']; // e.g., Auto Intenders, Personal Finance
const iabContentSegments = ['214', '218'];       // e.g., Investing, Credit & Lending

// 1. Configure Google Publisher Tag (GPT) with PPID and PPS
googletag.cmd.push(function () {
  const pubads = googletag.pubads();

  // Set GAM Publisher Provided ID (32-150 alphanumeric chars)
  pubads.setPublisherProvidedId(publisherFirstPartyPPID);

  // Inject IAB Audience & Content Taxonomies via Publisher Provided Signals (PPS)
  pubads.setPublisherProvidedSignals({
    'IAB_AUDIENCE_1_1': iabAudienceSegments,
    'IAB_CONTENT_2_2': iabContentSegments
  });

  pubads.disableInitialLoad();
  pubads.enableSingleRequest();
  googletag.enableServices();
});

// 2. Synchronize identical signals into Prebid.js 11.x OpenRTB 2.6 (ortb2)
pbjs.que.push(function () {
  pbjs.mergeConfig({
    ortb2: {
      site: {
        content: {
          data: [
            {
              name: 'firstparty.publisher.com',
              ext: { segtax: 6 }, // IAB Tech Lab Content Taxonomy 3.0
              segment: iabContentSegments.map(id => ({ id: String(id) }))
            }
          ]
        }
      },
      user: {
        data: [
          {
            name: 'firstparty.publisher.com',
            ext: { segtax: 4 }, // IAB Tech Lab Audience Taxonomy 1.1 (SDA)
            segment: iabAudienceSegments.map(id => ({ id: String(id) }))
          }
        ],
        ext: {
          eids: [
            {
              source: 'publisher.com',
              uids: [
                {
                  id: publisherFirstPartyPPID,
                  atype: 1
                }
              ]
            },
            {
              source: 'pair-protocol.com',
              uids: [
                {
                  id: 'a9f8d7e6c5b4a3f2e1d0c9b8a7f6e5d4c3b2a1f0',
                  atype: 500
                }
              ]
            }
          ]
        }
      }
    }
  });
});

Executing this post-Sandbox architecture requires strict operational discipline across three concrete engineering checkpoints:

  1. Upgrade to Prebid.js 11.x and Purge Sandbox Bloat: Audit your Prebid build pipeline immediately to ensure paapi, paapiForGpt, topLevelPaapi, and topics modules are removed, and strip obsolete Permissions-Policy directives (run-ad-auction, browsing-topics, attribution-reporting) from your CDN response headers.
  2. Deploy Unified SDA + PPS Signal Pipelines: Map your first-party behavioral cohorts and article/video metadata to IAB Audience Taxonomy 1.1 (segtax: 4) and Content Taxonomy 3.0 (segtax: 6 or 7), feeding them simultaneously into Prebid ortb2 and GAM setPublisherProvidedSignals(). This immediately lifts clearing prices on Safari, Firefox, and iOS traffic where third-party cookies are absent.
  3. Consolidate Supply Paths with Clean, Curated Demand: At Sky Boosts, we pair server-side OpenRTB 2.6 curation, GAM MCM (Manage Inventory and Manage Account), and Prebid Server with 100% Google-friendly, HUMAN and Pixalate IVT-clean inventory standards (strictly mainstream, brand-safe demand with zero alcohol, gambling, adult, or restricted categories) backed by reliable Net-30 and Net-60 payment terms. By combining Chrome cookie density with deterministic first-party signals and SDA curation across ID-less environments, publishers capture maximum yield across every browser and device without relying on deprecated browser experiments.
Next step

Put it to work.

Every pattern in this article runs on our unified SSP and monetization platform: GAM and MCM management, Prebid client and server-side, and CTV SSAI.

Net-30 / Net-60 terms · 100% brand-safe demand