- Los bloqueadores de anuncios usan listas de filtros para detener los scripts de píxel y sus solicitudes, de modo que la plataforma publicitaria no recibe ningún evento de ese navegador.
- Un píxel bloqueado pierde las visitas de página, los eventos de añadir al carrito y las compras, y la compra es lo que más importa porque determina el ROAS que se informa y las pujas.
- Las compras enviadas desde el servidor a partir de los datos de tus pedidos no se ven afectadas, porque el navegador del comprador no las envía.
- Mide tu propia brecha comparando los pedidos web de tu tienda con los eventos Purchase que envió el píxel del navegador, no con las conversiones atribuidas.
- El server-side tracking no puede recuperar eventos de navegación ni click ids que nunca se guardaron, y la recopilación first-party reduce esa pérdida.
Los bloqueadores de anuncios impiden el tracking porque evitan que el script de píxel de la plataforma publicitaria, o las solicitudes que envía, se cargue en el navegador del comprador. Cuando eso ocurre, la plataforma nunca se entera de la visita a la página, del añadido al carrito ni de la compra, aunque el pedido esté en tu tienda. Las compras enviadas desde el servidor a partir de los datos de tus pedidos no se ven afectadas, porque el navegador del comprador no interviene en su envío.
Esta guía explica cómo funcionan los bloqueadores de anuncios y las funciones de privacidad de los navegadores, qué eventos pierde tu tienda, qué recupera el server-side tracking y qué no. Termina con una forma sencilla de medir la brecha en tu propia tienda.
¿Cómo frenan los bloqueadores de anuncios los píxeles de tracking?
La mayoría de los bloqueadores de anuncios funcionan con listas de filtros. Una lista de filtros es una larga lista de reglas que coinciden con direcciones web: dominios, rutas y nombres de archivo de scripts de anuncios y de tracking conocidos. Cuando una página pide al navegador que cargue algo que coincide con una regla, el bloqueador cancela la solicitud.
Las listas más conocidas son EasyList, para anuncios, y EasyPrivacy, para tracking. Funcionan con extensiones como Adblock Plus, AdBlock, uBlock Origin y AdGuard. El píxel de una gran plataforma publicitaria es un objetivo fácil para estas listas, porque carga el mismo script desde el mismo dominio en muchos sitios distintos.
Navegadores con protección integrada
Algunos navegadores bloquean los rastreadores sin necesidad de una extensión. Brave activa sus Shields en todos los sitios de forma predeterminada, y los Shields bloquean los anuncios de terceros, los rastreadores y las cookies entre sitios. Firefox bloquea el contenido de dominios de seguimiento entre sitios conocidos en las ventanas privadas, y los usuarios pueden elegir ajustes más estrictos que se apliquen a todas las ventanas. La Intelligent Tracking Prevention de Safari bloquea todas las cookies de terceros y acorta la vida de las cookies que crean los scripts. Nuestra guía sobre Safari ITP y tracking publicitario explica esos límites.
Bloqueadores a nivel de red
Algunas personas bloquean los rastreadores en un dispositivo entero o en toda la red doméstica, con un bloqueador basado en DNS o con una VPN con filtro de rastreadores. Estos bloquean las solicitudes a dominios de tracking en todos los navegadores y apps de esa red. Cambiar de navegador no modifica el resultado.
¿Qué eventos pierde tu tienda?
Cuando el píxel está bloqueado, se pierde todo evento que habría enviado desde ese navegador. El daño no es igual para todos los eventos.
| Evento | Para qué se usa | ¿Se pierde cuando se bloquea el píxel? | ¿Pueden sustituirlo los datos de los pedidos? |
|---|---|---|---|
| PageView, ViewContent | Audiencias de visitantes del sitio, retargeting de productos | Sí | No |
| AddToCart, InitiateCheckout | Optimización hacia compradores que inician una compra, retargeting del carrito | Sí | No |
| Purchase | Conversiones informadas, ROAS, optimización de compras, pujas basadas en valor | Sí | Sí |
| Click id en la landing page | Vincular la compra con el clic exacto del anuncio | Sí, cuando el script de tracking también está bloqueado | No, debe guardarse en el navegador |
Perder eventos de navegación reduce el tamaño de tus audiencias de retargeting. Perder compras hace más daño. La plataforma informa de menos conversiones, el ROAS del informe de anuncios baja y el algoritmo de puja aprende de menos compradores. Entonces una campaña rentable puede parecer no rentable y puede que la recortes.
Por qué los eventos server-side basados en los datos de los pedidos no se bloquean
Un bloqueador de anuncios funciona dentro del navegador del comprador. Solo puede detener las solicitudes que hace el navegador. Cuando la compra se envía desde los datos de pedidos de tu tienda, la solicitud va de un servidor a la API de la plataforma publicitaria. El navegador del comprador no forma parte de ese recorrido, así que el bloqueador no tiene nada que cancelar.
14:02:11 PageView pixelBloqueado por una lista de filtros en el navegador14:09:47 Purchase pixel order-1042Nunca se envía, porque el script del píxel no se cargó14:09:52 webhook order-1042 paidLa tienda informa del pedido pagado al servidor14:10:12 Purchase server order-1042Enviado a la Conversions API con el email y el teléfono con hashDespués, la plataforma vincula la compra con una persona a partir de los datos del evento: el email y el teléfono con hash del pedido, la dirección IP y el user agent, y el click id si se guardó uno. Nada de esto pasa por el bloqueador. Para ver el recorrido completo de los datos, lee qué es el server-side tracking.
¿Qué no puede recuperar el server-side tracking?
El click id necesita el navegador
El pedido en sí está a salvo, pero el vínculo con el clic del anuncio se establece en el navegador. Un script tiene que leer el click id de la URL de llegada y guardarlo. Si un bloqueador de anuncios también bloquea ese script, el pedido llega sin click id. La plataforma aún puede vincular la compra mediante los datos de cliente con hash, pero la coincidencia es menos fiable.
Dos cosas reducen esta pérdida. La primera, recopilar los eventos first-party: servir el script de tracking y sus solicitudes desde tu propio dominio, por ejemplo mediante un proxy de app de Shopify o un subdominio de tu sitio. Las listas de filtros apuntan a direcciones de tracking de terceros conocidas, así que una ruta first-party es mucho más difícil de bloquear, aunque no imposible. La segunda, usar la landing page que algunas tiendas online, como Shopify, guardan con cada pedido. Si esa URL aún contiene el click id o las UTM, el pedido se puede atribuir sin ningún evento del navegador.
Los eventos de navegación se siguen perdiendo
Los datos de pedidos contienen pedidos, no visitas de página. Enviar compras a partir de los pedidos no recupera las visitas de página ni los eventos de añadir al carrito de un visitante cuyo navegador bloqueó todo. Un recolector first-party puede reenviar estos eventos desde el servidor cuando sus propias solicitudes llegan.
Rechazar el consentimiento no es bloquear
Un visitante que rechaza las cookies de marketing en tu banner de cookies no es lo mismo que un visitante con un bloqueador de anuncios. El primero tomó una decisión que tu tracking debe respetar. Con Respect visitor consent activado, ROASaurus no asigna ningún id de visitante a ese visitante, así que sus clics en anuncios y sus visitas no se vinculan con él. Sus eventos del navegador se conservan sin id de visitante, dirección IP ni datos del navegador, y no se envían a las plataformas publicitarias. El pedido pagado sí se sigue enviando desde el servidor, con los datos de cliente con hash del pedido y la dirección IP y el user agent del pedido. Mantén separados los dos grupos cuando midas tu pérdida y consulta consentimiento y privacidad para ver los detalles.
Cómo estimar tu propia pérdida
No necesitas promedios del sector, que dependen de la audiencia, el dispositivo y el país. Puedes medir tu propia brecha comparando los pedidos de tu tienda con las compras que informó el píxel del navegador en el mismo periodo.
- Elige un periodo y una plataforma
Usa 14 o 30 días y una sola plataforma, por ejemplo Meta. Usa la misma zona horaria en ambos sistemas.
- Cuenta los pedidos web de tu tienda
Empieza con todos los pedidos. Quita los pedidos que nunca pasan por tu checkout online: los de punto de venta, los manuales y los borradores, las renovaciones de suscripción y los pedidos de prueba.
- Cuenta los eventos Purchase del navegador
En la herramienta de eventos de la plataforma, cuenta los eventos Purchase que envió el píxel del navegador. Es más fácil hacerlo antes de añadir eventos del servidor. Si los eventos del servidor ya están activos, usa la vista por método de conexión de la plataforma cuando la ofrezca. Events Manager de Meta muestra el método de conexión de cada evento y cuenta ahí los eventos antes de la deduplicación. No uses las compras atribuidas del informe de anuncios.
- Divide
Compras del navegador ÷ pedidos web es la proporción que vio el píxel. El resto es tu brecha.
- Separa el consentimiento del bloqueo
Estima los pedidos de los visitantes que rechazaron las cookies de marketing con la tasa de rechazo de tu herramienta de consentimiento. Lo que queda son sobre todo bloqueadores de anuncios, ajustes de privacidad y páginas que no se cargaron.
| Tienda de ejemplo, 30 días | Pedidos | Proporción de pedidos web |
|---|---|---|
| Todos los pedidos de la tienda | 1,240 | |
| Pedidos de punto de venta, manuales y de renovación | −90 | |
| Pedidos web | 1,150 | 100% |
| Eventos Purchase del píxel del navegador | 874 | 76% |
| Brecha | 276 | 24% |
| Pedidos estimados de visitantes que rechazaron el consentimiento (10% de tasa de rechazo) | 115 | 10% |
| Resto: bloqueadores de anuncios, ajustes de privacidad, páginas que no se cargaron | 161 | 14% |
La brecha también afecta al ROAS. Supón que Meta informa de un ROAS de 2.0 para esta tienda y que su ROAS de equilibrio es 2.3. Con los datos del píxel, las campañas pierden dinero. Si los pedidos generados por anuncios se perdieron con la misma tasa del 24% que todos los pedidos web, el píxel solo vio el 76% de los ingresos de los anuncios. El ROAS real sería entonces de aproximadamente 2.0 ÷ 0.76 = 2.6, por encima del equilibrio. Es una estimación máxima, porque no todos los pedidos que faltan venían de un anuncio. Nuestra guía sobre el ROAS de equilibrio explica cómo fijar ese umbral.
Cómo reducir lo que pierdes
Las soluciones son las mismas para cualquier plataforma de tienda online. Funcionan mejor combinadas.
- Envía las compras a partir de los datos de los pedidos. Así se cierra la brecha de compras en todas las plataformas que conectes, sea cual sea lo que bloquee el navegador del visitante.
- Mantén el píxel, con un id de evento compartido. Los visitantes sin bloqueador siguen enviando eventos del navegador con cookies y contexto de la página. El mismo id de evento en ambas copias permite que la plataforma se quede con una sola. Consulta cómo evitar el doble conteo.
- Recopila first-party. Sirve el script de tracking y sus eventos desde tu propio dominio, para que se guarden los click ids de más visitantes.
- Envía datos de cliente con hash. El email y el teléfono del pedido permiten que la plataforma vincule las compras que no tienen click id.
- Vuelve a medir. Repite la comparación un mes después. Los eventos Purchase que recibe la plataforma ya deberían coincidir con tus pedidos web.
Cómo gestiona ROASaurus los bloqueadores de anuncios
ROASaurus envía cada pedido pagado desde el servidor a las plataformas publicitarias que añadas en Tracking & platforms, así que un bloqueador de anuncios en el navegador del comprador no detiene la compra. En Shopify, los eventos de la tienda pasan por el proxy de app de Shopify en el dominio de tu propia tienda. También puedes servir el script y sus eventos desde un subdominio CNAME de tu sitio. Cuando de un visitante no hay ninguna interacción en el navegador, la atribución de ROASaurus recurre a los click ids y las UTM de la URL de llegada del pedido, cuando la tienda la registra, como hace Shopify.
Cada envío y la respuesta de la plataforma aparecen en el Event log, así que puedes comprobar que cada pedido llegó a cada plataforma. Para la configuración, consulta server-side tracking y la integración con Shopify.
Fuentes
- EasyList: Overview
- Brave: Brave Shields
- MDN Web Docs: Firefox tracking protection
- WebKit: Tracking Prevention in WebKit
- Meta for Developers: Verifying Your Setup