FAQs for Consent & Preferences

OneTrust is a Data Processor when it delivers the Cookie Consent service. Our role is defined in the DPA we offer customers.

The user's preferences are stored in a cookie called OptanonConsent that is saved to the browser of the website visitor. For more information, see OneTrust Cookies.

You can also track the opt-in/opt-out rates in your dashboards by enabling the Capture Records of Consent setting in your geolocation rules. For more information see, Enabling Consent Logging and the Cookie Consent Dashboard.Enabling Consent Logging and the Cookie Consent Dashboard

The Cookie Preference is stored in a cookie that is saved to the device of the website visitor.

The Cookie Preference is stored in a cookie that is saved to the browser of the website visitor. Database storage could be triggered by enabling optional features such as analytics or through an integration with consent functionality.

No. The OneTrust script makes a call to the Geolocation service. The network request, as with any network request, contains the IP address which is then used to look up the location information based on the granularity configured within the application (e.g., Country, State). The response contains the 2-byte ISO codes, but no IP address information is written to storage.

We use Cloudflare, which is leveraged to perform a reverse IP lookup that will return the general location of the user (approximately at the city level). The location is not stored and is only used to determine the applicable rule.

For more information, see Cloudflare Support.

Yes, we use the full IP address of the site visitor. Cloudflare is GDPR and CCPA compliant.

For more information, see Cloudflare GDPR and CCPA.

The consent cookie is stored with the location they are in when consent is given. Therefore, the consent model for the location they were in when they consented will be applied as long as the consent cookie is active. To trigger a re-prompt for consent, the user would have to clear their cookies or the consent cookie would have to expire.

Yes, you can read more about the changes to OneTrust cookies to support the changes in SameSite in Setting SameSite Cookies and OneTrust Cookies.

OneTrust includes Russia within the guidance we provide to companies on Cookie requirements. Compliance depends on a number of factors and the customer’s interpretation of how the requirements apply to our cookie infrastructure. In addition, customers who understand the data localization requirement to apply to cookies often take additional steps to meet this requirement. For example, customers may proxy the data sent to OneTrust.

If you scan www.domain.com, the related scripts will function only on this sub-domain and anything that comes under www.domain.com (for example, www.domain.com/page).

If you scan the root domain (domain.com), the scripts can be utilized on any sub-domains, pages, or URLs that come under the root domain (e.g., www.domain.com, xyz.domain.com, domain.com/page, etc.).

If you would like to have unique experiences on each of your sub-domains (for example, www.domain.com has a different experience and its own consent as compared to abc.domain.com), you can scan these separately. Otherwise, the root domain scan, domain.com, will cover everything.

You are not required to scan test websites alongside production sites. When you add a domain for scanning, it will generate a test as well as production script. The test script can be used on any domain, irrespective of whether you have it added in the OneTrust tenant or not. Hence, if the main purpose of scanning the test website is to have the scripts available for testing, then it is not mandatory to scan the test website.

There is not a limit to the number of domain scans in a certain tenant. However, the number of production scripts that you can publish depends on the number of licenses you have purchased.

Scan time varies from a couple hours to several days. Scan time depends on several factors including total number of pages as well as number of scans launched at the same time in the tenant.

You can scan your domain in parts by initiating multiple scans of the same website. Each time, add a few sub-domains in the Target Pages to Scan section of the scan configuration. You can also add a few sitemaps each time in the Sitemap URL section.

See see Scanning Behind Authentication for information on configuring a scan to pick up pages behind login.

Yes, the OneTrust scanner can be configured to login with multi-factor authentication or onetime passwords.

Re-directs are now supported. You will need to configure the root path as an expected re-direct in the login configuration.

If your site uses storage objects that are set post‑login, these may not be captured; pages treated as already visited after login are not re‑crawled. Add these post-login pages manually when configuring your scan.

No, our scanner does not have the ability to perform any user actions like checking boxes, accepting existing banners, submitting forms, etc.

No. The scanner does not support SPA sites. You can either manually add the pages you want to scan or manually add the cookies relevant to your site.

The scanner does not require any specific Allow rule within robots.txt. You only need to safelist the OneTrust user agent within your security or bot‑detection systems (e.g., Cloudflare Bot Management, WAF, or custom firewalls) to prevent the scanner from being blocked.

