Meta's Privacy Sandbox pixel: a technical deep dive

Meta quietly embedded Chrome's Attribution Reporting API (ARA) into its standard Facebook Pixel (fbevents.js), routing conversion signals through a dedicated endpoint at facebook.com/privacy_sandbox/pixel/register/trigger/. This endpoint represents Meta's implementation of the trigger registration step of Chrome's ARA — the privacy-preserving mechanism for recording conversions without third-party cookies. The endpoint runs in parallel alongside the traditional /tr/ pixel, serving as a complementary attribution path for browsers that restrict cookie-based tracking. No official Meta developer documentation exists for this endpoint. In a significant twist, Google officially retired the Attribution Reporting API in October 2025, making this implementation effectively transitional — though Meta's broader privacy-preserving attribution work through the W3C now forms the backbone of the successor standard.

How trigger registration works under the hood

The /privacy_sandbox/pixel/register/trigger/ endpoint implements one half of Chrome's ARA two-step protocol. The full flow operates as follows: when a user views or clicks a Meta ad on a publisher's site, Meta registers an attribution source with the browser via the Attribution-Reporting-Register-Source HTTP response header, storing encrypted metadata (campaign ID, destination site, expiry) in the browser's private cache. Later, when that user visits an advertiser's site and performs a conversion — a purchase, form submission, or other tracked event — Meta's pixel fires a request to the /privacy_sandbox/pixel/register/trigger/ endpoint.

This request uses the fetch() API with the attributionReporting: {eventSourceEligible: false, triggerEligible: true} option, causing Chrome to attach an Attribution-Reporting-Eligible: trigger request header. Meta's server then responds with the Attribution-Reporting-Register-Trigger response header containing JSON-encoded trigger configuration — event trigger data, aggregatable trigger data, priority values, deduplication keys, and filter specifications. The browser processes this header internally, matches the trigger against stored sources based on destination site and reporting origin, and schedules delayed attribution reports to be sent back to Meta. Event-level reports arrive with 2–7 day delays and contain limited, noised data; aggregatable reports are encrypted and must be processed through a Trusted Execution Environment before Meta receives differentially private summary statistics.

The critical difference from the traditional /tr/ endpoint is who controls the attribution logic. With /tr/, Meta receives full event data in real time and performs server-side matching using third-party cookies (_fbp, _fbc) and user identity graphs. With the ARA trigger endpoint, the browser itself performs attribution matching — Meta never receives cross-site identifiers, only delayed, noised, or aggregated reports.

Parameters decoded: cd[], rqm, expv2, and the rest

The request parameters sent to /privacy_sandbox/pixel/register/trigger/ blend established Facebook Pixel conventions with Privacy Sandbox–specific data. Here is what each parameter group carries:

cd[] (Custom Data) is the best-documented parameter, inherited directly from the traditional pixel. It carries event-specific conversion data — cd[value], cd[currency], cd[content_type], cd[content_ids], and similar fields. When an advertiser calls fbq('track', 'Purchase', {value: 115.00, currency: 'USD'}), the pixel serializes those properties into cd[] query parameters. In the Privacy Sandbox context, this data informs Meta's server how to construct the ARA trigger response header — determining trigger_data values, aggregatable key structures, and contribution budgets.

rqm=FGET (Request Method: Fetch GET) indicates the HTTP transport mechanism. Traditional pixel calls use rqm=GET for <img> tag requests and rqm=POST for XMLHttpRequest calls. The FGET value means the request was made via the browser's fetch() API using the GET method. This is not arbitrary — ARA trigger registration requires fetch() with specific attributionReporting options to signal trigger eligibility to Chrome. The FGET designation lets Meta's server distinguish Privacy Sandbox–eligible requests from standard pixel fires.

expv2 (likely Experiment Version 2) is undocumented publicly but almost certainly encodes Meta's internal A/B testing and feature flag assignments. Meta operates one of the largest experimentation platforms in the industry, and the exp prefix plus v2 suffix strongly suggest this carries experiment bucket identifiers that determine which ARA configuration variant — trigger data encoding, aggregation key structure, privacy budget allocation — the server should use when constructing the response header.

pmd[] and ap[] are also undocumented. Based on naming patterns and ARA protocol requirements, pmd[] most likely stands for "Pixel Metadata" — configuration data about the pixel instance itself (version, initialization state, consent signals) distinct from the event data in cd[]. The ap[] group likely carries "Attribution Parameters" — data specifically needed for ARA trigger construction, such as aggregatable values, key pieces, or priority signals that map to the aggregatable_trigger_data and aggregatable_values fields in the ARA response header. These interpretations remain informed inference; Meta has not publicly documented these parameters.

