Antes de hacer un sitio web conviene valorar y evaluar que se hace y como en el sector específico en el que nos vamos a desenvolver, porque para cada tipología de sitio web, y según su perfil de usuarios, suele haber un estandar, no declarado, de diseño, de mensaje, de presentación de producto en la web. Y ese estandar solo se descubre a base de visitar y revisar sitios web de la misma temática o relacionados con aquel que queremos desarrollar.

Siguiendo esta premisa, me propuse encontrar el “estandar” que se emplea en el ecommerce español para lo relativo a las llamadas a la acción, sobre todo a aquellas relacionadas con la compra, con el clic que conduce al inicio del proceso de compra.

La llamada a la acción (al inicio del proceso de compra) es algo crítico en cualquier ecommerce, porque es parte fundamental del objetivo básico: vender

Para tener una base homogénea sobre la que valorar, recopilé 100 sitios web de ecommerce partiendo de varias webs de eventos de comercio electrónico (eComm Retail, Expo Ecommerce, Feria de tiendas virtuales de Walqa) en los que muchos ecommerce se dan de alta para concursar o para dar visibilidad a sus proyectos.

Y fruto de ello, salió esta lista de 100 comercios electrónicos (la mayoría españoles o su versión española) en la que me base para realizar un miniestudio sobre ese aspecto crítico que es para cualquier ecommerce la llamada de acción a compra, el botón de “comprar”, “añadir a mi cesta”, etc.

Quería ver cual es el estandar del mensaje de la llamada a la acción a compra, el color más empleado para los botones de acción y cuestiones de ese tipo, muy importantes para el clic del usuario que desencadena todo el proceso de compra, que es el verdadero objetivo (bueno, el objetivo es que se termine al 100%).

Sin entrar a valorar, los resultados de este estudio sobre estos 100 ecommerces son:

Color del botón principal de llamada a la acción (compra) en ecommerce:

Distribución del color del botón de acción principal en los ecommerces analizados

Como puede apreciarse, el “reparto” de los colores elegidos para los botones de acción a compra en ecommerce es:

1. Naranja – 23%
2. Rojo – 16%
3. Verde – 16%
4. Azul – 15%
5. Gris – 10%

Esto en cuanto a los 5 primeros elegidos, que supone un total del 80%. El naranja es el color más empleado para los botones de acción a compra, y aunque pueda parecer una opción lógica, ya que parece ser que es el color más vinculado al clic impulsivo, no debemos perder el norte, y recordar que hacer un elemento más clicable no significa que el proceso completo de compra (que es lo que realmente nos interesa) se lleve a cabo con éxito, simplemente significa que ese elemento, esa parte del proceso es más clicable o atractiva.

Lo del gris llama la atención, porque supera a otros colores, como el rosa o el negro, y es un tono realmente aséptico y de dificil contraste, la verdad.

Texto de la llamada a la acción en ecommerce:

En este caso, las llamadas a la acción se caracterizan por contener habitualmente esta serie de palabras como componentes de su mensaje:

1. Contiene “añadir” – 33%
2. Contiene “comprar”- 26%
3. Contiene “cesta” – 20%
4. Contiene “carro” o “carrito” – 15%
5. Contiene “ahora”- 3%

Por lo que el mensaje tipo para iniciar el proceso de compra puede deducirse que es, generalmente, “añadir a la cesta”, “añadir al carrito” o “comprar”. Llama la atención la poca presencia de adverbios como “ya” o “ahora”, solo presente en un 3% de las llamadas a la acción, y realmente importantes para generar cierta sensación de urgencia o premura en el usuario.

Tamaño del botón de llamada a la acción:

Para entender mejor como se reparten los tamaños de botones de acción a compra en ecommerce, es más fácil verlo de esta otra forma, con los porcentajes entre los arcos de tamaño de los botones tal y como son a escala real:

Asi se ve el reparto de los tamaños de botones de compra en ecommerce en relación a su tamaño real

Lo más llamativo es desde luego que el 32% de los ecommerces den tan poco protagonismo visual a un elemento, el botón de compra, que es crucial en el proceso que pretendemos que el usuario complete al 100%. De hecho, en el caso más “extremo” nos encontramos con un botón de tan solo 26×18 píxeles, el más pequeño, y que apenas es visible, siendo su protagonismo robado por otros múltiples elementos gráficos de mayor tamaño.

Así que, como podeis ver, si que parece, tras observar las landing pages de producto de 100 ecommerce, que si hay un pequeño estandar en lo relativo a botones de compra y llamadas a la acción, que podría resumirse en un botón de unos 100×40 píxeles, de color naranja, con el texto “añadir a la cesta”. Otra cosa es si esa es la mejor opción para un ecommerce o por el contrario, como es recomendable, cada uno debe buscar sus propias llamadas a la acción, lenguaje y colores y protagonismo visual, según el usuario al que nos dirijamos.

El mercado esta lleno de herramientas para realizar test A/B. Aunque lo más importante es pensarlo bien, el para que, no el como.

Las herramientas pueden variar, pero lo realmente importante es siempre la claridad de ideas y que un test sea algo que realmente tenga utilidad, no un divertimento. Sí, me repito y digo esto mucho, pero es necesario que eso quede muy claro. La herramienta es siempre secundaria, lo otro no.

Y dicho esto, hoy día la oferta de herramientas para testing web es extensísima, pero, bien por conocimiento directo, bien por referencias de garantía o por sus características, aquí teneis las principales herramientas de testing A/B y también multivariente del mercado, entre otras, a las que puede merecer echarle un vistazo en condiciones:

Google Website Optimizer

Sin lugar a dudas, Google Website Optimizer el la herramienta de A/B testing y multivariante más popular. Ideal para comenzar en este mundillo del testing por muchas razones, su uso es realmente sencillo, mediante la inclusión de un pequeño fragmento de código javascript en la página original y en aquellas que conforman el test. Además, al ser validado todo el proceso paso a paso, en caso de que hagas algo mal el mismo Optimizer te pone sobre aviso. Permite ofrecer diferentes alternativas de diseño de una landing page (A/B test) u ofrecer variantes del contenido (imágenes, copys, etiquetas h, etc) dentro de una landing page (multivariante). Puede utilizarse tanto para A/B testing como para multivariantes y permite, entre otras cosas, distribuir tráfico entre versiones de página a testear. No tiene coste y además hay una guía avanzada de uso de Optimizer muy recomendable si ya tienes exigencias de medio-alto nivel.

