Ya tengo una herramienta de analítica web. ¿Qué valor puedo obtener sin necesidad de usar fórmulas asociadas a KPIs personalizados que requieran de una consultoría especializada?

La respuesta dependerá obviamente de los datos disponibles y el tipo de negocio de que estemos hablando, pero hay ciertas decisiones que, a grandes rasgos, ya contarían con un apoyo suficientemente cimentado. Por nombrar unas cuantas:

- Discriminación de palabras clave en entornos PPC en función del nivel de conversión de cada una
- Enfoque en la renovación de contenidos para las áreas más populares entre nuestros visitantes
- Discriminación del sistema de navegación menos popular entre dos alternativas simultáneas
- Generación de contenidos en el idioma y para el área geográfica que representan un mayor porcentaje de conversión en el canal web
- Concesión de mayor protagonismo a los productos y servicios que resultan más populares

A estas y otras podríamos a continuación añadir las decisiones de más alto valor para la empresa: Aquellas que nos permiten segmentar a nuestros visitantes a partir de criterios dinámicos, influir en nuestra estrategia global de empresa o aumentar drásticamente el nivel de conversión con cambios aparentemente insignificantes. Eso sí, estas últimas exigen una completa adecuación al negocio propio y, en consecuencia, no vienen “de serie” 

Por si teníamos pocos anglicismos, vuelvo a estar obligado a usar otro (podemos pensar en “puntuación”, pero no encontraremos referencia alguna si no conocemos el término ya extendido por todo el mundo). Yendo por partes:

Introducción

Con Scoring nos referimos a la posibilidad de asignar un valor numérico a cada uno de nuestros visitantes en función de la satisfacción de ciertos hitos (ej.: Descarga de un folleto o visualización de un vídeo) o la pertenencia a ciertos segmentos predeterminados (por sexo, procedencia geográfica, idioma, etc.).

Este sistema de puntuaciones nos retrotrae a la eterna dicotomía análisis cualitativo/análisis cuantitativo. Pero una vez más salimos airosos sin vernos obligados a escoger: Las puntuaciones son individuales, pero su objeto es la definición de grupos en función de los puntos obtenidos. Estos grupos pueden ser más tarde usados en una multitud de entornos:

1) Ad Servers: Adaptando el contenido de banners a diferentes segmentos predefinidos
2) Combinación con datos de benchmarking: A efectos de estudio de mercado y planificación
3) Gestión de contenidos: Personalización mediante la integración con el CMS
4) Multivariate Testing: Adaptando combinaciones de elementos en la página a los segmentos definidos
5) Marketing directo: Obteniendo relaciones altamente segmentadas de los usuarios previamente registrados, lo que facilita la adecuación de ofertas a las inquietudes de la audiencia

¿Problemas con la ley?

Si bien los cuatro primeros no traen mayores consecuencias, la planificación de campañas de marketing directo en función de los resultados del Scoring puede convertirse en un terreno pantanoso desde el punto de vista jurídico.

La Ley Orgánica de Protección de Datos Personales(LOPD) obliga a registrar los “ficheros” de datos personales que vendrá a recoger toda la información asociada a las personas físicas susceptibles de individualización. Esto obliga a extender este registro a los datos relativos al “Scoring” realizado, dado que la dirección de correo electrónico de los usuarios registrados estará vinculada a toda la información recopilada durante el proceso de puntuación.

Por supuesto, la LOPD añade a esto otras obligaciones: La empresa prestadora deberá poner en conocimiento del usuario todas las actividades que piensa llevar a cabo con los datos de éste en el momento de la aceptación del consentimiento del susodicho para el almacenamiento de su dirección de correo (registro, compra, etc.), recordándole que tendrá derecho a acceder, modificar o cancelar la información a él referente en el momento en que lo considere oportuno.

Podemos vivir con ello

La buena noticia es que, una vez satisfechas las obligaciones señaladas, el usuario controla su información y el analista es libre para llevar a cabo su particular misión.

Nadie quiere la patata caliente, pero todo el mundo exige datos. ¿A que suena familiar? Pues habrá que decidir quien se encarga de dirigir el carro de la Analítica Web.

