Decodificador de TC string

Qué es una TC string, en la práctica

La TC string es el justificante que deja el CMP cuando alguien acepta, rechaza o guarda una selección en el aviso europeo. Casi siempre está en la cookie euconsent-v2. Abres las cookies de un sitio con ese aviso, buscas un valor largo que empieza por C, y eso es la cadena.

El formato es un campo de bits escrito con el alfabeto base64url: de la A a la Z, de la a a la z, dígitos, y los signos - y _. Los seis primeros bits son la versión. TCF 2 guarda ahí un 2, y seis bits son justo un carácter, así que la primera letra sale C. Por eso casi todas las cadenas de ahora empiezan así. Detrás van dos fechas, contadas en décimas de segundo desde el 1 de enero de 1970: cuándo se creó la cadena y cuándo la reescribió el CMP por última vez. Luego el id del CMP, el número de versión interno de ese CMP, la pantalla en la que se guardó la elección y el idioma del aviso. Cada letra de ese idioma es un número del 0 (A) al 25 (Z).

Después viene la versión de la Global Vendor List con la que se montó el aviso, y la versión de la política TCF de esa misma lista. IsServiceSpecific tiene que valer 1. Un 0 significa que, según la política, un vendor debe dar la cadena por inválida, aunque el resto de bits se puedan leer. UseNonStandardTexts vale 1 cuando el CMP cambió los textos estándar de los propósitos o las ilustraciones. PurposeOneTreatment vale 1 cuando el propósito 1 no se mostró de la forma habitual. PublisherCC es el país cuya ley el medio toma como referencia: dos letras, con la misma codificación que el idioma.

Los propósitos ocupan veinticuatro bits de consentimiento y otros veinticuatro de interés legítimo. El propósito 1 es el primer bit de cada fila: guardar o acceder a información en un dispositivo. Solo están nombrados del 1 al 11. Desde TCF 2.2, los propósitos 3, 4, 5 y 6 (perfiles de publicidad y de contenido) no pueden ir por interés legítimo, y esos cuatro bits tienen que estar a 0. Las special features van en otra fila de 12 bits. Las dos que existen hoy son la geolocalización precisa y el análisis de características del dispositivo para identificarlo. Un 1 significa que el usuario lo activó.

Luego van el consentimiento por vendor y el interés legítimo por vendor. Cada lista empieza por el id de vendor más alto que cubre, y un indicador: un bit por id, o una serie de rangos. Los rangos ocupan menos cuando la selección es dispersa, que es lo normal en una lista larga. Un vendor que no aparece en una lista por rangos no tiene señal. El id es el número de la Global Vendor List, no el nombre de la empresa. IAB Europe republica esa lista a menudo, y esta página deja el número. Los nombres están en https://vendor-list.consensu.org/v3/vendor-list.json para la lista vigente, y en https://vendor-list.consensu.org/v3/archives/vendor-list-v{version}.json para la versión que trae la cadena. Cruzar el fichero de hoy con una cadena vieja pone el nombre equivocado en vendors que ya se dieron de baja.

Las restricciones del publisher cierran el segmento principal. Cada una nombra un propósito, un tipo de restricción y los ids de vendor a los que aplica. El tipo 0 quiere decir que el medio no permite ese propósito para esos vendors. El tipo 1 exige consentimiento, también cuando el vendor registró el propósito como interés legítimo y lo marcó como flexible. El tipo 2 exige interés legítimo. El contador de restricciones siempre está, también cuando es cero.

Los puntos parten la cadena en segmentos. El primero es el núcleo y no lleva tipo: empieza por la versión. Cada segmento siguiente abre con un tipo de 3 bits. El tipo 1 es Disclosed Vendors, los ids que el CMP enseñó de verdad. Desde TCF 2.3 ese segmento es obligatorio, porque un vendor que solo declara special purposes no tenía otro sitio donde el CMP pudiera marcarlo como mostrado. El tipo 3 es el Publisher TC: los propósitos que el medio pide para sí mismo, más los propósitos propios que haya definido. El tipo 2 es el segmento viejo de Allowed Vendors, el del diseño out-of-band. Los CMP actuales no lo escriben. Si una cadena antigua todavía lo trae, se lee y se etiqueta aparte.

La virgulilla queda fuera del TCF. Todo lo que va después de ~ es el Additional Consent de Google: un número de versión y luego ids ATP separados por puntos. Los CMP lo pegan a la misma cookie para que la etiqueta de anuncio pueda leer proveedores que no están en la Global Vendor List. Esta página separa ese final y lista los ids. No llama a Google y no resuelve esos ids.

De dónde copiarla

