Tras contrastar los resultados finales de las elecciones del Barça con los obtenidos de nuestro estudio 1 semana antes, sorprenden su alto grado de similitud.
Os adjuntamos todos los detalles otra vez aquí.
Enjoy!!
El pasado 8 y 9 de Junio 2010 tuvo lugar en el Palacio Municipal de Congresos de Madrid Expo E-commerce, un evento dedicado al comercio electrónico, donde se daban cita a todas las empresas dedicadas al sector, desde Tecnología hasta Marketing Online pasando por Relación con el Cliente, Logística, Aspectos Legales, etc.
Cuatro salas de conferencias con más de 50 ponentes nacionales e internacionales. Dónde se dio espacio para crear un debate sobre el sector y buenas praxis de la mano de los mejores expertos.
Estuvimos allí participando en una mesa redonda de “Analítica Web: Importancia de la medicion y control del ROI” La charla fue un éxito (medida por el grado de interacción entre los ponentes) y los asistentes salieron encantados, con ganas de medir los resultados.
Queremos dar las gracias a los organizadores del evento por la invitación a participar y por crear espacios donde aprender a mejorar el sector.
Gracias Ronan
Tenemos el honor de anunciar que somos partners de NedStat, una herramienta de medición web de pago que logra atender las necesidades de grandes corporaciones.
Después de haber realizado un curso en Amsterdam de 3 días, dónde nos atendieron de fábula (todo hay que decirlo) tuvimos que realizar un examen tipo de test. ¡Más difícil que el de Google! Hubo que estudiar mucho y hacer codos pero al final hemos pasado el examen y ya podemos utilizar y recomendar esta extraordinaria herramienta.
En primer lugar logra atender las necesidades de grandes empresas. Destaca sobre el resto porque no agrega los datos (dispone de toda la información del usuario con todo el detalle)
Eso hace posible elaborar análisis según se desee para cualquier solicitud, fecha, y segmento.
Para visualizar la información provee de 2 funcionalidades clave: ReportBuilder con el que se puede construir cualquier vista de datos y el Live Segmentation que facilita la selección de cualquier tipo de usuario.
Con ReportBuilder se pueden adaptar los informes a las necesidades, combinando cualquier métrica y dimensión. A través de la característica ‘Calcular’, se pueden añadir métricas personalizadas en la interfaz del usuario.
Los datos externos, como el API o datos importados de la base de datos pueden ser incluidos como variables en los informes, enriqueciendo el entorno de análisis web con datos offline (incluye integraciones “plug and play” con tools claves de emailing, CRM, SEM, etc)
Sus funcionalidades estrella y por encima de sus competidores son el “cálculo costumizable de la atribución” para campañas y el cálculo a medida del “engagement“
En este sentido Sitestat proporciona la libertad de elegir entre 10 modelos de atribución para las campañas, como los de obvios, como primer clic, clic en última o la atribución compartida igualmente, o más avanzados como linealmente creciente o decreciente en el tiempo. La más avanzada es la participación del visitante o engagement, en la que el nivel de interés y la interacción del visitante determina la atribución por canal.
Eso hace superar a los softwares que sólo atribuyen crédito a la última campaña y niegan créditos para otras campañas existentes en el proceso de decisión del usuario. Además permite comparar fácilmente los distintos modelos de atribución, lo que le permite encontrar rápidamente la asignación más eficaz de su presupuesto de marketing. Es decir, una vez seleccionado un método de atribución no queda fijado sino que en segundos podemos volver a cambiarlo por otro más adecuado o compararlos cara a cara, como se muestra en la imagen.
Finalmente destaca además por su sistema de seguimiento de contenidos streaming (videos, audio, etc) que ha hecho que muchos canales de televisión europeos escojan esta herramienta para sus presencias online.
Además, esta herramienta fue de las 4 mejor valoradas por Forrester en ‘09 y es una de las importantes en Europa.
Lo dicho, a partir de ahora ya nos podéis encontrar aquí
Imaginemos que tenemos un site de ecommerce que queremos medir con Google Analytics. Uno de los pasos obligados es instalar el tag de ecommerce en el paso de confirmación de compra. Con esto conseguiremos entre otras cosas tener una estimación de nuestras ventas, conocer los productos más vendidos, y averiguar el tiempo y el número de visitas que necesita un usuario para realizar una compra.
Como vemos, instalar el tag de ecommerce nos aporta una gran cantidad de informaciónvaliosa que nos puede ayudar a mejorar nuestra web (que es para lo que queremos Analytics).
No obstante la instalación del tag de ecommerce no está exenta de problemas. En este post hablaremos sobre uno de ellos, el envío de transacciones duplicadas.
El tag de ecommerce se suele colocar al final de una transacción realizada con éxito. Idealmente solo debería ejecutarse una vez por transacción pero, ¿qué sucede si el usuario recarga la página o guarda el link en favoritos y meses más tarde vuelve a la página? El resultado es que la transacción se vuelve a enviar, con lo cual estamos mandando una transacción “fantasma” o inexistente. El problema se agrava si la página de confirmación es lenta en cargar (porque se queda esperando algún componente), en este caso el usuario puede intentar recargar la misma más de una vez con lo cual nuestras estadísticas se estropearán.
Para evitar que esto suceda, podemos aplicar alguna de las soluciones siguientes:
Solución #1: Usar una cookie para almacenar el valor de la última transacción.
La idea es almacenar en una cookie de sesión el valor de la última transacción enviada. Antes de ejecutar el tag de ecommerce preguntamos si el id de transacción actual coincide con el último id de transacción enviado y, si es así, no realizamos el llamado.
De esta manera nos aseguramos de no enviar nunca transacciones duplicadas, el algoritmo que serviría para implementar esta solución sería:
…Llamado a ga.js y pageTracker…
Solución #2: Añadir a cada id de transacción un número aleatorio
De esta manera, se puede identificar en el Analytics las transacciones duplicadas y la fecha en la que se realizó. Esto nos permitiría detectar un problema que se esté produciendo con nuestras páginas de confirmación, cosa que con la primera solución no sería posible. No obstante, al enviar transacciones repetidas al Analytics, estaremos estropeando los datos del ecommerce con lo cual tendremos que exportar los datos y tratarlos con otra herramienta para analizarlos correctamente o aplicar un filtro de sustitución para unificar los valores.
Solución #3: Controlar, mediante programación de servidor, que no se envíen transacciones duplicadas.
Esta solución implica que se tiene acceso a la base de datos donde se almacenan las transacciones y se puede modificar la misma.
La idea es activar un campo en la base de datos que, para cada transacción realizada se compruebe si se mostró la página de confirmación y por tanto, se envió el tag de ecommerce.
Al cargar una página de confirmación, se comprueba si la transacción actual tiene la marca de enviada/mostrada activada, si es así, no se carga el tag de ecommerce.
Esta solución es probablemente la más segura a la hora de evitar el envío de transacciones duplicadas, ya que también nos sirve para controlar los accesos desde emails o en sesiones diferentes. El problema es el nivel de acceso que debemos tener para poder modificar la base de datos.
Solución #4: Asociar una marca de tiempo a cada id de transacción
Como hemos visto en las soluciones anteriores, uno de los inconvenientes que comparten es¿cómo controlar las transacciones que se producen meses después de la original?, por ejemplo cuando un usuario mira un mail de confirmación semanas después de la compra y pincha en el enlace.
La idea consiste en asociar a cada transacción una marca de tiempo o time stamp, de forma que automáticamente el sistema descarta las transacciones cuya diferencia temporal sea mayor de 30 minutos (una sesión).
Esto resuelve el problema de duplicados que se producen por mails de confirmación enviados, o cargas de páginas guardadas en favoritos.
Los 6 productos restantes son el resultado de recargar la página de confirmación. Google Analytics ha agregado todo en una misma transacción, ya que se han producido todas con el mismo ID=1234 al actualizar la página de confirmación.
Como decíamos, el problema es identificar cuando es un problema de recarga y cuando no (¿quíen nos dice que no se ha realizado un pedido de 7 camisas?)
Evidentemente la única forma de determinarlo es verificando los datos de Analytics con los datos de nuestro gestor de pedidos de forma que podamos detectar posibles discrepancias en los datos.
Por último, en el caso de que queramos librarnos de transacciones duplicadas, Google proporciona una forma de eliminar datos de transacciones dentro del Google Analytics.
Esperamos que estas soluciones te sirvan para mejorar tus estadísticas y tus datos y te animamos a que compartas con nosotros otras posibles soluciones que estés aplicando.
E-commretail Show es el primer salón de España dedicado exclusivamente al comercio electrónico y al negocio online. Se celebró en Barcelona los pasados 15 y 16 de abril.
Como no podía ser de otra manera Multiplica y Metriplica, estuvieron allí con un estand y para deleitar a los presentes, con una estupenda conferencia de nuestro director de Metriplica Enric Quintero, dónde contó algunos trucos para medir los resultados de tu web.
La verdad es que fue todo un éxito y estamos contentísimos que se empiecen a realizar ferias de este tipo en nuestro país.
Os dejamos unas fotillos a continuación
En el número de mayo de la revista e-commretail, Enric Quitero también conocido como Doctor Metrics, nos habla sobre el web mining como evolución de las herramientas de analítica web, desde el uso de herramientas meramente pasivas que nos dicen qué está sucediendo en nuestro site hacia herramientas activas que permitan además tomar acciones en base a esta información…
“Una de las grandes ventajas de internet como canal es que permite a cualquier tipo de anunciante independientemente de su tamaño, interactuar con una audiencia de usuarios que crece exponencialmente y que cada vez realiza más transacciones de todo tipo.”
Seguir leyendo (en e-commretail)
¡Sorpresa!
Tengo que admitir que estoy algo sorprendido. En un post reciente, Avinash Kaushik nos habla de “la poca capacidad estadísitca” como causante de la mayoría de los miedos, dudas y desconocimientos existentes alrededor de la Analítica Web. Concretamente, en el post se menciona la poca capacidad para “cambiar de paradigma“, y que tal cosa es triste y frustrante. Evidentemente que lo es; Avinash, estoy contigo.
El caso de Google Analytics
Para darse cuenta de esto, no hay más que ver la flamante funcionalidad (todavía beta) de Google Analytics “Intelligence“. Toda esta inteligencia se reduce al cálculo de algunos intervalos de confianza para obtener cambios estadísticamente significativos. Perdonad mi tono sarcástico, pero en ningún momento he pretendido serlo: esta funcionalidad es la primera que hace inferencia estadística, es decir, es la primera que toca temas de predicción. Efectivamente, el cambio de paradigma se aproxima. Lento, pero se aproxima; y eso nos emociona. Éste es un tema que desde Metriplica llevamos tiempo pensado y meditando.
Aplicando la regla 20/80
En el post anterior ya dimos algunas primeras indicaciones para producir dicho cambio de paradigma en los tests mutivariantes: los podemos hacer inteligentes. Tal cambio supone una inversión (sobretodo mental) en capacidades matemáticas y estadísticas. Éste es el momento de aplicar la famosa regla 20/80 del mismo Avinash: 20% de inversión en herramientas y 80% de inversión en personas. El cambio de paradigma tiene que incluir, a la fuerza, una apertura de la analítica web hacia el mundo estadístico-matemático.
¡Pero la cosa no termina aquí!
Pero mi sorpresa no acaba aquí. Kaushik piensa que, debido a la gran complejidad de datos y su diversidad, los esfuerzos de minería de datos suelen fracasar y no arrojan soluciones de gran valor añadido en comparación a los costes que tienen. Esto, bajo mi punto de vista, vuelve a ser un punto que genera miedos, dudas e inseguridades. Como él mismo dice en el post, debemos hacer uso de lo que tenemos. Podemos recoger datos mediante tags de javaScript, mediante snippets en PHP, etc. Podemos integrar datos usando herramientas gratuitas y muy potentes estilo Pentaho. El coste que tenemos es únicamente de personal, ya que herramientas hay muchas, muy buenas y algunas son gratis. Matemáticos y estadísticos los hay a montones. Seguimos estancados en un paradigma en el que la Analítica Web no acoge a la comunidad matemática. Es decir, seguimos estancados en una mentalidad reactiva y en ningún caso proactiva.
Y nosotros, ¿qué aportamos?
Por suerte, Metriplica ya ha cambiado su paradigma, y estamos convencidos que ésta es la manera de seguirle la pista a la rápida evolución de la web. Podemos hacer tests multivariantes más inteligentes, podemos testear precios con un control estadístico riguroso por detrás, podemos personalizar, etc. Realmente estamos otro pasito más cerca de la web inteligente utlizando complejas técnicas estadístico-matemáticas.
Ya habíamos comentado desde Metriplica que las e-empresas en España se encuentran en el nivel de madurez necesario para dar el paso hacia el Webmining, y más concretamente hacia los contenidos personalizados. Para centrarnos un poco, quería hablaros de una nueva manera de hacer tests multivariantes.
¿Qué teníamos hasta ahora?
Imaginémonos la siguiente situación: tenemos una landing page que nuestras métricas indican que debemos mejorar. Pensamos una serie de alternativas para cada sección y acabamos con una serie de recetas que vamos a testear. En este punto, y como es habitual y obligatorio, nos disponemos a pensar a quién vamos a dirigir el test: 80% del tráfico, tráfico proveniente de orgánico, directo, etc.
¿Qué problema tiene?
Con esta mentalidad, estamos tratando a todos estos usuarios por igual (en terminología del post anterior, nuestros clusters son, en este caso, las fuentes de tráfico) y obviamos el hecho de que hay usuarios que sí compran con el diseño actual. Diversas técnicas de Data Mining nos ayudan a identificar este segmento (clasificadores Bayesianos, Árboles de decisión, etc.). La pregunta está clara: ¿por qué no mantenemos a este segmento la versión original? La respuesta quizás pase por temas de programación. Nos dirán que hay que tocar la programación de la página, más allá de insertar simples tags del Google Website Optimizer. Estamos convencidos, y la experiencia así nos lo demuestra, que la ganancia final supera con creces al esfuerzo que hay que hacer de programación, que no va más allá de insertar una serie de condicionales antes de los tags.
No hay vencedores ni vencidos
Una vez acabado nuestro test, nuestro software nos da un “ganador”. ¿Ganador? En media sí lo es, pero en ningún caso se trata de un ganador absoluto. “El 50% de los usuarios que convirtieron lo hicieron con la receta “ganadora”. Eso significa que el otro 50% convirtió con otras recetas. Nuevamente, aplicamos los algoritmos de Data Mining que nos identificarán los segmentos para los que una determinada receta les gusta más. Entonces, en vez de hablar de un “ganador”, hablaremos de diversos ganadores. Es decir, el concepto de ganador cambia a encontrar receta(s) que satisfagan a un cierto número de usuarios dentro de los segmentos.
Esta técnica, además, minimiza el impacto que tiene, para los segmentos identificados, el hecho de cambiar de diseño cuando vuelven a entrar: si la muestra ha sido significativa y hemos programado nuestra página para detectar esos segmentos y mostrar la receta correspondiente, se les mostrará la receta que les gustó, con la que o bien convirtieron o están dispuestos a convertir.
¿Qué tengo qué hacer si no quiero programar?
Antes comentamos que el esfuerzo de programación que debemos hacer para reflejar los cambios que los algoritmos nos proponen pasa por implementar una serie de sentencias condicionales, para hacer coincidir el segmento del visitante con el del algoritmo. Pues a este respecto tenemos muy buenas noticias. Navegando por la web hemos encontrado una herramienta, BTBuckets, que permite crear segmentos de usuarios y tomar acciones sobre ellos en tiempo real. El esfuerzo de programación que debemos hacer para habilitar esta herramienta se reduce a insertar un tag en nuestras páginas.
¿Es lo mejor que puedo encontrar?
A pesar de que los segmentos que permite crear son un tanto limitados, nos da un punto de partida, fácil y gratuito a la personalización de contenidos por segmentos, y hace que nos pique la curiosidad para que comencemos a utilizar algoritmos de Data Mining que nos dé los segmentos basados en conocimiento, y no en intuición. Del resto, al menos en una fase inicial, se puede encargar BTBuckets.
¿Hacemos un ejemplo?
Y para muestra un botón. Hemos hecho de conejillos de indias y hemos probado esta herramienta con nuestro site. Hagamos el siguiente experimento: vayamos a la página de consultores autorizados de Yahoo!
Clica sobre el link hacia la página de Metriplica (el número 103). Observa que el link es hacia la home. Pero ¡sorpresa! Hemos ido a parar a la página que ofrece nuestros servicios de consultoría de Yahoo! Analytics.
¿Cómo? Pues hemos creado un Bucket que indica que si un usuario viene de la página de Yahoo! Analytics salte directamente hacia la página de servicios con Yahoo!
Igualmente, si esto sigue sonando a ciencia-ficción, no tienes más que contactarnos.
Desde hace varios meses Google Analytics dispone de una nueva opción a la hora de implementar su tag en una página web, el llamado seguimiento asíncrono.
¿Por qué complicar las cosas entonces? ¿a qué necesidad responde?
El dilema al insertar un tag
A la hora de instalar una herramienta de análisis web basada en marcadores (tags), como Google Analytics, debemos introducir en cada una de las páginas a monitorizar un pequeño código javascript.
La duda que nos asalta en este punto es ¿y dónde pongo el tag dentro del código de mis páginas?
Opción 1: antes del cierre del “body”
La recomendación siempre ha sido situarlo dentro del código html de cada página, antes de la etiqueta /body
Opción 2: dentro del “head”
Una posible solución al problema mencionado en la opción 1, en la que poníamos el tag abajo del todo de la página, es situarlo arriba del todo de la misma. Más concretamente, dentro de la sección head del código html de la página.
Observando los problemas que puede dar la opción 2, parece más grave la cura que la enfermedad.
¿No existe otro método que tenga impacto mínimo en la carga, tenga efectos negativos en la carga de mis contenidos?
La solución el código Asíncrono
La respuesta está en el modelo de objetos de documento (DOM), una tecnología que permite modificar dinámicamente documentos HTML. Muchas de las nuevas herramientas e interfaces de programación (API) como jQuery y Ajax están basadas en el DOM.
La clave para lo que buscamos está en que, cuando se carga y ejecuta un documento interpretable mediante las herramientas del DOM, aquél proceso no detendrá la ejecución del documento principal, sino que se llevará a cabo de forma paralela.
Y ahora ¡¡ya podéis probarlo!!
El método asíncrono funcionará sin ningún problema en la gran mayoría de los sitios, simplemente hay ciertos cambios en su implementación con respecto al método tradicional.
Os invitamos a comprobar su funcionamiento. Lee las instrucciones de migración.
Si eras de aquellos que descartaba el uso de Google Analytics por considerar que la carga de ga.js perjudicaba el tiempo de carga y despliegue de las páginas de tu sitio, ésta es la gran oportunidad para dejar atrás los temores y dar el salto con la mejor herramienta del mercado.
Google Search Suggestions, es una herramienta de Google que nos propone un listado de las 10 consultas más populares y recientes en base a una palabra introducida en el buscador (al menos esta es la teoría ya que no se han revelado los detalles del algoritmo que lo hace posible).
Además, esta herramienta es lo suficientemente inteligente para mostrar resultados en función de la versión del buscador que se esté utilizando e decir, no sugerirá las mismas consultas si utilizo google.com frente a google.es
Búsqueda en Google.es
Búsqueda en Google.com
La suposición en la que se basa esta herramienta es que, en general, todos tenemos inquietudes similares y por tanto si tú comienzas a realizar una búsqueda para comprar entradas por ejemplo, es razonable pensar que esa búsqueda esté relacionada con otras búsquedas frecuentes realizadas por otros usuarios.
¿Y para que nos vale todo esto? Pues nos vale porque en definitiva, Google Suggestion es una “ventana” hacia la manera en la que los usuarios realizan las búsquedas y nos indica sus necesidades de información, lo cual es tremendamente útil para los que nos dedicamos a optimizar contenidos webs.
Por ejemplo, imaginemos que tenemos una web que vende entradas para espectáculos y estoy planeando los contenidos que debería destacar en la home. Como podemos ver gracias a la figura 1, tanto la Alhambra, Luna nueva como el Real Madrid, y las entradas para la champions del 2010 parecen ser contenidos muy demandados.
Esta información, puede orientarme hacia qué contenidos destacar en mi home así como sobre qué términos de adwords debería comprar para tener más probabilidad de atraer tráfico hacia mi web (asegurando siempre que las expectativas del usuario se vean cumplidas).
Además, hay que tener en cuenta que estas sugerencias se van actualizando a lo largo del tiempo, lo cual es perfecto para ir evolucionando nuestros contenidos en función de las necesidades de los usuarios.
Como final del post, quiero mostrar algunos resultados curiosos que podemos encontrar utilizando el search suggestion …
Descubrir qué nos preocupa
O responder a la pregunta de ¿cómo “somos” los españoles?
Y por último, se han preguntado de qué tenemos miedo…
Una vez más parece que el amor y sus consecuencias están entre nuestros principales temores…
Les invito a que prueben sus propias consultas, es realmente adictivo.
