Short answer: From 13 May 2027, ad tracking and attribution that rely on consent need a notice first (s.5, Rule 3), then a clear affirmative action that is specific to that purpose and not a condition of using the app (s.6(1)), plus a way to withdraw that is as easy as opting in (s.6(4)). In an onboarding flow, that usually means a separate tracking choice, made before marketing SDKs start, with a matching switch in settings.
What is valid consent for ad tracking?
Valid consent for ad tracking under the DPDP Act is a clear affirmative action, taken after a notice, that agrees to tracking or attribution as a specified purpose, covers only the personal data that purpose needs, and can be withdrawn as easily as it was given (s.5(1), s.6(1), s.6(4)).
- Clear affirmative action: a positive step by the user, such as a tap on an unticked option (s.6(1)). Interpretation: silence or a pre-ticked box is unlikely to count as one.
- Notice: the statement Rule 3 requires before or with the consent request: an itemised list of personal data, the specific purpose and how to withdraw, exercise rights and complain to the Board.
- Burden of proof: where consent is the basis, the app must prove that notice was given and consent obtained in line with the Act and Rules (s.6(10)).
Interpretation: the Act does not mention ad tracking or advertising IDs. Treating them as needing consent rests on two readings: that linkable identifiers are personal data (s.2(t)), and that s.7 has no legitimate interests ground. See consent and legitimate uses for the general rules.
How do the consent tests map to onboarding?
Each s.6 test lands on a specific moment in the flow. The table follows a typical first-run sequence.
| Onboarding moment | What the law asks | Source | Design choice teams consider |
|---|---|---|---|
| First launch | Consent before processing that relies on it | s.4, s.6(1) | Interpretation: hold attribution and ad SDKs until the choice is made |
| Notice screen | Itemised data, purpose, withdrawal link, Board complaint route; understandable on its own | s.5(1), Rule 3 | Interpretation: a short screen of its own, since Rule 3(a) asks for a notice understandable on its own |
| Language and contact | English or an Eighth Schedule language; DPO or authorised contact named | s.5(3), s.6(3) | A language switch and a contact line |
| The choice | Specific, unambiguous, affirmative | s.6(1) | One option per purpose, nothing pre-selected |
| Continue button | Unconditional; only necessary data | s.6(1) | The app works whichever way the user chooses |
| Settings | Withdrawal as easy as giving | s.6(4) | A tracking switch reachable in a similar number of taps |
| Back end | Proof of notice and consent | s.6(10) | A timestamped record of the choice and the notice version shown |
The detail of what the notice must say is on the notice requirements page.
Can ad tracking consent be bundled with the terms of service?
Interpretation: probably not safely. A single "I agree" covering the service and ad tracking together is hard to square with consent that is specific and unconditional (s.6(1)). The Act's illustration says consent to access a contact list is invalid where the list is not necessary for the service, and advertising is rarely necessary to deliver an app's core feature. Keep the tracking choice separate from sign-up, and do not block the app for users who decline.
Does an operating system tracking prompt count as DPDP consent?
Interpretation: not on its own. A platform prompt such as Apple's App Tracking Transparency is a platform rule, not a DPDP mechanism, and it does not carry the itemised notice, withdrawal link and Board complaint route that Rule 3 requires. Linkrunner's glossary explains how App Tracking Transparency works if you need the platform side.
Interpretation: many teams will need both, the platform prompt on iOS and a DPDP notice and choice on every platform, with the DPDP notice shown first so the user has the s.5 information before any tracking choice.
What happens to attribution when a user declines?
- Interpretation: if attribution and ad SDKs wait for consent, installs from users who decline, or who leave before choosing, may not be attributed to a campaign.
- If you change when an SDK starts, re-test attribution. Attribution Debugger's troubleshooter for paid installs showing as organic covers the timing causes.
- On a later withdrawal, the app must stop processing within a reasonable time and cause its processors to stop (s.6(6)), and erasure duties follow (s.8(7)). The marketing SDK checklist covers how each vendor receives that signal.
What about users who signed up before 13 May 2027?
Processing on consent given before commencement may continue until the user withdraws it, but the app must give a notice as soon as reasonably practicable (s.5(2)). The Act's illustration mentions email or an in-app notification.
- Interpretation: an in-app notice to existing users, with the same tracking choice new users see, is a common way to plan for s.5(2). What "as soon as reasonably practicable" means is not defined.
- A user may also give or withdraw consent through a registered Consent Manager (s.6(7)). Using one is optional for the user, so the app still needs its own flow. See consent managers.
What this means for your app
These are practical steps teams commonly consider. They are not a guarantee of compliance.
- Consider listing each tracking purpose (attribution, ad personalisation, retargeting) as its own option.
- A common approach is a consent state flag that every marketing SDK reads before it starts.
- Consider keeping one record per user per purpose, with the notice version, so s.6(10) can be met.