Analítica web para desarrolladores

Hace unos meses me propusieron dar una charla de analítca web para desarrolladores para ADWE, Asociación Desarrolladores Web de España.  

La charla tuvo lugar el pasado martes 15 de marzo en el espacio CAMon de Madrid. 

Me puse a preparar mi presentación para la charla con mucha ilusión y muchas ideas. Es difícil seleccionar que contar a un desarrollador acerca de la analítica web cuando piensas que todo es importante. ¿Qué tipo de desarrolladores asistirán? ¿diseñadores? ¿programadores? 

Siendo realista, al final, toda la información que sale de una herramienta de analítica web afecta al desarrollador. Optimización de procesos de compra, páginas de aterrizaje para campañas... no hay nada, que no requiera de  los desarrolladores si pretendemos evolucionar, cambiar y mejorar.

He tenido la suerte de poder utilizar para mi presentación los datos de una empresa real, Flunch. Todo un lujo, porque poder explicar la información que viene de una herramienta de analítica web con datos de reales es más gratificante que hablar de objetivos, métricas, indicadores y análisis en abstracto.

A continuación os dejo el testimonio gráfico y el enlace a la página donde está colgado el vídeo de la charla. 


Vídeo

Testar una web en varios navegadores

Llevo un tiempo inmersa en un proyecto en el que hemos construido una aplicación web nueva desde cero. En esta última etapa previa al lanzamiento me he visto en la necesidad de testear la aplicación en varios navegadores. Dentro de las especificaciones a los desarrolladores, incluimos la compatibilidad con los navegadores más utilizamos por los usuarios, y bueno, tirando de analítica web es un dato bastante fácil de conocer.

Una vez detectamos los principales navegadores que utilizan los internautas que llegan a nuestro site hay que decidir para cuántos vamos a optimizar y cuantos nos vamos a dejar fuera. El panorama con el que yo me he encontrado es el siguiente:

 

¿Qué hacemos en este caso? Vemos claramente que 5 navegadores suponen el más del 90% del tráfico,  así que lo lógico es ir a por ellos y tratar de tener la aplicación optimizada para el mayor número de visitantes.

Bien, ya sabemos para que navegadores debemos optimizar, ahora falta comprobar el funcionamiento de todos ellos para asegurarnos que no dejamos ningún cabo suelto.

En mi caso, empecé a pedir a los compañeros de soporte que me lo instalaran todo: Firefox, Chrome, Safari, Opera y  todos los IE. 

Primera barrera con la que me encontré:  mi equipo iba tirando con windows 2000 (si, si, en el año 2011 con windows 2000) y no admitía Chrome. Lo solucioné más  o menos de forma rápida, migración de sistema operativo y Chrome listo.

Segunda barrera: no se pueden tener varias versiones de Internet Explorer al mismo tiempo,  un pelín más complejo de solucionar, aunque existen simuladores de IE como IE Tester que nos pueden facilitar el trabajo. Pero, la duda de siempre ¿son fiables estas herramientas?

Casualmente, mi paisano Ricardo Tayar   tuiteó en esos días un post acerca del tema. Este post originó en Twitter una interesante conversación  que terminó sembrando en mí la duda de si IE tester era fiable o no. A esas alturas, ya me había presentado en una reunión con pantallas del IE Tester y quejas varias de que la aplicación estaba hecha un desastre para IE 7.

Al final, no quise correr riesgos y terminé invirtiendo un tiempo que no me sobraba en que mis compañeros de soporte me instalaran y me desinstalaran los IE que necesitaba probar.

Quiero compartir la experiencia de uso de IE Tester, porque seguro que a alguien le sirve y le ahorra tiempo. 

Aplicación según IE Tester: 

Aplicación con IE 7: 

Aplicación como tiene que verse:

 

Como se puede ver, a pesar de que no tengo la captura de la misma pantalla, el aspecto general que nos da IE Tester de la aplicación es prácticamente el mismo que el que obtenemos en las pruebas realizadas directamente sobre el navegador IE 7.

No se carga la miga, ni el color de los laterales ni algunas imágenes.

Conclusión: para mí IE Tester es fiable.

Construyendo embudos de conversión

Una de las tareas más importantes de un analista web que trabaja para un e-commerce es optimizar el proceso de compra o embudo de conversión. Sabemos de sobra que no siempre es sencillo conseguir la implementación adecuada de la solución de medición.  A veces no es posible tener el etiquetado a tiempo y eso hace que sea complicado extraer  los datos. Obtener un informe  con un solo clic se convierte en una utopía y en la mayoría de las casos es completamente imposible utilizar los datos sin tratarlos primero.


