"Mis tags parecen bien configurados, pero mis números se sienten más bajos que la cantidad real de visitantes." Una causa común son los ad blockers y las funciones de prevención de tracking que detienen tus tags de medición. Como no es un error de configuración, es difícil detectarlo en tus dashboards — y tus números pierden silenciosamente justo a los usuarios que están bloqueando.
¿Te suena familiar alguno de estos casos?
- Tu conteo de usuarios en GA4 se siente más bajo que el tráfico que realmente ves
- Tus logs de acceso del servidor y los conteos de sesiones de GA4 claramente no coinciden
- Tu pixel de Meta o tag de conversión no se dispara para algunos usuarios
- Los usuarios más técnicos o con navegadores específicos parecen desaparecer de tu medición
Esta guía explica cómo los ad blockers bloquean realmente tus pixels y tags, por qué las conversiones se subcontabilizan, por qué es difícil medirlo con precisión, y hasta qué punto puedes mitigarlo — desde la perspectiva de alguien que lo vive en el día a día. También separaremos esto del rechazo en consent mode, que es un factor distinto.
Principio básico: los ad blockers bloquean solicitudes específicas
El error fácil es pensar que un ad blocker simplemente "oculta banners publicitarios". En realidad, la mayoría de los ad blockers y funciones de prevención de tracking bloquean las solicitudes que tu página envía a dominios externos de medición desde el principio. Ocultar banners es solo una parte de lo que hacen.
Así es como las herramientas más comunes aplican su bloqueo:
| Herramienta / función | Cómo bloquea |
|---|---|
| uBlock Origin / extensiones AdBlock | Bloquea solicitudes a dominios listados en listas de filtros |
| Brave Shields (integrado en el navegador) | Bloquea solicitudes a trackers por defecto |
| Firefox Enhanced Tracking Protection (ETP) | Bloquea según listas de trackers conocidos |
| Extensiones de bloqueo de contenido de Safari | Bloquea solicitudes que coinciden con reglas de filtrado |
Muchas de estas comparten listas de filtros públicas como EasyPrivacy. Estas listas contienen un gran conjunto de dominios "conocidos por medición y tracking", y el navegador verifica las solicitudes contra la lista al cargar la página y detiene las que coinciden.
Qué se bloquea: los dominios reales
Los dominios que las listas de filtros suelen bloquear son exactamente los que usamos para medición.
google-analytics.com… solicitudes de medición de GA4 (collect, etc.)googletagmanager.com… Google Tag Manager (el contenedor de GTM mismo)googleadservices.com… tracking de conversiones de Google Adsfacebook.com/tr… envío de eventos del pixel de Meta
Eso significa que cuando el contenedor de GTM mismo no puede cargar, todos los tags de GA4, ads y Meta dentro de él pueden dejar de funcionar juntos. El fenómeno de "el tag está implementado correctamente, pero nunca se dispara para ciertos usuarios" suele ser esto.
Error común: mirar tu propia pestaña Network y concluir "
collectse está disparando, así que todo está bien" puede simplemente significar que tú no tienes un bloqueador instalado. Abre la misma página en un navegador con un bloqueador activado, y esa solicitud puede desaparecer por completo.
Cómo las conversiones se subcontabilizan
Lo que hace tan complicados a los ad blockers es que no se manifiestan como un "error". Cuando una solicitud es bloqueada, el navegador trata ese evento como si nunca hubiera existido. Desde el punto de vista del tag, simplemente "no se disparó" — sin advertencia, sin log de error.
El resultado son dos cosas.
1. Los resultados de los usuarios que bloquean se pierden por completo
Cuando un usuario con ad blocker convierte, ese evento nunca llega a Google o Meta. El resultado realmente ocurrió, pero en tus reportes nunca sucedió.
2. Tus datos se sesgan hacia el segmento "sin bloqueo"
Lo que queda contabilizado es solo a los usuarios sin bloqueador. Así que tus números se convierten en una imagen sesgada de solo una parte de tu audiencia. Esto importa más que un simple "el conteo bajó": tus tasas de conversión y el análisis de audiencia se sesgan por completo hacia los usuarios sin bloqueador.
Error común: "Mi producto es B2B o de tecnología, pero GA4 se siente más bajo que la realidad." Los usuarios técnicos y con mayor conciencia de privacidad tienden a tener mayor adopción de bloqueadores, así que en algunas industrias la pérdida golpea con más fuerza.
No puedes saber con precisión cuánto se está bloqueando
Esta es la parte más espinosa del problema de los ad blockers. No hay forma de saber con precisión "qué porcentaje de mi propio sitio está bloqueado" desde el lado del tag de medición. La razón es simple: los eventos bloqueados nunca llegan, así que no se pueden contar desde el principio.
Las cifras de adopción varían ampliamente entre estudios y cambian según navegador, región, industria y dispositivo. Precisamente por eso no deberías fijarte en "es X por ciento" — necesitas aproximar tu propia situación con medición real.
Una aproximación comúnmente usada es esta comparación:
- Logs de acceso del servidor … la página en sí se sirve, así que esto está cerca del alcance real
- Medición del lado del cliente (GA4, etc.) … sale más baja exactamente en la cantidad bloqueada
La brecha entre ambos te da un sentido aproximado de escala de cuántos usuarios están bloqueando tus tags (trátalo como una estimación, ya que los bots y otros factores también entran en juego).
Benchmarks de la industria: cuánto se está bloqueando
Aunque no hay un número universal (varía según audiencia, región y dispositivo), los datos de la industria de 2025–2026 ofrecen benchmarks útiles:
| Segmento | Adopción aproximada de ad blockers |
|---|---|
| Promedio global (todos los dispositivos) | 25–30% de las sesiones web |
| Usuarios de escritorio | 30–40% |
| Usuarios móviles | 10–15% (más bajo porque los navegadores móviles tienen menos opciones de extensiones) |
| Audiencias técnicas / de desarrolladores | 50–70% |
| Mercados de la UE / con alta conciencia de privacidad | 35–45% |
Impacto en el tracking de conversiones: Con un 25–30% de sesiones bloqueadas, las plataformas suelen registrar entre 20–40% menos conversiones de las que realmente ocurren. En el caso de Meta específicamente — cuyos dominios de pixel están entre los más agresivamente atacados por las listas de filtros — la brecha puede ser incluso mayor.
Estos números son orientativos, no definitivos. El punto es: si no has medido tu propia brecha (logs del servidor vs. analytics del lado del cliente), es posible que estés subreportando conversiones de forma significativa sin saberlo.
Hasta dónde puedes mitigarlo: server-side tagging
¿Puedes prevenirlo? No por completo — pero puedes mitigar parte de ello. El enfoque líder es el server-side tagging.
La medición normal en el navegador envía solicitudes directamente desde el navegador del usuario a dominios como google-analytics.com, lo que los convierte en blancos fáciles para las listas de filtros. Con server-side tagging, los datos primero van a tu propio dominio first-party (por ejemplo, analytics.tusitio.com), y luego el servidor los reenvía a Google o Meta.
- Como el destino es tu propio dominio, los filtros que solo miran el nombre de dominio tienen menos probabilidad de bloquearlo
- Pero no es una bala de plata. Los bloqueadores son conscientes de esta técnica, y los filtros más avanzados han comenzado a detectar y bloquear también la medición first-party
En resumen, el server-side tagging es una mitigación que "evade algunos bloqueadores", no una solución que "recupera todo". No te sobre-esperances.
El enfoque híbrido: cliente + servidor con deduplicación
La mejor práctica real en 2026 no es "cliente o servidor" — es ambos, con deduplicación. Así es como funciona:
- Mantén tus tags del lado del cliente (GA4, Meta Pixel, Google Ads) funcionando con normalidad
- Añade tracking del lado del servidor en paralelo (sGTM, Meta CAPI, etc.)
- Etiqueta cada evento con un
event_idúnico (otransaction_idpara compras) - La plataforma publicitaria recibe el evento desde ambos caminos y deduplica usando el ID
Por qué funciona: Para usuarios sin bloqueador, ambos caminos se disparan y la plataforma deduplica — no hay doble conteo. Para usuarios con bloqueador, el camino del cliente falla silenciosamente pero el camino del servidor tiene éxito — la conversión se sigue capturando.
Meta recomienda explícitamente este patrón para CAPI: ejecutar Pixel + CAPI juntos, enviar el mismo event_id, y dejar que Meta maneje la deduplicación. Google admite lo mismo con Enhanced Conversions y sGTM.
Bloqueo a nivel DNS: lo que ni siquiera el server-side puede arreglar
Una categoría creciente de bloqueo opera a nivel DNS, antes de que el navegador siquiera haga una solicitud:
- Pi-hole — bloqueador DNS a nivel de red que bloquea dominios de tracking para todos los dispositivos en la red
- NextDNS / AdGuard DNS — servicios DNS en la nube con listas de filtros integradas
- Bloqueo DNS integrado en el navegador — algunos navegadores resuelven dominios de tracking a
0.0.0.0
El bloqueo a nivel DNS puede derrotar el enrutamiento por dominio first-party si la lista de filtros del servicio DNS incluye tu subdominio de medición (por ejemplo, analytics.tusitio.com). La adopción actual es baja (estimada en 2–5% de los usuarios), pero está creciendo en segmentos con alta conciencia de privacidad.
Qué significa esto en la práctica: Siempre habrá un segmento de usuarios que no podrás rastrear con ningún mecanismo del lado del cliente. La respuesta no es un arreglo técnico — es construir tu estrategia de medición para tolerar un margen de conversiones no medidas, usando los datos del backend como fuente de verdad para los conteos totales.
Este es un factor distinto al rechazo en consent mode
Estos son fáciles de confundir, así que separémoslos. "La medición baja" tiene dos fuentes ampliamente distintas.
| Factor | Qué ocurre |
|---|---|
| Ad blockers | La solicitud se bloquea físicamente del lado del navegador del usuario, independientemente de la configuración de consentimiento de tu sitio |
| Rechazo en consent mode | El usuario no consiente, así que el comportamiento del tag queda restringido — un mecanismo y una solución distintos |
Como ocurren de forma independiente, atender solo uno deja las pérdidas del otro intactas. El mecanismo y la verificación del lado de consent mode se cubren en un artículo separado (este está enfocado en ad blockers). Ten en cuenta también que ITP (Intelligent Tracking Prevention) de Safari es de la misma familia de factores — medición perdida del lado del navegador.
Cómo verificar "si me están bloqueando" en producción
Método 1: Abre la página en un navegador con un bloqueador activado
La verificación más intuitiva.
- En un navegador con uBlock Origin (o Brave), abre la página que quieres verificar
- Abre la pestaña "Network" en DevTools y filtra por
collect,googletagmanager,facebook.com/tr, etc. - Revisa si las solicitudes se envían o se bloquean (las bloqueadas suelen aparecer como fallidas o canceladas)
- Compara con el bloqueador desactivado, y verifica qué solicitudes desaparecen
Método 2: Concilia los logs del servidor con la medición del cliente
Como se mencionó antes, comparar el alcance del lado del servidor con los conteos de sesiones de GA4 (etc.) te permite estimar la escala del bloqueo. Aunque no sea una cifra exacta, te dice si es una escala que no puedes ignorar o si está dentro del margen de error.
Lo que revisar en tu propia máquina no te puede decir
Los métodos anteriores son útiles, pero probar una sola vez en tu propia PC tiene dos puntos ciegos específicos de los ad blockers:
- Tu entorno no es el entorno de tus usuarios en producción. Quien ejecuta la prueba muchas veces tiene el bloqueador desactivado para desarrollo, o siempre activado — en cualquier caso, las condiciones difieren de las de los visitantes reales. Lo que ves en tu "una máquina" es solo una de las innumerables combinaciones de navegador/extensión/configuración. Los usuarios reales llegan con configuraciones que nunca probaste.
- Reproducir algo con un clic en un anuncio conlleva riesgo de política de auto-clic. Para ver rigurosamente "cómo se trata a un usuario que llegó vía un anuncio y usa un bloqueador", necesitarías hacer clic en un anuncio real para recrear el camino — lo cual conlleva el riesgo de una violación de política publicitaria por auto-clic.
Las pérdidas por ad blockers ocurren en el entorno de "la otra persona que usa un bloqueador", no en el de "tú, que lo desactivaste". El hecho de que se vea bien en tu máquina es precisamente lo que oculta la pérdida.
Un checklist para verificar con confianza
- ¿Confirmaste que las solicitudes de medición se disparan en un navegador con un bloqueador activado?
- ¿El contenedor de GTM (
googletagmanager.com) mismo no está siendo bloqueado? - ¿Las solicitudes de GA4 (
google-analytics.com) no están siendo bloqueadas? - ¿El pixel de Meta (
facebook.com/tr) se está disparando? - ¿Estimaste la escala aproximada del bloqueo a partir de la brecha entre logs del servidor y medición del cliente?
- ¿Consideraste tu industria y audiencia (los usuarios con perfil técnico tienden a mayor adopción)?
- ¿Estás enmarcando correctamente el server-side tagging como una mitigación, no una bala de plata?
- ¿No estás confundiendo el rechazo en consent mode con el bloqueo de ad blockers?
Preguntas frecuentes
P. ¿Cuánto reducen las conversiones los ad blockers? R. No hay una respuesta única. La adopción varía según los estudios y cambia mucho según navegador, región, industria y dispositivo. Por eso, en lugar de fijar un porcentaje específico, el enfoque práctico es estimar tu propia escala a partir de la brecha entre tus logs del servidor y la medición del cliente.
P. Si no muestro banners publicitarios, ¿los ad blockers no me afectan? R. No. Independientemente de si muestras banners publicitarios o no, la mayoría de los bloqueadores bloquean las solicitudes a los dominios de medición y tracking mismos. Un sitio que solo usa GA4 o un pixel de Meta también se ve afectado.
P. Si cambio a server-side tagging, ¿puedo recuperarlo todo? R. No. Enrutar a través de un dominio first-party evade algunos bloqueadores, no todos. Los filtros avanzados han comenzado a detectar también la medición first-party. Trátalo estrictamente como una mitigación.
P. ¿Ser "rechazado" en un banner de consentimiento es lo mismo que ser bloqueado por un bloqueador? R. No — son factores distintos. El rechazo en consent mode significa "el comportamiento del tag está restringido porque el usuario no consintió"; un ad blocker significa "la solicitud se bloquea físicamente del lado del navegador del usuario". Los mecanismos y las soluciones difieren, y ambos pueden ocurrir a la vez.
P. ¿Puedo ver en mi dashboard si me están bloqueando? R. No. Los eventos bloqueados nunca llegan, así que los dashboards de GA4 y de ads ni siquiera registran que algo "falta". Por eso mismo necesitas verificarlo visualmente en un navegador con un bloqueador activado y conciliarlo contra los logs del servidor.
Conclusión: verifica con "el usuario en producción que usa un bloqueador", no con "tú, que lo desactivaste"
Las pérdidas por ad blockers no aparecen en tus dashboards, porque no son un error de configuración — y tus números pierden silenciosamente exactamente al segmento que bloquea. Lo que importa es verificar — hasta el nivel de cada solicitud individual — cómo se tratan tus solicitudes de medición en el entorno real de un usuario con un bloqueador activado.
ConversionOK ejecuta tu página en vivo en un navegador independiente y aislado e intercepta las solicitudes de tags de medición y pixels que realmente se envían, para luego verificarlas — sin necesidad de hacer clic en tu propio anuncio y sin interferencia de tu entorno de oficina. Empieza con una revisión estática gratuita para confirmar que el punto de entrada de tu medición se sostiene incluso antes de que entren en juego los bloqueadores.
Artículos relacionados