Herramientas de participación de Firebase: A/B Testing

Aquí llega el tercer post de nuestra serie de artículos sobre la sección de participación de Firebase.

Sí, habéis leído bien, Google ha vuelto a hacer un cambio de naming y ya no es ni crecimiento ni interacción, sino participación. Este nuevo nombre se debe a que desde la propia marca quieren reflejar mejor el carácter colaborativo de estas herramientas y sus posibilidades de integración con otras plataformas y funcionalidades.

Dejando el tema del nombre aparte, hoy nos vamos a centrar en A/B Testing, una herramienta totalmente gratuita que permite llevar a cabo experimentos A/B, dicho en otras palabras, compara la versión original de nuestra app con una o más variantes y nos dice cuál de ellas funciona mejor. Así podemos ir optimizando nuestra aplicación de manera continua y conseguir el mejor rendimiento posible (si lo que quieres es realizar un test A/B en una web —y no en una app— te recomendamos este artículo en el que te contamos cómo lanzar un experimento en Google Optimize).

Suena interesante, ¿no? Y si además se pudiesen hacer tests no solo con el contenido y el diseño, sino con todo tipo de notificaciones y mensajes dentro de la aplicación, ¿no sería todavía más útil?

Pues tenemos buenas noticias porque, gracias a todo lo que hemos aprendido en los anteriores posts sobre Remote Config, Cloud Messaging e In-App Messaging, vamos a ser capaces de hacer todo esto y mucho más.

Ahora sí, ha llegado la hora de empezar de verdad con A/B Testing.

A/B Testing para Remote Config

Empezamos combinando A/B Testing con Remote Config, que como ya sabemos es otra de las herramientas de participación de Firebase y sirve para editar y personalizar el aspecto y el comportamiento de nuestra aplicación sin tener que pasar por el proceso de actualización.

En este caso vamos a ir un poco más allá y vamos a ver con datos reales y concluyentes si sería buena idea aplicar de forma indefinida los cambios que habíamos pensado implementar con Remote Config.

Requisitos

Realmente, según Google, A/B Testing no tiene más requisitos que implementar en la app la funcionalidad sobre la que vayamos a hacer los experimentos, en este caso Remote Config.

Si ya tenéis Remote Config instalado os podéis saltar esta parte, sino toca hacer un poco de memoria y recordar que Remote Config necesitaba de una instalación específica para cada alternativa que ofrece Firebase, siendo estas las opciones disponibles hasta la fecha:

• Android
• iOS
• JavaScript
• C++
• Unity
• REST

Una vez más, esta parte habría que dejársela a las personas del equipo que tengan un mayor conocimiento sobre programación, así que nos tocaría pedirles ayuda a ellos.

De forma secundaria, también habría que habilitar la integración entre Firebase y  Google Analytics. Este requisito no está entre las especificaciones que realiza Google en sus guías de implementación, pero sí que nos va a hacer falta contar con Google Analytics para poder disfrutar de muchas de las opciones de segmentación y también para configurar y medir las conversiones en función de las que se va a escoger la versión ganadora, por lo que sí, Google Analytics es totalmente necesario.

Finalmente, el último de los requisitos, y realmente la razón de existir de esta funcionalidad, es tener una hipótesis que queramos comprobar y que pueda ser aclarada mediante un test A/B.

Funcionamiento

Ahora pasamos a lo verdaderamente interesante: aprender a usar A/B Testing con Remote Config.

Lo primero de todo sería ir a la interfaz de Firebase y, dentro de la sección de participación, localizar A/B Testing.

Lo normal es que si no tenemos ningún experimento habilitado, nos encontremos con un panel vacío donde, aparte de cierta información introductoria acerca de la herramienta y un pequeño vídeo publicitario de la misma, podremos crear nuestro primer experimento.

También se nos avisa de que nuestra versión de A/B Testing es una beta que puede sufrir algunos cambios. No os preocupéis, lleva en versión beta desde 2017 y lo único que se ha hecho desde entonces es añadir la opción de crear experimentos A/B con las notificaciones.

Después de hacer click en el botón de Crear experimento se abrirá un panel donde podremos elegir qué tipo de experiencia queremos crear. Aquí ya sabemos que sería Remote Config.

1. Aspectos básicos

