Adblock-immune por construcción

Los adblockers bloquean por URL. La URL de Beaconry es tu propio sitio WordPress. No hay un dominio o ruta que un adblocker pueda bloquear sin romper WordPress mismo.

El problema

Las herramientas de analítica del lado del navegador (Meta Pixel, gtag.js, el TikTok Pixel, el LinkedIn Insight Tag) cargan su propio JavaScript desde dominios third-party: connect.facebook.net, googletagmanager.com, analytics.tiktok.com, snap.licdn.com. Las filter lists de adblockers como EasyPrivacy tienen esos dominios dentro. Cualquiera con uBlock Origin, Brave Shields, Pi-hole o AdGuard instalado nunca llega a cargar el script. El evento de conversión nunca se dispara.

Las soluciones server-side TMS (GTM Server-Side, Stape) mueven el dispatch al servidor pero siguen necesitando un bootstrap del lado del navegador. Típicamente usan un subdominio custom como tags.tudominio.com que resuelve a un worker de Stape. En cuanto las filter lists pillan el patrón (y lo hacen, en pocas semanas tras cualquier patrón de onboarding de Stape volviéndose popular), vuelven a ser detectables por el adblocker.

Cómo Beaconry esquiva eso

El endpoint es /wp-json/beaconry/v1/event. Corre dentro de tu instalación WordPress, en tu propio dominio.

• Dominio: el dominio de tu propio sitio, no un third-party.
• Path: un sub-path de /wp-json/, el namespace REST API de WordPress. Cada sitio WordPress usa /wp-json/ para su propio admin interno, búsqueda, comentarios, ajustes de tema.
• Payload: JSON custom (forma específica de Beaconry), no el wire format de ningún pixel. Las filter lists basadas en contenido tampoco pueden identificarlo como tracking.

Un adblocker que bloquease /wp-json rompería:

• La búsqueda core de WordPress 6.x (usa /wp-json/).
• El editor de bloques de WordPress (usa /wp-json/wp/v2/).
• La mayoría de los temas modernos de WordPress (usan /wp-json/ para AJAX).
• Comentarios, "load more posts", cualquier patrón AJAX-driven.

Ningún maintainer de filter-list va a publicar una regla que rompa WordPress para los millones de sitios legítimos que usan /wp-json/.

Lo que esto significa en números

Los datos del sector sugieren que entre el 25 y el 30 por ciento del tráfico web usa alguna forma de ad-blocker. Eso es una cuarta parte de tus conversiones invisibles para ti cuando dependes de pixels del lado del navegador. Beaconry recupera todas: cada visitante que da consentimiento de analytics tiene su conversión capturada server-side, sin importar qué extensión o blocker a nivel de DNS use.

Lo que NO hace a Beaconry adblock-immune

• El modo híbrido para cualquier canal vuelve a introducir el browser pixel de la plataforma. Los adblockers van a bloquear esos bytes en el cable como antes. Beaconry deduplica, así que los visitantes afectados por adblocker siguen teniendo su evento server-side rastreado, pero la ventaja de la cookie first-party del modo híbrido se pierde para ese visitante en concreto.
• El propio banner de consentimiento se carga desde tu propio dominio, pero el visitante todavía debe aceptar el consentimiento de analytics para que cualquier evento se dispare. Si rechaza, Beaconry se queda en silencio. Eso es GDPR, no un problema de adblocker.

Cómo verificarlo

Abre tu sitio en un navegador con uBlock Origin activado, visita cualquier página, abre DevTools, pestaña Network. Deberías ver:

• Peticiones POST a /wp-json/beaconry/v1/event en tu propio dominio. Status 202.
• Cero peticiones a connect.facebook.net, googletagmanager.com, analytics.tiktok.com (a menos que el modo híbrido esté activado para ese canal).

Eso es el test entero. Si las peticiones POST llegan a /wp-json/beaconry/v1/event, los eventos también llegan a las plataformas.