Tags populares:

¿Confías en tus datos? ¿Alguna vez te has planteado la veracidad de los datos que recoges en Google Analytics?

02/03/2015 a las 11:41

La medición y el análisis de los datos de una organización afecta directamente a la calidad de las decisiones tomadas en cualquiera de los distintos niveles organizacionales. Errores en implementación y/o configuración nos pueden llevar a plantear hipótesis equivocadas y consecuentemente a la toma de decisiones erróneas.

Garantizar la calidad de la información es un reto para la mayoría de las organizaciones, y cada vez son más aquellas que se preocupan por conocer sus propios niveles de calidad y el impacto que esto supone en el negocio.

Se trata, no solamente de asegurar que todos los elementos del sitio que queremos medir tengan incorporado el tag de seguimiento, sino que la información recogida es correcta. Hay ciertos errores que no son evidentes a primera vista, por ejemplo, si nos equivocamos en la nomenclatura de páginas, el número de páginas vistas en Analytics será correcto mientras que en realidad, la información que proporciona es errónea.

En este post, describimos los errores comunes en la medición y destacamos la necesidad de un método de evaluación que permita a las organizaciones confiar en sus sistemas de medición.

 

  1. Códigos obsoletos o mal ubicados

Es muy importante asegurar que no quedan residuos de código antiguo, una vez se ha hecho la actualización del código de seguimiento a versiones superiores. Esto a veces puede cortar sesiones, generar sesiones nuevas, etc…

Imagen1

  1. Estructuras de cuentas, propiedades y vistas

Se recomienda la creación de 3 vistas como mínimo:

  • Test: Nos sirve para probar los nuevos filtros antes de ser aplicados a la vista de producción o de consulta. En caso de error, lo podremos solucionar dentro de esta misma vista sin perder datos y sin que esto afecte a las vistas de consulta.
  • Maestro. La vista de consulta de datos, puede contener filtros. Ejemplo: exclusión de IPs, reescritura de la información recibida, etc…
  • Sin filtros. Es un sistema de seguridad que permite tener recogidos todos los datos en formato original, por si alguna vez perdiésemos los datos en alguna vista de consulta. También permite investigar incidencias que pueda haber en la recogida.

Además es importante tener una estructura limpia y crear una convención de nomenclaturas, que permita identificar rápidamente los distintos entornos. Una buena solución sería por enumeración, donde la 999 sería la vista de “test” y se ubicaría al final de la lista.

Imagen2

 

  1. Filtros y vistas

Dentro de este apartado hay muchas consideraciones a tener en cuenta y que pueden ser de distinta naturaleza. Enumeramos 3 ejemplos:

  • Filtros vs. Segmentos: A menudo hay cierta confusión entre filtros en vistas y segmentos avanzados. Los filtros en vistas se aplican de forma indefinida, una vez ejecutados no se pueden recuperar los datos que han quedado fuera del filtro. Hay que tener mucho cuidado con ello y entender muy bien las diferencias entre un segmento avanzado y un filtro dentro de una vista, ya que podríamos perder todos los datos de una vista sin opción de poder recuperarlos.
  • Robots: Es muy común utilizar robots que comprueban que los procesos funcionan correctamente. Estos robots, mientras recorren todo el sitio web ejecutan el código de javascript de Google Analytics y dan falsos registros de sesiones. Es conveniente filtrarlos también.
  • Tráfico relevante: Es importante identificar los distintos mercados de actuación ya que todo el tráfico que quede fuera de estas áreas geográficas puede que no sea conveniente incluirlo. Para ello incluiremos un filtro que nos permitirá hacer foco solamente en aquellas áreas relevantes para el negocio. Aquí se incluyen filtros del tráfico interno de una organización, etc…

Imagen3

Exclusión de parámetros

En el supuesto caso que tengamos en las urls cualquier parámetro de consulta o ID de sesión único (por ejemplo, sessionid o vid) y no deseemos verlo en los informes es importante excluirlos. Si no lo hacemos, este contenido quedaría tan disgregado que podríamos alcanzar el límite máximo de filas por informe (50.000). Google Anlaytics lo que hace entonces es agrupar en otra categoría llamada (other) perdiendo, así, el nombre de la página real.

 

Imagen4

  1. Autoreferencias

En Google Analytics, las autorreferencias son aquellos casos en los que los propios dominios aparecen en el informe de adquisición à Todas las referencias. Por ejemplo, si nuestro sitio web es www.example.com, cualquier dato del informe que incluya www.example.com es una autorreferencia.

Si aparecen muchas autorreferencias, puede deberse a un problema con la configuración de Google Analytics y, por lo tanto, es posible que las métricas aparezcan sesgadas y no se muestren las fuentes de tráfico reales a las que se atribuyen las conversiones y otros tipos de interacción en su sitio.

 Imagen6

  1. Pensamiento a largo plazo: anotaciones técnicas

Es importante tener previsión a largo plazo a la hora de dar contexto a los datos. Es muy buena práctica dotar el sistema de medición de anotaciones técnicas con el objetivo de informar  cualquier cambio de implementación y/o configuración. Estos cambios suelen afectar a la recogida de datos incrementando o disminuyendo sesiones, usuarios, etc…. Si no existe un registro de toda esta información, durante la fase de análisis es muy difícil contextualizar e interpretar posibles cambios producidos por un cambio técnico.

Imagen7

  1. Convención de nomenclaturas (campañas y contenidos)

Es importantísimo definir una convención de nomenclaturas para nuestras campañas y contenidos del sitio. De esta forma, las agencias externas que estén gestionando nuestras propias campañas pueden ajustarse a nuestra estructura al momento del etiquetado. Esto permitirá un orden mucho más limpio y evitará duplicidades y el caos.

Imagen8

 

  1. Data Quality Assurance: Asegurar la calidad de los datos

Es importante establecer una metodología que ayude a prevenir incidencias en la recogida de datos. Esto se lleva a cabo mediante un sistema periódico de revisión, rastreo y monitoreo que alerta si se ha producido algún cambio debido a la pérdida de algún tag o un error en implementación y/o configuración. La idea es minimizar el impacto de una posible pérdida de datos en el negocio.

