Los sistemas en la empresa (y en la vida real)

El libro está repleto de ejemplos muy clarificadores.  En realidad son el eje vertebrador de los capítulos.  Aunque estos ejemplos están muy centrados en las organizaciones, también hay ejemplos de la vida cotidiana.  No en vano el autor incluye un apartado en el que habla de la conciliación de la vida profesional y la familiar, comentando la aplicación del análisis de sistemas a los niños.

Un ejemplo que el autor expone al principio del libro para entender la perspectiva sistémica es el de una cadena de venta y distribución de bebidas.  En una práctica que realiza en sus sesiones de formación, el autor asigna distintos roles a varios participantes: uno actúa como fabricante, otro como distribuidor y otro como vendedor.  Las peticiones de bebida y las entregas al siguiente nivel se separan por "turnos".

El proceso demuestra comprobar cómo afectan a la cadena de distribución los cambios abruptos de demanda en la tienda.  En general su experiencia indica que la demanda de bebidas excede las cantidades necesarias, el almacén de la tienda queda saturado y todos salen perdiendo.  Todo ello debido a que ante un aumento inesperado de la demanda, incrementa la cantidad solicitada de bebida al proveedor.

El resto es cuestión de inercia del sistema: el sistema empresarial es mucho más complejo e ineficiente de lo que las teorías clásicas de gestión empresarial plantean. Es por eso que Senge propone un cambio de visión hacia el pensamiento sistémico.

Algunos de los motivos por los que el autor recomienda el pensamiento sistémico son:

• La estructura del propio sistema influye sobre la conducta.
• La estructura de los sistemas humanos es sutil.
• El equilibrio del sistema (que denomina punto de apalancamiento) se descubre aplicando nuevas formas de pensar.

Las leyes del pensamiento sistémico

Tras estos motivos, el autor enumera una serie de leyes del pensamiento sistémico:

• Los problemas de hoy derivan de las soluciones de ayer.
• Cuanto más se presiona, más presiona el sistema: forzar la situación tiene un efecto rebote.
• La conducta mejora antes de empeorar: como las bombillas que, antes de fundirse, lucen más intensamente.
• El camino fácil nos lleva al mismo lugar.
• La cura puede ser peor que la enfermedad.
• Lo más rápido es lo más lento.
• En los sistemas, la causa y el efecto no están próximos en el espacio ni en el tiempo.
• Los pequeños cambios pueden dar mejores resultados, pero las zonas de mayor apalancamiento (puntos de equilibrio en el sistema) a menudo no son obvias.
• Se pueden obtener dos metas aparentemente contradictorias.
• Dividir un elefante por la mitad no genera dos elefantes.
• No hay culpa.
  

Esto es sólo el principio del libro, una introducción sobre lo que se desarrolla en el resto.  El autor expone con claridad cualquiera de las afirmaciones anteriores.  Por lo que apelo a la lectura ante cualquier escepticismo.  El resto del libro no decepciona.

Algo más que decir

Aunque el autor lo menciona en algunos pasajes, el análisis de sistemas y la simulación son metodologías muy relacionadas cuando se aborda un entorno desconocido.  De hecho la simulación es una herramienta poderosa si se basa en datos fiables y objetividad.

El autor no se cansa de insistir en que los cambios instintivos fruto de la adrenalina y la opción fácil no acostumbran a ser buenos consejeros.  Nuestra mente está acostumbrada a las reacciones instintivas, algo necesario para sobrevivir, pero ineficiente al contemplar la complejidad de un sistema (sea un empresa, o una familia).

Paso 1: Festival con voces en Español y codificador LAME

Hace tres o cuatro años que descubrí el programa Festival Speech Synthesis System, desarrollado por la Universidad de Edimburgo.  Este software diferencia sus licencias de uso en relación al propio código fuente y a las voces que contiene.  En esencia el software es totalmente libre (con una licencia de tipo BSD), pero en el caso de las voces existen restricciones.  Por ejemplo, las voces británicas están basadas en el Oxford Advanced Learners' Dictionary of Current English, por lo que su uso se restringe a aplicaciones no comerciales.  Algo similar sucede con la voz en castellano.

Buscando información sobre el tema, encontré dos proyectos de creación de voces para Festival en catalán y castellano:

• El primero, el desarrollo de voces en catalán por la UPC.  Hay diez voces diferentes (cinco masculinas y cinco femeninas), y además con dos estructuras diferentes: HTS (Cadenas de Markov Ocultas, HMM) y clunits (Cluster units).
• El segundo, el desarrollo de voces en castellano en un proyecto de la Junta de Andalucía.  En este caso los resultados se limitan a dos voces (una femenina y otra masculina), más que suficiente.

Para la realización de estas voces se ha utilizado el conjunto de herramientas Festvox, desarrolladas por el grupo de tecnologías de la pronunciación de la Universidad Carnegie Mellon y dirigida específicamente a la creación de voces para Festival.

En ambos sitios se puede encontrar información sobre el proceso de creación del corpus de sonidos, que es diferente en cada caso.  Cabe comentar brevemente las dos versiones presentadas en el proyecto de la UPC: HTS y Clunits.

HTS se basa en la aplicación de modelos derivados de las Cadenas Ocultas de Markov (Hidden Markov Models - HMM) a los sistemas de síntesis de voz, como se puede leer en el sitio HMM-based Speech Synthesis System (HTS).  Las cadenas de Markov (y por extensión las cadenas ocultas) son una herramienta de uso muy extendido, no sólo en síntesis o en reconocimiento de voz, sino también en procesamiento del lenguaje natural, o en el algoritmo del PageRank. No voy a entrar en detalles, trataré de dedicarle un artículo a este tema.

Para entender cómo funciona el modelo Clunits (Cluster Units Algoritmo de clusterización de unidades de sonido), hay un documento de Alan W. Black y Paul Taylor (1997) sobre la descripción del Algoritmo.

Después de escuchar varias versiones de ambos modelos, creo que el resultado más interesante está en el modelo Clunits, aunque las inflexiones de voz parecen más artificiales (no sabría decir si debido al modelo de creación del corpus).

El proceso de instalación y configuración de las voces en catalán puede leerse respectivamente en el sitio del equipo catalán de Ubuntu.  Para las voces en castellano, recomiendo la lectura del artículo Cómo instalar e integrar Festival en Asterisk, un caso de uso muy interesante. La cuestión clave es configurar festival para que utilice las voces correspondientes.

Respecto a la instalación de LAME Mp3, sólo cabe decir que en Debian no existe un paquete específico, debido a las restricciones de codificación del formato MP3.  En cualquier caso es posible descargarse el paquete y compilarlo sin problemas aparentes.

Paso 2: Script de recuperación y limpieza de los contenidos

Festival no está pensado como lector de páginas web en crudo, por lo que es necesario eliminar las etiquetas y las entidades HTML antes de realizar el proceso.  Puede ser necesario convertir el texto a codificación Latin-1 porque según la documentación del proyecto, es la codificación correcta. De todos modos es una cuestión que yo no he necesitado, desconozco si las mejoras en festival han incluído soporte para UTF8.

Antes de empezar hay que tener en cuenta un detalle importante: al eliminar las etiquetas HTML, todo el texto se desestructura.  Es decir, que un título no tiene una énfasis especial, ni siquiera se reconoce como frase (porque no es costumbre poner puntos al final del título).  Tampoco he entrado a fondo en las posibilidades de Festival para personalizar el énfasis en ciertos términos o frases.

