Playbook · Castañer
Guía operativa del e-commerce

El centro de mando, el negocio en directo.

El Dashboard Castañer es el lugar donde todos los datos de la tienda online —ventas, pedidos, stock, tráfico, devoluciones, fulfillment— confluyen, vivos las 24 horas. Una sola fuente de verdad, siempre actualizada, en la que se puede confiar ciegamente.

Playbook v1 Junio 2026 Dashboard Castañer
00
Manifiesto

El puesto de mando del e-commerce de Castañer

El Dashboard Castañer es el lugar donde todos los datos de la tienda online —ventas, pedidos, stock, tráfico, devoluciones, fulfillment— confluyen en una sola verdad, viva las 24 horas del día.

No es un informe que se mira una vez al mes. Es el pulso diario del negocio: lo primero que se abre por la mañana y lo que responde, en segundos, la pregunta que importa en cada momento. Una sola fuente de verdad, siempre actualizada, en la que se puede confiar ciegamente. Esta confianza es todo el proyecto; todo lo demás —la arquitectura, los automatismos, los agentes— existe para protegerla.

01
Visión rápida

El proyecto en 30 segundos

Qué es. Un dashboard interno 24/7 de KPIs operativos para castaner.com, la tienda online de Castañer (marca catalana de calzado, fundada en 1927).

Para quién. El equipo de e-commerce de Castañer. Nació como herramienta de un solo usuario y hoy es multiusuario con roles: gestión, agencia, dirección, operaciones, marketing y el equipo de tienda UK, cada uno con su vista.

Qué problema resuelve. Castañer vende por muchos canales y mercados; los datos viven dispersos entre Shopify, Klaviyo, GA4 y REVENI, a menudo con criterios que no cuadran entre sí. El dashboard los unifica, los hace consistentes y los sirve consolidados, sin que nadie tenga que exportar Excels ni recalcular nada.

Datos clave

7
mercados: ES · FR · IT · UK · US · GR · resto UE
2
tiendas online: principal (EUR) + UK (GBP)
~20
procesos automáticos: snapshots, sincronización, emails, auditoría
4
asistentes de IA especializados
3
idiomas completos: CA / EN / ES
DatoDetalle
MercadosES · FR · IT · UK · US · GR · resto de la UE/mundo
CanalesWeb · Marketplaces · Tiendas físicas (10+ puntos)
2 tiendas onlinePrincipal (EUR) + UK (GBP)
IntegracionesShopify · Klaviyo · GA4 · REVENI · transportistas
IdiomasTrilingüe completo CA / EN / ES
Automatismos~20 procesos automáticos: snapshots, sincronización, 2 emails automáticos, auditoría diaria
Asistentes de IA4 asistentes especializados: redactor de emails, 2 traductores, auditor de datos
02
Reglas de oro

Principios y reglas de oro

Principios no negociables. Cada uno ha nacido de un error real; seguirlos es lo que mantiene el dashboard fiable y mantenible.

2.1

Los datos no se inventan nunca

Todo lo que se afirma sale de una cifra real. Cuando una vista, un email o el chat necesitan un número, leen el campo ya publicado en el snapshot JSON; no vuelven a hacer la query a la base de datos.

Por qué. Cuando una pieza recalculaba por su cuenta, daba cifras ligeramente distintas a las del dashboard, e incluso porcentajes de crecimiento con el signo contrario o atribuciones de canal infravaloradas. La regla: para cuadrar, lee siempre el campo ya publicado, no repliques la lógica de cálculo.
2.2

Todo texto pasa por i18n (CA/EN/ES)

Ningún texto se codifica directamente ("hardcoded"). Todo va vía el diccionario de frontend/js/01-core.js: una clave en ca:{}, en:{} y es:{}, y en el HTML/JS se usa data-i18n o window.t(clau).

Por qué. El idioma se asigna por usuario. Un texto hardcoded sale siempre en catalán y rompe la experiencia del usuario inglés o castellano. Texto nuevo = siempre la clave en los 3 idiomas (vía los agentes traductores).
2.3

Los informes son autocontenidos

Los informes monográficos llevan los datos inyectados dentro del propio HTML. Se conserva siempre la versión con datos, nunca una plantilla vacía sin rellenar.

