Herramientas de interacción de Firebase: Remote Config

En el post anterior de esta serie vimos cómo utilizar las herramientas Predictions, Cloud Messaging e In-App Messaging para aumentar el rendimiento y la eficiencia de nuestra aplicación móvil.

Ahora le toca el turno a Remote Config, la que probablemente sea una de las funcionalidades más útiles que se pueden encontrar dentro de Firebase, pero que tiene la dificultad añadida de tener que estar algo familiarizado con el código interno de la app y con la definición de parámetros.

Aun así no os preocupéis, gracias a este artículo seréis capaces de entender mejor el funcionamiento de Remote Config y de utilizarlo, aunque sea de forma básica, para sacarle el máximo partido a vuestra aplicación.

Qué es Remote Config

Remote Config es una herramienta de la sección de interacción de Firebase que permite editar y personalizar el aspecto y el comportamiento de nuestra app sin necesidad de ejecutar una actualización.

Su principal ventaja es precisamente esa inmediatez que nos proporciona. Mientras que el proceso de edición, subida y publicación de una nueva versión de la app lleva días, Remote Config solo tarda unos minutos en hacer visibles y operativos los cambios.

Proceso estándar de actualización de una app

 

Personalización de una app con Remote Config

Requisitos de Remote Config

Los requisitos para poder usar Remote Config en nuestra aplicación variarán dependiendo de con qué sistema operativo o lenguaje de programación vayamos a trabajar.

Como sabemos que cada uno de vosotros tendrá sus propias necesidades en esta parte, os dejamos aquí las instrucciones de instalación para cada una de las alternativas que ofrece Firebase:

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

Este punto puede resultar algo complejo si no tenemos conocimientos de programación, por lo que quizá sea el momento de acudir a nuestro equipo de desarrollo y pedirles que hagan esta configuración por nosotros.

Funcionamiento de Remote Config

Una vez está instalado y configurado correctamente, y antes de meternos a cambiar parámetros, tenemos que comprender cómo funciona realmente Remote Config.

Normalmente, cuando se instala Remote Config en una aplicación, se crea también una biblioteca en la que se almacenan los parámetros que se utilizan dentro de la app y que se quiere poder modificar a través de la interfaz Remote Config, pudiendo tratarse de casi cualquier cosa, desde el color de la fuente hasta el texto de un botón, el nivel de dificultad de un juego, etc.

Todo lo que pueda incluirse dentro de un parámetro, se puede modificar.

A la hora de definir esos parámetros también se suelen establecer unos valores por defecto para los mismos, como por ejemplo:

• background_color: #FFFFFF
• font_size: 12
• home_banner_image: https://aukera.es/img/partners-de-google.png
• active_promotion: “Migraciones a Google Analytics 4”

Estos valores que hemos predeterminado son los que se ejecutarán en nuestra aplicación hasta que nosotros decidamos actualizarlos mediante un cambio en Remote Config.

Para esto, solo habría que entrar dentro de Firebase e ir a la sección de interacción (antes sección de crecimiento). Aquí encontraremos la funcionalidad de Remote Config.

Una vez dentro de la propia herramienta, veremos un recuadro como este, donde se pueden añadir los nombres, o claves, de los parámetros que hayamos definido como preestablecidos para Remote Config y cambiar sus valores. 

Cogiendo uno de los ejemplos anteriores, imaginemos que hemos descubierto que el tamaño de fuente se ha quedado muy pequeño para las pantallas de dispositivos iOS y que es necesario aumentar el tamaño de letra (el parámetro font_size) para estos dispositivos.

Entonces, lo que haríamos sería ir a ese recuadro que se ve en la imagen superior e introducir los siguientes datos:

• Clave del parámetro (nombre que le hemos dado al parámetro)
• Valor predeterminado (el valor que le queremos dar)
• Descripción (una explicación de que supone este cambio)

Después solo habría que clicar en Añadir parámetro para que el cambio se ejecutase.