Visual Website Optimizer

Visual Website Optimizer, a diferencia de Google Website Optimizer, ya es una herramienta que ofrece una serie de características más extensas (a su precio, es de pago en función de las visitas a testear y la versión gratis permite testaera sobre 1.000 visitantes). El funcionamiento es similar, como en todas, con el uso del consabido javascript que se debe incluir en las versiones originales y alternativas. Lo que Visual Website Optimizer si ofrece diferente, entre otras cosas, es: segmentación por keyword (muy interesante, según la keyword de entrada enviar a una u otra landing), mapas de calor y clicks de los tests, capacidad para hacer test sin saber nada de código y muchas otras características.

Sitespect

SiteSpect presenta muchas características similares a las herramientas ya vistas (test simultaneos, orientación de tráfico a test por keyword, URL de origen, etc), pero se centra en dos puntos principales en los que ofrece algo característico: generación de test de manera automática, con contenido generado en base a target de comportamiento para identificar la mejor combinación posible y la ausencia en determinados test de implementación manual de JavaScript.

Unbounce

Sin duda el gran valor añadido de Unbounce, lo que suma frente a las características de las otras herramientas, es su tremenda facilidad de uso y la cantidad de plantillas preconfiguradas que ofrece tanto para crar landing pages como para la generación de páginas de leads. En apenas unos minutos puedes tener listas landing pages alternativas sin necesidad de diseño ni desarrollo propio. Lógicamente eso tiene su limitación creativa, etc, pero es tremendamente util para contrastar modelos genéricos o alternativas de forma rápida y ágil.

Vanity

Vanity es un framework para hacer ejercicios de testing web con Rails. Facilita una API para ser desgcargada y un manual extenso en PDF con detalles de como utilizarlo. Es un sistema de testing basado mucho en el uso del código por parte de los desarrolladores, pero parece bastante ágil y con buenas capacidades de alternativas de cara a plantearle opciones al usuario.

Vertster

Vertster centra sus virtudes, y diferencia con otras herramientas, en el tipo de informes que ofrece durante y en la conclusión de un test, con muchas variables de segmentación, como la franja horaria, día de la semana, y otros valores de segmentación, que son empleados para determinar que modelo de landing page funciona mejor para cada uno de esos posibles segmentos, lo cual acaba configurando un mapa de posibles elecciones muy orientado a segmentos específicos de usuarios. Por supuesto, ofrece otras muchas cosas, pero muy similares a cualquier otra de las herramientas vistas. También se centra en la NO necesidad del uso de tags, etc, y que con la inclusión de un único JavaScript, el resto de funcionalidades pueden ser controladas, sin necesidad de actualizaciones FTP de archivos, etc.

Optimizely

De todas las opciones de pago en lo referente a herramientas de testing de este tipo, Optimizely parece ser una de las más completas por las múltiples y completas posibilidades que ofrece. Además de, al igual que Vertster, ofrecer una sola línea de JavaScript para controlar los tagas, etc, ofrece una interfaz muy visual para el cambio de elementos, incluso permitiendo drag&drop, y otras muchas funciones, como testeo múltiple. Quizás lo más interesante sea la posibilidad de hacer edición avanzada de código, seguimiento múltiple de objetivos según las landings pages que se quieran optimizar, y un amplio abánico de opciones en ese sentido que lo convierten en una de las opciones más serias y profesionales por la cantidad de características que ofrece.

WordPress A/B testing plugin

Por un precio de 9.95 $ USA, los chavales de WPPlugins (un interesante marketplace de plugins de WordPress) nos ofrecen este plugin de pago que permite, básicamente, hacer tests A/B para WordPress tomando como base el ofrecer al usuario diferentes versiones del sitio web variando el tema. Es decir, tenemos un sitio web desarrollado con WordPress y lo que hacemos con este plugin es cargar 2 o más temas (con lo cual puedes introducir cambios en base a un tema que tú mismo hayas desarrollado) que son mostrados aleatoriamente a los usuarios, lo que nos permite deteminar cual de esos temas ofrece un mejor rendimiento. Desde luego, es muy limitado en cuanto a funciones, pero también es cierto que por su precio y para hacer testing de este tipo en WordPress es algo de lo más útil, por básico que sea. Más aún si tenemos en cuenta que otros plugins gratuitos de funciones parecidas no funcionan nada bien. Muy muy básico, pero util si trabajais mucho con WordPress.

A/Bingo

La principal característica de A/Bingo es similar a la de Vanity. A/Bingo es un framework de testing A/B para ruby on rails que funciona como un plugin en este entorno de desarrollo web. Lógicamente A/Bingo es open source y está muy orientado al entorno de la programación, con lo que puede ser una muy buena manera de que los desarrolladores habituados a ruby on rails se introduzcan en el mundo del testing.

LiveBall

LiveBall tiene una pinta tremenda, y un precio en consonancia. Lo que LiveBall ofrece es una solución de testing a grandísima escala y pensada para landing pages en múltiples idiomas, y con una cantidad de variables a manejar enormes. Incorpora prácticamente la posibilidad de editar cualquier aspecto concerniente a una landing page, desde su URL, hasta la totalidad de su contenido, optimización y generación de landing pages para dispositivos móviles, orientación 100% pensada en SEO. Por incorporar, incorpora hasta variables de lógica de comportamiento por las que podemos definir la presentación de una landing page tomando como referencia el pais de procedencia del usuario, el día de la semana en que estemos, la cadencia de visita del usuario… En fin, una solución que, en la teoría, prácticamente aglutina y mejora todas las características de todas las herramientas de testing conocidas y por conocer. Es una solución, por precio y características, orientada a sitios web de caracter internacional y multiidioma y compuestos por miles y miles de páginas. No conozco a nadie que la haya usado, pero estaría encantadísimo de tener alguna opinión real sobre LiveBall para ver si realmente responde a las expectativas.

Genetify

Genetify es una solución de testing bastante enfocada a desarrolladores y pensada para poder testear alternativas en diferentes elementos de una landing page, desde el CSS hasta cualquier etiqueta de HTML. Puede utilizarse con la inclusión de un simple script y de manera remota o instalando en nuestras propias máquinas si ya tenemos necesidades concernientes a sitios web con volúmenes de tráfico bastante altos.

