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. De dónde sale cada cifra: la venta viene de la maestra de boletas del ERP, que es el criterio único de todo el panel; las transacciones son las órdenes pagadas del ecommerce, que es la unidad en que se cuenta una compra; el ticket es esa misma venta dividida por esas órdenes; sesiones y conversión vienen de GA4. La venta se cuenta el día en que la transacción se contabiliza, no el día de la boleta, y la meta diaria está repartida sobre ese mismo criterio: es la definición que confirmaron el equipo de datos y el dueño del presupuesto comercial. Las cards de venta, transacciones y ticket muestran la variación interanual (YoY) contra los mismos días calendario del año pasado (si el rango es 1–2 de agosto, compara contra el 1–2 de agosto del año anterior). La venta y las transacciones comparan con la misma fuente en los dos años. El ticket es la excepción y se declara: la base 2025 se arma con la venta de las órdenes de esos días, no con la maestra de boletas. Ese contraste cruza dos criterios. Se lee como orden de magnitud, no al peso. La inversión también compara YoY (misma fuente ambos años, 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 elegible en Google + Meta (denominador alineado a los días con dato de canal); qué inversión entra al denominador está más abajo, en «Cómo calculamos el MER». Bajo el MER, la franja CPM · CTR · CPC es blended Google + Meta y se mide sobre la inversión total de las dos cuentas, no sobre la elegible del MER, porque son métricas de entrega; sigue al selector de rango y por ahora va sin comparación. La composición muestra la misma venta en 4 miradas (región, venta propia y marketplace, medio de pago, tipo de despacho); el corte entre venta propia y marketplace sale directo del ERP, así que suma exacto el titular, mientras que región y medio de pago son estimaciones de mezcla (el reparto viene de una fuente y el total de otra).

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 y en venta. La venta de esta sección usa el criterio único del panel: la maestra de boletas del ERP, la misma del titular. Cuadra exacto con el Resumen ejecutivo. Las transacciones vienen de las órdenes pagadas del ecommerce y las sesiones de GA4. El ticket de esta tabla es entonces venta de productos ÷ órdenes, igual que la card del Resumen.

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 mensual de ingresos (mes en curso 1–N vs. los mismos días calendario del mes anterior, 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 cuánto varió la última semana cerrada contra 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 la del Resumen ejecutivo (maestra de boletas del ERP); el desglose por canal solo existe en GA4, por eso no suma exacto al total.

El universo completo de departamentos con venta en el rango elegido, ordenado por venta ($), 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). La tabla scrollea con el encabezado fijo. La venta usa el mismo criterio del titular (venta de productos del ERP), así que suma exacto contra el Resumen ejecutivo; transacciones (órdenes) y unidades vienen de Salesforce a grano día; vistas PDP, ATC, login y compra desde GA4. Las columnas de tasa son 100% GA4 para no cruzar fuentes dentro de un ratio: ATC rate = ATC / vistas PDP; PDP a Login = sesiones que llegaron al paso de login / vistas PDP; PDP a Compra = sesiones que compraron / vistas PDP (se muestra «–» si GA4 no tiene base suficiente). El paso de login se mide como universo (sesiones con login o con cualquier paso posterior del checkout). El evento de login solo se dispara al autenticarse, y quien ya venía con la sesión iniciada no lo gatilla. El avance / cumpl. compara, contra la meta comercial del mes, la venta de los departamentos que tienen meta: el encabezado dice cuántos son. El presupuesto se compromete solo por departamento, así que un departamento sin meta va con guion y no entra en el agregado. La meta se lee del presupuesto oficial cada día. Si un día no llega, la columna queda sin dato y el encabezado lo dice. 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 es la venta de productos del ERP abierta por la taxonomía comercial del maestro de productos, así que la tabla muestra el universo completo y su suma da exacto el titular del Resumen ejecutivo, incluidos los departamentos que el ERP factura y las órdenes del sitio no traen como fila. 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.

El universo completo de secciones comerciales con venta en el rango elegido, ordenado por venta ($), con los mismos indicadores que departamentos y el mismo selector de días. La tabla scrollea con el encabezado fijo. Las píldoras filtran por una de las top 20 categorías. La venta usa el mismo criterio del titular (venta de productos del ERP), así que su suma da exacto el Resumen ejecutivo; transacciones (órdenes) 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 por departamento, no por 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. 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. La venta usa el mismo criterio del titular (venta de productos del ERP); transacciones (órdenes) 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 grupos sin marca real («sin marca», «(not set)», «no aplica», «sin clasificar»). El universo completo de marcas sí suma exacto el titular, pero esta tabla muestra solo las 12 de mayor venta, o sea una parte de ese total. 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 100 SKU de mayor venta ($) en el rango elegido (mismo selector de días). La venta usa el mismo criterio del titular (venta de productos del ERP) por línea de producto; transacciones (órdenes) y unidades desde Salesforce; vistas PDP y ATC desde GA4, cruzando por código de SKU. Un SKU sin correspondencia en GA4 muestra «–» en sus tasas de funnel, pero su venta se sigue mostrando. Vistas PDP = vistas de la ficha del producto; las tasas (ATC, PDP a Compra) se calculan solo con datos de GA4. Esta tabla no suma el titular: muestra los 100 SKU de mayor venta del rango.

Foto diaria de TODA la vitrina publicada (la vitrina propia 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 una foto por día y el panel conserva los últimos 90 días: la serie disponible hoy arranca el –. Los primeros días de una foto nueva se descartan. En esos días la vitrina todavía se estaba poblando, y un catálogo incompleto se lee como alza de precio. Por ahora la comparación es contra la misma ventana 7 días antes (mismo número de días y mismos días de semana), y solo si esa ventana tiene la foto completa; con un mes cerrado pasará a ser contra los mismos días del mes anterior. 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 con la misma serie de la sección 9 (últimos 90 días, desde el –), con selector propio (solo días con dato) y comparación contra la misma ventana 7 días antes (mismo número de días). 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, 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, la misma del reporte SEO semanal), 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 usa el criterio único del panel (la maestra de boletas del ERP, la misma del titular) y el comportamiento sale de GA4; nunca se cruzan fuentes dentro de un ratio. La comparación contra el año pasado es la excepción y se declara: la base 2025 son las órdenes pagadas de esos días, así que ese contraste cruza dos criterios de venta y se lee como orden de magnitud, no al peso. Todas las cifras salen de la actualización diaria; sin números estimados.

El MER de Paid Media = venta del ecommerce atribuida a Paid Media (GA4 último clic, deduplicada por transacción) ÷ inversión elegible en Google + Meta. Qué inversión entra al denominador. Desde el 26 de agosto de 2026 entra solo la inversión del mundo ecommerce: la que Growth marca como tal al nombrar la campaña. Queda fuera todo el mundo tarjeta, sin distinguir si la campaña busca que alguien saque la tarjeta o que compre con ella. Hasta el 25 de agosto rige el criterio anterior y esos días no cambiaron. Ahí entraba toda la inversión que lleva gente a hites.com. Quedaban fuera la inversión de marca, el mundo tarjeta y lo que la operación marcó como que no va. Los dos tramos no son comparables entre sí y el corte está a la vista en el gráfico diario. El panel declara cuánto gasto quedó fuera en el anexo «Origen de los datos».

De dónde sale la meta. El presupuesto comercial se planifica por semana, por departamento y para el canal internet. Este tablero lee la apertura diaria oficial del almacén de datos corporativo: 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, con la estacionalidad real del calendario, y el reparto cambia por día de semana, por eventos y por feriados: un sábado no pesa lo mismo que un martes. En una semana puntual la apertura diaria y el plan semanal pueden diferir, porque la 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. Qué universo cubre la meta. Es una meta de venta bruta del mundo ventas: producto vendido, con el kiosco dentro. Quedan fuera las notas de crédito, los ingresos logísticos y la venta de servicios. Por eso el cumplimiento se mide en venta bruta, la misma unidad en que está expresada la meta: medirlo contra la venta descontadas las devoluciones lo subestimaría en la tasa de devoluciones. La tabla de departamentos y el avance por mundo se miden con el mismo criterio y en la misma unidad. El porcentaje no es el mismo en las tres, porque cada una cubre un universo distinto: el avance por mundo deja fuera el marketplace, así que queda bajo el avance del mes de Meta de venta, que es la lectura con la que se calcula igual. Con el otro porcentaje de esa card, el cumplimiento, no se compara: ese divide por la meta de esos mismos días, no por la del mes completo. Cuándo se cuenta la venta. La venta se cuenta el día en que la transacción se contabiliza, no el día de la boleta, y la meta diaria está repartida sobre ese mismo criterio. Lo confirmaron el equipo de datos y el dueño del presupuesto comercial. Así el numerador y el denominador hablan del mismo día. 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 entre forecast y plan del plan semanal comercial vigente (por departamento y mes); la proyecta el propio equipo comercial y nosotros no la estimamos. La meta se lee del presupuesto oficial cada día. No se inventa, no se estima y no se guarda a mano. Si un día la meta no llega, tres lecturas quedan sin dato y lo dicen: el cumplimiento mensual, el avance por mundo y la columna de avance de la tabla de departamentos. Nunca se comparan contra una meta vieja, porque una meta vieja se ve igual de sana que una meta al día.

El panel cierra en el día anterior y se actualiza todos los días. El día en curso nunca se muestra, porque todavía se está moviendo. Un día que llega a medias tampoco se publica: si la venta del último día viene muy por debajo de su nivel normal, el panel retrocede un día antes que mostrar un día incompleto. El indicador del encabezado se abre y muestra, en una línea por fuente, hasta qué día llegó cada una. Hasta es el último día con dato de esa fuente. Los tres estados son al día (la fuente llegó completa), parcial (llegó, pero no hasta el último día cerrado) y no llegó. El indicador cerrado toma el peor de los tres, así se ve sin abrirlo. El panel se publica igual aunque una fuente no llegue, y lo declara. Un día sin panel cuesta más que un día con una fuente corta. Los días que quedaron cortos se completan cuando esa fuente llega. Nada se rellena ni se estima para tapar un hueco.

Cómo se calcula: total de sesiones (visitas al sitio) en el rango elegido, tal como las cuenta GA4. De dónde sale (warehouse): analytics_312935658.events_* (export nativo de Google Analytics 4 al BigQuery de Hites) hacia nuestra capa growth_analytics.datastudio_canal_diario / funnel_base.

Cómo se calcula: órdenes pagadas distintas del rango (COUNT DISTINCT de orden, PAYMENT_STATUS='paid', SITE_ID='HITES'). De dónde sale (warehouse): MODGESTION.SF_MOD_HECHO_ORDERS_V2 (réplica de las órdenes de Salesforce Commerce) hacia growth_analytics.sf_venta_real_diario.

Cómo se calcula: venta de productos ÷ órdenes del rango. Se calcula por orden, que es la unidad del ecommerce; el ERP lo calcula por boleta y da menos, porque una orden puede generar más de una boleta. De dónde sale (warehouse): numerador desde la maestra de boletas del ERP (MODGESTION.BI_MOD_HECHO_VENTAS, local del ecommerce, criterio de cierre comercial), con la jerarquía de producto resuelta por tres llaves (producto propio, marketplace y flete). Denominador = órdenes pagadas de MODGESTION.SF_MOD_HECHO_ORDERS_V2 (Salesforce).

Cómo se calcula: transacciones ÷ sesiones del rango (qué % de las visitas termina en compra). De dónde sale (warehouse): transacciones de Salesforce (SF_MOD_HECHO_ORDERS_V2) sobre sesiones de GA4 (events_* hacia datastudio_canal_diario).

Cómo se calcula: es la venta de productos, el número que reporta el equipo de ecommerce. Suma el producto de todos los mundos (electro, deco, vestuario y marketplace), propio y de terceros, ya descontados los refunds. Qué NO incluye: los ingresos logísticos (fletes, tanto el propio como el de marketplace) y las garantías extendidas; los tres van como card propia en el Resumen, así el total se puede reconstruir. De dónde sale (warehouse): la maestra de boletas del ERP (MODGESTION.BI_MOD_HECHO_VENTAS, local del ecommerce, criterio de cierre comercial), con la jerarquía de producto resuelta por tres llaves (producto propio, marketplace y flete). Todo el panel usa este mismo criterio. El titular, las tablas por departamento, sección, marca y SKU, y el lente 1P/3P suman exactamente lo mismo.

Cómo se calcula: gasto total de medios pagados del rango, Google Ads (en pesos) + Meta (en dólares, convertido a pesos con una tasa única de $– por dólar para todos los días), con todas las campañas de las dos cuentas. Esta card no es el denominador del MER: el MER divide sólo por la inversión elegible. Desde el 26 de agosto de 2026 esa es la del mundo ecommerce; antes era la que lleva gente a hites.com, sin la marca ni el mundo tarjeta, que en – fue – menor que este total (– de –). De dónde sale (warehouse): API de Windsor.ai conectada a las cuentas de Google y Meta, fuente externa que no vive en el DW; el build guarda la serie diaria de gasto (total y elegible) en el repo del panel y la respalda en growth_analytics.inversion_vertical_diario_hist.

Cómo se calcula: cumplimiento = venta del rango ÷ meta de esos mismos días; avance del mes = venta ÷ meta del mes completo. El forecast aplica sobre la meta la relación Fcst/Plan del TD Plan semanal de Comercial. De dónde sale (warehouse): HOMOLOGACION.BI_HOM_META_DIARIA_COMERCIAL, apertura diaria oficial del presupuesto (canal INTERNET, día × departamento); el build la agrega a mes y la conserva a día.

Cómo se calcula: venta atribuida a Paid Media ÷ inversión elegible para el MER (cuánta venta trae cada $1 invertido). Al denominador entra, desde el 26 de agosto de 2026, solo la inversión del mundo ecommerce: Growth marca el mundo en el nombre de cada campaña y el MER toma únicamente ese. Todo el mundo tarjeta queda fuera. Hasta el 25 de agosto rige el criterio anterior, que tomaba toda la inversión que lleva gente a hites.com y dejaba fuera la inversión de marca, el mundo tarjeta y lo que la operación marcó como que no va; esos días no cambiaron. Los dos tramos no se comparan entre sí. Un día sin inversión elegible conocida no aporta al MER; no cae a la inversión total. En – lo excluido fue el – del gasto, por eso el denominador es menor que la card de Inversión, que muestra el total invertido. De dónde sale (warehouse): numerador = venta Paid Media por último clic (analytics_312935658 hacia datastudio_canal_diario), atribución GA4, que no cuadra exacto con el titular; denominador = inversión Windsor filtrada a las campañas elegibles. Se sigue contra la base limpia –.

Cómo se calcula: publicado = promedio del precio de vitrina de los SKU propios (1P) con stock; vendido = venta ÷ unidades. De dónde sale (warehouse): publicado desde REGNEGOCIO.BI_REG_PRODUCTO (maestra de precios del AS400, vía stock_internet_full hacia catalogo_publicado_diario_hist, que guarda la historia diaria); vendido desde Salesforce.

Cómo se calcula: monto a crédito ÷ venta bruta, por departamento (la fórmula oficial de comercial/TI: el monto pagado a crédito es la venta con Tarjeta Hites). Más el evolutivo de esa participación. De dónde sale (warehouse): maestra de boletas MODGESTION.BI_MOD_HECHO_VENTAS (ID_LOC 425, el local del ecommerce), campos MNT_CRE_VEN_DET (crédito = TH) y MNT_BRU_VEN_DET (bruta), por fecha de proceso; el departamento se cruza con REGNEGOCIO.BI_REG_PRODUCTO.

Cómo se calcula: reparto de sesiones móvil vs escritorio, con su evolutivo. De dónde sale (warehouse): analytics_312935658.events_* (GA4) hacia growth_analytics.segmento_dispositivo_diario (sesiones por dispositivo y día, ventana rodante ~90 días).

Cómo se calcula: reparto de la venta por método de entrega (domicilio / retiro / same day) y por región; con toggle a las tiendas de mayor retiro. De dónde sale (warehouse): SF_MOD_HECHO_ORDERS_DETAILS_V2 (método SHIPPING_METHOD_NAME, región SHIPPING_ADDRESS_STATE_CODE, local de retiro C_FROMSTOREID) cruzado con MODGESTION.BI_MOD_LOC_SUCURSALES (nombre y zona de los locales).

Cómo se calcula: participación geográfica (mix %) aplicada proporcional al total de venta del titular, para que la composición sume exactamente lo que muestra la card de venta. Es una mezcla estimada, porque el mix viene de una fuente y el total de otra. De dónde sale (warehouse): el mix desde GA4 (analytics_312935658); el total desde la maestra de boletas del ERP (MODGESTION.BI_MOD_HECHO_VENTAS, local del ecommerce, criterio de cierre comercial), con la jerarquía de producto resuelta por tres llaves (producto propio, marketplace y flete).

Cómo se calcula: reparto entre venta propia y marketplace. Sale directo del ERP (campo TIPO_VENTA), no estimado, así que 1P + 3P da exacto el titular. De dónde sale (warehouse): la maestra de boletas del ERP (MODGESTION.BI_MOD_HECHO_VENTAS, local del ecommerce, criterio de cierre comercial), con la jerarquía de producto resuelta por tres llaves (producto propio, marketplace y flete).

Cómo se calcula: mix de medio de pago aplicado proporcional al total del titular. Es una mezcla estimada (el mix viene de una fuente y el total de otra). De dónde sale (warehouse): el medio de pago desde MODGESTION.SF_MOD_HECHO_ORDERS_V2 (Salesforce); el total desde la maestra de boletas del ERP (MODGESTION.BI_MOD_HECHO_VENTAS, local del ecommerce, criterio de cierre comercial), con la jerarquía de producto resuelta por tres llaves (producto propio, marketplace y flete).

Cómo se calcula: los 7 pasos del viaje de compra: sesiones, vistas PLP de categoría (paso opcional), vistas PDP, checkout (nodo bifurcado en con login e invitado), despacho, pago y compra; cada paso como % de las sesiones. Agregar al carro no es un paso de este embudo: el ATC se muestra como tasa sobre las vistas PDP en las tablas de producto. De dónde sale (warehouse): analytics_312935658.events_* (GA4) hacia growth_analytics.funnel_base (grano sesión, login∩checkout).

Cómo se calcula: son las mismas ocho columnas y la misma fuente que el funnel por departamento, abiertas con un día por fila en vez de resumidas en el rango. El paso de login se mide como universo (sesiones con login o con cualquier paso posterior del checkout), igual que arriba, así que ninguna tasa puede pasar de 100%. El corte: por defecto es todo el sitio, que acá significa la suma de los departamentos del catálogo clasificado, exactamente el mismo global que publica el encabezado del funnel de arriba. Una sesión que vio fichas de dos departamentos cuenta en los dos. Por eso ese total no es idéntico al conteo de sesiones del sitio, y se dice en vez de esconderlo. Las secciones van con su departamento adelante porque el mismo nombre de sección existe en varios departamentos. PROMOCIONES está en 55 y ACCESORIOS en 24, así que un corte por el nombre suelto sumaría secciones de otras categorías. De dónde sale (warehouse): la base cruda de GA4 (analytics_312935658.events_*) hacia la vista growth_analytics.funnel_base a grano sesión, y la jerarquía comercial del ERP (BI_REG_PRODUCTO, departamento y sección). Rango propio, independiente del funnel de arriba, y sin comparación por celda: un día contra otro día no tiene una base equivalente obvia.

Cómo se calcula: los mismos pasos del funnel, pero abiertos por departamento de merchandising, más el ranking de PLP por categoría. De dónde sale (warehouse): analytics_312935658.events_* (GA4) hacia growth_analytics.datastudio_departamento_diario.

Cómo se calcula: venta, sesiones, transacciones, ticket y conversión mirados por semana y por día del mes. De dónde sale (warehouse): la venta se unifica al criterio del titular, o sea la maestra de boletas del ERP (MODGESTION.BI_MOD_HECHO_VENTAS), así que cuadra exacto con el Resumen; sesiones desde GA4 (events_*); transacciones desde Salesforce (SF_MOD_HECHO_ORDERS_V2). El ticket es entonces venta de productos ÷ órdenes.

Cómo se calcula: sesiones y venta atribuida por canal de adquisición (agrupamiento Growth 2026: Paid, Organic, Directo, Owned, Social), atribución último clic. De dónde sale (warehouse): analytics_312935658.events_* (GA4) hacia growth_analytics.datastudio_canal_diario. La venta total autoritativa es la contable; el desglose por canal solo existe en GA4, por eso no suma exacto.

Cómo se calcula: venta de productos del rango (el mismo criterio del titular), ordenada de mayor a menor, con el universo completo de departamentos (sin tope: la tabla scrollea con el encabezado fijo). De dónde sale (warehouse): la maestra de boletas del ERP (MODGESTION.BI_MOD_HECHO_VENTAS, local del ecommerce, criterio de cierre comercial), con la jerarquía de producto resuelta por tres llaves (propio, marketplace y flete). La suma de esta tabla da exacto el titular. Las columnas de comportamiento y de orden siguen viniendo de Salesforce y GA4, que es su fuente: vistas PDP, tasa ATC, PDP a login, PDP a compra, transacciones y unidades. El cumplimiento compara contra la meta comercial usando la venta bruta, porque la meta está expresada en venta bruta.

Cómo se calcula: venta de productos del rango (el mismo criterio del titular), ordenada de mayor a menor. De dónde sale (warehouse): la maestra de boletas del ERP (MODGESTION.BI_MOD_HECHO_VENTAS, local del ecommerce, criterio de cierre comercial), con la jerarquía de producto resuelta por tres llaves (propio, marketplace y flete). La suma de esta tabla da exacto el titular. Las columnas de comportamiento y de orden siguen viniendo de Salesforce y GA4, que es su fuente: vistas PDP, tasa ATC, PDP a login, PDP a compra, transacciones y unidades. Muestra el universo completo de secciones (sin tope: la tabla scrollea con el encabezado fijo).

Cómo se calcula: venta de productos del rango (el mismo criterio del titular), ordenada de mayor a menor. De dónde sale (warehouse): la maestra de boletas del ERP (MODGESTION.BI_MOD_HECHO_VENTAS, local del ecommerce, criterio de cierre comercial), con la jerarquía de producto resuelta por tres llaves (propio, marketplace y flete). El universo completo de marcas sí suma exacto el titular, pero esta tabla muestra solo las 12 de mayor venta, o sea una parte de ese total. Las columnas de comportamiento y de orden (vistas PDP, tasa ATC, transacciones, unidades, markdown) siguen viniendo de Salesforce y GA4, que es su fuente. Abre la venta por marca.

Cómo se calcula: venta de productos del rango (el mismo criterio del titular), ordenada de mayor a menor. De dónde sale (warehouse): la maestra de boletas del ERP (MODGESTION.BI_MOD_HECHO_VENTAS, local del ecommerce, criterio de cierre comercial), con la jerarquía de producto resuelta por tres llaves (propio, marketplace y flete). Esta tabla no suma el titular: muestra los 100 SKU de mayor venta. Detrás, el panel guarda una reserva mucho mayor de SKU: los de más venta de la ventana, más los de cada departamento. Alcanza de sobra para el top 100 global y para el top de cada categoría. Las columnas de comportamiento y de orden (vistas PDP, tasa ATC, transacciones, unidades, markdown) siguen viniendo de Salesforce y GA4, que es su fuente.

Cómo se calcula: por departamento/sección, precio publicado vs vendido, descuento promedio y cuántos productos hay publicados. De dónde sale (warehouse): catálogo publicado (REGNEGOCIO.BI_REG_PRODUCTO hacia stock_internet_full y de ahí a catalogo_publicado_departamento_hist) + venta Salesforce para lo vendido.

Cómo se calcula: lo mismo que el de departamentos, pero por marca. De dónde sale (warehouse): catálogo publicado (stock_internet_full hacia catalogo_publicado_marca_hist) + venta Salesforce.

Cómo se calcula: los 100 términos más buscados en el buscador del sitio y cómo convierte quien busca vs quien no. De dónde sale (warehouse): analytics_312935658.events_* (evento de búsqueda del sitio) hacia growth_analytics.datastudio_search_termino_diario y datastudio_search_conversion_diario.

Cómo se calcula: las 100 búsquedas de Google que más traen clics al sitio (genéricas vs marca), con clics, impresiones y posición media. Llega con ~2-3 días de rezago. De dónde sale (warehouse): searchconsole.searchdata_site_impression (export oficial de Google Search Console) hacia growth_analytics.seo_query_clasificado_diario.

Cómo se calcula: los movimientos más notorios del último día cerrado (o del mes acumulado) por categoría, contra su base. De dónde sale (warehouse): los mismos agregados de venta (maestra de boletas del ERP, criterio único del panel) y de tráfico (GA4) que alimentan el resto del panel. La base interanual es la única que sale de las órdenes de Salesforce (SF_MOD_HECHO_ORDERS_V2), porque el corte por criterio del ERP no llega hasta 2025 en esta serie.

Cómo se calcula: qué SKU tienen un precio exclusivo con Tarjeta Hites publicado en la ficha, y su precio. De dónde sale (warehouse): REGNEGOCIO.BI_REG_PRODUCTO (maestra de precios) + eventos de precio vigentes + la ficha real de hites.com como árbitro (la maestra replica el precio oferta cuando el SKU no está activado) hacia growth_analytics.snap_skus_th_web_hist.

Las siglas del oficio se usan tal cual en todo el panel. Acá está qué significa cada una. MER: venta del ecommerce por cada peso invertido en medios pagados. CPM: costo por mil impresiones. CPC: costo por clic. CTR: clics sobre impresiones. GA4: la herramienta con que se mide el tráfico del sitio. SEO: posicionamiento en el buscador de Google, sin pagar por el clic. KPI: indicador de seguimiento. ERP: el sistema de gestión de la compañía, de donde sale la venta. SKU: código único de producto. TH: Tarjeta Hites. YoY: contra el mismo período del año anterior. MoM: contra el mes anterior. PDP: la ficha de un producto. PLP: la grilla de una categoría. ATC: agregar al carro. 1P y 3P: venta propia y venta de terceros en el marketplace. Markdown: descuento sobre el precio normal.