Implementation Best Practices: Mobile & OTT/CTV App Consent

2.1 Regulations & Frameworks

Identify the core regulations and frameworks driving your implementation. OneTrust supports a wide range of privacy laws and standards, including GDPR, U.S. State Privacy Laws, LGPD and IAB Transparency and Consent Framework.

Best Practices:

1. Conduct a thorough analysis of which regulations apply to your organization. This ensures your implementation focuses on the most relevant compliance requirements, avoiding wasted effort on non-applicable regulations.

2. Leverage OneTrust's regulatory templates and updates to stay current with changing laws. Privacy laws are constantly evolving. Using OneTrust's pre-built templates and updates saves time and helps ensure ongoing compliance with the latest regulatory changes.

2.2 Key Stakeholders

Identify stakeholders who will be involved as part of the implementation. Successful implementation requires collaboration across multiple departments.

Best Practices:

1. Form a cross-functional privacy team including representatives from Legal, IT, Information Security, HR, and key business units. Include individuals who act as DPOs for legal entities, if applicable. Also consider including internal contacts for third parties. Privacy impacts all areas of an organization. A diverse team ensures comprehensive coverage of privacy concerns and promotes organization-wide buy-in.

2. Clearly define roles and responsibilities for each stakeholder in the OneTrust implementation process.

   Tool Owner

   Thewill maintain the functional implementation, which includes all configuration steps required in the OneTrust tool.

   Development Decision Maker

   Thewill oversee the technical implementation of the OneTrust CMP across your digital assets, integrating with your internal tools, and ensuring the relevant tracking technologies are being blocked after a user gives consent.

3. Establish regular communication channels and meeting cadences for the privacy team. Consistent communication keeps all stakeholders informed, allows for timely problem-solving, and maintains momentum throughout the implementation process.

4. Identify executive sponsors to champion the implementation and secure necessary resources. Executive support is crucial for overcoming organizational barriers, securing budget and resources, and emphasizing the importance of the privacy program across the organization.

2.3 Organizational Structure

Determine how to represent your organization's structure within OneTrust. This will impact data visibility, access controls, and reporting capabilities.

1. Decide if mirroring your actual organizational hierarchy within OneTrust, including the different sub-organizations/brands is relevant to you. This may be relevant, for example if you would prefer different brands within your organization to only have visibility of their own digital assets. However, it is not always necessary for every business and may lead to an overcomplicated set-up.

2. Implement role-based access control (RBAC) to ensure appropriate data access and permissions. RBAC enhances data security, prevents unauthorized access, and ensures users only see information relevant to their roles and responsibilities.

3. Plan for future organizational changes and ensure your structure is scalable. Organizations evolve over time. A flexible, scalable structure in OneTrust reduces the need for major reconfigurations as your organization changes.

4. Consider language requirements if multi-lingual use is applicable to your organization.

3.1 Scanning

Using OneTrust, you can scan your application to help identify which SDK libraries are being used by your application.

Best Practices:

1. Adding and scanning applications:

   Today, the OneTrust scanner only supports the scanning of Android/Android TV or iOS/tvOS applications by uploading an .apk/.aab or .ipa file to OneTrust. For any other applications, the recommendation is to still add a Mobile or OTT/CTV application in OneTrust, although you can skip the Upload step (for scanning) and manually add SDKs to this application. Your development team should be able to provide a list of SDKs that are being used by the application, so you can manually add these SDKs in OneTrust. This step is especially important if you are choosing to display an SDK list within your Preference Center, seeing as this list will be populated from the Categorizations section.

2. Re-scanning your application:

   Generally, all applications will have ongoing release and maintenance. As part of this process, you should consider re-scanning your application in OneTrust to audit the newly found SDKs and Permissions, including removing old SDKs that are no longer part of the application. Doing this will ensure an up-to-date list of SDKs in OneTrust, as well as transparency as it relates to handling consent. A best practice recommendation is to align the re-scans and review of SDKs with your application release cycles.

3.2 Categorizations

In OneTrust, SDKs are assigned to one of the following default categories: Strictly Necessary, Performance, Functional, Targeting and Social Media. You can manually categorize SDKs to the relevant categories, whilst also having the option to create new categories if relevant. The overall goal here is to identify all technologies used by the application and categorize them accordingly so you know which libraries to suppress if a user opts out.

Best Practices:

1. Naming Categories:

   The default categories will use the name and description that has been configured for Cookie Consent. This generally includes references to Cookies rather than SDKs and so the best practice would be to edit the category and toggle on the options for Want to show a different title and description text for Mobile Apps and Want to show a different title and description text for CTV Apps. This will allow you to remove references to Cookies and replace this with SDKs, providing a more relevant title and description to your Mobile or Connected TV users.

2. Displaying Categories on the preference center:

   SDK categories will only display on the preference center if there is at least one SDK assigned to the category. For each category that you would like to collect consent for on the preference center, ensure that at least one SDK has been assigned to this category.

3.3 Templates

You can leverage OneTrust’s out of the box User Interfaces (UI), including banners, preference centers & prompts to easily collect consent and preferences within the application.

Best Practices:

1. Template configuration:

   When it comes to configuring your template, you can choose to create a new template just for Mobile or OTT/CTV applications, or alternatively you can use the existing Cookie Consent template already deployed for your website. To extend a deployed Cookie Consent template for use across other platforms, navigate to the Details screen for the template and toggle on the respective option for Mobile App Template and/or CTV App Template. By default, Mobile and CTV Apps will use the configuration from the Web Browser Platform. You can override some elements of this configuration at either Mobile App or CTV App Platform level, e.g. title, description, font or border radius size, banner layout height, etc.

2. Customizing your User Interface (UI):

   If you would like to customize the UI beyond the options available within the template, there are two options, Customize UI & Build Your Own UI (BYOUI). With both options, you will still embed the OneTrust SDK within your application. Refer to the Mobile SDK Features documentation within the Developer Portal to determine if these options are available for your application.

   Customize UI

   With this option, you will use the out-of-the-box OneTrust UI, however you will have the option to override certain parameters at application-level to give you a more tailored experience.

   Build Your Own UI (BYOUI)

   With this option, you will not use the out-of-the-box OneTrust UI, instead you will build your own UI and use the OneTrust SDK to manage consent.

   BYOUI will give you more flexibility in being able to design your user interface in comparison to Customize UI, however it comes with the added development effort of having to design the UI from scratch, as well as ensuring that consent given on this UI is updated on the OneTrust SDK. Generally, customers will opt to Customize UI if possible, compared to BYOUI due to the lower development efforts required.

3.4 Geolocation Rules

Geolocation Rules are created to customize the consent model, user interactions, and content displayed to visitors based on their geographical location.

Best Practices:

1. Capture Records of Consent:

   OneTrust users can leverage dashboard reporting to view consent transaction data from site visitors. To view this data, users will need to first enable the Capture Records of Consent setting in a geolocation rule within the application. If multiple geolocation rules are configured in your geolocation rule group, ensure you have the Capture Records of Consent feature enabled for all the rules where you want to receive the consent details. This enables you to review interactions for a particular audience(s). Note that after enabling the Capture Records of Consent setting, the OneTrust SDKs will need to be published for the applicable application to start tracking consent.

2. Google Consent Mode:

   Within the Geolocation Rules, you will have the option to configure the Google Consent Mode (GCM) integration. This allows for the adjustment of how Google SDKs behave based on the consent given or not given by the end-user through the Mobile App Compliance SDK. To determine whether you need to use the Google Consent mode integration, you will need to consider whether your application uses Google Products that support Google Consent Mode.

4.1 Initializing the SDK

After initializing the OneTrust SDK, your application will retrieve an object that contains all the data needed to present a UI to a User to collect consent for the SDKs used in your application. The data returned is determined by the configurations made in the OneTrust Admin console.

Best Practices:

1. It is generally recommended to initialize the OneTrust SDK as early as possible during the application user journey, which would ideally be on initial app launch. This can be done during the splash screen or after it. While your application is initializing, the OneTrust SDK will fetch the configurations relevant to the banner and preference center. Initializing the SDK and showing the banner UI as early as possible during the app lifecycle will allow you to capture the consent of a user and determine the behavior of the SDKs within your application. It is also recommended to initialize the SDK on every app launch to ensure the latest data is fetched each time.

4.2 Displaying the User Interface (UI)

The OneTrust SDK manages several different user interfaces (UI) to display to a User, whilst also providing a few different methods to display the UI.

Best Practices:

1. The recommendation is to leverage setupUI or shouldShowBanner methods to drive the decision making for when to display the banner or preference center UI. This should help eliminate the need for you to create manual logic to decide when to show the banner.

4.3 Actioning Consent

Once a user gives consent to the banner or preference center, OneTrust provides two methods for your application to know the status of consent: querying consent and listening for event broadcasts.

Best Practices:

