Tu glosario no es semántica

Una definición te dice qué es un cliente. No te dice cuáles filas califican.

En 2008 me tocó construir un modelo de fidelización para una operación de venta directa por catálogo. El pedido venía de gerencia comercial, con apoyo de TI. Las vendedoras eran independientes: no firmaban nada que las obligara a comprar en cada campaña, y una campaña duraba unas tres semanas. Si hacían pedido, tenía que alcanzar un mínimo para que fuera despachable. Había además escalas de descuento por volumen. La fidelidad ahí no era un gesto de cariño. Era plata.

El indicador que más le importaba al negocio era negativo y tenía nombre propio: NECA, No Envío Campaña Anterior. Una vendedora activa a la que no le despachamos nada la campaña pasada.

Lo primero que aprendí mirando esos datos es que un NECA no significa lo que el nombre te hace pensar. Podía ser que ella no hubiera pedido. También podía ser que sí pidiera y el pedido llegara tarde, o que no hubiera inventario al momento del despacho.

O sea que el indicador de deslealtad de la fuerza de ventas disparaba, algunas veces, porque nosotros no habíamos hecho nuestro trabajo.

La definición nunca fue el problema

Acá está lo resbaloso: no había nada malo con la definición. “Una vendedora activa es la que nos compra con regularidad.” Cierto. Claro. Inútil.

Es inútil porque no te dice cuándo, y no te dice bajo qué condiciones una fila dada califica. Describe el concepto en abstracto y se queda muda exactamente donde empieza el trabajo.

Hay una distinción que vale la pena afilar acá, porque la mayoría de los glosarios de datos viven del lado equivocado de ella.

Una descripción declarativa dice qué es algo en principio: un cliente es alguien que nos ha comprado. Una definición operacional dice qué condiciones tiene que cumplir una fila para contar: un cliente es alguien con al menos una transacción pagada en los últimos 24 meses y una cuenta al día. La primera se lee bien en un glosario. La segunda es la que de verdad podés ejecutar.

No son la misma cosa, y la brecha entre ambas es donde yo diría que vive la semántica de verdad. Entidades, relaciones y definiciones te dan un vocabulario estructurado. Eso es valioso. Nombrar bien las cosas es trabajo real, y la mayoría de las organizaciones ni siquiera hace eso. Pero un vocabulario no es un significado. El significado es el conjunto de condiciones bajo las cuales una fila específica es la cosa que el vocabulario nombra.

El criterio no era una frase. Era una máquina.

Lo que terminamos entregando en 2008 no fue una definición mejor redactada. Entregamos un grafo con un camino de entrada y dos de salida, cada transición con su fecha.

El camino de entrada tenía cuatro compuertas: firma del contrato, revisión y aprobación de crédito, primer pedido, segundo pedido. Recién ahí entrabas al núcleo de vendedoras activas, las que venían comprando en las últimas campañas seguidas. Nadie es cliente por firmar, y nadie lo es por comprar una vez.

Las salidas eran dos, y esa fue la parte que costó. La primera es por envío: NECA, después RENECA, y de ahí inactiva con una, dos o más campañas consecutivas sin pedir. La segunda es por pago: una vendedora que sí pide, que quiere comprar, pero que no canceló el pedido anterior y por eso no se le despacha.

En los datos las dos se ven idénticas. No hubo envío esta campaña.

En el negocio no son la misma cosa, y la prueba es el teléfono. A las NECAs las llamás para que te pidan. A las que tienen problema de pago hay que resolverles el pago. No es la misma llamada de gestión, así que no es el mismo concepto. Redefinimos NECA y RENECA sobre el no envío, pero excluyendo a las que estaban frenadas por crédito, para que no cayeran en la misma pila.

Eso es lo que quiero subrayar, porque es precisamente lo que un glosario no puede hacer: la condición de pertenencia quedó definida por la acción a la que servía. No por la estructura del dato, que era la misma en los dos casos.

Y RENECA no existía antes de ese proyecto. Lo pusimos nosotros. El negocio hacía un esfuerzo de telemarketing sobre las NECAs y al segundo strike las daba por perdidas, sin ningún nombre en el medio. Ponerle nombre al segundo strike fue el acto de modelado: mientras se llamara “perdida”, no había forma de tratarla distinto de una perdida.

La tabla de no hechos

Un tema que se repite en los modelos tabulares que construyo son las tablas de no hechos: eventos de negocio que debieron ocurrir, o que se esperaba que ocurrieran, y no ocurrieron. El producto en promoción que no se vendió. El cliente activo que no compró. La NECA.

Un hecho se registra solo. Alguien facturó, alguien despachó, y queda la fila. Un no hecho no tiene fila. Existe solamente si antes declaraste la regla que lo vuelve faltante, y por eso es el lugar donde la ausencia de condición de pertenencia se cobra más caro. Sin criterio no hay ausencia. Hay nada.

