Dimensión de Core/Dash: Etiquetas Personalizadas y Segmentación

Segmentación Personalizada en CoreDash

Las dimensiones técnicas como el país y el tipo de dispositivo se construyen a partir de las señales del navegador. CoreDash las recopila automáticamente. Las tres dimensiones que se cubren aquí son diferentes: Etiqueta de Página, Test A/B y Estado de Inicio de Sesión son definidas por el usuario. Se establecen asignando una variable de ventana en tu propio código antes de que se ejecute CoreDash.

Ese cambio de lo automático a lo intencional es precisamente el punto clave. Tu aplicación sabe cosas que el navegador no puede inferir: qué variante del proceso de pago está viendo un usuario, si la URL actual es una página de detalles del producto o una landing page, o si el usuario está autenticado. Pasar ese contexto a CoreDash significa que tus datos de rendimiento reflejan cómo funciona realmente tu negocio.

Etiqueta de Página (lb)

La dimensión Etiqueta de Página te permite agrupar páginas por función de negocio en lugar de por estructura de URL. Defínela así:

window.__CWVL = 'mypagelabel';

Valores típicos: checkout, product-detail, landing-page, category, search-results, account. El valor es una cadena de texto arbitraria que tú controlas.

Por qué es importante

El análisis basado en URL tiene un problema fundamental de escalabilidad. Un sitio grande de comercio electrónico puede tener 50,000 páginas de detalles de productos. Sus URLs se ven como /products/blue-widget-32oz y /products/red-gadget-xl. Estas usan la misma plantilla, tienen la misma función de negocio y el mismo objetivo de optimización. Analizarlas URL por URL no es útil. Agruparlas bajo product-detail te ofrece un perfil de rendimiento único para todo el catálogo de productos.

La Etiqueta de Página también separa las páginas que manejan diferentes presupuestos de rendimiento. Una página de pago tiene un umbral de LCP aceptable porque genera ingresos directos. Una publicación de blog tiene una tolerancia distinta. Una página de destino con tráfico de pago tiene cero tolerancia a un LCP lento porque cada milisegundo te está costando inversión publicitaria.

Una vez que etiquetas las páginas por función de negocio, puedes configurar diferentes umbrales de alerta en CoreDash por etiqueta y enviar las alertas correctas a los equipos correspondientes.

Test A/B (ab)

La dimensión Test A/B contiene una etiqueta que asignas a la variante actual que está experimentando el usuario. Defínela así:

window.__CWAB = 'my page version';

El valor es arbitrario. variant-a y variant-b son opciones obvias, pero puedes usar cualquier cadena que se asigne a los identificadores de variantes de tu plataforma de experimentación.

Por qué es importante

Los tests A/B son una de las fuentes más comunes de regresiones de rendimiento no deseadas. La variante B incluye un nuevo carrusel de imágenes hero. La variante B carga un widget de recomendación de terceros. La variante B incluye una ronda extra de hidratación de React. Todo esto conlleva un costo de rendimiento que tus herramientas de experimentación casi con seguridad no están midiendo.

La mayoría de las plataformas de experimentación rastrean las tasas de conversión y los ingresos. No rastrean el LCP ni el INP en el percentil 75 (p75). Si la variante B convierte un 2% mejor pero carga 400 ms más lento en dispositivos móviles, necesitas saberlo antes de implementarla al 100% del tráfico. El costo de rendimiento podría anular la ganancia de conversión durante el próximo trimestre a medida que los usuarios pierden la paciencia.

Con __CWAB configurado, abre CoreDash, filtra por ab = variant-b y compara los Core Web Vitals lado a lado con el grupo de control. He visto tests A/B donde la variante ganadora tenía un LCP en el p75 que era 600 ms peor que el control porque cargaba una fuente más pesada. El equipo de negocio vio el aumento en la conversión; no vieron la regresión en el rendimiento. Eso es exactamente lo que previene esta dimensión.

Estado de Inicio de Sesión (li)

La dimensión Estado de Inicio de Sesión registra si el usuario actual está autenticado. Defínela así:

window.__CWVLI = 1; // sesión iniciada
window.__CWVLI = 0; // sesión cerrada

Por qué es importante

Los usuarios con sesión iniciada reciben una página fundamentalmente diferente a la de los visitantes anónimos. Sus solicitudes evitan muchas capas de caché del CDN. El servidor ejecuta consultas a la base de datos para obtener contenido personalizado: el carrito del usuario, su historial de pedidos, sus artículos guardados. Ese trabajo del lado del servidor se suma directamente al TTFB.

En el frontend, las páginas autenticadas suelen cargar más JavaScript: widgets de cuenta, sistemas de notificaciones, reactividad del carrito de compras. También pueden saltarse el renderizado previo (prerendering) o el almacenamiento en caché perimetral (edge caching) que hace que las páginas anónimas sean rápidas. El resultado es que los usuarios con sesión iniciada a menudo ven un rendimiento más lento que los usuarios anónimos, a pesar de que los usuarios autenticados son típicamente tus clientes de mayor valor. Ya han convertido. Son los que más necesitas retener.

Sin la dimensión li, el rendimiento lento de los usuarios autenticados se oculta dentro de tus números agregados. Tu LCP anónimo podría ser de 1.8s mientras que tu LCP de sesión iniciada es de 3.4s. El agregado marca 2.3s y parece aceptable. Divídelo por li y el panorama cambia por completo.

Implementación

Las tres dimensiones utilizan el mismo patrón: establece una variable de ventana antes de que se ejecute el fragmento de CoreDash. Colócalas en una etiqueta script en el head de tu documento o en el código de inicialización de tu aplicación:

// Configura las tres basándote en el estado de tu app
window.__CWVL  = 'checkout';      // etiqueta de página
window.__CWAB  = 'variant-b';     // variante de test A/B
window.__CWVLI = 1;               // sesión iniciada

Los valores de las etiquetas son cadenas de texto (excepto __CWVLI, que toma 1 o 0). Mantenlos consistentes en toda tu base de código. Si usas product-detail en una plantilla y productDetail en otra, CoreDash los tratará como dos segmentos separados y tus datos se fragmentarán. Elige una convención y aplícala rigurosamente.

Combinando las tres

El verdadero valor aparece cuando apilas estas dimensiones juntas. Estás ejecutando un test A/B en tu página de pago para usuarios con sesión iniciada. Quieres saber si la variante B hace que la experiencia de pago autenticada sea más rápida o más lenta.

En CoreDash, filtra por ab = variant-b más lb = checkout más li = 1. Eso te da el rendimiento de tu variante de pago específicamente para usuarios autenticados. Ninguna otra herramienta de monitorización saca a la luz esa combinación sin trabajo de ingeniería personalizado por tu parte.

Las dimensiones técnicas estándar te dicen lo que experimentó el navegador. Las dimensiones personalizadas te dicen lo que experimentó el negocio. Una regresión de 400 ms en el LCP significa algo muy diferente en una landing-page con tráfico de pago frente a una publicación de blog. Estas distinciones son clave para la priorización, y la priorización es donde el trabajo de rendimiento tiene éxito o se estanca.