MaxTEST

MaxTEST parece una solución de testing muy interesante cuando lees cosas como que permite, entre otras cosas, el testing del contenido generado por el usuario para determinar su calidad, testing múltiple de procesos de compra online, etc… cosas que llaman la atención, que parecen interesantes, pero que no vienen nada explicadas en su presentación, que además debes descargarte facilitando tus datos de contacto, WTF! (si no, lo que puedes leer -el enlace- es una decripción muy genérica). A pesar de ello, por lo poco que se cuenta, parece una opción interesante, aunque se agradecería más claridad y extensión en como funciona y en sus características propias.

Hubspot

La solución de testing de los populares HubSpot no ofrece nada excesivamente nuevo que no hayamos visto antes en otras herramientas, pero si que incide en algo muy interesante: los leads. Todos los que hemos trabajado con captación de leads en internet sabemos de sobra lo importante de la optimización en este tipo de landing pages, y la solución de HubSpot se centra en ofrecer sincronización entre la captación de leads del sitio web con el CRM de la empresa, lo cual es una nota muy característica e interesante que hace que valga la pena curiosearlo.

Test&Target

Test&Target es una solución que ofrece un abanico de opciones de lo más jugoso para todo lo relativo al testing, y por supuesto, se integra a la perfección con las herramientas de analítica web de Omniture, por lo que es la opción más clara para los clientes de la marca. Test&Target, entre otras muchas opciones, ofrece la posibilidad de testear el contenido no solo de sitios web, sino de emailings o publicidad de display, también permite diversificar tráfico por variables como geografía, uso horario y otras opciones. Una opción muy interesante es el aprendizaje automático predictivo, lo que permite extraer información detallada de los segmentos de usuarios que han interactuado con las diferentes opciones de landing pages presentadas. Una solución tremendamente completa con muchísimas opciones y funciones, que en el caso de Test&Target 1:1 ya alcanza el summum de la optimización, que es la personalización y adaptación de elementos web de manera individual, usuario a usuario, ya que se almacena con un ID único la interacción de cada usuario para ofrecerle variables personalizadas según su comportamiento o directrices definidas.

Y para terminar, todas estas herramientas ofrecen vídeos de su funcionamiento y también la posibilidad de disponer de una demo (bien de forma directa o bien bajo petición), lo que realmente es la única forma de valorar (probándolas) si nos sirven o no para nuestros propósitos. Así que ya sabeis… revisad vuestros sitios web y testing time!

Tras ese primer post, ahora le toca el turno a este, en el que trataré el tema de como planificar un test A/B y como utilizar una metodología básica, una guía que sirva para que este tipo de test nos de los mejores resultados e información posibles, independientemente de las herramientas con que se realice.

Lo más importante de un test A/B está en su planificación, en su metodología en como hacerlo y, sobre todo, para que.

Este tipo de test son una herramienta de mejora de gran valor, pero deben realizarse en un marco concreto, siguiendo unos mínimos pasos y, sobre todo, por una razón de peso y buscando precisamente esa mejora, pero no como una acción de entretenimiento o de prueba porque sí.

Como puede verse en esta gráfica de Optimizer, un test A/B puede comenzar con una versión dando muy buenos resultados para luego cambiar radicalmente. De ahí la importancia de tener un método, una guía, que de consistencia a la prueba

Dicho esto, los pasos principales, el método básico, la guía para conseguir realizar un test A/B que sea un éxito y nos de información relevante sobre nuestro sitio web se basa en:

1. Tener claros los objetivos o valores del sitio web. Lógicamente, por obvio que parezca, este es el punto de partida. Si no sabemos cual es el objetivo a alcanzar, los valores que marcan el horizonte de a donde queremos llegar, va a ser muy dificil que busquemos una mejora, porque no tenemos referencia de si estamos mejor o peor, y la intuición no sirve.
2. Reconocer claramente indicadores que nos digan de manera inequívoca que debemos realizar un test A/B. Si, por ejemplo, queremos tener 500 leads al mes generados por una página que recibe 10.000 visitas en el mismo periodo de tiempo, ya sabemos que eso implica un 5% de conversión, así que configura ese objetivo en Analytics y observa. Si no llegas a ese porcentaje de conversión, un test A/B sobre esa página puede ser una de las herramientas que te ayuden a conseguirlo, pero no debe hacerse porque sí. Esa observación de indicadores es la “palanca”, el gatillo que dispara las acciones de mejora y aquí el testing cobra todo el sentido.
3. Identificar con claridad la página de nuestro sitio web sobre la que se va a realizar el test. Un test A/B debe realizarse sobre una página concreta en la que efectivamente no se alcanzan los objetivos propuestos (que sean realistas, por favor, las conversiones del 67% para las historias de ciencia ficción), y dicha página debe ser significativa, es decir, debe tener tráfico, debe generar cierto volumen. Hacer un test con una página poco significativa por volumen no dará una información de valor. Intentad que, si es posible, la página sobre la que se va a ejecutar el test tenga un mínimo de entre 250-400 conversiones (de lo que sean) al mes. Para identificar las páginas que peor ratio de conversión tienen, ya sabeis, os vais a Analytics, previa configuración de objetivos, y, entre otras formas, os generais un informe personalizado que os diga el ratio de conversión a objetivo de cada página del sitio web. Es la forma más apropiada de conocer de manera fiable donde están los puntos de mejora a nivel de cada página de producto. No pensemos que todos los productos convierten igual o se comportan de la misma manera.
4. Escoger un periodo de tiempo adecuado. Por favor, nada de testing en Navidad, en Semana Santa, en vacaciones de verano o en periodos que no sean representativos de la actividad y estables.
5. Garantizar unas condiciones de “normalidad” en el sitio web y, en concreto, en la página sujeto del test. Es decir, nada de enviar de repente ingentes cantidades de tráfico, ni duplicar la inversión publicitaria ni, en resumen, hacer nada distinto a lo que se venía haciendo, porque si las condiciones del test se alteran sustancialmente, el valor de sus datos también.
6. Diseño gráfico, maquetación y a lanzar el test A/B. Sobre todo, que un test A/B sea eso, un test A/B y ofrezca como mínimo al usuario dos versiones alternativas (mínimo) de la página sujeto de testing. Es decir, no hais pequeñas modificaciones, para un test A/B sino todo lo contrario, plantear cambiso grandes en la arquitectura visual, en el diseño gráfico de la página en cuestión. Para afinar resultados y valorar la validez de copys, textos, etc, ya utilizaremos un test multivariante, pero no un A/B. Y ahora, escoge una herramienta, monta el test y a funcionar.
7. Comprobar el correcto funcionamiento. Tanto navegando como un usuario, con diferentes sesiones en diferentes navegadores, como utilizando Analytics (viendo que la URL del test figura como contenido y por tanto recibe tráfico), comprueba que todo funciona OK.
8. Establecer un periodo de prueba suficiente y consistente. Hay que entender que un test precisa de un mínimo periodo para validar sus resultados. Un test de un solo día os va a dar una información muy sesgada, muy poco fiable. Además de que sea un periodo estable, mantened el test entre 20 y 45 días, por ejemplo, aunque depende mucho de los volúmenes de tráfico.
9. Valorar la evolución de los datos de manera diaria pero sin emitir conclusiones. Comprueba que los datos varian, que los ratios cambian, etc, pero nada de sacar conclusiones de manera precipitada. Un test cuyas versiones alternativas empiezan funcionando muy bien puede acabar al contrario y vicecersa.
10. Finalizar el test y extraer las conclusiones y decisiones que correspondan. Una vez habeis hecho todo lo anterior, toca recopilar los datos del test y de ahí sacar conclusiones y ejecutar acciones, que pueden ir desde un cambio radical en la propuesta de diseño de la página analizada, hasta no hacer absolutamente nada, porque el test ha servido para demostrarte que de X número de alternativas, resulta que la original es la que mejores resultados te da.

