Vendors fantasma y terceros silenciosos- Post 3 — Serie 2 (Cookies/CMP/UX)

Posted on by Leocadio Marrero Trujillo

 

Vendors fantasma y terceros silenciosos

Lo que tu CMP declara, lo que tu web ejecuta… y lo que nadie ve (CDN, fonts, embeds, conversion APIs)

Hay un problema que aparece una y otra vez cuando revisas una web “con ojos de auditoría”: la CMP cuenta una historia y la red cuenta otra.

  • La CMP declara 40 vendors… pero en tráfico aparecen dominios que no figuran en ningún sitio.
  • O al revés: la CMP declara 200 vendors “por si acaso”… y la web realmente usa 15.
  • O el banner parece correcto… pero hay terceros “silenciosos” (CDN, fuentes, embeds, widgets, conversion APIs) que se activan antes de cualquier elección.

A esto lo llamamos, sin dramatismo: vendors fantasma y terceros silenciosos. Y es el tipo de desajuste que te deja sin defensa, porque en inspección no vale “yo no sabía”: vale lo que ocurre.

1) Dos conceptos que aclaran todo

Vendor fantasma

Algo que aparece en tu CMP (en tu lista de proveedores/finalidades), pero no se observa realmente en el tráfico de tu web/app.

Problema típico: CMP sobredimensionada por plantillas, configuraciones “default” del proveedor o vendors heredados.

Tercero silencioso

Algo que sí se observa en tráfico (dominio/endpoint/SDK), pero no está declarado o no está bien clasificado en la CMP.
Ejemplos clásicos: CDN/WAF, fuentes externas, embeds (mapas/vídeo), chat widgets, anti-fraude, APM/crash reporting, y cada vez más, conversion APIs del lado servidor.

2) Por qué esto importa de verdad (y no es “perfeccionismo”)

Porque el estándar práctico que se está consolidando es que rechazar sea tan fácil como aceptar y que el consentimiento sea real, no cosmético. La CNIL, por ejemplo, ha reiterado esa exigencia y ha emitido órdenes por banners que no permiten rechazar con la misma facilidad. (cnil.fr)

Y, además, la AEPD insiste en guías técnicas orientadas a evidencias y responsabilidades reales cuando la analítica la presta un tercero (lo que en la práctica te obliga a controlar configuración “en producción”, no solo el texto del banner). (Agencia Española de Protección de Datos)

3) Dónde se esconden los “terceros silenciosos” (lista útil)

Te dejo los lugares más comunes donde se cuelan sin que nadie lo “sienta” como tracking:

  1. CDN / WAF / DDoS: logs, cabeceras, IP, telemetría.
  2. Fuentes e iconos externos (Google Fonts u otros): requests “inofensivos” que igualmente contactan con terceros.
  3. Embeds: YouTube/Vimeo, mapas, widgets sociales, reviews.
  4. Chat y soporte: scripts que se cargan “siempre” por plantilla.
  5. Analítica y A/B testing: especialmente cuando se activa pre-consent por error.
  6. Session replay / heatmaps: si están mal configurados, el riesgo se dispara.
  7. Conversion APIs / server-side tagging: parece “menos cookies”, pero puede mantener seguimiento y transferencias por otras vías.
  8. SDKs en app: a menudo se olvida inventariarlos y condicionarlos.

No todos son ilegítimos. El problema es otro: que existan sin gobierno, sin clasificación y sin evidencia.

4) El método que no falla: “declarado vs observado” (en 30–45 minutos)

Este post no busca que te conviertas en ingeniero. Busca que tengas un método repetible y defendible.

Paso 1 — Extrae lo “declarado”

  • Exporta (o captura) la lista de finalidades y vendors de la CMP.
  • Si la CMP lo permite, guarda el “vendor list” y la configuración por categorías.

Paso 2 — Extrae lo “observado”

  • Haz el protocolo Pre / Accept / Reject del Post 2, pero aquí céntrate en dominios/endpoints.
  • Puedes hacerlo con HAR o con capturas de Network.