Por qué. Si una actualización sobrescribe un informe ya publicado con la plantilla vacía, el informe se queda sin datos. La verificación obligatoria antes de publicar es confirmar que no queda ningún hueco sin rellenar.
2.4

Despliegue controlado y trazable

Los cambios se publican siempre por una vía única y versionada, de forma que cada actualización quede registrada y sea reproducible. Nunca se sube un fichero "a mano" saltándose ese flujo.

Por qué. Modificar directamente el entorno de producción al margen del flujo deja el sistema en un estado inconsistente que puede bloquear silenciosamente las siguientes actualizaciones. Mantener un único camino de publicación evita sorpresas.
2.5

Colisiones de funciones JS

El JS vive en 9 módulos (01-core.js09-crm.js) que comparten un único scope global. Una function _foo() redeclarada sobrescribe silenciosamente la anterior (la última que se parsea gana).

Por qué. Pasó con _loadSheetJS: dos versiones, la segunda ganaba por hoisting → el bug sobrevivió 5 commits. Regla: antes de declarar function _helper(), haz grep -r en los 9 módulos. Si colisiona, pon un nombre específico del contexto.
2.6

Consistencia visual vía CSS global

Todos los bloques con el patrón título → descripción → filtros tienen el mismo espaciado vertical, gobernado por shared.css. Anchura uniforme (width:90%; max-width:1900px).

Por qué. Nunca margin-top inline en los banners o filtros. Un bloque nuevo con esta estructura no hay que estilarlo: el CSS global ya lo cuadra.
2.7

Colores solo vía variables CSS

Hay dark mode (por defecto) y light mode (monocromo estricto: negro/blanco/grises, solo verde y rojo para positivos/negativos). Nunca hardcodear colores: siempre var(--xxx).

Por qué. Para que se adapte al tema. Excepción: Chart.js no resuelve var() en el canvas → dentro de las configs de gráficos se usan grises neutros literales que funcionan en ambos temas.
2.8

Las API keys de solo lectura no se rotan

Para keys de terceros (Klaviyo, Shopify) con scope solo lectura, si se exponen accidentalmente no se rotan: el riesgo es limitado (se pueden leer datos, no modificar nada).

Por qué. Las keys read-write o con permisos sensibles sí deben rotarse.
2.9

UK es un mundo aparte

UK tiene su propia tienda, almacén, Klaviyo y moneda (GBP→EUR). Se ve en Realtime, Negocio, Producto y "Operaciones UK".

Por qué. SE EXCLUYE de Operaciones, Stocks, Analítica y CRM del shop principal (sus pedidos no afectan a nuestra logística). Las ventas del año anterior (LY) pre-abril 2025 vienen de un override de Excel (la BD no es fiable).
03
Arquitectura

El sistema de un vistazo

El dashboard es un proceso de 4 capas. La clave de todo es la capa de snapshots: ninguna pantalla ni email consulta nunca la base de datos en vivo.

Las 4 capas · flujo de datos

CAPA 1Fuentes
Shopify tienda principal Shopify tienda UK Klaviyo email/SMS, campañas, flows GA4 canales de adquisición REVENI devoluciones/RMA Transportistas (tracking) Banco central (cambio GBP)
captura automática
CAPA 2Base de datos centralizada
pedidosdevolucionesinventario sesionesanalítica marketingventas POS funnel UKusuarios
publicación periódica
CAPA 3Snapshots publicados
realtimeanalíticastocks operacionespresupuestocrm marketingdevolucionesstock UK
consulta autenticada
CAPA 4aFrontend
12 páginas refresco continuo (Realtime) actualización periódica (pedidos/stock)
CAPA 4bEmails · Chat · Informes
Email diario/semanal (insights) Manuel (chat) lee los mismos datos Informes monográficos

El patrón snapshot · por qué existe

El frontend, el email diario y el chat Manuel no consultan nunca la base de datos en vivo: leen los mismos snapshots publicados que el sistema regenera periódicamente.

  • Una sola fuente de verdad. Es imposible que el dashboard, el email y Manuel muestren cifras distintas: todos leen el mismo dato del mismo snapshot.
  • Velocidad. Leer un snapshot en caché es prácticamente instantáneo; recalcularlo desde la base de datos sería mucho más lento.
  • No sobrecarga la base de datos, que ya recibe escrituras continuas de los procesos de captura.
  • Consistencia temporal. Todos ven la misma foto del mismo instante.
