Ce qu’est réellement le TC string

L’IAB Transparency & Consent Framework produit un seul jeton compact — le TC string — qui voyage avec chaque requête publicitaire et indique aux fournisseurs exactement ce avec quoi un utilisateur est et n’est pas d’accord. Il est encodé en Base64-URL et compacté au niveau du bit, il ressemble donc à du charabia (CPxy...AAA) mais encode un enregistrement précis et auditable.

Les segments

Un TC string complet se compose de plusieurs segments séparés par des points. Le premier est le core string ; les autres sont facultatifs :

• Core — le CMP ID, la version du CMP, les horodatages de consentement, la version de la politique et, surtout, les champs de bits des consentements de finalité et des consentements de fournisseur.
• Disclosed vendors — quels fournisseurs ont été présentés à l’utilisateur.
• Publisher TC — les consentements propres à vous, l’éditeur.

Les champs de bits sont l’essentiel : le bit N défini à 1 signifie consentement pour la finalité N ou le fournisseur N. La finalité 1 est “stocker/accéder à des informations sur un appareil”, les finalités 3 et 4 couvrent les publicités personnalisées, et ainsi de suite.

Décoder une chaîne en pratique

Vous décodez rarement les bits à la main. Utilisez les bibliothèques fournies par l’IAB ou un décodeur public :

• Découpez sur . et décodez en Base64-URL le segment core.
• Lisez les champs d’en-tête de largeur fixe (version, created, lastUpdated, cmpId, cmpVersion).
• Parcourez les champs de bits des finalités et des fournisseurs pour voir exactement lesquels sont accordés.

En JavaScript, l’appel __tcfapi('getTCData', 2, cb) renvoie l’objet déjà analysé — tcData.purpose.consents et tcData.vendor.consents sont des cartes id → booléen. C’est votre vérité de terrain à l’exécution.

Les erreurs qui tuent les revenus

Lorsque la demande personnalisée disparaît silencieusement, le TC string en est généralement la raison :

• Chaîne manquante — la requête publicitaire ne porte aucun gdprApplies/TC string, donc les SSP conformes basculent vers le non personnalisé.
• Fournisseur non consenti — le bit de l’ID de fournisseur de votre partenaire de la demande est à 0, il ne peut donc pas enchérir avec personnalisation.
• Chaîne expirée ou obsolète — un ancien horodatage pousse les plateformes en aval à s’en méfier.
• Mauvais CMP ID — un CMP ID non enregistré ou de test invalide toute la chaîne.

Un flux de débogage

Reproduisez le consentement de l’utilisateur, récupérez le TC string en direct depuis __tcfapi ou la requête publicitaire, passez-le dans un validateur et comparez les finalités/fournisseurs décodés à ce que vos partenaires exigent. Neuf fois sur dix, l’écart est un seul bit de fournisseur ou une finalité 1 manquante.

Où FlexyConsent intervient

FlexyConsent génère des TC strings conformes à la spécification avec un CMP ID enregistré, les maintient à jour, expose l’état décodé pour le débogage et signale quelles finalités et fournisseurs sont réellement accordés sur l’ensemble de votre trafic — afin que vous puissiez voir, et non deviner, où le consentement (et les revenus) fuient.

Points clés à retenir

• Le TC string est un enregistrement compacté au niveau du bit et auditable de chaque choix de consentement.
• Les champs de bits des finalités et des fournisseurs déterminent si les partenaires peuvent diffuser des publicités personnalisées.
• La plupart des baisses de revenus se ramènent à une chaîne manquante, un fournisseur non consenti ou un CMP ID obsolète/invalide.
• Décodez la chaîne en direct avec __tcfapi et validez-la par rapport aux exigences des partenaires lors du débogage.