Limited Data Use Meta: data_processing_options in Server Events

The documented name for carrying a US state-privacy signal in your events is Limited Data Use - Meta's data_processing_options mechanism: "a data processing option that gives you more control over how your data is used in Meta's systems." For server-side buyers it lives in three fields - data_processing_options, data_processing_options_country, and data_processing_options_state - inside each Conversions API event. This guide explains what the fields do, the exact documented values, the empty-array semantics most setups miss, and when the flag belongs in your traffic.

The delivery machinery around the fields - tokens, postbacks, required fields - is the standard contour from the postback-to-CAPI guide; identity rules live in the deduplication guide, and this page stays on the privacy signal itself.

What Limited Data Use Is

Meta's framing is control: Limited Data Use "gives you more control over how your data is used in Meta's systems and better supports your compliance needs" (data processing options for US users). The flag matters for traffic from US states whose privacy laws create opt-out duties - whether a specific event gets processed under those restrictions is a fact you know and Meta does not.

Two properties of the mechanism shape everything else. It is per-event: each event in the batch carries its own processing options, so mixed traffic can be flagged selectively. And it is explicit: silence is not neutral, because the documented empty array exists precisely to state "process this normally" on purpose.

The Three Fields, Documented

For the Conversions API, Meta documents the implementation "by adding data_processing_options, data_processing_options_country, and data_processing_options_state inside each event within the data parameter" of the request. The documented combinations:

Numeric codes matter: the documented manual-location example uses country 1 and state 1000 for California - a matching-relevant detail when the same user converts in several states. The empty array deserves separate emphasis - it is not the same as omitting the field. Meta documents it as the way to "explicitly specify that this event or record shouldn't be processed with the Limited Data Use restrictions," which makes it the deliberate "normal processing" statement for events where the privacy signal does not apply.

The Pixel Equivalent

On the pixel side, the same options travel under camelCase: dataProcessingOptions in the JavaScript call, and query parameters dpo=LDU&dpoco=1&dpost=1000 for the image pixel form. Mixed setups - pixel on some funnels, server events elsewhere - should carry a consistent signal on both sides, or the same user action arrives at Meta with different privacy statements depending on which channel delivered it.

When the Flag Belongs in Your Traffic

Whether to send ["LDU"] is a compliance question first: if your traffic includes visitors from states whose privacy laws give them opt-out rights that your funnel must honor, the events for those visitors carry the signal. The mechanics are these:

1. Decide per event, not per campaign - the fields live inside each event for exactly this reason.
2. Choose the location mode: Meta-performed geolocation (0/0) or manual codes (1/state) when you know the jurisdiction yourself.
3. Use the empty array deliberately for events outside the LDU scope, so your payload states its processing mode explicitly rather than by omission.

Verification habits from the postback troubleshooting checklist apply unchanged: one test event per configuration, inspected in the platform's tooling (get started with the Conversions API).

Limited Data Use: Frequently Asked Questions

Sources