Empezamos con la configuración de nuestro experimento de Remote Config definiendo los aspectos básicos del mismo, es decir, un nombre interno para la experiencia y una breve descripción que lo acompañe.

Lo primero que nos llamará la atención es que hay una alerta avisando de que el tiempo máximo de duración del experimento son 90 días. Es un periodo predeterminado y, al menos de momento, inamovible, así que bastaría con tenerlo en cuenta a la hora de diseñar el test. 

El nombre que escojamos debe ser de por sí bastante aclarativo y darnos a entender de qué tipo de experimento se trata y sobre qué se está haciendo la prueba. Todo esto en un máximo de 50 caracteres.

Adicionalmente, y de forma opcional pero totalmente recomendable, podremos agregar una descripción que sirva para detallar más extensamente en qué consiste el experimento. Si bien no hay límite de caracteres, no se aconseja emplear más de 90, ya que si se hace una descripción muy larga más tarde no se visualizará correctamente en la interfaz de Firebase.

2. Segmentación

Después pasaríamos a la segmentación, en otras palabras, a decidir qué grupo de usuarios va a participar en este experimento.

Hay que empezar escogiendo una de nuestras apps. Algo importante a tener en cuenta es que cada experimento puede hacerse sobre una única aplicación, por lo que si por ejemplo quisiéramos hacer un test A/B sobre la versión para Android y la versión para iOS de una misma aplicación, tendríamos que configurar dos experimentos por separado.

Esto tiene todo el sentido del mundo, si se tiene en cuenta que cada versión de la aplicación tendrá su propio formato y contenido y, por lo tanto, también patrones de uso diferentes.

Una vez elegida la aplicación móvil sobre la que se hará el experimento, se puede segmentar aún más. Esta opción está un poco escondida, pero si clicamos en la “y” de la derecha, se nos habilitará un desglegable con todos los posibles criterios de segmentación.

Como se puede ver, es una segmentación parecida a cualquiera que nos podamos encontrar en otras de las herramientas de Google y que nos va a permitir crear una audiencia más específica en función de:

• Versión: es la versión de la app que el usuario tiene instalada.
• Número de compilación: esta es una opción que posibilita segmentar según la versión de compilación del paquete de iOS o Android.
• Idiomas: este sería el idioma que el usuario tiene configurado en su dispositivo.
• País o región: localización geográfica del usuario en función del país en el que se ubique. Si bien pone que también existe la opción de segmentar según la región, esta alternativa no está realmente disponible.
• Públicos de usuarios: se refiere a las audiencias que se hayan creado en la interfaz de Firebase y que se pueden consultar en la sección Audiences. Además, siempre vamos a tener las audiencias predeterminadas All Users y Purchasers.
• Propiedad del usuario: estas son las audiencias que hemos configurado dentro de Google Analytics y que se han importado a Firebase en el proceso de integración de ambas herramientas.
• Predictions: otra de las herramientas de participación de Firebase que hemos visto en posts anteriores ha sido la de Predictions, que como recordaremos servía para predecir el comportamiento de los usuarios en relación a la app.
• Versión heredada de Predictions: esta es la versión anterior de Predictions que ya no está disponible, pero de la que aún se pueden extraer las predicciones relacionadas con la desinstalación de la aplicación (churn) y las compras dentro de la app (spend). No obstante, estos dos eventos también los podemos encontrar en la versión actual, así que recomendamos optar por ella.

Seguidamente habrá que escoger la exposición o visibilidad del experimento. Este lo que hace es coger un porcentaje del total de los usuarios que coincide con los criterios establecidos en el punto anterior y hace que solo ese pequeño porcentaje participe en el experimento.

Normalmente se establece una exposición de en torno al 5% – 10% para que el test A/B afecte lo mínimo posible al rendimiento de la app.

Algo interesante es que aquí se puede ver una aproximación del número de usuarios que formarán parte del test. Esto puede servir como una herramienta para saber si la segmentación que estamos definiendo es correcta, demasiado amplia o demasiado restrictiva.

El peor de los casos sería este último, ya que querría decir que no va a haber una audiencia suficiente como para obtener un resultado concluyente del experimento.

Por último, existe la opción de fijar un evento de activación para condicionar la inclusión de los usuarios en la medición del experimento a que estos hayan realizado una acción específica dentro de la app.