The scanner checks robots.txt for a sitemap on any scan that does not have any sitemap URLs provided. The check is skipped if a sitemap is provided in the scan request.

Currently, OneTrust can notify only one user when a scheduled scan is completed. You can add a distribution list to notify multiple users at once.

Pages is the number of pages scanned for that particular scan.

Total Pages is the sum of pages for all scans ever run for that domain.

If you would like for the scan report to include manually added cookies, you can export the list by navigating to Tracking technologies tab and clicking the Export icon. This report will include all cookies (including manually added) with the latest categorizations. Scan reports generated from the Websites or Website details screens will not include manually added cookies.

For more information, see Managing Tracking Technologies.

No. Tracking technologies found via scan are accessible across your entire tenant, including other sub-organizations. Scanned technologies are not separated based on sub-organization.

• Check if the website is available in the region that the scanner is located. For more information, see About OneTrust Hosting Options, Backup, and Locations. Safelisting the scanner’s IP address will help if the website is not available in the scanner’s region.

• If the website is behind a firewall, that will require safelisting the scanner’s IP address.

• Check if the website has a re-direct. If this re-direct is to a domain other than the one entered for scanning, the scanner will not yield expected results. For instance, if you are trying to scan example.com but it is automatically re-directed to xyz.com, then the scanner will return zero pages and zero cookies and you would have to scan xyz.com.

If all the above fail or are not applicable, OneTrust recommends adding a few pages in Target Pages to Scan. This can direct the scanner to visit all the pages mentioned in the scan configuration.

Multiple scans of the same website can produce varying outcomes as the scanner may navigate different paths throughout the site. For instance, in a case where a page becomes unavailable during a scan due to load timeout, and it includes links to other pages that lead to additional links branching out to other pages, there is a possibility that this cluster of pages may not get scanned.

Any of the following could result in inconsistent scan results:

• Changes to the website (new services added, modified code) since the last scan.

• Changes in the scan configuration (target pages, etc.).

• Use of sitemaps or change in sitemaps.

• Safelisting of scanner IPs.

1. Ensure that you have the right permissions.

2. Review the scanner settings for incorrect URLs or mandatory fields that are not filled in.

3. Expand the Advanced Settings section on the Add Website screen and check if there are any required fields left empty or any incorrect URLs inputted in sitemaps or target pages. If the URLs are entered without the protocol, you need to add https://.

Path duplicates are cookies with same name, host, and secure flag values, but different path values.

Cookie uniqueness is based on a combination of Name + Host + Secure + Path. Some cookies are set uniquely on each path, in which the path is identical to the page of the domain on which it’s set. These cookies can only be set and accessed within the page path on which they’re specified. For example, you would not see cookies with path = products/data-discovery on the products/cookie-consent page. However, each cookie, because of the path value, is unique, even if the name, host, and secure flag is the same. These are commonly referred to as path duplicates within OneTrust.

Although there are unique records for each cookie in the database table, OneTrust consolidates path duplicates into one cookie in the Categorizations tab and on the Preference Center. The reason you see a noticeable difference in the count between website scan results and cookie categorization pages is because of this front-end consolidation.

Yes, you can still manually override the category of a cookie. This enhancement provides a better default category for all Unknown cookies.

There is no tenant-specific data that maps cookies to which page/domain it was found on.

The cookie list provides users with updated information on cookies, which is required by law for certain regulations.

Yes, it's common practice to display a cookie list to users. Please consult with your legal team for specific requirements.

If you have scanned multiple domains, such as example.com and example1.com, and the scanner identifies cookies as follows:

• example.com: _ga and _fbp

• example1.com: _gcl and YSC

When you implement the script for example.com and embed its cookie list script, the cookie list will only display cookies identified for example.com (_ga and _fbp). Cookies from a different domain (e.g., _gcl and YSC from example1.com) will not appear in the example.com cookie list.

Templates are not assigned to a domain. A template is assigned to a geolocation rule group, which in turn is assigned to a domain.

You can reassign a template to another organization if you have multiple organizations in your organizational hierarchy. Please note that users assigned to a particular organization will only be able to view items (including domain scans, templates, geolocation rules, etc.) assigned to that organization and any of its child organizations. For details on creating and managing organizations, please refer to Managing Organizations.

