Por qué las analíticas no funcionan en Brave (y qué hacer al respecto)

Brave Shields bloquea Google Analytics, Tag Manager y la mayoría de trackers de terceros por defecto — pero la forma en que lo hace deja la pérdida invisible en tu panel. Qué ocurre realmente a nivel de red, por qué nunca ves un error, y qué opciones tienes.

Brave ya no es un navegador minoritario

Brave ha superado los 80 millones de usuarios activos mensuales a nivel global. Para audiencias técnicas, preocupadas por la privacidad o adyacentes al mundo cripto, su cuota de navegador se sitúa habitualmente entre el 5% y el 15% — a veces más. Si publicas contenido técnico, vendes SaaS para desarrolladores, o tu producto va dirigido a una audiencia consciente de la privacidad, una parte significativa de tus visitantes está usando Brave ahora mismo.

Y por defecto — recién instalado, sin tocar ninguna configuración — Brave bloquea la inmensa mayoría de los scripts de analítica.

Qué hace realmente Brave Shields

Brave Shields no es un único mecanismo, son tres capas de protección aplicadas en este orden:

1. Bloqueo a nivel de red — para trackers que aparecen en EasyList, EasyPrivacy y las listas propias de Brave, la petición nunca sale del navegador. En DevTools verías (blocked:other) o (cancelled) sin código de estado.
2. Redirección a un stub vacío — para algunos scripts populares (incluyendo partes del ecosistema de Google), Brave devuelve una respuesta local vacía con HTTP 200 para evitar romper la página. La página no falla; el script simplemente no hace nada. La visita nunca se registra en tu analítica, pero en DevTools la petición parece "exitosa".
3. Aleatorización de huella digital — para todo lo que sí se carga, Brave altera las señales de canvas, WebGL, audio context y enumeración de fuentes para que tu tracker no pueda construir una huella estable del visitante.

La capa 2 es la que pilla a la mayoría de propietarios de sites desprevenidos. Abres DevTools, ves que la petición a GA4 devuelve 200 OK, y asumes que el tracking funciona. No funciona — el script que descargó el navegador es el stub vacío que devolvió Brave, no el gtag.js real. Ningún dato sale de la página.

Por qué tu panel nunca te avisa

Los productos de analítica no miden su propia ausencia. Google Analytics te muestra las visitas que recibió. No puede mostrarte las visitas en las que el script nunca se cargó — esos visitantes, desde la perspectiva de GA4, son indistinguibles de gente que no visitó.

No hay log de error, no hay asterisco, no hay aviso de "tu alcance está reducido". El número en tu panel simplemente es más pequeño que la realidad en una cantidad que depende de la composición de tu audiencia. Para una audiencia tipo Hacker News, esa diferencia puede superar el 40%. Para un site generalista, sigue siendo del 5–15%.

Por eso al migrar de GA4 a una herramienta de analítica privacy-first los números suelen subir. No porque la nueva herramienta cuente de más — porque la anterior llevaba años contando de menos en silencio.

Qué puedes hacer

Opción 1: aceptar la diferencia, ajustar las decisiones

Si tu audiencia es mayoritariamente no técnica y tu proporción de usuarios con ad-blocker es baja (digamos por debajo del 10%), la respuesta más simple es reconocer el undercount y no sobreinterpretar pequeñas diferencias en tu panel de GA4. No tomes decisiones de ranking sobre números que sabes que están incompletos.

Opción 2: server-side tracking

Mueve el measurement protocol de GA4 al servidor. Tu código en el cliente envía eventos a tu propio endpoint, que los reenvía a Google. Brave no bloquea tu dominio.

El problema: el GA4 server-side es genuinamente complejo de configurar correctamente, el consentimiento GDPR sigue aplicando (sigues recolectando los mismos datos personales, solo cambias el transporte), y sigues necesitando un banner de cookies. Has resuelto el problema del bloqueador pero conservas todos los demás.

Opción 3: un tracker privacy-first y resistente a bloqueadores

Existe una categoría de productos de analítica construidos en torno a no aparecer en las listas de bloqueo en primer lugar. Plausible, Fathom, GoatCounter y Logly siguen este planteamiento con compromisos ligeramente distintos.

El patrón común: un endpoint first-party en un dominio que no está en EasyPrivacy, sin cookies (luego sin banner de consentimiento), y un tracker lo suficientemente pequeño como para que mantenerlo en una lista de bloqueo no merezca el esfuerzo. Los pings salen, la petición devuelve 204 (sin contenido), y no hay nada que la capa de redirección de Brave pueda sustituir.

Validamos Logly contra Brave Shields en Standard y Aggressive, además de uBlock Origin con EasyPrivacy, como gate de release. Si una futura versión de Brave empieza a bloquearnos, el gate falla y lo arreglamos antes de deployar. Otras herramientas de esta categoría hacen validaciones similares.

¿Cuánto cambia esto realmente tus números?

Cálculo aproximado para un site con audiencia técnica que recibe 10.000 visitas reales al mes:

• ~12% de visitantes usan Brave o tienen bloqueo agresivo activado → 1.200 visitas perdidas en silencio.
• De las 8.800 restantes, ~25% usa uBlock u otro bloqueador → otras 2.200 perdidas.
• Lo que registra GA4: ~6.600 visitas. Te falta aproximadamente un tercio de tu audiencia.

Para un site generalista los números se comprimen (menos Brave, menos uBlock) pero rara vez verás más del 90% del tráfico real, y a menudo bastante menos.

Si tomas decisiones de producto, marketing o contratación sobre tráfico que está 25–35% por debajo de la realidad, vale la pena conocer esa diferencia — aunque no cambies de herramienta mañana mismo.