Diseñar una segmentación fiable con conciliación
Un caso ficticio de arquitectura: calcular el segmento es fácil; el diseño está en garantizar exactamente uno por cuenta elegible, salidas explícitas y reejecuciones seguras.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01El resultado
Cada cuenta elegible tiene exactamente un segmento vigente, cada salida se escribe de forma explícita, las reejecuciones son idempotentes y cada ejecución termina con una conciliación cuyas diferencias tienen responsable.
Hay cuentas que acaban con dos segmentos o con ninguno, y las campañas siguen dirigiéndose a cuentas que ya se han recuperado.
¿Cómo tiene cada cuenta elegible exactamente un segmento vigente, y cada reejecución sigue siendo segura?
Publicar la población completa de cada periodo con bajas explícitas, aplicarla como un diff idempotente y conciliar la pertenencia esperada con la real después de cada ejecución.
Cada mes, los clientes se clasifican en En objetivo, Por debajo, En riesgo y Sin venta según su rendimiento frente a objetivo. El segmento dispara tareas de recuperación en el CRM y define la pertenencia a campañas. El pipeline escribe los segmentos nuevos pero nunca elimina los antiguos, y una reejecución tras un fallo escribe algunas cuentas dos veces.
02La realidad · situación actual
Qué hacen hoy los datos.
- Algunas cuentas tienen dos segmentos después de una reejecución
- Las cuentas sin ventas y sin objetivo no reciben ningún segmento
- Las cuentas que salieron de la población conservan su último segmento durante meses
- Las campañas siguen incluyendo cuentas que ya se han recuperado
- Nadie sabe decir qué cuentas se saltó la última ejecución
03Flujo objetivo
De dónde vienen los datos, adónde van… y cómo.
Cada traspaso se nombra con su modo. El modo sigue la tolerancia del negocio a la espera, a la inconsistencia y a la pérdida.
- 01 · Plataforma de datosPoblación elegibleTraspasa por Batch
Cuentas activas con objetivo o con histórico de ventas.
- 02 · Plataforma de datosCálculo del segmentoTraspasa por Batch
Exactamente un segmento por cuenta elegible y periodo.
- 03 · Plataforma de datosDiff frente a lo vigenteTraspasa por Batch
Entradas, cambios y bajas, por cuenta y periodo.
- 04 · CRMPertenencia en el CRMTraspasa por Evento
Segmento vigente, de solo lectura, con versión.
- 05 · Plataforma de campañas · CRMCampañas y tareas
Altas, salidas y tareas a partir de los cambios de pertenencia.
04Contratos
Qué significa una fila o un mensaje.
Significado, granularidad, clave, frescura y responsable, por escrito antes de mapear nada.
Pertenencia al segmento
El segmento vigente de una cuenta elegible en un periodo.
- Granularidad
- Cuenta × periodo
- Clave
Cuenta + periodo + versión de ejecución- Frescura
- Mensual, reejecutable
- Responsable
- Operaciones de ventas
Cambio de pertenencia
Una entrada, un cambio o una baja que aplicar en los sistemas destino.
- Granularidad
- Cuenta × cambio
- Clave
Cuenta + periodo + tipo de cambio- Frescura
- En el día siguiente a la ejecución
- Responsable
- Equipo de la plataforma de datos
05Dimensión clave · Población, bajas y reejecuciones idempotentes
Pertenencia esperada frente a pertenencia real
Después de cada ejecución, la población publicada se compara con lo que realmente tienen el CRM y las campañas. Cada tipo de diferencia tiene un responsable y una reparación.
Cuentas elegibles del periodo, tal como se publicaron
| Clave | Publicado | En CRM y campañas | Resultado |
|---|---|---|---|
ACC-A12 | En objetivo | En objetivo | CoincideAmbos lados coinciden. |
ACC-B07 | En riesgo | Por debajo | DiferenciaUna reejecución aplicó una versión antigua después de la nueva. |
ACC-C33 | Por debajo | — | FaltaEl batch de writeback se detuvo a mitad. |
ACC-D19 | No elegible | Sin venta | InesperadoLa cuenta salió de la población; su baja nunca se escribió. |
ACC-E02 | En riesgo | En riesgo + Sin venta | DiferenciaDos pertenencias: la antigua nunca se cerró. |
ACC-F58 | Sin venta | Sin venta | CoincideAmbos lados coinciden. |
- Coincide
Misma cuenta, mismo segmento, misma versión.
- Responsable
- Nadie
- Acción
- Registrar la comprobación.
- Diferencia
Misma cuenta, distinto segmento o versión.
- Responsable
- Equipo de la plataforma de datos
- Acción
- Volver a aplicar la versión vigente; el upsert por clave es idempotente.
- Falta
Publicado, pero ausente en los sistemas destino.
- Responsable
- Operaciones de integración
- Acción
- Reenviar las claves que faltan de esa ejecución.
- Inesperado
Presente en los sistemas destino, pero no en la población publicada.
- Responsable
- Equipo de la plataforma de datos
- Acción
- Escribir la baja; sacar de las campañas y cerrar las tareas.
Una cuenta sin segmento y una pertenencia obsoleta son el mismo fallo visto desde dos lados. Solo una comparación de la población completa ve ambos.
07Fallo y recuperación
Diseñar el camino del fallo antes que el camino feliz.
- La activación se completa solo en parteConciliación: faltaReenviar las claves que faltan; no se toca nada másOperaciones de integración
- Una reejecución tras un falloMismo periodo, nueva versión de ejecuciónAplicar por versión; las versiones antiguas se ignoranEquipo de la plataforma de datos
- Una cuenta sale de la poblaciónConciliación: inesperadoBaja explícita; salida de las campañas y cierre de las tareasEquipo de la plataforma de datos
- Una cuenta elegible se queda sin segmentoRecuento de la población frente a recuento segmentadoHacer fallar la ejecución antes de publicarOperaciones de ventas
08Arquitecturas candidatas
Opciones creíbles, evaluadas frente a estas premisas.
Recalcular y sobrescribir en el CRM
Poblaciones pequeñas que nunca se reducen
Coste: Las bajas y las cuentas sin segmento son invisiblesMantener los segmentos solo en analítica
Segmentos que informan, no que actúan
Coste: No pueden disparar tareas ni campañasPoblación completa, bajas explícitas, diff idempotente y conciliación
Segmentos que disparan acciones
Coste: Requiere una versión de ejecución y un paso de conciliación09La segunda capa
Preguntas que cambian el diseño.
Población
- ¿Cuál es la población elegible?
- ¿Cómo se detecta una cuenta sin segmento?
- ¿Cómo se representan las bajas?
Activación
- ¿Qué pasa si la activación se completa solo en parte?
- ¿Cómo se mantienen alineadas las campañas y tareas posteriores?
- ¿Qué sistema es la referencia para el segmento vigente?
Reejecuciones e histórico
- ¿Cómo se garantiza la idempotencia de una reejecución?
- ¿Cómo se conserva el histórico de pertenencia?
- ¿Quién responde de cada tipo de diferencia?
10Decisiones y entregables
Qué produce el trabajo.
- 01Contrato de segmentación
- 02Modelo de elegibilidad
- 03Semántica de las bajas
- 04Versionado de ejecuciones y regla de reejecución
- 05Diseño de la conciliación
- 06Modelo de estados de activación