TL;DR: The data available for mobile app personalization is shrinking. iOS App Tracking Transparency has reduced cross-app tracking to a fraction of its former scale. GDPR requires explicit consent for any non-essential processing. India's Digital Personal Data Protection Act, now in phased enforcement since November 2025, imposes consent requirements with no legitimate interests exception. User awareness of tracking has raised the bar for what feels acceptable. Teams that treat these constraints as blockers will build personalization systems that are increasingly illegal, technically fragile, or both. Teams that design for them will build personalization systems on first-party and zero-party data that are more accurate, more trusted, and more durable than anything cross-app tracking ever produced.
The mobile advertising ecosystem was built on a foundational assumption: that apps could observe user behaviour across other apps and websites, aggregate that behaviour into detailed profiles, and use those profiles to deliver personalised experiences and targeted advertising without meaningful friction from either users or regulators. For most of the 2010s, that assumption held. The data flowed freely. Personalization was powered by cross-app signal. Attribution was measured at the user level. The system worked, on the terms it was designed for.
The Privacy Shift: What Has Actually Been Removed
Understanding what has changed requires separating the specific capabilities that have been constrained from the broader category of personalization, which remains available and in some respects more powerful than before.
iOS App Tracking Transparency and the IDFA.
Apple's App Tracking Transparency framework, introduced with iOS 14.5 in 2021, converted the Identifier for Advertisers from an opt-out system, where most users were trackable by default, to an opt-in system, where apps must request explicit permission before accessing the IDFA for cross-app or cross-website tracking.
The impact on opt-in rates has been significant and consistent. Prior to ATT, around 70% of users did not exercise the option to opt out of tracking. After ATT, the opt-in picture is reversed. As of Q2 2025, the average ATT opt-in rate across iOS apps was approximately 35%, with apps that present the permission prompt immediately at launch seeing rates as low as 13.85%. Gaming apps have fared better (around 50% opt-in) than non-gaming apps (around 12% for immediate prompts). Apps implementing pre-permission education, which explains the value of personalisation before presenting the system prompt, see 40 to 60% higher ATT acceptance rates than those showing the prompt without context.
What ATT has removed from the toolkit: the ability to link a user's behaviour across different apps and websites without their explicit consent, access to the IDFA as a persistent device-level identifier for cross-app targeting, and the scale of user-level attribution data that powered third-party ad networks. iOS 26 has added a further constraint: advanced fingerprinting protection is now enabled by default, blocking access to device signals commonly used to identify users without IDFA access. The workaround that many teams relied on post-ATT has been shut down.
What ATT has not removed: the ability to observe, measure, and personalise based on user behaviour within your own app. First-party in-app behavioural data is not affected by ATT. A user who declines the ATT prompt is not invisible to your app. They are simply invisible to cross-app tracking. Their behaviour within your app, the screens they visit, the features they use, the actions they complete, is fully available for personalisation purposes, subject to your own privacy policy and applicable regulations.
GDPR's consent requirements.
GDPR, which has been in force in the European Union since 2018, requires a valid lawful basis for any personal data processing. For most personalisation use cases, the applicable lawful basis is consent: explicit, informed, specific, freely given, and as easy to withdraw as to grant. The legitimate interests basis, which some teams have used to justify personalisation without a consent prompt, has been narrowed by regulatory guidance and enforcement. Personal data used for behavioural profiling and personalised marketing is unlikely to qualify for legitimate interests in EU regulatory practice.
What GDPR has constrained: any personalisation that depends on personal data without a documented lawful basis, any cross-device tracking or profile-building based on inferred behaviour without consent, and any data retention beyond the period necessary for the stated purpose. GDPR non-compliance carries fines of up to 4% of global annual turnover, with enforcement actions from data protection authorities across EU member states continuing to increase in volume and size.
What GDPR has not removed: personalisation based on data collected with proper consent and a documented lawful basis, personalisation based on in-session contextual data that does not require persistent personal data processing, and personalisation based on user-provided preference data (zero-party data) collected with clear transparency about its use.
The third-party cookie.
Google's deprecation of third-party cookies in Chrome has been delayed repeatedly, but the trajectory is unambiguous: the cross-site tracking infrastructure built on cookies is being dismantled across the browser ecosystem. For mobile apps, third-party cookies are not directly relevant in the same way they are for web, but the broader signal is clear: data infrastructure built on cross-context tracking without user consent is being progressively removed.
First-Party vs. Zero-Party Data: The Two Sources That Remain
Within the constraints created by ATT, GDPR, and DPDP, two categories of data remain available, unconstrained, and in fact more valuable than before precisely because they are what survives when cross-app tracking is removed.
First-party data is what you observe from user behaviour within your own app. Session events, feature usage, purchase history, content engagement, onboarding completion, support contacts: all of these are first-party signals. You did not need to track users across other apps to obtain them. They were generated in your own product. According to a 2024 Forrester report, leveraging first-party data delivers consistent improvements in marketing effectiveness. A 2023 report by Deloitte found that brands integrating first-party data into their advertising strategies saw an 8x return on marketing spend and a 10% increase in sales.
First-party data in a mobile app is also the most contextually accurate signal available for in-app personalization. A user's behaviour in your app tells you what they actually do in your product, not what they did somewhere else that an algorithm has inferred is relevant to what you offer. According to research, companies that grow faster than their counterparts generate 40% more of their revenue from personalised experiences, and 71% of consumers expect personalised interactions. First-party behavioral signals are the most reliable input for building those personalised experiences.
Zero-party data is what users voluntarily and explicitly share. Zero-party data is personal information that a customer intentionally shares with a business, through onboarding forms, surveys, preference centres, and interest selections. Unlike first-party data, which is observed, zero-party data is declared. The user told you their investment risk preference, their dietary restrictions, their content interests, their communication frequency preference. They made a choice to share it. That choice carries its own trust signal.
Zero-party data offers the most direct insights into customer needs and desires. It also helps enhance trust by showing customers that their preferences and choices matter. Because zero-party data is voluntarily shared, it is also inherently compliant. There is no question of whether consent was obtained because the act of sharing is the consent. Netflix uses self-reported genre preferences to personalise content recommendations. Brands like Ruggable found that conversion rates are four times higher for customers who answered a preference quiz.
The combination of first-party and zero-party data produces a personalisation system that is both more accurate and more durable than one built on third-party or cross-app signals. More accurate because both signal types reflect actual behaviour in or explicit declarations about your specific product. More durable because neither depends on infrastructure that is being legislated or technically closed.
Zero-Party Data Collection in Mobile Apps: How to Collect Without Feeling Invasive
Zero-party data collection fails in one specific way: when it feels like an interrogation. A sequence of 10 questions during onboarding, presented before the user has experienced any product value, is not a preference collection moment. It is a registration barrier. Users who encounter it either abandon the flow or answer randomly to get through it. The data quality is poor. The experience is negative.
Zero-party data collection works when it is timed correctly, limited in scope, and clearly connected to a benefit the user will receive immediately.
Onboarding preference questions. The most effective time for zero-party data collection is not the first screen the user sees. It is after the user has experienced enough of the product to have a stake in personalising it. For a fintech app, that might be after account creation but before showing the dashboard. The question should be immediately connected to the dashboard experience: "What are you primarily using this app for: everyday spending, savings, or investments?" The answer changes what the user sees first. They can feel the connection between what they said and what happened. That immediacy is what makes preference collection feel like a feature rather than data extraction.
Onboarding questionnaires adding smart questions during account creation are a simple method of collecting zero-party data that personalises the customer journey from the start. The design principle: ask one question at a time, not a batch. Frame each question as a choice the user is making about their own experience, not information the app is collecting. "How do you want your home screen to be organised?" reads differently from "What type of user are you?" Both can collect the same underlying information. The first feels like customisation. The second feels like profiling.
In-app surveys for progressive data collection. Preference data collected at onboarding becomes stale as user needs evolve. Digia Engage's in-app survey module places short preference questions in context, after specific actions or at specific lifecycle moments, with a 30% or higher in-app response rate compared to a 3% baseline for email surveys. A user who has been in a savings app for 60 days may have developed a more specific savings goal than the one they selected at onboarding. A well-timed in-app question after their third savings milestone reveals updated intent. That updated intent is more valuable for personalisation than the initial answer, and it was collected at a moment when the user had context and motivation to answer accurately.
Explicit interest selections as ongoing data. Interest selection tools (allow users to mark features, categories, or topics as relevant or irrelevant to them) provide continuous zero-party data without the question-and-answer format. A user who marks "portfolio analysis" as relevant and "cryptocurrency" as not relevant has told the app everything needed to personalise its feature recommendations. The interaction is embedded in the product rather than extracted as a survey. Preference centres that let customers set communication frequency, content preferences, and product categories they care about make collecting zero-party data seamless and keep messaging relevant.
The critical design principle for all zero-party collection: the value exchange must be visible. The user shares a preference and receives, immediately or demonstrably, a more relevant experience. When the value exchange is clear and the benefit is real, users share more. When the value exchange is unclear or the benefit is invisible, even simple questions feel intrusive. The success of collecting zero-party data comes down to transparency. When customers know they will get personalised recommendations, exclusive perks, or improved product suggestions in return, they are far more willing to share.
First-Party Behavioral Data: What You Can Still Track and Why It Is the Strongest Signal
First-party in-app behavioral data is unaffected by ATT. It does not depend on cross-app tracking, third-party cookies, or the IDFA. It is generated every time a user opens your app, navigates a screen, completes an action, or exits a flow. It is the most contextually accurate signal for in-app personalisation because it reflects what the user actually does in your product.
The behavioral signals available to any mobile app without any cross-app tracking:
Session behaviour. Which screens the user visits in each session, in what order, for how long, and at what time of day. This data supports contextual personalisation based on current usage patterns without storing persistent cross-session profiles.
Feature engagement. Which features the user has accessed, how frequently, and with what depth. A user who accesses the portfolio analysis feature in a fintech app three times per week has demonstrated a signal about their primary use case that no survey answer can match in reliability.
Conversion events. Completed purchases, transactions, form submissions, milestone achievements: these are the highest-signal first-party events because they represent the actions the user chose to take, not just screens they happened to visit.
Content engagement. For content apps: which articles, videos, or topics the user engaged with, for how long, and whether they completed or exited. This data can power content recommendations based on observed behaviour in your app without touching any cross-app or external data.
Lifecycle stage. Where the user is in the product journey: new, activated, retained, at-risk. First-party event history is the most reliable input for lifecycle stage classification.
Consistent field naming, consent tagging, and ingestion cadence are prerequisites before any downstream personalisation strategies can succeed. The first-party data advantage is only realisable when the data layer is clean: correctly instrumented events, consistent naming, resolved user identity, and freshness within the thresholds required for each personalisation use case. For teams that have done this work, first-party behavioural data is a durable, regulation-proof foundation for personalisation that outperforms third-party data in contextual accuracy.
Users who actively opt in to data sharing provide higher-quality, more reliable data than data inferred through third-party tracking. Even setting aside the regulatory and infrastructure advantages, first-party data that reflects actual in-product behaviour is simply a better personalisation input than cross-app inference. The user who completes a transaction in your fintech app has given you a first-party signal of far higher quality than any inferred propensity score built from cross-app behaviour.
Consent-Based Personalization: Making It Opt-In and Framing the Value Exchange
Consent-based personalisation is personalisation that users explicitly activate, adjust, or deactivate. It is not the default on/off binary of ATT prompts. It is an in-product architecture where personalisation features are presented as something users can turn on and configure, with a transparent explanation of what each feature does and what data it uses.
The framing shift is significant: from "we are personalising your experience based on our data collection" to "you can personalise your experience by telling us more about what you want." The first framing positions the app as the actor and the user as the subject. The second positions the user as the author of their own experience. Both can produce the same personalised outcome. The second consistently produces higher opt-in rates, stronger long-term retention, and better data quality.
According to Cisco research, 81% of users say the way a company treats their personal data is an indicator of how it views them as a customer. A McKinsey report found that 87% of respondents said they would stop doing business with a company that gave away sensitive data without permission. The value exchange between user data and personalised experience is not just a legal requirement. It is a trust mechanism that determines whether users stay.
Companies implementing comprehensive consent optimisation strategies demonstrate significant improvements in customer lifetime value through enhanced personalisation, more accurate attribution modelling across marketing channels, and improved marketing ROI through complete funnel visibility. Organisations with optimised consent experiences report 40 to 60% better data completeness compared to those using default banner implementations.
The practical implementation of consent-based personalisation in a mobile app:
A personalisation preference centre. A screen, accessible from account settings, where users can see exactly what the app personalises, what data each personalisation feature uses, and how to turn each feature on or off. This is not a privacy policy page. It is a product settings page that happens to relate to data use. The difference in framing matters enormously: users who engage with a "personalisation settings" page are making product choices. Users who are directed to a "privacy policy" are reading legal text.
Progressive disclosure of personalisation features. Rather than activating all personalisation at once, surface personalisation features at relevant moments. A user who has completed their third investment in a fintech app is the right moment to surface "personalised portfolio insights based on your investment history." The user has enough history for the feature to have value and enough context to understand what "personalised" means in this specific case.
Explicit explanations at the point of personalisation. When a personalised recommendation or adapted interface appears, include a brief, visible explanation. "Based on your savings goal" or "because you frequently use portfolio analysis" makes the personalisation legible. Users who understand why they see what they see are more comfortable with the personalisation than users who receive identically accurate recommendations with no visible reasoning. Transparent personalisation that shows its reasoning is more trusted, more effective, and less likely to trigger the creepiness response than equivalent personalisation without explanation.
Contextual Personalization: The Privacy-Safe Default
Contextual personalisation is the most underused mechanism in mobile personalisation strategy. It requires no stored behavioural profile, no persistent user identifier, no cross-session data accumulation. It adapts the experience based on what is observable in the current session: what screen the user is on, what action they just completed, what time of day it is, what the user's device state is.
Examples of contextual personalisation that require no persistent data:
A fintech app that shows a transaction summary widget when the user opens the app after completing a payment in the same session. The widget appears because of the session action, not because of a stored behaviour profile.
A content app that surfaces long-form articles when the user opens the app on a weekend morning and short-form content when they open it on a weekday at noon. The adaptation is based on time context available in the current session without any historical data.
An e-commerce app that shows recently viewed product categories (within the current session) prominently when the user returns to the home screen mid-session. The signal is the current session's navigation history, not a stored cross-session profile.
Contextual signals like current screen, action just completed, and time of day can refine the experience without requiring persistent data about the user. The experience feels personalised because it is responsive to the user's current context. The user does not need to have consented to behavioural profiling for the app to surface content relevant to what they are doing right now.
Contextual personalisation also avoids the staleness problem that affects stored profile personalisation. A stored profile reflects past behaviour. A contextual adaptation reflects present behaviour. For many personalisation use cases, present behaviour is the more relevant signal: what the user is doing now is the best predictor of what they want to see next, not what they did three weeks ago.
On-device processing is an adjacent approach that enables more sophisticated contextual personalisation without sending personal data to external systems. ContextSDK, which performs context analysis on-device without collecting or storing personally identifiable information, demonstrates that high-quality personalisation signals can be generated without persistent data collection. The processing happens locally. The signal stays on the device. No personal data transits to a server. This architecture is naturally compliant with both ATT and GDPR because it does not involve the data flows that those frameworks regulate.
Regulatory Compliance in Practice: GDPR, ATT, and India's DPDP Act
Understanding what each framework actually requires for mobile app personalisation, as distinct from what is generally discussed about each framework, is necessary for building a compliant personalisation architecture.
GDPR in practice for mobile personalisation.
GDPR requires a lawful basis for any personal data processing. For personalisation that involves personal data (user ID, behaviour events associated with an identified user, preference data), the relevant basis is typically consent or legitimate interests. The legitimate interests basis is increasingly narrow for personalisation: the Article 29 Working Party guidance and subsequent enforcement have indicated that personalised advertising and profiling typically require consent, not just a legitimate interests assessment.
In practice, this means: any personalisation that creates or uses a behavioural profile of an identifiable user requires a consent mechanism, with the right to withdraw as simple as the act of consenting, and personalisation must be scoped to the purposes disclosed when consent was obtained. Personalisation based on zero-party data voluntarily shared by the user is the most straightforwardly compliant form because the act of sharing is itself the consent.
GDPR also requires data minimisation: collect only data necessary for the stated purpose. A personalisation system that collects 200 event types when 15 would suffice is in tension with data minimisation, even if all collection is individually consented. Building a lean, purposeful event taxonomy (as covered in the data foundation article) is not just a data quality practice. It is a GDPR compliance practice.
iOS ATT in practice.
ATT applies specifically to cross-app and cross-website tracking and access to the IDFA. It does not apply to in-app analytics or personalisation based on in-app behaviour. Apps that never access the IDFA, never link data across apps, and never share data with third parties for tracking purposes are not subject to ATT prompts. For teams whose personalisation is entirely first-party and in-app, ATT is architecturally irrelevant.
For teams using third-party analytics SDKs that access device-level identifiers, ATT applies to the SDK's data practices. Since May 2024, Privacy Manifest compliance has been mandatory for all App Store submissions. Developers must declare all data types collected, justify API usage, and disclose third-party SDKs with data access capabilities. Inconsistencies between declared practices and actual behaviour result in App Store rejection.
When the ATT prompt is necessary, timing and framing matter significantly. Apps implementing pre-prompt education see 40 to 60% higher ATT acceptance rates. Show the prompt after the user has experienced value, not at first launch. Customise the purpose string to explain specifically what personalisation the user is enabling, not a generic tracking statement.
India's Digital Personal Data Protection Act in practice.
India's DPDP Act is now in phased enforcement. Phase 1 (the Data Protection Board of India established) has been active since November 2025. Phase 2 (consent manager registration) activates November 2026. Phase 3 (full substantive obligations) activates May 2027. However, enforcement actions were initiated in Q1 2026 against several app developers found to be processing data without valid consent, so preparation cannot wait for Phase 3.
The DPDP Act has a critical structural difference from GDPR: there is no legitimate interests lawful basis. Under GDPR, some data processing can proceed without explicit consent if it passes a legitimate interests balancing test. Under the DPDP Act, if you process personal data of Indian users, you need consent. Period. Consent must be free, specific, informed, unconditional, and unambiguous, given by clear affirmative action. It must be granular per purpose. Withdrawal must be as easy as giving consent. Pre-ticked boxes, bundled consent, and consent inferred from continued use are not valid.
The practical implications for Indian mobile apps:
No conditional consent. You cannot make app access conditional on consent for personalisation-related data processing. A consent flow that says "agree to our data practices or you cannot use the app" is explicitly non-compliant under the DPDP Act.
Granular consent per purpose. A user can consent to processing for core product functionality while declining processing for personalised recommendations. Your consent architecture must support this granularity.
7-day erasure window. When a user withdraws consent, the DPDP Act requires data erasure within 7 days, compared to approximately 30 days under GDPR. This has implications for data retention architecture and the time window within which personalisation can continue to operate after consent withdrawal.
Children under 18 require verifiable parental consent. GDPR defines children as under 13 to 16 depending on member state. The DPDP Act defines children as under 18, with no lower threshold. Any app with Indian users that could plausibly include users under 18 must implement verifiable age verification and parental consent for data processing.
Penalties. Up to Rs 250 crore (approximately USD 30 million) for security safeguard failures. Up to Rs 200 crore for processing without consent or for children's data violations. These are fixed amounts, not percentages of turnover, which means they are as significant for small apps as for large ones.
Notices in Indian languages. Privacy notices and consent requests must be available in at least one of the 22 scheduled Indian languages, in addition to English. For apps with large regional user bases, this requires localised consent flows, not just English translations.
The Pre-Permission Moment: Designing Consent Experiences That Users Actually Accept
The ATT prompt and the DPDP consent notice are moments in the product experience, not legal formalities to be minimised. Teams that treat them as obstacles to be minimised produce the lowest opt-in rates. Teams that treat them as design moments, where the value of data sharing is communicated clearly and the user's choice is respected either way, produce measurably higher opt-in rates and stronger long-term trust.
The pre-permission education screen, shown before the system ATT prompt, is the highest-leverage intervention available for improving opt-in rates. Apps implementing pre-permission education see 40 to 60% higher ATT acceptance rates compared to immediate system prompts. Effective pre-permission education: explains what the user is about to be asked, connects the data use to a specific benefit the user will experience, uses plain language at an eighth-grade reading level, and does not pressure or manipulate. The goal is informed consent, not maximum consent. Users who understand what they are consenting to and choose to consent are more valuable, both as data sources and as long-term users, than users who consent without understanding.
The framing of consent requests matters at the word level. The ATT prompt's language "allow app to track your activity across other companies' apps and websites" intentionally signals cross-context tracking. The custom purpose string you add to the prompt is the place where the value proposition for consent lives. "Allow [App] to personalise your investment recommendations based on your activity" is a materially different frame than the default language. The personalisation benefit is specific. The scope is bounded to your app's context. Users who see personalisation as the purpose of consent are more likely to accept than users who see tracking as the purpose.
Under DPDP, the consent notice must state an itemised description of all personal data being processed, the purposes of processing, and the rights the user has. The notice must be presented before any data processing begins, in language the user can understand. This is not a checkbox at the bottom of a terms and conditions page. It is a dedicated notice, presented at an appropriate moment in the onboarding or product flow, that gives users genuine information about what they are agreeing to.
Trust as a Competitive Advantage: The Retention Evidence
The argument that privacy-first personalisation is not just a compliance exercise but a competitive strategy rests on measurable evidence, not on a values claim. The data is clear and consistent: users who trust how an app handles their data stay longer, engage more deeply, and refer more.
According to Cisco research, 81% of users say the way a company treats their personal data is an indicator of how it views them as a customer. This is not a privacy question. It is a relationship question. Users who trust the app's data practices are users who trust the app. Users who do not trust the data practices have a fundamental doubt about the product that will eventually express itself in disengagement or churn.
87% of respondents in McKinsey research said they would stop doing business with a company that gave away sensitive data without permission. A 2024 Forrester report found consistent improvements in marketing effectiveness from first-party data use, including higher open rates, better conversion rates, and lower acquisition costs. These improvements are downstream of the trust relationship that transparent, consent-based data practices build over time.
The mechanism is straightforward. Users who opted into personalisation as a deliberate choice are more engaged with personalised content than users who are passively subject to personalisation they may not know about. The act of opting in creates engagement. The user is invested in the personalisation working because they chose it. When the personalisation delivers relevance, it confirms the user's choice. That confirmation builds trust. Trust drives retention.
Transparent personalisation that explains its reasoning, presenting recommendations with visible context about the data signal behind them, is more effective and less likely to trigger the privacy concern that damages trust. The research consistently finds that perceived fairness in data use is a stronger predictor of continued engagement than personalisation accuracy alone. A user who receives a slightly less accurate recommendation but understands why they received it is more likely to remain engaged than a user who receives a highly accurate recommendation with no visible reasoning and begins to wonder how the system knew.
The competitive advantage is structural. Apps that have built personalisation on first-party and zero-party data, with consent-based architecture and transparent framing, are not affected by additional ATT restrictions, GDPR enforcement actions, or DPDP compliance requirements. Their personalisation system does not depend on data flows that regulation is closing. It depends on data that regulation explicitly protects: data that users chose to share, for purposes they understood, with the ability to withdraw at any moment.
How Digia Engage Supports Privacy-First Personalization
Digia Engage's in-app nudge and widget system fires on real-time in-app events, which means its personalisation is entirely first-party by architecture. No cross-app tracking is required. No third-party data integration is necessary. The events that trigger nudges and adapt widgets are generated within your app, processed within your app's data layer, and used to deliver in-app experiences without leaving the first-party data environment.
The survey module enables zero-party data collection at high-signal moments in the app session, with a 30% or higher in-app response rate. Preference data collected through Digia Engage surveys is voluntary, explicitly provided, and immediately connected to the personalisation experience it informs. This is zero-party data collected in the most compliant possible form: the user chose to answer, understood the purpose, and immediately experienced the benefit.
In-app widgets adapt content within stable structural templates, which means the personalisation affects what users see within consistent layouts, not the navigation or core flows. This approach avoids the structural personalisation that breaks mental models while delivering the content relevance that drives engagement.
Campaigns built in Digia Engage are deployed without app releases, which means consent and personalisation experiences can be iterated on the same timeline as the legal and regulatory landscape. When a consent requirement changes, the in-app experience that presents and manages that consent can be updated without waiting for an App Store review cycle.
The integration with CleverTap, MoEngage, and WebEngage means that the consent and preference data managed in those platforms flows directly into Digia Engage's personalisation logic. A user who withdrew consent for personalisation in CleverTap does not continue to receive personalised nudges from Digia Engage because the segment exclusion propagates through the integration.
Topics Not in the Brief That Teams Should Know
The pre-prompt design problem. Most teams treat the ATT prompt as a system event they have no control over. They do. The custom purpose string in the ATT prompt, the timing of when the prompt appears, and the pre-prompt educational screen are all controllable design elements. Apps showing ATT prompts after delivering value, rather than at first launch, see significantly higher opt-in rates. The difference between a 13% opt-in rate and a 35% opt-in rate is often not the user base. It is when and how the prompt was shown.
Consent portability under DPDP. The DPDP Act's Consent Manager framework, active from November 2026, introduces a new concept for the Indian market: users can manage their consents across multiple apps through a registered Consent Manager. This means a user's consent record with your app may be managed through a third-party intermediary. Apps need to build technical integration with Consent Manager infrastructure before Phase 3 enforcement begins in May 2027.
Children's data is a compliance priority for Indian apps. The DPDP Act defines children as under 18. Any app available on the Indian App Store or Play Store with no age restriction is an app that may have under-18 users. Processing their personal data without verifiable parental consent is a compliance violation. This is not a theoretical risk. The first DPDP enforcement actions in Q1 2026 included children's data violations.
The data minimisation advantage. Privacy-first personalization, because it depends on first-party and zero-party data rather than maximum data collection, is naturally aligned with data minimisation requirements under both GDPR and DPDP. A lean event taxonomy with 15 core events collects less personal data, requires less consent management infrastructure, and reduces the surface area of compliance risk compared to a schema with 150 events instrumenting every possible user interaction. The compliance advantage of doing less, but doing it better, is underappreciated.
Server-side tracking as a privacy-ambiguous workaround. Some teams have moved to server-side event processing as a way to continue collecting behavioural data without client-side tracking restrictions. Apple's October 2024 compliance report found that 43% of Meta's iOS behavioural data is now collected server-side, bypassing ATT entirely. Server-side processing does not remove GDPR or DPDP obligations. The legal basis requirement for personal data processing applies regardless of whether the collection happens on the device or on a server. Teams treating server-side tracking as a compliance workaround are misreading the regulatory framework.
Key Takeaways
iOS ATT has reduced cross-app tracking to a fraction of its former scale, with average opt-in rates around 35% and fingerprinting protections in iOS 26 closing the remaining workaround. What has not been removed is first-party in-app behavioural data, which is unaffected by ATT.
GDPR requires a lawful basis for any personal data processing. For personalisation involving behavioural profiling, consent is the operative basis in most EU regulatory practice. Legitimate interests is an increasingly narrow argument for personalisation.
India's DPDP Act, in phased enforcement since November 2025 with full obligations from May 2027, has no legitimate interests basis. Consent is required for all personal data processing. Consent must be granular per purpose, freely given, and withdrawable as easily as it was granted.
First-party data is what you observe from user behaviour within your own app. Zero-party data is what users voluntarily share. Both are regulation-proof, increasingly valuable, and more accurate for in-app personalisation than cross-app inference.
Zero-party data collection works when timed after the user has experienced product value, limited to one question at a time, and directly connected to a visible benefit. Onboarding preference questions, in-app surveys, and interest selection tools are the three primary collection mechanisms.
Contextual personalisation adapts the experience based on the current session without requiring stored behavioural profiles. It is the most privacy-safe personalisation approach because no persistent personal data is required, and it is often the most accurate because it reflects present rather than past behaviour.
Consent-based personalisation, framed as a user choice rather than a system behaviour, produces higher opt-in rates, better data quality, and stronger long-term retention than covert collection. Users who opted in as a deliberate choice are more engaged with personalised content than users who are passively subject to it.
Trust is a competitive advantage that compounds over time. Apps that have built personalisation on first-party and zero-party data with transparent framing are not affected by additional regulatory restrictions on cross-app tracking. Their personalisation system is on the right side of the direction of travel.
Further Reading
From Digia Engage:
- Over-Personalization: When Too Much Adaptation Makes the App Feel Unreliable — the complement to this article: what happens when personalisation goes too far in the other direction
- The Data Foundation: What You Need to Clean Up Before Personalization Can Work — building the first-party data layer that makes privacy-first personalisation possible
- When NOT to Show a Nudge: Building a Suppression Logic — how suppression logic prevents personalised nudges from firing in the wrong context
- Digia Engage Surveys — in-app zero-party data collection with 30%+ response rates
- Digia Engage Nudges — event-based personalisation that is entirely first-party by architecture
- Digia Engage CleverTap Integration — connecting CleverTap's consent and segment data to Digia Engage personalisation
- Digia Engage MoEngage Integration — syncing MoEngage consent records to Digia Engage campaign logic
External Sources:
- App Tracking Transparency 2026: ATT Status and SDK Fix — Respectlytics (iOS 26 fingerprinting protections, session-based analytics that avoid ATT entirely, ATT and GDPR interaction)
- ATT Opt-In Rates in 2025 and How to Increase Them — Purchasely (13.85% immediate opt-in rate, gaming vs. non-gaming breakdown, value of pre-permission framing)
- Mobile App Consent for iOS: A Deep Dive 2025 — Secure Privacy (40 to 60% higher acceptance with pre-prompt education; Privacy Manifest compliance requirements)
- App Tracking Transparency: AppsFlyer Mobile Glossary — AppsFlyer (full history of ATT, IDFA, opt-in mechanics, and prompt timing strategies)
- India DPDP Act for Mobile Apps: Compliance Deadlines, Penalties, and What Developers Must Do Now — Respectlytics (no legitimate interests basis, 7-day erasure window, children defined as under 18, Rs 250 crore penalties)
- India DPDP Act 2026: Compliance Reality for App Developers — Make An App Like (enforcement actions in Q1 2026, specific consent requirements, cross-border transfer status)
- India Digital Personal Data Protection Act: Comprehensive Compliance Guide 2026 — Atlas Systems (full DPDP obligations: lawful basis, purpose limitation, data minimisation, transparency requirements)
- Digital Personal Data Protection Rules 2025 — CookieYes (phased enforcement timeline: November 2025, November 2026, May 2027)
- Zero-Party Data vs First-Party Data: A Complete Guide for 2025 — RedTrack (preference centres, onboarding questionnaires, poll and survey mechanics for zero-party collection)
- Zero-Party Data vs First-Party Data: What's the Difference? — Transcend (90% of businesses believe personalization is crucial; how zero-party and first-party data combine for compliant profiles)
- Zero-Party Data vs First-Party Data — Shopify (Ruggable's 4x conversion rate from preference quiz; 81% of consumers still prefer personalised experiences)
- Zero-Party vs First-Party Data: Moving Beyond Collection to Value Creation — mParticle (reconciling stated preferences with observed behaviour for accurate personalisation)
- What Is Consent Management? Complete Guide for Businesses 2026 — Enzuzo (Cisco: 81% of users judge companies by data treatment; McKinsey: 87% would stop business with companies misusing sensitive data)
- 2026 and Beyond: Powering Enterprise Growth with Consent and Preference Management — Transcend (Deloitte: 8x return on marketing spend from first-party data; McKinsey: companies with personalisation generate 40% more revenue)
- Consent Conversion Rate Optimisation: Complete Guide — Secure Privacy (40 to 60% better data completeness from optimised consent; consent management market growing to $1.4 billion by 2035)
- Personalization Strategies for Media Companies — Databricks (consistent field naming and consent tagging as prerequisites before downstream personalisation strategies can succeed)
- Privacy-Focused Personalization for Social Media Apps — ContextSDK (on-device personalisation without PII collection; context-aware engagement without persistent data)
Privacy-first personalisation built on first-party event data and zero-party preference data is exactly what Digia Engage's architecture supports. In-app triggers fire on events from your own app. Surveys collect explicit user preferences in context. Widgets adapt content without storing cross-session behavioural profiles. Book a demo to see how the system works within your existing CleverTap, MoEngage, or WebEngage data layer, or read the integration documentation for the technical architecture of each connection.
