El fin último de cualquier estrategia que sigamos en nuestra app es la compra por parte del usuario.
Ganar dinero.
El “flush”, que dice un amigo mío.
A este lugar podemos llegar por muchas vías y todas ellas serán importantes: mejorar la visibilidad, la conversión, la retención, el tiempo de pantalla, las reviews (iremos viendo todas estas cosas…).
Sin embargo, el momento de la verdad, ese en el que el usuario nos da su dinero, es el momento en que le mostramos nuestro paywall. Ya hablamos de lo difícil que era hacer un paywall en un número anterior. Como dijimos, no existe la receta perfecta. Hoy veremos someramente algunas cosas que hemos tenido en cuenta a la hora de confeccionar el paywall de Resvolutions.
Un experimento.
Para el tipo de app que nos traemos entre manos, una app sencilla que nos ayuda en la generación de hábitos, lo más sencillo hubiera sido que la app hubiera tenido un precio fijo en la App Store. Creedme cuando digo que nos hubiera ahorrado muchísimo trabajo, tanto en el desarrollo como en la publicación.
Sin embargo, el objetivo de esta app era servir de base para el aprendizaje y la experimentación. Si hubiéramos hecho lo anterior, nos hubiésemos perdido dos cosas:
- Montar nuestro sistema de compras dentro de la app con StoreKit2 y async/await.
- Probar un sistema de “pay what you want”
Este último punto nos interesaba especialmente. Queremos ver qué tal funciona la posibilidad de que el usuario desbloquee la aplicación completa por el precio que él o ella decida.
Esta lógica de aportación al proyecto en función de las posibilidades y la percepción del usuario del valor recibido es algo que se ve habitualmente en otros entornos, como las campañas de crowdfounding (Kickstarter o similares) o las donaciones en plataformas como Twitch, pero es algo que no acostumbramos a ver en el marco de un paywall de aplicaciones.
El modelo.
Incluir esta lógica de “paga lo que estés dispuesto a pagar” nos obliga, de alguna manera, a aceptar la premisa de que el usuario, para formar su criterio, ha de tener la posibilidad de acceder a un periodo de prueba.
Ofrecer un periodo de prueba era algo inevitable, máxime cuando estás planteando un hard paywall; la app no tiene ninguna funcionalidad gratuita fuera del periodo de prueba.
La pregunta inevitable es: ¿qué duración tendrá ese periodo de prueba?
Aquí se han valorado fundamentalmente dos cuestiones: las características de la app que han de probarse y el uso y motivación de la propia aplicación.
La aplicación puede probarse en su totalidad y entenderse todas sus mecánicas y beneficios en apenas 30 minutos. Este, por lo tanto, no es un criterio que nos invite a crear un periodo de prueba muy prolongado.
El objeto de la aplicación es el de la creación de un hábito que mejore de alguna manera nuestra vida. El usuario con un mayor impulso de adquisición de nuestra app será probablemente quien haya decidido hacer ese cambio vital más recientemente. No es ningún secreto que cuanto más alejemos la decisión de compra de ese primer impulso de cambio más posibilidades tendremos de que el usuario desinstale nuestra app. Yo he abandonado decenas de propósitos, ¿tú?
Visto la anterior, consideramos que 4 días es un tiempo idóneo para que el usuario entienda nuestra app y sea capaz de identificar los beneficios de los recordatorios, la simplicidad para compartir sus propósitos con el mundo (con el compromiso que eso conlleva) y se involucre con las mecánicas de gamificación.
La regla de los 3, el marco referencial y el decoy
El último punto era decidir qué precios ofertábamos para acceder a nuestra app y cómo se lo presentábamos al usuario.
Siguiendo “la regla de los 3”, de la que ya hablamos en otro número al mencionar las preferencias de Steve P. Young en materia de paywalls, decidimos crear los siguientes precios:
- El precio base: 0,99€
- El precio deseado: 1,99€
- El precio señuelo: 4,99€
Aun sabiendo que un alto porcentaje de los usuarios optarán por pagar el menor de los precios, este planteamiento nos permite no excluir a aquellos que de verdad perciben en nuestra aplicación un valor superior; que entienden que, en su momento actual y para ellos, esta app vale 1,99€.
El precio de 4,99€ es lo que se conoce como un precio señuelo o “decoy”. Sirve para general un marco mental en el que, de repente, 1,99€ no es un precio tan elevado y puede representar el valor de la aplicación para el usuario.
Lo importante aquí es la flexibilidad que no obtendríamos si fijáramos un precio fijo en tienda para nuestra app.
A la hora de presentar las opciones, hemos querido presentar primero, como opción destacada el precio deseado.
Además, teniendo el cuenta que el paywall es lo primero que ve el usuario tras una pequeña pantalla de onboarding, era necesario que visualmente tuviese un aspecto cuidado y profesional, que anticipe lo que se va a encontrar al acceder a la app.
Por lo anterior, hemos optado por un carrousel que puede moverse mediante desplazamiento (swipe) o seleccionando (pulsando) la opción que se desee. Como no sabemos cuál va a ser la opción de interacción elegida por el usuario, programamos ambas para no generar fricciones en este punto.
No es oro todo lo que reluce
Me anticipo y planteo dos observaciones que hacen que este paywall pueda ser una mala idea para la conversión y de paso, abro un debate para redes sociales (o, si eres tímido o tímida, correo electrónico).
En primer lugar, puede no ser buena idea llevar al usuario a dos decisiones de conversión en tan poco tiempo.
En segundo lugar, existen voces contrarias a los periodos de prueba (ya sean en hard paywall o modelo freemium) por el input negativo que supone quitarle algo al usuario. “Nunca le quites algo que ya tenía”, dicen.
¿Qué pensáis?