A default template means any time a new geolocation rule group is created, the default template will be assigned to this geolocation rule group.

A default geolocation rule group means anytime you add a domain for scanning and do not assign a geolocation rule group manually, the domain will automatically be assigned to the default geolocation rule group.

No, there is no limit on the number of templates you can create.

Yes, you can assign multiple domains to the same geolocation rule by clicking the Assign to Domains button on the Assigned Domains tab of the Geolocation Rule Group Details screen. All assigned domains will appear in the Assigned Domains tab.

For more information, see Configuring Geolocation Rules.

If you would like to modify any of these details, you can navigate to the Cookie Consent menu and select Purposes. Here, you can select the appropriate category and edit the details. These changes will display in your templates.

For more information, see Configuring Purposes.

Built-in/default categories cannot be disabled or removed from the Preference Center. However, if you do not require a category to display on the Preference Center, make sure there are no cookies in the Categorizations tab assigned to that category. Custom categories can be deleted after recategorizing any cookie mapped to a custom category to a different category.

No, the language codes are not case sensitive.

Currently, OneTrust does not support the use of variables to dynamically modify cookie banner content based on the domain or location. Instead, OneTrust applies branding configurations (such as the cookie policy link, logo, and color scheme) at the domain level. These settings override the original template configurations according to the geolocation rule. To meet the need for domain-specific content, you can create separate templates for each domain or brand. Assign each template to its corresponding geolocation rule group. This approach allows each domain to display a uniquely customized cookie consent banner with brand-specific links and styling.

For more information, see Configuring Domain Branding.

You can view the version history of a template by clicking on the Context Menu icon in the header of the Template Details screen and selecting View Version History. For more information, see Customizing the Banner Template or Customizing the Preference Center Template .

For more information, see Configuring Geolocation Rules.

No, this feature is not currently supported. If you would like to see this feature, please create or up-vote the idea in the OneTrust Ideas Portal.

If a site visitor decides to click on the close (‘X’) button on the Banner, the default consent model for that location as configured in geolocation rule groups would be honored.

In the Content section of your Banner template, select Button Set. For the item When using the button in a web page to access the Cookie’s Preference Center, you can select Show other text and enter your desired text. Please note that if you would like to apply this change for all geolocations, you will have to make this change to all the templates you have assigned in your geolocation rule group.

For more information, see Customizing the Banner Template.

You are required to enable the Enable persistent Cookie Settings hover button setting for the icon to show up after Banner interaction. For more information, see Customizing the Preference Center Template.

Yes, it is a Preference Center setting that is available for all the frameworks.

For more information, see Customizing the Preference Center Template.

The CMP suppresses the Require banner interaction overlay (grey background) when the current page URL matches a URL configured within the banner or preference center content.

The CMP evaluates URLs configured in the following locations:

• Cookie policy link template field

• Imprint link template field

• Custom anchor (<a>) tags added to the Title and description field

When a user navigates to a configured disclosure URL, the CMP suppresses the require banner interaction overlay to ensure the content remains accessible. URLs configured within banner or preference center content are typically intended to direct users to privacy-related disclosures and legal notices, such as Privacy Policies, Cookie Policies, Terms of Use, or similar notices. End users must be able to access and review this transparency and disclosure information before making a consent decision. Providing access to these resources prior to consent supports informed consent practices and improves transparency.

You can get the HTML or CSS code by executing Optanon.getHTML() or Optanon.getCSS() respectively.

Scripts will not be generated unless you add the domain for scanning.

The test scripts are designed to be leveraged on any domain. Test scripts are not tied to the domain you scan in the tenant.

For instance, if the scanned URL is domain.com, but the testing website is www-test.staging.com, you can still use the test scripts from domain.com on this testing website. The only other step required is to ensure you publish the scripts before using them on the site.

For more information, see Implementing Cookie Consent Scripts.

The production scripts are tied to the domain scanned in the OneTrust application.

For instance, if you scan domain.com, then the production script will only function on domain.com and any of its sub-domains, paths, or pages. If you try to integrate it on test.com, it will not work correctly; the banner will keep popping up on every page or every page refresh even if you have consented to it. In order to use the production scripts, you must publish them first.