Así que el resultado final puede ser mejorado si existen opciones en Festival que yo no estoy utilizando y quizá remarquen puntos clave (por ejemplo, en el caso de texto en negrita).  Además, en el proceso de conversión a texto normal, la entidad HTML "nbsp" se convierte en un "espacio raro", algo que Festival no tolera demasiado bien (de hecho parece que trague saliva).  También los puntos seguidos deben contener un solo espacio en blanco posterior, y ninguno entre éste y la última palabra de la frase.

Resumiendo el proceso, los pasos a realizar antes de eliminar las etiquetas HTML son:

• Introducir saltos de línea antes de las etiquetas de títulos (H1..H5)
• Introducir puntos al cierre de las etiquetas de títulos (H1..H5)
• Introducir saltos de línea antes y después de los tags de párrafo (P)
• Eliminar la entidad "nbsp".
• Introducir un espacio posterior a los puntos seguidos(.), y eliminar el doble espacio posterior (".").
• Mantener unidos los puntos suspensivos (excepción al caso anterior).
• Cambiar los paréntesis de apertura y cierre por comas.
  

Una vez realizados estos cambios, hay que eliminar las etiquetas HTML (en PHP, strip_tags ), y luego eliminar las entidades HTML (en PHP, html_entity_decode ). En caso que sea necesario, también hay que recodificar el texto (en PHP, mb_convert_encoding ).

Después de esto, el proceso ya llega a su fin: Hay que volcar el contenido generado a un archivo de texto, y ejecutar las dos llamadas para convertir de texto a WAV y luego a MP3 (primero text2wave, luego lame).

Paso 3: Definición de los scripts de Ejecución text2wave y lame

En Festival existe la utilidad text2wave, que puede ejecutarse (después de indicarse el cambio de voz en la configuración) con la siguiente llamada:

# text2wave archivo_texto -o archivo_wav

Con esto se recogerán el texto de archivo_texto, lo convertirá en sonido y lo volcará en formato WAV en archivo_wav.

Una vez conseguido el archivo de sonido, es necesario convertirlo a formato MP3.  Para ello se puede ejecutar el siguiente comando:

# lame -h -m m -b 92 --resample 22.05 --scale .61 --replaygain-accurate --clipdetect archivo_wav archivo_mp3

Con esta instrucción se genera el sonido , con las siguientes características:

• Codificación con calidad alta (-h). Evita algunos clicks/pops en la conversión a MP3.
• Sonido de un canal (-m m = modo Mono).
• Calidad de 92 kbps (-b 92): esta calidad es más que suficiente para la voz.
• frecuencia de muestreo de 22050 Hertzios (--resample 22.05). Festival varía el ratio de muestreo según la calidad de la voz, por lo que esta opción normaliza el resultado.  Se podría indicar 44100 hertzios (44.1) para aplicar el mismo ratio de muestreo que un CD a costa de aumentar el tamaño del archivo.
• escalado del valor al 61% respecto a la señal recibida del archivo WAV (--scale .61). En esencia reduce el volumen, pero lo que trata de evitar esta opción es el "cliqueo" (clipping) que se produce si el volumen es alto.
• Identificar los picos de sonido para evitar el clipping (--replaygain-accurate).
• Avisar si existe clipping (--clipdetect)
  

Las últimas tres opciones se incluyen para conseguir un resultado más agradable a los oídos y para recibir información sobre el resultado final. Esto es debido a que, al menos en el caso de las voces en castellano, el volumen original genera muchos clicks, probablemente debido a la concatenación de los sonidos que representan cada fonema/difonema. Dado que el tono y volumen de la voz están normalizados (y no sufren alteraciones en cada locución), se pueden establecer estos parámetros como fijos, algo que no podríamos hacer en caso de una locución humana real.

Paso 4: Disponibilidad de la audición en la interfaz web

Para el último paso me he valido del programa Flash MP3 Player , que permite incrustar un reproductor MP3 personalizable en una página web.  El proceso en relación a lo anterior es bastante sencillo: incluir un código HTML en la página que incruste el archivo SWF del reproductor, incluyendo como parámetro la URL.

En la propia página existe un generador de código para el reproductor, para cada uno de los reproductores.  El código permite la personalización de colores.

Con esto ya está incrustado el reproductor en la página, que referencia al archivo MP3 que previamente hemos generado y que permite escucharlo sin más problemas.

Conclusiones, otros recursos y cuestiones de accesibilidad

El resultado final tiene unas cuantas ineficiencias manifiestas (pero tampoco tan críticas: se nota que ambos proyectos de creación de voz han hecho un esfuerzo notable).  Por un lado, la pronunciación de siglas y direcciones web no siempre se acerca a unos resultados deseables.  Aunque en el caso de las voces de la Junta de Andalucía se ha trabajado en el análisis de tokens para procesar direcciones de correo y direcciones web (URL), el resultado final es mejorable.

Otro tanto sucede al escribir fragmentos de texto en otros idiomas, o instrucciones de código fuente.  La solución a este tema pasa por utilizar tags de HTML concretos (por ejemplo en el caso del código fuente, utilizar el tag "code").  Antes de procesar el contenido, estos tags pueden ser tratados como textos separados (para utilizar voces en el idioma original) o bien eliminados, y luego concatenar los pequeños archivos de voz generados.  De todos modos, esta mejora va mucho más allá de mis objetivos por ahora.  Por no decir que el resultado es a veces tan divertido que vale la pena escucharlo para echarse unas risas .

El reproductor MP3 de Flash no soluciona una cuestión importante: la accesibilidad.  Por eso considero oportuno añadir un enlace directo al archivo MP3.  De este modo se ofrece una opción de disponibilidad del contenido para personas con discapacidades visuales que no tengan screenreaders en el ordenador de consulta y que tampoco tendrían asegurado el uso del reproductor de Flash.  También descarto la inclusión del reproductor en el contenido de los feeds porque es una funcionalidad susceptible de dar problemas en algunos programas lectores de feeds.

Otras aplicaciones de un servicio como éste serían convertir a voz los artículos recogidos de otras fuentes de información.  Es decir, capturar nuestros feeds habituales y convertirlos a voz sintetizada para luego escucharlos como cualquier otro podcast.  Este caso presenta un pequeño añadido en complejidad, ya que debemos controlar el idioma de la fuente y también el marcado HTML. Lo primero es fácil, pero lo segundo puede complicarse.

Como ejemplo de este caso encontré este enlace en PHPied: conversión de feeds a podcast con ffmpeg, otra opción interesante. El uso de ffmpeg o de lame es una cuestión opcional, ya que ffmpeg requiere de un codec (que puede ser perfectamente el proporcionado por LAME). En su caso utiliza un sintetizador de Mac. Vale decir que si la fuente original está en inglés, las cosas se simplifican mucho por la disponibilidad general de sintetizadores en este idioma.

La introducción del enlace al archivo MP3 en el RSS del blog difiere conscientemente de las especificaciones de iTunes y Yahoo! Media RSS Module. Este archivo no es un podcast por sí mismo, sino una versión sintetizada, y por lo tanto no es una alternativa sino una herramienta de soporte al texto.  Con esto quiero aclarar algo: si quieres entenderlo todo, mejor acaba leyendo el artículo original.

Movimiento de los ojos, movimiento de las ondas

El uso de eyetracking para el diseño de productos es el área que más me interesa personalmente.  En especial el análisis en aplicaciones web (tanto dirigidas al público general como a personal corporativo).  Otras áreas de aplicación en psicología quedan lejos de mi conocimiento (que no interés). Hace no mucho, por ejemplo, aparecía un estudio sobre el search marketing aplicado al turismo y el triángulo de oro de Google .