Y hay una segunda cosa, que es la que nos mordió. La regla dice que debía haber un envío. No dice quién debía hacerlo. Cuando la bodega no tenía inventario, el no hecho era nuestro y el reporte se lo cobraba a ella.

Por qué una definición no alcanza: necesario vs. suficiente

Hay una forma precisa de decir qué falta. Una entrada de glosario carga condiciones necesarias: si algo es un cliente, entonces te ha comprado. Eso te deja razonar en una sola dirección. Lo que hace falta para mirar una fila y decidir son condiciones necesarias y suficientes: cumplí estos criterios y sos miembro, sin que nadie más tenga que opinar. (Los que vengan de ingeniería de ontologías van a reconocer acá la distinción de OWL entre una clase primitiva y una clase definida; el modelado de datos no tiene un par de términos tan limpio para lo mismo.)

Un glosario, en el mejor de los casos, te da la mitad necesaria. Y casi nadie escribe la otra.

Dejala afuera y la brecha no desaparece. Alguien aguas abajo la llena (un analista, un dashboard, cada vez más un LLM), tomando la decisión que tu modelo declinó tomar. Van a elegir un umbral, adivinar un borde, asumir una intención. A veces adivinan como vos lo habrías hecho. Muchas veces no. Y cada adivinanza es un lugar donde el número en la pantalla de alguien deja de significar lo que esa persona cree.

Seis años después, tres respuestas

Hace unos doce años trabajaba en una POC para un cliente en Estados Unidos. El corazón de lo que construíamos era un modelo tabular analítico, y el cliente había pedido que le metiéramos “un poco de data science”. Me pareció que un modelo de churn era lo valioso que le podíamos dar, así que armé uno con sus datos reales.

Pasé varios minutos explicando la diferencia entre analítica y data science. En un modelo tabular uno clasifica al cliente con reglas: yo lo sacaba de la lista de activos cuando llevaba sin comprar más días que el percentil 85 del intervalo entre compras de esa base. Global, no por cliente. Segmentábamos ese cálculo solo cuando había diferencias obvias y grandes, mayorista contra detallista, importador contra nacional. Un modelo de churn no funciona así. Corre el eje del tiempo hasta la última compra y mira los eventos anteriores, para pronosticar si ese punto va a ser el final.

El sponsor del proyecto me atajó con algo que tenía su razón: el cliente dejó de ser cliente el día después de la última compra. Cierto, le dije. Y también inútil, porque nosotros no tenemos señal de eso hasta bastante después. Lo sacamos de la lista cuando la regla se dispara, no cuando el hecho ocurrió, porque hasta ese momento no sabemos si va a volver.

Y ahí el gerente de ventas, que me había dejado hablar todo ese rato, dijo: no, ellos dejaron de ser clientes en tal fecha.

Él sabía que había habido un choque con ese cliente y que no iban a renovar el contrato. Eso estaba en el CRM, que nosotros no leíamos. Para mí esa cuenta era una fila interesante en una tabla, un caso de estudio que servía para la demo. Para él era un cliente que querían y cuya pérdida le había dolido. No verifiqué la fecha que dijo. Por la forma en que lo dijo en la sala, a nadie se le ocurrió pedirle la prueba.

Tres respuestas. Las tres correctas.

Y las dos primeras no discrepaban por tener umbrales distintos, que es la explicación cómoda. Discrepaban porque cada disciplina ancla el eje del tiempo en un origen distinto. La regla de actividad ancla en el calendario y pregunta si el evento esperado ocurrió dentro de la ventana. El modelo de churn corre el origen hasta la última compra de cada cliente y mira hacia atrás. No son dos umbrales del mismo eje. Son dos sistemas de coordenadas, y por eso pueden caer a meses de distancia sin que ninguno esté mal.

Tres definiciones operacionales, todas válidas

Ese “churned” no tiene una sola definición operacional. Tiene varias, y cada una es correcta para un propósito distinto.

Definición	Condición de pertenencia	Construida para
Regla de actividad	Más días sin comprar que el percentil 85 del intervalo entre compras de la base	Segmentación
Modelo de churn	Corre el eje a la última compra y pronostica si esa fue la última	Predicción
Evento en el CRM	Choque registrado, avisó que no renueva	Pronóstico de renovación

Ninguna de estas es la correcta en abstracto. La correcta depende de qué estás por decidir. ¿Armás una campaña de recuperación? La regla de actividad sirve. ¿Pronosticás las renovaciones del próximo trimestre? El evento del CRM importa más que cualquier brecha de compra. La definición operacional codifica una decisión sobre el uso, y por eso no puede heredarse de un glosario que no sabe qué estás decidiendo.