Se puede escoger tanto un evento automático como uno personalizado.

Es frecuente utilizar un evento de activación cuando se quiere filtrar todavía más los usuarios que van a formar parte del experimento.

Un uso muy común es cuando se trata de orientar el test A/B mediante el evento sign_up hacia usuarios que utilizan por primera vez la app, a usuarios que han iniciado la sesión a través de una notificación, es decir, que han activado el evento notification_open o incluso para usuarios que han fallado un nivel de un juego con el evento level_end.

Todas estos filtros de usuarios se podrían hacer usando una audiencia específica que incluyera estos eventos como criterios de inclusión.

Sin embargo, haciéndolo con los eventos de activación nos a aseguramos de que estas segmentaciones funcionan correctamente, ya que no se filtra a los usuarios en el momento de muestreo definido por los filtros anteriores, sino en un instante posterior en el que toda la segmentación previa ya ha surtido efecto, consiguiendo así un doble filtro que aporta mayor seguridad y certeza.

3. Objetivos

Hecha la segmentación, pasaríamos a elegir los objetivos, esto es, los eventos que van a determinar cuál de las variantes es la ganadora.

Antes de pasar a seleccionar un objetivo de la lista, hay que recordar qué indicador queríamos mejorar mediante las modificaciones con Remote Config y tomar una decisión sobre qué métrica se verá más afectada tras la activación de este experimento, ya que ese será el evento que definamos como objetivo.

Entre los eventos susceptibles de ser escogidos como objetivos, por un lado están aquellas métricas predefinidas relacionadas con el nivel de ingresos y la retención de usuarios a lo largo del tiempo.

Además, si se hace algo más de scroll aparecerán todos los eventos automáticos y los personalizados que hayamos creado y, si ninguno de los anteriores nos encaja, desde aquí podríamos llegar a activar uno nuevo con solo introducir un nombre que no esté en el listado.

De forma complementaria se pueden añadir otras 5 métricas adicionales, las cuales no se tendrán en cuenta para escoger la variante ganadora, pero sí para darnos algo más de información sobre el funcionamiento del cambio introducido a través de Remote Config. Servirá sobre todo para asegurarnos de que mientras mejoramos la métrica u objetivo principal, no estamos perjudicando el resto de aspectos y objetivos secundarios.

Nosotros aquí, como norma general, recomendamos usar una métrica secundaria relacionada con la retención para cerciorarnos de que ninguna modificación tenga como consecuencia el abandono o desinstalación de la app.

4. Variantes

Ahora ya entramos con lo que sería la configuración de las variantes, donde para cada variante se asigna un valor diferente a uno o varios parámetros de Remote Config, creando así distintas variaciones de un mismo elemento.

El primero de los bloques siempre va a corresponder al modelo de referencia o grupo de control, es decir, a cómo se está mostrando la app a día de hoy. Si bien se puede editar, se recomienda no modificar nada en este campo para que las variantes se comparen con la versión actual de la app y sepamos cómo de bueno o malo sería el cambio con respecto a lo que tenemos ahora.

El dejarlo en blanco no quiere decir que se vaya a mandar un campo vacío, sino que se enviará el valor por defecto que tengamos introducido en el código de la aplicación.

Una vez tengamos seleccionado el parámetro en el modelo de refererencia, pasaríamos a configurar nuestras variantes. 

Para ello bastaría con seleccionar en el desplegable el parámetro que se quiera modificar y en la casilla contigua añadir su nuevo valor. Este parámetro debe existir ya dentro de la app y ser de los personalizados, no pudiendo alterarse aquellos parámetros automáticos.

No solo se puede alterar un parámetro por variante, sino que se pueden hacer experimentos multivariante modificando múltiples aspectos técnicos y estéticos de la app dentro de una misma versión.

Lo que pasa es que si se opta por hacer esto, después es muy complicado interpretar los resultados del experimento y decidir cuál de los cambios dentro de una misma variante es el que realmente ha supuesto la diferencia. Así que tened esto en mente si os animáis a crear variantes con más de un más de un parámetro.

En total, se pueden llegar a crear hasta 7 variantes distintas, teniendo así 8 versiones diferentes de la aplicación funcionando de forma simultánea (1 versión original + 7 variantes).