Paso 3 — Cruza y clasifica

Crea una tabla simple (y que puedas mantener):

Dominio/endpoint observadoPreRejectAcceptFigura en CMPCategoría CMPProveedor realAcción
ejemplo-cdn.comSíSíSíNo/SíNecesaria/—CDN/WAFDeclarar/Justificar
ejemplo-analytics.comSíSíSíSíAnalíticaAnalyticsBloquear/Condicionar
ejemplo-ads.comNoSíSíSí/NoMarketingAdsRevisar/Eliminar

Cómo interpretar rápido

  • Observado en Pre y no es estrictamente necesario → alerta alta.
  • Observado en Reject cuando debería estar bloqueado → “rechazar” no funciona.
  • Figura en CMP pero nunca aparece → vendor fantasma (limpieza pendiente).
  • Aparece y no figura → tercero silencioso (declaración y gobierno pendientes).

5) Qué suele estar roto

Esto te ahorra horas de discusiones internas:

Caso A — CMP bien, pero Tag Manager mal

La CMP registra elección, pero el Tag Manager dispara igual. Resultado: tercero silencioso en Reject.

Caso B — Tag Manager bien, pero scripts hardcoded

Hay scripts en el <head> o plugins que se cargan antes del consentimiento. Resultado: tercero silencioso en Pre.

Caso C — La CMP está “inflada”

Incluye vendors por defecto o por paquetes, pero tu web no los usa. Resultado: vendor fantasma que ensucia transparencia y complica auditorías.

6) Qué hacer

No intentes arreglar todo a la vez. Prioriza por impacto.

  1. Cierra Pre: cualquier tercero no necesario que aparezca antes de elegir es prioridad 1.
  2. Arregla Reject: si rechazar no bloquea, tu banner es indefendible (aunque sea bonito).
  3. Limpia vendor fantasma: reduce vendors declarados a lo que realmente usas (mejora claridad y reduce riesgo).
  4. Clasifica terceros “técnicos” (CDN, WAF, fuentes, embeds): decide si son necesarios, cómo se justifican y cómo se documentan.
  5. Versiona y prueba: cada cambio cierra con evidencia (Pre/Accept/Reject + tabla actualizada).

7) Evidencia mínima “lista para inspección”

Si solo guardas una cosa, guarda esto por release o por trimestre:

  • Tabla “declarado vs observado” (con acciones y fechas)
  • 3 HAR (o capturas Network) por 2 páginas críticas: Pre / Accept / Reject
  • Capturas de configuración CMP (categorías/vendors)
  • Control de cambios (qué se tocó en CMP/Tag Manager y cuándo)

Si quieres subir nivel, hay tooling específicamente pensado para auditoría web y recolección de evidencias que permite repetir pruebas con método y exportar resultados, útil tanto para equipos internos como para auditorías. (edpb.europa.eu)

Cierre

Los banners fallan menos por mala intención y más por falta de gobierno del ecosistema: nadie mira el conjunto.
Cuando cruzas lo declarado con lo observado, el problema se vuelve visible, cuantificable y corregible.

 

Siguiente post (Post 4):
“CDN, fuentes y embeds: cómo decidir qué es ‘necesario’, qué exige consentimiento y cómo documentarlo sin autoengaños”
(Con ejemplos prácticos y un mini árbol de decisión.)

Bibliografía y recursos (selección)

  • CNIL — Refusing cookies should be as easy as accepting them (acciones y órdenes). (cnil.fr)
  • CNIL — Dark patterns in cookie banners (enfoque y recordatorios clave). (cnil.fr)
  • AEPD — Guía cookies analíticas externas (roles, evidencias y configuración real). (Agencia Española de Protección de Datos)
  • AEPD — Guía sobre el uso de las cookies (marco general y orientaciones). (Agencia Española de Protección de Datos)
  • EDPB — Website Auditing Tool (auditoría web con evidencia). (edpb.europa.eu)
  • EDPS — Website Evidence Collector (automatización de recolección de evidencia). (GitLab)
Leocadio Marrero Trujillo