Por ejemplo, una subida repentina y considerable en el porcentaje de nuevas sesiones podría indicar una pérdida accidental de la cookie, normalmente debido a un error en la configuración del salto de dominio.Imagen9

Código de moneda en Ecommerce Clásico con GTM

18/02/2015 a las 14:05

Con la aparición del Enhanced Ecommerce de Google Analytics ha cambiado mucho la información que disponemos para el estudio de las conversiones.
La implementación se ha vuelto más compleja y mucho más rica, Google se ha preocupado en recoger todos los datos significativos del proceso y si necesitamos alguno más siempre tenemos las dimensiones personalizadas, tal y como hacíamos antes.

No es una situación muy común, pero se puede dar algún caso en el que todavía tengamos que realizar implementaciones con el Ecommerce clásico.

La implementación del Ecommerce clásico con GTM es muy sencilla, tan solo es necesario incluir el dataLayer correspondiente y la etiqueta de transacción en el contenedor, contamos con documentación de Google donde se explica este proceso de una forma, más o menos, clara. Recientemente nos hemos encontrado con la necesidad de recoger la moneda de la transacción, dato que no forma parte del dataLayer del ecommerce clásico.

Informar de la moneda a Google nos permite tener vistas diferentes para cada país, con su moneda correspondiente, y una vista global en la que se realiza la conversión a euros de cada moneda para tener una información general de los ingresos.

Para enviar este dato a GA, en primer lugar tendremos que agregar el valor al dataLayer de la conversión.

<script>

dataLayer = [{
‘transactionId': ‘1234’,
‘transactionAffiliation': ‘Ropa Acme’,
‘transactionTotal': 38,26,
‘transactionTax': 1,29,
‘transactionShipping': 5,
‘transactionCurrency': ‘GBP’,
    ‘transactionProducts': [{
‘sku': ‘DD44′,
‘name': ‘Camiseta’,
‘category': ‘Ropa’,
‘price': 11,99,
‘quantity': 1
},{
‘sku': ‘AA1243544′,
‘name': ‘Calcetines’,
‘category': ‘Ropa’,
‘price': 9,99,
‘quantity': 2
}]
}];

</script>

En el siguiente paso iremos a GTM y crearemos una macro de tipo “variable de capa de datos” en GTM que recoja este valor, indicando el nombre de la clave que hemos incluido en el dataLayer de transacción.

macro_currency

A continuación en nuestra etiqueta de transacción añadimos el nuevo campo. Para ello desplegamos la opción “more settings” dentro de la etiqueta e insertamos el nuevo campo en “fields to set”

more_settings - fields to set

En versiones más recientes de GTM Google ha simplificado la inserción de este dato en concreto en la etiqueta de transacción, proporcionando un campo específico para ello.

añadiendo currency code en la transacción

De la misma manera que en el ejemplo anterior debemos crear antes la macro que recoja el valor del dataLayer.

Esto permite a Google recoger ese valor sobre el que basarse para realizar la conversión oportuna.

Google Proporciona un listado de los códigos de moneda sobre los que soporta la conversión, que son los que deberemos incluir en cada caso en el campo de transactionCurrency de nuestro dataLayer.

Como nota curiosa, en una experiencia reciente, hemos comprobado que a pesar de que en el listado se indica que el código de la Lira turca es TRL, Google no lo acepta y el código correcto sería TRY.

Por supuesto, en el resto de casos, es importante mantener el código especificado por Google. En el caso de que existan distintas definiciones para una misma moneda en necesario utilizar la que aparece en el listado.

Esto puede darse por ejemplo con la moneda china, el yuan o renminbi abreviado como RMB, también se ha utilizado como código de moneda en muchas ocasiones, pero en este caso el código que acepta Google para esta moneda es el oficial (CNY).

Es importante saber que Google Analytics utiliza el valor de cambio del día anterior en el que se realizó el procesamiento de los datos, por lo tanto, si contamos con una propiedad en la que se recogen los datos de las transacciones de varias divisas para mostrar los ingresos en una moneda común, por ejemplo en euros, si el valor de una moneda fluctúa, podemos encontrarnos con ingresos diferentes para un mismo producto en distintos periodos de tiempo seleccionados en los informes.

 

Cómo conocer la ruta del consumidor y el aporte de cada canal digital

13/02/2015 a las 10:41

 

Por Cristóbal Bello.

 

Desde el momento en que  se comenzaron a conocer las métricas de conversiones asistidas en Google Analytics, se abrió una nueva manera de analizar la ruta del consumidor o el “consumer journey”. Dándole una nueva perspectiva a las personas en marketing de cómo funciona (o trabajan en equipo) los canales, como mailing, search, social media o display en la generación de conversiones o ingresos.

Cabe destacar que no todas las marcas y sus acciones generan una ruta del consumidor larga, más bien algunas resultan cortas, ya que depende del tipo de conversión, lead, tipo de producto que cada sitio posea.

Desde el punto de vista del tiempo, para saber si la ruta es larga o corta, es decir si se toman muchos o pocos días antes de generar una conversión, hay que observar el reporte de lapsos de  días en el menú de conversiones

Conversiones -> Embudos Multi-Canal -> Lapso de Tiempo

post_crist_1

Si un porcentaje representativo de conversiones  está sobre cero días, vale la pena conocer un par de datos más. Para eso hay que ir a:

Conversiones -> Embudos Multi-Canal -> Conversiones por Contribución

post_crist_2

 

DEFINIENDO LAS MÉTRICAS

1. Las conversiones por contribución

Son la cantidad de compras y leads,  donde cada canal descrito a nivel de fila ha contribuido conversiones sin ser  el canal de último clic o el último de la ruta

2. El valor  de las conversiones asistidas.

Simplemente es el dinero que estos canales generaron sin ser el último canal de la ruta.

3.Conversión de último clic o directa.

Es la cantidad de compras y leads provenientes de la última fuente de tráfico previa a la conversión.

4.Valor de las conversiones por interacción de último clic o directa.

El dinero que estos canales aportaron de dicha manera.

¡Y la última métrica! (y relevante en este post):

5. Conversiones de contribución/de interacción de último clic o directa.

Esto es una relación expresada con una simple división:

post_crist_3Cuando el resultado es cercano a 0 quiere decir  que existen pocas conversiones por contribución  y el  canal funcionan de manera más directa.

Cuando el resultado es igual a 1, quiere decir que la cantidad conversiones por contribución son  iguales a las de último clic.

Cuando el resultado es mayor a uno quiere decir que las conversiones por contribución son mayores y el canal aporta más asistiendo.

Esto nos indica en que etapa de la ruta a la compra funcionan  los medios. Por ende, cada canal lo podemos agrupar por su valor en las famosas etapas como se muestra a continuación, dibujando finalmente el consumer journey.

post_crist_4

 

post_crist_5Es interesante darse cuenta de como se comporta los medios digitales según la naturaleza de cada sitio, por ejemplo:

–          El  resultado número  1, posee a los canales más dispersos, y varios que actúan más de manera indirecta que directa, influenciado por el hecho de que la conversión es una compra.

–          En el resultado numero 2 los canales resultan ser todos directos, influenciado  por que la conversión es una solicitud de contacto, existiendo una ruta más corta en comparación con el primer resultado.

TAKE AWAYS

Para las marcas, entender la manera en que la audiencia interactúa con ellas y el camino que generan resulta relevante, ya que entrega un entendimiento, mapeo y posibilidades de mejoras hacia el cliente. Esto, desde el punto de vista de interferir de mejor manera en la comunicación de los canales, sabiendo como influye  cada uno en la venta final.

Por un camino paralelo, resulta interesante poder conocer como influye cada campaña  pagada en search o inclusive cada keyword. Esto permite por ejemplo cuestionarse la táctica de landing pages según posición de campañas, u optimizar keywords solo de last click, o potenciar orgánicamente nuevas keywords. El juego aquí será amplio, dependiendo de  cuantas campañas, y cuánto y cómo influyan en la ruta de compra.

PD: Google Analytics permite obtener estas métricas y  analizarlo a nivel únicamente de  AdWords

Por último, hilar en lo más fino va a consistir en evaluar cual  vendría siendo el mejor modelo de atribución en base a la realidad de cada sitio. Existen 7 modelos de atribución, el más usado por defecto es el de last click, pero lo visto anteriormente crea la oportunidad de volver a optimizar el presupuesto desde otros puntos de vista.

NOTA

Comprender como se recopilan los datos de atribución que posee Google puede resultarte importante (lo es :-) ). Para ello, recomiendo leer esta ayuda de google.

 

 

 

Ajuste de rebote mediante temporizador en Google Tag Manager

06/02/2015 a las 18:36

Una de las métricas que nos da señales de la efectividad de las páginas en un sitio, es la “Tasa de Rebote” o “bounce rate”, cuando esta métrica está en los extremos, ya sea baja, alta o de valor cero, es porque algo no anda bien con nuestro sitio o definitivamente algo en la implementación de Google Analytics no anda como debería.  Pero cómo saber si la tasa de rebote de nuestras páginas está indicando de manera verídica la efectividad de nuestras páginas, ¿Y qué pasa con aquellos sitios que tienen una única página?, ¿Cómo poder ajustar el rebote en estos casos?

Ajuste de rebote mediante temporizador en Google Tag Manager

Bueno, a través de la creación de eventos y etiquetas en Google Tag Manager, se puede lograr ajustar y calcular el rebote de forma más precisa, sobre todo para aquellos sitios de contenido como blogs y otros que solo puedan tener su contenido en una sola páginas.

Por lo tanto,  haciendo este evento vamos a poder diferenciar aquellas visitas genuinas, de aquellas que realmente abandonan sin ningún interés en nuestro sitio.

 

Ajuste mediante Temporizador:

Una de las soluciones que nos permite Google Tag Manager, a través de la creación de eventos, es no considerar rebote cuando una página lleva abierta cierta cantidad de tiempo sin ninguna interacción por parte del visitante, asumiendo que éste ha encontrado lo que busca, consume el contenido y luego se va, sin necesariamente contabilizarla como abandonada, sino más bien como una visita completada.

Para poder hacer esta acción, se tiene que crear un evento de temporizador para que cuando ocurra ese suceso, se accioné el evento tras pasado un tiempo determinado, de esta forma se cancelará el rebote y contabilizará la interacción especifica.

A continuación, lo primero por hacer es crear una etiqueta tipo “Procesador de temporizador” y nombre de evento “gtm.timer”.

 

Ajuste de rebote mediante temporizador en Google Tag Manager-2

Lo segundo es llenar los siguientes campos, así que mucha atención.

Ajuste de rebote mediante temporizador en Google Tag Manager-3

La etiqueta se activará, en este caso, después de un intervalo de 20 segundos que equivale a definir 20000 milisegundos, o el tiempo que se considere necesario para el sitio.

En relación al intervalo,  éste será “1”, ya que queremos que el evento se ejecute en cada visita una sola vez. En caso que quisiéramos que se active varias veces de manera cíclica, se coloca la cantidad de veces que queremos que se active el evento.

Una vez creado el evento que va a procesar esta interacción de tiempo, creamos una etiqueta que tendrá por objetivo capturar  el evento en Google Analytics.

Para eso vamos a nombrar la etiqueta como “UA-Tiempo de Interacción”, o como estimen conveniente,  en este caso seguirá siento de tipo Universal Analytics y con el código de seguimiento de su cuenta de Google Analytics “UA-XXXXXXXX-X”.

Ajuste de rebote mediante temporizador en Google Tag Manager-4

Si se fijan, en este caso he creado una macro llamada “Tracking id” de tipo “Cadena constante”, para así poder guardar el código de seguimiento. La ventaja de crear esta macro, es que previene posibles errores al momento de ingresar el código, así como también permite cambiarlo de manera fácil y rápida.

 

Ajuste de rebote mediante temporizador en Google Tag Manager-5

 

Lo que no pueden olvidar es colocar  valor “Falso” en la vista sin interacción, de esta forma contará como interacción y cancelará el rebote.

A un solo un paso de finalizar, lo siguiente es crear la regla de activación para que se capturen los datos cuando ocurra el evento gtm.timer, como se muestra en la captura de pantalla.

Ajuste de rebote mediante temporizador en Google Tag Manager-6