🌍
Dónde vive todo. El dashboard se sirve desde un servidor en la nube con conexión segura (HTTPS), accesible en dashboard.castaner.com. La base de datos, los procesos de captura y los snapshots conviven en ese mismo entorno, separados del navegador del usuario.
⚠️
Optimización clave. El snapshot de Realtime había crecido demasiado y tardaba en cargar. Se aligeró enviando al navegador solo el detalle de pedidos de los últimos días; los meses anteriores se cargan bajo demanda al consultarlos.
04
Producto

Las páginas, en clave de negocio

Cada pestaña responde una pregunta de negocio. "Quién la ve" indica los roles con acceso (el admin lo ve todo).

Real Time
"¿Qué está pasando AHORA mismo?" Ventas, pedidos, conversión de hoy en vivo (refresco 90 s).
Quién: Todos
Negocio
"¿Vamos bien respecto al presupuesto y al año anterior?" Progreso sobre budget, indicadores por país, mes/año en curso.
Quién: Gestión, agencia, dirección, marketing
Producto
"¿Qué modelos se venden y cuáles se piden cuando no hay?" Rankings, mix y devoluciones por modelo, todo por 4 canales (Web · Tiendas · Marketplaces · Total).
Quién: Todos (operativo)
Operaciones
"¿Cómo va el back-office?" Tres vistas en una pestaña: Pedidos (fulfillment, envíos atascados, PUDO), Devoluciones (motivos REVENI + ciclo del RMA) y Stocks (inventario, alertas de restock/tallas/deadstock, evolución).
Quién: Gestión, agencia, operaciones
Operaciones UK
"¿Cómo va la tienda UK?" Negocio + funnel del día + stock del almacén.
Quién: Equipo UK, gestión, agencia
BBDD
"¿Cómo está nuestra base de datos de clientes?" Suscriptores, altas/bajas, compradores FY, estado Klaviyo.
Quién: Gestión, agencia, marketing
CRM
"¿Qué funciona de nuestro email marketing?" Top campañas/flows por revenue, subjects, comparativa revenue TY/LY.
Quién: Gestión, agencia, dirección, marketing
Analítica
"¿Dónde perdemos a los visitantes por el camino?" Funnel (sesiones→carrito→checkout→compra), canales de adquisición, evolución mensual.
Quién: Gestión, agencia, dirección, marketing
Informes
"¿Dónde están los informes monográficos?" Directorio de informes (Member Days, Checkout US, etc.).
Quién: Admin y gestor
Admin
"¿Quién tiene acceso y a qué?" Gestión de usuarios, roles, permisos, suscripciones a emails, seguimiento de actividad.
Quién: Solo admin
🎙️
El chat Manuel (no es una pestaña de datos) responde en lenguaje natural cualquier pregunta sobre las cifras del dashboard, leyendo los mismos snapshots JSON. Tiene voz (micrófono + lectura en voz alta).
05
Automatización

Los ritmos automáticos

Todo funciona solo gracias a una veintena de procesos programados. Esta es la jornada de un día normal.