Por supuesto, esta es solo una guía genérica con buenas prácticas para planificar y ejecutar un test, pero cada uno debe pensar y adaptar su propio sistema de testing porque cada sitio web y cada negocio online tiene sus propias particularidades que pueden hacer que haya que poner o quitar pasos en este sencillo proceso.

Así que ahora ya sabeis, a darle vueltas al coco y testing time!

Es decir, que cualquier búsqueda realizada de esa forma dará como resultado tráfico (not provided) y desconoceremos la cadena de búsqueda introducida por el usuario

Esta información hasta ahora estaba a disposición de todos y ahora, pues ya no lo está, así de claro. Le podemos dar todas las vueltas que queramos y buscar todo tipo de explicaciones para esa decisión de la gran G. La blogocosa se ha poblado de artículos sobre el tema, pero la pregunta de verdad es, ¿qué impacto real tiene esto a nivel de la información que vamos a perder sobre las búsquedas realizadas para acabar llegando a nuestros sitios web? Ya hay artículos que hablan de sitios web que pierden información de cadenas de búsqueda de entre un 7 y un 14% de su tráfico, y eso si es una cosa seria. ¿Vamos hacia eso?

En realidad es una cuestión de tiempo, y de esperar, porque ¿cuantos usuarios navegan logeados a sus cuentas de Google y hacen búsquedas?, la verdad es que no lo sabemos, simplemente lo suponemos. Y solo a base de ver la evolución del tráfico (not provided) que llega a nuestros sitios web podremos valorar si perdemos mucha o poca información.

En mi opinión es una cuestión de perfiles de usuario. Si tenemos sitios web en los que los usuarios son de un perfil avanzado o geek es probable que perdamos bastante información, ya que, a priori, parece un público susceptible de navegar logeado por sus características. Si por contra, en nuestros sitios web el perfil de usuario no es experto o de nivel avanzado es muy probable que el tráfico (not provided) suponga una cantidad despreciable de pérdida de información… a día de hoy.

Como ejemplo de ello, sirvan estas muestras de tráfico (not provided) de sitios web de muy diferentes tipologías. Los datos abarcan el periodo comprendido entre el 3 de octubre y el 2 de noviembre, ambos inclusive.

En este primer caso, el tráfico (not provided) de este mismo blog supone un 0,22% del tráfico total de este sitio web… no creo que suponga una hecatombre… aún, aunque ese pico del final habrá que ver si es tendencia sostenida o casualidad.

El tráfico (not provided) de los últimos 30 días en este blog

En el siguiente caso vemos las gráficas de un ecommerce del mercado brasileño, donde el tráfico (not provided) supone un 0,25% del total. Tampoco parece que en Brasil y en este tipo de ecommerce en concreto los usuarios naveguen logeados:

En Brasil, picos puntuales que no manifiestan una tendencia consistente

A continuación el tráfico (not provided) de un sitio web de generación de leads de una serie de temáticas enfocadas a un público alejado de la tipología de usuario avanzado de internet, y el dato aquí si es muy curioso, porque hablamos un 0%, de un rosco, sobre 30.000 visitas. Queda claro que el perfil de usuarios de un sitio web va a ser determinante para que perdamos más o menos información de las búsquedas realizadas.

En un sitio web utilizado por un perfil nada "tecnológico" tenemos "linea mortal"

Un ecommerce enfocado a un público genérico, donde hablamos de un 0,02% del total del tráfico

De nuevo, poca cosa, ¿no?

Y para terminar, un sitio web enfocado a público de habla hispana, con tráfico de varios paises, y orientado a servicios gratuitos a usuario, en el que el tráfico (not provided) supone el 0,10% del total:

Un pico relevante al final que habrá que vigilar por si es tendencia ascendente

Resumiendo y concluyendo, que ambos son gerundio:

1. Es muy muy pronto para valorar el impacto de esta medida en nuestros sitios web en lo relativo a la pérdida de información de cadenas de búsqueda por la que nos han llegado usuarios. Debemos esperar.
2. Pese a que ahora no representa volúmenes considerables en sitios web de tráfico “genérico” yo mismo he configurado alertas de Analytics para controlar tendencias ascendentes de un día respecto a su homónimo de la semana anterior e ir controlando la tendencia creciente de este tipo de tráfico. Cada uno que haga lo que quiera, pero yo lo recomendaría.
3. En principio, en el corto plazo, aquellos sitios web con un perfil de usuario más avanzado o geek van a ser los que van a tener una mayor cantidad de este tráfico. Tiene todo el sentido, por sus hábitos de uso, aunque no lo puedo confirmar porque no tengo acceso a datos de sitios web de ese perfil, ¿alguien se anima?
4. Lo único que podemos hacer es esperar, observar y valorar si realmente perdemos tanta información como el desconocimiento puede hacernos creer. En el momento que el tráfico (not provided) suponga un porcentaje relevante del tráfico total, según el volumen, desde luego y según la tipología del sitio web, es un poco bastante puñeta y perderemos información que vendría muy muy bien.
5. El nivel de usuarios que realizarán búsquedas logeados a servicios de Google y cuyas keywords de búsqueda serán ocultadas bajo (not provided) irá a más poco a poco, como todo hábito que se va implantando paulatinamente, de forma que habrá que adaptarse al escenario nos guste o no e ir manejándose con los datos de los que dispongamos, pero yo soy de esos que dice que cuando Dios cierra una puerta abré una ventana, así que habrá otro tipo de datos u otra forma de extraer conclusiones similares a como se hacía, y será una cuestión de habituarse al escenario. Ni más ni menos.

Y ahora solo nos queda esperar y confiar en que este no sea el primero de muchos cambios dirigidos a proteger la privacidad del usuario (pffffff) a la vez que a no facilitar información a las herramientas de medición que puede ser clave para el análisis…

Poder ver una charla de Avinash era una oportunidad que no podía dejar pasar… es como si AC/DC tocan en tu ciudad y no vas a verlos, ¿estás loco, man?

Foto que me hice con Avinash y mi camiseta con el mensaje "I´m a slave of conversion rate". Foto y derechos de la misma de Fernando Ortega

Y es que es así. Si te dedicas a esto o simplemente te gusta, la oportunidad de ver a este hombre no se podía dejar pasar bajo ningún concepto.

¿Qué no has podido ver a Avinash? Tranquilo/a, que yo te cuento (un poco) lo que vivimos esa mañana.

Lo primero que debo decir de Avinash es que se nota que es una persona realmente apasionada con lo que hace y esa pasión está muy presente en su forma de hablar, de explicarse y de transmitir sus conocimientos, y es algo que se agradece mucho, porque realmente impregna el ambiente, te implica y consigue transmitirte la absoluta fé que tiene en todo lo que dice.

El desayuno comenzó, como debe ser, desayunando, con café y pastitas y compartiendo conversación con buena parte de los asistentes al evento (que al final debimos ser unas 80-90 personas). Allí estaban buena parte de las personas más representativas del análisis y gestión de negocios web en España, como la plantilla de MV Consultoría, encabezada por Sergio Maldonado, Pere Rovira y mucha plantilla de webanalytics.es (Oriol, Cristina, etc), Gemma Muñoz, Bárbara Mackey, Ana Soplón, Nancy Guillén, Fernando Ortega, Gema Mora, Javier Godoy y muchos más profesionales del sector.

Avinash comenzó muy fuerte, sentando las bases de su discurso, al afirmar que “Los datos sin propósito son basura“, y lo que realmente debe hacer un negocio con presencia en internet es preguntarse el porque de las cosas, porque hacemos lo que hacemos, cual es el propósito.

También hablo de la importancia que tiene el comenzar haciendo bien las cosas en entornos pequeños y la dificultad que supone el tener luego que escalarlos.

Como ruta de su charla nos propuso centrarse en 3 puntos: el que, el como y el porque

En cuanto al que, Avinash profundizo en la idea de que las métricas cuantitativas per se carecen de valor. Los follows, los +1, las visitas, etc, son basura, no importan y debemos centrarnos en las métricas que realmente importan. Hay que centrarse en la eficiencia táctica, en preocuparse mucho más de donde llevas al usuario que ha hecho un click que le conduce a una landing page tuya que en las cuestiones relacionadas con los datos empíricos de esa página. Para ejemplificarlo nos mostró la home de El Pais, que con 469 posibles clicks, es un ejemplo de compañía dirigida por páginas vistas. En contraposición nos mostró la web de la Universidad de Minnesota, que se preocupa más por sus visitantes al facilitar la opción de adaptar la navegación al perfil del usuario específico, huyendo del patrón de navegación genérica pensada para todos los usuarios.

Dentro de su apartado del que, Avinash también incidió para comprender mucho mejor la eficiencia táctica en el movil como paradigma de uso y no como dispositivo. Ahora mismo, los tablets y smartphones son usados por personas de buen nivel adquisitivo, y la experiencia en ellos es crucial.

Afirmó con rotundidad que uno de los errores más graves es perder el contexto del análisis, sin ser consciente del contexto el análisis, directamente no existe, no es posible.

Concluyó esta parte hablando de que la analítica web debe evolucionar hacia lo accionable. Es decir, alejarse del reporting, de los informes, y centrarse en el cambio.

Respecto al como, compartó al 100% su visión de que centrarse en el 2% de los usuarios que compran en un sitio web, por ejemplo, supone NO centrarse en el 98% restante, con lo que eso supone. Hay una enorme importancia que otorgar a la medición de lo macro + micro y debemos orientarnos a un pensamiento en torno al concepto de darle valor económico a acciones que objetivamente y de forma directa pueden no tenerlo. Hay microconversiones de gran valor, que sin ser conversiones directas son pasos hacia una macroconversión y, precisamente por ello, tienen un valor económico real dentro de la dinámica de un sitio web.

Cada fuente de tráfico tiene un valor de aplicación a las actividades del sitio web, ¿qué estamos haciendo y cómo sucede?, y además de las fuentes de tráfico, está la cuestión de los dispositivos, ¿qué hacen los usuarios que vienen de diferentes dispositivos?. Nos habló del caso de Target.com como adaptación de gran valor al uso del dispositivo movil.

Hay que demandar el valor económico de las acciones, porque va a suponer la diferencia entre ganar o perder.

Sobre el porque, afirmó que el 99% de los fallos se deben a la estructura de pensamiento y no a cuestiones técnicas o de otro tipo. Para trabajar el enfoque y la correcta visión de negocio, propuso una matriz muy util basada en 5 pasos:

1. Objetivos de negocio. ¿Por qué existe tu iniciativa?
2. Metas. Estrategias específicas que te ayudan a conseguir los objetivos de negocio
3. Identificar KPIs. El KPI debe definirlo un analista con la persona de más alto rango de la organización con la que pueda tratar.
4. Objetivos.
5. Identificar segmentos.

