Pulso Ecommerce · Gerencia Growth · Marketing

El selector de rango acota los días dentro del mes en curso y recalcula tarjetas y composición, siempre cuadrando al total. Las cards de ingresos, transacciones y ticket muestran la variación interanual (YoY) contra el mismo tramo del año pasado, por día de semana equivalente (Salesforce, misma definición día-a-día: cuadra exacto al total); la inversión también compara YoY (misma fuente ambos años: Windsor, Google + Meta); sesiones y conversión no se comparan porque su base 2025 no es homologable. El MER = venta atribuida a Paid Media ÷ inversión en Google + Meta (denominador alineado a los días con dato de canal). Bajo el MER, la franja CPM · CTR · CPC es blended Google + Meta (mismo origen y unidad que la inversión: Meta convertida a CLP), sigue al selector de rango y por ahora va sin comparación. La composición muestra la misma venta en 4 miradas (región, 1P/3P, medio de pago, tipo de despacho); el split 1P/3P es a nivel de línea de producto, por eso cubre ~99,9% del total. Venta ($ y transacciones) desde Salesforce; tráfico y conversión desde GA4.

Los 7 pasos del viaje de compra en GA4 (sesiones, vistas PLP de categoría, vistas PDP, checkout, despacho, pago y compra), con su selector de rango propio dentro del mes. Cada paso es presencia del evento en la sesión (no estrictamente anidado): el % mostrado es sobre el total de sesiones y la tasa paso a paso compara con el paso anterior. Las vistas PLP son un paso opcional (grilla de categoría, excluye la búsqueda de texto /busqueda); van en punteado porque muchas sesiones llegan directo a la ficha sin pasar por una categoría, por eso PLP suele ser menor que PDP. El checkout es un nodo bifurcado: se abre en con login e invitado, derivados del cruce real login∩checkout a nivel sesión (vista grano-sesión funnel_base, no una resta), ambos suman exactamente el checkout. Tráfico y eventos desde GA4 (prop. 312935658).

Mes a la fecha: el mes en curso día a día contra el mes pasado. Por semana: compara las últimas 6 semanas cargadas, una contra otra (no las suma); las dos últimas columnas muestran el triángulo de cada semana vs. la previa, «mismo día a la fecha», en sesiones (GA4) y en venta (ingresos Salesforce). Ingresos y transacciones desde Salesforce; sesiones desde GA4.