Como advertencia adicional, hay que tener en cuenta que mientras estemos realizando este experimento no se deben alterar los valores de cualquiera de los parámetros que estemos utilizando dentro del test, ya sea dentro del código interno de la app o mediante Remote Config, ya que se ensuciarían irremediablemente los resultados del experimento.

Para terminar de configurar nuestro test A/B de Remote Config solo nos quedaría el escoger el peso de cada una de las variantes, o explicado de forma más sencilla, de los usuarios que entran dentro del experimento, qué porcentaje va a ver una variante y qué porcentaje va a ver la otra.

Por defecto, esta ponderación está hecha para que los porcentajes se distribuyan de forma igualitaria entre todas las versiones y, de hecho, lo mejor sería dejarlo así para no influir en el resultado del test dando una mayor priorkdad a alguna de las variantes.

De cualquier forma, en caso de ser necesario, se podría cambiar esa asignación en los recuadros del margen inferior. Además, cualquier cambio en los relativo al peso de las variantes debe hacerse antes de comenzar el experimento, ya que una vez iniciado, estos porcentajes no se podrán modificar.

Y ya está, con esto ya tendríamos configurado nuestro experimento de A/B Testing para Remote Config.

A/B Testing para Cloud Messaging

Como ya hemos dicho al inicio de este post, no solo se pueden hacer experimentos con el diseño y el funcionamiento de la app, sino que también se pueden hacer pruebas con las notificaciones push de la app, esas que nos llegan a nuestro móvil cuando tenemos cerrada la aplicación.

Requisitos

Aparte de la vinculación entre Firebase y Analytics que mencionábamos anteriormente, para poder hacer experimentos de A/B Testing con Cloud Messaging será imprescindible agregar esta funcionalidad a nuestra aplicación.

Para ello tendremos que pedirle a nuestro equipo de IT que configure el SDK de Firebase Cloud Messaging con la última versión disponible.

Una vez lo tengáis todo listo, podemos pasar a la configuración del experimento.

Funcionamiento

La creación de un experimento de Cloud Messaging es bastante similar a lo que ya hemos visto en la parte de Remote Config, pero sí que es cierto que tiene algunas especificidades dignas de mención.

Lo primero será ir a Participación > A/B Testing y añadir un nuevo experimento de “Notifications”.

1. Aspectos básicos

En esta primera parte vamos a tener que escoger un título y si queremos una descripción que la acompañe. Aquí seguiremos las mismas indicaciones que en el caso de Remote Config, procurando que ambas sea lo suficientemente claras como para permitirnos saber de un vistazo de qué experimento se trata y en qué consiste.

Como gran diferencia, la segmentación de usuarios también formaría parte de los aspectos básicos. En lo que respecta a su configuración tendremos que partir escogiendo una de nuestras aplicaciones, ya que aquí tampoco podremos lanzar un experimento para varias apps de forma simultánea.

Después solo quedaría definir el resto de criterios que van a ser exactamente los mismos que los de Remote Config. Os dejamos aquí la lista para que podáis refrescar la memoria:

Después solo quedaría escoger el porcentaje de exposición, que en su momento definimos como el porcentaje de usuarios que coinciden con las condiciones anteriores y que van a formar parte del experimento.

2. Variantes

En segundo lugar tendríamos que definir las variantes, que en este caso van a ser los distintos mensajes que los usuarios van a recibir a modo de notificación externa.

Como siempre, vamos a tener un modelo de referencia. Sin embargo, como no hay un valor por defecto para el texto del mensaje de las notificaciones, si dejamos este campo en blanco, los usuarios que vean esta variante no recibirán ninguna notificación.

Esto puede ser muy útil para comprobar la efectividad de mandar una notificación versus el no enviar nada. Si por el contrario, estamos totalmente seguros de que queremos que nuestros usuarios reciban mensajes directos por nuestra parte, tendremos que configurar ambos cuerpos del mensaje.

Esta vez rellenaremos ambos casos para ver si el reclamo de un 10% (ficticio) de descuento es realmente efectivo.

Si queremos, podemos agregar hasta 7 variantes más, aunque tampoco es aconsejable tener tantas versiones de un mismo mensaje. Lo mejor es probando nuestras hipótesis poco a poco y solo testear dos o tres mensajes por experimento.

