Skip to main content
Privacy is at the forefront of everything we do at Content Ignite, and we believe you, the publisher, should own and control your users’ privacy. For that reason we do not ship a “default” consent experience inside the Mobile SDK. Instead, we require you to integrate a certified Consent Management Platform (CMP) in your app. A correctly implemented CMP is not just a legal safeguard — it has a direct impact on your ad revenue. When valid consent is present, ads can be served as personalised, which typically monetises significantly better than the non-personalised ads that are served when consent is missing or cannot be read.

​
What is a CMP?

A CMP’s job is to collect consent from your users in regions where consent is legally required for the sharing of personal data (such as the EEA and UK), and to make that consent readable, in a standardised format, by every party in your ad stack. CMPs first appeared as a response to the European Union’s GDPR, which requires users to opt in to data sharing up front. To make consent readable by any third party in a uniform way, the IAB introduced the Transparency & Consent Framework (TCF) — a single framework that all CMPs adhere to, so that any downstream partner knows how to read user consent regardless of which CMP a publisher chooses.
For a deeper, framework-level explanation of CMPs, TCF, GPP and consent generally, see the full CMP Guide. This page focuses on what a CMP means specifically for your Mobile SDK integration.

​
Why we require a TCF-certified CMP

A TCF-compliant CMP is responsible for:
  • Presenting users with the IAB TCF consent experience, including the standardised purposes, special purposes, features and legal bases defined by the framework.
  • Presenting the Global Vendor List (GVL), allowing users to grant or deny consent for participating advertising vendors.
  • Generating and storing a standardised TC String containing the user’s consent choices.
  • Making that TC String available to downstream advertising partners (SSPs, exchanges, mediation platforms, demand partners, etc.) via the recognised TCF APIs so that consent signals can be read and honoured throughout the ad serving chain.
Without a certified CMP, SSPs and buyers are generally unable to reliably determine user consent status in the standardised format expected by the ecosystem, which can result in reduced demand, restricted personalised advertising, or non-compliance with partner requirements. For that reason, we require a TCF-certified CMP implementation rather than a custom consent flow. Suitable providers include, for example:
Key TakeawayChoose a CMP that is clearly listed as TCF (and, where you operate globally, GPP) certified, and that provides a native mobile SDK for Android and iOS. A custom or web-only consent flow will not produce a consent signal that our SDK and downstream partners can read.
On the web, consent is passed via the __tcfapi JavaScript API and the ordering of page scripts matters (this is why web integrations rely on a CMP “stub”). In a mobile app there is no stub and no script ordering — the mechanism is simpler and is defined by the IAB’s Mobile In-App CMP API specification:
  1. Your chosen CMP’s mobile SDK presents the consent experience to the user.
  2. The CMP writes the resulting TC String (and related TCF keys, all prefixed with IABTCF_) into the standard platform storage:
    • Android — the app’s default SharedPreferences.
    • iOS — UserDefaults (NSUserDefaults).
  3. The Content Ignite Mobile SDK, the Google Mobile Ads SDK, Prebid and the other partners in your ad stack read those values from platform storage and honour them automatically when requesting ads.
Because consent is read from shared platform storage, you do not pass the TC String to us manually — once the CMP has written it, the signal is available to the whole ad serving chain.

​
Initialise the CMP before requesting ads

The one ordering rule that does matter on mobile is timing. Initialise and gather consent through your CMP before you initialise the Content Ignite Mobile SDK and request your first ad, so that a valid TC String is already present in platform storage when the ad request is made.
If the SDK is initialised and ads are requested before the CMP has written a TC String, those early requests can only be served as non-personalised, reducing the revenue from that session. Gather consent first, then initialise the SDK as described in the relevant platform guide (Android, iOS SwiftUI, iOS UIKit, React Native).

​
Vendor list

As part of configuring your CMP, ensure Content Ignite and the ad partners we integrate with are enabled in your vendor list (the GVL). If we, or our demand partners, are not consented in the vendor list, our consent signal will read as missing and ad serving will default to non-personalised. Most CMPs enable all vendors by default, but it is always worth confirming — especially if you trim the vendor list.

​
Need help choosing or implementing a CMP?

We do not provide a pre-configured CMP, as privacy control should remain with you. However, we can advise on suitable third-party CMPs based on our extensive experience in this field — simply reach out to your account manager, who will be happy to assist. You can also read more about the CMP options we work with in our Ad Tech integrations documentation.