En un e-commerce, una vez que hemos conseguido atraer al usuario a nuestro site, el proceso de compra es crítico y la optimización del proceso se basa en  construir un embudo de conversión que nos permita analizar los pasos del proceso y  detectar  puntos de mejora. ¿Parece sencillo? Pues generalmente no lo es tanto, en más de una ocasión el analista web debe buscarse la vida para llegar a conclusiones con lo que tiene disponible.

Podemos encontrarnos varios obstáculos en el camino:

- Páginas que forman parte del embudo y que se utilizan para otros menesteres. Por ejemplo, la página de inicio del embudo  usada como página de aterrizaje en buscadores para determinadas keyword.

- Es bastante común tener una sola página de error a la que se llega desde distintos puntos del proceso de compra. En un informe de rutas,  podemos volvernos locos y por supuesto un embudo es muy difícil de construir.

-Recargas de página que contamos como pasos en el proceso de comprar y que "contaminan" los datos reales. Si no tenemos cuidado al etiquetar, podemos encontrar más volumen en pasos más adelantados del embudo que en los iniciales.

A lo largo del tiempo que llevo como analista he tenido que buscar atajos  que me han permitido llegar a datos sólidos, análisis fundamentados y finalmente a recomendar acciones que eran para ayer.

Y  aquí van algunos truquillos que a mi me han servido a la hora de constuir mis embudos:

- No utilizar premeditadamente un paso del embudo como landing page, a veces será inevitable por el contenido indexado por SEO pero es necesario esforzarse para que esto no ocurra. Si te encuentras en esta situación, puedes "limpiar" los datos eliminado del proceso de compra el rebote de esa página, quitando las visitas que accedan a site por la página en cuestión y que no ven ninguna otra página del site.

- Crear una página de error distinta dependiendo del punto del embudo. Es más costoso de mantener, pero será mucho más fácil detectar de forma rápida que está pasando si uno de los errores sufre modificaciones.

- No intentar construir embudos asumiendo que un  paso del proceso es equivalente a una página vista. Las recargas de página pueden hacerte cometer errores.

postview o no postview, esa es la cuestión

Una de las preguntas más habituales en las canpañas online, es el retorno de la inversión que tiene remunerar el postview. En este post, voy a comentar mi opinión acerca de tener o no postview en un programa de afiliación. No creo que exista la receta mágica o la ecuación que nos pueda dar la respuesta. Lo que  pienso es que hay que ANALIZAR cada programa de forma INDIVIDUAL  y extraer las conclusiones de si nos interesa o no tener postview en cada caso.

No pretendo sentenciar, si el postview es bueno, malo o regular, Solo quiero lanzar al aire unos cuantos puntos sobre los que pensar y  analizar para que las personas que no estén muy familiarizadas con la gestión de un programa de afiliación o que se encuentren en la coyuntura de tener que lanzarlo, puedan valorar si les interesa mantener o incluir  el postview.

Probablemente, un programa de afiliación se  lanza con una buena dosis de recelo y bastante desconocimiento. Yo diría, que los anunciantes a priori, tenemos una postura que intenta ser conservadora y prudente a la vez que deseamos fervientemente maximizar las oportunidades que nos proporciona el marketing de afiliación. Por ejemplo, la cobertura que nos ofrece una red de afiliación es muy difícil conseguirla con acciones más tradicionales y además, en un pago por acción tenemos un  altísimo control de los costes de adquisición. Si el afiliado no consigue registros, ventas o el objetivo que le hayamos marcado, no cobra.

No es que a estas alturas no sepamos que el es marketing de afiliación, creo que hoy en día más o menos todos los profesionales vinculados al online tenemos una idea bastante clara acerca del tema, lo realmente difícil es conocer a los afiliados y su forma de trabajar. Con el paso del tiempo y muchas, muchas  pruebas  (con sus correspondientes errores en algunos casos) sabremos que afiliados son los que mejor rendimiento sacan a  nuestro programa y cuáles son los intervalos aceptables de comisión para cada modelo de trabajo en la red. No es lo mismo un afiliado dedicado a e-mail marketing que un afiliado que se dedica a comprar inventario invendido o que un afiliado que puja en buscadores. Cada uno tiene su especialidad y unos costes distintos asociados al canal por el que capta el tráfico y a con él a los potenciales clientes. Es absolutamente necesario conocer todos los segmentos o tipos de afiliados para ofrecerles una comisión adecuada y unas condiciones óptimas de acceso a nuestro programa.

