El histórico de datos: aprender de nuestros errores

Con este post queremos dar un paso más hacia la web inteligente. Parece ser que esto va a necesitar, inexorablemente, la colaboración de diversos perfiles: matemático-estadísitico, marketing, sistemas, etc.

Desde Metriplica siempre hemos insistido en una sencilla frase: menos intuición y más ciencia. Estas cinco palabras envuelven una metodología de trabajo en la que se enmarca la medición y el testing. Pero ahora hay que añadir un inquilino más que ya habíamos presentado: el data mining. Hemos pasado de cinco a dos palabras, y la metodología envuelta por éstas es todavía más densa y, quizás, un tanto abstracta. Uno de los actores principales en la minería de datos es el que más cuesta obtener: el histórico de datos. Vamos a hurgar en su uso y en su creación.

Tabla

El data mining

El data mining es una tarea de aprendizaje contínuo. Se trata, a grosso modo, de una estrategia de prueba y error (pruebo cambios y luego evalúo resultados), con la única diferencia es que la siguiente prueba tiene una base matemático-estadística irrefutable. Pero para poder aplicar técnicas o algoritmos matemáticos, necesitamos un input: algo a lo que aplicar el algoritmo, un conjunto de datos de prueba sobre los cuales ya conocemos la respuesta.

El histórico de datos (o conjunto de control) es una colección de datos reales (en nuesto caso, la actividad web quizás cruzada con datos del off-line, o del CRM) sobre los que ya tenemos cierta información que más adelante necesitaremos inferir sobre datos frescos (conjunto de test o de prueba). Lo más habitual en entornos web, es disponer de datos y una confirmación de conversión o de no conversión relativa a ellos.

Un ejemplo, por favor

Hace algunos posts hablamos de los tests multivariantes inteligentes. Durante la fase de testeo se va acumulando información sobre las variaciones mostradas, datos técnicos y sociodemográficos sobre los visitantes, y si los usuarios convirtieron o no. Esto es un ejemplo de histórico de datos: allí hay “errores” (combinaciones que dan pocas conversiones) que los algoritmos deben detectar y descartar para futuras pruebas o reglas de negocio. Esto, ni más ni menos, es aprender de nuestros errores.

¿Cómo lo obtengo?

Ya hemos visto cómo usar el histórico. Ahora toca resolver otro detalle: cómo crearlo. En un principio no sabemos qué parámetros son los más influyentes, así que no nos queda otra que recoger todo lo que se nos ocurra. Evidentemente este proceso se irá refinando a medida que vayamos ganando experiencia. No hace falta que diga que cuántos más datos queramos recoger, más problemas tendremos para su recogida, almacenamiento, procesamiento, etc.  ¿Cómo recogo todo lo que se me ocurre? Lo primero es hablar con el departamento de sistemas, ya que lo primero que tenemos que averiguar es si se puede (los datos sociodemográficos no se pueden recoger de los software de analítica web, se tendrán que recoger de encuestas, fichas de registro, etc.), cómo se recogerán (PHP, .Net, Google Analytics, etc.), en qué formato los vamos a guardar (tabla MySQL, Excel, CSV, etc.) y dónde los vamos a alojar (en local, en remoto, cloud computing, etc.).

Esto no es malo. Ni mucho menos

Una situación habitual en el mundo del data mining es la siguiente. Después de recoger decenas de parámetros, después de diseñar metodologías de recogida y almacenamiento, resulta que el modelo matemático de reglas de negocio (por ejemplo, un árbol de decisión o una red neuronal) sólo tiene en cuenta dos o tres de dichos parámetros. ¿El modelo es incorrecto? No, el modelo es sencillo. ¿Hubiese podido recoger menos información? No, a priori no podemos saber qué parámetros son los más influyentes a la hora de construir un modelo. Por otra parte, es muy habitual tener un modelo que hoy utilice dos parámetros y que pasado un tiempo utilice muchos más. Con esto quiero decir que el histórico tiene que ser grande, tiene que tener mucha información. Por supuesto, después de construir un modelo, nunca hay que borrar datos históricos.

¿Y ahora qué?

Prometo, para próximos posts, comenzar a hablaros de técnicas más concretas de minería de datos. Palabra de doctor.

Autor:

Fundador de Metriplica y socio de la consultora Multiplica Licenciado en Ciencias y técnicas estadísticas. Programador Mainframe Profesor de Masters y Postgrados en diversas universidades y escuelas de negocio.

4 Comments

  1. No estoy seguro, pero me parece que no se menciona un tema importante, y es que la minería de datos si bien tengo entendido nace con la finalidad de obtener conocimiento de una gran, gran, gran cantidad de datos, en donde la metodología estadística es imposible de aplicar.

    De otro modo la aplicación de la metodología estadística resulta más eficiente.

    Y siempre, como mencionas, en ambos casos, los datos deben pasar por un proceso de preparación.

    Muy buen aporte al mencionar a esta herramienta en el análisis web, la cantidad considerable de data que hay en la web, la hará imprescindible para recoger conocimiento par la toma de decisión. Sólo hay que saber manejarlo.

  2. admin

    Hola Miguel. Lo del gran volumen de datos no es un requisito, es un hecho, y diversas técnicas se pueden aplicar sobre ellos, incluyendo las estadísticas: regresión, árboles de decisión, etc. Existen algoritmos rapidísimos que resuelven el problema de la recta de regresión, regresión de Poisson, y otras. Hoy en día, el gran volumen de datos no respresenta ningún problema a nivel computacional. Lo que ocurre es que otros campos también aportan técnicas para resolver el problema: redes neuronales, reconocimiento de patrones, etc.
    Un saludo!

  3. Gracias por la aclaración, aunque no entendí muy bien que el gran volumen de datos es un hecho, o sea, te refieres a que el gran volumen de datos se da en todas las situaciones en el análisis de datos de la web?

    Y sólo para aclarar cuando me refería a la metodología estadística (no técnica), me refería más a que generalmente partimos de una hipótesis a demostrar y se sigue el proceso – método… En este caso me parece que no es así. Tenemos muchos datos, muchas variables e intuimos que ahí debe haber algo, pero no sabemos bien qué jajaja. Y luego, usando también algunas técnicas estadísticas propiamente dichas y otras no estadísticas (más relacionadas al campo computacional) llegamos a algún conocimiento que antes era desconocido.

    Y sí, no se trata sólo de la cantidad de información, sino de la complejidad de los datos, que hace también que la estadística se intersecte con los algoritmos computacionales para rescatar conocimiento de los datos.

    Muchas gracias nuevamente, y bueno, aquí tienes a un seguidor, un abrazo.

  4. admin

    Hola Miguel. La actividad en un site de, digamos 100.000 visitas al mes, genera mucha cantidad de información. Y todavía más si la cruzamos (y así debemos hacer) con otras fuentes de datos (encuestas, CRM, etc.). ¡Nos encontramos con un histórico de varios centenares de miles de líneas!
    Estoy completamente de acuerdo contigo en que necesitamos una cierta “intuición” antes de ejecutar un algoritmo u otro ante tal magnitud de datos, pero esto es algo que pasa en la mayoría de situaciones, incluso con históricos mucho más pequeños. La principal razón para ello radica en la interpretación de los outputs: en un histórico pequeño podemos aplicar muchos algoritmos y obtener outputs variopintos; si no tenemos una intuición sobre lo esperado nos encontraremos en una encrucijada que no sabremos resolver: ¿qué output es el “correcto”?
    Un saludo y gracias por leernos!

Leave Comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.