Al final, concluyó afirmando que en realidad se trata de extraer la información de máximo valor, que es la comprensión del funcionamiento de tu modelo y tu negocio. Y esa es la llave del rendimiento máximo que se puede obtener.

Y si quereis ampliar información sobre la charla de Avinash y conocer otras opiniones, podeis leer este post de Cristina Mataix, que complementa y/o amplia a este.

Tras su intervención, tuvimos la ocasión de hacerle un buen número de preguntas a Avinash, que además nos regaló un chocolatillo (eso sí, de San Francisco) a cada uno de los que preguntamos algo. Y luego, se prestó a firmar libros (en mi caso, mi libreta de Analytics, ya que me deje su último libro en casa) y pudimos estar charlando un rato con él.

Entre medio, Sergio Maldonado nos habló de un concepto que me pareció muy interesante, como es la gestión de activos digitales, y también pudimos ver la presentación y una demostración de la herramienta sweetspot, que me pareció una brutalidad en cuanto a prestaciones y concepto, ya no como herramienta de análisis, sino directamente de trabajo global.

Y así discurrió una mañana en la que como yo mismo le dije a Avinash, no nos habló de analítica web, sino de un modo de pensar y de hacer las cosas.

La popularización de Analytics como sistema de medición “estándar” de la mayoría de webs y el tener cada vez más usuarios hacía quizás necesario que la herramienta, el propio Analytics, tuviera su propio evento en España, al estilo de eventos como el Photoshop Training Convention (éste en USA) y similares, y no encuadrado dentro del marco de la analítica web, que es un concepto más amplio y que ya tiene eventos como el Conversion Thursday, el PWA o el WSAB, sino solo para tratar esta herramienta especifica, que a fin de cuentas es la que más difusión tiene.

Y con ese espíritu nace la Google Analytics User Conference, que se celebra el próximo 27 de octubre en Madrid

Lo que me gusta del evento, a priori, es que todo gira en torno a Google Analytics y, por tanto, ya sabes que se trata de un foro en el que solo se va a hablar de esa herramienta y se va a compartir experiencias, a poner dudas en común y sobre todo, a enterarse de como se hacen un montón de cosas que hemos leido que pueden hacerse con Google Analytics pero que muchos no hemos sido capaces de hacer (que levante la mano el que sepa hacer TODO lo que en teoría puede hacerse con Analytics)

Como en la mayoría de eventos de este tipo, el mayor valor será, sin duda, el conocer a personas que usan Analytics en negocios muy diversos y compartir experiencias, intentar conocer como hacer según que cosas, los resultados que les ha dado, etc. Siempre creo que este es el mayor valor de este tipo de eventos, y generalmente se aprende mucho de los propios asistentes, ya que cada uno se ha buscado la vida para resolver sus necesidades usando Analytics.

Además, el programa del evento parece bien orientado y distribuido a priori, ya que incluye 2 plenarias y un workshop a elegir entre 6, distribuidos en función del nivel del asistente y/o en base a lo que se quiera aprender.

Como idea, desde luego me parece muy buena, y habrá que ver como se desarrolla y el tipo de asistentes que tiene, pero desde luego, hacen falta iniciativas como esta, porque es parte del camino para un uso profesional de la analítica web y sus herramientas.

Suerte en esta primera edición y a ver como sale la cosa! Allí nos vemos!

Dicho esto me he propuesto escribir una serie de post que compongan una especie de guia básica de optimización web, en la que el test A/B es una buena parte, porque todos tenemos muy claro que es, para que sirve y como hacer un test A/B, ¿o no? La mejor opción es siempre empezar por el principio, un “back to basics”, porque no conviene presuponer que todos sabemos lo que son las cosas por muy populares que se hayan vuelto.

Y el principio aquí es ¿qué es un test A/B?

Un test A/B, hablando del entorno web,  es un método que permite ofrecer al usuario, sin que éste lo sepa, dos o más versiones de una misma página de un sitio web, de forma que el mismo producto, servicio o contenido de una página puede ser ofrecido a diferentes usuarios bajo diferentes layouts o diseños. La herramienta que hayamos escogido para ejecutar el test A/B recogerá la información relativa al rendimiento de cada uno de los diseños en función de la conversión a objetivo que cada uno coseche, y de esta forma dispondremos de una información 100% empírica (basada en datos) sobre la capacidad de cada diseño para generar mejores resultados, sean estos los que sean.

Explicado de una manera más pausada, un test A/B nos permite, en primer lugar, comprobar que modelo de presentación o interacción funciona mejor para una página web, por ejemplo:

Ejemplo de un test A/B real, comparando dos modelos de presentación e interacción muy diferentes del mismo producto

Y luego, pasado un periodo de prueba consistente y bien planificado, los datos que obtengamos del test A/B nos permitirán evaluar la capacidad de nuestras propuestas para conseguir el objetivo deseado, ya que lo que se mide aquí realmente es que ratio de éxito tiene cada modelo en la consecución del objetivo de la landing page: generación de leads (contactos), descargas efectuadas de un archivo, inicio de procesos de compra, y un larguísimo etecetera compuesto por todas aquellas acciones susceptibles de ser consideradas objetivo de una página web.

La cuestión de fondo antes de plantear un test A/B es precisamente tener claro cual es el objetivo, no del sitio web, sino de la página específica sobre la que se va a ejecutar el test.

El test A/B no es nada nuevo, por mucho auge que viva ahora en el escenario de internet. Ha existido siempre y en todos los campos. Cuando se consigue un modelo inicial de lo que sea, rara vez se da por finalizado, y cualquier modelo, proceso o producto es sometido a muchos test A/B a lo largo de su vida (entre otras muchas cosas para hacerlo evolucionar) para conseguir el mejor ratio posible de consecución de objetivo o de satisfacción del cliente.

Para mi ha sido un honor ser profesor de este master junto con profesionales tan reconocidos del sector internet como son mi paisano Daniel Torres Burriel, Adrián Segovia, Pere Rovira, Iñaki Mediavilla, Juan Leal, la propia Gemma Muñoz y un larguísimo etcetera de profesores de primerísimo nivel en analítica web y profesionales de experiencia contrastada en internet.

Este master de analítica web tiene ahora una edición en Zaragoza, que empieza el 14 de octubre, y yo me alegro, porque es mi casa, y es una buena oportunidad.