Aunque hay gente que mataría (bueno, puede que no sea tan extremo) por asumir tan feliz posición, es habitual que su responsabilidad comience recayendo sobre aquellos que ignoran en qué consiste o sencillamente no cuentan con más tiempo o ganas para añadir otra misión a su ya larga lista de funciones. Y esto a pesar de los salarios que empiezan a pagarse por ahí por asumir meramente el rol de Analista Web (pregúntenle a Eric Peterson, que ya sabe tanto de recursos humanos como de analítica

Al final, acaba cayendo a esta gente:

1. Agencia de Marketing Online o proveedor de PPC: Esto ocurre cuando es la propia agencia o proveedor el que ha colocado una herramienta de analítica (Ej. Google tiene a un buen cliente de AdWords y le ofrece Google Analytics). En la práctica esto significa que nadie está encargado de la analítica y que nunca se cuenta con informes medianamente competentes (quitando el seguimiento básico de las propias campañas que han dado origen a la relación).

2. Director de Marketing Online: Esto es muy común, pero bastante contraproducente. Una cosa es que el Director de Marketing Online tenga que revisar informes para tomar decisiones sobre sus campañas. Otra muy distinta es que sepa gestionar la recopilación, análisis y optimizacion asociadas al puesto. Además: La analítica web puede tocar a otros departamentos como el de comercio electrónico o contenidos (según la naturaleza del negocio).

3. Director de Comercio Electrónico: También bastante frecuente, siempre y cuando se lleve a cabo una actividad de comercio electrónico. A veces el Director de Marketing Online depende de este mismo responsable. En ocasiones puede ser exactamente al revés. En cualquier caso, sigue siendo mala idea. El Director está para tomar decisiones, no para investigar, analizar, estudiar posibles algoritmos, poner a prueba elementos en la página, etc.

4. Equipo encargado de Data Mining o Business Intelligence: Mal, otra vez. Y común en entornos en los que el equipo de sistemas ha extendido el báculo de su mando sobre gran parte de la organización (!). Aunque se trata de gente que obviamente sabe cómo gestionar cantidades ingentes de datos, las aptitudes técnicas de estos profesionales no suelen estar equilibradas con un conocimiento profundo de la web, el marketing o la estrategia de negocio en general.

5. Analista Web: Por fin, alguien competente. El problema es encontrarlo. De ahí los salarios que comenta Peterson y de ahí lo ya comentado en este mismo blog hace meses.

6. Empresa externa especializada: Una gran alternativa que permite aunar sinergias y reducir costes. Especialmente adecuado en el caso de empresas que hagan uso de herramientas de analítica en modo ASP (on-demand). Mediante un contrato de externalización de tareas de análisis y optimización, una empresa externa puede conectarse regularmente a los sistemas del cliente y aportar las últimas tendencias en metodología y análisis.

En definitiva, la especialización no era solo para los insectos

Estando como están tan de moda los agregadores de RSS y Widgets y las páginas personales que permiten la integración de ambos, nos encontramos a menudo con un problema de perspectiva real del éxito de nuestros contenidos y aplicaciones.

Como el tema de los RSS ya ha sido tratado, me gustaría centrarme brevemente en la medición de Widgets.

Los Widgets son pequeñas aplicaciones o subprogramas (desarrollados habitualmente en Flash) con total independencia de la web de la que originan. Estos Widgets pueden facilitar la vida a sus usuarios dando un acceso a servicios o información personalizada y concisa desde el panel de control o página personal del propio usuario.

¿Por qué medir el uso de estos Widgets? Porque están ahí para cumplir una función. Esta función puede ser de mero branding (ej. una famosa marca de tablas de surf puede regalarnos un miniaplicativo que actualice el estado de las olas en la región), reproducción de podcasts o, por ejemplo, puerta de entrada a una tienda online.

¿Cómo medir este uso? Por lo general, será necesario insertar una muesca de seguimiento en el propio código fuente del Widget que vincule su actividad (la propia manipulación del aplicativo por el usuario) a la actividad global en su web de procedencia.

En el marco de la venta directa al consumidor (”Retail”), se plantea con frecuencia el problema de la vinculación de diferentes versiones de una página de aterrizaje (o puerta de entrada al negocio online) a segmentos demarcados por el grado de intención de compra del visitante.

Esto implica combinar dos importantes tareas:

1. La del A/Bn Testing o MVT de diferentes elementos en la página
2. La de segmentación

Como la primera tarea ya ha protagonizado diversas entradas en este blog y está suficientemente documentada en cientos de webs especializadas, paso a centrarme en la segunda para después reflexionar sobre los nexos que podríamos establecer entre ambas.

La segmentación en base al grado de intención de compra no había estado nunca tan al alcance de la mano (si bien el concepto no tiene nada de nuevo). Asumiendo que el canal web objeto de análisis no cuenta con un canal alternativo en el mundo “offline” (red de tiendas), podemos establecer tres grandes segmentos:

- Visitantes que nunca comprarán: Curiosos, despistados o competidores que buscan descripciones, imágenes o entretenimiento.
- Visitantes que están pensando en comprar.
- Visitantes que entran para comprar porque la decisión ya ha sido tomada en su fuero interno.

Es evidente que todo lo que hagamos por satisfacer al segundo grupo satisfará igualmente al tercero (que va a comprar de todos modos). Sin embargo, no tenemos claro que lo que hagamos por satisfacer al primero en la lista no vaya a ser contraproducente con vistas a hacer la vida más fácil a los dos últimos grupos (hay ciertos contenidos que pueden ser muy útiles a nivel de documentación académica y al mismo tiempo constituir un peligroso elemento de despiste para quien esté buscando una fría comparativa entre funcionalidades específicas).

¿Cómo distinguirlos?

Podríamos empezar con la fuente. La web de origen o palabra de búsqueda en motor de búsqueda pueden delatar, por ejemplo, al investigador académico o competidor en algunas circunstancias.

Podríamos seguir con los datos sociodemográficos ya disponibles a partir del proceso de navegación (que cotejados con tendencias históricas o resultados obtenidos de nuestros esfuerzos en web mining pueden ser enormemente ilustrativos).

A ello podemos añadir encuestas, datos remitidos mediante formularios de acceso e información almacenada en el historial de visitante (número de visitas, compras previas, etc.). No vendrá mal aquí echar mano de los vitales conceptos de Recency y Latency documentados hasta la saciedad por Jim Novo.

Todo esto nos permite definir con mayor o menor solidez los tres segmentos identificados. ¿Cómo establecer ahora el nexo entre estos segmentos y los contenidos que les dan la bienvenida? Es aquí donde dependemos completamente de nuestra capacidad de integración técnica entre la generación de contenidos y la identificación del segmento. Como alternativa a la integración manual que a día de hoy recae sobre consultores expertos en Analítica Web y desarrollo, el mercado está presenciando ciertas iniciativas de integración de sistemas de MVT (Multivariate Testing) con herramientas de gestión de contenidos (verbigracia de la reciente adquisición de Optimost por Interwoven), y aquí podría estar la respuesta.

Por supuesto, todo esto deja de ser necesario en el momento en que confiamos en algoritmos de aprendizaje automático (inteligencia artificial) que crean sus propios segmentos sobre la marcha. Productos como Touch Clarity incorporan estos algoritmos, si bien su alcance se limita a módulos muy específicos (”containers”) de la página.

Aquí algo muy concreto que da bastante guerra: Cómo evitar imprecisiones a la hora de elaborar informes sobre la descarga de documentos en formato PDF.

Como habrá quien aún procese logs http para obtener sus informes, aquí hay una lista de problemas históricamente asociados a la obtención de resultados sobre descargas:

- Un solo PDF puede provocar más de una petición http (por su tamaño, se descarga por partes o páginas y cada parte implica una entrada en el log). Esto provoca distorsiones cuando la medida a utilizar es el número de descargas (los documentos más voluminosos se presentan como los más populares), lo que nos obliga a buscar soluciones como:

1. Recurrir a realizar comparativas sobre el volumen de visitas entre diferentes documentos (con las limitaciones que la definición de visita pueda acarrear en un entorno que no usa cookies).

2. Filtrar las peticiones redundantes, delatadas por el código (”Return Code”) 206 asociado a aquellas que recaen sobre un archivo en proceso de descarga (a medida que se va avanzando sobre las páginas del documento).

- Los archivos descargados se contabilizan como hits (accesos), pero no entran dentro de la definición de page views (páginas vistas) al no tratarse de documentos web. Esto resulta con frecuencia en informes aislados en compartimentos estanco: Archivos descargados y páginas visualizadas. Como consecuencia, resulta muy difícil vincular una serie de descargas a la navegación de páginas realizada por el usuario de modo previo a dichas descargas.

Cubiertos estos problemas históricos (y muy presentes para mucha gente), veamos cual es el principal problema asociado a una metodología de análisis basada en huella (tag):

- El PDF no puede generar tráfico porque no puede incorporar huella (JavaScript), al contrario que los documentos web. Esto obliga a etiquetar el Click (evento) que precede a la descarga. En consecuencia:

1. No sabemos si el documento se ha descargado o visualizado. Sólo sabemos que alguien ha solicitado su descarga.

2. Por extensión de las limitaciones asociadas a la huella, no tenemos dato alguno con relación a los visitantes que no admiten JavaScript (la visibilidad es en este caso menor incluso que en las documentos web, que pueden incorporar una sección NOSCRIPT).

¿En qué se traduce todo esto? En que, una vez más, la técnica utilizada provoca estragos en los KPIs escogidos a nivel de requerimientos de negocio. Si estamos analizando logs y ya no podemos filtrar el histórico tendremos que tener cuidado con la comparativa basada en el número de descargas (la imprecisión en el concepto de visitante que pueda contaminar el criterio de visita es extensible a todas las tablas y en consecuencia menos grave). Por otra parte, si usamos huella, podremos jugar con el dato almacenado durante el click de solicitud, que puede ir más allá de la descarga para permitir su cruzado con información de navegación de páginas.

Durante la última década, los Sistemas de Información de Marketing (SIM) han tenido que adaptarse a los nuevos canales digitales, donde las técnicas tradicionalmente utilizadas no resultan del todo operativas. De esta manera, la Analítica Web se ha ido introduciendo paulatinamente en las organizaciones que operan a través de la red.

Es indudable el valor aportado por la “gestión científica” de los clientes, pero llegados a este punto, cabe preguntarse cómo la Analítica Web puede contribuir a la creación de valor en el canal Internet, máxime teniendo en cuenta las características intrínsecas del medio: dificultad para identificar al visitante individual y, la elevada cantidad de información generada, la cual complica la obtención de información útil para la toma de decisiones.

Descargar el artículo completo.

El entorno multimedia se ha convertido en un hecho más que presente en la Web, y las necesidades de medir este tipo de contenidos crece día a día. ¿Qué ocurre con nuestro contenido multmedia? ¿los usuarios ven nuestros videos hasta el final? ¿se producen muchas pausas durante su reproducción?

A través de visualrevenue.org encontramos una solución para recoger toda esta información directamente del objeto Windows Media y el evento playerStateChange(), utilizando, eso sí, extensiones MSIE. Esto quiere decir que la metodología solo recogerá los eventos cuando nuestros usuarios utilicen navegadores Microsoft Internet Explorer.

Tomamos como ejemplo el siguiente player WMV del que vamos a hacer un seguimiento de sus eventos:

<object width="280" height="280" id="TestMediaPlayer">
<param name="fileName" value="http://mydomain/myvideofile.wmv"></param>
<param name="animationatStart" value="true"></param>
<param name="transparentatStart" value="false"></param>
<param name="autoStart" value="false"></param>
<param name="showControls" value="true"></param>
<param name="loop" value="false"></param>
<param name="ShowStatusBar" value="true"></param>
</object>


Gracias a la propiedad playState del Windows Media Player podremos conocer el estado del reproductor, siguiendo los códigos de estado que se explican en la especificación de Microsoft MSDN. Con el siguiente bloque de código JavaScript controlamos los eventos del reproductor:


<script language="Javascript" type="text/javascript"
for="TestMediaPlayer" event="PlayStateChange(NewState)">
switch (NewState)
{
case 1:
// Stopped
break;
case 2:
// Paused
break;
case 3:
// Playing
break;
case 8:
// Media Ended
break;
}
</script>

Para cada caso bastaría con invocar a una función que enviase el dato deseado (sin recargar la página) a nuestra herramienta de analítica preferida.

He aquí una discusión que no se pasa de moda y que creo que no ha surgido aún en el contexto de la AEAW: ¿Qué fuente de tráfico tiene más valor a corto, medio y largo plazo?

Como resulta que la mayor parte de los expertos en SEO no lo son en PPC y viceversa, este dilema torna a menudo en una acalorada discusión.

Los expertos en SEO afirman que su tráfico es más duradero porque, al contrario que los vínculos esponsorizados, los resultados orgánicos no desaparecen en el momento en que se detiene la inversión (que en PPC se asocia al pago directo por click y en SEO corresponde al tiempo dedicado por el profesional en cuestión).

Los expertos en PPC podrían decirnos por su parte que:

- El tráfico esponsorizado se dirige exactamente a las puertas de entrada deseadas (uno de los efectos no deseados del SEO es que las “ventanas” queden mejor posicionadas que las “puertas”)
- Este tráfico es más medible al tener control total sobre cada vínculo y poder conocer con exactitud el coste de cada visita
- El nivel de riesgo es siempre menor mediante PPC, dado que un cambio en el algoritmo de la herramienta de búsqueda puede alterar los resultados orgánicos pero no los de pago
- Quien usa un vínculo esponsorizado lo hace porque inconscientemente sabe que si alguien paga por estar presente es porque tiene algo serio y profesional que ofrecer

Por supuesto, todo esto es igualmente discutible. En mercados poco maduros (España, sin ir más lejos) la línea de pensamiento del consumidor medio es precisamente la contraria a la expresada en este último punto: La mayoría de la gente desconfía de los vínculos de pago ignorando que los vínculos orgánicos están sujetos a un nivel de manipulación nada despreciable (léase SEO).

Con todo esto sobre la mesa surge una alternativa a ambos: El tráfico originado más allá de herramientas de búsqueda. Esto es, en URLs concretas de referencia. Y este tráfico podría considerarse el de más alto valor por varias razones:

- En función de la web de referencia, contará con mayor o menor estabilidad que el tráfico SEO, pero siempre superará a la aportada por PPC
- Este tráfico conlleva un menor nivel de riesgo que el originado en SEO, al no ser susceptible a cambios en los algoritmos de la herramienta de búsqueda (históricamente, varios cambios drásticos se han sumado a las mejoras paulatinas asumibles)

Por supuesto, el valor a corto, medio y largo plazo de unas u otras URLs de referencia o webs a las que pertenecen dependerá de cada una de ellas, pero se sumará a su propio impacto en los esfuerzos ya invertidos en SEO. Con independencia de la evolución de los algoritmos, el tráfico generado en URLs estables siempre contará con un peso considerable en el posicionamiento de la web. Además, una lista controlada de estas URLs o relación próxima con el operador que las publica facilitará el nivel de control que sólo PPC nos garantiza.

AJAX (Asynchronous JavaScript And XML) es una tecnología del lado del cliente basada en JavaScript y XML. Sin entrar en detalles demasiado técnicos, se podría resumir su funcionamiento en la posiblilidad de realizar cambios en una página sin necesidad de recargarla, esto es, hacer peticiones HTTP en segundo plano, de forma transparente al usuario. De este modo se aumenta la interactividad, rendimiento y usabilidad de la aplicación.

Dejando a un lado la accesibilidad de las aplicaciones basadas en AJAX, bastante cuestionable por sí misma ya que se basa en la tecnología JavaScript (evitar la discriminación requerirá de código alternativo), vamos a analizar el impacto que tiene el uso de esta técnica de programación en nuestras herramientas de Analítica Web.

Dado que a partir de ahora no siempre se carga una nueva página cada vez que el usuario realiza un evento (pulsa un link), la técnica de colocar la huella al final de cada página que se desea controlar no será suficiente, ya que ésta no siempre se ejecutará y el evento pasará desapercibido para la herramienta de analítica.

Una posible solución consiste en la introducción de la huella en cada fichero susceptible de ser invocado. Por ejemplo, si tenemos un pequeño formulario que se empotra en la página al pinchar un enlace, al invocarlo se ejecutaría la huella y se interpretaría como la carga de una nueva página. Sin embargo, esto podría dar lugar a la ejecución de la huella varias veces al cargar una misma página que incluye llamadas a otras, lo cual supondría un problema importante a la hora de interpretar los informes.

Otra posible solución que se ajusta más a la realidad, sería el etiquetado de los eventos que invoquen AJAX (cualquier enlace que llame a la funcion JavaScript XMLHttpRequest). De este modo la herramienta conocería la ejecución de código AJAX, sin interpretar la carga de una nueva página. Sin embargo este método también presenta el problema de la complejidad del etiquetado en aplicación con un uso intensivo de AJAX. La mejor solución sin duda consiste en alternar ambas técnicas, en función de la importancia del código que se ejecuta.

Aunque aún hay mucho camino que recorrer en este campo, ya que la introducción de AJAX en nuestras aplicaciones dificulta enormemente la labor de las herramientas de Análitica Web, esto se puede solventar parcialmente con un adecuado etiquetado de las páginas.