Aitor Sánchez - Blog - Mar. 27, 2024, 8:53 a.m.
Los test a/b, o Split test, son la mejor manera para aumentar tu tasa de uso y reducir nuestra tasa de desinstalación de nuestras aplicaciones.
Así que, si quieres mejorar tus aplicaciones, esto tal vez te interese.
Mira,
Esto que te voy a explicar a continuación no sé si será la mejor manera de hacerlo, eso son prioridades.
Tampoco sé si la manera más bonita de hacerlo, eso son gustos.
Lo que no es ni de prioridades, ni de gustos, es que te estás dejando pasta en el camino por no usar este modelo de optimización.
Atiende:
Eres dueño de una confitería, a la puerta de un instituto de secundaria.
Suena el timbre del descanso, y en tropel, pasan por tu puerta más de 1000 adolescentes sudando hormonas como ciervos en berrea.
Tienes unos Donuts buenísimos que te dejan un buen margen y yo, como experto en marketing, entro a comprar uno y cómo me conoces me preguntas:
Aitor ¿cómo puedo vender más Donuts?
Durante todo el mes que viene, te respondo, haz un esfuerzo extra y haz dos modelos de Donuts.
El primero tal cual lo tienes.
El segundo, en lugar de espolvorear azúcar blanco por encima, dale con azúcar glas.
Pon los dos juntos en el escaparate y dentro de un mes me cuentas.
Resultado: Los Donuts con azúcar glas se venden un 20% más.
Ahora, aplica el resultado, haz todos los días Donuts con azúcar glas y habrás aumentado tu facturación un 20%.
Y vuelta a empezar. Ahora con las roquillas.
El poder de los Test A/B... No tiene más.
Bien.
Primero, veamos como trabajarás en nuestro panel de administración de IApplication para crear tus test a/b.
Basándonos en la premisa de la historia del Donuts, esta es una funcionalidad que te permite, por ejemplo, mostrar dos variantes diferentes de un botón y el sistema te informará cuál de las dos es la que más se pulsa.
Una vez tengas tu API Key generada, y una aplicación asociada a esa API Key creada, se te desbloqueará esta funcionalidad.
Te dirigirás al menú lateral y pulsarás sobre “Apis y Herramientas”
Ahora selecciona “A/B Testing” de las opciones que aparecen.
Obviamos todo lo que estás viendo en pantalla ahora mismo y pulsas sobre el botón “+” que está en la parte inferior derecha de la pantalla.
Es un nombre identificativo interno, esto no le llegará a tu cliente.
Recomiendo que expliques bien que es lo que vas a hacer en el experimento. Luego te ahorrará mucho tiempo.
Pulsa en continuar.
Cada uno de los experimentos irá asociado a una aplicación, para poder categorizar los datos.
En este paso, selecciona cuál será la app asociada.
Bien, estás serán las opciones que tendrá el experimento.
Por ejemplo:
n Variante A
n Variante B
Nota:
Este es el identificador que llegará al cliente.
Puedes usar la clave cómo el valor a mostrar, por ejemplo:
“Suscríbete ahora”
“Comenzar prueba gratuita”
“Prueba gratis por 7 días”
Pero es una opción que no recomiendo, por el tema de las traducciones.
Yo prefiero crear unas claves genéricas:
“var1”
“var2”
“var3”
Y darle el valor correspondiente a mi botón dependiendo de lo que me llegue.
Hay una diferencia sobre cómo se muestran los datos de los resultados de estos experimentos.
Mira,
Supongamos que quieres evaluar cuanto tarda un usuario en salir de tu aplicación al mostrarle un cuadro de suscríbete cada 1 minutos, o cada 2.
Por la naturaleza de un experimento normal, no podrías hacerlo. Porque en el momento que mandas la confirmación “ha pulsado el botón”, el registro se bloquea y ya no recibirá actualizaciones.
Digamos que este, es un experimento activo.
Pero si es un experimento de tiempo, un experimento pasivo, …
… puedes mandar una actualización cada 10 segundos y actualizar la cantidad de tiempo que tu usuario lleva dentro de tu app.
Cuando la app se cierre, ya no registrará más tiempo, y es ese el valor que se quedará para calcular la diferencia desde que se creó el registro hasta la última vez que se actualizó.
Revisa que todo esté correcto.
En caso de que algo esté mal, pulsa “atrás” y arréglalo.
En caso de que si, “crear experimento” y pasamos a la parte de la integración en el cliente.
¿Qué hacemos si queremos elegir una variante y no queremos/podemos actualizar la app?
Bien,
desde el detalle del experimento existe una opción que puedes seleccionar para que, a partir de ese momento, y sin posible vuelta atrás, se envíe todo el tiempo la misma variante al cliente.
Dando así el experimento por finalizado.
Resultado seleccionado.
Donuts con azúcar glas.
Este proceso es mucho más sencillo.
A modo resumen,
Supongamos,
Tienes un botón que quieres saber si es mejor mostrarlo azul o verde.
Solicitamos una opción al servidor.
Nos llega la variante “var1” que es para ponerlo azul (este registro inicia en negativo).
Ahora esperamos el resultado:
El usuario no ha pulsado el botón: El registro se queda como negativo y así se mostrará en los datos.
El usuario ha pulsado el botón: Actualizas el registro, como veremos a continuación, y lo cambiarás a positivo.
Si el experimento es de tiempo, lo podrás actualizar las veces que veas oportuno.
Si el experimento no es de tiempo, al mandar la confirmación se bloqueará el registro.
Este es todo el proceso para la gestión de los experimentos en el cliente.
Ahora te enseñaré como puedes hacerlo.
URL:
Cabeceras:
Método:
Parámetros:
Respuestas:
{ "R0": 403, "R1": "Prohibido", "R2": ""}
404: No se ha enviado la cabecera app-package-name o no se ha enviado el parámetro uuid_experiment.
{"R0": 404, "R1": "No se ha podido completar, faltan datos", "R2": ""}
404: El experimento no existe.
{"R0": 404, "R1": "No existe", "R2": ""}
200: Todo ha ido bien y aquí están los datos.
{
"R0": 200,
"R1": {
"id": "VllsWmgtcURDbXczY0JYVC12NUFrUGxmV1pZT0t0UkdQU05mWEE1ODNiND0=",
"created_at": 1711532034,
"record_key": "variante"
},
"R2": ""
}
URL:
Cabeceras:
Método:
Parámetros:
Respuestas:
{ "R0": 403, "R1": "Prohibido", "R2": ""}
404: No se ha enviado la cabecera app-package-name o no se ha enviado el parámetro uuid_record.
{"R0": 404, "R1": "No se ha podido completar, faltan datos", "R2": ""}
404: El registro del experimento solicitado no existe.
{"R0": 404, "R1": "No existe", "R2": ""}
200: Todo ha ido bien y aquí están los datos.
{
"R0": 200,
"R1": 1,
"R2": ""
}
En ese caso, cada vez que se solicite un nuevo registro desde la aplicación del cliente, siempre se enviará la variante ganadora.
A parte, se enviará en el ID: "experiment_finished". Por defecto, al enviar este ID al servidor en caso de que el usuario haya completado la tarea pensada para el experimento, el servidor responderá por defecto un 200.