For more information, see Implementing Cookie Consent Scripts.

When there is any change within OneTrust tool across categorizations, templates, geolocation rule groups, etc. you are required to publish the testing CDN or production CDN to view the changes on test or production site, respectively.

Without publishing the scripts, the changes will not reflect on test or production website.

When you publish the production scripts for a domain, the geolocation rules and templates tied to it automatically change from Draft to Active status.

The status of a template and geolocation rule group changes from Draft to Active when production scripts are published.

The testing CDN is meant for testing purposes, and it is not domain-specific to the website scanned within the OneTrust tool. The testing CDN writes OneTrust cookies to the domain it is currently on, allowing it to behave like a Production CDN script in a testing environment. While using the testing CDN, it is not possible to test consent carrying forward from root domain to sub-domain and vice-versa.

No, the script ID does not change when templates or geolocation rules are modified or when a domain is re-scanned.

The OneTrust Testing/Production CDN remains the same in all scenarios except:

• When the auto-blocking setting is enabled/disabled.

  When auto-blocking is enabled, the source (src) of the script tag is modified to add OtAutoBlock.js. Make sure to copy and paste the new scripts on your website.

  
  
  

  Similarly, when auto-blocking is disabled, source (src) OtAutoBlock.js is removed from the script. Ensure you update the correct scripts on the website.

• When ‘Enable language detection of scripts’ is updated from corresponding to the visitor’s browser settings to corresponding to the language from the HTML page and vice-versa

  If Determine the language from HTML page is chosen, a new attribute, data-document-language="true" is added to the script tag. Make sure to copy and paste the new scripts on the website when enabling this option

  
  
  

  Similarly, when the language determination is chosen from Visitor’s browser settings, the attribute data-document-language is removed. Be sure to update to the correct scripts on your website.

Whichever you prefer; there are no comparative advantages to integrating the CDN through the head section of the code or GTM. However, it is not recommended to place the snippet in GTM if you are using auto-blocking.

Bulk Domain Management allows you to deploy a single script across several domains by creating a domain group. A domain group is a collection of domains to which the main domain script applies. The main script functions and writes consent to the domains contained in the domain group. Consent is written individually per domain.

Use Case: You may wish to leverage domain groups if you have a business where the tracking technology template across a large number of domain properties is the same or similar. Because of the number of domain properties, the number of domain scripts and association with domains among different teams can become hard to manage. Using Bulk Domain Management, you are able to associate a list of domain properties with a singular domain script, making it easy to deploy and manage changes across all the domains.

• The domain that is used as the parent of the domain group should be scanned in the OneTrust tenant. Since the script is only specific to the parent domain, the cookie list will only include cookies from the parent domain scan.

• If you display the cookie list on the preference center, this list populates from the main domain’s scan.

• If you use Auto-Blocking, the sources of the will be limited to those found in the main domain's scan.

• Templates and geolocation rules will be inherited from the parent domain. Domain level branding is not possible.

• Dashboard metrics will be combined and displayed under the parent domain.

• If a domain needs to be removed from the group and implemented separately, you can scan the domain as a different website in the OneTrust environment and implement it.

• Bulk Domain Management is not compatible with Download to Local.

Refer to the developer portal documentation for steps on how you can set-up Bulk Domain Management for your selected domains.

Yes, it is possible to use one script across multiple root domains via Bulk Domain Management. Please note that this feature is currently available only for enterprise license types.

For more information, see Bulk Domain Management FAQ.

Yes, it is possible for the consent to be shared across domains if the user is authenticated. This can be achieved via a cross-domain consent setup. Please note that this setting is not available by default and requires you to purchase a Consent Rate Optimization (CRO) license. You can speak with your account representative to purchase this license.

For more information, please see Cross-Domain and Cross-Device Consent.

OneTrust suggests using Auto-blocking for simpler websites (where you don’t have dynamic URLs firing cookies on the website and where you have fewer cookies, which makes it easier to maintain the Auto-Blocking file).

Please see OneTrust Cookie Auto-Blocking™.

Yes, the Auto-Blocking script must be the first item in your head section of your source code. This is to ensure it runs before any cookies are dropped.