3. Objetivos

Esta parte sí que es exactamente igual que lo que ya hemos aprendido en Remote Config y pasa por escoger la métrica en función de la cual se va a medir qué variante es la mejor.

Los eventos susceptibles de ser objetivos también van a poder ser de los automáticos y/o de los personalizados, tanto para fijar el objetivo principal como para establecer como métricas secundarias.

4. Opciones del mensaje

Teniendo en cuenta que el experimento consiste en el envío de notificaciones, es lógico que también podamos definir el momento en el que se van a enviar y otros aspectos relacionados con la personalización de la notificación.

• Fecha de entrega: se puede hacer que la notificación se envíe nada más lanzar el experimento o programarla para una fecha y una hora concretas. Además, por si acaso tuviéramos usuarios en otras ubicaciones, también podemos seleccionar una zona horaria específica y hacer que les llegue a esas personas en la hora local que fijemos.
• Título: podemos añadir un título que acompañe al mensaje de la notificación. Esto puede ser útil para destacar sobre el resto de notificaciones que reciba el usuario en su móvil y para darle algo más de contexto al mensaje.
• Sonido: si tenemos establecido un sonido específico para nuestras notificaciones y los usuarios nos han dado permiso para hacerles llegar mensajes con sonido, podemos hacer que nuestra notificación incluya ese sonido cuando la reciban.
• Vencimiento: puede ser que cuando nosotros hayamos tratado de enviar esa notificación, el móvil del usuario estuviera apagado o sin conexión, por lo que entonces haremos que Firebase guarde esa notificación durante un tiempo prudencial para volver a mandarla cuando este dispositivo vuelva a estar operativo. El tiempo máximo para almacenar y tratar de enviar la notificación será de 4 semanas.

Este era el último paso, así que ya tenemos listo nuestro experimento de A/B Testing para Cloud Messaging.

A/B Testing para In-App Messaging

Vamos con A/B Testing para In-App Messaging, que es el último de los tipos de experimentos que podemos configurar en Firebase.

Lo que vamos a hacer ahora es aprender a hacer experimentos con las notificaciones internas de la app, más concretamente con los mensajes que aparecen mientras estamos utilizando la aplicación. 

Requisitos

Aquí vamos a volver a necesitar tener vinculados Analytics y Firebase, pero además vamos a tener alguna exigencia más para poder agregar In-App Messaging a nuestro proyecto de Firebase.

Concretamente esto es lo que nos va a hacer falta:

• Android: incluir el repositorio Maven a nivel de proyecto dentro del archivo build.gradle en las secciones buildscript y allprojects.
• iOS:
  • Xcode 10.3 o versión superior
  • CocoaPods 1.4.0 o versión superior

Como ya habréis deducido, esto mejor se lo dejamos al equipo de desarrollo.

Funcionamiento

La verdad es que la mayoría de aspectos de los 3 tipos de experimentos son muy similares a la hora de configurarlos dentro de Firebase, aunque sí que es verdad que cada uno tiene sus propias secciones y particularidades.

Por tercera vez, vamos a ir a Participación > A/B Testing y vamos a crear un nuevo experimento, esta vez de In-App Messaging.

1. Conceptos básicos

Esta vez se llama conceptos básicos en lugar de aspectos básicos, pero va a consistir en introducir un nombre para el experimento y una descripción que vaya con él.

2. Variantes

Después pasaríamos a donde está la verdadera diferencia de los experimentos con In-App Messaging respecto al resto, la configuración de las variantes.

En su momento, vimos en el artículo dedicado a In-App Messaging que había 4 tipos de notificación interna: 

• Tarjeta –> plantilla recomendada para cuando queremos comunicar mensajes extensos a nuestros usuarios, como por ejemplo informarles de una nueva funcionalidad o darles indicaciones para un proceso específico.
• Modal –> es un pequeño banner de formato cuadrado que se usa sobre todo para anunciar ofertas y redirigir a los usuarios a las páginas específicas.
• Solo imagen –> este tipo de mensajes son los más llamativos a pesar de que solo se componen de una imagen. Normalmente se emplea este tipo de notificación para promociones temáticas muy puntuales.
• Banner superior –> es un formato poco invasivo que muestra un banner situado en el margen superior de la pantalla. Es muy común utilizar los banners superiores para notificaciones relativas al funcionamiento de la aplicación.