Meta's broader strategy bypassed Google's Privacy Sandbox

The most striking finding is that Meta was never a listed tester of Google's Privacy Sandbox APIs. While companies like Criteo, RTB House, NextRoll, and Index Exchange actively tested ARA through Google's origin trials, Meta pursued an entirely different path. Starting in February 2022, Meta engineer Ben Savage and Mozilla engineer Martin Thomson co-developed Interoperable Private Attribution (IPA) — a competing proposal submitted to the W3C's Private Advertising Technology Community Group.

IPA differs fundamentally from Google's ARA. Where ARA relies on Trusted Execution Environments and is Chrome-specific, IPA uses Multi-Party Computation (MPC) with independent "helper parties" and was designed to work across browsers and devices. Crucially, IPA leverages encrypted match keys tied to user logins — a design that exploits Meta's core competitive advantage of billions of logged-in users across Facebook, Instagram, and WhatsApp. This enables cross-device attribution that ARA could never achieve.

Despite this strategic divergence, Meta's fbevents.js code does fire requests to Privacy Sandbox endpoints in production — both the /privacy_sandbox/pixel/register/trigger/ ARA endpoint and a separate /privacy_sandbox/topics/registration/ Topics API endpoint. The earliest documented observation of the trigger endpoint came in January 2025, when a Gravity Forms community member noticed these requests firing during form submissions. This suggests Meta hedged its bets, implementing Chrome's APIs at the code level while advocating for its own standard at the policy level.

The ICO report reveals Meta's five-stage PPA architecture

The most detailed official description of Meta's privacy-preserving attribution system comes from the UK Information Commissioner's Office, which published a Regulatory Sandbox Final Report in September 2025 after collaborating with Meta from June 2024 to April 2025. Meta's Privacy Preserving Attribution (PPA) system operates through five stages: source registration stores ad impression data on the user's device; trigger registration records conversion events; on-device extraction creates encrypted "histogram contributions"; MPC computation splits encrypted data between two independent helper parties who aggregate it with differential privacy noise; and finally a differentially private histogram is returned to the advertiser.

The ICO concluded that UK privacy regulations (PECR) do apply to PPA because information is stored on and accessed from users' devices, meaning user consent would be required. However, the report acknowledged that PPA "reduces data protection risks in comparison with existing industry practices" — a qualified endorsement of the approach.

Google retired ARA, vindicating Meta's W3C bet

On October 17, 2025, Google officially retired the Attribution Reporting API along with Topics, Protected Audience, Private Aggregation, and most other Privacy Sandbox technologies, citing "low levels of adoption." Google simultaneously announced it would contribute learnings to the W3C's Privacy-Preserving Attribution: Level 1 specification — the interoperable standard being developed through the Private Advertising Technology Working Group, where Meta's IPA proposal serves as a foundational input alongside Apple's Private Ads Measurement.

This retirement renders Meta's /privacy_sandbox/pixel/register/trigger/ endpoint effectively transitional. As Chrome phases out ARA support (specific removal timeline not yet published as of March 2026), these calls will cease functioning. However, Meta's strategic positioning has proven prescient: the W3C successor standard incorporates IPA's MPC architecture, cross-device match keys, and server-side privacy enforcement — all Meta innovations.

Conclusion

Meta's Privacy Sandbox pixel implementation represents a pragmatic hedge rather than a strategic commitment. The company built ARA trigger registration into its production pixel code while simultaneously developing and advocating for a fundamentally different architecture through W3C standardization. The /privacy_sandbox/pixel/register/trigger/ endpoint is genuine Chrome ARA infrastructure — it fires fetch() requests with attribution reporting options, carries conversion data through familiar cd[] parameters, and elicits proper Attribution-Reporting-Register-Trigger response headers. But the undocumented status of key parameters like pmd[] and ap[], the absence of any Meta developer documentation, and Meta's conspicuous absence from Google's official tester lists all signal that this was a parallel implementation rather than a primary investment. With ARA now retired and the W3C standard ascending, Meta's real attribution future lies not in this endpoint but in the MPC-based, cross-device PPA system it has been building through the standards process — a system designed around its greatest asset: billions of logged-in users.