Ahora solamente tenemos que guardar y publicar, para que así se actualice la última versión. Y con esta acción, ya se estará cancelando el rebote de una visita que ha permanecido en una página sin hacer ninguna otra interacción, en un periodo mayor a  20 segundos.

Para saber si Google Analytics está capturando esta interacción, hay que buscar “Interaccion/timer 20s”  en los informes de Eventos de Google Analytics.

Otra forma de enterarse, es descargar la herramienta gratuita de Chrome haciendo clic acá.

gtm chrome event

Y luego ir a la página y verificar que se activó el evento pasado los 20 segundos.

Ajuste de rebote mediante temporizador en Google Tag Manager-7

Hay otras formas más óptimas de ajustar el rebote que mediante un evento de temporizador, esta opción no considera la posibilidad de que un visitante pueda dejar abierta la página sin necesariamente estar interactuando con ella, puede haberla dejado abandonada en alguna pestaña de su navegador o simplemente se fue a preparar un café, no lo sabemos. Es por esta razón que existen otras mejores opciones como la realización de un evento, donde se cancele el rebote a través de interactuar con el scroll de la ventada de navegación de la página, así como también considerar dos eventos conjuntamente, el de scroll más el temporizador, para así poder ajustar el rebote de un sitio con características que requieran ajustes, como por ejemplo aquellos que tienen una sola página, blogs o webs de contenidos, entre otros.

Pero las otras opciones se las comentaré en otro post de Doctor Metrics.

¡Hasta la próxima!

 

Posibles errores en el envío de eventos a través de GTM

13/01/2015 a las 11:51

 

peligro

 

A estas alturas, nadie duda de la comodidad (y la conveniencia en el 99% de los casos) de implementar Google Analytics a través de un gestor de etiquetas como Google Tag Manager (alias GTM). Pero hay que tener cuidado y saber muy bien como funciona para evitar errores como el que vamos a ver a continuación.

En una implementación directa, enviábamos los eventos mediante la inserción en nuestra página de un código con la siguiente sintaxis:

ga(‘send’,‘event’,‘category’,‘action’,‘label’, value);//value es un entero.

Ejemplo:  ga(‘send’,‘event’,‘button’,‘click’,‘nav buttons’,4);

Label y value son opcionales.

Con una implementación mediante GTM, ponemos esos datos en una estructura de datos llamada datalayer: 