En lo relativo a crear las variantes de notificaciones internas con A/B Testing, el proceso es el mismo que el que estuvimos describiendo en el post específico sobre In-App Messaging, al que recomendamos que le echéis un vistazo para saber más sobre este tipo de notificaciones y aprender a configuralas correctamente.

En A/B Testing lo que se suele buscar con este tipo de experimentos es probar qué modelo de notificación funciona mejor para enviar un mismo mensaje. Eso se conseguiría creando distintas variables cuyo mensaje sea idéntico, pero el diseño cambie.

Por ejemplo, podríamos probar a mandar un mensaje para que nos contacten probando con un modal y con un banner superior y saber si es mejor optar por formatos más llamativos o más discretos.

3. Segmentación

Esta vez la segmentación vuelve a tener un apartado propio en lugar de estar integrada dentro de los aspectos básicos, pero sigue consistiendo en escoger un app, definir una audiencia y establecer un porcentaje de exposición.

No hay mas cambios.

Aquí tampoco se puede configurar un experimento para varias aplicaciones distintas, así que si queremos hacer este test en otra app que tengamos, habrá que rehacerlo o duplicarlo y modificar la segmentación,

4. Objetivos

La configuración de objetivos es el único aspecto que es idéntico en cualquiera de los 3 tipos de experimentos.

Así que aquí ya sabemos que nos toca elegir un objetivo principal basado en un evento y/o métrica de entre los personalizados o automáticos y uno o varios objetivos secundarios que sirvan para aportar información extra sobre el rendimiento de cada variable.

5. Programación

Las notificaciones internas no son tan puntuales como las notificaciones push o externas, sino que suelen durar un periodo de tiempo bastante más largo.

Es por ello, que no solo podemos fijar un momento de inicio de la campaña de notificaciones, sino que también tendremos la opción de escoger una fecha de finalización.

Revisión del experimento

Ya hemos visto cómo configurar un experimento de cada tipo pero, ¿qué hacemos ahora? ¿Los publicamos directamente y que el público decida?

La respuesta es un no tajante.

Antes de poner en marcha el experimento y

dejar que los usuarios vean el experimento, hay que pasar a revisarlo.

Esta revisión comienza por observar el resumen del borrador del experimento y ver que toda la información que ahí aparece sea la correcta.

Si todavía estamos configurando el experimento, bastaría con clicar en el botón “Revisar” en el margen inferior derecho. Por el contrario, si hemos dejado guardado el experimento para continuar con él más adelante, tendríamos que ir a A/B Testing y buscarlo dentro de la pestaña de “Borrador”.

De cualquiera de las maneras, la información que tenemos que comprobar será la misma. Habrá que hacer un repaso de todos los elementos que tenemos aquí recogidos, desde aspectos tan simples como el nombre y la descripción del experimento hasta piezas tan detalles tan importantes como la segmentación, los objetivos establecidos o la configuración de las variantes.

Si cualquiera de los datos es incorrecto, se podría dar marcha atrás clicando en “Editar” de la cabecera, haciendo esto volveríamos de nuevo a la página de configuración del experimento que ya conocemos.

Sin embargo, esta revisión que mencionábamos no incluye solo el comprobar el resumen del borrador, que también hay que hacerlo de forma exhaustiva como ya hemos explicado, sino que también va a implicar hacer pruebas con dispositivos reales. Estos dispositivos no van a ser de usuarios cualquiera sino que van a pertenecer a miembros del equipo.

Para poder hacer este tipo de testeos previos necesitaríamos el ID token del dispositivo específico con el que vayamos a hacer la prueba. Para sacarlo va a hacer falta trastear con el código interno de la app, así que de nuevo tendremos que recurrir a nuestros desarrolladores.

El proceso realmente es bastante rápido y sencillo, tan solo habría que entrar en la consola de MainActivity en Android, o en su equivalente AppDelegate en iOS, e introducir los siguientes códigos según sea el caso:

Le daremos a guardar y la próxima vez que iniciemos la app desde ese dispositivo veremos la variante seleccionada.

