How does Meta technically store and aggregate Off‑Facebook Activity on its servers?

Checked on January 20, 2026
Disclaimer: Factually can make mistakes. Please verify important information or breaking news. Learn more.

Executive summary

Meta collects signals from websites and apps outside its platforms and stores them in systems that were redesigned to avoid directly linking that off‑site activity to a person’s primary UID; when users disconnect future Off‑Facebook Activity, Meta maps that activity to a shared “bucketed MID” used for aggregated measurement rather than one-to-one user records [1]. The company accepts data via client-side trackers and server-to-server connections, retains attribution windows and aggregations governed by partner rules, and keeps some data in aggregated, non‑user‑specific forms even after users clear their personal links [2] [3] [4].

1. How the data arrives: pixels, SDKs, and server-to-server receipts

Meta receives off‑platform signals through a mix of embedded code (the Meta/Facebook Pixel or SDKs in apps) and direct server‑to‑server submissions from companies and ad partners; researchers and Meta’s own interfaces show examples of both browser/app-based tracking and server‑side uploads as sources of the activity entries users can view under “Your activity off Meta technologies” [2] [5].

2. Where it’s written: existing storage vs. redesigned systems

Historically, content shared on Meta used online, real‑time storage organized by user identifiers, but engineering work for the Off‑Facebook Activity tool required redesigning systems so off‑site events would not be directly connectable to a person’s UID once they chose to disconnect — a key architectural decision Meta describes in engineering documentation about separating those event stores from per‑user live deletion paths [1].

3. The bucketed MID and the mechanics of aggregation

When a person disconnects future Off‑Facebook Activity, Meta assigns a bucketed MID — an identifier that deliberately does not represent an individual but is shared across many disconnected users — enabling statistical, aggregated operations (for example: concluding that someone in the bucket saw an ad and later visited a measured site) while preventing systems from mapping those events back to a unique user ID [1].

4. Attribution windows, third‑party partners, and retention limits

Third‑party measurement partners that ingest Meta’s attribution signals operate under constraints — for instance, Meta forbids partners like Adjust from storing attribution data beyond a defined period (reported mappings and limits such as a 150‑day flagged attribution window are documented in partner help material) — showing that aggregation is paired with policy controls on retention and reporting [3].

5. What “aggregated” means in practice and its limits

Meta and independent reporting stress that “aggregated” does not mean the data vanishes; disconnected activity is unlinked from a specific account but may be retained in aggregated form for measurement and analytics — a posture Meta outlines and consumer reporting confirms when researchers used the Off‑Facebook Activity export to study server‑to‑server flows and the list of companies sharing signals [1] [2] [4].

6. How users can interact with these systems — and where reporting is silent

Users can review and clear Off‑Facebook Activity from their accounts through the controls Meta exposes in account settings; engineering notes emphasize unlinking from the UID and assigning bucketed identifiers for disconnected users, while watchdogs and guides point out that clearing history does not necessarily stop future collection unless users disable the setting and that some forms of tracking (including offline data uploads) may still flow to Meta [1] [4] [2]. Reporting available in these sources does not provide low‑level schema diagrams, database types, or exact hashing/cryptographic procedures Meta uses to implement the unlinking and bucketing, so the technical description stops at the architectural and operational choices Meta discloses [1].

7. Competing narratives and implicit incentives

Meta frames the bucketed MID and aggregated retention as privacy‑protecting engineering choices that still permit advertisers to measure outcomes; critics and privacy groups argue the company’s business model and partnerships incentivize broad data collection including offline and server‑side uploads, and caution that aggregation can preserve useful signals for ad targeting even if direct UID links are severed — both perspectives are evident in Meta’s engineering post and in critical reporting from privacy organizations [1] [6] [2].

Want to dive deeper?
How does Meta’s bucketed MID differ technically from standard hashed user IDs in ad systems?
What legal or regulatory limits exist on Meta’s retention and aggregation of third‑party attribution data?
How do server‑to‑server tracking flows to Meta work and how can companies opt out of sharing them?