> For the complete documentation index, see [llms.txt](https://cmp.docs.sirdata.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cmp.docs.sirdata.net/applications-mobiles-sdk-natif/mobile-sdk/sharing-consent.md). # Transmission du consentement aux SDK partenaires C'est la partie qui fait fonctionner la publicité — et c'est aussi celle qui vous demande le moins de code. Comme toute CMP conforme IAB, Sirdata CMP publie le consentement via les **clés de stockage in-app standard**. Les SDK partenaires conformes — Google Mobile Ads, Prebid Mobile, AppLovin, Amazon APS et les autres — lisent ces clés d'eux-mêmes. Pour les SDK les plus courants qui ne le font pas, ou pas entièrement, le SDK Sirdata embarque des **adaptateurs de consentement** qui transmettent chaque choix à votre place. | Plateforme | Stockage | Comment les partenaires le lisent | | ---------- | ---------------------------------------- | ------------------------------------------------- | | Android | `SharedPreferences` (fichier par défaut) | `PreferenceManager.getDefaultSharedPreferences()` | | iOS | `NSUserDefaults.standard` | `UserDefaults.didChangeNotification` | ## SDK par SDK Ce dont chaque SDK courant a besoin, vérifié avec les vraies bibliothèques. | SDK | Lit les clés IAB | Ce que fait le SDK Sirdata | Ce que vous faites | | ------------------------------------- | ------------------------------------------ | -------------------------- | ------------------------------------------------------------------ | | Google Mobile Ads (AdMob, Ad Manager) | Oui | — | Rien | | Firebase Analytics | Seulement avec l'option d'interopérabilité | Adaptateur Consent Mode | Rien — [détails](#firebase-analytics) | | AppsFlyer | Seulement si on le lui demande | Adaptateur de consentement | `enableTCFDataCollection(true)` — [détails](#appsflyer) | | Adjust | Non | Adaptateur de consentement | Rien — [détails](#adjust-et-branch) | | Branch | Non | Adaptateur de consentement | Rien — [détails](#adjust-et-branch) | | Meta (SDK Facebook) | Non | — | À conditionner vous-même — [détails](#conditionner-un-sdk-non-iab) | Versions vérifiées : Google Mobile Ads 25.5.0 (Android) ; Firebase Analytics 23.2.0 (Android) et 12.19.2 (iOS) ; AppsFlyer 7.0.1 (Android) et 7.0.2 (iOS) ; Adjust 5.8.0 ; Branch 5.21.3 (Android) et 3.14.2 (iOS) ; Meta 18.3.0 (Android — le SDK Meta iOS n'a pas été mesuré). Google Mobile Ads ne demande aucun code : ses requêtes publicitaires portent la chaîne TC stockée, la chaîne Additional Consent et la chaîne GPP. Initialisez Sirdata CMP en premier, et chargez les publicités une fois le consentement collecté. ## Les clés maintenues par le SDK **IAB TCF v2.2** | Clé | Contenu | | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | `IABTCF_CmpSdkID` | `92` — écrit de façon synchrone dès `initialize()` | | `IABTCF_CmpSdkVersion` | `10`, la version de CMP que porte la chaîne TC — pas la version du SDK (2.0.0). Écrite avec `IABTCF_CmpSdkID` | | `IABTCF_PolicyVersion` | Version de la politique TCF, tirée de la Global Vendor List chargée (`5` au premier lancement, en attendant son chargement) | | `IABTCF_gdprApplies` | `1` / `0` | | `IABTCF_PublisherCC` | Code pays de l'éditeur | | `IABTCF_PurposeOneTreatment` | Indicateur de traitement spécifique de la finalité 1 | | `IABTCF_UseNonStandardTexts` | Indicateur de textes non standard | | `IABTCF_TCString` | La chaîne TC | | `IABTCF_VendorConsents` / `IABTCF_VendorLegitimateInterests` | Champs de bits partenaires | | `IABTCF_DisclosedVendors` | Champ de bits des partenaires présentés | | `IABTCF_PurposeConsents` / `IABTCF_PurposeLegitimateInterests` | Champs de bits finalités | | `IABTCF_SpecialFeaturesOptIns` | Opt-in aux fonctionnalités spéciales | | `IABTCF_PublisherRestrictions{ID}` | Restrictions éditeur par finalité | | `IABTCF_PublisherConsent` / `IABTCF_PublisherLegitimateInterests` | Consentement éditeur | | `IABTCF_PublisherCustomPurposesConsents` / `IABTCF_PublisherCustomPurposesLegitimateInterests` | Champs de bits des finalités personnalisées de l'éditeur | **Google** | Clé | Contenu | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | `IABTCF_AddtlConsent` | Chaîne Google Additional Consent | | `IABTCF_EnableAdvertiserConsentMode` | `1` quand la configuration laisse les signaux publicitaires à Google ([Firebase Analytics](#firebase-analytics)), absente sinon | **GPP et CCPA / USP** | Clé | Contenu | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `IABGPP_HDR_GppString` | Chaîne GPP complète | | `IABGPP_GppSID` | Identifiants des sections en vigueur, joints par `_` (par exemple `2`, ou `2_6_7`) | | `IABGPP_HDR_Version` | Version de l'en-tête GPP : `1`, ou `0` tant que la chaîne GPP est vide | | `IABGPP_HDR_Sections` | Identifiants des sections présentes dans la chaîne, joints par `_` | | `IABGPP_[SectionID]_String` | Une clé par section présente : `IABGPP_2_String` (TCF EU v2, la chaîne TC elle-même), `IABGPP_6_String` (US Privacy), `IABGPP_7_String` (US National) | | `IABUSPrivacy_String` | Chaîne US Privacy, par exemple `1YN-`. **Absente tant qu'aucun choix US n'est enregistré** — enregistré depuis l'écran US de l'interface de consentement, ou passé à `setCcpaOptOut()` | Les sections 6 et 7 ne sont présentes que si l'US Privacy s'applique à l'utilisateur et que la configuration ne la désactive pas ; la section 6 exige en plus un choix US enregistré. **Quand les clés apparaissent.** Pendant `initialize()` : `IABTCF_CmpSdkID`, `IABTCF_CmpSdkVersion` et `IABTCF_PolicyVersion`. Une fois la configuration chargée, avant tout choix : `IABTCF_gdprApplies`, de nouveau `IABTCF_PolicyVersion` (tirée de la Global Vendor List chargée), `IABTCF_PublisherCC`, `IABTCF_PurposeOneTreatment`, `IABTCF_UseNonStandardTexts`, les chaînes de bits éditeur, qui portent alors les valeurs par défaut du SDK et non un choix, `IABTCF_EnableAdvertiserConsentMode` quand elle s'applique, et, pour un utilisateur américain, les clés GPP avec la section US National. Seulement une fois un choix enregistré : la chaîne TC, les champs de bits finalités et partenaires, les opt-in aux fonctionnalités spéciales, les restrictions éditeur, `IABTCF_AddtlConsent`, et les clés GPP des autres utilisateurs. `IABUSPrivacy_String` attend un choix US. Pour savoir si un choix est enregistré, testez `IABTCF_TCString`. ## L'API de commandes in-app Les SDK partenaires qui préfèrent l'interface de commandes au stockage brut peuvent appeler l'API TCF in-app — l'équivalent de `__tcfapi` : ```kotlin // Android SirDataCMPApi.tcfApi().execute("ping", 2, { data, _, success -> /* … */ }) SirDataCMPApi.tcfApi().execute("getInAppTCData", 2, { data, _, success -> /* … */ }) SirDataCMPApi.tcfApi().execute("addEventListener", 2, { data, listenerId, success -> /* … */ }) ``` ```swift // iOS IosCMPApi.shared.tcfApi().execute(command: "ping", version: 2, callback: { data, _, success in /* … */ }, parameter: nil) ``` Un écouteur enregistré avec `addEventListener` est rappelé quand la CMP est chargée, quand l'interface de consentement s'affiche, quand un choix est enregistré et quand l'interface se ferme. Le deuxième argument de chaque appel est l'identifiant de l'écouteur, à passer à `removeEventListener`. **En 2.0.0, ces appels ne portent pas d'`eventStatus`.** Le premier argument est la donnée TC courante une fois la CMP chargée, et le nom de l'événement avant ; l'appel fait juste après l'enregistrement porte `"tcloaded"`. Un écouteur ne peut donc pas distinguer `tcloaded`, `cmpuishown`, `useractioncomplete` et `cmpuiclosed` : à chaque appel, relisez les valeurs courantes — les clés `IABTCF_` stockées, ou `getInAppTCData` — plutôt que de vous fier à l'événement reçu. Les interfaces de commandes équivalentes `gppApi()` et `uspApi()` existent ; les événements des écouteurs GPP portent bien leur nom, dans `eventName`. Quand la configuration laisse les signaux publicitaires à Google, `ping` et `getTCData` portent aussi `enableAdvertiserConsentMode: true`, comme sur le web. Listes des commandes : [Référence — Android](/applications-mobiles-sdk-natif/mobile-sdk/reference.md#iab-api-access) et [Référence — iOS](/applications-mobiles-sdk-natif/mobile-sdk/reference-1.md#iab-api-access). ## Adaptateurs de consentement À chaque enregistrement d'un choix — depuis l'interface de consentement, ou par `acceptAll()`, `rejectAll()`, `saveConsent()` ou `submitConsent()` — le SDK traduit le choix TCF en signaux de consentement Google (`ad_storage`, `analytics_storage`, `ad_user_data`, `ad_personalization`) et les transmet à chaque adaptateur dont le SDK est présent dans l'application. Rien à enregistrer, rien à importer : un adaptateur est actif dès que son SDK est lié. | Adaptateur | Ce qu'il transmet | | ------------------ | --------------------------------------------------------------------------------------------------------------- | | Firebase Analytics | Consent Mode v2 (`setConsent`) — voir [Firebase Analytics](#firebase-analytics) | | AppsFlyer | `setConsentData` : application du RGPD, usage des données, personnalisation publicitaire, stockage publicitaire | | Adjust | Consentement à la mesure (`ad_storage`), et les signaux Google DMA en options de partage `google_dma` | | Branch | Suivi désactivé tant que `ad_storage` est refusé, et les signaux Google DMA (`setDMAParamsForEEA`) | * **La transmission a lieu à l'enregistrement d'un choix, pas au lancement.** Firebase, Adjust et Branch gardent d'une session à l'autre ce qu'ils ont reçu en dernier. AppsFlyer ne le garde que pour la session — voir [AppsFlyer](#appsflyer). * **Pour vérifier ce qui a été transmis** : `getRegisteredAdapters()` (les adaptateurs dont le SDK est présent) et `getLastForwardedConsentState()`. * **Un adaptateur en échec le signale** dans les logs — tag Logcat `SirDataCMP` sur Android, `[CMP]` dans la console Xcode sur iOS — par exemple `Consent adapter 'Branch' failed to forward consent: …`. Cela n'affecte ni les autres adaptateurs, ni votre application. * **Builds release Android** : le SDK livre les règles R8 dont ses adaptateurs ont besoin. Rien à ajouter à votre `proguard-rules.pro`. * **iOS** : les adaptateurs s'exécutent dans le SDK, via le runtime Objective-C. Ils fonctionnent de la même façon avec Swift Package Manager et CocoaPods, avec ou sans l'interface de consentement fournie. Un adaptateur est actif quand les classes de son SDK sont liées à l'application — pour Firebase Analytics via Swift Package Manager, c'est l'option d'édition de liens `-ObjC` que Firebase exige déjà. ## Firebase Analytics Aucun code. N'appelez pas `setConsent` vous-même pour les signaux que l'adaptateur transmet : une valeur posée par l'application l'emporte sur celle que Firebase dérive de la chaîne TC. Ce que transmet l'adaptateur dépend de l'option de configuration **Enable TCF/Google Consent Mode Interoperability**, dans la [Console Sirdata](https://cmp.sirdata.io) : * **Désactivée** (par défaut) : les quatre signaux, `analytics_storage`, `ad_storage`, `ad_user_data` et `ad_personalization`, à chaque choix. * **Activée** : `analytics_storage` seul. Le SDK écrit `IABTCF_EnableAdvertiserConsentMode` = `1`, et Firebase dérive lui-même les trois signaux publicitaires de la chaîne TC. C'est ce que fait la CMP web avec la même option. Le moment où Firebase lit la chaîne TC dépend de la plateforme. Sur Android, il la relit dès qu'elle change. Sur iOS, il la lit au lancement de l'application et à son retour au premier plan : avec cette option, un nouveau choix — refus compris — n'atteint les trois signaux publicitaires qu'à ce moment-là. Option désactivée, les quatre signaux sont posés immédiatement sur les deux plateformes : si un refus doit atteindre Firebase immédiatement sur iOS aussi, laissez l'option désactivée. Pour le constater sur Android, activez les logs détaillés de Firebase (`adb shell setprop log.tag.FA VERBOSE`) et enregistrez un choix : avec l'option, Firebase écrit `Consent generated from Tcf`, puis les événements partent avec `consent_signals: G111` après un « Tout accepter » (`G1` + stockage publicitaire + stockage analytics, `1` accordé, `0` refusé). ## AppsFlyer Demandez à AppsFlyer de lire les clés IAB, avant `start()` : ```kotlin // Android AppsFlyerLib.getInstance().enableTCFDataCollection(true) ``` ```swift // iOS AppsFlyerLib.shared().enableTCFDataCollection(true) ``` AppsFlyer envoie alors la chaîne TC stockée avec ses requêtes (`consent_data.tcf`). Au premier lancement, sa requête de lancement part avant tout choix, avec des clés vides, et sur Android il ne les relit pas pendant la session : l'adaptateur comble ce manque en transmettant chaque choix par `setConsentData` (`consent_data.manual`), que portent les requêtes suivantes. ## Adjust et Branch Aucun des deux ne lit les clés IAB ; les adaptateurs leur transmettent chaque choix. Aucun code. Sur Android, initialisez Branch comme d'habitude (`Branch.getAutoInstance(context)` dans `Application.onCreate()`) : avant cela, Branch n'a aucune instance pour recevoir le consentement, et l'adaptateur signale que Branch n'est pas encore initialisé. ## Conditionner un SDK non IAB Conditionnez vous-même les SDK qui ne lisent pas les clés IAB aux finalités ou aux partenaires dont ils dépendent, au démarrage et à chaque changement. L'exemple ci-dessous conditionne Meta à la finalité 1 (stocker des informations sur un appareil et/ou y accéder). Désactivez d'abord le démarrage automatique du SDK : `com.facebook.sdk.AutoInitEnabled`, `com.facebook.sdk.AutoLogAppEventsEnabled` et `com.facebook.sdk.AdvertiserIDCollectionEnabled` à `false` dans le manifeste, chacune sous la forme ``. `getConsentUpdates()` est un signal, pas une liste de décisions : il change à chaque modification des sélections, y compris chaque bascule que l'utilisateur actionne dans l'interface de consentement avant d'enregistrer, ainsi qu'à chaque choix enregistré. Relisez les valeurs stockées à chaque émission, comme ci-dessous — `hasPurposeConsent` lit le stockage, si bien qu'une bascule non enregistrée ne change pas sa réponse. Appelez-le après `initialize`. Un choix US — enregistré sur l'écran US, ou avec `setCcpaOptOut` — ne fait pas avancer le compteur. Si vous conditionnez un SDK aux signaux US, relisez `getUspString()` et `getGppString()` à la fermeture de l'interface de consentement. ```kotlin // Android — getConsentUpdates() émet sa valeur courante, puis à chaque changement des sélections lifecycleScope.launch { SirDataCMPApi.getConsentUpdates().collect { val allowed = SirDataCMPApi.hasPurposeConsent(1) if (allowed) { FacebookSdk.setAutoInitEnabled(true) FacebookSdk.fullyInitialize() } FacebookSdk.setAdvertiserIDCollectionEnabled(allowed) FacebookSdk.setAutoLogAppEventsEnabled(allowed) } } ``` ```swift // iOS — l'observateur réagit à chaque changement, pas au démarrage : appliquer une première fois func applyGate() { let allowed = IosCMPApi.shared.hasPurposeConsent(purposeId: 1) // activer ou désactiver le SDK ici } applyGate() let watcher = UpdateCounterWatcher(flow: IosCMPApi.shared.getConsentUpdates()) watcher.watch { _ in applyGate() } // Gardez `watcher` en vie tant que vous en avez besoin, et appelez watcher.close() ensuite. ``` ## Intégrations Google * **Additional Consent (chaîne AC)** — maintenue dans `IABTCF_AddtlConsent` pour les partenaires publicitaires Google absents de la Global Vendor List du TCF. Lue avec `getAddtlConsent()`. * **Consent Mode** — le SDK dérive l'état de consentement Google des finalités TCF et le transmet à Firebase Analytics, voir plus haut. Inspection via `getGoogleConsentState()`. * **Opt-out CCPA** — `setCcpaOptOut(true)` / `isCcpaOptedOut()` pilotent la chaîne USP et les sections US du GPP pour les parcours « Do Not Sell ». Appelez `setCcpaOptOut` depuis un contrôle que l'utilisateur actionne : il enregistre le choix de l'utilisateur lui-même. L'écran US de l'interface de consentement l'appelle quand l'utilisateur enregistre. ## WebViews Pour du contenu web conditionné au consentement dans une WebView, passez la chaîne TC à la page et exposez-la via le stub `__tcfapi` de la page, ou ajoutez-la à l'URL si votre site l'accepte : ```kotlin val url = "https://example.com/article?gdpr=1&gdpr_consent=${SirDataCMPApi.getTcString()}" ``` ## Checklist 1. Initialiser Sirdata CMP **avant** chaque SDK publicitaire et analytics. 2. Collecter le consentement **avant** de charger la première publicité. 3. SDK conformes IAB, Firebase Analytics, Adjust et Branch : rien d'autre à faire. 4. AppsFlyer : `enableTCFDataCollection(true)` avant `start()`. 5. Autres SDK : les conditionner à `hasPurposeConsent(...)` / `hasVendorConsent(...)`, et réévaluer à chaque émission de `getConsentUpdates()` — et, pour les signaux US, à la fermeture de l'interface de consentement. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://cmp.docs.sirdata.net/applications-mobiles-sdk-natif/mobile-sdk/sharing-consent.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.