Por qué el "tracking server-side" sigue perdiendo el 25 % de las conversiones por adblockers

La mayoría de setups etiquetados como "server-side" siguen arrancando desde un dominio externo en el navegador. Las filter lists pillan cualquier patrón en semanas, en cuanto se vuelve popular. La solución no es un fallback más rápido, es same-origin desde el primer byte.

El malentendido del "server-side"

"Tracking server-side" suena como una descripción de dónde ocurre el dispatch. En la práctica casi siempre describe dónde se declara el dispatch. La secuencia real en una página "server-side" típica sigue siendo:

1. El navegador carga https://tags.cliente.com/gtm.js (un script externo, aunque el subdominio parezca first-party).
2. El script dispara eventos desde el navegador, dirigidos al mismo endpoint externo.
3. Ese endpoint reenvía el evento a Meta, Google, TikTok servidor a servidor.

El reenvío del paso 3 sí es server-side. Pero el paso 1 es el punto de entrada, y es exactamente donde opera cada filter list de adblocker. Si tags.cliente.com está en la lista, el script no carga. Si el script no carga, el evento no se dispara. El reenvío servidor a servidor es irrelevante porque nada llegó al servidor.

Cómo funcionan realmente las filter lists

EasyPrivacy y listas similares se mantienen de forma colaborativa. Los nuevos patrones de tracking se reportan, revisan y añaden en días, no meses. Las listas se sincronizan con uBlock Origin, Brave Shields, AdGuard, Pi-hole y otros con un ciclo de refresco de 4 a 24 horas. Para cuando un patrón de tracking es lo bastante popular como para importar, también lo es como para haber sido reportado.

Las reglas exactas varían, pero la firma típica incluye: subdominios de tracker conocidos (analytics., tags., track.), rutas de CDN externas conocidas, huellas reconocibles del contenido del script (Meta Pixel, gtag.js, firmas de bytes del TikTok Pixel). Cuando un patrón coincide con cualquiera de estas reglas, el request se descarta a nivel de red antes de llegar a tu servidor.

Lo que esto significa para los setups "server-side": en el momento en que se reconoce tu patrón, tu alcance cae exactamente la tasa de adblockers de tu audiencia. Las estimaciones del sector la sitúan entre 25 y 30 por ciento en la web abierta, más alta en audiencias B2B/dev (35-50 por ciento), más baja en retail mainstream (15-20 por ciento).

El patrón DNS de Stape

La solución de Stape es apuntar un subdominio del cliente como tags.tutienda.com mediante CNAME a un worker alojado por Stape. Desde la perspectiva del navegador, el request parece first-party: va a tu dominio. Desde la perspectiva del adblocker, depende de si la filter list ha pillado el patrón "tags.* CNAME-apunta-a-stape.io".

Durante un tiempo esto es genuinamente mejor que el patrón de dominio externo. Pero los responsables de las listas acaban notando el patrón. La detección de CNAME-cloaking es una capacidad conocida (Brave Shields la trae activa por defecto, uBlock como opt-in, NextDNS lo hace en servidor). Una vez activada, el request se bloquea en la misma capa DNS que antes.

La respuesta de Stape es rotar dominios de worker. El resultado es un juego del gato y el ratón en el que cada nuevo patrón Stape consigue unas pocas semanas de margen antes de aparecer en las listas. Los clientes siguen siendo técnicamente alcanzables, pero la varianza en la resistencia a adblockers a lo largo del tiempo es incómoda para cualquiera que haga performance-marketing a escala.

El patrón GTM Server-Side / Cloud Run

La respuesta oficial server-side de Google es GTM Server-Side, típicamente desplegado en Cloud Run con un subdominio propio del cliente como server.tutienda.com. Funcionalmente similar a Stape, con dos diferencias prácticas: (a) operas la infraestructura tú mismo (precios de Cloud Run, DNS, renovación SSL), y (b) escribes tus propias plantillas de tag.