Agrupamiento «Growth | 2026» de GA4 (Paid Media, Organic, Directo, Owned Media, Social). Mes a la fecha: una línea por canal, con la variación de ingresos MoM (mes en curso 1–N vs. el mismo tramo del mes anterior por día de semana equivalente, atribución GA4) en cuanto exista un mes previo completo de canal; mientras tanto (el desglose por canal arranca el 1-jun, así que el MoM se activa al pisar julio) la columna muestra la variación de la última semana cerrada vs. la previa (7 días contra 7). Por semana: cada canal a través de las últimas 6 semanas, con el triángulo de la última semana vs. la previa. Ingresos por canal con atribución GA4: la venta total autoritativa es Salesforce (KPI's Globales); el desglose por canal solo existe en GA4, por eso no suma exacto al total.

Los 20 departamentos de mayor venta ($) en el rango elegido, con su propio selector de días dentro del mes en curso (por defecto, mes a la fecha; mueve también secciones, marcas y SKU). Venta, transacciones (órdenes) y unidades vienen de Salesforce a grano día (la misma fuente que reconcilia el equipo comercial); vistas PDP y ATC desde GA4. Las columnas de tasa son 100% GA4 para no cruzar fuentes dentro de un ratio: ATC rate = ATC / vistas PDP; PDP a Compra = unidades GA4 / vistas PDP (se muestra «–» si GA4 no tiene base suficiente). El avance / cumpl. compara la venta del top 20 contra la meta comercial del mes (presupuesto INTERNET, comprometido solo a nivel de departamento). El markdown y el precio promedio ya no van aquí: viven en el Catálogo publicado (secciones 9 y 10), la mirada insesgada sobre TODA la vitrina y no solo sobre lo vendido (el markdown sobre ventas tiene sesgo de selección: lo más descontado se vende más). La venta por departamento cubre el catálogo clasificado (~95% del total); el resto son ítems sin clasificación de catálogo, por eso la suma de departamentos queda algo bajo el total autoritativo del Resumen ejecutivo. Sin YoY por categoría (el catálogo 2025 tiene SKU sin clasificar que sesgarían la comparación); el YoY total está en el Resumen ejecutivo.

Las 12 secciones de mayor venta ($) en el rango elegido, con los mismos indicadores que departamentos y el mismo selector de días. Las píldoras filtran por una de las top 20 categorías. Venta, transacciones y unidades desde Salesforce; vistas PDP y ATC desde GA4 (tasas 100% GA4). No lleva columna de meta/avance porque el presupuesto comercial se compromete a nivel de departamento, no de sección: no inventamos una meta que no existe. El markdown y el precio promedio están en el Catálogo publicado por departamento (sección 9), que se abre a sección. La venta por sección cubre el catálogo clasificado; el total autoritativo está en el Resumen ejecutivo. Sin YoY por sección, por la misma razón que en departamentos.

Las 12 marcas de mayor venta ($) en el rango elegido (mismo selector de días que departamentos). Las píldoras filtran por una de las top 20 categorías. Venta, transacciones y unidades desde Salesforce; vistas PDP y ATC desde GA4 (tasas 100% GA4, igual que en departamentos). Marca y categoría desde el catálogo; se excluyen los buckets sin marca real («sin marca», «(not set)», «no aplica», «sin clasificar»). La venta por marca cubre el catálogo con marca clasificada; el total autoritativo está en el Resumen ejecutivo. Sin YoY por marca, por la misma razón que en departamentos. El análisis de markdown por marca (mismo estándar insesgado del catálogo publicado) va ahora en su propia sección al final del informe (sección 10).

Los 50 SKU de mayor venta ($) en el rango elegido (mismo selector de días). Venta, transacciones y unidades desde Salesforce a nivel línea de producto; vistas PDP y ATC desde GA4, cruzando por código de SKU. Un SKU sin match en GA4 muestra «–» en sus tasas de funnel, pero su venta sigue 100% Salesforce. Vistas PDP = vistas en evento view_item; las tasas (ATC, PDP a Compra) se calculan solo con eventos GA4.

Foto diaria de TODA la vitrina publicada (fuente stock_internet_full, la vitrina 1P completa: vestuario, deco y electro), se venda o no cada SKU: por eso es la mirada insesgada del surtido publicado. El markdown sobre ventas tiene sesgo de selección (lo más descontado se vende más y sobre-representa el descuento real del surtido); este mide el descuento sobre el catálogo completo. Por SKU con stock: precio prom. publicado = precio oferta promedio; markdown publicado = 1 − precio efectivo / precio normal (usa precio tarjeta si el SKU lo tiene, si no el de oferta). Todo aditivo (n_sku, valor y markdown son sumas), así que cuadra exacto al total global y a cada sección. Se guarda como foto diaria en growth_analytics (patrón _hist: historia + hoy en vivo) desde el 6-jul y acumula hacia adelante. Por ahora la comparación es vs el día anterior; con un mes cerrado pasará a ser vs el día equivalente del mes anterior, mismo día de semana (variación diaria, semanal y mensual). Toca un departamento para abrir sus secciones.

El mismo estándar insesgado del catálogo publicado de la sección 9, ahora por marca: foto diaria de TODA la vitrina publicada (se venda o no cada SKU), no solo lo vendido. Por SKU con stock: precio prom. publicado = precio oferta promedio; markdown publicado = 1 − precio efectivo / precio normal (usa precio tarjeta si el SKU lo tiene, si no el de oferta). Todo aditivo, así que el global cuadra exacto; se listan las top 40 marcas por SKU publicado. Foto diaria en growth_analytics desde el 6-jul con selector propio (solo días con dato) y comparación vs el día anterior. Va al final del informe por ser la mirada más granular del surtido.

Los términos que la gente escribe en el buscador de hites.com, ordenados por número de búsquedas (top 100). Fuente: el reporte curado de búsqueda de Growth (datastudio_search_termino_diario), la misma serie oficial que alimenta el tablero de búsqueda del sitio, con el término ya normalizado y el conteo oficial de búsquedas. La métrica es búsquedas, no sesiones ni usuarios: así la suma de variantes es exacta. Agrupación de variantes: se normalizan mayúsculas y tildes, se unifican plurales/singulares y errores de tipeo (distancia de edición 1) y un diccionario corto y editable de sinónimos obvios (por ejemplo tv = televisor = tele). No se fusionan variantes con intención distinta (género, marca, modelo o medida): zapatillas mujer se mantiene separado de zapatillas hombre, y iphone 15 de iphone 16, porque son demandas comerciales distintas. El chip +N junto al término indica cuántas variantes se agruparon (pásale el cursor para ver la lista). Tiene filtro de día propio y va sin comparación: es una foto de la demanda expresada en el rango elegido.

Las consultas que la gente escribe en Google (no en el buscador del sitio) y terminan en hites.com, desde Search Console (la capa SEO curada de growth_analytics, la misma de la weekly SEO), clasificadas en genérico (demanda de producto) y marca (navegacional). Calendario propio: la serie GSC tiene su cobertura (últimos ~90 días) y llega con ~2-3 días de rezago, por eso la sección declara su propia fecha y no sigue el filtro de otras secciones. El universo son las consultas líderes por clics de los últimos 90 días; el ranking se reordena según el rango elegido y la Δ compara contra la ventana equivalente por día de semana (−28d) cuando la serie la cubre completa. Posición media ponderada por impresiones.

Estructura fija de 7 lecturas del último día cerrado, siempre en el mismo orden: 3 globales (ingresos · qué lo movió, con la venta descompuesta en tráfico × conversión × ticket · volumen y ticket), 2 de departamentos (el líder del día y los mayores cambios) y 2 de productos (el SKU más vendido y la marca líder). Todo se compara contra el mismo día de la semana anterior (comparación limpia: controla la estacionalidad del día, no contra el promedio del mes que el CyberDay infla) y, donde aplica, contra el mismo día del año pasado. La plata sale de Salesforce y el comportamiento de GA4; nunca se cruzan fuentes dentro de un ratio. Todas las cifras salen del refresh diario; sin números estimados.

El MER de la tarjeta = venta atribuida a Paid Media (GA4 último clic, deduplicada por transacción) ÷ inversión real en Google + Meta (Windsor, Meta convertida a CLP con FX 899), sobre los mismos días con dato de canal y siguiendo el selector de rango. Se ancla siempre contra una base limpia de 8,1× (ene–may 2026, 145 días), levantada con la misma vara: (1) una sola fuente: venta de clic en GA4, inversión real de plataformas, sin mezclar orígenes dentro del ratio; (2) sin view-through: la medición anterior sumaba conversiones por visualización (VTC de Google + view de Meta); GA4 último clic las excluye por construcción; (3) una sola ventana de clic: normalizamos la base de 90 días al estándar vigente de 30 días para que todos los períodos sean comparables. Con ese método el 2026 calza en cuatro tramos con una sola vara: base 8,1×, Cyber 12,0× y Post-Cyber 20,9×. La comparación «vs mes anterior» se enciende sola cuando el mes previo tiene serie Paid completa para el rango (el split por canal arranca el 1-jun, por eso aparece al pisar julio). Bajo la card, el gráfico de seguimiento diario del MER traza el MER de cada día (misma fórmula a grano día: venta Paid del día ÷ inversión del día) contra la base limpia 8,1×, y sigue el mismo selector de rango.

De dónde sale la meta. El presupuesto comercial 2026 se planifica por semana (plan del equipo comercial, Vta Bruta, canal INTERNET, por departamento). Este tablero lo lee de la apertura diaria oficial del data warehouse corporativo (tabla BI_HOM_META_DIARIA_COMERCIAL, grano día × departamento × canal): la meta mensual del tablero es la suma de esas metas diarias, así que ambas lecturas cuadran por construcción. La apertura a día no es un prorrateo nuestro: es la distribución oficial de la capa de homologación, con la estacionalidad real del calendario — el reparto cambia por día de semana (un sábado pesa en promedio ~20% de su semana), por eventos y por feriados. Consistencia verificada (jul-2026): el total anual de la apertura diaria calza con el plan semanal comercial (dif +0,25%, redondeos); a nivel de una semana puntual pueden diferir (la apertura diaria reparte los eventos con su propio calendario), por eso el tablero usa la diaria como referencia de ritmo y el compromiso sigue siendo la meta del mes. Las dos lecturas de la card: (1) cumplimiento del período = venta del rango elegido ÷ suma de la meta diaria de esos mismos días (si eliges un día, es la meta de ese día); (2) avance del mes = venta ÷ meta mensual completa. El forecast aplica sobre la meta la relación Fcst/Plan del plan semanal comercial vigente (por departamento y mes); es la proyección del propio equipo comercial, no una estimación nuestra. Venta desde el titular del Resumen (ERP comercial en el modo elegido); la meta no se inventa ni se estima, es el número presupuestado oficial.

Origen DW: MODGESTION.BI_MOD_HECHO_VENTAS — la maestra de boletas del ERP corporativo (la misma con la que reconcilia Comercial); el ecommerce es el local 425 INTERNET, por fecha de boleta. Transformación: el build agrega la serie diaria en 4 modos (bruta / bruta−nc / neta / neta−nc). En el panel: el titular de venta y el numerador de meta/forecast.

Origen DW: MODGESTION.SF_MOD_HECHO_ORDERS_V2 (cabecera de orden: medio de pago, estado) y SF_MOD_HECHO_ORDERS_DETAILS_V2 (línea de producto: precio pagado, cantidad, vendedor 1P/3P vía TIPO_MKP) — la réplica en el DW de las órdenes de Salesforce Commerce; siempre filtradas a pagadas (PAYMENT_STATUS='paid', SITE_ID='HITES'). Transformación: agregados diarios por sitio, departamento (cruce con dim_sku) y SKU. En el panel: transacciones, ticket, top departamentos/secciones/marcas/SKU, precio vendido.

Origen DW: analytics_312935658.events_* — el export nativo de Google Analytics 4 al BigQuery de Hites (evento a evento). Transformación: growth_analytics.funnel_base (grano sesión: pasos del viaje, login∩checkout) y datastudio_canal_diario (sesiones y venta atribuida por canal, agrupamiento Growth 2026). En el panel: sesiones, conversión, funnel de compra, KPI's por canal.

Origen: API de Windsor.ai conectada a las cuentas de Google Ads (CLP) y Meta (USD, convertido con FX fijo) — fuente externa, no vive en el data warehouse. Transformación: serie diaria de gasto (snapshot spend.csv en el repo del panel). En el panel: card de inversión y denominador del MER.

Origen DW: HOMOLOGACION.BI_HOM_META_DIARIA_COMERCIAL — la apertura diaria oficial del presupuesto comercial (canal INTERNET, grano día × departamento), cargada en la capa de homologación corporativa. Transformación: el build la agrega a mes y la conserva a día (glob_d/dep_d). El forecast aplica sobre esa meta la relación Fcst/Plan del TD Plan semanal de Comercial (archivo de planificación, no BQ). En el panel: cards de meta y forecast, avance por departamento.

Origen: numerador = venta atribuida a Paid Media (GA4 último clic, de datastudio_canal_diario ← analytics_312935658); denominador = inversión Windsor. En el panel: card MER y su seguimiento diario contra la base limpia 8,1×.

Origen DW: BASE_STOCK_INTERNET.stock_internet_full — la foto de la vitrina 1P del sitio (vestuario, deco y electro) que el origen sobreescribe cada día (no guarda historia). Transformación: growth_analytics.catalogo_publicado_diario_hist (+ _departamento_ y _marca_) — nuestros snapshots diarios SON la historia, acumulando desde el 6-jul. En el panel: precio publicado, secciones 9 y 10 de markdown.

Origen DW: REGNEGOCIO.BI_REG_PRODUCTO (maestra de precios del AS400: lista, oferta y precio Hites) + MODGESTION.BI_MOD_HECHO_EVENTOS(_PRODUCTOS) (eventos de precio vigentes) + la ficha real de hites.com (verificador diario que confirma la caja TH publicada — el árbitro, porque la maestra replica el precio oferta cuando el SKU no está activado). Transformación: growth_analytics.promos_th_sku_vigente_web + snapshot snap_skus_th_web_hist (capa del Pulso Promos TH). En el panel: fila "con precio Tarjeta Hites" de la matriz de precios.

Origen DW: las mismas órdenes Salesforce (SF_MOD_HECHO_ORDERS_V2, medio de pago HITES_CARD) cruzadas con el catálogo (dim_sku) para el departamento. Transformación: serie día × departamento con venta/transacciones TH y totales. En el panel: card Tarjeta Hites (penetración, evolutivo, tabla por categoría).

Origen DW: SF_MOD_HECHO_ORDERS_DETAILS_V2 — el método real de la línea (SHIPPING_METHOD_NAME), la región de la dirección (SHIPPING_ADDRESS_STATE_CODE) y el local de origen del retiro (C_FROMSTOREID), cruzado con MODGESTION.BI_MOD_LOC_SUCURSALES (maestra de locales, nombre y zona). En el panel: card de despacho (método, región, toggle tienda de retiro).

Origen DW: analytics_312935658.events_* (GA4). Transformación: growth_analytics.segmento_dispositivo_diario (sesiones por dispositivo y día, ventana rodante ~90 días). En el panel: dona + evolutivo móvil/escritorio.

Origen DW: analytics_312935658.events_* (GA4, evento de búsqueda del sitio). Transformación: growth_analytics.datastudio_search_termino_diario (término normalizado y conteo oficial de búsquedas) y datastudio_search_conversion_diario (quien busca vs quien no). En el panel: sección "Qué busca la gente".

Origen DW: searchconsole.searchdata_site_impression — el export bulk oficial de Google Search Console al BigQuery de Hites (query a query; llega con ~2-3 días de rezago). Transformación: growth_analytics.seo_query_diario y seo_query_clasificado_diario (clasificación genérico/marca vía fn_grupo_query — la misma capa de la weekly SEO). En el panel: bloque "Lo que buscan en Google".

Origen DW: analytics_312935658.events_* (GA4). Transformación: growth_analytics.datastudio_departamento_diario (pasos del funnel por departamento de merchandising, nomenclatura Data Studio) + el ranking PLP por categoría de navegación desde el evento crudo. En el panel: sección Funnel completo por departamento.