Short answer: The DPDP Act and Rules do not mention device IDs, advertising IDs, IP addresses, cookies, SDKs or attribution. Law firm commentary reads identifiers that can be linked to a person as personal data, and analytics and attribution as generally needing consent, but this is interpretation with no Board or court ruling yet. The relevant duties take effect on 13 May 2027.
Is attribution data personal data under the DPDP Act?
Attribution data is personal data under the DPDP Act if it is data about an individual who is identifiable by or in relation to it (s.2(t)). The definition gives no list of examples.
- Identifier for rights requests: any sequence of characters the app issues to identify the user, such as a customer ID, email or mobile number (Rule 14(5)).
What the law says, and what is interpretation
| Topic | What the law says | Interpretation (labelled) |
|---|---|---|
| Ad IDs, device IDs, IPs | Identifiability test only (s.2(t)); terms not mentioned | Likely personal data where linkable to a person (AMLEGALS) |
| Lawful basis | Consent or a closed list of legitimate uses (s.4, s.7) | Analytics and attribution generally need consent (AMLEGALS) |
| SDK vendors | Processor defined (s.2(k)); app responsible (s.8(1)) | Processor if on instructions only; fiduciary if it uses data for its own purposes |
| Withdrawal and deletion | App must cause processors to cease and erase (s.6(6), s.8(7)) | Opt-out and deletion signals should flow to processor SDKs |
| Children | No tracking, behavioural monitoring or targeted ads at children (s.9(3)) | No exemption for measurement or attribution |
Are advertising IDs and IP addresses personal data?
Interpretation: device IDs, advertising IDs and IP addresses are likely to be personal data where the app, or a party it works with, can link them to an identifiable individual, and hashing does not take an identifier outside the Act if it remains linkable. This is reported from law firm AMLEGALS in its DPDP review for advertising and adtech (law reviewed as on 27 July 2026).
- DLA Piper's India summary reports that the law has no specific regulation of cookies, behavioural advertising or location data, but that such data may include personal data, and recommends obtaining consent.
- Whether a device or advertising ID alone, without a name, email or phone number, makes a person identifiable is an open question. There is no guidance, FAQ or Board decision yet.
Do analytics and attribution SDKs need consent?
Interpretation: because s.7 has no legitimate interests ground, analytics, attribution and marketing processing of personal data that does not fall within s.7(a) would generally need s.6 consent obtained before tracking starts, with withdrawal as easy as giving it. This is reported from AMLEGALS. Whether purely first-party product analytics can rest on s.7(a), data voluntarily provided for a specified purpose, is untested. See consent and legitimate uses.
Are SDK vendors processors or fiduciaries?
Interpretation: an SDK vendor that processes only on the app's instructions fits the Data Processor definition (s.2(k)) and needs a s.8(2) contract. A vendor that also uses the data for its own purposes, such as cross-app profiles or improving its own models, is likely a Data Fiduciary in its own right or jointly with the app. The Act does not address SDKs expressly, and AMLEGALS, while requiring a s.8(2) contract for every processor in the ad stack, does not classify SDK vendors.
Attribution SDKs such as Linkrunner, AppsFlyer, Adjust or Branch process device and event data on the app's behalf. As an example of the configuration choices available, Linkrunner offers PII hashing by default and a Bring Your Own Cloud option that keeps raw events, identifiers and PII inside the app's own cloud boundary. Masking and obfuscation are security measures under Rule 6(1)(a), and the app's own consent, contracts and controls decide its position. See processors and SDKs.
What about deletion, rights and children?
- Interpretation: s.6(6) and s.8(7) imply passing opt-out and deletion signals to attribution, analytics and ad partners acting as processors. For independent fiduciaries, the Act does not expressly require the app to propagate erasure. AMLEGALS flags the lack of a way to honour withdrawal across the ad stack as a risk.
- Interpretation: s.11(1)(b) means an app should be able to name every SDK vendor and partner, fiduciary or processor, with which a given user's data was shared.
- Interpretation: s.9(3) has no exemption for measurement or attribution, so behavioural tracking of users known to be children appears prohibited even with parental consent, unless a Fourth Schedule exemption applies. See children's data.
- Rule 8(3) requires processing logs and associated traffic data to be kept for at least one year, including at processors.
What this means for your app
These are practical steps teams commonly consider. They are not a guarantee of compliance.
- Consider listing every identifier your SDKs collect (advertising ID, device ID, IP address, install referrer, event data) in your Rule 3 notice.
- A common approach is to initialise analytics, attribution and marketing SDKs only after the relevant consent, and to stop them on withdrawal.
- Review vendor terms for use of your users' data for the vendor's own purposes, test how opt-out and deletion reach each vendor, and put s.8(2) contracts in place.
- Consider disabling behavioural tracking for accounts identified as children, and keeping a per-user record of which vendors received data.