Cómo hacer A/B Testing en la página de donación de tu servidor de MU Online

La página de donación es el activo comercial más importante de cualquier servidor privado de MU Online: es allí donde la comunidad convierte el engagement en ingresos que pagan el hosting, la protección DDoS y el tiempo del equipo de desarrollo. Pequeños cambios de copy, layout o precio pueden generar variaciones de 15% a 40% en la conversión — pero sin un proceso estructurado de prueba, esos cambios se convierten en simples corazonadas del administrador. Este tutorial muestra cómo montar un programa de A/B testing para la página de donación, desde la formulación de la hipótesis hasta la lectura estadística del resultado, evitando decisiones basadas en "sensación" o en una muestra demasiado pequeña para significar algo.

Por qué probar la página de donación y no solo "mejorarla al ojo"

Los administradores de servidor suelen rediseñar la página de donación basándose en gusto personal o copiando al competidor con más jugadores. El problema es que una página que convierte bien para un público (PvP hardcore, servidor x1000) puede convertir mal para otro (casual, servidor x50). Un programa de A/B testing cambia la pregunta "qué me parece bonito" por "qué hace que más gente complete el pago", midiendo con datos reales de tu propio público. Esto es especialmente crítico cuando el cambio involucra precio o eliminación de un ítem de la tienda, puntos que generan fricción directa con la comunidad si se deciden mal.

Definiendo la métrica principal antes que nada

Antes de diseñar cualquier variante, define qué métrica decide la prueba. Las más usadas en portales de MU son:

Elige una métrica principal por prueba. Correr una prueba optimizando conversión y ticket promedio al mismo tiempo, sin prioridad definida, es la causa más común de "la prueba dio inconclusa" en reportes de la comunidad.

Formulando la hipótesis

Toda prueba debería seguir el formato: "Si cambio [X], espero que [métrica] mejore porque [motivo basado en comportamiento observado]". Ejemplos de hipótesis sólidas para servidores de MU:

• "Si muestro el bono de Jewels que el jugador gana al comprar el paquete de 50 Coins, espero aumentar la conversión porque hoy el jugador no percibe el valor agregado del paquete."
• "Si reduzco de 6 a 3 los paquetes mostrados en la página, espero aumentar el ticket promedio porque el exceso de opciones está causando parálisis de decisión (paradoja de la elección)."
• "Si agrego un contador de donadores del día/mes, espero aumentar la conversión porque la prueba social reduce la duda de quien nunca ha donado."

Hipótesis vagas como "hagámoslo más bonito" no generan aprendizaje — aunque la variante gane, no sabrás por qué, y no podrás replicar la ganancia en otra prueba.

Estructura técnica: cómo dividir el tráfico sin dos versiones del sitio

Para servidores que usan un CMS propio (PHP con panel tipo IGCN, MuEMU Website, o WordPress personalizado), la forma más simple es una cookie de bucket definida en el primer acceso:

<?php
// bucket.php - se ejecuta antes de renderizar la página de donación
session_start();
if (!isset($_COOKIE['ab_donation_test'])) {
    $bucket = (mt_rand(0, 1) === 0) ? 'A' : 'B';
    setcookie('ab_donation_test', $bucket, time() + 60*60*24*30, '/');
    $_COOKIE['ab_donation_test'] = $bucket;
}
$variant = $_COOKIE['ab_donation_test'];

if ($variant === 'B') {
    include 'doacao_variante_b.php';
} else {
    include 'doacao_variante_a.php';
}

Este patrón garantiza que el mismo jugador siempre vea la misma variante (consistencia), lo cual es esencial: alternar el layout en cada visita destruye la confianza del usuario y contamina los datos, ya que podría iniciar el pago en una variante y terminarlo viendo otra.

Herramientas para medir sin reinventar la rueda

No necesitas construir un motor estadístico desde cero. Opciones compatibles con sitios de MU Online:

Para la mayoría de los administradores, GA4 con un evento donation_variant_view y otro donation_purchase_complete, cruzados por segmento, ya es suficiente para decidir la prueba sin costo adicional.

