Actualizado el 21 may 2026

Cuando el seguimiento entre dominios se rompe en silencio

Un pico alarmante de tráfico directo parecía una historia de privacidad. Mira Wise explica cómo resultó ser un seguimiento entre dominios roto, y cómo dividir el número en tercios rescató la confianza de la dirección.
Sophie Steffen

Presentado por:

Sophie Steffen
Mira Wise

Invitado/a:

Mira Wise

Producido por

MarTech Tools Team

Algunos fallos de reporting llegan con sirenas. Este llegó como un número que era simplemente un poco demasiado grande para ignorarlo. En el podcast Let’s Talk Marketing, la líder de revenue operations Mira Wise le contó a Sophie Steffen la historia de un pico de tráfico directo que parecía una pulcra historia de privacidad y resultó ser un bug de seguimiento escondido detrás de una. Es un caso práctico útil sobre resistirse a la explicación cómoda.

La explicación conveniente era falsa

El contexto era un lanzamiento reciente de HubSpot. HubSpot deja caer un píxel de seguimiento en tu web, el píxel pone una cookie, y la cookie es donde se definen todas las propiedades de fuente que te dicen de dónde vino un visitante. Maquinaria estándar. Entonces el equipo miró los datos y vio una porción realmente grande de tráfico instalada en el cubo de directo.

Ahora bien, el tráfico directo en aumento tiene una coartada prefabricada en 2026. Bloqueadores de cookies, rechazos de consentimiento, navegadores preocupados por la privacidad: todo el mundo en marketing ha aprendido a esperar una porción de tráfico que simplemente se niega a identificarse. El camino de menor resistencia era asentir, culpar al estado general de internet y seguir adelante.

Wise rechazó la coartada. La porción era lo bastante grande como para querer saber si algo estaba genuinamente roto o si esto era simplemente la nueva normalidad de usuarios rechazando el consentimiento. Esa distinción importa, porque una de esas respuestas requiere un arreglo y la otra requiere aceptación, y confundirlas hace perder el tiempo a todo el mundo.

“Necesitamos profundizar en si algo está yendo mal aquí, o si es simplemente que ahora que tenemos todo esto en marcha, muchos de nuestros usuarios ni siquiera nos están dando el consentimiento para rastrearlos.”

Un bug viviendo entre los subdominios

La investigación encontró al culpable, y era estructural. La empresa operaba una maraña de dominios y subdominios: un .com, un .es, un .fr, más subdominios separados para la propia app y para el formulario de registro que crea una cuenta de la app. El seguimiento entre dominios es lo que cose el recorrido de un solo visitante a medida que se mueve por esa propiedad. Estaba roto.

La consecuencia era silenciosamente destructiva. Un visitante que empezaba en el .com y cruzaba al .nl quedaba registrado como una sesión completamente nueva con una fuente directa, en lugar del recorrido continuo que en realidad era. Cada uno de esos cruces borraba la campaña original que trajo a la persona. El equipo de marketing no estaba mirando ruido de privacidad. Estaba mirando su propia atribución de campaña fugándose por una costura de la web.

Aquí es donde la historia deja de ser una pulcra anécdota técnica y se convierte en una organizativa. Un equipo de marketing es dueño del contenido de su web y puede arreglarlo directamente. No es dueño del código subyacente de la web. Producto e ingeniería lo son, y ese equipo trabaja en sprints ajustados hacia sus propios objetivos. Wise no podía simplemente parchear el problema. Tenía que conseguir que entrara en la hoja de ruta de otra persona, y los signups, una métrica de top-of-funnel que la dirección vigila de cerca, se estuvieron midiendo mal todo ese tiempo. Esa combinación es lo que convirtió un bug en un sprint de pánico.

Cómo el sprint de pánico se convirtió en proceso

Dos cosas resolvieron la situación, y solo una de ellas era código. La mitad técnica fue bastante sencilla: trabajar con producto e ingeniería para pasar la información del visitante correctamente entre cada subdominio. La mitad más instructiva tenía que ver con la comunicación.

En lugar de entregar a la dirección una única cifra aterradora, el equipo hizo el trabajo analítico de dividir el número de tráfico directo en tres categorías honestas. Una parte era genuinamente directo. Una parte era el bug entre dominios, identificado y en reparación activa. Y una parte era tráfico que las normas de consentimiento hacían verdaderamente imposible de rastrear, una porción que ningún arreglo recuperaría jamás.

“Es un 25%, no un 100% completo de lo que pensábamos que era, y eso también ayuda a recuperar la confianza, que creo que se puede perder en situaciones como esta.”

El desglose hizo el trabajo pesado. Cuando los líderes pueden ver con precisión qué salió mal, qué se está arreglando y qué nunca estuvo roto de verdad, una crisis se encoge hasta sus dimensiones reales. Wise también replanteó el episodio como prueba de progreso en lugar de fracaso. Antes del despliegue de HubSpot, el equipo no habría podido detectar este problema en absoluto. Ahora podía verlo y cuantificarlo en dos días en lugar de dos meses, que es el sentido entero de construir una infraestructura de datos seria. El sprint de pánico fue incómodo, pero dejó al equipo mediblemente más honesto sobre sus propios números de lo que había sido antes.

Para el desglose completo de la entrevista, consulta nuestro Expert Insight completo con Mira Wise.

Herramientas mencionadas en la entrevista

Las siguientes herramientas y plataformas fueron mencionadas durante esta conversación.

HubSpot

Contenido relacionado