La primera edición fue un éxito y supongo que por eso mismo, desde K School se han animado a que la segunda edición de este master de analítica web no solo se haga en Madrid y Barcelona, las ciudades más “típicas” para este tipo de formaciones especializadas, sino que también va a hacerse en Zaragoza y Valencia, y eso representa una muy buena oportunidad de acceder a un conocimiento de gran calidad sobre una especialidad, como es la analítica web, con una demanda cada vez mayor.

Si quieres más información del master de analítica web en Zaragoza haz clic en la imagen

La verdad es que el saber que este máster se va a realizar en Zaragoza, empezando el 14 de octubre (en plenos Pilares, yeah!!!), es algo que me gusta mucho, y no porque sea parte interesada (doy clase allí), que lo soy, sino porque pone al alcance de la gente de Zaragoza y alrededores la oportunidad de acceder a un conocimiento de primerísimo nivel de la mano de muchos de los mejores profesionales de internet que hay hoy día en el panorama nacional, y eso significa aprender de los mejores, una oportunidad que desgraciadamente no se presenta todas las veces que nos gustaría.

Hasta ahora iniciativas de este tipo estaban muy limitadas a Madrid y Barcelona, básicamente, y creo que es muy buena noticia que en nuestra casa tengamos ahora la oportunidad de acceder a este tipo de formaciones.

Desconozco si al final el máster podrá llevarse a cabo o no, porque eso depende del número de inscritos, aunque a tenor de las noticias que tengo, el interés es muy grande y eso es muy buena señal. Pero independientemente de que salga o no, el hecho de tener en casa, en Zaragotham, en la ciudad del Ebro, la opción de asistir a una formación de este tipo es, en sí, una buenísima noticia para la ciudad. Y eso me gusta, oigan.

Pero, ¿y si no conseguimos lo que buscabamos?, ¿y si invertimos en el sitio web demasiado tiempo y dinero?, ¿cuando conviene cerrar el sitio web?

Porque, y no nos engañemos, como en todo, hay sitios web que consiguen su propósito desde el día 1, hay otros que requieren de tiempo y cambios para lograrlo y hay otros que, por múltiples razones, nunca lo consiguen.

Y es cierto que en cualquier sitio web debe haber un periodo de adaptación, cambio, optimización, buscando conseguir y mejorar los resultados. Debe haber paciencia y debe haber opostunidades de mejora, pero todo tiene un límite y lógicamente no podemos prolongar la vida de un sitio web más allá de lo necesario.

¿Cuando debemos considerar cerrar un sitio web y por qué? Siempre partiendo de que ha habido un proceso previo de observación, toma de acciones, implantación de mejoras, optimización, etc, los principales argumentos para dar este último paso y que nos hagan tomar esa decisión deben ser:

1. No conseguimos los objetivos planteados para el sitio web, y, de hecho, tenemos una gran desviación negativa. Si hemos definido unos objetivos iniciales, hemos ido haciendo un seguimiento regular de éstos y además planteado acciones para corregir la desviación negativa o la no consecución de los objetivos durante un periodo de tiempo razonable (entre 6 y 9 meses, por poner un marco temporal) y nada de eso supone una mejora o una tendencia ascendente que confirme que estamos en un camino que nos permitirá reducir ese gap e incluso aproximarnos a los objetivos inicialmente planteados, debemos empezar a considerar que algo está roto en la concepción del sitio web, lo que nos lleva a remodelarlo y/o readaptarlo o a considerar su cierre. Si optamos por seguir trabajando en él el replanteamiento puede hacer que despegue… o no.
2. El coste de mantener el sitio web es mayor que el beneficio que éste nos reporta. Independientemente de que el beneficio sea o no económico (puede ser innovación, testing, etc), si la inversión que destinamos a mantener el sitio web (costes fijos + costes variables) es mucho mayor que el beneficio que nos da, la decisión parece clara.
3. No alcanzamos el punto mínimo de equilibrio gasto-ingreso en el plazo máximo asignado. Es decir, independientemente de que el sitio web no nos de los beneficios esperados, además tampoco alcanza unos mínimos exigibles en lo referente a los mínimos ingresos necesarios para mantenerlo funcionando (puede ser rentabilidad negativa).
4. La tendencia de las métricas principales, no solo web sino también económicas o de negocio, es descendente y no presenta signos de mejora a pesar de cambios y acciones sobre ello en un periodo de tiempo prudencial. No hay beneficios, no hay equilibrio mínimo, no se consiguen objetivos. Por si esto fuera poco, además, o en su lugar, las métricas principales del sitio web (ventas, leads, descargas, engagement, etc) tampoco manifiestan una tendencia de mejora clara y sostenida.
5. Aunque ya no destinas recursos de ningún tipo al sitio web lo mantienes abierto, pero la atención a sus usuarios es muy deficiente. Vale, has asumido que no funciona y has dicho “bueno, peor lo mantengo online. Total, ¿qué puede pasar?”, pues puede pasar que tengas usuarios que te envíen consultas que no sean respondidas, que se te caiga el sitio y ni te enteres porque no inviertes ni un minuto en él, que alguien compre y su pedido no se procese, que sea hackeado, afectando a sus vecinos de IP y, de nuevo, ni te enteres. Si estás en este punto, cierra ya.

Desde luego, son síntomas, no web, sino claramente de negocio que llevarían a tomar una misma decisión de cierre se tratara o no de un sitio web.

Si se dan estas situaciones o los indicadores muestran claramente que vamos hacía ellas, conviene empezar a pensar en la posibilidad del cierre y en no mantener vivo un sitio web que no da muestras de arrancar.

Pero lo más llamativo es que parece que cuesta más desprenderse de un sitio web que de otro tipo de elementos de negocio, porque parece que su coste, por el simple hecho de “ser una web” es mucho menor y es fácil de asumir. Sabemos que no es así, porque puede haber un gran número de recursos asociados a una “simple web”, y si realmente sabemos que eso es así, hay que reaccionar de la manera más adecuada: le has dado al sitio web el escenario mejor que has podido para que consiguiera su cometido, para que funcionara, y no ha sido así. Bueno, no es el fin del mundo, sino simplemente el fin de una web.