Calculando el tamaño de muestra antes de lanzar

Un error recurrente es terminar la prueba en cuanto una variante "parece" estar ganando. Antes de correrla, estima cuántas conversiones necesitas para detectar la diferencia que importa. Como referencia práctica (no exacta), para detectar una mejora relativa del 20% sobre una conversión base del 3%, necesitas aproximadamente entre 2.000 y 3.000 visitantes por variante — números que servidores medianos (2 a 5 mil jugadores activos) alcanzan en 1 a 2 semanas en la página de donación.

Si tu servidor tiene tráfico bajo, prefiere probar cambios con un efecto esperado grande (rediseñar toda la página) en vez de detalles finos (color del botón), ya que los efectos pequeños requieren muestras mucho mayores para detectarse con confianza.

Corriendo la prueba: duración y ventanas de contaminación

Nunca termines una prueba antes de completar al menos un ciclo semanal completo — las donaciones se comportan de forma muy distinta en el día de reset de season, en un evento de drop doble, o en un fin de semana de pago (muchos jugadores reciben su salario a inicio/mediados de mes). Si tu servidor hace reset de ranking mensual, incluye al menos uno de esos ciclos en la prueba, ya que ese día suele concentrar entre el 20% y el 40% de los ingresos mensuales en servidores con season corta.

Leyendo el resultado con significancia estadística

Después de recolectar los datos, calcula si la diferencia observada es estadísticamente significativa o solo ruido. Una prueba de proporción (z-test) simple entre las dos tasas de conversión, con un nivel de confianza del 95%, es el estándar del mercado. Herramientas como GrowthBook y PostHog calculan esto automáticamente; si lo haces manualmente, usa una calculadora de significancia A/B (existen varias gratuitas en línea) alimentada con: visitantes de la variante A, conversiones de A, visitantes de B, conversiones de B.

Pruebas prioritarias para empezar

Si nunca has hecho A/B testing en la donación, comienza por estas, en el orden de impacto histórico observado en portales de MU:

1. Titular y propuesta de valor en la parte superior de la página (enfoque en beneficio vs. enfoque en ítem).
2. Número y composición de paquetes mostrados (3 paquetes vs. 6 paquetes).
3. Sello de "más popular" en un paquete intermedio (efecto ancla de precio).
4. Mostrar u ocultar el total recaudado/meta del servidor (transparencia vs. urgencia).
5. Orden de los métodos de pago (Pix primero vs. tarjeta primero, para público de Brasil).

Cuidados éticos y de comunidad

Probar precio y escasez artificial ("quedan 3 unidades") puede generar desconfianza si la comunidad percibe manipulación, especialmente en servidores más pequeños donde la base está más cerca del equipo de administración. Evita crear escasez falsa (números ficticios de "cupos restantes"); prefiere probar elementos legítimos como claridad de la información, prueba social real (número real de donadores) y facilidad de pago. Las pruebas percibidas como engañosas cuestan más en reputación que cualquier ganancia de conversión a corto plazo.

Errores comunes y soluciones

Lista de verificación de implementación del A/B testing

• Métrica principal definida antes del lanzamiento de la prueba.
• Hipótesis escrita en el formato "si X, entonces Y, porque Z".
• Tamaño de muestra estimado para el efecto esperado.
• Cookie/bucket de variante persistente y consistente por jugador.
• Herramienta de medición configurada (GA4, GrowthBook o PostHog).
• Duración mínima de un ciclo semanal/season definida.
• Significancia estadística calculada antes de declarar un ganador.
• Cambio comunicado a la comunidad si involucra precio o paquetes.

Después de validar tus primeras pruebas, el siguiente paso natural es conectar los resultados de la página de donación con el resto de la telemetría de tu portal, cruzando la conversión con los datos de gameplay y retención descritos en el tutorial de cómo crear un servidor de MU Online, cerrando el ciclo entre el engagement in-game y los ingresos.

Preguntas frecuentes