Pero si hiciéramos esto, ¿estaríamos realmente solucionando el problema de los dispositivos iOS? La respuesta es no.

Si dejamos así estos valores y le damos a Añadir parámetro, estaremos cambiando el tamaño de fuente para TODOS los usuarios.

Cuando el cambio se pretende aplicar a un segmento concreto de los usuarios, entonces hay que establecer unas condiciones que especifiquen cuándo deben actualizarse los valores predeterminados.

Esto se haría yendo a Añadir valor de condición (la opción del margen superior derecho) y configurando una nueva.

A esta nueva condición, aparte de ponerle un nombre, podemos darle un color (el que queramos). Esto servirá para poder identificar esta condición de cara al futuro, algo que irá cobrando más importancia cuando ya llevemos varios parámetros modificados con Remote Config.

Sin embargo, la parte crucial es el escoger los activadores adecuados. Dentro de las condiciones de Remote Config, se pueden establecer condiciones de activación en función de:

• Versión de la app
• Número de compilación de una app iOS
• Plataforma
• Idiomas
• País o región
• Audiencias de usuario
• Propiedades de usuario (desde Analytics)
• Percentiles aleatorios
• Fecha y hora

Como nosotros hemos dicho que únicamente queremos aplicar estos nuevos valores a los dispositivos iOS, escogeríamos la opción de Plataforma > iOS. 

Tras esto solo quedaría hacer clic en Crear condición y ¡listo!

Ya hemos cambiado el tamaño de letra para los dispositivos iOS. Bueno, no del todo, en el siguiente apartado veremos cuál es el paso que nos falta.

Estrategias de carga

Una cosa es que nosotros introduzcamos cambios en la app y otra cosa es que sean visibles para los usuarios. Es por ello, que dentro del proceso de creación de nuestra biblioteca de Remote Config, habrá que hacer un ajuste más que pasa por definir y configurar una estrategia de carga.

Esta estrategia de carga servirá para informar a la app de cuándo tiene que obtener y activar esos nuevos valores de parámetro del servidor.

Aquí os dejamos algunas de las estrategias de carga que

• Activar y actualizar: si elegimos esta opción, los parámetros se actualizarán cuando el usuario inicie la aplicación, de forma síncrona. Si bien esta es la opción más común para aplicaciones que se encuentran en fase Beta o que son muy simples, no es del todo recomendable porque puede darse la situación en la que los cambios se apliquen en la app mientras el usuario la está utilizando, lo que puede dar lugar a problemas de usabilidad o errores importantes.
• Pantalla de carga: otra alternativa que suele verse bastante, es la implementación de una pantalla de carga. Esta solución implica que, en vez de iniciarse la app de inmediato, los usuarios verán una pantalla intermedia durante el tiempo que tardan en descargarse y activarse los valores nuevos de los parámetros.

Si bien es una opción muy interesante de cara a evitar el problema que presentaba la estrategia de activar y actualizar y cerciorarnos de que los parámetros están siempre con la última de las versiones, las pantallas de carga pueden ralentizar bastante el tiempo que tarda el usuario en acceder a la aplicación.  Este aumento del tiempo de espera puede resultar, al igual que en el caso anterior, en un detrimento de la experiencia de usuario.

No obstante, independientemente de esta desventaja que acabamos de mencionar, esta es la estrategia de carga a emplear siempre que se esté llevando a cabo un experimento con A/B Testing.

• En el siguiente inicio: una estrategia más compleja, pero muy eficaz, es la de descargar los nuevos valores según se inicie la app, pero seguir utilizando y mostrando los antiguos durante toda esa sesión. Dichos valores se almacenarán hasta que el usuario abra la aplicación una segunda vez; será entonces cuando se recuperarán los valores que se habían descargado previamente y pasarán a estar operativos.

Al igual que en las estrategias previas, esta alternativa también presenta una gran desventaja y es que, aunque el tiempo de espera se vea notablemente reducido y no se den problemas de usabilidad, el usuario debe iniciar dos veces la aplicación para que los valores de los parámetros se actualicen.