1. En Chrome: DevTools, Application, Cookies, y el sitio. Copia el valor de euconsent-v2. Si el CMP guardó el Additional Consent en la misma cookie, no cortes lo que va detrás de la virgulilla.
2. En una página con el CMP cargado, en la consola: __tcfapi("getTCData", 2, function (data) { console.log(data.tcString); }). tcString es el núcleo más los segmentos separados por puntos. Si el CMP rellena también addtlConsent, ese valor es el que va detrás de la virgulilla.
3. Las peticiones de puja suelen repetir el mismo valor en gdpr_consent o euconsent. Una URL larga se corta. Una cadena cortada falla aquí con un aviso de que se acaba antes de tiempo. La copia fiable es la de la cookie.

Cómo leer el resultado

Las fechas salen en tu idioma y otra vez en UTC. Creada es la primera vez que se guardó esta elección. Última actualización se mueve cuando el CMP reescribe la cadena, también en un refresco de la lista de vendors.

La línea del CMP nombra unas cuantas empresas de la lista actual de CMP de IAB Europe: Usercentrics (5), Sourcepoint (6), Didomi (7), OneTrust (28), consentmanager (31), Sirdata (92), Cookiebot (134) y Google (300). Cualquier otro id se queda en número. Entran empresas y cambian de nombre, y un nombre inventado es peor que el id.

La tabla son los propósitos del 1 al 11. Sí significa que ese bit está activo. El interés legítimo de los propósitos 3 a 6 tiene que estar apagado en una cadena hecha con TCF 2.2 o posterior. Si lo ves encendido, el CMP que escribió la cadena no siguió esa regla.

Cada bloque de vendors enseña el recuento, el id máximo, si fue bit a bit o por rangos, y después los ids. A partir de 200 ids el resto se cuenta y no se imprime, para que un aceptar-todo no deje la pestaña colgada. Si falta el segmento de Disclosed Vendors, hay una línea que lo dice. En una cadena de TCF 2.3 ese segmento tiene que estar.

Preguntas que salen con esta cadena

¿Dónde está guardada la TC string?

En la cookie euconsent-v2, en casi todos los CMP que implementan TCF 2. Algunos stacks la meten también en la URL de la puja. Cópiala de la cookie cuando puedas. Un valor sacado de una URL larga suele llegar cortado, y una cadena cortada no se decodifica.

¿Por qué empieza por C?

La versión es el número 2, guardado en seis bits. Seis bits son un carácter de base64url, y el carácter del valor 2 es la C. Una cadena de TCF 1 empieza por otra letra porque el número de versión es otro. Esta página solo abre la versión 2.

¿Qué cambia entre la columna de consentimiento y la de interés legítimo?

El consentimiento es un bit que activó el usuario. El interés legítimo es un bit que pone el CMP cuando enseñó ese propósito bajo interés legítimo y el usuario no se opuso. El vendor tiene que mirar además su ficha en la Global Vendor List. Un propósito registrado como consentimiento no queda cubierto por el bit de interés legítimo.

¿Qué es el propósito 1?

Guardar o acceder a información en un dispositivo. Es el propósito de las cookies y del almacenamiento parecido, y la política TCF pide consentimiento. PurposeOneTreatment, más arriba en la misma cadena, le dice al vendor si el CMP mostró el propósito 1 de la forma normal. Junto con el país del publisher, así decide si en ese país sigue haciendo falta un sí para el propósito 1.

¿Por qué hay puntos en medio?

Cada punto abre otro segmento. El núcleo va primero. Detrás suele venir Disclosed Vendors y, en algunos sitios, el Publisher TC. El orden de esos segmentos posteriores da igual, porque cada uno empieza por su tipo.

¿Qué es el texto de después de la virgulilla?

El Additional Consent de Google. El primer número es la versión de AC y luego va una lista de ids de proveedores ATP. Los CMP lo guardan al lado de la TC string para que la etiqueta de Google pueda leer las dos cosas. No es un segmento TCF y no va en base64.

¿Se sube lo que pego?

No. El script de esta página lee la caja y escribe el resultado debajo. No hay ninguna petición que lleve la cadena. Cierras la pestaña y desaparece.

¿Sirve para una cadena de TCF v1?

No. La versión 1 tiene otro diseño. Si los seis primeros bits no son un 2, la página se para y enseña la versión que ha encontrado.

La lista de vendors son solo números. ¿Dónde están los nombres?

La cadena guarda ids. Los nombres viven en la Global Vendor List de la versión que sale junto a Lista de vendors. El fichero vigente es https://vendor-list.consensu.org/v3/vendor-list.json y uno antiguo es https://vendor-list.consensu.org/v3/archives/vendor-list-v{version}.json, con la versión de la cadena en el sitio de {version}. La lista de hoy contra una cadena vieja le pone el nombre de otro a los vendors dados de baja.

¿Qué es un id de CMP?

Un número que IAB Europe asigna a la empresa que recoge el consentimiento. No es el medio, y no es un id de vendor de la Global Vendor List. La versión de CMP que va al lado es el número de build de esa empresa. Es el campo que quieres cuando un fallo solo sale en una release de su aviso.