Simple integrations are available for all tag managers, giving you a great way to control when tags fire based upon user consent.

With Auto-Blocking turned on, new tags are automatically disabled if the tag is in a category blocked until consent is given.

If you already have a tag manager integrated with your domain, it is recommended that you utilize the respective tag manager blocking mechanism.

Auto-Blocking is only recommended if you have 20-30 cookies or if the CMS does not allow code modification for manual blocking, like Shopify or Wordpress. Additionally, it is important to note that Auto-Blocking requires cookie categorization in the OneTrust tenant and only works for cookies that have a resource URL.

For additional details on Auto-Blocking requirements, please see OneTrust Cookie Auto-Blocking™.

Yes, you can use custom category IDs with the Auto-Blocking script. It uses whatever IDs are configured in the tool. The Auto-Blocking script adds the appropriate IDs to the tags that need to be blocked.

Yes, you can use any consent model with Auto-Blocking. When using an opt-out consent model, cookies are allowed when the user first visits the site. If the user chooses to opt-out or reject a category, cookies belonging to that category are blocked on the website. This also applies to Auto-Blocking.

Auto-Blocking currently only works for iFrames created dynamically on the page, such as advertising iFrames that are injected by a JavaScript file.

For iFrames embedded directly on page, for example some YouTube videos, we recommend following the manual steps to block those iFrames.

For more information, see Client-Side Cookie Management.

You can rescan your site by using the automatic scan scheduler or by manually initiating a scan. If new cookies are found, you will need to make sure they are categorized and have the correct resource URL added or they will not be blocked.

After categorizing the new cookies, you will need to publish the script.

Cookies will not be blocked until they are categorized. Make sure to republish your scripts if you make any categorization changes for those changes to reflect on the site.

You should make sure all cookies on your site have been categorized in the OneTrust application. Cookies that are uncategorized will not be blocked by the Auto-Blocking feature. Additionally, any cookies that are categorized as Strictly Necessary will not be blocked by the Auto-Blocking feature.

If all of the cookies are categorized, verify that the cookies being dropped are not categorized as Strictly Necessary cookies. These cookies will not be blocked by default.

Any cookie that is categorized but does not have a source URL associated with will continue to fire on the website irrespective of a user's consent. For information on how to check the source URL for a cookie, see Configuring Purposes.

Check the consent model being used for your region. If the consent model is opt-out, then the cookies will be enabled until the site visitor opts out.

You can export an Excel file that gives you a list of all the cookies and their associated source URL(s). To export this file, follow the steps in the To export you cookie list section of Configuring Purposes.

Important:

Disable the Exclude Resource URLs setting on the Cookie Export modal when exporting your cookie list.

This happens when the Auto-Blocking file contains sources responsible for loading those functionalities.

To ensure all aspects of your site load properly when cookies are rejected, you can unblock any unnecessary sources from your Auto-Blocking file. Unnecessary sources may include sources ending in .img, .png, .css or .gif.

You can also test whether Auto-Blocking is causing an issue on your site by blocking the network call to the Auto-Blocking file and reloading the site to see if the behavior continues.

For more information on how you can unblock sources, see OneTrust Cookie Auto-Blocking™.

With A/B testing, you can run different variant tests per different location. This means you will be able to add a variant per geolocation rule.

Currently, just country (geolocation) is available to test. Newer versions will be able to test age and a custom variable for a user.

Three variants can be tested under one control group.

The variants can be different for both the Cookie Banner and Preference Center because variants are configured at the template level.  It is recommend that you only change one aspect at a time so you can understand what is affecting your opt-in rate.

This happens in the code you have via JavaScript function. We do not perform algorithmic selection.

No. Tests cannot be edited after launching.

Only the templates added as A/B testing variants will be displayed. Audience logic overrides the domain's standard template configured in Geolocation Rules.

The information is stored the same way as information captured through standard consent logging.

Yes, personally identifiable information is not used. It is based on a geolocation.

Yes, we can load cookies pre-consent.

The IAB TCF was created to support parties who display and manage digital advertising and targeted content comply with the European Union's General Data Protection Regulation (GDPR) and ePrivacy Directive (ePD). The framework helps to clarify how data is collected and use as well as the legal basis for processing data.

