--- title: What consent do I need to get from my app users? description: Learn when and how to ask app users for consent, what the law requires, and how your approach to data requests affects trust, sign-ups and retention. image: https://weareaffective.com/hubfs/learning-centre-images/what-consent-do-i-need-to-get-from-my-app-users.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-consent-do-i-need-to-get-from-my-app-users#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What consent do I need to get from my app users? Table of Contents Consent in apps is the first real signal your product sends about how it treats people. The moment you ask a user for something, whether that is their email address, their location, or access to their camera, you are asking them to trust you. How you frame that ask, and when you make it, shapes whether they feel respected or surveilled. Get it wrong and people leave. Get it right and they stay, engage, and come back. > The moment you ask for something, you are asking for trust, and how you frame that ask shapes whether people feel respected or surveilled. The question teams usually ask is: what are we legally required to collect? That is the wrong starting point. The more useful question is: what do we need, at which moment, and how do we ask for it in a way that feels proportionate? Legal compliance sets the floor. Good consent design determines whether your product earns a relationship or just a grudging click. This article covers both: the legal baseline and the behavioural reality of how people respond to data requests. We draw on work across fitness apps, marketplace platforms, residential concierge products, and anonymous messaging tools, and the patterns that emerge from that work are consistent. Consent is a design problem, and it deserves the same care as any other part of the experience. ## The legal baseline: what consent the law actually requires Under GDPR, which governs apps used by anyone in the UK or EU, consent must be freely given, specific, informed, and unambiguous. That means you cannot bundle data requests together and have users agree to everything at once. You cannot pre-tick boxes. You cannot make access to the product conditional on accepting optional data processing that is not necessary for the service to function. On mobile, Apple and Google add platform-level requirements on top of that. iOS requires explicit runtime permission prompts for camera, microphone, location, contacts, and health data. Android requires similar declarations, and since Android 11, permissions left unused for extended periods are revoked automatically. Neither platform will approve an app that collects data without a clear stated purpose. #### What counts as necessary processing Necessary data collection, which does not require consent under the same conditions, covers what the product literally cannot function without. A navigation app needs location data. A payment feature needs billing details. What falls outside necessity is marketing analytics, behavioural tracking, third-party data sharing, and any processing that benefits you rather than the user. Those require separate, explicit consent, and users must be able to withdraw it without losing the core service. #### Legitimate interest is not a shortcut Legitimate interest is sometimes misread as a way around consent requirements. It is not. The bar requires a genuine balance of interests, a proportionality test, and a clear opt-out. For most consumer lifestyle apps, relying on legitimate interest for personal data processing is risky. Consent, collected properly and at the right moment, is the cleaner and more defensible basis. ## When to ask: sequencing consent around value, not process The most common consent mistake is asking too early. A user opens an app for the first time and is immediately presented with a [push notification permission prompt](https://weareaffective.com/learning-centre/how-do-i-write-push-notification-messages-that-users-actually-read) before they have seen a single screen of content. From a product logic standpoint, the team wanted to capture notification opt-ins at the highest possible point in the funnel. From the user's standpoint, a stranger just asked for their attention before explaining what they are offering. Most people decline, and once declined, permission prompts on iOS cannot be re-triggered without the user going into settings manually. We think about this as [narrative onboarding rather than data collection onboarding](https://weareaffective.com/app-onboarding-design). Show people what the product does and why it matters to them before asking for anything. On a gifting platform and a sports second-hand marketplace we worked on, we deferred login until later in the flow, allowing users to browse, explore, and experience value before committing to an account. Sign-up rates were consistently higher because people arrived at the registration moment already invested in the product. The sequence that works is straightforward. Value first, then the request that helps you deliver more of it, then the explanation of why the data matters. Not the other way round. ## UX/UI design built around *real* psychology We design app interfaces around how people actually think and behave. User research, psychology-driven UX/UI design and technical specs delivered as one complete package. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## How much to ask for: matching data requests to the moment On an auction game product we worked on, we built a tiered registration model with multiple levels of authentication triggered by user actions rather than front-loaded as a blanket requirement. Watching or favouriting an auction required only a basic account, a name and email or phone number. Actually playing a game and winning real money required elevated verification, including age confirmation and a payment method on file. We only asked for additional data at the exact moment the product functionality required it. This approach reflects a simple principle: the data request should match the stakes of the action the user is about to take. Asking for a full ID upload before someone has placed a single bid is disproportionate and creates unnecessary friction at the exact moment you want users to feel excited and willing to engage. > Data requests should match the stakes of the action, not the preferences of the product team. The tiered model also distributes the cognitive weight of consent across the journey, rather than front-loading it into a wall of permission prompts. Users feel each request is logical because it follows naturally from what they are trying to do. The table below shows how this looks in practice. | User action | Data required | Verification level | | --- | --- | --- | | Browsing or favouriting | None | Guest | | Saving or following | Name and email or phone | Basic account | | Bidding or purchasing | Age confirmation and payment method | Elevated verification | Audit every data request in your onboarding against the question: what does this make possible for the user right now? If the answer is nothing yet, move the request to where it becomes relevant. ## High-stakes disclosures: location, identity, and financial data Location data sits in a different category to most other permissions. Research published on arXiv in 2025 found that 57% of participants were surprised by the extent of information that could be inferred from their location data after seeing a visualisation of their own traces, and 54% had underestimated how many applications they had already granted location access to ([Boutet and Morel, arXiv, 2025](https://arxiv.org/abs/2502.11658v1)). People share location more casually than they realise, and that gap between habit and awareness is where trust breaks down when something goes wrong. On [a fitness social app we worked on](https://weareaffective.com/learning-centre/what-a-fitness-social-app-changed-when-it-realised-precise-location-was-the-wron), the original design showed users' real-time locations on a map so people could find workout partners nearby. Research revealed that a high proportion of users were female, making precise location sharing a significant security concern. We fundamentally redesigned the feature to replace precise location with a randomised offset, showing only that a potential running partner was within a rough area, perhaps 200 to 500 metres, without revealing their exact position. #### Sequencing disclosure to build confidence After seeing the approximate location, users could view a profile and start a conversation before choosing to share their precise location and arrange a meetup. This [opt-in sequence preserved the core value](https://weareaffective.com/learning-centre/what-makes-users-trust-a-product-enough-to-enter-their-card-details), enough proximity data to judge whether a meetup was feasible, while giving users control over when they stepped up to higher-stakes disclosure. The feature worked better than the original design precisely because it respected the progression from lower to higher trust. For location, identity, and financial data, always give users a preview of value before the high-stakes ask. Let them decide to proceed rather than requiring disclosure before they know why it matters. #### Financial data and identity verification Payment data and identity documents carry the highest weight. Users approach these requests with the most scrutiny and abandon flows at the highest rates when the timing or framing feels wrong. Whatever verification is required, the design job is to make the reason obvious, the process fast, and the moment logical within the user's journey. ## When the law overrides good UX: safety and authentication exceptions There are situations where legal or safety requirements mean you cannot defer authentication or soften a data request. The principle of value-first, then consent, is a design default, not an absolute. Knowing when to override it matters as much as knowing when to apply it. On an anonymous messaging app we worked on, we had to put authentication right upfront. The product allowed anonymous messaging, but we needed to tie messages back to specific users on the back end for legal reasons, specifically to handle cases of abuse or harassment. Allowing people into the product and letting them send messages before we could identify them created an unacceptable legal exposure. The authentication requirement came before any value was shown, because the law required it and safety demanded it. #### Age verification as a legal floor Age-restricted products face similar constraints. A product selling alcohol, gambling services, or adult content cannot simply defer age verification until after the user has experienced value. The verification gate is a legal requirement, and the design task is to make the process as clear and fast as possible rather than to remove it. Moving the verification moment from pre-registration to post-first-value creates a drop-off risk of its own: users who have already engaged are more willing to complete verification than users who have seen nothing yet, but this only applies where the product category legally permits access before verification. The honest position is this: some consent and authentication requirements exist because the alternative creates harm, not just friction. Design works within that, not around it. ## How you ask: framing that signals respect rather than surveillance The wording of a consent request changes how people respond to it, even when the technical outcome is identical. Telling a user "we need access to your location" feels like a demand. Asking "is it okay if we use your location to show nearby options?" feels like a conversation. The data collected is the same. The psychological experience is not. Shifting from declarative to permissive framing, from "we require" to "can we", makes users feel they are in control of what they share. People who feel in control are more willing to share, more likely to engage with the product over time, and more likely to return. This is a fundamental change in the relationship the product proposes to have with its users. 1. State what you are asking for and why in plain language. 2. Frame the request as a question, not a requirement. 3. Explain what the user gets in return for sharing the data. 4. Make declining easy and consequence-free where the data is not essential. 5. Confirm what happens after they agree, and give a clear path to change their mind. Read your consent copy aloud. If it sounds like a terms-and-conditions extract rather than a sentence a person would say, rewrite it until it does. A useful internal test: if you had to tell users exactly what you were doing with their data and why, would they still agree? If the answer is no, the framing is obscuring the true purpose. The right response is to change the purpose, not to polish the language until it hides it better. ## What happens when you get it wrong: drop-off, distrust, and abandonment The cost of poor consent design is not hypothetical. Six in ten users report abandoning an app installation after discovering excessive data requirements, and only about 34% of background permission requests are expected by users, making background data collection a significant source of discomfort ([eSpincorp](https://www.e-spincorp.com/user-consent-and-transparency-in-mobile-apps-what-you-need-to-know/)). When a request feels disproportionate or poorly timed, users do not debate it. They leave, and they rarely return. Drop-off at consent moments tends to cluster around three patterns. Asking for data before demonstrating value, so the user has no reason to trust the exchange. Asking for more data than the current action requires, so the request feels invasive rather than logical. And asking in a way that sounds like a demand rather than a question, so the user feels processed rather than respected. #### Distrust compounds over time A user who accepts a consent request but felt uncomfortable doing so carries that discomfort into their subsequent use of the product. It surfaces as lower engagement, lower willingness to share further, and a stronger reaction the next time a permission prompt appears. Consent experiences that feel extractive at the start tend to produce suspicious users throughout the product lifecycle. #### Withdrawal and settings behaviour Users who feel their data is being used in ways they did not fully understand tend to revisit their settings and revoke permissions. This is a signal that the consent moment failed to clearly communicate what they were agreeing to. Clear, honest framing at the point of consent reduces the likelihood of later withdrawal, which matters because regranted permissions on iOS require the user to navigate there themselves. ## Conclusion Consent design is where legal compliance and behavioural psychology meet, and the gap between them is where most products lose people. The law tells you what you must collect, what you must disclose, and what requires explicit agreement. Behavioural reality tells you that even compliant consent flows can feel coercive if the timing is wrong, the ask is disproportionate, or the framing is transactional rather than respectful. The consistent thread across the products we have worked on, from the fitness social app with its location sequencing to the auction platform with its tiered authentication to the anonymous messaging product where legal requirements meant authentication had to come first, is that consent works best when it is treated as a relationship moment rather than a data capture event. What are you asking for, why does the user benefit, and is this the right moment to ask? Getting those three things right does not require a complete product redesign. The most immediate change any team can make is switching from declarative language to permissive framing across every data request in the product. That single shift, from telling to asking, changes how users experience the relationship the product is proposing. Everything else follows from that. If you are building or reviewing a product and want to think through where your consent moments are creating friction or distrust, [let's talk about your consent design](https://weareaffective.com/get-started). ## Frequently Asked Questions What does the law require when collecting consent from app users? Under GDPR, consent must be freely given, specific, informed, and unambiguous. You cannot bundle data requests together, use pre-ticked boxes, or make access to your app conditional on users accepting optional data processing that is not necessary for the service to function. Do Apple and Google have their own consent requirements on top of GDPR? Yes, both platforms add requirements beyond the legal baseline. iOS requires explicit runtime permission prompts for camera, microphone, location, contacts, and health data, and neither platform will approve an app that collects data without a clearly stated purpose. What data can I collect without asking for consent? You can collect data without consent only when it is strictly necessary for the product to function, for example location data in a navigation app or billing details for a payment feature. Marketing analytics, behavioural tracking, and third-party data sharing all fall outside necessity and require separate, explicit consent. Can I rely on legitimate interest instead of collecting consent? Legitimate interest is not a straightforward alternative to consent. It requires a genuine balance of interests, a proportionality test, and a clear opt-out, and for most consumer lifestyle apps it is a risky basis for personal data processing. When is the right moment to ask users for permissions? The most common mistake is asking too early, before users have seen what your app offers or understood its value. Consent requests perform better when they are sequenced around value, meaning you ask at the moment the user is most likely to understand why the permission is useful to them. What happens if a user declines a permission request? On most platforms, once a user declines a permission, it is very difficult to surface the prompt again, making early or poorly timed requests costly. Designing consent around the right moment reduces the likelihood of refusal and helps preserve the relationship with the user. Can I withdraw core app features if a user refuses optional data processing? No. Users must be able to withdraw consent for optional data processing without losing access to the core service. Making the main product conditional on accepting non-essential data collection is not permitted under GDPR. Is consent purely a legal concern, or does it affect how users experience my product? Consent is as much a design problem as a legal one. How you frame a data request and when you make it shapes whether users feel respected or surveilled, which directly affects whether they stay, engage, and return to your app. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.