Si vemos que esto no funciona, seguramente tendrá algo que ver con el caché de la app. De forma predeterminada, este caché se actualiza cada 12 horas, por lo que teóricamente tendría que pasar este tiempo hasta que se descargaran los nuevos valores y pudiéramos hacer la prueba.

Decimos teóricamente porque siempre podemos recurrir a ese equipo de desarrollo que tanto nos ayuda y pedirles que reduzcan este lapso de tiempo a 0 para pruebas realizadas en modo desarrollador. Este último punto es muy importante, puesto que no se deben realizar modificaciones de este tipo en producción, se dejan únicamente en el lado de desarrollo.

Ahora sí que debería funcionar y nosotros comprobar que, efectivamente, nuestra variante se visualiza correctamente y nuestro experimento está listo para lanzarse.

Interpretación de resultados

Ahora llega una de las partes más duras y difíciles de A/B Testing: la espera.

El tiempo que vamos a tener que esperar hasta ver resultados va a variar dependiendo del tipo de experimento que sea. Normalmente, los experimentos relacionados con notificaciones, ya sean internas o externas, suelen tener efectos más inmediatos y pueden verse ya algunos resultados pasados los 7 días.

No obstante, los experimentos con Remote Config se dilatan algo más en el tiempo porque la propia herramienta tiene en cuenta que las modificaciones que se realizan en la app tienen un interés que va en declive a lo largo del tiempo, es decir, llaman más la atención cuando resultan novedosas para los usuarios, pero van dejando de atraer tanto interés según avanzan los días.

Es por ello que Firebase deja un cierto tiempo prudencial para estudiar esta evolución y la repercusión real que tendrían los cambios. Sabiendo esto, podemos establecer un plazo de alrededor de 2 semanas hasta obtener resultados en nuestro experimento.

Aparte, otro factor clave es el propio tráfico que tiene la app de por sí. Cuantos más usuarios utilicen la aplicación más datos tendrá Firebase para tomar una decisión y más rápido tendremos nosotros los resultados.

Adicionalmente, hay que tener en cuenta que durante este tiempo no se podrá hacer ningún cambio de relevancia en la aplicación, ya que de hacerlo los resultados dejarían de ser válidos y relevantes.

Si en algún momento queremos comprobar qué tal va el experimento y si ya hay suficientes datos, podemos entrar en A/B Testing y ver los experimentos “En ejecución”.

Mientras haya pocos datos tendremos que seguir esperando y, una vez que la herramienta nos avise de que ha llegado a una conclusión será cuando pasemos al análisis de los resultados en los experimentos “Completados” de A/B Testing.

Dependiendo de cómo haya ido el experimento y de los datos que haya obtenido la herramienta, Firebase puede arrojar los siguientes resultados:

• No se ha encontrado ningún líder –> la herramienta no es capaz de afirmar qué variante es la mejor
• Es probable que el modelo de referencia sea el mejor –> lo más seguro es que la versión original sea la mejor opción
• Se encontró una posible mejora –> existe una probabilidad media-alta de que una de las variantes tenga un rendimiento respecto al resto de variantes y a la versión original
• Se encontró una mejora evidente –> la herramienta es capaz de afirmar con seguridad que una de las variantes es la mejor

Si bien lo habitual es que A/B Testing llegue a una conclusión, también es normal que la herramienta no detecte un ganador. 

Esto no quiere decir que el experimento no haya servido o que realmente los resultados no sean válidos. Muchas veces lo que pasa es que las variantes de ese experimento no sobrepasan el 90% de probabilidad de ser la mejor opción y Firebase no es capaz de lanzar una afirmación concluyente, lo que no significa que en verdad no haya una variante ganadora para nosotros.

Para salir de dudas, lo mejor es que siempre hagamos un análisis exhaustivo de los diferentes indicadores del experimento.

Realizando el análisis, lo primero que vamos a ver es el mismo resumen que teníamos durante la revisión del borrador del experimento. La única diferencia va a ser una cabecera adicional donde quedará reflejada la conclusión a la que ha llegado la propia herramienta después del test.

Básicamente será uno de los resultados que hemos comentado antes junto a qué variante es la mejor y por cuánto supera al resto.

