Analítica rápida con millones de contactos, sin proceso nocturno por lotes

Un responsable de marketing abre Contactos, entra en Analítica y lee: "12 contactos nuevos hoy". Son las cuatro de la tarde. En realidad, cuarenta huéspedes se han dado de alta desde medianoche. El panel no está roto. Funciona exactamente como fue diseñado, y ese es el problema silencioso de toda una categoría de productos de analítica.

Ese diseño es la foto fija nocturna: un proceso se ejecuta una vez al día, resume la base de datos y escribe los resultados en una tabla pensada para leerse rápido. Cada carga del panel a partir de ahí se limita a leer una respuesta ya preparada, en vez de hacer la pregunta real. Es un instinto totalmente razonable. Una base de datos de contactos con un par de millones de filas es realmente cara de resumir desde cero con cada clic, y nadie quiere que una sola vista de página dispare una consulta que recorra toda la tabla.

El coste de ese instinto es fácil de pasar por alto porque nunca se anuncia. La cifra en pantalla transmite seguridad. Tiene las comas en su sitio y un gráfico debajo. Nada en ella parece desactualizado. Pero es una fotografía, no una ventana, y la distancia entre la fotografía y la realidad puede llegar a un día completo, para cada cliente, independientemente de si alguien la está mirando, e incluso de si algo ha cambiado. La desactualización deja de ser un caso extremo y se convierte en el estado normal del producto.

Primero construimos la foto fija, y la retiramos el mismo día

Esto no es el error hipotético de un competidor. Fue la primera versión que lanzamos para la propia Analítica de Contactos de GuestMaker. Un flujo de trabajo nocturno calculaba una foto fija, la escribía en una tabla dedicada y el panel de cada cliente leía desde esa tabla. Funcionaba. También significaba que cada grupo hotelero que lo usaba veía cifras que, por diseño, podían ir hasta 24 horas por detrás durante todo el día, como caso normal y no como peor escenario.

La reemplazamos el mismo día en que vimos lo que eso significaba de verdad en la práctica, con una arquitectura que consulta en directo, contra la base de datos real, en cada carga.

Qué significa «en directo» en siete pestañas

Analítica de Contactos es una suite de siete pestañas situada sobre toda la base de datos de huéspedes de un grupo hotelero: Resumen, Contactabilidad y Consentimiento, Salud de la Base de Datos, Ciclo de Vida y Reservas, Demografía e Idioma, Fuentes y Adquisición, y una tabla comparativa Por Hotel para grupos que gestionan decenas de establecimientos bajo una misma marca. La pestaña Ciclo de Vida y Reservas se apoya en la misma lógica de etapas del huésped que permite al conserje con IA saber si un huésped ya ha llegado realmente. Cada pestaña responde a una pregunta operativa realmente distinta, desde "a cuántos de nuestros huéspedes podemos contactar de verdad por correo electrónico o WhatsApp" hasta "cuál de nuestros establecimientos está creciendo y cuál se está reduciendo discretamente".

El detalle que convierte "directo" en algo más que una palabra de marketing es lo que ocurre cuando haces clic en una cifra. Cada estadística clicable de cada pestaña te lleva directamente a la lista de contactos filtrada que hay detrás, las filas exactas que componen esa cifra, el mismo desglose que recorremos pestaña por pestaña en qué responde realmente cada una de las siete pestañas. Eso solo funciona de forma honesta si la cifra salió de la tabla real hace un momento. Una foto fija y una lista de contactos pueden separarse en cuanto un huésped cancela su suscripción o entra una nueva reserva, y un enlace profundo construido sobre datos desactualizados acaba llevándote a los huéspedes equivocados, o a ninguno. La analítica en directo y un desglose fiable son la misma decisión, no dos funcionalidades separadas.

Medido, no supuesto

Nada de esto vale mucho como afirmación si no aguanta frente a una base de datos real y grande, así que se probó con una base de datos a escala de verdad, bien entrada en los millones de registros de huéspedes repartidos entre decenas de establecimientos individuales. La mayoría de las siete pestañas responde lo bastante rápido con ese conjunto de datos como para no necesitar caché en absoluto. Simplemente se ejecutan.