También se ha tratado la opción de superponer esta información con otros datos generados durante la navegación , como logs de servidor, focus groups, etc.  Lo que sucede es que este tipo de datos ya son externos al usuario. Si el ojo es una fuente secundaria, éstas ya se pueden considerar fuentes terciarias: fruto de la decisión que ha pasado por los filtros del ojo y el cerebro (e incluso la coordinación de movimientos).  Todo esto dando por hecho que están los filtros de valores, cultura, circunstancias en el momento de realizar la acción...

La posibilidad de profundizar en la información de la actividad neuronal del usuario es un paso más en la investigación de la caja negra que supone el cerebro.  Hace años que voy picoteando información sobre este tema, pero (lo acepto) sin poder entrar a fondo. Los precios o la disponibilidad de los dispositivos en relación a la poca prioridad que le doy al tema es el principal obstáculo.

El hecho de acceder a las ondas cerebrales nos aporta una información mucho más cercana a lo que sucede en nuestra mente.  Si no es una fuente primaria, poco le falta.  No está del todo claro qué ondas cerebrales son las más significativas en procesos como el impacto de un banner o la relevancia de un documento, aunque si hablamos de atención estádo anómalo del conocimiento o relevancia , la respuesta puede estar entre las ondas alfa y beta.

La posibilidad de coordinar los datos sobre los movimientos y la actividad cerebral es un doble filtro muy interesante: ni siempre miramos lo que vemos, ni siempre pensamos en lo que estamos mirando.  Establecer correlaciones entre ojos y mente parece una vía interesante para adentrarse en la atención.

Herramientas para la captura del EEG y los movimientos faciales

Entre las búsquedas que realicé antaño me topé con OpenEEG , un proyecto actualmente algo obsoleto que proporciona instrucciones concretas para el desarrollo de software y la producción de hardware (todo con permisos Open Source y Open Hardware) para la creación de estos dispositivos.  La razón por la que hablo de obsolescencia es que los dispositivos presentados van conectados principalmente por el antigo puerto de serie (el mítico COM1), por lo que la velocidad de transmisión de datos y el número potencial de canales de información es más bien escaso.  La actualización para integrar dispositivos USB está mencionada, pero no he sabido encontrar resultados concretos al respecto. En cualquier caso, la capacidad para ensamblar un aparato de estos queda bastante limitada a alguien con conocimientos de eletrónica (o alguien con amigos para este conocimiento que tenga ganas de perder parte de su tiempo libre).

En cualquier caso, el proyecto OpenEEG dispone de una lista bastante interesante de software (libre y propietario) para recoger la información, así como una especificación (modularEEG) para facilitar la comunicación entre hardware y software.

Sobre este último aspecto, creo que en la situación actual, la evolución puede enfocarse hacia un modelo más amplio: algo que pueda aplicarse a la captura de información por el movimiento de todo el cuerpo, donde las ondas cerebrales sean una parte, los movimientos conscientes otro, y los movimientos no conscientes (incluyendo respiración, pulso y sudoración) sea otro.  Y luego, dependiendo del dispositivo, se pueda procesar esta información de acuerdo con la parte que se analiza.

Emotiv EPOC

Después de OpenEEG, mi búsqueda se dirigió hacia otro lado: máquinas ya ensambladas que realicen este proceso de recogida de datos, recopilando la información pertinente (varios canales / electrodos que recojan la actividad en varias zonas del cerebro), y dejando la tarea pendiente de procesar esta información. Es decir, máquinas que vuelcan los datos recogidos en crudo, tras lo cual hay un programa que escuche el puerto USB y los procese.  Algo difícil, si además se añade un interés para que todo esto funcione con independencia del sistema operativo...

Para que exista una máquina de este tipo tiene que haber mercado.  En este caso, mercado a consumidores finales, ya que los precios de las máquinas dedicadas a la medicina o cualquier otra actividad en empresas encarece sobremanera el producto (en el primer caso, por los estándares de calidad, y en el segundo, supongo que por los pocos usos que tiene aún).  Desde luego, el sector más proclive a llevar esto a la práctica es el del ocio, y en concreto el del gaming.

Es por eso que al leer sobre el proyecto EPOC de la empresa Emotiv pareció que las cosas se acercaban, que ya faltaba menos.  Este proyecto parecía tener todos los componentes necesarios para ser el nuevo cacharrito de experimentos.  Incluso incluye un conjunto de herramientas de desarrollo de aplicaciones (Software Development Kit - SDK) con dos versiones: SDK estándar y SDK Lite. La diferencia es que en la primera se adquiere un casco, mientras que la segunda dispone de un emulador del casco vía software para el desarrollo de aplicaciones.

El SDK parece proporcionar informaciones (no datos) bastante concretos sobre las emociones o movimientos faciales de la persona. Una aplicación desarrollada con este SDK se podría centrar en el tratamiento de estos estados mentales y no en los datos, porque el SDK ya incorpora los algoritmos de identificación de las señales cerebrales.  No queda claro hasta qué punto es necesario el aprendizaje, un tema que quizá en el futuro cada vez sea menos importante , aunque hoy en día lo es.

Sin embargo, el proyecto sigue estando en fase beta, y además su distribución parece limitada a Estados Unidos (eso indican en el sitio).  Parece ser que la razón de esta beta es la mejora en la interpretación de los datos, imagino que tratando de mejorar el SDK.  Si el precio permite diferenciar la compra por motivos de "curiosidad" o de "ir en serio", creo que actualmente el de este aparato (299 dólares) cae en la segunda opción.

OCZ NIA: Neural Impulse Actuator

Hace poco apareció en Microsiervos una entrada comentando NIA, el que parece ser otro candidato.  El aparatejo en sí es muy simple: el número de sensores se reduce a tres, se recogen los datos de ondas cerebrales y movimientos oculares (no queda del todo claro si parpadeos y movimientos de cejas, o bien llega a desvelar la dirección de los ojos), y tiene un precio bastante asequible: aproximadamente 160 Euros.

Sobre la ubicación de los sensores vale la pena hacer un comentario.  Al ubicarse sólo en el área de la corteza prefrontal, se captura principalmente la actividad derivada de jucio, voluntad y toma de decisiones (Zonas 9, 10 y 11 según las zonas de Brodmann ), y en mucho menor grado en la articulación y comprensión del lenguaje (Zonas 44 a 46 de Brodmann).  Esto quiere decir que todo el resto se descarta: ni emociones, ni actividad de la memoria... el NIA es una suerte de mouse mental, no un procesador completo de señales cerebrales.

Lo que hace es recoger las señales de las ondas cerebrales (recopila y amplifica la señal), y los vuelca en bruto (a modo de stream) a través de un puerto USB.  Prácticamente no hay limpieza de datos antes de su entrada por USB, por lo que el resto es cosa del software proporcionado con el aparato, o bien de cualquier otro software que reciba los datos.

Las opiniones sobre la calidad de la señal que emite el aparato son variadas.  Por el precio y los componentes no se puede esperar una máquina de alta precisión: no es un mouse ni un teclado, es algo bastante más complejo. No será de alta precisión, pero sí imagino que suficiente. Lo que sí indican en el sitio (en realidad es una obviedad) es el riesgo de interferencias en la señal por tener aparatos eléctricos cerca como cargadores, auriculares o móviles.

