Mobile Consent Management

Modern privacy laws are generally platform agnostic - they require companies to honor user rights regardless of the device or platform they are using. Because of this, it is important to ensure your company has a solution in place to capture, honor, and sync user preferences (like consent for processing or Do Not Sell/Share opt-outs) for your mobile applications.

Managing consent in a mobile application is different in several ways from handling consent on a website. Generally speaking, mobile applications have different and fewer tracking technologies and more rigid UI constraints - pop-up banners are even less desirable in the limited real estate of mobile apps than on websites. Cookies are not a concept in mobile applications, and instead most data sharing occurs via backend-based tracking calls or directly through third-party SDKs installed in the application.

In short, supporting mobile application consent will require the following:

  • Providing an interface for users to opt in and out of the relevant consent purposes for their region.
  • Enforcing user consent by ensuring first and third party data practices are modified in response to user consent decisions. This may involve stopping or modifying data collection or sharing.
  • Syncing consent preferences for the same user across multiple devices.

This guide will walk you through the high-level steps to adding a mobile consent experience for your app. The process involves selecting a consent management interface, setting up storage of consent preferences, ensuring SDKs are identified and regulated based on user preferences, and, if needed, using consent change events to trigger subsequent backend workflows.

For additional reading about handling consent preferences for anonymous and authenticated users across multiple devices and websites, see our documentation on Full Stack Consent Management.

Adding consent interfaces for users of your applications may take one or more forms depending on your design needs and the applicable regulations.

You can collect consent using a Transcend-provided UI served by our iOS or Android SDK directly in the application.

This is the most turnkey option, and is especially useful for more complex UIs like IAB’s TCF interface. To have Transcend provide the UI for users you’ll add our Consent SDK into your application. Our SDK will then handle triggering the UI for consent collection as well as setting, syncing, and governing collected consent preferences.

This is a good option for maximum control of the user interface and when seamlessly embedding privacy controls into existing workflows (like a welcome wizard or a settings menu) is desired. Your developers will do this differently depending on your mobile frontend stack (such as React Native, Objective-C, Swift, Java, Kotlin, or others).

Be mindful of how the UI will differ (e.g., the checkboxes for each available purpose) depending on the region, such as GDPR, California, etc.:

  • For GDPR/opt-in regimes, you need to prompt for consent when a user 1. Signs up, 2. Logs into your app one year after their consent expires or 3. Manually retriggers the interface via a button in your settings or elsewhere.
  • For other regulations like CPRA and areas with opt-out requirements, the interface can be simpler - just a toggle for setting their preference.

You can use our iOS and Android SDKs to help power your custom UI. You can request information about the user’s detected region and matching Transcend Regional Experience rules, fetch existing stored consent, and pass captured consent values back to Transcend for governance.

If you’d like to leverage our existing UI work in building your custom UI you can visit our repository to review our open source designs.

Starting with iOS 14.5 Apple began requiring developers to declare the type of data an app is tracking and ask users for permission to track them through their App Tracking Transparency framework. Collecting ATT permission is different from collecting regulation-specific consent or opt-outs. While the consent manager choices can be granular and regulation specific (e.g. for GDPR purposes), the ATT has a narrow defined purpose based on Apple’s definitions of tracking.

With that said, if you have a need to store an ATT decision, or modulate client-side or backend data flows in order to fully honor a user’s ATT choice, we can help with that in the same way we pass and effectuate other consent decisions. For example, you could choose to treat a negative ATT decision as an opt out of sale or sharing and pass that into our SDK for governance.

Please reach out to Transcend Support if you have additional questions about ATT and how it intersects with other consent choices.

We currently support iOS and Android. Please refer to the platform-specific documentation for setup instructions and available APIs.

For UI and Regional Experience Configuration this SDK follows the configuration associated with the airgap.js bundle for your Transcend instance which is loaded from our CDN. Your configured settings from the admin dash used for your web TCF CMP experience will be respected in the Consent SDK experience.

Next, you need to connect to the consent database to read and store consent preferences across all your apps and websites. You can either use Transcend's Preference Store or build your own.

Our Mobile SDKs will handle setting and retrieving Consent for you to this database. You can also leverage the following APIs if you want to access directly or build a custom use case:

Endpoint: Get consent preferences for a user

GET

/sync
Open in API Reference

Endpoint: Set consent preferences for a user

POST

/sync
Open in API Reference

Next you need to identify what third-party SDKs are in use in your mobile app. Transcend can help by scanning and identifying SDKs in use. We do this via integrations with tools like CocoaPods and can also directly scan repositories to find dependency files and the libraries they contain.

We can set up a process where the build file is scanned at a regular interval, and have those scan outputs be sent into the Data Inventory as Silo Discovery suggestions, or into your Native Applications view.

This can lead to a discovery workflow where:

  • A developer adds a new dependency to your mobile app build file
  • Transcend scan picks up on the new dependency and suggests that data silo in Data Inventory
  • You approve the suggestion and receive a recommendation to integrate that vendor for mobile consent management

As SDKs are identified through scanning or manually added in the dashboard, they need to be configured for proper governance in the application based on a user’s preferences. For more information, please review this guide.

There are several governance methods available. A summary of the process to ensuring collected consent will be fully effectuated:

  • Review the discovered SDKs from the prior steps in the Transcend Dashboard and ensure the relevant consent purposes for the data processing they conduct are assigned.
  • Add a small Transcend-provided code snippet in your mobile application for each SDK which checks with the our Consent SDK to see if the third party should be initialized based on what consent is in place. (E.g. don’t load an analytics SDK if proper GDPR analytics consent isn’t in place for a user in the EU.)
  • Optional: If you’re using the IAB TCF framework and UI, our Consent SDK will expose the proper TC String for SDK Vendors who are members of the framework to read and honor.
  • Optional: You can also add a vendor or a DSR workflow to govern backend/server-side uses of their data when a consent change happens.

Please reach out to your solutions engineer at Transcend if there are any SDKs you want further recommendations on.

Sometimes user consent changes need to be reflected or modify subsequent data processes. For instance, we can attach a webhook to that event, or have internal processes subscribed that will trigger workflows.

You can set up a DSR Automation workflow to submit the opt out to Transcend, and Transcend submits that to all the different relevant vendors. This step will depend on the APIs you’ve set up for your backend and mobile frontend stack:

  • If you built your own backend, you will simply submit a DSR with the following API:

    Endpoint: Submit a DSR

    POST

    /v1/data-subject-request
    Open in API Reference
  • If you are using Transcend's Preference Store, you can work with your solutions engineer to define how you intend to map consent purposes to your workflows. Your solutions engineer will be able to set up the automatic connection between purpose changes and new DSRs.

For more information, see our doc on Syncing Consent Preferences Downstream.