Dos vistas no. Un resumen por establecimiento entre decenas de hoteles y una cifra que muestra cuántos contactos tienen una reserva real asociada tardan bastante más que todo lo demás en la página, con un margen lo bastante amplio como para que servir cualquiera de las dos en directo con cada clic, para cada usuario, fuera irresponsable.

El resumen por establecimiento es, en realidad, la misma pregunta de correspondencia de huéspedes que una plataforma de datos de clientes para grupos hoteleros existe para responder, solo que formulada de forma agregada en vez de huésped por huésped. Probamos varias formas distintas de escribir esa segunda consulta antes de aceptar que la lentitud no era un problema de optimización de consulta. Es estructural.

La única parte que sigue siendo realmente lenta, dicha claramente

Esta es la parte honesta, y merece la pena nombrarla directamente: la consulta que conecta los contactos de un grupo hotelero con sus reservas reales tiene que entrar en una tabla que registra los huéspedes de las reservas de toda la plataforma, y esa tabla no lleva un marcador por cliente como sí ocurre en la mayor parte del esquema. Responder a "cuántos contactos de este grupo hotelero han reservado alguna vez" exige tocar una porción relevante de una tabla compartida muy grande, porque ahora mismo no hay una forma barata de acotarla primero a un solo cliente. No es un problema de caché. Es una carencia de esquema, y la solución real es hacer lo que corresponde: añadir ese marcador a la tabla subyacente e indexarlo, no pegar una solución provisional en la ruta de lectura.

Esa solución está acotada y entendida. También sigue sin estar hecha, a propósito. Un backfill sobre millones de filas en una tabla que se escribe constantemente merece su propia migración cuidadosa y deliberada, no un añadido apresurado pegado a una corrección de analítica. Publicar ahora la respuesta provisional honesta era mejor decisión que lanzar mal la solución real bajo presión de tiempo.

La respuesta provisional es una caché corta, aplicada solo a esas dos vistas concretas, que sirve al instante la última respuesta buena mientras recalcula discretamente en segundo plano y se vuelve a comprobar cada 30 minutos. En la práctica, eso significa que casi cada vista de esas dos cifras está fresca o refrescándose sin que se vea, y que la única vez que alguien espera de verdad a la cifra real es la primera vez que un cliente nuevo abre esa pantalla. Después de eso, es instantánea para ese cliente, para siempre.

Rápida donde puede serlo, honesta donde no

Hay una diferencia real entre "esto es demasiado caro de calcular con cada clic" y "no quisimos pensarlo", y una arquitectura que lo convierte todo en fotos fijas tiende a mezclar ambas cosas. En cuanto una parte de un panel está precalculada, es fácil precalcular el resto por defecto, porque resulta más sencillo construir un único patrón que justificar dos. La disciplina que merece defenderse es la contraria: usar datos en directo por defecto, medir con honestidad contra datos reales antes de recurrir a una caché, y utilizarla solo donde las cifras lo obligan de verdad, en la superficie más pequeña posible.

Nombrar la parte que sigue siendo lenta y decir con claridad qué la arreglaría y por qué aún no está arreglada no es admitir una debilidad. Es la alternativa a lo mucho más habitual: no decir nada y dejar que el cliente descubra por su cuenta la desactualización, casi siempre en el peor momento posible, casi siempre como un ticket de soporte en vez de como una decisión documentada.

Qué preguntar si evalúas esto a tu propia escala

Si estás valorando un CRM o una plataforma de analítica para una base de datos de huéspedes de millones de registros, hazle al proveedor una pregunta directa: esta cifra, ¿está en directo o es una foto fija? Y si es una foto fija, ¿cuánto puede desactualizarse antes de que alguien lo note o lo diga? La mayoría no tendrá una respuesta clara, porque la mayoría no ha tenido que construir más allá del punto en el que una consulta en directo se vuelve realmente cara. Lo interesante en ingeniería no es evitar ese punto. Es lo que hace un equipo cuando llega ahí, y si te lo cuenta.

Analítica de Contactos se apoya en el mismo registro de huésped que alimenta la CDP de GuestMaker, la capa de identidad que resuelve un único huésped a través de cada estancia, cada canal y cada establecimiento de un grupo antes de que la analítica llegue siquiera a resumir nada. Si tienes curiosidad por cómo se construye ese registro desde el principio, el registro de huésped que nunca olvida explica la resolución de identidad que hay debajo.