Buscando en YouTube he encontrado varias referencias al producto.  En general, buscando NIA OCZ hay muestras para todos los gustos, desde reportajes hasta muestras hechas por los propios usuarios.  Dado que mi afición por los videojuegos es prácticamente nula, no sé valorar si el resultado promete.

Sobre la posibilidad de trabajar con Linux, he encontrado el proyecto NIA4Linux , donde se está desarrollando el driver que recoge los datos en bruto.  El análisis previo parece que está en curso (en base al comentario sobre la estructura de los datos que explican en el foro del proyecto ).

Antes de tener algo mínimamente operativo a este nivel, hay una cuestión principal: poder separar la mezcla de señales. Los tres electrodos están transmitiendo (cada uno) señales cerebrales y/o musculares, todo en un mismo paquete de datos. Parece ser que los electrodos laterales aportan información de cada lado (una señal invertida, provocando una especie de efecto estéreo) y un electrodo central que se utiliza como referencia.  Con estos datos, queda por saber qué parte se refiere a actividad cerebral y qué otra se refiere al movimiento ocular.

La identificación de los datos puede ser compleja aunque con el tiempo es posible que se encuentren resultados.  Desde luego trabajando en Windows con el aparato parece más sencillo a priori, ya que con el software proporcionado se puede ver de forma casi instantánea el funcionamiento del aparato. Si el uso va más allá de los juegos, es posible crear un perfil de movimientos de acuerdo con las señales.

Sobre la posibilidad de recoger la información directamente, parece que el principal problema es el de siempre: el problema de acceso a las especificaciones , ya que según explica un moderador del foro de productos de OCZ, es un producto con licencia de terceros, aunque se apuntan los puntos clave para conseguirlo.

Conclusiones y aplicaciones

La época en la que estos aparatitos se puedan aplicar de forma más intensiva parece estar llegando.  Para una aproximación al tema, el OCZ NIA parece un muy buen candidato, mientras que para análisis más profundo el Emotiv EPOC parece el indicado.  Para su uso en entornos Windows su aplicación es casi inmediata, utilizando los drivers que proporcionen sus respectivos fabricantes.  En el caso de Linux, la situación es de stand by, aunque OCZ NIA, por su sencillez y disponibilidad fuera de Estados Unidos actualmente, parece el más indicado a corto plazo.

Respecto a sus aplicaciones (dejando a un lado las que ya existen: juegos, mundos virtuales y demás), me parecen incontables.  Es un nuevo canal de interacción y por ello es potencialmente aplicable a todo lo que se nos ocurra.  La evolución de las interficies va relacionada con la limitación en la capacidad de proceso de los inputs que tienen los ordenadores.  Hace unas pocas décadas el ratón era una entelequia, igual que lo fueron en su momento la interpretación de comandos o el uso de menúes en aplicaciones.  Utilizar este nuevo modo de comunicación es cuestión de tiempo, y también de saber su verdadera utilidad.

Retomando el hilo con el que iniciaba el artículo, una de las posibles aplicaciones que veo en estas herramientas es su aplicación en estudios de producto.  Como herramientas de combinación de los datos oculares y cerebrales parecen muy interesante. Combinar este aparato con una aplicación que envíe el stream a un servidor central, y que combinara el vídeo y voz puede tener un potencial interesante para procesos de beta-testing.

Otra aplicación muy interesante es el e-Learning.  Una interfaz de este tipo puede ayudar en los procesos de evaluación de competencias sin basarse en los contenidos de evaluación.  No se trata de grabar todo el proceso, sino saber el grado de seguridad con el que se desenvuelve un alumno en una tarea, midiendo su nivel de estrés y sus errores, para determinar qué partes son las más complejas.  El uso de agentes inteligentes en ese proceso es un paso más.

Otra aplicación relacionada es una mezcla entre coaching y productividad: capturar la información sobre las tareas diarias delante del ordenador para luego determinar qué distrae, qué mejora el resultado, y cómo tratar las distracciones.

Finalmente, hay otras cuestiones (ahora lejanas) relativas a la convergencia del hardware de interacción.  En los últimos años estamos presenciando la aparición de dispositivos y entornos de trabajo que tratan de mejorar la experiencia de usuario armonizando la interacción y los movimientos naturales del cuerpo.  Entre ellos podemos encontrar escritorios en tres dimensiones, entornos multitouch, sin olvidar iPhones i Wiis.

Lo que me parece factible a medio-largo plazo es que un sistema de comunicación con el cerebro sea el principal impulsor de un sistema unificado de interacción.  Aunque los esfuerzos en investigación deberán ser notables, hay dos factores determinantes en la comercialización de estos dispositivos: el coste y los públicos objetivos.  Es mucho más fácil distribuir un aparato como los anteriores que un par proyector-pizarra.

Además, el software asociado al casco es más fácilmente actualizable que cambiar todo el hardware, por lo que el lanzamiento comercial y el ciclo del producto pueden ser más asumibles para el retorno de la inversión.

Para el potencial comprador, el casco no tiene coste de adecuación del entorno (aparte del aprendizaje del sistema), y puede esperar una vida media de producto más larga, sin grandes costes de mantenimiento debido a consumibles, y con mejoras a medio-largo plazo (con actualizaciones de software).

Del principito a la campana de Gauss

En la historia, la diferencia de visiones sobre el mismo dibujo es una muestra de la distancia entre los que se han acostumbrado a ver la realidad de un modo, y los que la perciben de un modo diferente, planteando que quizá lo esencial sea invisible.

Eso es lo que sucede cuando se trata de tratar con variables aleatorias.  Todo el mundo puede entender lo que es una campana de Gauss porque la ve. Sin embargo, a menudo cuesta entender que nunca nos encontraremos cara a cara con una muestra de datos reales que sean idénticos a esta campana.  Argumentar que necesitaríamos un número infinito de datos empeora el tema.

Porque, claro, relacionar la campana de Gauss con probabilidades, tiene su intríngulis.  Hay que entender cómo la serpiente se ha podido tragar al elefante.

Las bases de la estadística probabilística surgieron en los salones de juego de cartas.  Comprender que se repetían ciertos patrones y frecuencias inspiró a matemáticos como Pascal a analizar matemáticamente lo que sucedía en esas situaciones.

Así, lo que acaba convertido en fórmulas (la serpiente) fue fruto de numerosos análisis matemáticos sobre datos reales, o cuanto menos, supuestos plausibles (los elefantes).  En matemáticas es posible que una serpiente (una fórmula matemática) pueda tragarse un elefante (cada uno de los infinitos casos reales). Aunque tenga un cierto sabor Freudiano, las serpientes estadísticas se crean para poder tragar elefantes.

Del punto a la línea

Ahora imagínate que lo estás moviendo creando una forma concreta (un círculo, una elipse, un ocho...).  Lo mueves cada vez más rápido, más rápido...  A medida que aumentas la velocidad, tu ojo deja de ver el punto en movimiento. Si consigues moverlo muy rápido, verás una línea continua, una figura.

Graba esa forma en tu mente.  Si fueras capaz de mover tan rápido el puntero como para situarlo al azar en algún lugar concreto de esa línea continua, tienes algo muy parecido a una variable aleatoria.

De algún modo, las variables aleatorias son eso: puntos que se mueven de un modo que les es característico, pero cuya ubicación individual no es totalmente predecible: sólo probable.

Bajando a la realidad

La realidad quizá no sea tan dura si nos la tomamos a sorbos.  Nuestros sentidos están acostumbrados a recoger sólo una parte de la información que fluye en el ambiente, y nuestro cerebro es capaz de resaltarnos lo importante.  Su funcionamiento no es perfecto, pero tiene un objetivo claro: tomar decisiones para mantenernos vivos.