continuo
Captura de pedidos
Recoge pedidos, devoluciones y tracking de Shopify cada pocos segundos
~1 min
Publicación de snapshots
Regenera los snapshots que leen el dashboard, los emails y el chat
~10 min
Sincronización UK
Pedidos de la tienda UK + conversión de divisa GBP→EUR
~15 min
Inventario
Captura el inventario de Shopify (con histórico por referencia)
~15 min
Analítica
Captura sesiones, funnel y datos por país
~30 min
Sincronización de marketing
Actualización incremental de Klaviyo (newsletter + SMS + histórico)
cada hora
Sesiones
Sesiones de las dos tiendas, con el reparto de mercado correcto
cada 2 h
Stock + funnel UK
Inventario y funnel del día de la tienda UK
de madrugada
Copia de seguridad
Backup automático de la base de datos, con retención de varios días
de madrugada
Compradores del año fiscal
Reconstrucción del cruce entre compradores y base de contactos
de madrugada
Marketing (12 meses)
Campañas y flows de Klaviyo de los últimos doce meses
de madrugada
Back-in-Stock
Cohorte de solicitudes "avísame cuando vuelva" de los últimos 90 días
de madrugada
Devoluciones
Descarga del año fiscal completo de devoluciones desde REVENI
primera hora
Ventas de tienda física
Reconstruye las ventas de tienda física por punto y día
07:45
🛡️ Auditoría de datos
Auditoría de coherencia de los KPIs; alerta SOLO si hay un problema real
08:00
✉️ Email diario
Briefing diario redactado por el asistente redactor
lun 08:05
✉️ Email semanal
Resumen semanal más detallado, los lunes
lun
Copia externa
Copia de seguridad de la base de datos fuera del servidor principal
cada hora
Informe Checkout US
Regenera el informe horario del test de checkout en EE. UU.
bajo demanda
Canales GA4
Datos de adquisición de GA4, reactivable una vez al día
🧭
Orden intencionado por la mañana. Primero los snapshots de la noche (CRM, Klaviyo, REVENI, POS) → después el auditor (07:45) valida que todo cuadra → y solo entonces sale el email diario (08:00), ya sobre datos verificados.

El calendario de comunicación

Los emails de insights conocen el calendario comercial (campañas, Early Access y Rebajas por mercado). Sirve para contextualizar las comparativas vs el año anterior: a menudo una caída respecto al año pasado no es una alarma sino un desplazamiento de calendario.

📅
Ejemplo típico. Una caída fuerte de la web respecto al año anterior puede deberse simplemente a que ese mismo día, el año pasado, arrancaban las rebajas (un pico), mientras que este año la demanda se ha adelantado al Early Access de días antes. Lo mismo ocurre por mercado cuando un país abre su Early Access más tarde: no es un problema de conversión, sino de calendario.

El calendario se mantiene al día a medida que se planifican nuevas campañas. Detalle de marca: Castañer NO hace Black Friday (posicionamiento "NO Black Friday").

06
Arquitectura

Decisiones clave y el porqué

Registro de decisiones de arquitectura. Formato: Decisión → Contexto → Por qué.

🗂️Snapshots publicados en lugar de la base de datos en vivo
Contexto
El frontend, los emails y el chat necesitan datos.
Por qué
Una sola fuente de verdad (imposible que diverjan cifras), respuesta casi instantánea, sin sobrecargar la base de datos (que recibe escrituras continuas), y todos ven la misma foto temporal. Es el principio central de todo el sistema.
Conversión realtime = pedidos ÷ visitantes
Contexto
La tasa de conversión de Real Time.
Por qué
La tasa de conversión que ofrecía la fuente externa mezclaba numerador y denominador de mercados distintos (daba valores absurdos para UK) y llegaba con horas de retraso. La fórmula pedidos ÷ visitantes × 100 usa los mismos números que se VEN en la card → cuadra a ojo y es verificable.
🔑Acceso multiusuario con sesión y roles
Contexto
El dashboard pasó de ser una herramienta de un solo usuario a usarse por varios equipos.
Por qué
Cada persona entra con su propia sesión y solo ve las páginas que le corresponden según su rol. El acceso a los datos requiere haber iniciado sesión. Se cuidó además que la pantalla de acceso encaje con la estética de la marca.
🤖Emails redactados con la suscripción de IA
Contexto
La redacción de los emails no debía depender del consumo por uso, que podía agotarse y dejar sin briefing.
Por qué
La redacción se hace con una suscripción de IA de coste fijo, sin consumo variable. El sistema calcula los datos, el asistente redactor escribe, los traductores traducen y el sistema envía.
🇬🇧Tienda UK separada, con funnel capturado directamente
Contexto
UK funciona como una tienda online aparte.
Por qué
El funnel por geolocalización de la tienda principal no recogía bien el Reino Unido. Por eso el funnel de UK se captura directamente de su propia tienda. Mismo criterio para las ventas (con un ajuste para el dato del año anterior previo a abril de 2025) y para el tráfico.
📅Calendario de comunicación en los insights
Contexto
Caídas vs LY que parecían alarmas.
Por qué
Muchas son desplazamientos de calendario (el Early Access adelanta la demanda). Dar el calendario al redactor permite explicarlo por mercado en lugar de hacer saltar falsas alarmas.
🌐i18n trilingüe CA/EN/ES
Contexto
El dashboard lo usan equipo interno + agencia, en idiomas distintos.
Por qué
Todo texto pasa por diccionario → el idioma se asigna por usuario y el dashboard se abre directamente en su lengua. El manuel (chat) queda en catalán por diseño.
🛡️Auditor de datos proactivo
Contexto
Durante un tiempo aparecieron números mal calculados que había que detectar a mano.
Por qué
Un motor de reglas audita los snapshots cada día a primera hora; si hay hallazgos, la IA los verifica y descarta falsos positivos; solo envía alerta si queda alguno real. "Contrasta antes de afirmar", automatizado.
07
Inteligencia