1. Inside of the callbacks of either method, consent must be actioned to convey the user’s wishes to the third-party SDKs. This process is unique to each SDK as they each have different requirements for enabling/disabling data collection. The recommendation would be to read the developer documentation for the relevant third-party SDKs. It may be as simple as setting a consent flag for that SDK, or it may require preventing the SDK from initializing. It is important to start considering which non-strictly necessary SDKs are being used in your application, so that you can adjust SDK behavior after a user gives consent. Adjusting SDK behavior based on consent is essential for implementing a compliant solution. Ensure that you test your solution to ensure that SDKs are successfully being blocked or behavior is correctly adjusted after collecting consent via the banner or preference center.

4.4 SDK Maintenance

It is important to consider upgrading the OneTrust SDK to make the most of the enhancements offered by OneTrust.

Best Practices:

1. In general, the OneTrust SDK does not need to be upgraded with every release. In some cases, it will be important to upgrade the SDK version to a newer one. This could be due to customers wanting to use a new feature released in the new version, mitigating a bug found in the previous version or to align with upgrades to operating systems, e.g. an upgrade to the android or iOS version. It is recommended best practice to read the release notes periodically to stay up to date on functionality, but also ensure customers are making the best use of their Mobile & OTT/CTV SDK to optimize it for best performance.

5.1 Passing Consent to Webview

Many mobile applications use WebViews to display content to end users and often, the website being displayed will also have the OneTrust Cookie Consent solution implemented. Once a user gives consent on the Mobile App Consent banner or preference center, to prevent the user from being prompted by the Cookie Consent banner again in WebView, you can leverage a solution provided by the Mobile SDK called Passing Consent to WebView.

Best Practices:

1. Consent gathered via the Mobile App Consent banner will be passed into the WebView via a Javascript variable and ingested by the Cookie Consent script, which is able to evaluate this variable and determine whether or not to surface the banner. For this feature to work, the recommendation is to use the same/nearly the same categories across both Cookie Consent and Mobile App Consent. If the Mobile SDK does not capture consent for a category that is present on the Cookie Consent banner, then the banner will resurface in WebView to gather consent for this category.

5.2 App Tracking Transparency (ATT)

Apple introduced the App Tracking Transparency (ATT) framework with the release of iOS / iPadOS / tvOS 14, in order to provide more transparency to users for the data the application and its third parties are accessing from the user.

Best Practices:

1. You need to receive the user’s permission through the ATT prompt, in order to track them or access their device’s advertising identifier. In general, the recommendation would be to use the OneTrust banner alongside the ATT prompt. This will allow you to capture consent for Tracking via ATT, as well as other consents that may be required from privacy regulations via OneTrust. If you will not be tracking, then you do not require user permission through the ATT Framework. To better understand what is considered tracking, refer to this documentation from Apple.

5.3 Authenticated Consent

Authenticated consent (Cross Domain/Device Consent) allows you to share consent given by a user on one Website or Application, across your other managed Websites and Applications.

Best Practices:

1. This is achieved through linking consent to a unique user identifier, which can be shared across the protected OneTrust cloud to additional devices or browsers where the user chooses to roam, safely creating a seamless user experience. To help determine whether this would be applicable for your use case, you will want to consider the Prerequisites required for this functionality to work, and also consider whether there is benefit to storing consent against a unique user identifier, as opposed to a random identifier.

5.4 Universal Consent Purposes Banner

If you would like to collect consent for Universal Consent Purposes within a Mobile application, this is possible using the Universal Consent Purposes banner that is available within the Mobile App Consent solution.

Best Practices:

1. This banner will allow collection of consent for purposes like promotional emails, newsletters, SMS messaging, etc. that typically require an integration with a third-party system like Salesforce and Marketo. It is recommended to have configured Authenticated Consent to ensure that the consent is tied to a specific user. After a Universal Consent transaction is collected, if you would like to send this consent downstream via integration workflows, consider Connecting CMP Preferences with Universal Consent & Preference Management Profiles.

5.5 CMP Server Side API Solution

If you would like to introduce the CMP to a device that doesn’t have a supported SDK today, consider the CMP Server Side API solution.

Best Practices:

1. The CMP Server Side API solution is designed to help support web-based CTV platforms currently not supported by the CTV SDK. As the name entails, CMP functions will be computed on the server and the response handed back to the client. This was done to improve performance for web-based CTV platforms as some of these lower-end devices have limited storage and computing power. Today, this is a headless solution, and you will be responsible for creating the User Interface (UI) for the banner and preference center. For more information on how to implement this solution, refer to the Server-Side CMP API documentation in the Developer Portal.