Consent Management with the Singular SDK: A Decision Framework

Follow
Avatar
Jared Ornstead
Updated

Consent Management with the Singular SDK: A Decision Framework

This article describes the privacy controls Singular provides and the implementation patterns we observe across our customer base, and gives a framework for composing them into a consent architecture. Each individual control is documented in its own article; this page explains how they work together.

Before you start: Your legal and privacy teams control your consent flow and are responsible for deciding which posture applies to your app in each jurisdiction. This article describes product behavior only and is not legal advice.

The two decisions every consent flow reduces to

Singular's privacy controls compose around two independent decisions. Keeping them separate lets a single consent prompt drive a compliant implementation.

Decision 1: Tracking. Does Singular see this user at all? This is controlled by whether and when you initialize the SDK. Initialization sends the first session, creates the install record, and triggers attribution processing. If the SDK is never initialized, Singular receives nothing for the device. This is the strictest control available.

Decision 2: Sharing. Given that Singular sees the user, may their data be shared with advertising partners? This is controlled by the Limit Data Sharing (LDS) flag. LDS lets you keep first-party analytics (sessions, retention, events, your reporting) while restricting what flows to partners in postbacks. See the Limit Data Sharing FAQ for semantics and partner behavior.

If your consent framework distinguishes measurement consent from advertising or retargeting consent (common in the EEA), the mapping is direct: measurement consent gates initialization, and advertising consent sets LDS. One prompt, resolved once, drives both levers.

The control inventory, from least to most restrictive

Control What it does What it does not do
limitDataSharing (config or runtime) Marks the user's sharing preference; partner postback behavior follows your per-partner configuration. Does not stop Singular from tracking; does not change postbacks unless partner-level restrictions are configured.
Limited identifiers mode SDK does not collect IDFA or GAID; uses IDFV or ASID instead. Does not stop tracking or sharing of non-advertising identifiers.
stopAllTracking() Halts all transmission immediately and persistently until resumeAllTracking() is called. Does not undo the install and events already sent; initialization has already triggered attribution.
Never initialize Singular receives and processes nothing for the device. Deferred deep links and attribution are unavailable for these users.
trackingOptIn() Legacy: records a consent notification event only. Has no functional effect on tracking or data handling; do not build consent logic on it.

Three consent flow models

  • Opt-out default (initialize first): The SDK initializes on app open; consent is presented during onboarding; a decline triggers stopAllTracking() or sets LDS to true. This gives full attribution fidelity and prompt SAN postbacks. The install moment is captured before the user answers, so this model requires a legal posture that permits collection before an affirmative choice. Common for US audiences.
  • Opt-in default (consent first): The SDK is not initialized until the user affirmatively consents. Nothing is transmitted for non-consenting users. Standard for GDPR audiences. Persist the decision and initialize immediately on later launches in every app entry point.
  • Hybrid (initialize immediately, resolve LDS at initialization): Resolve the consent surface at app open, then initialize with limitDataSharing already set on the config object. Every record from the install onward carries the user's declared state, with no window where intent exists but has not been applied. This is the pattern we recommend to privacy-sensitive customers who can show consent at open.

Most multi-region apps run more than one model, selected at runtime by jurisdiction or by their CMP.

Timing consequences to plan for

  • Deferred initialization does not cost the install if initialization happens within the same app session: the Android install referrer persists on the device and the attribution request completes normally.
  • SAN match rates degrade when initialization is delayed for a long time (multi-step consent flows, multi-day gaps). Keep first-launch gates to a single fast screen.
  • SKAdNetwork postbacks are generated by the OS at install time and are unaffected by SDK initialization timing.
  • Deferred deep links require initialization and attribution to resolve. Under a strict opt-in model, deferred deep linking is only available to consented users.
  • There is no initialization-complete callback. If you build custom event sequencing, snapshot the consent state at the moment of initialization.
  • The install record locks the LDS value in effect at initialization. Later updates apply to subsequent events only, and postbacks already sent are not recalled. Do not default undecided users to LDS true unless your legal posture requires it; either resolve consent first or leave LDS unset until the user answers.

Common pitfalls

  • Unset LDS is treated as not limited. An integration that intends to restrict a user but has not yet set the flag is, from Singular's perspective, an unrestricted user.
  • LDS true changes nothing by itself. Postback behavior for LDS users is defined per partner, per app, in your partner configuration (do not send / send without PII / send as usual). Set the flag and configure the enforcement.
  • ATT is not a consent framework. It governs only IDFA release. Whether an ATT denial should also imply LDS true is a policy decision for your privacy team.
  • GDPR erasure is not an opt-out. The OpenDSR API deletes collected data; it does not stop the SDK from sending future events. Pair erasure with stopAllTracking() in the same user flow.

Related articles