Qué es un onboarding modular, para qué sirve y cuándo deberíamos utilizarlo

Lo que vas a leer a continuación no está escrito en ningún libro. No hay apenas información en Internet, y es fruto del esfuerzo del Growth Squadron de Product Hackers para resolver los problemas que nos encontramos al trabajar para algunos de nuestros clientes.

Imagina una empresa donde la conversión de inicio de registro al aterrizaje en la interfaz de producto fuera del 3%. Es duro y muy real, especialmente para productos que requieren, por su naturaleza, muchos datos para completar un registro y/o son productos innovadores que son más complejos de explicar.

Las Fintech son un ejemplo clarísimo de esta problemática. Algunas están reguladas por la CNMV o tienen que pasar por procesos de verificación de clientes POR LEY (KYC). En estos casos, la fricción se dispara y el registro y onboarding se convierten en un punto crítico que puede llegar a multiplicar fácilmente por 10 el coste de adquisición.

Nuestro primer cliente con esta problemática apareció en diciembre. Como suele ocurrir, ellos consideraban que debían incrementar la captación. Habían asumido ese 10% de conversión de inicio de registro a cliente como algo normal. En la primera sesión de trabajo, analizando su funnel, nuestro equipo de Growth descubrió que su problema no era de adquisición, era claramente de activación.

Fue entonces cuando nos planteamos desarrollar un sistema de registro y onboarding modular que nos permitiera modificar el journey de usuario de una forma ágil, controlada y totalmente medida. Lo hicimos, lo probamos y los resultados son brutales. Os lo cuento todo 🙂

 

Qué son y para qué sirven

Un registro modular consiste en trocear el proceso de registro en partes que se puedan reorganizar, generando diferentes flujos, con el objetivo de descubrir el que maximiza la conversión. Pero, sobre todo, permitiéndonos aprender de la conducta del usuario, para entender lo que está buscando, cuáles son sus motivos para abandonar y evitar que se produzcan durante el registro.

 

Ejemplo de uso de onboarding modular en startup de ejemplo

 

El registro es el proceso burocrático y, casi siempre, tedioso, en el que el usuario entrega al producto digital los datos “indispensables” para que el producto pueda funcionar. En este caso nos referimos a este proceso como onboarding porque, además de registrar al usuario, vamos a ir explicándole mediante el registro cuál es el valor del producto.

 

Cómo se utilizan

Un onboarding modular nos permite probar con partes que pueden o no estar dentro de los diferentes flujos. De una manera muy sencilla nos permiten introducir, modificar o cambiar algunos de estos módulos y ver el impacto que tiene un nuevo paso o una alteración en el orden sobre el porcentaje final de usuarios que completan el funnel.

Para ello hemos desarrollado un modelo de analítica que nos permite interpretar y reaccionar a estos datos. Hemos transformado el funnel en nuestra palanca para incrementar la conversión.

 

La complejidad de un onboarding modular

Un onboarding modular presenta una mayor complejidad técnica por motivos evidentes: hay que programar un sistema que nos permita modificar ese onboarding de forma total o porcentual al volumen de entrada. Que nos permita alterar el orden de respuestas dentro de una vista, con los diferentes elementos y vista que supone. También implica una mayor complejidad a la hora de medir cuál de todos los posibles “caminos” o flujos es el mejor.

Además, a esto le tenemos que añadir que un onboarding modular requiere una capacidad de modificación rápida y muy ágil. Idealmente el propio product manager debería ser el que pudiera alterarlo, realizando decenas de cambios en copys, flujos, opciones, etc. De manera que las posibilidades de modificación de flujos y opciones sean casi infinitas. Si este funnel solo lo puede modificar un desarrollador, el equipo necesario para operarlo y el tiempo necesario por cada modificación hará que no sea rentable.

Las posibilidades de experimentación son directamente proporcionales a la experiencia de la persona que las opera. Tener muchas posibilidades sin los conocimientos adecuados nos puede llevar a realizar experimentos que no nos lleven a ninguna parte.

