Cómo ensamblar datos transaccionales

La semana pasada recibí una consulta de un analista de una empresa de telefonía celular que está llevando adelante un proyecto para predecir las líneas que deberían participar en una campaña de marketing.

Éste, como muchos proyectos, utiliza una base histórica transaccional que debe ser ensamblada en un formato apropiado para que cualquier herramienta de Data Mining pueda trabajar con ella. La consulta fue acerca de cómo ensamblar los datos.

Es muy difícil dar una respuesta simple y completa, ya que depende de cada caso en particular, pero existen varias sugerencias que podrían ayudar:

1. Definir cuál será el objeto de estudio

Es imprescindible que tengamos en claro cuál será el objeto a focalizar. Por ejemplo, supongamos que estamos analizando datos provenientes de una línea de POS (Point Of Sale) de supermercados. ¿Qué deseamos analizar? ¿Productos? ¿Tickets? ¿Clientes?

La tabla final deberá contener una fila por cada objeto. Por ejemplo, si el objeto es el cliente entonces cada fila se referirá a un cliente y no existirán dos filas que se refieran al mismo cliente.

2. Definir la variable a predecir

Tener claro el objeto de estudio no implica que se conozca la variable a predecir (OP). De hecho, en algunos casos, definir la OP es un tema crucial para el éxito del proyecto. Por ejemplo, si el proyecto es acerca de clientes (el objeto de estudio es el cliente) y se desea obtener un modelo de score para predecir la probabilidad de cesación de pagos, primero habrá que definir qué significa cesación de pagos. ¿Un cliente que no paga sus cuotas por un período de 2 meses debe considerarse moroso? ¿O deben pasar 3 meses?

En el caso de predecir riesgo de fuga de clientes (attrition) es similar. ¿Cuántos meses de inactividad debo tomar para considerar que perdí el cliente? ¿Qué significa inactividad?

3. Fijar tiempo histórico, presente y futuro

Cuando se trabaja con datos transaccionales existe una línea de tiempo que hay que considerar. Cuando se arma un modelo, uno conoce el pasado, el presente y el futuro. Cuando el modelo se pone en producción, sólo se conocerá el pasado y el presente.

Definimos el tiempo presente como cualquier punto en la línea de tiempo, aunque dependiendo de dónde lo ubicamos, existirá o no el tiempo pasado o futuro.

El tiempo pasado es el período que está antes (temporalmente) que el presente. Normalmente un modelo tiene en cuenta sólo unos meses de tiempo pasado. Por ejemplo, se podría definir como tiempo pasado los 12 meses anteriores al tiempo presente.

En muchos casos es útil definir varios presentes (y por lo tanto, varios tiempos pasados). Un ejemplo aclarará este tema.

Supongamos que deseamos armar un modelo de riesgo crediticio y la base de datos contiene información acerca de cada transacción que realizó cada cliente durante los últimos 24 meses. El siguiente gráfico representa algunos clientes durante estos 24 meses de historia. Como asumimos que la base de datos histórica es nueva (recién armada), ponemos la marca HOY a las transacciones más recientes, y por supuesto no tenemos datos del futuro.

Las flechas azules indican clientes que nunca entraron en mora. Las rojas indican clientes morosos. Existirán clientes que comenzaron su crédito hace 24 meses y aún continúan sin ser morosos (flechas azules que van desde el comienzo hasta HOY). Otros clientes que tomaron sus créditos hace menos de 24 meses y aún continúan sin ser morosos (azules que no empiezan desde el comienzo pero llegan hasta HOY). Finalmente clientes que alguna vez se convirtieron en morosos. Empiezan en cualquier momento (como los azules), pero normalmente no llegan hasta HOY porque dejaron de pagar sus cuotas en la fecha a la que llega la flecha roja. O sea, la flecha roja indica el último mes en que el cliente pagó su cuota.

Para el caso de los clientes morosos el tiempo presente será el punto en que es declarado moroso, o sea donde llega la flecha roja. Como cada cliente moroso deja de pagar en cualquier momento dentro de los 24 meses de historia, entonces tendremos distintos tiempos presentes para estos clientes.

Con respecto a los clientes que nunca entraron en mora, si bien por simplicidad se podría tomar siempre los datos desde la última fecha (HOY), es conveniente que se tomen puntos al azar en toda la historia para obtener mayor representatividad.

La primera flecha roja no parece contener tiempo pasado suficiente, así que este cliente podría dejarse de lado.

Las flechas azules, representando clientes vigentes, tienen sus tiempos presentes tomados al azar.

4. Agregar variables acerca de atributos del objeto de estudio

Este tipo de variables se refieren a diferentes atributos que el objeto de estudio tenía en el tiempo histórico. En el caso de clientes se podrían tomar variables demográficas, ratios (por ejemplo, valor de la cuota con respecto al sueldo), etc.. En caso de productos las variables podrían ser diferentes características, clase de producto, precios relativos, etc.

5. Agregar variables de comportamiento

Estas variables deben ser calculadas para el tiempo pasado. Normalmente se usan promedios, tendencias, variabilidad, máximos, mínimos, etc. Muchas veces es conveniente calcular distintas variables considerando diferentes períodos. Por ejemplo, si el tiempo histórico es de 12 meses, se podrían generar variables promedio de 3, 6 y 12 meses.

Finalmente, existen dos puntos importantes a considerar:

1. Verificar que la variable OP (la variable dependiente) se refiera al tiempo futuro y no se solape con el pasado.
2. Verificar que las variables IP (variables independientes) no utilicen información que no estará disponible cuando el modelo se ponga en producción

La tabla final contendrá tantas filas como objetos de análisis existen y tantas columnas como variables del objeto. Ya que normalmente la cantidad de variables que contendrá la tabla es muy grande (normalmente más de 100), habrá que seleccionar aquellas con mayor información acerca de la OP antes de hacer el modelo.

En caso de usar Powerhouse, la selección de variables puede dar una pista importante si se violaron alguno de los dos puntos anteriores. ¿Cómo darse cuenta? Simple, si aparece una primera variable con enorme cantidad de información acerca de la OP (por ejemplo, un 70%) es probable que esta variable esté usando información que no estará disponible cuando el modelo esté en producción o que el período usado para calcular la OP se solape con el pasado.