• Híbrida: una opción que mezcla varios elementos de las estrategias anteriores es la híbrida.

Esta alternativa consiste en revisar la fecha de la última actualización y actuar en función de ello:

• Si ha pasado mucho tiempo (>48 horas) podemos prever que la descarga de nuevos valores va a tardar bastante rato, por lo que lo mejor será utilizar una pantalla de carga para impedir que los cambios se activen durante el uso de la aplicación.
• Si ha pasado poco tiempo (<48 horas) es poco probable que haya grandes cambios de una versión a otra, por lo que optaremos por descargar los valores durante la sesión actual e implementarlos en la próxima.

Hemos visto que cada tipo de estrategia de carga tiene sus pros y sus contras, por lo que queda en manos de cada uno el decidir cuál es la más adecuada para su aplicación en función de las características y necesidades de esta.

Limitaciones

Seguro que después de tenerlo todo instalado y preparado para empezar a funcionar, estáis deseando realizar vuestra primera personalización. No obstante, antes de que esto ocurra, tenemos que contaros algunas limitaciones funcionales y legales que tiene Remote Config y que hay que tener en cuenta al usar esta herramienta:

• Almacenamiento de datos confidenciales: la confidencialidad es un tema que siempre ha estado muy presente en todas las plataformas de Google. Es por eso que también en Firebase está prohibido recopilar información personal o identificativa de los usuarios que utilizan nuestra app, no pudiendo emplearse los parámetros introducidos a través de Remote Config para capturar este tipo de valores.
• Actualizaciones sin autorización: si bien una de las grandes ventajas de Remote Config es poder hacer actualizaciones casi instantáneas de la app, no debe aprovecharse esta funcionalidad para introducir algún cambio que requiera el permiso explícito de los usuarios, ya sea por evitar cualquier conflicto legal o simplemente para no hacer que los usuarios desconfíen de nuestra aplicación.
• Eludir los requisitos de las stores: las tiendas donde podemos descargar y actualizar las aplicaciones de nuestros dispositivos móviles o tablets establecen sus propias condiciones para asegurar el buen uso de las apps, tanto por parte de los usuarios como por parte de la empresa que las haya desarrollado. Es precisamente por este motivo por el que no se permite hacer ninguna modificación a través de Remote Config con el objetivo de saltarse estas disposiciones.

• Límites de parámetros y condiciones: si nos centramos en restricciones de tipo técnico, estos son los límites que habrá que considerar para nuestro proyecto de Firebase:
  • Parámetros
    • 2000 máximo por proyecto
    • 256 caracteres por parámetro y 800.000 caracteres por proyecto
    • Deben empezar por cualquier letra (en mayúscula o minúscula) o con un guion bajo
  • Condiciones
    •  500 máximo por proyecto
  • Plantillas
    • 300 versiones máximo en Firebase
    • 90 días de ciclo de vida

Ahora sí que sí, es el momento de pasar a utilizar Remote Config. Por si no se os ocurre por dónde empezar, en el siguiente apartado podéis encontrar varias ideas.

Usos prácticos de Remote Config

Como ya hemos comentado al inicio de este post, Remote Config es una de las herramientas que más posibilidades ofrece para personalizar la apariencia y el funcionamiento de una app y ayudar a mejorar su rendimiento. Ahora vamos a comentar algunas de ellas para que conozcáis el potencial de esta funcionalidad:

• Ofrecer contenido nuevo de forma rápida: sabemos que el proceso de actualización de la app puede ser bastante complejo y tedioso, implicando trabajo de programación y todas las formalidades de aprobación y publicación hasta estar disponible para los usuarios.

Así que, si lo que buscamos es publicar contenido nuevo rápidamente, podemos introducir estos cambios a través de la consola de Remote Config y ahorrarnos esos pasos intermedios.

