Mobile Consent Management

Managing consent for your mobile applications will be different from their web counterparts which usually has far more tracking technologies especially for the selling and sharing of personal data. Mobile consent’s tracking technologies include network requests but not cookies, and are mostly vendor SDKs or backend-based tracking calls.

In short, supporting mobile consent will require the following:

  • Have an interface for users to opt in and out of the relevant consent purposes in that region
  • Notify any vendors of opt-out preferences that have changed, and blocking said vendors if users have opted out
  • Sync consent preferences for the same user across multiple devices
  • Prompt users for opt-in consent when necessary

This guide will walk you through the steps to building mobile consent for your app. The process involves building a consent management interface, building a backend to store consent preferences, turning off your SDKs based on user preferences, and sending consent change events to trigger subsequent workflows.

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

First, you will have to build a consent management interface in your mobile app that allows users to opt in or out of the relevant consent purposes in their region. 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, or 2. Logs into your app one year after their consent expires
  • For all other users, there should be some setting to change consent preferences whenever they desire

Your consent preferences UI should update based on the settings in your Regional Experiences. There is no airgap on a mobile app, but you would potentially want a way to fetch the regional experiences metadata from Transcend which can be done by making a call to one of the Consent Manager metadata files stored alongside airgap.js. If applicable, this interface should also accurately load a user’s previously selected consent settings, such as if it is fetched from a consent backend, which you will read about in the following step.

For more guidance on building your own UI, visit our repository.

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 Managed Consent Database or build your own.

Full stack consent management architecture diagram with Transcend's Managed Consent Database feature

Full stack consent management architecture diagram with your own backend store

To set and retrieve consent preferences for a user, use the following APIs:

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

To learn in detail how to set up a backend, please refer to the Backend Infrastructure Setup section in our Full Stack Consent guide, as this application is not solely for mobile devices.

Next you should scan build files to identify which third-party SDKs are in use in your mobile app. You likely have a repository that includes a dependency file which lists the libraries you use. This can be done using Transcend's open-source CLI tool and running tr-discover-silos, which will identify the SDKs that may be relevant for personal data. For all the vendors that are identified in your dependencies to be receiving user data, you will need to notify that each vendor to opt out by individually passing into each SDK the output value from Consent backend.

You can set up a process where the build file is scanned at some regular interval, and have those scan outputs be sent into the data inventory as Silo Discovery suggestions. This will then enable a workflow where:

  1. A developer adds a new dependency to your mobile app build file
  2. Transcend scan picks up on the new dependency and suggests that data silo in Data Inventory
  3. You approve the suggestion and receive a recommendation to integrate that vendor for mobile consent management
  4. You map the opt-out preferences to the vendor SDK, or you can set up the vendor for a DSR workflow

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

Consent being updated in the backend for some encrypted identifier can affect subsequent 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 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 make a DSR with the following API:

    Endpoint: Submit a DSR

    POST

    /v1/data-subject-request
    Open in API Reference

  • If you are using Transcend Consent backend, you will need to configure the flow such as when a user opts out of SOME_PURPOSE_SET in some REGIONAL_EXPERIENCE, submit a DSR in the Admin Dashboard for the respective ACTION_TYPE for that user based on their stored identifier, e.g., when a user opts out of ['Advertising', 'Sale of Personal Info'] in California, submit an ERASURE request for them with their email being the core identifier

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

We hope this guide helps you build mobile consent for your app. If you have any further questions, please don't hesitate to contact us.