No, these are separate frameworks that will be handled with different template configurations.

For TCF Canada, there is change in the concept of Legitimate Interest, which is replaced with Implied Consent.

You can find all of the documentation from the IAB TCF here.

The Global Vendor List (GVL) is automatically updated once a week.

The format is [ Core String ].[ Disclosed Vendors ].[ Allowed Vendors ].[ Publisher TC ]. See IAB TCF 2.0 Consent String for further detail. IAB TCF 2.0 Consent String

BObdrPUOevsguAfDqFENCNAAAAAmeAAA.PVAfDObdrA.DqFENCAmeAENCDA.OevsguAfDq

Yes, the vendor must register with the IAB TCF because this signal is relayed by a vendor ID, which comes from the IAB Global Vendor List.

These Vendors are not relayed in the TC string. OneTrust can disclose these separately if desired and leverages the base tracking control tools to manage these Vendors.

Publishers need to leverage available OneTrust blocking methods based on how non-vendor tags are added to the site. See the section Third-Party Integrations and Blocking Guidance here.

For mobile consent, publishers can programmatically block or enable vendors based on recent consent changes.

This signals that generally you support OOB and that these vendors have been disclosed at some point in the global context.

Yes, this is specific to service-specific string as it is dictated by the publisher.

You can do this for enhanced transparency and consolidation. This may also be achieved through the standard cookie categories and controls.

The consent given on the first site will be taken from the euconsent third-party cookie.

If the transparency or consent is not received, you will not be able to process the user's data.

No, if you make a custom change to your vendor list and want users to re-consent, you must select the option in the publish modal when re-publishing the script.

Custom illustrations are the responsibility of publishers. Please work with your legal team to provide illustrations collecting users' personal data for your business needs.

By default, OneTrust lists examples of illustrations provided from the IAB TCF, which can be leveraged as per the specification.

If you plan to customize the text, please contact your OneTrust implementation consultant or reach out to OneTrust Support via the Create a Case web form.

The GPP enables advertisers, publishers, and technology vendors to adapt to regulatory requirements across markets. The framework enables companies to use a consent management platform (CMP), such as OneTrust, to capture and communicate consent signals throughout the digital ad supply chain. The creation of GPP consolidates the management of different consent signals from multiple global privacy jurisdictions and also supports the Global Privacy Control (GPC), a browser-level signal that enables individuals to opt out of the sale or sharing of information. The GPP currently supports the US Privacy and IAB Europe TCF consent strings.

You can find all of the documentation for IAB GPP here.

No, MSPA is not a requirement to use GPP. Publishers can confirm whether they would like to adhere to the MSPA. Please see documentation here for more detail.

The IAB recommends companies transition away from the US Privacy Specifications and adopt GPP. GPP will be the only platform to accommodate upcoming and future privacy and consent management requirements in the US. There will be a grace period before this full transition.

The format is [Header]~[Discrete Section]. See IAB TCF GPP Consent String for further detail.

The consent given on the first site will be taken from the OTGPPConsent third-party cookie.

Yes, they are encrypted.

Generally, the OneTrust SDKs use all three, but the iOS SDK does not.

OneTrust does not expose our public APIs to Objective-C by default. If your app is written in Objective-C, you can write an interface and access our Swift APIs from Objective-C.

Many clients obfuscate their apps prior to release to optimize for size, security, and performance. Android supports this via the minifyEnabled setting for release buildTypes.

If you happen to come across issues when minifyEnabled is set to true, this is most likely due to the application's org.json Gradle dependency causing a collision with the OneTrust SDK's org.json dependency used for JSON parsing.

To resolve this, please add the following to your app's proguard-rule.pro file inside of Gradle Scripts, then re-build the app.

-keep class org.json.** { *; }

In this instance, you can exclude these dependencies from the SDK and add it explicitly in your app.

For example, the SDK uses OkHttp 2.8.1 which introduces vulnerabilities/conflicts with the app.

You can exclude this dependency from OneTrust and specify your own.

Yes, our Mobile and CTV CMP SDKs will work with IPv6.

Yes, our CMP API will work with IPv6.

