Meta Limited Data Use is a geo switch on the collector, not a global off button for conversions.
Check your payload in the playground →
Agency measurement tickets still arrive with one sentence: turn on Limited Data Use so we are opted out in California. That sentence mixes three different wires. A CMP opt-out on the site is one signal. A Meta pixel parameter or CAPI field is another. A hard stop on ads delivery is a third. Meta documents Limited Data Use as data_processing_options with LDU, plus country and state integers on each event. That trio is a geo-scoped processing instruction for US privacy law, not a universal kill switch that replaces consent strings or deletes hashed email from the payload.
On October 23, 2026, AdExchanger framed Apple's latest Safari move as identity resolution going the way of the cookie, with WebKit blocking resolver domains even when vendors rebrand as first party. The same week, Italy's email-pixel deadline and Safari revenue-loss tallies keep compliance teams busy. Under that pressure, agencies paste LDU onto every US Purchase because it sounds like opt-out. Meta's own Conversions API guide states the opposite default: to explicitly not enable Limited Data Use, send an empty data_processing_options array or remove the field. Events still flow. They process without the LDU restriction.
This post is about the collector dialect agencies control from the vendor login and the sandbox payload, not a hashing tutorial. If your production worker sends LDU on Texas shoppers because the legal memo said US, while the browser pixel omits dpo entirely, Events Manager can show green dedup with two different processing policies for one order. The advertiser blames the agency. The agency blames Meta. The fix is reading what LDU actually toggles on the wire.
What Meta measures when LDU is present
Limited Data Use is not a consent string and not an event_name change. Meta's Conversions API documentation places data_processing_options, data_processing_options_country, and data_processing_options_state inside each event object in the data array. LDU in the options array tells Meta to apply its Limited Data Use treatment for that event. Country code 1 is the United States. State code 1000 in Meta's examples corresponds to California when you manually specify location instead of asking Meta to geolocate from IP.
When LDU is off, Meta documents two equivalent paths: set data_processing_options to an empty array or omit the field. That is an affirmative choice for full processing under Meta's US rules, not an accidental default. Teams that believe omitting the field means do not track have it backwards relative to vendor docs. Omission means LDU is not enabled for that event.
Geolocation mode is its own branch. Meta shows LDU with country 0 and state 0 so Meta performs geolocation and applies LDU where its policies require. That is not the same as sending country 1 with a known state code you collected from the CMP. Country without state, or state 0 while country is 1, invites Meta to geolocate rather than trust your declared region. Pixellint flags that pattern because the restriction you thought you set may not match the region Meta assigns.
LDU does not strip user_data. Hashed em, fbc, fbp, and client_ip_address can all remain on the same Purchase. LDU changes processing rules Meta applies to that event under US state privacy frameworks. It does not replace opt_out flags from older API versions and it does not mirror a user's email-list unsubscribe. Those live on different systems with different HTTP shapes.
Browser dpo and server LDU are one policy split across hops
On facebook.com/tr, Limited Data Use uses dpo=LDU with dpoco for country and dpost for state. The Conversions API uses the data_processing_options trio on the JSON event. Meta expects the same policy when both hops fire for one conversion. Pixel plus CAPI dedup joins on event_id and time; it does not merge processing options. A browser tag with dpo=LDU and dpoco=1 and dpost=1000 paired with a server Purchase that omits data_processing_options sends Meta one restricted and one unrestricted event for the same cart.
Dedup may keep the richer server event. That is where agency nightmares start. Marketing enabled LDU on the pixel because the CMP showed a California visitor. Engineering's server template never added data_processing_options because someone said LDU was a pixel-only checkbox. Events Manager dedupes to the server body. Full processing wins while the trafficking sheet claims Limited Data Use is on.
The inverse hurts too. LDU on every server event with data_processing_options set for all US ZIP codes, while the pixel stays unrestricted, trains two policies on the same campaign. Sandbox tests that only inspect the pixel URL miss the worker POST entirely until production revenue diverges from the test event stream.
Consent Mode on Google and TCF strings on Floodlight do not set Meta LDU. A green ad_user_data update in Tag Assistant does not populate data_processing_options_state. GPP US National on a display tag does not travel to graph.facebook.com unless your tag manager copies it, and Meta does not document GPP as a substitute for LDU fields.
What the solutions engineer can see from the agency seat
As a solutions engineer at an agency, you see the sandbox event and the vendor sample payload, and you do not own the production dataset. The advertiser owns the Meta Business Manager login. The landing page and checkout code belong to the client or their dev shop. Your job is to prove the sample JSON the vendor published matches what production sends after macros, GTM versions, and server containers diverge.
When legal asks for LDU everywhere in the US, your first response is not a Jira to add LDU to every trigger. It is a side-by-side of one Purchase in Test Events: pixel request query parameters versus CAPI JSON. Note whether data_processing_options is absent, empty, or set to LDU with which country and state. Note whether the pixel fired dpo at all. That diff is evidence the client can send to counsel without you claiming to be their lawyer.
Agency-owned server-side GTM or CAPI Gateway templates often hard-code LDU after a single California test passed. Production traffic includes states with different effective dates and users whose CMP choice was sell but not share. LDU is not a stand-in for those CMP outcomes. It is Meta's US processing knob. Blanket LDU on all US events can over-restrict relative to what the user chose on the site, while still not counting as an opt-out in the ESP or CRM.
The October identity-resolution headlines matter here because teams conflate blocked resolver domains with turn off matching. LDU does not unblock Safari resolver calls. It does not restore fbp when ITP caps cookie life. It tells Meta how to treat an event that still arrived with whatever identifiers you sent.
Explicit full processing versus LDU with manual California
Illustrative JSON from Meta Conversions API Data Processing Options section; state 1000 is Meta's California example.
Full processing (Meta docs: not enabling LDU):
{
"data": [{
"event_name": "Purchase",
"event_time": 1761200000,
"action_source": "website",
"event_source_url": "https://client.example/thanks",
"user_data": { "em": ["<sha256>"] },
"custom_data": { "currency": "USD", "value": 129.99 },
"data_processing_options": []
}]
}
LDU with manual US + California (Meta example shape):
{
"data": [{
"event_name": "Purchase",
"event_time": 1761200000,
"action_source": "website",
"user_data": { "em": ["<sha256>"] },
"custom_data": { "currency": "USD", "value": 129.99 },
"data_processing_options": ["LDU"],
"data_processing_options_country": 1,
"data_processing_options_state": 1000
}]
}The first payload is what Meta documents when LDU should be off. It is not anonymous. Email hash remains. The second payload is restricted processing under LDU with an explicit state. Neither payload stops Events Manager from receiving the event. Neither is equivalent to deleting the tag from the page.
Agency QA should capture both shapes from staging before go-live. If the client's legal team believes empty array means do not send, show Meta's sentence that empty array explicitly disables LDU. If they believe LDU means do not track, show that hashed identifiers may still be present and that test_event_code events also flow into measurement per Meta's testing notes.
Production failures show up as policy drift, not 4xx errors. Graph accepts incomplete LDU pairs. Meta may geolocate when state is missing. The advertiser sees conversion counts while audit asks why California users were processed fully. Your sandbox diff is the artifact that separates misconfigured LDU from a true delivery problem.
Sandbox versus production checklist
- Pull Meta's sample Purchase from the Conversions API doc and compare field names to your server template line by line.
- Fire one labeled test Purchase on the client staging site with Test Events open; copy pixel query string and CAPI POST separately.
- Record whether data_processing_options is missing, [], or ["LDU"] and record country and state integers for each hop.
- If the pixel sends dpo=LDU, confirm dpoco and dpost match the CAPI country and state on the same event_id.
- Do not map CMP opt-out buttons to LDU without legal sign-off; map CMP outcomes to whether the event should fire at all.
- When Safari identity blocking breaks fbp, do not increase LDU scope; fix identifier strategy and leave LDU geo accurate.
- After publish, re-run one production Purchase weekly until the client's dev shop stops editing the container without notice.
To explicitly not enable Limited Data Use (LDU), specify an empty array for each event or simply remove the field in the payload.
Meta, Conversions API using the API, Data Processing Options for US Users
How this differs from Italy email opt-out and Safari blocking
Italy's granular email-pixel opt-out lives on the ESP send path. It removes the open pixel from the message. It does not rewrite Meta CAPI on the storefront. LDU on a web Purchase does not satisfy an email-tracking revocation and email revocation does not set data_processing_options on site events. Our October Italy post on pixellint.org keeps those pipes separate; this post keeps LDU separate from both.
Safari's identity resolver block stops email from reaching resolver hosts during login flows. LDU neither opens those hosts nor replaces first-party CAPI with a global off switch. Teams hit by AdExchanger's October 23 identity story should fix resolver dependencies and cookie caps, then revisit LDU only where US state law actually requires Meta's processing mode for that user's region.
Pixellint is not affiliated with Meta. Validate CAPI JSON against the documented LDU shapes linked below. That catches empty versus LDU mismatches and country-without-state pairs before the advertiser compares your sandbox screenshot to a production export that tells a different story.
Limited Data Use belongs in the same conversation as consent fields, not as a shortcut through it. When the agency seat owns the vendor login but not the site, your deliverable is a reproducible sandbox-versus-production diff on processing options, not a blanket LDU flag that sounds like opt-out in a slide deck.
Sources
Contract pages
The dated argument is above. These pages are the field lists.