La optimización de un programa de afiliación tiene dos fases principales, primero hay que estudiar a los afiliados y a continuación analizar los datos del programa. Volviendo al tema del post, necesitamos las dos patas para saber si nos resulta rentable tener remunerado el postview y en el caso de que la respuesta sea afirmativa, que comisión es rentable para ambas partes.

Antes de atacar a las métricas, me gustaría comentar algunos puntos que a veces se desconocen de los programas de afiliación y que afectan a la medición del postview.

- Las plataformas de afiliación disponen de tecnología para realizar el seguimiento de los registros o ventas distinguiendo si son transacciones directas, de postclick o de postview. La cookie de postview es distinta de la cookie de postclick.

- Dentro de la plataforma, suele haber normas estabecidas para atribuir el mérito de la conversión a uno u otro impacto publicitario si han sido necesarios más de uno para llegar a ella. Por ejemplo, si el usuario que realiza una conversión (registro o venta) tiene una cookie de impresión de un afiliado y una cookie de click de otro, la conversión se atribuiría al afiliado que logró el click. Podría decrise que se considera la cookie de postclick  más importante que la de postview.

- Es posible asignar una comisión distinta (habitualmente menor) a las conversiones que proceden de postview.

Teniendo en cuenta estos puntos, las posibilidades son muchas. Desde la más sencilla, que sería  tener en las transacciones de postview con una comisión más baja que en las transacciones de postclick o las directas,  hasta la que probablemente sea la mas compleja, el "comission split" que consistiría en atribuir una parte de la conversión (y por lo tanto de la comisión)  a cada uno de los intervinientes en el proceso de conversión teniendo en cuenta la aportación que cada uno ha hecho a la misma.

Para analizar el rendimiento del postview en un programa, hay varios factores a tener en cuenta además del tipo de producto y tipo de accción que estemos comisionando.

Por ejemplo, para mi una métrica muy importante es el porcentaje de transacciones en sesión respecto al total de transacciones de postview. Si un progama de afiliación tiene un postview de 24 horas, pero un porcentaje alto de las transacciones atribuidas al postview se realizan en sesión (dentro de los siguientes 30 minutos a la impresión) podemos concluir casi con total seguridad que en estas conversiones si ha intervenido la impresión mostrada.

Otra métrica a monitorizar es el porcentaje de duplicidades en las conversiones de postview. Debemos saber cuántas conversiones "se apuntan" dos o más soportes en cualquier caso, pero en el postview es crucial. Podemos encontrarnos remunerando postview a una conversión que tiene uno o varios esfuerzos publicitarios posteriores. La duplicidad no se dará dentro de la misma plataforma porque ya hemos visto que existen reglas para atribuir el mérito de la conversión a uno u otro impacto. Pero no tenemos controlado que sucede en soportes distintos.

duplicidades, debemos calcular si nos sigue resultando rentable pagar dos veces esa conversión o si por el contrario debemos crear un sistema de anulaciones para los registros/ventas que se encuentren en esta circunstancia.

La casuística es muy amplia y solo he intentado lanzar algunas ideas que permitan comenzar a investigar sobre el retorno de la inversión en el  postview.

Como conclusión: no debes fiarte de tu instinto si puedes medir, medir y medir para basar tus decisiones en datos.

MÁSTER EN ANALÍTICA WEB de Secuoyas Academy

Hace unas semanas me invitaron a impartir uno de los talleres del primer máster en analítica web que va a realizarse en España. Para mí ha sido un honor que Gemma Muñoz, (@sorprendida) quiera contar conmigo para este proyecto.

La analítica web es una nueva y pujante disciplina profesional, que se encarga  de medir el comportamiento de los usuarios en internet. Este máster esta creado para que profesionales del mundo de la tecnología o del mundo del marketing y la empresa puedan formarse en esta nueva disciplina profesional

Este nuevo perfil profesional se está convirtiendo en una pieza clave para las empresas de cualquier sector.

Espero que todos los que estéis interesados en la analítica web o el marketing online os apuntéis y aprendáis  todo lo que los estupendos profesores y colaboradores pueden ofreceros de su experiencia. Este es un trabajo emocionante, en el que no paras de aprender día a día en un entorno que no deja de cambiar. La mayoría de los analistas web que conozco, hemos tenido que formarnos de manera autodidacta porque no existía ningún curso de analítica web.