This consent will not be passed from the website in WebView back to the mobile application.

As a security best practice, yes, we recommend using a backend for generating JWTs as OneTrust does not support this functionality today.

The JWT.io site has a lot of great resources if you scroll down the page.

No, a JWT auth token is user-specific and tied to their unique identifier.

Since you are likely using the same identifier to sync a user's consent between mobile to CTV or web to CTV, there is no need to change the JWT auth token in this scenario.

It is possible to perform an environment copy, but we recommend that you speak to your OneTrust contact to confirm if this is suitable for your case.

Your applications, templates and geolocation rules will all be copied.

Please note, the SDK App IDs will be copied, although you will not be able to use the same app ID in both environments, and so you will need to decide whether a new app ID is generated for the old or new environment.

The Mobile App will revert back to the Web Browser styles, which reflect a Light Mode color scheme.

The Mobile App will revert back to Web Browser styles

Once enabled on the Template, Dark Mode settings will be automatically applied based on the device settings. Developers or QA do not need to perform any backend configuration.

No, Apple does not allow this. The App Tracking Transparency permission can only be updated in the following ways:

• User interacts with Apple’s App Tracking Transparency permission prompt.

• User updates the App Tracking Transparency permission value in the device’s settings.

The OneTrust SDK can only:

• Show Apple’s App Tracking Transparency permission prompt to the user, via Pre-Prompt.

• Deep link the user to the application’s device settings for updating App Tracking Transparency permission, via Settings Prompt.

Apple records this as a Ask App Not to Track user selection. This will impact the application in the following ways:

• The application will not be allowed to show the App Tracking Transparency permission prompt to the user again, since it was already shown once.

• Calling OneTrust SDK’s showConsentUI() method will result in a Settings Prompt, not a Pre-Prompt.

• If Consent Logging feature is enabled, the next time startSDK() or checkAndLogConsent() is called, the OneTrust SDK will log a consent transaction for the App Tracking & Transparency purpose with status Opted Out.

Nothing happens. The OneTrust SDK will not log any consent transactions.

The next time OneTrust SDK’s showConsentUI() method is called, the Pre-Prompt will still be shown because the App Tracking Transparency permission prompt has yet to be shown to the user.

The application will restart (Apple device does this automatically).

If Consent Logging is enabled on Geolocation rule, the next time startSDK() or checkAndLogConsent() is called, the OneTrust SDK will log a consent transaction for App Tracking & Transparency purpose with status of Confirmed or Opted Out (depending on user’s new selection.)

If the user turned off App Tracking Transparency, then a status of Opted Out for linked purposes will be returned and consent logged to OneTrust.

If the user turned on App Tracking Transparency, when it had previously been turned off, the user can update the settings in their Preference Center, but the OneTrust CMP will not automatically show a status of Opt In for a user.

The application will return a status of denied.

When startSDK() or checkandLogConsent() are called, Opted Out will be logged in the receipt.

If a status of Not Given has been logged, the ATT Pre-Prompt has been disabled and consent was not recorded for the user.

Yes. You can disable a Collection Point to temporarily or permanently stop the generation of receipts. This provides additional security and a way to retire a Collection Point that is no longer needed. For more information, see Disabling and Enabling a Collection Point.

You can test end-to-end Collection Point workflows by creating receipts using test data subjects, which can help you evaluate and adjust the Collection Point configuration before publishing.

You will have four more attempts to enter the correct access code. After five attempts, you will need to contact the privacy team for assistance.

You can click the Resend Code button to receive a new access code. The code will be valid for 10 minutes.

The recommended file format will vary based on the import template, as detailed below:

• Use .csv format for the Create / Update Data Subject Consent import template.

• Use .xlsx for the Create Historic Data Subject Consents and Create/Update Consent Data Subjects import templates.

• Use .jsonl or jsonl.gz for the Stream Consent Receipts import template.

If using the Create / Update Data Subject Consent, Create Historic Data Subject Consents, or Create/Update Consent Data Subjects import templates, uploads should be limited to 50,000 rows per file. If using the the Stream Consent Receipts import template, uploads should be limited to 250,000 data subject consent records. However, if you are importing more than these limits for the respective template, please contact OneTrust Support in advance before performing the import.