La resistencia a adblockers sigue la misma dinámica que Stape. El subdominio personalizado ayuda durante un tiempo; la detección de CNAME-cloaking acaba pillándolo. El coste añadido, $30 a $500/mes por el contenedor de Cloud Run, más tiempo de ingeniería en plantillas de tag, es significativo para clientes individuales pequeños y medianos.

Qué significa "first-party desde el primer byte"

La única salida es asegurarse de que el primer request que el navegador envía, el script de entrada, no esté en ninguna filter list y no tenga un patrón que probablemente acabe en una.

"First-party" en este sentido fuerte significa: same-origin con la propia página, servido desde la instalación de WordPress del cliente, en una ruta que el core de WordPress usa para su propio AJAX. Sin subdominio, sin CNAME, sin CDN externo, sin firma reconocible en el contenido del script.

El test honesto: abre el sitio en un navegador con uBlock Origin activo, visita una página, observa la Network tab. Si ves un POST exitoso a una ruta de tu propio dominio, el tracking funciona. Si ves un request fallido a cualquier otro dominio, el tracking no funciona para los usuarios con adblocker en ese canal.

Por qué /wp-json/beaconry/v1/event esquiva los adblockers estructuralmente

El endpoint de Beaconry es POST /wp-json/beaconry/v1/event en tu propio dominio. Tres propiedades lo hacen estructuralmente resistente a adblockers:

• Same-origin: el request va al mismo dominio del que se sirve la página. Sin subdominio, sin CNAME.
• Namespace REST genérico de WP: /wp-json/ es la ruta que el core de WordPress usa para su propio block editor, búsqueda, comentarios, "cargar más posts" y miles de plugins de terceros con AJAX. Cualquier filter list que bloquee /wp-json/ rompería un cuarto de la web pública de WordPress.
• Payload JSON personalizado: el body es la forma propia de Beaconry, no el wire format de Meta Pixel ni GA4 ni TikTok Pixel. Las reglas de filtro basadas en contenido tampoco pueden identificarlo como tracking.

La combinación es lo que hace que aguante. Las reglas basadas en dominio no pueden apuntar a /wp-json/ por dominio del cliente. Las reglas basadas en contenido no pueden hacer pattern-match con el payload. La única forma de bloquearlo sería una regla genérica "bloquea todos los POST a /wp-json/", lo que destrozaría WordPress para cualquier sitio que lo use.

Números

El volumen de conversión recuperado es exactamente la tasa de adblockers de tu audiencia. Concretamente:

• Un sitio B2B SaaS con 1.000 leads/mes a 100 € de valor de lead, 35 % de tasa adblock: ~350 leads × 100 € = 35.000 €/mes invisibles para tu reporting.
• Una tienda e-commerce retail con 5.000 pedidos/mes a 60 € de pedido medio, 20 % de tasa adblock: ~1.000 pedidos × 60 € = 60.000 €/mes que nunca llegan a Meta o Google para optimización.
• Un sitio de medios con 50.000 altas de newsletter/mes a 5 € de valor LTV-atribuido, 30 % de tasa adblock: ~15.000 altas × 5 € = 75.000 €/mes silenciosamente perdidos.

Prueba la calculadora de alcance en la página de inicio con tus propios números. La cifra es lo que sigue siendo invisible para tu reporting hoy, mes a mes, hasta que mueves el dispatch fuera de los dominios externos de tracking.

Para llevar

La etiqueta "tracking server-side" describe lo que pasa después de cargar el script de entrada. La pérdida por adblockers ocurre antes. Si te importa el 25-30 por ciento de conversiones que ahora mismo no ves en Meta o Google, la pregunta correcta a cualquier proveedor no es "¿es vuestro dispatch server-side?", sino "¿a qué URL envía el navegador el primer request?". Si la respuesta incluye un subdominio, un CNAME o cualquier dominio externo, la resiliencia es alquilada.