Sin embargo, ¡nosotros somos Product Hackers! Nuestra existencia se debe a mejorar los productos de aquellos que nos contratan, y para nosotros esta herramienta tiene muchísimo sentido. De hecho, en nuestro caso es uno de los pocos donde desarrollar este tipo de sistemas tiene sentido, dado que lo vamos a utilizar con todos los clientes que tengan problemas en el onboarding y, por lo tanto, la amortización es más factible.

Este tipo de herramientas nos permiten ser más ágiles y mejorar nuestra velocidad a la hora de generar éxito para nuestros clientes.

 

Analítica

Analítica en un onboarding/registro simple

El éxito en la fase de activación consiste en llevar al máximo posible de los usuarios/visitas que llegan a nuestra aplicación/web hasta un punto de comprensión total de nuestro servicio. Fijaos que no he dicho: maximizar el número de usuarios que llegan al final. Este es el resultado de un trabajo bien hecho. ¡No es el objetivo! ¡Es el resultado! Si queréis aprender más sobre esta visión sobre la activación os recomiendo leer mi libro: Growth Hacking: Supera el reto de crear productos digitales exponenciales.

Simplificando el concepto y llevándolo a la FUX (First User Experience) se trata de una serie de pasos que tiene que realizar el usuario. En el caso de un onboarding de una aplicación sencilla, habrá pocos pasos y serán todos fáciles de ejecutar.

Podemos por lo tanto mostrar el proceso como una serie de pasos que el usuario tiene que completar, donde cada columna representa un paso. El primero representa al total de los usuarios/visitas que han empezado y el último paso representa el porcentaje de usuarios que lo han completado. A medida que va habiendo pasos vamos perdiendo usuarios y nos queda el “user path”.

 

Típica imagen de un User Path en Amplitude

 

Analítica para un onboarding modular

Cuando tenemos varios onboadings, y tenemos que compararlos, tendremos que tener el mismo gráfico, pero en esta ocasión debe haber una columna por paso y por onboarding.

La analítica debe permitirnos comparar varios flujos para determinar cuál supone mejoras con respecto al resto. Habrá algunos flujos con más o menos pasos, con diferentes órdenes en las acciones, incluso podríamos llegar a generar cientos de flujos diferentes si permitiéramos al sistema realizar variaciones de forma automática.

 

En esta imagen podemos ver la comparación de dos flujos diferentes y su impacto

 

Si tenemos un número definido de posibles flujos la analítica no será muy compleja, pero como no sabemos cuáles serán las modificaciones que realizaremos en el futuro, debemos suponer el peor de los casos y diseñar un sistema de analítica que nos permita cubrir todos los flujos futuros.

La herramienta de analítica que utilicemos será fundamental y condicionará cómo tendremos que marcar cada evento.

 

Analítica para un onboarding modular en Google Analytics

Como Google Analytics no hace este tipo de user paths por defecto, tendremos que gestionarlo con eventos personalizados y utilizar su nomenclatura para ser capaces de determinar cuál de todos los posibles flujos es el mejor.

Para ello, utilizaremos la categoría “onboarding”. En la acción vamos a identificar el funnel de una forma concreta para poder determinar a qué flujo del onboarding pertenece. La notación debería ser algo parecido a “0000_step_0000”, donde la primera cifra identifica el paso o “step” del onboarding por el que ha accedido y la segunda el orden de flujo que ha realizado el usuario. En “label”, introduciremos el nombre del paso, por ejemplo “Geo”.

De este modo, seremos capaces de comparar todos los flujos en la vista de “Eventos principales” al seleccionar como dimensión secundaria “Acción del evento”, filtrar en el buscador por “onboarding” y ordenarlos por orden alfabético. En definitiva, encontraremos todos los datos ordenados igual que en Amplitude.

 

Análitica para un onboarding modular en Amplitude

Amplitude está especialmente diseñado para trabajar con flujos de usuarios y, por lo tanto, es especialmente sencillo implementarlo. Sin embargo, también hay que seguir una notación específica para que el sistema nos permita tener múltiples onboardings.

En primer lugar: los eventos que lancemos deben ser de la forma “step-0001”. Lo importante es que el onboarding “conozca” el orden del flujo antes de empezar y cuando llegue el usuario se le marque con una propiedad de usuario que identifique el flujo. Esto nos permitirá seleccionar a los usuarios con esa propiedad de usuario y poder ver cómo han funcionado. En la versión de pago podríamos generar cohortes que nos permitirían generar segmentos de usuarios más potentes, pero solo para esto no es necesario.

 