El programa del máster es muy práctico. Está basado en el modelo “ponte con,” que permite aprender a hacer las cosas observando sobre el terreno cómo se realiza la tarea, y no sólo desde un punto de vista teórico. El aprendizaje solo es posible cuando uno se enfrenta a un reto y lo intenta resolver. El máster tiene un gran número de  casos de Negocio y en uno de ellos participo yo misma.

He elegido el tema "campañas", porque en mi trabajo, me dedico a generar demanda en una compañía de respuesta directa y saber que aporta cada una de las campañas que ponemos online es fundamental.

Os dejo el enlace a la información del máster y espero veros esta primavera en Secuoyas Academy!

Ana (@ana_sopli)

El día a día de un analista web

Siguiendo el hilo de mi anterior post, me gustaría hablar un poco más de las funciones de un analista web. Hace poco, he tenido la necesidad de explicar a una persona nueva en mi organización  en que consiste mi trabajo y me he dado cuenta de que para las personas ajenas a la AW es difícil entender que hacemos "los frikis de Internet". Para mí,  es necesario aterrizar la teoría y bajarla  a  un día en la oficina. 

Mi resumen del WSAB (Web & Social Analytics Bootcamp) se basó en las diferentes etapas de un analista web a la hora de desarrollar su trabajo en una empresa.

 

1.       Definición de los requerimientos y objetivos  de negocio

2.       Elección de la solución de medición

3.       Explotación de la información

La mayoría de las personas que trabajamos en este mundo nos encontramos viviendo  2 o incluso las 3 etapas a la vez, con lo que las tareas no pueden hacerse en ningún orden predefinido. Para llegar al detalle concreto y contar que hace un analista web me voy a basar en mi experiencia, y como solo he trabajado vinculada a la analítica web en una compañía, doy por hecho que no todos los profesionales que se dedican a la analítica web tienen exactamente los mismos objetivos y/o responsabilidades. Creo que el analista web es un poco "prisionero" de la estructura organizativa que tenga de la empresa en la que trabaje y sobre todo del departamento en el que se encuentre ubicado.

Es un debate muy antiguo y muy de moda a la vez el que debemos poner en marcha para llegar a decidir a que departamento debería  pertenecer al analista web dentro de la empresa. Las opciones son múltiples: en IT, en Marketing en Negocio... Al tratarse de una figura relativamente nueva en el panorama laboral de nuestro país, casi nadie se atreve a sentenciar cuando opina cuál es la posición ideal para que el analista pueda desempeñar su trabajo con las condiciones óptimas.

En mi caso particular, pertenezco al departamento de Marketing con sus ventajas y sus inconvenientes. Como ya he comentado, últimamente he estado trabajando en la definición del objetivo principal de mi puesto de trabajo y la creación de un listado de tareas detallado para explicar que hago realmente en mi puesto de trabajo. Tras darle muchas vueltas, al final  creo que he sido capaz de definir el objetivo como "optimización del canal web".

Y en cuanto al listado de tareas,  me ha quedado dividido en cuatro bloques, dos de optimización: de tráfico y del site, uno de integración de datos y el último de operativa. A su vez, los cuatro bloques serán el paraguas para poder completar muchas vueltas al flujo de trabajo de AW: medición, análisis, segmentación y optimización.

Los tres primeros bloques (optimización del tráfico, optimización on site e integración multifuente), son las partes más puras de analítica y en principio las más interesantes mientras que el bloque 4 (operativa) es un poco más accesorio, aunque no por ello menos importante.

Centrándome ya en el primer bloque de tareas, contiene los análisis o reportes necesarios para  la optimización del tráfico que somos capaces de atraer a nuestra página web. Debemos tener en cuenta el volumen de tráfico, de dónde viene, cuántas veces viene, de qué campañas viene y cuáles son sus características. Además, en el primer bloque está incluida la parte de test, totalmente imprescindible en cualquier proceso de optimización.

El segundo bloque contiene los análisis de optimización del site. Deberemos entender el negocio al que se dedica la empresa y sobre todo el objetivo de la web antes de definir  que analizar para optimizar. Al igual que en el primer bloque, encontramos aquí el test, como no podía ser de otra forma.

He definido tareas muy generales: embudos de conversión,  usabilidad y contenido. En cualquier página podemos construir un embudo de conversión: rellenar un formulario, navegar por el contenido en un orden concreto, realizar una compra... Es fundamental localizar las tareas y las micro-tareas que deseamos que nuestros usuarios lleven a cabo con éxito.