Esa imperfección es suficiente para decidir. Y de eso mismo trata la estadística. Ni necesitamos ni somos capaces de absorber toda la información: podemos decidir con menos. La cuestión es saber cuánta información necesitamos para que acertar sea muy probable.

En nuestro día a día, la /figura/ nunca aparece completa. Lo único que nos encontramos son puntos que no sabemos en qué figura encajan. La labor estadística es encontrar la forma donde mejor encajan esos puntos.

Lo habitual es que con un solo punto no sea suficiente.  Hay que seleccionar unos cuantos para tener una idea de la figura más parecida.  Es un ejercicio parecido al de "unir los puntos", pero en versión matemática.

El proceso que nos conduce del punto a la figura pasa por dos fases principales:

• Seleccionar la mínima cantidad de puntos que nos den la máxima información posible.  Este proceso es el denominado muestreo estadístico.
• Comparar la serie de puntos con las diferentes figuras (las distribuciones estadísticas). A este proceso se le llama contraste de hipótesis .

La razón para recorrer este camino es que al identificar la forma, podemos trabajar sobre una base (teórica) más sólida y tomar decisiones con más criterio.

Por retornar al símil con la historia del principito: Si sabemos la forma que tiene el elefante, seremos capaces de saber si estamos tocando la cola, la trompa o una pata, y ya no andaremos tan a ciegas.

Película, cámara, luz, plano, encuadre...

• El entorno que es objeto de nuestro análisis: No es para nada homogéneo y además puede variar con el tiempo. Para complicarlo más, convive con elementos que pueden distorsionar nuestra percepción.
• Las herramientas que utilizamos para capturar los datos de ese entorno: Considerando un grado asumible de imperfección, tienen unas características que conocemos y podemos utilizar en nuestro favor.
• El sujeto que quiere capturar los datos con un objetivo concreto: No la quiere por sí misma, sino para extraer algo: una visión sintetizada de ese entorno y sus implicaciones.

En el caso de las herramientas, huelga decir que la calidad de la cámara afecta al resultado de forma determinante.  Dependiendo de las exigencias, la calidad es un punto importante. El sistema óptico es clave, así como la velocidad del obturador y el angular.  También lo es la película utilizada: su granularidad y la sensibilidad, junto al enfoque, definen la precisión de los detalles.

Y finalmente nos queda el sujeto, que imprime su carácter al acto de fotografiar y al resultado.  A nivel estadístico, la visión artística queda a un lado para dejar paso a métodos de muestreo.  Lo que sucede a menudo es que hay muchas opciones para decidir cómo se muestrea. En ese punto entra en juego la visión del sujeto, el objetivo del análisis y los medios con que cuenta.  Y lo más importante de todo es que, como en el arte, el equilibrio entre lo bello a lo terrible es frágil.

La combinación de estos tres elementos es lo que puede convertir el muestreo en una mera rutina o en un arte.  La rutina intentará desdeñar los elementos distorsionadores del entorno y centrarse en los datos utilizando las mínimas herramientas, pero... es importante plantearse algunas preguntas:

• ¿Y si resulta que la distorsión del entorno potencia algo que yo quiero analizar?
• ¿Puedo alterar el entorno para que simplifique la recogida de datos?
• ¿Si recogo una muestra destruyo el entorno que quiero analizar? Si es así, ¿puedo muestrear de forma indirecta?
• Por extensión a lo anterior, ¿Hay algún dato en el entorno más fácil de capturar y que sea un buen indicador de lo que yo quiero analizar?
• ¿Tengo datos anteriores que me ayuden a capturar partes concretas con más precisión para luego hacer un collage?
• ¿Existen elementos monótonos o repetitivos?

La lista de métodos de muestreo no es para nada cerrada.  Lo que sucede a menudo es que los diferentes métodos se combinan. Eso sí, inventarse un método de muestreo no es algo baladí, la base matemática  que hay tras un método es muy intensa.

Más allá del muestreo aleatorio simple

Con esta información, y dado que quieres hacer un reportaje lo más representativo posible (pero cuanto antes acabes mejor), te preguntas: ¿Cuántas opiniones recojo de cada barrio?  La lógica lleva a pensar que en el barrio A sólo vas a entrevistar a una sola persona (la segunda te dirá lo mismo que la primera), y en el barrio B, las que puedas recoger el resto del tiempo.

El resultado es que tardas una hora menos de lo habitual en recoger opiniones, con lo que llegas antes a casa. Eso sí, antes de tumbarte a hacer la siesta te apuntas en la agenda que debes un café a ese compañero.

En los procesos de muestreo sencillos, el aprovechamiento de esa información se obvia en detrimento del muestreo aleatorio simple.  En el caso de la reportera, eso equivale a recoger el mismo número de opiniones en los barrios A y B, con la consecuencia que obtienes *menos variedad* de opiniones con más esfuerzo.

Por lo tanto, el muestreo aleatorio simple es el primer escalón en las técnicas de muestreo, pero por ello el menos eficiente.  Si tienes información sobre la estructura del entorno, puedes aprovecharla y ahorrarte esfuerzo.  Algunas de las posibilidades son:

• El entorno está diferenciado en conjuntos totalmente separados.  En ese caso puedes utilizar el muestreo estratificado. Lo que vas a hacer es recoger cantidades diferentes de ese estrato, y luego hacer una media ponderada de acuerdo con el peso de cada estrato en la población total. Ejemplos de estratos son la diferenciación por sexos, o edad, o nivel de ingresos.
• Hay división de conjuntos, cada uno de los cuales es heterogéneo en su interior, y parecido al resto. Es decir, que tienes pequeñas muestras representativas de todo el conjunto.  En ese caso puedes utilizar el muestreo por conglomerados. Los conglomerados son lo opuesto a los estratos. Un ejemplo de conglomerado serían poblaciones de tamaño similar: en todas podemos encontrar su plaza, ayuntamiento, iglesia, su parte antigua y probablemente una parte nueva.  Esta repetición casi sistemática ayuda a tratar unos pocos pueblos representativos y luego trasladar los resultados al conjunto.
• El entorno genera (o emite) elementos en serie, de forma rítmica y totalmente predecible. En ese caso, puedes aprovechar ese ritmo para aplicar un muestreo sistemático.  Este muestreo divide los elementos en grupos y selecciona uno o más de cada subgrupo. En esencia es similar al muestreo aleatorio simple, sólo que la forma de muestreo puede depender de las características de la /serie/.
• Lo que quieres analizar es mucho más complejo de observar que otro elemento con el que tiene una relación causa-efecto.  En ese caso puedes aplicar un muestreo de razón (o de ratio).  Observando el segundo puedes deducir el primero por su correlación.

Comentarios finales

Siempre es importante tener en cuenta que el usuario da valor a la herramienta, por lo que no se puede afirmar la veracidad de un estudio sin saber su método. Lo que sí es posible afirmar es que la selección correcta del método de muestro garantiza buenas conclusiones con poco esfuerzo.

A todo esto, sólo me queda añadir un detalle.  En el caso de las encuestas y estudios sociales con personas, hay otro elemento añadido: el cuestionario.  Este elemento es parte de la caja de herramientas de la estadística, y otro punto clave.  Pero esto, si lo considero oportuno, ya será motivo de otro artículo.

La productividad de las pequeñas cosas