dataLayer.push({‘event’:’eventoGA’,’category’:’<event_categoria>’,’action’:’<event_accion>’,’label’:’<event_label>’,’value':<event_value>});

Los recogemos de ella mediante una etiqueta de GTM que detecta que se ha producido un evento. Normalmente (y ahí está el problema), utilizamos etiquetas genéricas, que sirvan para todos los eventos posibles:

 

GTM_events_1

 

GTM_events_2

 

 

GTM_events_3

 

El datalayer es una estructura de datos persistente a nivel de página. Es decir, mantiene sus valores mientras no abandonemos la página actual (o los modifiquemos mediante una acción datalayer.push).

Movidos por la costumbre de cuando implementábamos directamente, cuando hemos de registrar un evento para el que no necesitamos los valores opcionales label y/o value, no los incluimos en el datalayer.push:

dataLayer.push({‘event’:’eventoGA’,’category’:’<event_categoria>’,’action’:’<event_accion>’});

Pero ojo, que ésto no manda el evento a Google Analytics. Es GTM quien lo hace. Y si utilizamos una etiqueta genérica como la que mostrábamos más arriba, estará enviando también valores para label y value. Presuntamente, no hay valores para ellos, por lo que enviará valores nulos, tal y como pretendemos.

Pero, ¿qué ocurre cuando en esa misma página se ha lanzado previamente un evento que sí utilizaba los citados parámetros opcionales? Al ser el datalayer persistente mientras no abandonemos la página actual, lo que ocurrirá será ésto:

 

EVENTO A :

dataLayer.push({‘event’:’eventoGA’,’category’:’ev_A_cat’,’action’:’ev_A_act’,’label':’ev_A_lab’,’value':9.99});

Lo que recogeremos y enviaremos a Google Analytics mediante GTM será:

Categoría: ev_A_cat

Acción: ev_A_act

Etiqueta: ev_A_lab

Valor: 9.99

 

EVENTO B (posterior al A, en la misma página, no usa label ni value) :

dataLayer.push({‘event’:’eventoGA’,’category’:’ev_B_cat’,’action’:’ev_B_act’});

Lo que recogeremos y enviaremos a Google Analytics mediante GTM será:

Categoría: ev_B_cat

Acción: ev_B_act

Etiqueta: ev_A_lab

Valor: 9.99

Nuestra etiqueta de GTM está buscando en el datalayer valores para esos dos últimos parámetros y los encuentra.

Puede parecer que no es un error grave (no se alteran los datos que sí necesitamos para los eventos de tipo B, pero si posteriormente realizáramos un análisis en base al número de eventos con un valor u otro en “etiqueta” o “valor”, obtendremos un número mayor del real de eventos que cumplan el criterio.

Para evitar que se nos “ensucien” los datos de eventos, proponemos dos soluciones:

A) Hacer etiquetas y reglas diferentes para eventos que no usen los campos opcionales. Por ejemplo, podríamos tener un evento de tipo ‘eventoGA1′ que solo usa categoría y acción y otro, ‘eventoGA2′, que los use todos. Habría una etiqueta para cada uno de ellos que solo enviaría a Google Analytics los valores requeridos. La regla que las dispararía comprobaría que el evento sea del tipo correspondiente:

 dataLayer.push({‘event’:’eventoGA1’,’category’:’ev_A_cat’,’action’:’ev_A_act’,’label':’ev_A_lab’,’value':9.99});

 dataLayer.push({‘event’:’eventoGA2’,’category’:’ev_B_cat’,’action’:’ev_B_act’});

B) Actualizar todos los parámetros en el datalayer para todos los eventos. Es decir, tratándolos como si no fueran opcionales. Esto nos permitiría mantener en GTM una etiqueta de gestión de eventos genérica. Dicha etiqueta mandaría siempre a Google Analytics todos los parámetros de evento, incluidos los opcionales. Pero, para los eventos que no los necesiten, pasaríamos sus valores a nulo (usando solo las comillas como valor):

dataLayer.push({‘event’:’eventoGA’,’category’:’ev_B_cat’,’action’:’ev_B_act’,’label':”,’value':”});

Nos inclinamos por la segunda opción. Mantiene una estructura más sencilla en el contenedor de GTM y no implica más trabajo de implementación en la web.

 

Medición de aperturas de una app desde referentes

02/12/2014 a las 11:05

 

pescando_smartphone

 

Excepto en aplicaciones de pago para smartphones (y ni tan siquiera en ellas, si lo pensamos bien), de poco sirve que los usuarios descarguen nuestras apps si luego no las van a utilizar o si las abandonan al poco tiempo de empezar a usarlas.

Quitando los casos de terminales con escasa capacidad de almacenamiento o de usuarios celosos de mantener “limpio” su equipo, muchos ni se molestan en desinstalarlas. Y es ahí donde podemos realizar algún intento de reactivación . Algunas apps utilizan un sistema de notificaciones para ésto, pero requiere su implementación y es posible desactivar las notificaciones por parte del usuario, por lo que no siempre funcionaría.

Una alternativa más sencilla a este tipo de intentos se puede emplear cuando la instalación de la app implicó alguna clase de registro y disponemos de las direcciones de correo electrónico a las que enviar una campaña a través de ese medio. En el mensaje que enviaremos, podemos  informar de las novedades y mejoras que hayamos podido introducir en la aplicación y animar a seguir usándola, incluyendo un enlace a la misma, la clave de este asunto.

En cualquier caso, sea cual sea el tipo de campaña de “repesca” que planeamos lanzar, os habréis dado cuenta de que cuando tocamos sobre un hipervínculo en nuestro smartphone o tablet, el sistema operativo nos da la opción de elegir la aplicación con la que lo podemos abrir.

Por ejemplo, para un enlace como el siguiente:

https://play.google.com/store/apps/details?id=com.mi_app&hl=es

Android nos mostraría las siguientes opciones:

 

completar_accion_con

 

Para que una aplicación esté incluida en la lista de aspirantes, en el fichero AndroidManifest.xml (para Android) o info.plist (para IOS) asociado a ella, debemos haber definido con qué tipo de protocolos es capaz de lidiar (https en este caso).

Para nuestra app, cuyo lanzamiento queremos provocar desde un enlace, podríamos incluso inventarnos el nombre de un protocolo, de manera que no haya otra app capaz de abrirlo y lo haga la nuestra directamente.

 

ANDROID:
Añadir tras <activity>:

<intent-filter>
<action android:name=”android.intent.action.VIEW” />
<category android:name=”android.intent.category.DEFAULT” />
<category android:name=”android.intent.category.BROWSABLE” />
<data android:scheme=”xxx” android:host=”yyy”/>
</intent-filter>

IOS:
<key>CFBundleURLTypes</key>
<array>
     <dict>
          <key>CFBundleURLName</key>
          <string>com.standalone.[ nombre de la app]</string>
          <key>CFBundleURLSchemes</key>
          <array>
                <string>xxx</string>
         </array>
    </dict>
</array>

 

Donde ponemos xxx figuraría el nombre o siglas para  el tipo de llamada ante la que respondería la aplicación. El host yyy sería el dominio ficticio que constaría en la llamada. Y el enlace que insertaríamos en el código HTML de nuestra campaña (anuncio en una web, correo, otra app, etc.), sería algo así (etiquetado para Google Analytics):

 

<a href=”xxx://yyy/?utm_source=Newsletterdeprueba&utm_medium=Email&utm_campaign=te_echamos_de_menos”>Pincha para abrir la app</a>

 

Es importante que este enlace incluya los parámetros de campaña habituales, ya que luego los recogeremos desde la app para atribuir la sesión al referente adecuado.

Google nos facilita el código que habría que añadir en la aplicación para realizar esa tarea, por lo que bastará con copiarlo en ella.

 

ANDROID: https://developers.google.com/analytics/devguides/collection/android/v3/campaigns

IOS: https://developers.google.com/analytics/devguides/collection/ios/v3/campaigns

 

Con estas sencillas modificaciones seremos capaces de medir en Google Analytics la efectividad de nuestros esfuerzos a la hora de recuperar a esos usuarios que perdieron interés por nuestra aplicación para smartphone o tablet.

ga_app_adq

 

Metriplica, el mejor servicio de analítica web 2014

04/11/2014 a las 16:52

premio

No lo decimos nosotros, sino quienes han confiado en nuestra propuesta y nos han dado su apoyo y reconocimiento. A todos ellos, clientes, colegas de profesión, compañeros de viaje y amigos, les damos nuestro más sincero agradecimiento y les dedicamos este premio, el eawards Madrid 2014 como “Mejor servicio de Analítica Web“, categoría donde, tras ser seleccionada de una amplia lista de candidatos, Metriplica era finalista.

Los eawards, premios a los mejores negocios online, contaron este año con la participación de 151 candidatos, que se presentaron en distintas categorías tales como “Mejor empresa de Social Media”, “Mejor servicio de logística”, “Mejor agencia de creación y diseño de Tiendas Online”, entre otras.

Y es que, pese a haber sido pioneros en España en temas de analítica web, seguimos innovando con servicios como la medición de tiendas físicas, divulgando mediante nuestro blog y nuestras participaciones en diversos eventos y foros de encuentro, así como formando a través de nuestros cursos online.

Esperamos poder seguir haciéndolo por muchos más años, porque detrás de todo ello, lo que hay es un equipo de personas apasionadas por su trabajo, que no escatiman en esfuerzo, dedicación e ilusión ni un solo día.

Gracias de nuevo de parte de todos nosotros: Anna, Dani, David, Enric, los dos Felipes, Fernando, Julià, María, Marta, Nuria, Pol, Raúl, Richard, Vicente, Xavi, así como los que formaron parte del equipo en algún momento y los que se van a incorporar a esta gran familia que no para de crecer.

img_821

Metodología de Optimización

31/10/2014 a las 10:24

Antes de empezar con la metodología vamos a ver que es esto del CRO, que no y por qué es importante.


¿Qué es Optimización?

Si buscamos Optimización en el RAE nos lo define como: “buscar la mejor manera de realizar una actividad”, por lo que aplicado al mundo Web podríamos decir que es mejorar los procesos claves de la web para conseguir que los usuarios tengan una experiencia de uso más satisfactoria y en consecuencia aumentar los ratios de conversión


¿Qué no es Optimización?

– Cambiar el color de los botones o el tamaño de las imágenes por probar, no tiene sentido empezar a probar cosas sin una lógica, sin haber detectado un error o una posible mejora.

– Hacer cambios basándose en opiniones personales y mejores prácticas, porque no siempre lo que funciona para unos tiene que funcionar para otros, lo que si hay son estrategias y métodos que te pueden ayudar a averiguar que no funciona en tu web y arreglarlo. Porque optimizar tu web no es como jugar a los Lemmings donde todos hacen lo mismo.


La importancia de la optimización de tu sitio web

¿Por qué deberías hacer CRO en tu web? El principal motivo para realizar CRO es el “show me the money ”.

show-me-the-money

Si estamos atrayendo cada vez más usuarios a través de campañas de PPC o Email Marketing (que por cierto, ellos si que están optimizando constantemente), pero una vez llegan a nuestra web los perdemos estamos dejando de ganar dinero y perdiéndolo en las campañas.

Si somos capaces de mejorar nuestro ratio de conversión en la web, no solo ganaremos más dinero, sino que las campañas de atracción se podrán optimizar todavía mejor y además estarán mejor situadas.

Hay que destacar que la parte de la conversión es la más complicada de todas., por lo que hay que prestarle especial atención.

atraccion

Y si esto no es suficiente por si solo, además te ayudará a mejorar la experiencia de usuario, ya que podremos mejorar la facilidad de uso de nuestro site adaptado a lo que buscan nuestros clientes favoreciendo que tengan una percepción positiva sobre nuestros productos y/o servicios, que a la vez se puede transformar en un aumento de los ratios de conversión.

Después de ver porque deberías hacer optimización en tu web vamos a definir brevemente los diferentes pasos de que consta.

Como hemos dicho, las “best practices” no siempre son unas buenas aliadas pues cada negocio tiene un contexto diferente y lo que le va bien a una web es muy probable que no funcione en otra. En lo que si creemos es estructurar el proceso de optimización y seguir una metodología.

El no tener el proceso de optimización estructurado puede tener una serie de problemas como:
– Test que duran demasiado tiempo
– No tener claro que testear
– Malos resultados
– No se sacan conclusiones ni se aprende nada
– Problemas técnicos

Así que vamos con una metodología que puede ayudar a mejorar tus procesos de optimización:

optimization project
Paso 1 – Investigación

– Tener claro los objetivos de la empresa:
Si trabajas en esa compañía ya deberías saberlos, pero si eres una agencia o freelance no hay mejor manera que preguntar, al responsable de eCommerce, al de ventas, etc.…

– Conocer a tus clientes, que buscan en tu web:
Es indispensable conocer a tus usuarios, uno de los principales fallos no solo a la hora de planificar los test sino incluso de diseñar la web entera es que no conocemos a nuestros usuarios y clientes potenciales en la red y no diseñamos la web de acuerdo a sus necesidades y objetivos.

Para esta parte podemos usar los datos cuantitativos obtenidos a través de la herramienta de analítica que estemos utilizando, y además es recomendable recopilar datos cualitativos a través de encuestas online, encuestas por email (a posteriori) u otras herramientas como user tests que nos ayudarán a entender cuales son sus objetivos, donde no estamos cumpliendo sus expectativa y en definitiva nos ayudarán a decidir que partes son las que están fallando para testear nuevas propuestas.

Hemos de tener en cuenta que en nuestra web tendremos usuarios diferentes, que nos visitarán con diferentes propósitos y que tendrán diferentes percepciones de nuestro producto pero que nuestra web será la misma para todos, por lo que también tendremos que decidir si decidimos hacer experimentos que afecten a todos los usuarios de nuestra web o por si el contrario decidiremos hacer experimentos por segmentos.

Adults-Perception-Model

– Conocer bien tu web:

Para empezar no estaría mal realizar un compra (o bajarse un folleto, o generar un lead, … cualquiera que sea el objetivo de la web) y ver como funciona el proceso de primera mano. No sería la primera vez, ni la última, que se empiezan a mirar datos y a planear cosas sin ni siquiera haber visto el proceso de compra en primera persona.

Una vez visto esto ya podemos empezar a echar un ojo a los datos, lo cual hace indispensable disponer de una herramienta de medición donde podamos ver por donde vienen nuestros usuarios, por donde se van, los embudos, demografía, tasas de conversión….

Herramientas que pueden ser útiles en este paso: SurveyMonkey, ClickTail, Inspectlet, …

 

Paso 2 – Listado de problemas y creación de hipótesis

Escribe la lista de todos los problemas que has ido encontrando en la primera fase y priorizarlos.

Definir que vamos a testear, a quién (segmentar usuarios o no), dónde (qué páginas), cuando, … Las mejores páginas para testear son las que tienen mucho tráfico y problemas:

trafico-problemas

Hay miles de elementos que podemos testear, pero los vamos a clasificar en tres ejes:
– Problemas funcionales:
– Problemas de accesibilidad
– Problemas de usabilidad

Una vez definido todo lo anterior es el momento de crear hipótesis y propuestas de mejora que sean suficientemente significativos y persuasivos para nuestro propósito, que es mejorar la conversión

Herramientas que podemos utilizar: Google Analytics nos puede ayudar a ver que páginas son las que tienen más tráfico, más salidas, etc …

 

Paso 3 – Experimentos

En este tercer paso ya toca meterse de lleno en los test. Lo primero será diseñar las alternativas a testear. Hay que tener en cuenta que los cambios que se quieran proponer tienen que ser técnicamente viables, por lo que sería conveniente hablar con el departamento de IT, el desarrollador web, diseñador web, etc. responsable para verificar que no vamos a probar algo que luego no se podrá implementar.

Es el momento de poner a prueba esas hipótesis mediante experimentos.

testAB

Ejemplos de herramientas que puedes utilizar para realizar tus test: Optimizely, Virtual Website Optimizer, …

 

Paso 4 – Análisis de resultados

Analiza los resultados. Qué hipótesis han funcionado, cuales no, …. Etc.
La hipótesis ha sido correcta, ¡genial! Quizás ahora es el momento de hacer los cambios en la web. Qué la hipótesis no ha sido correcta, no pasa nada, muchas veces ocurre y de los “no” también se aprende y se sacan conclusiones.

También hay que tener en cuenta que la muestra haya sido estadísticamente significativa, sacar conclusiones de 10 visitas no nos va a decir mucho.

Herramientas: Para analizar los resultados del experimento podremos utilizar la misma herramienta con la que hemos realizado el test.

 

Paso 5 – Repetir

El otro día leí esta frase en twitter en temas de empresa, pero que también se puede usar en temas de optimización y es que la optimización es como en los videojuegos hay que “Guardar y seguir jugando”.

Seguro que más de uno leyendo esto ha jugado a videojuegos, cuantos os pasasteis una pantalla de Super Mario Bros y la volvisteis a jugar hasta coger todas las monedas, o cuantos habéis jugado a algún juego de rol y habéis repetido la misma pantalla hasta conseguir todas las armas o encontrar la más poderosa de todas? Seguro que más de uno ; )

