Dimensión 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 crean a partir de las señales del navegador. CoreDash las recopila automáticamente. Las tres dimensiones que se tratan aquí son diferentes: Etiqueta de página, Prueba A/B y Estado de inicio de sesión son definidas por el usuario. Se establecen asignando una variable de ventana en su propio código antes de que se ejecute CoreDash.

Ese cambio de automático a intencional es el punto central. Su aplicación conoce cosas que el navegador no puede inferir: qué variante de pago está viendo un usuario, si la URL actual es una página de detalles del producto o una página de destino, si el usuario está autenticado. Pasar ese contexto a CoreDash significa que sus datos de rendimiento reflejan cómo funciona realmente su negocio.

Etiqueta de página (lb)

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

window.__CWVL = 'mypagelabel';

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

Por qué esto es importante

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

La etiqueta de página también separa las páginas que sirven a 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 diferente. Una página de destino que recibe tráfico pagado tiene cero tolerancia a un LCP lento porque cada milisegundo le está costando inversión publicitaria.

Una vez que etiqueta las páginas por función de negocio, puede establecer diferentes umbrales de alerta en CoreDash por etiqueta y enrutar las alertas correctas a los equipos correctos.

Prueba A/B (ab)

La dimensión Prueba A/B contiene una etiqueta que usted asigna a la variante actual que un usuario está experimentando. Defínala así:

window.__CWAB = 'my page version';

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

Por qué esto es importante

Las pruebas A/B son una de las fuentes más comunes de regresiones de rendimiento no intencionales. La variante B incluye un nuevo carrusel de imágenes principales. La variante B carga un widget de recomendaciones de terceros. La variante B incluye una ronda adicional de hidratación de React. Todo esto conlleva un costo de rendimiento que sus herramientas de experimentación casi con certeza no miden.

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

Con __CWAB configurado, abra CoreDash, filtre por ab = variant-b y compare las Core Web Vitals lado a lado con el control. He visto pruebas A/B donde la variante ganadora tenía un LCP en el percentil 75 que era 600 ms peor que el control porque cargaba una fuente más pesada. El equipo de negocios vio el aumento de conversión; no vio la regresión de rendimiento. Eso es lo que esta dimensión evita.

Estado de inicio de sesión (li)

La dimensión Estado de inicio de sesión registra si el usuario actual está autenticado. Defínala así:

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

Por qué esto 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é de CDN. El servidor ejecuta consultas de base de datos para 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 a menudo cargan más JavaScript: widgets de cuenta, sistemas de notificaciones, reactividad del carrito de compras. También pueden omitir el renderizado previo o el almacenamiento en caché en el borde 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 y, sin embargo, los usuarios con sesión iniciada son típicamente sus clientes de mayor valor. Ya han convertido. Son los que más necesita retener.

Sin la dimensión li, el rendimiento autenticado lento se oculta dentro de sus números agregados. Su LCP anónimo podría ser de 1.8s, mientras que su LCP con sesión iniciada es de 3.4s. El agregado se lee como 2.3s y parece aceptable. Divida por li y la imagen cambia por completo.

Implementación

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

// Establecer las tres según el estado de su aplicación
window.__CWVL  = 'checkout';      // etiqueta de página
window.__CWAB  = 'variant-b';     // variante de prueba A/B
window.__CWVLI = 1;               // sesión iniciada

Los valores de las etiquetas son cadenas de texto (excepto __CWVLI, que toma 1 o 0). Manténgalos coherentes en toda su base de código. Si usa product-detail en una plantilla y productDetail en otra, CoreDash las tratará como dos segmentos separados y sus datos se fragmentarán. Elija una convención y aplíquela.

Combinando las tres

El verdadero valor aparece cuando apila estas dimensiones juntas. Usted está ejecutando una prueba A/B en su página de pago para usuarios con sesión iniciada. Quiere saber si la variante B hace que la experiencia de pago autenticada sea más rápida o más lenta.

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

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