Fijate que los dos proyectos fallan al revés uno del otro, y que son las dos únicas formas de fallar que hay acá. En 2008 había una pila con dos conceptos adentro, y el arreglo era partirla. En la POC había un concepto con tres criterios legítimos, y el arreglo era declarar cuál aplicaba a cuál decisión. En los dos casos el glosario estaba bien escrito y no ayudaba en nada.

Juha Korpela argumentó en su publicación Common Sense Data que las entidades, relaciones y definiciones son cómo construís semántica: “Building Semantics with Conceptual Models.” Es un buen post, y esto es mi contrapunto a esa única afirmación. La sala de la POC es exactamente con lo que se topa. El modelo conceptual nombraba “cliente” con limpieza. Aun así no pudo darles a tres personas competentes la misma fecha.

La salida y la puerta: la misma brecha en los dos extremos

El churn es la versión de tiempo del problema: cuándo deja una fila de ser un cliente. Hay una versión espejo en el otro extremo (quién cuenta como uno en primer lugar), y el primer post de esta serie ya tiró de ese hilo. La base de un distribuidor estaba llena de filas que nadie habría llamado clientes: ventas internas, compradores de una sola vez por veinte dólares, favores anotados como pedidos. Ahí la falla era más cruda que esta, porque no existía definición alguna. Acá sí hay una definición, acordada y citable, y aun así no te puede decir cuáles filas están adentro. La misma brecha, en ambos extremos. La salida necesita una condición de pertenencia que la definición nunca provee, y la puerta también. Dejá cualquiera de las dos implícita y toda métrica encima (conteos de clientes activos, tasas de retención, ingreso promedio por cliente) hereda filas que una consulta nunca se le ocurre cuestionar.

La cura es el trabajo más difícil

El arreglo no es una mejor frase en el glosario. Es capturar las cosas que un glosario, por estructura, no puede sostener:

• Las condiciones de pertenencia, o sea los criterios necesarios y suficientes para que una fila cuente.
• Los estados del ciclo de vida, con sus transiciones fechadas: activo, dormido, en churn, perdido, recuperado. Un cliente no es un booleano, y muchas veces tampoco es una escalera de un solo tramo.
• Los caminos de salida, en plural, cuando hay más de uno. Si dos filas idénticas en los datos exigen dos llamadas distintas, son dos conceptos y necesitan dos condiciones.
• Los casos de borde, como la cuenta que avisó antes de que se dispare cualquier umbral, la morosa, o el comprador estacional que siempre pausa y siempre vuelve.
• Y para los no hechos, quién era el obligado. Un envío que no ocurrió necesita decir de quién era la falta, o el reporte se la va a cobrar al que estaba esperando.

Dos cosas más que estos dos proyectos vuelven inevitables.

Cuando varias definiciones operacionales son legítimas, decí cuál aplica a cuál decisión. No porque las otras estén mal, sino porque dejarlo implícito es cómo tres respuestas correctas se convierten en un número equivocado.

Y una condición de pertenencia correcta todavía puede disparar la acción equivocada. “Segundo strike y la damos por perdida” era una regla decidible, limpia y aplicable, exactamente lo que vengo pidiendo en todo este post. Y estaba mal, porque no miraba el valor de la vendedora. A algunas convenía seguirlas trabajando más allá del segundo strike. Escribir el criterio suficiente es el trabajo; que además sea el criterio correcto para la acción es otro trabajo, y no viene incluido.

Si estás construyendo lógica de clasificación encima de esto (segmentación, scoring, cualquier cosa sobre la que un modelo o un agente vaya a actuar), construila sobre la definición operacional. La declarativa no clasifica nada. Nunca fue su intención.

Cierre

Una definición te dice qué es un cliente. La semántica te dice cuál fila califica como uno. Esos son trabajos distintos, y el glosario solo hace el primero.

Nombrar bien tus entidades y relaciones vale la pena. Es apenas el comienzo del trabajo, no el final: el vocabulario estructurado, no el significado. El significado está en las condiciones: quién entra, quién queda afuera, cuándo cruzan la línea, y cuál línea estás trazando para cuál decisión. Eso es trabajo de modelado, no trabajo de redacción, y no cabe en una celda.

Queda un detalle de esa sala que tardé en digerir. El choque que recordaba el gerente de ventas había pasado antes de que las compras se apagaran. Su fecha no era la tercera opinión sobre un hecho pasado. Era la señal más temprana y más precisa de las tres, y la única que ninguno de mis dos modelos podía ver, porque estaba escrita en un sistema que no estábamos leyendo. Lo que me llevé de esa POC no fue el modelo de churn. Veníamos leyendo el CRM como fuente de actividad. También es un insumo de la condición de pertenencia.

¿Cuándo perdimos la cuenta? La respuesta honesta no es una fecha. Es otra pregunta: ¿perdida para qué?