marioworld

En optimización web es más de lo mismo, imaginamos que la página que decidimos optimizar es como una pantalla de un videojuego, tenemos una hipótesis, la probamos, y si funciona bien la implementamos en la web, ¿pero con pasarnos esa pantalla ya vale? ¿O aun podemos mejorar? Aunque el test haya funcionado ¿seguro qué no hay otra opción que funcione aun mejor? Posiblemente si, es por eso que hemos de guardar ese cambio y seguir jugando y probando nuevas hipótesis, el proceso de optimización no acaba nunca, siempre hay algo que se puede mejorar.

Como hemos dicho al principio del post hacer CRO es encontrar fallos en la web y arreglarlos, pero también es mejorar lo que ya funciona, así que ¿a qué esperaras para optimizar tu web?

 

¿Por qué debo creerme una métrica calculada a partir de una muestra si cambiando la muestra cambiaría el valor?

25/09/2014 a las 15:10

Esta es una pregunta que, como estadística, me han hecho incontables veces y muchas de ellas en el entorno del samplig (injustamente tratado de forma habitual como el demonio) de Google Analytics.

Dado este fenómeno reiterado he creído que era un buen tema a tratar en un post.

muestreo

La respuesta constituye la esencia de la teoría del muestreo estadístico y para responderla vamos a focalizarnos en el tiempo medio en el site. La clave reside en las buenas propiedades de los estimadores utilizados habitualmente, entre ellos por supuesto la media, que son las siguientes:

1. El valor medio de la media muestral coincide con la media poblacional.

Es evidente que la media varía de una muestra a otra (si de un total de 1000 visitas cojo una muestra de 100 el tiempo medio será uno, si cojo otra muestra de 100 el tiempo medio será distinto seguro). Sin embargo, si repitiéramos este proceso de substraer muestras (cosa que no hacemos en la práctica), todos estos valores distintos de la media muestral estarían agrupados (con mayor o menor dispersión) entorno a la media poblacional. Cuando un estimador tiene esta propiedad se dice que es un estimador insesgado.

Esto nos deja algo más tranquilos pero no del todo ya que, como hemos apuntado antes y seguro que está retumbando en vuestra mente, nosotros solo tenemos una de esas estimaciones y por tanto desconocemos si está cerca o lejos de la media poblacional también desconocida que queremos estimar.

Para quedarnos más tranquilos sobre este aspecto tenemos la segunda propiedad.

2. La variabilidad del estimador (media muestral) disminuye al aumentar el tamaño de muestra.

Los datos en sí tienen una variabilidad que a menudo olvidamos pero que siempre está allí y conviene tener presente como comentamos en anteriores posts. Conocer dicha variabilidad ya presente en los datos poblacionales (todas las visitas de mi site no están el mismo tiempo en él) nos permite calcular el tamaño necesario de muestra para que, por ejemplo, el 99.7% de las medias muestrales estén a una distancia de menos de dos unidades de la media poblacional.

De esta forma, mediante cálculos estadísticos, se puede determinar cuál es el tamaño de muestra necesario para garantizar esta precisión en nuestra estimación (para vuestra tranquilidad diré que el tamaño de muestra no crece proporcionalmente al tamaño de la población, tema que trataremos en otro post si queréis). Este es un trabajo que, en el caso del sampling en los reports de Google Analytics, desempeña Google sin dar demasiadas explicaciones al respecto. Se trata una vez más de un acto de fe por nuestra parte (no mayor a los que hacemos habitualmente) que consiste en creer que el equipo de Google tiene conocimientos básicos de muestreo estadístico. Preguntarse por qué no dan detalles sobre ello es natural en el caso de personas curiosas y os aseguro que a mí me ha pasado reiteradas veces, pero reflexionando en frío debemos pensar que tampoco nos dan detalle de muchos otros aspectos técnicos ni creo que puedan hacerlo dado que estarían haciendo público su producto. En el caso del muestreo resulta tan claro y evidente cómo se debe hacer que es impensable que Google no lo gestione de la forma adecuada.

Así que, a pesar de conocer una única estimación del valor que queremos conocer, sabemos que “casi” en todos los casos va a estar muy cerca del valor poblacional. Cuando haces una estimación de este tipo no puedes asegurar que tu estimación no sea una de esas tres de cada mil que caen más lejos de la media poblacional, pero este es un riesgo que debemos estar dispuestos a asumir SIEMPRE que trabajemos con estimaciones estadísticas (encuestas, tests de calidad en procesos industriales, estudios de mercado, etc.). Trabajando con el umbral del 99.7% tenemos que pensar que, el hecho de que nuestra media quede a una distancia superior a la de dos puntos es como si compráramos 997 boletos en una rifa con 1.000 boletos a la venta y no nos toca el premio (hay que ser muy gafe para que esto pase).

Resumiendo: que siempre que queremos hacer cálculos en base a una muestra corremos el riesgo de equivocarnos, pero este riesgo se puede controlar :)