Las tareas técnicas que tengo en mente ocupan el mismo lugar que freír un huevo, abrocharse una camisa o cambiar una bombilla. Contratar a un cocinero, un sastre o un lampista para hacer estas tareas es posible, pero poco eficiente.

Precisamente en estas "pequeñas cosas" (ahora sí, hablo de informática) es donde uno toma el pulso de la introducción de las tecnologías y en cómo afectan a la productividad (y quizá también a la motivación). Mi conclusión personal es que el pulso mejora, pero aún es débil.

Aunque la penetración del ADSL, los móviles y de los servicios web puedan ser buenos indicadores de interés, no lo son necesariamente de resultados. Creo que el componente de usuario pasivo  es el principal factor del alza en el uso de estos servicios.

A todos muchos nos han enseñado a abrocharnos una camisa o a cambiar una bombilla, pero en el terreno tecnológico eso no ha sucedido de la mejor manera ni de una forma estructurada. Este déficit se soluciona teniendo cerca a alguien "entendido" en la materia. Desde el  denominado" pringao", hasta el compañero de trabajo habilidoso con el ratón y el teclado, el que siempre nos soluciona el mismo problema porque nunca recordamos cómo lo resolvió.

Cuando veo de cerca lo mucho que podrían mejorar algunas situaciones de manejo de ordenadores, me planteo cómo se podría mejorar la calidad de vida, tanto de los usuarios como de sus compañeros habilidosos. De ahí la idea del técnico de proximidad. El término es más apropiado por proximidad que por técnico, pero en cualquier caso es un término y nada más.

Cómo definir las tareas del técnico de proximidad

Funciones del TP

• Detectar las deficiencias de los usuarios, e identificar las formas de corrección de las competencias (formación, motivación, organización).
• Sentar las bases de un plan para mejorar la productividad de cada persona delante de un ordenador, enfocándose especialmente en el aumento de la confianza hacia el uso del PC y sus programas.
• Enseñar los pequeños trucos que reducen significativamente el tiempo en tareas, especialmente las más repetitivas y monótonas.
• Trabajar con trucos mnemotécnicos, "refcards", chuletas, how-tos cortos (y principalmente visuales), o dudas habituales, que sirvan de soporte. Deben ser elementos de referencia rápida, nada de manuales.
• Proponer mejoras en el entorno de trabajo, programas o equipos para aumentar la productividad y el bienestar.
• En cierto modo, ser invisible hasta que detecta que es necesario.
• Dinamizar el intercambio de "trucos" entre usuarios. Los mejores trucos pueden surgir de la serendipia durante la rutina diaria. En ese momento el TP puede detectar quién hace las cosas diferentes y trasladarlas al resto.
• En caso que la empresa contrate desarrollos de aplicaciones a medida, detectar la forma de trabajar para trasladarla al análisis de estas aplicaciones (participando activamente), y luego en el testeo (seleccionando los usuarios más adecuados testear y diagnosticar la usabilidad).

Funciones que no son del TP

• Resolver problemas técnicos, si no es que se ha establecido así.
• Convertirse en un loro-diccionario de trucos: El truco está ahí y todo el mundo puede escucharlo, pero repetirlo cada vez que lo preguntan es algo contranatura: si el truco interesa el usuario se acuerda, y en caso contrario puede seguir haciéndolo como siempre.
• Pulular sin rumbo. Mejor estar sentado leyendo algún informe o un documento antes que pasear sin más.
• Ser un formador puro y duro. Su papel está en el learning by doing de los usuarios. La estandarización se construirá por la misma organización (sobreviven las tareas más útiles), y no en un manual.
• Hacer la tarea por el usuario, salvo que las circunstancias obliguen (urgencia, imprevistos, potencial pérdida de datos, riesgo de seguridad, etc.).
• Ser generador de estigmas (burlándose de los errores ajenos) o convertirse en el "vigilante de los ineptos".
• Posicionarse como experto o gurú. Es más, creo que el mejor perfil de TP puede ser el de un usuario avanzado que ha superado las fases de aprendizaje útiles para el resto.
  

Consecuencias, ciclos y evolución

No me cabe duda que la introducción de este perfil ayudaría en muchas organizaciones a mejorar la productividad. Pero la productividad es un fin que también pasa por la motivación, el interés, los conocimientos y la organización del trabajo.

En caso de conseguir que la mayoría de miembros de una organización se impliquen en la iniciativa, las mejoras no tardarán en llegar. Quien quiere aprender cuestiones útiles de la informática, aprende rápido dentro de sus posibilidades. Tardar la mitad de tiempo en realizar una tarea monótona es un incentivo suficiente (siempre que el objetivo no sea perder el tiempo).

Después de conseguir estas mejoras básicas pero palpables, la función y los objetivos del TP pueden diluirse. Aún definiendo un plan a medio plazo, la vistosidad de los primeros cambios disminuye. En ese momento alguien puede preguntarse para qué necesitan saber más, si con lo aprendido ya han mejorado.

Este ciclo de aceleración-freno es natural, y puede ser interesante consolidar lo aprendido aplicándolo a servicios de ocio (utilizar la tecnología en el plano personal), utilidades del ámbito personal, o similares. Aumentar las formas de uso de una utilidad mejora el hábito y refuerza la memoria de uso.

A largo plazo, el papel del TP se integrará tanto en la organización que desaparecerá o bien se implicará directamente en las tareas internas. Lo primero puede suceder si la organización tiene profesionales sobradamente competentes en su actividad, y que han asimilado lo necesario para reforzar sus habilidades técnicas. Lo segundo puede suceder si la dirección se percata de lo valioso que puede ser alguien que ha visto trabajar a los empleados y los conoce muy de cerca. Los casos que no buscan lo mejor para todos no merecen ser mencionados.

Lo que no creo que sea beneficioso es que este perfil se institucionalice indefinidamente, ya que en ese momento perderá la espontaneidad. La proximidad con el resto de usuarios desaparecerá, siendo este factor el más importante para el TP.

Por desgracia, no veo cerca la introducción formal de este perfil en el mercado laboral, por lo que es posible que todos aquellos que han asumido informalmente estas funciones lo sigamos haciendo. ¡Qué lástima! Seguiremos teniendo ratos de total improductividad, aunque a veces muy enriquecedores ;-).

¿CMS + Empaquetamiento = PMS?

Entrada+Proceso+Salida = Fuentes+(Selección ó Producción)+Difusión

Destinatarios de un PMS

• Periodistas independientes, o productores de contenido para empresas ajenas que quieren organizar su producción en un solo entorno, para luego enviarlo a cada uno de sus clientes.
• Newsmasters (ese flamante perfil profesional ), que trabajan filtrando y seleccionando noticias para varios sitios.
• Servicios de agregación y alertas personalizadas.
• Agencias de publicidad y comunicación, que promocionan productos de sus clientes a través de microsites, boletines ó e-mail marketing.
• Grupos de comunicación (desde prensa "tradicional" hasta redes de blogs) que desean centralizar su gestión interna en un mismo entorno de trabajo.
• Servicios de inteligencia competitiva que precisen la captura de información y la realización de "reports".
  
</ul>En estos perfiles presentan características que determinan los requerimientos del gestor de publicaciones:


• Disponer de lo necesario para la producción interna de contenidos.
• Poder gestionar la selección y filtrado de fuentes externas, para combinarlo con la producción propia.
• Aplicar la herramienta para el uso interno de una organización o bien para dar servicios a terceros.
• Disociar la gestión de contenidos (la trastienda) de su difusión (la tienda) y su presentación (el escaparate) desde el punto de vista orgánico: quien trabaja con los contenidos no necesariamente debe diferenciar el trabajo según el canal de difusión o sobre cómo se presentarán.
• Incluir los criterios de filtro y agrupación de usuarios como un elemento clave en los criterios de difusión.
</ul>Con estos criterios es posible empezar a profundizar en un análisis más a fondo. </p>
Read more »

Parámetros básicos

• Respecto al sistema de empaquetado:
  • Sin empaquetado. Los contenidos van por libre en un listado continuo.
  • Empaquetado de portada/resumen, con acceso al detalle o listado de contenidos no encapsulados (archivo de contenidos).
  • Empaquetado por entrega (issue).
  
  
  
  
• Quién establece el criterio de selección
  • Decisión editorial/interna.
  • Personalización del usuario.
  • Combinación de ambas.
  
  
  
  
• Cómo se establece el criterio de selección
  • Línea editorial
  • Temática
  • Filtros por otros campos (autoría, coincidencia full-text, etc)
  
  
  
  
• Periodicidad de actualización
  • Flujo continuo: en cuanto el contenido está disponible se difunde (a modo de stream)
  • Cronológica (cada X horas/días/semanas/meses...)
  • Según el volumen (cuando al menos hay X contenidos disponibles).
  • Sin periodicidad: Sitios estáticos que no actualizan sus contenidos.
  
  
  
  
• Niveles de acceso (cada nivel debe combinarse con un criterio de control de acceso):
  • Publicación general / portada.
  • Sección / Apartado / Temática.
  • Detalle del contenido.
  • Archivo/hemeroteca de contenidos antiguos.
  
  
  
  
• Criterios de control de acceso (deben combinarse con los niveles de acceso):
  • Totalmente abierto (usuarios anónimo).
  • Restricción de acceso por cuentas de usuario.
  • Restricción de acceso por perfiles de usuario.
  • Restricción por caducidad (suscripciones gratuitas o de pago)
  • Restricción por pago (pay per view)
  
  
  
  
• Organización de los contenidos:
  • Líneas editoriales / Secciones.
  • Formatos o tipos de contenidos.
  • Temática (categorías, etiquetas, etc).
  • Otros elementos y campos (fuente, autoría, coincidencia full-text, etc)
  
  
  
  
• Canal de difusión/distribución:
  • HTTP (Web,RSS,etc): visualización en el navegador o similar.
  • e-mail: visualización en el cliente de correo.
  • SOAP/XMLRPC (visualización determinada por el solicitante)
  • Impresión.
  • Otros (La lista puede ser muy larga)
  
  
  
  
• Formato:
  • HTML
  • RSS (+HTML)
  • PDF u otros formatos binarios
  • Impreso
  
  
  
  
• Destinatarios (target):
  • Usuarios visitantes (difusión pasiva).
  • Suscriptores aceptados.
  • Clientes potenciales (con o sin filtro de segmentación)
  
  
  
  
• Análisis de la interacción:
  • Ningún análisis (al raro hoy en día).
  • Análisis básico: Uso de variables básicas como páginas vistas, Visitas, Usuarios únicos, tasas de rebote...
  • Análisis por segmentos: Combinación de variables básicas para identificar tipologías de usuarios.
  • Objetivos de navegación: Visita a una página determinada sin necesidad de realizar acciones adicionales.
  • Objetivos por acciones: Alta de suscripción, respuesta a encuestas, rellenado de un formulario, compra de producto...
  
  
  
  
• Posibilidad de personalización:
  • Ninguna personalización.
  • Personalización general basada en contenidos, líneas editoriales, temáticas u otra información del sistema.
  • Segmentación general por grupos de personas.
  • Personalización sin datos históricos por usuario.
  • Personalización con datos históricos del usuario (tasas de impacto en difusiones anteriores).
  
  
  
  

Tomando como base esta aproximación, una publicación se crea a partir de la combinación de características anteriores (y otras que no estén aquí). El nombre que recibe al final es una simple anécdota.

No todos los factores pueden combinarse de forma indiscriminada. Por ejemplo, es complejo (y seguramente nada cómodo) utilizar el control de acceso por suscripciones si el formato de difusión es RSS. Al establecer los parámetros básicos lo que se permite es que la configuración sea flexible, tras lo cual hay que establecer restricciones para casos concretos como el del ejemplo.

Otros aspectos

Por ejemplo, he descartado la posibilidad de analizar los criterios de diseño y maquetación de una publicación. En este caso, lo más habitual es trabajar sobre una plantilla general que se desglosa en cajas.

Sobre este punto creo que para tener una base sólida, la aplicación debe diferenciar el aspecto visual en vistas (por utilizar la terminología del MVC ). Este detalle y la decisión sobre qué campos mostrar en cada nivel de la publicación deben depender de la gestión de vistas, y no del control interno. Evidentemente determinan el resultado final de la publicación, pero no configuran la publicación como bloque de trabajo.

Además puede ser interés trabajar con diferentes vistas para una misma publicación (un caso típico son los themes que tienen aplicaciones como Wordpress o Joomla), o introducir vistas predeterminadas que luego sean configurables (algo por ejemplo disponible en Drupal, donde es posible cambiar los colores principales en los temas que lo permiten).

Otros aspectos que hay que tener en cuenta en el nivel de la vista es la posibilidad de incrustar widgets y otras cajas con contenidos/servicios externos (si el objetivo implica un mashup). El caso más obvio es el de la publicidad. No debería ser necesario generar un tipo de contenido "banner" teniendo opciones libres como OpenX , o bien opciones conocidas como AdSense. También sería interesante pintar datos utilizando gráficos estadísticos que dependan de aplicaciones externas.

Consideraciones previas

Incluso en la colección de datos que nos interesa, es habitual encontrar datos defectuosos fruto de la recogida de información (el trabajo de campo) que también deben ser eliminados para conseguir una mayor fiabilidad de la información.

En el siguiente ejemplo descarto datos de acuerdo con los objetivos que me planteo, pero no hago una limpieza posterior, con una doble intención: comprobar que es necesario, y ver que los datos erróneos también tienen unas características propias, que son detectables con métodos estadísticos básicos.

Objetivos

Este análisis podría dar paso a búsquedas posteriores para determinar si existe alguna relación entre tales enlaces y sus características propias (número de palabras del enlace, términos utilizados en el enlace) como ajenas (posición en el conjunto del texto, posición dentro del párrafo, posición en una frase). De todos modos este estudio más complejo que dejo al margen para otras ocasiones.

Extrayendo datos de Piwik

Por ahora vamos a extraer una serie de datos para tener una idea de la información que hay almacenada en la base de datos.

Empezaremos por comprobar cuántas salidas genera el blog hacia otros sitios. Para ello, ejecuto la consulta:

SELECT pla.name,count(*) salidas FROM `piwik_log_visit` plv inner join piwik_log_action pla on plv.visit_exit_idaction=pla.idaction WHERE pla.name like 'http%' and pla.name not like '%sopadebits.com%' group by visit_exit_idaction order by salidas desc

La consulta selecciona los nombres de los sitios que han recibido visitas desde un enlace en mi blog.  Para detectar los sitios externos, filtro los datos teniendo en cuenta que el campo name de la tabla piwik_log_action empiece por "http" [pla.name like 'http%'] y que no contengan el dominio del post [pla.name not like '%sopadebits.com%']. Ordeno el resultado según la cantidad de visitas (de más a menos):

El resultado es parecido a:

Dividiendo el número de visualizaciones por el número de salidas, tendré el ratio de click-through. El primer paso se consigue con la consulta siguiente:

select distinct pllva.idaction_ref,pllva.idaction from piwik_log_action pla inner join piwik_log_link_visit_action pllva on pla.idaction=pllva.idaction_ref where pllva.idaction in (6, 24, 31, 135, 106, 11, 53, 107)

De todos modos, en estos datos nos encontramos con dos temas:

• vemos que las acciones 5 y 144 son equivalentes.
• Vemos que las acciones 24 y 106 vuelven a ellas mismas, lo que sin duda es un error (quizá debido a un doble click del usuario mientras se procesa la consulta o algo por el estilo).

Nos quedamos entonces con los ítems  [5,10,30,7,8,61,27,12,10,17,144].  Ahora queda ejecutar la consulta para las páginas vistas de cada ítem:

select pla.idaction,pla.name,count(*) paginas_vistas from piwik_log_link_visit_action pllva inner join piwik_log_action pla on pllva.idaction=pla.idaction where pla.idaction in (5,10,30,7,8,61,27,12,10,17,144) group by pla.name order by paginas_vistas desc

Por ejemplo, el enlace 61 es claramente un error, probablemente debido a un error en la introducción del enlace.  El click-through que presenta puede ser debido a que el usuario trata de accede r repetidas veces al enlace. Es probable que se pudiera unificar con la acción 27 (el post sobre el efecto Medici), y que los dos clicks fueran porque el usuario vuelve a intentar el enlace.

El cálculo aporta información interesante, aunque no significativa.  De lo anterior sólo  los tres primeros enlaces tienen datos suficientes como para sacar alguna conclusión. Entre ellos cabe destacar en positivo el enlace de open-flash-chart y en negativo el de las distancias normalizadas.

Sobre el resto, precisamente el enlace del Medici Effect aporta información interesante...  pero para corregir errores. Esto en sí mismo es interesante porque el detectar que el ratio  varía bastante (aunque es poco significativo por los pocos datos). éste es un caso determinado nos induce a pensar que algo sucede. Pero no era el objetivo de estas consultas.

También cabe comentar que todo este proceso podría haberse realizado con una sola consulta, máximo dos.  En cualquier caso estas consultas no serían eficientes en un servidor a pleno rendimiento.

El siguiente paso (en otro artículo) será extraer datos globales de las relaciones entre enlaces para realizar un análisis basado en cadenas de Markov. Para eso utilizaremos el paquete estadístico GNU R.

La principal debilidad en el lado del cliente es que la recogida de estos datos funciona con javascript, por lo que si el navegador lo tiene desactivado, estos datos no se recogen. (Ref. a diferencias entre log servidor y cliente).

Para organizar esta información, normalmente se estructura en base a usuarios, visitas, y páginas vistas.  Hay un documento con definiciones muy bien planteadas (PDF)  para esta información básica en el sitio de la Web Analytics Association.  Para estructurar esta información se utiliza como elemento base el código de sesión. Este código es un valor único que el navegador del usuario almacena en su cookie .

Normalmente el servidor elimina los datos de sesión al cabo de un tiempo después del a última petición del usuario (pocos minutos por lo general), mientras que el navegador puede borrar la cookie cuando caduque o cuando el usuario lo solicite.  La diferencia entre la información a nivel cliente y servidor es el quebradero de cabeza para desglosar usuarios y visitas.  Sabemos con bastante fiabilidad cuándo se inicia o se acaba una visita, pero no podemos tener claro si una nueva visita se corresponde con un usuario anterior si la cookie se ha borrado.

En cambio, si la cookie existe, volverá a enviar el código de la última visita.  El gestor de analíticas habrá almacenado este código para poder identificar a ese usuario, y aunque le asigne un código nuevo, ya dispondrá de una relación entre dos visitas.

A este embrollo hay que añadir que un equipo no se corresponde con un usuario.  Los cibercafés, los PCs en centros académicos y el ordenador "de la familia" son ejemplos claros de este hecho.  Por lo tanto, la fiabilidad de los usuarios únicos es relativa, mientras que las páginas vistas y las visitas son datos mucho más fiables.

Con estos tres niveles de datos se pueden extraer informaciones interesantes.  Algunas de ellas son indicadores de sobra conocidos, como las páginas por visita, tiempo entre dos visitas de un usuario, páginas más vistas, etc.

Hasta aquí la teoría básica de las analíticas web.  Hay muchos recursos al respecto, el problema es filtrar qué recursos son más interesantes.

Uso de Piwik

El siguiente paso es tener acceso a estos datos.  Hay variedad de formas, aunque los más conocidos son el análisis de logs del servidor (análisis transaccional). Dado que puede interesar disponer de más información que la que proporciona el servidor, yo voy a utilizar los datos que proporciona la aplicación Piwik, una herramienta de código abierto desarrollada con PHP y con licencia GPL que permite acceder a esta información ya estructurada en una base de datos MySQL.

Visto lo anterior, escojo Piwik como herramienta de analítica web porque me permite acceder de forma estructurada a los datos, pero hay otras que también permiten esas funcionalidades. Está por ejemplo PHPMyVisits , que incluye además una funcionalidad para obtener el heatmap de clics de los usuarios (integrando ClickHeat desarrollado por labsmedia ).

Volviendo a Piwik, su web proporciona una imagen sencilla de su _esquema de la base de datos_ que almacena la información de la aplicación.  En este esquema, hay que destacar tres tablas, que son las que almacenan los datos de navegación como tales:

• piwik_log_visit: Almacena los datos relativos a una visita.  Dado que se espera que cada visita mantenga los parámetros de equipo y navegador, no es necesario generar redundancia a cada clic del usuario.  Esta tabla incluye datos sobre cookie, localización, página de origen (referer ), opciones del navegador y del equipo, etc.
• piwik_log_link_visit_action: Almacena los datos de la página vista.  Esto incluye un código único de URL actual (lo comento en la siguiente tabla), código de URL de origen, y el tiempo de estancia en esta página.  Esta tabla será importante en el momento de realizar un análisis de la navegación. 
  
• piwik_log_action: Es una tabla auxiliar donde se almacenan las URL solicitadas, un registro por URL.
  

A todo esto hay que decir que Piwik genera tablas-resumen mensuales de los datos.  Estas tablas se tienen el formato piwik_archive_numeric_AÑO_MES y piwik_archive_blob_AÑO_MES. Estas tablas ayudan a mantener un tamaño reducido de las tablas anteriores, y siguen permitiendo el acceso a los datos básicos de fechas (tablas ..._numeric_...) o a los datos completos (tablas ..._blob_...).

Con todo esto, sólo queda añadir que el prefijo piwik de todas las tablas viene por defecto pero es posible cambiarlo en la fase de instalación de la aplicación.

La razón de existencia de la última tabla es que evita la redundancia de piwik_log_link_visit_action. Teniendo en cuenta que esta es la tabla que almacenará más datos, esto es importante para la agilización en la inserción de datos.

Analizando más a fondo la tabla piwik_log_visit, podemos ver que existen los campos visitor_idcookie y visitor_returning.  Estos datos nos permiten relacionar visitas para identificar a los "usuarios únicos", siempre teniendo en cuenta las consideraciones que comentaba antes.

Con estas tres tablas tenemos la estructura usuario-visita-página, necesaria para empezar a extraer información de forma estructurada.

En el próximo post empiezo a comentar las consultas SQL para extraer datos, los objetivos del análisis y su aplicación en GNU R.