Lo cierto es que no es plato del gusto de nadie reconocer que un sitio web que has puesto en marcha no funciona, no sirve, no consigue lo que querías, y hay que darle carpetazo y seguir hacia adelante. No pasa nada, esto, como muchas cosas, duele mucho la primera vez, luego, por aquello de ir acostumbrándose al fracaso (aunque sea a pequeña escala), ya es más fácil. Yo mismo he participado en el cierre de no menos de 15 o 20 sitios web por muy diferentes motivos, siempre relacionados con las causas arriba indicadas, y al final te das cuenta de que es lo mejor, y principalmente para el usuario, sobre todo si pensamos en el punto 5.

Sobre este tema es muy recomendable la web Fail Beta, que aunque ya no se actualiza, está repleta de ejemplos de sitios web que no salieron adelante.

Lo has medido, lo has observado, lo has trabajado, has pensado en el usuario, has hecho los cambios oportunos, OK, lo has hecho todo bien, has seguido el manual, pero la “criatura” no funciona. Amigo, aunque le tengas cariño y aunque se trate de un sitio web que hayas concebido tú, de tu bebito, asúmelo, no pasa nada, cierra y pasa página.

Esto ha redundado en que muchos responsables de negocio de sitios web desarrollen una casi enfermiza obsesión por la conversión

La conversión es, a fin de cuentas, el resultado final de un proceso bastante largo que puede resumirse en que tu cliente queda convencido por la oferta que le expones en tu sitio web y finalmente decide ejecutar la acción que es tu objetivo principal, la tan ansiada y deseada conversión, pudiendo ser ésta una compra, una descarga, un lead, etc. La popularización de la conversión ha significado también la popularización masiva del embudo de conversión, que a día de hoy es el gráfico favorito de muchos sitios web que se juegan los cuartos en la optimización, y, sí, en sus tasas de conversión.

Este embudo no es el típico de conversión, pero luce muy bien y es tremendamente resultón

El problema empieza cuando toda la optimización de un sitio web se centra casi única y exclusivamente en mejorar el ratio de conversión, y éste es el horizonte que marca el éxito. Lo que sucede, contrariamente a lo que pudiera parecer, es que esa obsesión insana por conseguir mayores ratios de conversión, lleva a centrar la optimización de un sitio web en torno al embudo de conversión, y nos olvidamos de  todo lo demás. La conversión es mi nuevo Dios y haré todo pensando en ella, lo demás es irrelevante.

¿Y qué es lo que puede suceder? Pues que el orientar tanto la optimización web a ese objetivo es generar una optimización bastante antinatural en cierta forma, porque nos centramos en optimizar procesos, flujos de navegación, etc, y nos acabamos olvidando del cliente, con lo que el resultado final, oh sorpresa!, es que nuestra conversión no solo no mejora, sino que a lo mejor hasta empeora.

Está muy bien centrarse en mejorar la conversión de un sitio web, porque en realidad es lo que todos queremos, ganar el máximo posible, y eso es 100% lícito y recomendable para cualquier negocio por definición. El problema viene cuando en torno a la conversión se genera una sobreoptimización web que ya resulta antinatural, con todo el sitio web enfocado a ello, casi como si estuviéramos empujando al cliente a “convertir” y no convenciéndole para que lo haga.

Por tanto lo más recomendable cuando hablamos de optimizar un proceso de conversión web es pensar siempre y como elemento principal en el cliente

No debemos pensar solo en los procesos o mejoras asociados a su comportamiento, sino en el cliente, en sus necesidades reales. El poner un botón más grande, más llamativo, con mejores copys, etc, mejorará tu CTR y mejorará tu proceso, seguro, pero no son los únicos pasos para mejorar la conversión, porque son pasos mecánicos, y necesitas trabajar también toda la faceta “humana” de tu oferta web, y eso, bien trabajado, si que ayuda a mejorar mucho esos ratios, quizás más que las mejoras de tipo “técnico”, más enfocadas a optimizar un proceso que de base ya funciona y que hay que ir puliendo.

A la hora de optimizar buscando mejoras en conversión, no debemos obsesionarnos solo con mejorar los procesos directamente asociados a las acciones vinculadas a ésta (como los embudos de conversión, los pasos de un proceso de comrpa, botones, copys, etc), sino aprovechar para potenciar y mejorar todos los aspectos directamente relacionados con cliente y negocio y trabajar, por ejemplo, sobre:

1. ¿Lo qué le ofreces al cliente en tu sitio web es claro, atractivo, está bien explicado, va a despertar su interés?
2. ¿Tienes a la vista medios para recoger su feedback, para demostrarle que te preocupas por su opinión?
3. ¿Hay garantías visibles para el cliente, que sean válidas para él y qué le sirvan para valorarte como opción antes que a la competencia?
4. ¿Tu estilo de redacción es claro, bien estructurado o has elegido el típico bloque monolítico de texto?
5. Si conoces a tu cliente, ya sabes lo que te va a preguntar, ¿resuelves sus dudas desde el inicio?
6. ¿Hablas como lo hacen tus clientes en tu sitio web o presentas tus productos con larguísimas referencias o similares?

Sorprendentemente muchos sitios web no pueden dar una respuesta a estas sencillas preguntas, con lo que en lugar de una optimización mecánica deberían pensar en una optimización más orientada a planteamiento y negocio como primera fase.

No orientemos la mejora de nuestros sitios web exclusivamente en torno a las mejoras de los procesos y no lo basemos todo en cosas como los test A/B, multivariantes, clickmaps, etc, que están muy bien y ayudan a mejorar el negocio en la web, pero siempre hay que recordar que hablas de personas y, por tanto, no solo hay que optimizar procesos, sino el fondo de lo que ofreces. Debe haber empatía con el cliente, porque si no, por muy concebido que este tu sitio web desde el punto de vista técnico y 100% enfocado a la conversión, no funcionará.

Obsesionarse por la conversión, en plan insano, es como si al entrar en unos grandes almacenes tuvieras a un comercial pegado a tu culo e insistiéndote una y otra vez en que comprarás tal o cual cosa o en que hicieras esto u aquello. Es buscar el objetivo de una forma tan descarada e incluso agresiva que al final lo que consigues es justo lo contrario, así que lo más sensato es huir de esa sobreoptimización e intentar siempre que, aunque haya una base comercial, el proceso sea lo más amable y “natural” posible… convencer, sí, agobiar, no.