Two decisions, 14 months apart: what Google actually did
The Privacy Sandbox story has two distinct acts, and conflating them is how most marketing teams have misjudged the strategic situation.
Act one, July 22, 2024. Anthony Chavez, VP of Privacy Sandbox, published "A new path for Privacy Sandbox on the web" on blog.google. The post confirmed that Chrome would not deprecate third-party cookies. Instead, Google would introduce a user-facing choice mechanism: a Chrome UI that lets users make an explicit decision about cross-site tracking. The plan to remove cookies by a fixed deadline was abandoned. Regulators, publishers, and ad-tech vendors had all pushed back hard on the original timeline; Google cited the feedback as a driver of the reversal. At that point, Privacy Sandbox APIs were still live and nominally still on the roadmap.
Act two, October 17, 2025. Chavez published a second post: "Update on Plans for Privacy Sandbox Technologies." This one retired the APIs. Ten technologies were put on the deprecation list, with an explicit reference to "low levels of adoption" as the reason. The post acknowledged that with cookies staying, the urgency to adopt Privacy Sandbox alternatives had evaporated and the ecosystem had not built on them at meaningful scale.
The sequence tells a coherent story. Topics API, Protected Audience, and Attribution Reporting all required the ad-tech ecosystem to rebuild significant infrastructure. With third-party cookies staying in Chrome, that rebuild had no forcing function. Google's own statement names the result: "low levels of adoption." When adoption is low and the original motivation (cookie removal) is gone, retiring the APIs is the logical outcome.
What remains live in the Privacy Sandbox are the technologies that solve different problems. CHIPS (Cookies Having Independent Partitioned State) partitions first-party cookies to third-party contexts, improving security without breaking cross-site flows. FedCM (Federated Credential Management) handles federated login without exposing user identity to the identity provider. Private State Tokens address fraud and abuse signals without cross-site tracking. These three continue because they have genuine adoption and solve problems that exist regardless of the cookie-deprecation debate.
The ten APIs being retired, and the three that stay
The October 2025 announcement listed the retirements explicitly. For any team that invested engineering time or vendor integrations in Privacy Sandbox APIs, the table below is the complete reference.
| API / Technology | Status | What it was for |
|---|---|---|
| Topics API (Chrome + Android) | Retiring | Interest-based targeting without cross-site user profiles |
| Protected Audience API (Chrome + Android, formerly FLEDGE) | Retiring | On-device remarketing auctions without server-side user data |
| Attribution Reporting API (Chrome + Android) | Retiring | Privacy-preserving ad attribution using aggregated, noisy reports |
| Private Aggregation (including Shared Storage) | Retiring | Aggregate measurement across sites with differential-privacy noise |
| Related Website Sets (including requestStorageAccessFor) | Retiring | Cross-site cookie access within first-party-owned domain sets |
| IP Protection | Retiring | Proxy routing to prevent IP-based cross-site tracking |
| On-Device Personalization | Retiring | Local ML-based content personalisation without server-side data |
| Protected App Signals (Android) | Retiring | Privacy-preserving app install and engagement signals for Android advertising |
| SelectURL | Retiring | Privacy-preserving content selection from a pre-defined URL set |
| SDK Runtime (Android) | Retiring | Isolated runtime for ad SDKs on Android to reduce data access |
| CHIPS (Cookies Having Independent Partitioned State) | Continuing | Partitioned cookies for secure cross-site embedding without cross-site tracking |
| FedCM (Federated Credential Management) | Continuing | Federated login without exposing user identity to identity providers |
| Private State Tokens | Continuing | Anti-fraud and abuse signals without cross-site tracking |
Three patterns emerge from this list. First, the retiring APIs are all ad-tech focused: targeting, attribution, remarketing, measurement. The continuing APIs are infrastructure-focused: login, fraud prevention, secure cookie partitioning. Google is walking away from the ad-tech APIs and keeping the web-platform utilities.
Second, Android is in scope for several of the retirements. Teams running app campaigns that integrated Protected App Signals or SDK Runtime need to verify with their mobile measurement partner (MMP) and demand-side platform (DSP) what that means for attribution models. The web-only framing that dominated cookieless coverage in 2021-2024 missed the mobile-app dimension.
Third, Google's October post noted it will "continue to engage" on an interoperable attribution standard through the W3C Private Advertising Technology Community Group. Attribution Reporting API is retired, but the underlying problem of privacy-preserving cross-site attribution is still on the standards agenda. This is relevant to any team planning 3-5 year measurement infrastructure. The standard may arrive; build your stack to accommodate it when it does, but do not wait for it.
The real measurement problem was never Chrome
Chrome kept third-party cookies. Safari and Firefox still block them. Safari holds roughly 25-29 percent of global browser share depending on the measurement source, with higher concentration on mobile in markets like Singapore and Australia where iPhone penetration exceeds 50 percent in some demographics. Firefox adds 3-4 percent. A practical share between 28 and 33 percent of users have been operating in a cookie-limited environment since Safari's Intelligent Tracking Prevention (ITP) launched in 2017. That figure predates the entire Privacy Sandbox debate.
The walled garden problem is older and larger still. Meta's Conversions API (CAPI) exists because Meta's own pixel, running inside Facebook's ad attribution system, was never fully reliant on Chrome third-party cookies. Meta's signal loss problem accelerated with iOS 14.5 in April 2021, when Apple's App Tracking Transparency (ATT) framework required explicit opt-in for identifier-level tracking across apps. Meta reported a USD 10 billion revenue impact in 2022 from iOS ATT. That damage came from Apple, not from Chrome. Building CAPI infrastructure, matching hashed customer data with Meta's graph, and setting up server-side event matching are all responses to Apple and Meta's measurement architecture, not to Google's cookie decisions.
TikTok's Events API has the same architecture logic as CAPI. Google's own Enhanced Conversions and server-side Google Tag are also responses to signal quality erosion, driven partly by browser restrictions and partly by ad-blocking software. Our analytics and insights practice treats server-side tagging as baseline infrastructure regardless of browser policy, precisely because the signal erosion is multi-vector. No single browser decision reverses that.
The first-party data argument rests on three pillars that the cookie reprieve does not touch. One: consent-based collection. In markets where GDPR, PDPA, or the Australian Privacy Act apply, explicit user consent is required before tracking cookies are set. A third-party cookie dropped without consent is a legal problem regardless of Chrome's technical capability. Two: walled garden matching. Meta, TikTok, Google, and LinkedIn all offer better audience matching, better lookalike quality, and better event match scoring when you supply consented first-party signals. This is a performance argument, not a compliance argument. Three: signal durability. Regulation tightens over time, browsers make their own decisions, and users install ad blockers (penetration exceeds 40 percent in some markets). A first-party data foundation is insulated from all three.
The Chrome cookie decision did not change any of these three arguments. If anything, the October 2025 API retirement reinforces the third pillar: the industry tried to build privacy-preserving ad-tech alternatives, failed to adopt them at scale, and the infrastructure investment requirement still exists but must now be solved through first-party data and server-side measurement rather than browser-native APIs. For a deeper view of the measurement stack that survives both scenarios, see our post on cookieless MMM and Bayesian incrementality for APAC marketers.
What privacy law actually requires across your markets
The regulatory picture differs meaningfully by market. For any team operating across Singapore, Australia, the United States, and Canada (leapbuzz's five-market footprint, plus Malaysia), the following table is the practical orientation.
| Market | Primary law | Consent basis for tracking cookies | Enforcement posture (mid-2026) |
|---|---|---|---|
| Singapore | Personal Data Protection Act (PDPA) | Deemed consent with notification (lower bar), or express consent. PDPC advisory guidelines on marketing data apply. | PDPC enforcement actions in financial services and retail. Advisory guidelines updated; server-side measurement flagged as a privacy-positive approach. |
| Australia | Privacy Act 1988 (as amended) | Consent or legitimate interest with disclosure; tracking pixels treated as collection of personal information. OAIC published Meta-Pixel-class tracking findings in 2026. | Active enforcement. Statutory tort for serious privacy invasions now in force. Board-level risk. |
| EU / EEA | GDPR + ePrivacy Directive | Explicit opt-in for non-essential cookies. Consent Management Platform (CMP) with granular categories required. | High enforcement density. DPA fines in the hundreds of millions of euros for large platforms. Applies to any site with EU visitors. |
| United States | State-level patchwork (CPRA, Colorado CPA, Virginia CDPA, others) | Opt-out right for sale/sharing of personal data; no federal opt-in requirement. Threshold-based (number of residents served). | Enforcement active in California (CPPA). FTC enforcement under Section 5 for deceptive tracking practices. |
| Canada | PIPEDA (federal); Bill C-27 pending | Meaningful consent required for collection and use of personal information. OPC guidance on tracking and consent applies. | OPC enforcement capacity growing. Bill C-27 would substantially increase fines and rights if enacted. |
| Malaysia | Personal Data Protection Act 2010 (PDPA MY) | Consent required for processing personal data for marketing purposes. | Enforcement less active than SG/AU, but statutory requirements apply to any data collected from Malaysian users. |
The practical conclusion: every market in leapbuzz's five-market footprint requires either explicit consent or disclosed legitimate interest before tracking cookies are set for marketing purposes. Chrome's technical decision to keep cookies does not override any of these. A site that drops third-party tracking cookies without consent is non-compliant in the EU, AU, and SG regardless of Chrome's stance. The PDPC's advisory guidelines on use of personal data in marketing cover tracking pixels, audience matching, and retargeting directly.
For teams that have not yet implemented a consent management platform (CMP), the OAIC's 2026 findings on tracking pixels are a useful urgency signal for the AU market. The finding confirmed that embedding third-party tracking pixels without adequate disclosure and consent mechanisms constitutes a breach of Australian Privacy Principle 1 (APP 1), which requires transparent handling of personal information. For a practical walkthrough of CMP implementation aligned to strictly necessary consent categories, our post on Freshpaint and CMP strictly necessary consent covers the boundary conditions in detail.
Server-side tagging addresses the consent-execution problem as well as the signal problem. When tag firing is controlled server-side, the CMP consent state can be enforced at the server layer before any event is forwarded to a third-party platform. Browser-side tags, by contrast, rely on the CMP blocking script executing before the tracking pixel fires, which is technically fragile. Our analytics and insights service covers server-side architecture as part of every measurement engagement, not as an optional add-on.
One practical framing for AU-market clients: the OAIC's 2026 enforcement posture treats website analytics and ad pixels under the same regulatory lens as direct marketing lists. "We don't sell data" is not a defence for a tracking pixel that passes user-identifiable information to a third-party platform without disclosure. The regulatory definition of "collection" includes passive technical collection through pixels and tags.
What to do now: a decision flowchart
The decision depends on where your stack currently sits relative to two variables: Privacy Sandbox API exposure, and cookie-dependency combined with regulatory market mix. The flowchart below routes to one of four postures. All advice is generic; apply your own audit before acting on any branch.
A note on the flowchart postures. Action A (Privacy Sandbox API investors) requires an honest audit of what was built and what it cost. Most vendors who integrated Topics or Protected Audience early are already redirecting that engineering capacity; confirm with your DSP or measurement vendor before assuming your integration is dead code.
Action C (cookie-reliant, regulated-market exposure) is where the regulatory risk is most concentrated. The Australian OAIC's 2026 tracking-pixel investigation findings, the PDPC's enforcement pattern in Singapore, and GDPR's strict consent requirements in the EU all converge on the same conclusion: a third-party tracking cookie without a valid consent mechanism is a liability regardless of Chrome's technical posture. The CMP is not optional in these markets, and server-side tagging is the correct architecture for enforcing the CMP decision at the event layer. See our AI strategy service for how we approach measurement stack architecture as part of broader data strategy engagements.
For teams who have already built first-party data infrastructure (Action B), the October 2025 retirements are largely validation rather than a call to action. The Privacy Sandbox road was always uncertain. Teams that invested in consented data collection, CRM matching, server-side event pipelines, and CAPI integrations are in a defensible position regardless of what Google does with Chrome.
For a broader view of how to structure measurement that does not depend on any single browser decision, our post on first-party data strategy covers the foundational architecture decisions from customer data platform selection to consent-compliant collection mechanics.