Esto también nos será muy útil si realizamos modificaciones muy frecuentes en nuestra app. Si por ejemplo tenemos una promoción que cambia cada mes o si queremos incluir un artículo o noticia cada semana, lo más sencillo es que únicamente cambiemos los parámetros correspondientes en lugar de hacer una actualización completa.

• Crear contenido responsive: en ocasiones puede resultar muy complicado que los diferentes elementos de la app se visualicen correctamente en la totalidad de modelos de móviles y tablets del mercado.

Es por esto que a veces tenemos que ir optimizando nuestros contenidos mediante procesos de prueba-error. 

Lo más sencillo para agilizar este procedimiento es realizar estos ajustes en Remote Config y sobreescribir solo los parámetros relativos a los elementos que queramos modificar que, en estos casos, corresponderán sobre todo a tamaños de imágenes o fuentes de texto.

• Corregir contenidos o formatos: si vemos que hay alguna errata o error en nuestra aplicación, como textos en un idioma que no concuerda con el de esa versión de la aplicación, un CTA que no enlaza a la pantalla que debería o vídeos que no se reproducen correctamente, lo que podemos hacer es editar esos parámetros para que todo funcione como queremos.
• Personalizaciones: Remote Config también nos permite establecer valores diferentes para un parámetro basándonos en una audiencia o propiedad de usuarios que hayamos definido previamente, lo que nos va a permitir ofrecer una experiencia personalizada en función del tipo de usuario que esté utilizando la app.

De esta forma, podemos ofrecer recompensas a aquellos usuarios más leales o que más compren, bajar el nivel de dificultad para las personas que estén atascados en el juego, mostrar noticias de temáticas específicas según las consultas previas o cualquier otra customización que se nos ocurra.  

• Introducir cambios progresivos: supongamos que tenemos planeados una serie de modificaciones dentro de nuestra aplicación, pero que nos da cierto miedo publicarlos todos de golpe por si provocan algún fallo o no tienen la aceptación que esperábamos.

En este caso podríamos emplear Remote Config para hacer lanzamientos parciales e ir dando a conocer las novedades de una forma progresiva, ya sea realizando publicaciones periódicas de una parte de los cambios o mostrando todas las modificaciones al unísono a un pequeño porcentaje de la audiencia que iremos ampliando.

• Solucionar errores de programación: puede ser que en la anterior actualización estándar de la aplicación cometiéramos algún error y ahora queramos arreglarlo sin tener que volver a llevar a cabo todo el proceso de actualización, ya sea por temas de tiempo o practicidad. Aquí cabrían dos posibles soluciones:
  • Mandar una notificación a todos los dispositivos a través de Cloud Messaging para que cojan esa actualización de Remote Config inmediatamente. Lo bueno de seguir esta técnica es que la totalidad de dispositivos descargarían la actualización al momento y lo malo es que lo harían todos a la vez, lo que podría provocar una saturación del servidor y el mal funcionamiento de la aplicación.
  • Enviar una notificación vía Cloud Messaging para que deje una alerta local de actualización urgente que está pendiente.

  En este caso, la actualización comenzaría a descargarse una vez los usuarios inicien la app, por lo que se evitaría la sobrecarga del servidor aunque podría implicar un mayor tiempo de espera para acceder a la aplicación.

  La alternativa que escojamos entre estas dos opciones va a depender principalmente de la estrategia de carga que hayamos implementado para la gestión de actualizaciones de nuestra app.

Después de haber visto cómo podemos utilizar Remote Config de forma relativamente sencilla y de conocer las posibilidades casi ilimitadas de esta herramienta, solo queda una pregunta:

En el siguiente artículo de esta serie veremos cómo utilizar todo lo que hemos aprendido sobre Remote Config, Predictions, Cloud Messaging e In-App Messaging para ejecutar distintos tipos de Test A/B que nos permitan tomar decisiones basadas en datos reales.

Seguid atentos a nuestro blog y no dudéis en consultarnos cualquier duda que os surja.