Los asistentes de IA

Cuatro asistentes especializados que apoyan el día a día del dashboard.

✍️
Redactor de emails
Redacta el texto del briefing diario/semanal en catalán, con el tono de la casa y reglas anti-invención (no recalcula números, solo los interpreta).
Cuándo: automáticamente cada día y cada lunes. También a mano, para generar cualquier resumen o email basado en datos del dashboard.
🇬🇧
Traductor de inglés
Mantiene sincronizadas las traducciones al inglés del dashboard y traduce cualquier texto con el glosario e-commerce canónico.
Cuándo: al añadir texto nuevo en catalán o cuando se necesita la versión inglesa de cualquier texto.
🇪🇸
Traductor de castellano
Igual que el anterior pero hacia el castellano (neutro, evitando catalanismos).
Cuándo: al añadir texto nuevo o cuando se necesita la versión castellana.
🛡️
Auditor de datos
Verifica un número, card, KPI o afirmación contra los datos reales; dictamina ✅/⚠️/❌ con evidencia, diagnostica la causa y propone la corrección (sin aplicarla). Solo lectura.
Cuándo: cuando un valor hace dudar, o para validar un bloque o página antes de confiar en él. También se ejecuta solo cada día a primera hora.
08
Referencia

Glosario y convenciones

Canales

TérminoDefinición
WEBVentas de la tienda online (incluida la app de compra). Todos los mercados, incluido UK.
MARKETPLACESVentas en marketplaces. Importes pequeños; la señal real es que la mayoría no arrancan (solo El Corte Inglés factura de forma consistente).
TIENDAS / POSVentas de tienda física, por punto de venta. Fuera de los KPIs online.

Mercados

ESFRIT UK (tienda internacional) USGR Resto de la UE

Los principales agregados de mercado incluyen UK.

Métricas

TérminoSignificado
Ventas netas (pre-IVA)Importe de las líneas tras descuentos, sin IVA ni envío. Métrica de referencia.
Bruto vs NetoEl KPI grande "Ventas hoy" y las cards de mercado son BRUTO (no restan devoluciones). Las tablas de detalle y Objetivos/Mensual son NETO (sí restan). El email diario usa BRUTO.
LY (Last Year)Mismo día del año anterior, leído del snapshot publicado (no de la base de datos en vivo).
MTDMonth to date — mes en curso acumulado.
FY (Fiscal Year)Año fiscal de Castañer: agosto → julio.
Same-storeCrecimiento de tiendas abiertas los 2 años (excluye nuevas como París/Roma y cerradas como La Roca). El % bruto de tiendas lo inflan las nuevas.
Visitantes vs SesionesVisitantes = visitantes únicos (algo menos que sesiones). Sesiones = con el reparto de mercado correcto. Para UK, los visitantes se derivan de las sesiones.
Conversión (realtime)pedidos ÷ visitantes × 100 (los mismos números que se ven en la card).

Otros términos

  • Funnel: Sesiones → Carrito → Checkout → Compra (fuente Shopify; "ficha de producto" solo de GA4).
  • BIS / Back-in-Stock: solicitudes de "avísame cuando vuelva". "Dinero perdido" = (solicitudes − conversiones) × precio medio, sin IVA.
  • RMA: proceso de devolución de REVENI (estado, método, transportista, tiempos). Alrededor de la mitad de las devoluciones son por talla.
  • PUDO / pickup point: paquete dejado en un punto de recogida; detectado a posteriori por la información del transportista (estado virtual "Pendiente de recogida").
  • PUDO ≠ checkout: Castañer no ofrece puntos de recogida de terceros en el checkout.