If you are using bulk import templates, the traffic will be processed at 3.3k - 4.1k records per minute. Data subject profiles are known to take longer to complete due to the size and amount of data elements that need to be processed.

This is supported in the Stream Consent Receipts import template by adding the "dsDataElements":{} attribute to the list of payloads, as needed. Data elements and transactions should be uploaded separately when utilizing other import templates.

Privacy Notice Management is the updated version of the Policy & Notice Management module. It simplifies the complex process of creating, updating, and monitoring policies across websites and applications into one central location while eliminating the need of complex development work.

The Privacy Notice Management module has workflows and approvals, email notifications, related tab, attribute manager, and reporting and dashboards. For more information, see About Privacy Notice Management.

Yes. New and existing customers can trial the Privacy Notice Management module in the UAT or trial environment.

A feature toggle request must be submitted to OneTrust Support. Customers should work with their account executive or consultant to request the Privacy Notice Management module be enabled in their tenant.

The PNM Privacy Notice permission has been created to allow users the ability to view Privacy Notices in the Privacy Notice Management module.

The permissions associated with this feature are PNM Workflow and Approval Tab and PNM Bypass Required Approvals.

The PNM Workflow and Approval Tab permission allows users to view the workflow and approvals tab of documents using advanced workflows.

The PNM Bypass Required Approvals permission allows users to skip required approvers within advanced workflow approval stages.

No. Only users with the PNM Bypass Required Approvals permission can bypass other approvers. The roles with this permission are Site Admins and PNM Managers.

The PNM Workflow and Approval Tab permission allows the ability to add user type attributes as approvers.

The following count toward daily unique visitor metrics across web, mobile, CTV , SDK, and API implementations:

• the CMP is loaded

• a consent state check or consent validation occurs

• the browser or application requests the CMP from the CDN, such as when startSDK() executes.

• CMP-related consent infrastructure is invoked in supported implementations

• Accept all actions

• Reject All actions

• Saving preferences

• Other banner button interactions or preference center choices

• Whether a consent receipt is created

• Banner impressions alone

A banner interaction may never occur, and the visitor can still contribute to DUV if the CMP loads or a consent validation call is performed.

A visitor is counted once per day. This means:

• Multiple visits from the same browser or device on the same day are deduplicated.

• A return visit on a different day is counted again as a new daily visitor.

• The visitor does not need to see the banner again for that day's visit to count.

• If the CMP still loads or consent validation still occurs, that day's visit contributes to usage.

DUV is not intended to represent unique individuals. It does not perform cross-device identity stitching or person-level deduplication. It measures CMP activity in a privacy-friendly way without attempting to identify or unify users across channels.

DUV is not

• a known-person count;

• an identity graph count; or

• a cross-device unified user count.

Yes, multiple visits from the same user within 24 hours are only recorded as one impression.

No. Bot management removes bots from all metrics. You can view the number of bot devices excluded from your metrics in each widget.

Each day, OneTrust counts the number of unique daily visitors whose activity results in the CMP being loaded or a consent state being checked. A visitor is counted once per day, even if they visit multiple times that day. These daily counts are then aggregated and averaged across a rolling 365-day period. The resulting rolling average is displayed as ADUV.

ADUV is not tied to the selected reporting date range in the same way as a standard analytics metric. Instead, it is calculated as a rolling average over the past 365 days, or approximately 12 months.

Because of that:

• ADUV reflects a long-term normalized traffic baseline.

• ADUV is not meant to behave like a point-in-time daily or monthly historical traffic metric.

• Older date selections can still show a similar ADUV value because the underlying licensing logic uses the rolling 12-month average.

DAU is request-based, not engagement-based. It tracks CMP/banner load activity and CDN calls over a 24-hour cached session, not app opens or engaged users in the same way GA or internal analytics do. A user does not need to interact with the banner for activity to be recorded.

The introduction of CMP APIs changes where consent logic runs, but it does not change the fundamental licensing concept. Server-side and API-based implementations still generate consent validation activity and are measured from consent infrastructure activity rather than user interaction events. So moving to any of the following does not automatically convert the licensing model into a person-based model:

• Server-side CMP APIs

• Custom UI

• Authenticated identities

• Centralized consent storage