¿Qué es el Píxel de Seguimiento?

Técnicamente, un píxel de seguimiento es una etiqueta <img> cuyo atributo src apunta a un servidor de terceros en lugar de a una imagen real del sitio. El navegador o el cliente de correo la carga como cualquier otra imagen, sin necesidad de JavaScript, y esa simple petición HTTP queda anotada en el servidor de destino con la IP, el user agent, la hora y, si la URL lleva parámetros, el identificador de la campaña o del mensaje.

El nombre confunde a menudo con el de la cookie, pero son dos cosas distintas: el píxel es el mecanismo que dispara la petición, la cookie es el fichero que guarda un identificador entre visitas. La mayoría de los píxeles actuales, como el de Meta o el Insight Tag de LinkedIn, ya no cargan como una imagen de 1x1. Funcionan como una etiqueta de JavaScript que hace ambas cosas a la vez: envía el evento al servidor y además lee o escribe una cookie para reconocer al mismo navegador más adelante. El nombre "píxel" se ha quedado por costumbre, aunque la tecnología detrás haya cambiado.

Se usa sobre todo para tres cosas: confirmar la apertura de un correo, registrar la llegada a una página de destino tras un clic en un anuncio, y construir listas de remarketing con los visitantes que estuvieron en una página concreta.

Los tres términos se mezclan a menudo en la misma frase, pero resuelven partes distintas del mismo problema.

El canal técnico cambia entre las tres opciones, pero la obligación de pedir consentimiento se mantiene igual en todas.

Cuando el navegador procesa el HTML de la página o del correo, encuentra la etiqueta del píxel y lanza una petición GET al servidor indicado en el src. El servidor solo necesita devolver una imagen mínima, casi siempre transparente de 1x1; lo que importa es la petición en sí, que queda anotada con la marca de tiempo, la IP y el resto de cabeceras HTTP. Si la URL incluye un parámetro con el identificador del correo o de la campaña, esa anotación se asocia directamente a ese envío.

Los píxeles basados en JavaScript, como el de Meta o Google Ads, van un paso más allá: además de disparar la petición, pueden leer una cookie ya existente en el dominio del anunciante o escribir una nueva. Así se reconoce al mismo navegador en visitas posteriores y se construyen las audiencias de remarketing. Ese paso depende por completo de que el navegador permita guardar y leer esa cookie entre sitios distintos, y ahí es donde el panorama de 2026 se ha vuelto desigual: Safari bloquea las cookies de terceros por defecto desde la versión 13.1 en 2020, Firefox lo hace desde 2019 con su protección de seguimiento activada para todos los usuarios, y Chrome, tras años anunciando que las eliminaría, dio marcha atrás en julio de 2024 y confirmó en octubre de 2025 que las mantiene y retira en su lugar la mayoría de las tecnologías de Privacy Sandbox que iban a sustituirlas.

Por eso ha crecido el tracking del lado del servidor como complemento: el propio servidor del anunciante envía el evento directamente a la plataforma mediante una API, como la Conversions API de Meta o las Enhanced Conversions de Google Ads. Esto evita que un bloqueador del navegador impida el envío, aunque el dato sigue siendo información personal que llega a un tercero y necesita la misma base legal que el píxel clásico.

De los datos que capta el píxel dependen decisiones de presupuesto real: si una conversión no se registra porque el píxel no se disparó, esa campaña parece menos rentable de lo que fue y el dinero se mueve hacia donde sí hay datos, no necesariamente hacia donde hay resultados.

Hay también un riesgo legal directo. Disparar un píxel que transmite datos personales antes de que el usuario haya dado su consentimiento incumple el artículo 5.3 de la Directiva ePrivacy, y autoridades como la CNIL francesa han sancionado precisamente este patrón. Es la diferencia entre una campaña bien montada y una que expone a la empresa a una multa.

La fragmentación entre navegadores complica además la comparación entre campañas: la misma acción puede mostrar cifras distintas en Chrome que en Safari, un efecto técnico ligado a cuántos eventos capta cada navegador. Migrar a un tracking del lado del servidor exige más trabajo de implementación al principio, pero ese esfuerzo suele traducirse en datos más estables a medio plazo.

Por el reparto desigual entre navegadores y por la presión regulatoria, cada vez más empresas priorizan datos de primera parte y tracking del lado del servidor para no depender solo de una cookie que un navegador puede bloquear en cualquier momento.

• Conecta el píxel con el banner de consentimiento (CMP) a nivel técnico, para que la petición no salga del navegador hasta que el usuario acepte de verdad.
• Documenta cada píxel activo en la política de cookies con el nombre real del proveedor, no con una categoría genérica como "publicidad".
• Prioriza el tracking del lado del servidor para las conversiones que realmente mueven el presupuesto, en vez de depender solo del píxel del navegador.
• Revisa con regularidad qué píxeles siguen cargando en el sitio; los de una campaña ya cerrada solo añaden riesgo sin aportar ningún dato útil.
• Comprueba con las herramientas de red del navegador que ningún píxel se dispara antes de que el usuario acepte el consentimiento.
• Evita meter datos identificables, como el correo en claro, en los parámetros de la URL del píxel.

• Disparar el píxel antes de que el usuario acepte el banner de cookies, el fallo que más sanciones ha generado.
• Asumir que el tracking del lado del servidor no necesita consentimiento por no depender de una cookie, cuando sigue transmitiendo datos personales.
• Depender solo de un píxel basado en cookies de terceros para las audiencias de remarketing, sin ningún plan para Safari o Firefox.
• No incluir el píxel en el registro de actividades de tratamiento ni en la política de privacidad del sitio.
• Dar por hecho que Chrome eliminó las cookies de terceros, cuando la propia Google confirmó en 2025 que las mantiene.