Esto de entrada no suele significar mucho porque como ya se ha dicho antes, muchas de las resoluciones a las que llega Firebase no son del todo concluyentes, por lo que tenemos que pasar a las siguientes visualizaciones para poder sacar nuestras propias deducciones y tomar una decisión.

En primer lugar nos vamos a encontrar con un gráfico evolutivo con los principales KPIs en el que podemos seleccionar el periodo a considerar. Nosotros solemos ver la evolución total del experimento para conocer también la repercusión que ha podido tener en los datos ese efecto “novedad” y el progresivo declive del interés de los usuarios que mencionábamos previamente.

Si bien todos los indicadores aquí recogidos son de utilidad, deberemos centrarnos en aquel evento que hemos definido como objetivo principal, en este caso los ingresos totales estimados.

En la tabla que está justo debajo nos vamos a encontrar con una comparativa entre el grupo de control o modelo de referencia y las distintas variantes que hayamos configurado.

Lo primero que vamos a notar es que la tabla está divida en dos mitades, una con los datos observados, que vendrían a ser los datos generales y una segunda mitad con los datos modelados.

Estos datos modelados son el resultado de combinar los datos observados con modelos bayesianos para llegar a ciertas conclusiones basadas en la probabilidad.

Sabiendo esto, podemos ver cuántas veces ha sucedido el evento que estamos tomando como referencia, tanto en números absolutos como en porcentaje de usuarios que lo han realizado. Además, en la fila de la versión aparece una tercera métrica que estima en cuánto empeora o mejora cada variante los resultados de conversión del modelo de referencia.

Ya pasando a la sección de datos modelados, vemos el trabajo que ha realizado la herramienta y las conclusiones a las que ha llegado. Aquí sobre todo pondremos el foco en las probabilidades de superar el valor de referencia y el porcentaje de diferencia que hay respecto a este.

En este caso concreto el resultado es muy ambiguo, puesto que sí que parece haber una pequeña posibilidad de mejora con respecto a la versión original, pero no hay información suficiente como para que tampoco nosotros podamos asegurarlo.

Toma de decisiones

Vistos y valorados los resultados del experimento, tenemos que plantearnos la siguiente pregunta: ¿qué hacemos ahora?

Depende. Esta decisión deberá tomarse teniendo en cuenta la valoración que haga la herramienta de nuestro experimento, la valoración individual que hagamos nosotros y del desarrollo del propio test.

Así que ahora vamos a contaros qué opciones existen y en qué casos aplicar cada una de ellas:

• Parar el experimento: esta alternativa se selecciona cuando lo único que queremos es detener el experimento y no hacer nada más con él, bien porque ya hemos sacado nuestras conclusiones y queremos dejar las cosas tal y como estaban antes o bien porque no creemos que este experimento vaya a ayudarnos con nuestra estrategia.
• Repetir el experimento: si los resultados del test no han sido todo lo concluyentes que pensábamos que iban a ser, podemos repetir el experimento y ver si volviéndolo a hacer conseguimos obtener más información.
• Modificar el experimento y repetirlo: de forma similar a la anterior, aquí estaríamos repitiendo el experimento pero añadiendo alguna modificación con respecto al anterior. De este modo probamos distintas versiones de un mismo test.
• Incrementar el porcentaje de distribución: cuando la herramienta no ha sido capaz de escoger una variante ganadora y creemos que ha sido por falta de datos, podemos optar por ampliar el porcentaje de usuarios que forma parte del experimento y comprobar si con esa información extra se puede llegar a una conclusión.
• Exportar los datos a BigQuery: una alternativa bastante reciente es el poder enviar los datos en bruto de los experimentos a BigQuery y allí hacer un análisis más exhaustivo de la información recopilada. Si necesitáis aprender a hacer esta integración, podéis consultar el artículo sobre cómo vincular Firebase con BigQuery.
• Declarar un ganador: cuando Firebase, vosotros o ambos lo tenéis claro, lo único que queda es declarar una variante ganadora y hacer que esa pase a ser la nueva versión de la app para el 100% de los usuarios.

Ahora ya sois expertos en A/B Testing y podéis empezar a hacer vuestros primeros experimentos.

Si en algún momento tenéis alguna duda, decidnos y estaremos encantados de ayudaros.