El tiempo es oro: tiempos de página y tiempos de usuario en Google Analytics

04/09/2014 a las 12:35

 

Vivimos con prisa y el dicho de que el tiempo es oro es más cierto que nunca.

Sin embargo, en el terreno de la analítica web, los análisis de tiempos parecen unos segundones (cuando no se olvidan por completo). Al  hablar de tiempo, nos referimos a dos tipos de métricas diferentes: los tiempos de página (site speed) y los tiempos de usuario (user timings), ambos, localizados dentro de la sección “Comportamiento” de Google Analytics.

 

Tiempos de página

No vamos a decir nada que no sepamos todos ya, pero nunca está de más un recordatorio para no perder de vista aquello que es importante. Los tiempos de carga de nuestra web son críticos. Y no solo porque, como todo iniciado en SEO sabe, los buscadores favorecen en su posicionamiento a las webs más  optimizadas, sino porque no todo el mundo tiene el mismo ancho de banda. Esto último es especialmente importante si parte de nuestra audiencia potencial procede de zonas rurales o de países en vías de desarrollo.

 

mapa_t

tabla_t

 

¿Tendrán los internautas de las zonas con peores anchos de banda  la paciencia suficiente para moverse por nuestro sitio web si éste no está bien optimizado en cuanto a velocidad de carga?

t_rebote

 

En este ejemplo, se aprecia una tasa de rebote claramente superior a la media para las regiones con tiempos medios de carga más altos. Y en mayor o menor medida, la pauta se repite para otros muchos sitios revisados. Hay más factores, desde luego, pero un tiempo de carga de la página de más de medio minuto,  no ayuda.

Hay que tener en cuenta que para la obtención de estos tiempos se mide, por defecto, un 1% de las sesiones. Este porcentaje se puede modificar introduciendo la siguiente línea en el código de seguimiento, antes de enviar la página vista.

Por ejemplo, en Classic, podríamos cambiar el 1% de muestra por un 5% mediante

_gaq.push([‘_setSiteSpeedSampleRate’, 5]);

situado antes de _gaq.push([‘_trackPageview’]);

En Universal Analytics, ese parámetro lo cambiaríamos en

ga(‘create’, ‘UA-XXXXX-Y’, {
‘cookieDomain': ‘xxxxxx.com’,
‘siteSpeedSampleRate': 5
});

 

Antes de lanzarnos a poner un 100%, hay que saber que hay límites en función del volumen de tráfico del site. A partir del millón de hits diarios, Google Analytics no recogerá más del 1%, no importa que hayamos especificado un porcentaje mayor.

 

Si los resultados obtenidos no son todo lo buenos que quisiéramos,  podemos detectar puntos de mejora concretos en este terreno,  mediante herramientas como la extensión del navegador Firebug con su plugin Yslow.

 

p_yslow

Fuente: Yslow.org

Otra herramienta gratuita similar es Google PageSpeed, cuya API nos permite personalizar la manera en la que se muestran los resultados de la evaluación que hace de nuestra página, encolar la evaluación de múltiples páginas sin tener que hacerlo una a una a mano, etc.

pagespeed_API

Google Analytics, para estos informes, calcula los tiempos de carga  de la misma  manera que dichas herramientas, aunque no entre en detalle sobre recomendaciones, ya que no es su fin.

 

Tiempos de usuario

Este tipo de métricas no son tan conocidas, ni su utilidad tan  evidente, pero la tienen. Se trataría de mediciones personalizadas sobre elementos determinados. Aclararemos lo que significa ésto un poco más adelante.

Por defecto, este informe está en blanco, ya que se requiere cierta implementación por nuestra parte. El comando a utilizar es:

ga('send','timing','timingCategory','timingVar', timingValue);  // para Universal Analytics

o

_gaq.push([‘_trackTiming’, category, variable, time, opt_label, opt_sample]); // para Classic

En él,  indicamos la categoría del tiempo medido, su nombre y su valor para esta medición en concreto (esos son los parámetros obligatorios). Podríamos tener una categoría para los tiempos de carga de imágenes, otra para medir los tiempos de reproducción de los videos que tengamos en él, otra para recoger el tiempo empleado en interactuar con formularios u otros elementos, etc.

Como se puede ver en los ejemplos de categorías que damos, este tipo de métricas  nos pueden servir para analizar los tiempos de carga  de elementos específicos de la web, el grado de interés que despiertan nuestros contenidos y posibles problemas de usabilidad (correlación entre tiempos altos a la hora de rellenar un formulario, por ejemplo, y la tasa de abandono). Para este último uso, no serviría recurrir a la métrica “promedio de tiempo en página” cuando en una página hay más de un elemento al que pueda dedicar su tiempo el usuario.

cronometro

 

El tiempo a enviar mediante ese comando se calculará restando el tiempo (newDate().getTime()) del momento en el que termina el hecho que queremos medir (click en el botón “stop” de un video,  cuando se ha terminado de cargar una librería, cuando enviamos el formulario…) al momento inicial (click en el botón “play”, comienza la carga del script, comenzamos a rellenar el primer campo del formulario, etc.).

Es interesante incluir código que descarte tiempos menores que cero o anormalmente altos, para eliminar irregularidades (como el que el usuario cambie la hora del ordenador durante el proceso) que puedan afectar a los valores total y medio.

A la hora de mostrar los resultados de nuestras mediciones, disponemos de tres tipos de informe:

-Explorador: una tabla que nos mostrará por categoría de medición o en más detalle, para elementos concretos,  los tiempos medios y el número de muestras con las que se han calculado.

user_timing_1

user_timing_2

 

-Distribución: englobará las diferentes muestras en rangos de tiempo, para que podamos ver la distribución y descartar los extremos, si fuera necesario.

ut_distr

-Gráfico de visitas por ubicación: aquí volvemos a relacionar tiempos y ubicaciones geográficas, mediante un mapa como el que mostrábamos para los tiempos de página.

 

Resumiendo

Si le damos a la eficiencia de nuestra web la importancia que merece, tenemos a nuestro alcance las herramientas que nos permitirán optimizarla en ese sentido y en base a un análisis todo lo pormenorizado que queramos.