He llamado integración multifuente al bloque 3 porque me parecía que quedaba bien y porque la analítica web no puede tener una visión completa acerca de lo que está pasando sin un poco de ayuda externa. Entiendo por fuentes externas los datos del Adserver, las bases de datos internas de la compañía, los datos de budget de las campañas online o cualquier otro dato que complete la información de la AW.

El último bloque lo compone las tareas que no se ven, las que no van con ppt a un montón de destinatarios y que a su vez son totalmente necesarias para poder realizar el listado de reportes y análisis de los tres primeros bloques. Probablemente no todos los analistas web tienen que cubrir todos los puntos de este último bloque, e incluso puede que algunos no se hayan parado a pensar cuanto tiempo invierten en tareas "no productivas" por llamarlas de alguna forma,  pero seguro estaréis de acuerdo conmigo en que es tan necesario un tag bien puesto como un análisis bien hecho.

A mí no me gusta pasar dos días creando url parametrizadas antes de lanzar una campaña, pero si no lo hago, resultará imposible medir, analizar, segmentar y optimizar.

Web & Social Analytics Bootcamp

Esta semana ha tenido lugar en Madrid el WSAB, Web & Social Analytics Bootcamp organizado por MV Consultoría.

He tenido la suerte de asistir y disfrutar de dos días de intensa formación y estupenda compañía. El WSAB ha consistido en dos niveles formativos de analítica web, uno para profesionales actualmente en activo en esta materia y otro para los futuros analistas que han podido aprovechar una oportunidad excepcional para iniciarse en este apasionante campo. 

Aunque a primera vista parecen dos grupos de personas con distintas necesidades formativas, en esencia  la formación ha sido muy similar. No nos han enseñado a analizar, ni a utilizar herramientas, si no que se ha intentado sentar  las bases para ser o convertirse en buen analista.

No pretendo enumerar las ponencias ni escribir un post que contenga todo lo que nos han contando,  voy a intentar escribir la parte que considero mas importante y que mas me ha gustado. Yo aterricé en el marketing online por casualidad y como la mayoría de los analistas web, me he formado de manera casi autodidacta en eventos, blogs y libros. El WSAB nos ha permitido ver una metodología, unos requisitos, unas pautas... en  conclusión,  un guión a seguir en el día a día de trabajo de un analista web.

En el mundo ideal, las tres fases a las que debería enfrentarse  un analista son las siguientes:

1.       Definición de los requerimientos y objetivos  de negocio

2.       Elección de la solución de medición

3.       Explotación de la información

Pero ya sabemos que el mundo ideal no existe, a veces el analista encuentra una solución de analítica web ya implementada,  donde los distintos departamentos de la organización no han definido sus requisitos o  no es posible obtener explotar la información por haber trabajado lo suficiente en las fases 1 y 2.

Dentro de la primera etapa de trabajo, existen varias tareas que en mi opinión, serán fundamentales para el éxito o el fracaso  la analítica web en la empresa:

Identificar: a las partes implicadas y consolidar los requerimientos.

Numerizar:  los objetivos de negocio a dimensiones y traducirlas a métricas objeto de análisis.

Documentar: los requerimientos de todas las unidades de negocio. 

Una vez finalizada la primera etapa, el analista se enfrenta con la elección de la solución de medición que se ajuste a los requerimientos recogidos en la fase 1. Durante esta etapa podemos enumerar las siguientes tareas.

Redactar:   documento de requisitos.

Supervisar:  el cumplimiento de requisitos en la solución elegida.

Coordinar: a los departamentos técnicos , legales de la organización y/o proveedores y socios tecnológicos.

Documentar:  todos los pasos y avances.

Al finalizar las fases 1 y 2 el analista está listo para sumergirse en la explotación de la información y el posterior análisis si previamente prepara el camino.

Definir: la estrategia de explotación de la información.

Implicar: a los destinatarios de la información.

Concretar:  los cuadros de mando y tableros de control.

Verbalizar:  las conclusiones a partir de datos aportados por la solución de medición.

Ya he dicho anteriormente que el mundo ideal no existe, pero teniendo estas pautas, el analista puede identificar en que punto se encuentra y adaptarse a las tareas de la fase que le toque vivir.

En mi opinión, la cultura de analítica web empieza aquí, en la capacidad del analista web para asumir y llevar a cabo sus funciones. Además, el analista debe ser capaz de transmitir y educar en analítica web a toda la organización.

Y por cierto, tras el WSAB y por petición popular, voy a eliminar "aspirante" de mi bio. Ya estoy preparada para definirme a mi misma como ANALISTA WEB.