Por qué el píxel de Facebook se sigue cargando aunque tus etiquetas estén bloqueadas

Todos los artículos

El píxel de Facebook suele cargarse por uno de estos tres motivos: su código base se ejecuta en el head de tu página antes del banner, su etiqueta se dispara antes de que se fijen tus valores de consentimiento por defecto o la etiqueta nunca exigió consentimiento publicitario. Si los tres están limpios, probablemente el script de otro proveedor esté inyectando el píxel en tiempo de ejecución (‘runtime’), y tu contenedor no puede bloquear una petición que nunca hizo.

Descarta primero las causas habituales

Casi siempre es una de estas.

• El código base del píxel está en el head de tu página sin ningún fbq('consent', 'revoke') por encima, así que se inicializa antes de que se muestre tu banner.
• La etiqueta se dispara con un activador que se ejecuta antes de que se fijen tus valores de consentimiento por defecto, así que no lee ninguna elección.
• La etiqueta nunca se configuró para exigir consentimiento publicitario, así que se dispara pase lo que pase a su alrededor.
• Un contenido incrustado de una red social, un botón de me gusta o un widget de comentarios está fijando sus propias cookies.

Comprueba cada una en una página real, no en el contenedor: cómo comprobar si una etiqueta instala cookies antes del consentimiento explica el método. Si están limpias y las peticiones siguen apareciendo, la causa está fuera de tu contenedor.

Una herramienta de consentimiento bloquea lo que controla tu contenedor

Un píxel publicitario llega a una página por una de tres vías habituales, y una herramienta de consentimiento alcanza cada una de forma distinta. La mayoría de las respuestas publicadas solo contemplan las dos primeras.

La primera es una etiqueta en tu contenedor, que se dispara cuando el estado de consentimiento lo permite. La segunda es un script en el código fuente de tu página, que una herramienta de consentimiento normalmente también puede retener reconociéndolo antes de que el navegador lo ejecute.

La tercera es la que se saltan casi todas las guías. Un script que ya se está ejecutando, y que permitiste legítimamente, carga su propio módulo publicitario en tiempo de ejecución e inyecta el píxel. Tu contenedor nunca hizo esa petición, así que nada que cambies dentro de él la va a frenar.

Así era la tercera vía en las webs de un cliente que auditamos en agosto. Se estaban escribiendo cookies de Meta y LinkedIn antes del consentimiento, y el diagnóstico interno culpaba a las etiquetas del contenedor. En una sesión nueva, con el banner en pantalla y sin hacer clic en nada, las dos etiquetas tenían una condición de almacenamiento publicitario y ninguna se disparó. Las cookies aparecieron igualmente, con los mismos ID de píxel, porque una etiqueta permitida de una plataforma de marketing cargaba su propio archivo de píxel publicitario, que a su vez cargaba las bibliotecas de Meta y LinkedIn. No había nada mal configurado; la frontera no estaba donde todos suponían.

Cómo saber cuál tienes

Unos minutos, sin abrir el contenedor.

1. Abre la web con un perfil nuevo y rechaza todo

   Sin consentimiento guardado, con el panel de red abierto antes del primer pintado y con un rechazo deliberado.

2. Filtra por los hosts propios del píxel

   En el caso de Meta, es connect.facebook.net para la biblioteca y facebook.com/tr para el evento. Mira también el panel Aplicación: una cookie _fbp que aparece en tu propio dominio en esa sesión nueva suele significar que la biblioteca se cargó. Sin peticiones y sin cookie, no tienes este problema.

3. Despliega la cadena de iniciadores y no leas solo la primera línea

   Este es el paso en el que más fácil es equivocarse. Tu gestor de etiquetas aparece a menudo en la cadena porque cargó el script del proveedor mucho antes, y eso no demuestra que una etiqueta del gestor hiciera esta petición. Lo que buscas es la entrada que está justo encima de la llamada al píxel: indica el script que la origina.

4. Compara el contenedor con lo que acabas de ver

   Abre la vista previa y comprueba si se dispararon las etiquetas publicitarias. Que una etiqueta esté en la lista de no disparadas mientras la petición sigue apareciendo no es una contradicción: las dos herramientas describen dos capas distintas.

5. Sigue el script responsable hasta su plataforma

   Encuentra al proveedor que hay detrás y luego su ajuste de integración publicitaria. Es ese ajuste, y no tu configuración de consentimiento, lo que está poniendo el píxel en la página.

Por qué bloquear más en el contenedor no puede funcionar

Parece que avanzas, y por eso sale caro. El equipo añade una condición de consentimiento a las etiquetas publicitarias, luego un activador de bloqueo, luego una excepción, y concluye que la herramienta de consentimiento está rota, cuando todos los cambios fueron a parar a una etiqueta que ya no se estaba disparando.

Separa esto del fallo con el que se confunde. Que tus propias etiquetas se disparen antes de que el banner registre sus valores por defecto es un problema de tiempos, que sí se puede arreglar en el contenedor, y lo explicamos en por qué se disparan las etiquetas antes de que cargue el banner de cookies. Esto es una cuestión de alcance, no de tiempos: tus etiquetas se comportaron correctamente y algo que quedaba fuera de su alcance hizo justo lo que intentabas evitar.

Dónde está de verdad el arreglo

Hay cuatro palancas. La adecuada depende de lo que haga el script del proveedor antes del consentimiento y de en qué categoría debería haber estado el script desde el principio: en qué categoría de consentimiento va cada script de terceros explica esa decisión.

• El portal del propio proveedor. La mayoría de las plataformas que inyectan píxeles publicitarios tienen un ajuste para ello. Desactivar esa integración es lo más limpio: el script sigue haciendo su trabajo legítimo y deja de llevar el píxel de otro.
• Una llamada temprana a consent revoke. fbq('consent', 'revoke'), ejecutada antes de que nada pueda inicializar el píxel, le dice a la biblioteca de Meta que retenga sus eventos, la haya cargado quien la haya cargado. La propia documentación de Meta sobre consentimiento describe las llamadas ‘revoke’ y ‘grant’. Es un último recurso más que una respuesta completa: la biblioteca se sigue cargando, y solo ayuda si tu llamada se ejecuta de verdad la primera.
• La etiqueta del proveedor en tu contenedor. Si una etiqueta tuya carga el script del proveedor, condiciona esa etiqueta al consentimiento publicitario. Es una solución tosca: con los visitantes que rechazan pierdes también todo lo demás que hace ese script, como formularios o chat.
• Bloqueo por categoría en la herramienta de consentimiento. Si el script del proveedor carga fuera de tu contenedor, clasifica el propio script como publicidad para que la herramienta lo retenga antes de que se ejecute. Mismo inconveniente.

Después repite la misma prueba: perfil nuevo, rechazar, filtrar y confirmar que nada llega a los hosts del píxel. Un límite: esto solo lee el navegador, así que todo lo que tus servidores envíen a través de una API de conversiones hay que comprobarlo en el origen. Verificar en el destino y no en el banner es el hábito general, descrito en cómo comprobar que tu banner envía de verdad la señal de consentimiento.

Si también usas Signals Gateway de Meta, filtra además por el subdominio de tu gateway: su píxel es un código aparte que necesita su propia comprobación de consentimiento, y lo explicamos en cómo hacer que Meta Signals Gateway respete el consentimiento de cookies.

Velo retiene los scripts que marcas con una categoría de consentimiento hasta que se concede esa categoría; un píxel que inyecta otro proveedor sin esa marca sigue habiendo que rastrearlo hasta el proveedor.