¿Cuánta definición necesito en los eventos?

La mínima suficiente para reconocer problemas en el flujo de un onboarding. Con un evento por acción del usuario o vista (que debería ser lo mismo) será suficiente. Además, es crítico identificar errores en el proceso de onboarding y, por lo tanto, también deberíamos medirlos y lanzar eventos siempre que se produjera un error.

Lo ideal es tener un evento por vista o interacción del usuario y el control de errores. Más eventos incrementan la implementación y el desarrollo notablemente y no aportan apenas valor extra.

Es interesante marcar cada flujo para poder analizar correctamente cada uno y que cada usuario pase siempre por el mismo.

 

Conclusiones

Gracias a esta herramienta hemos conseguido aprender muchísimo sobre los clientes de nuestros clientes. De hecho, en uno de nuestros clientes, hemos incrementado la conversión de registro a cliente del 10% al 54%. ¡Esto es BRUTAL! Esto significa que nuestro cliente ahora convierte 5,4 veces más visitas en clientes gracias a nuestro sistema de onboarding modular. Dicho de otro modo, significa que ahora su inversión en marketing es 5,4 veces más rentable que antes. Si, por ejemplo, decidieran duplicar su inversión, captarían 10,8 veces más clientes.

Imaginad una empresa que invierte 200.000€ al mes en campañas de captación. Si quiere multiplicar por 5 sus clientes mensuales puede multiplicar su inversión por 5 o puede optimizar su registro.

Un onboarding modular es una herramienta brutal para mejorar tu conversión en la etapa de activación, pero también es compleja y costosa de desarrollar. En Product Hackers hemos desarrollado nuestro propio sistema a medida de nuestras necesidades, que son las de nuestros clientes y nuestros Growth Managers.

Para nosotros Growth significa Hackear Productos hasta que sirven a su propósito, poniendo de manifiesto su valor y remarcando los valores de la empresa que hay detrás. Eliminando fricciones y transformando problemas en oportunidades. No son trucos, es ciencia y creatividad al servicio de nuestros clientes, pero también a tu servicio, porque compartimos todo lo que aprendemos.

Gracias por leer este post. Si te ha gustado, sería genial que nos lo demostrases de alguna manera que podamos medir, por ejemplo comentando, compartiendo o recomendando la lectura de este post a quien creas que le puede interesar.

Somos Product Hackers y si tienes un producto y se puede medir: lo podemos mejorar.

6 comments

  1. Henry
    agosto 28, 2020 at 1:19 pm

    Me encanto! toca estudiar mas a fondo Luis

    1. Luis Díaz del Dedo
      agosto 31, 2020 at 6:43 am

      Muchas gracias Henry! 😀

  2. laura cloquell
    agosto 29, 2020 at 4:28 pm

    Hola! Me ha encantado vuestro post. Pero me surge una duda, en el caso de una APP ya no se puede medir con Google Analytics tal y como lo conocemos para web y webapp, así que no sería posible ‘pintar’ un funnel de conversión basado en eventos con categoría, acción y etiqueta para el proceso de onboarding

    1. Luis Díaz del Dedo
      agosto 31, 2020 at 8:51 am

      Hola Laura! Por supuesto depende de donde lo vayas a utilizar necesitarás un sistema u otro de analítica. Con Amplitude puedes medirlo seguro en app y hasta donde yo sé también puedes medirlo con Google Analytics! La forma de medirlo es la misma que en web, la idea es que los eventos personalizados estén definidos como indicaba en el post! 🙂

  3. andres
    septiembre 7, 2020 at 4:20 pm

    Muy bueno Luis. Me surgieron algunas dudas que iré a cosultar más tarde en tu libro. Saludos desde México.

    1. Luis Díaz del Dedo
      septiembre 7, 2020 at 4:23 pm

      Hola Andrés! Muchas gracias por comentar! Y si tienes más dudas sobre el post, pregunta directamente! Seguro que otras personas tienen la misma duda y así la dejamos resuelta en el post 🙂

Leave a Reply