Experimentos

Un experimento reparte una parte de la audiencia de una campaña entre dos o más versiones, espera, y después envía al resto la versión que ganó. Tú eliges con qué porcentaje de la lista probar y cuánto esperar; Bitelio decide la ganadora y libera el resto.

Qué se puede probar

Cualquier cosa que pertenezca al mensaje: el asunto, el cuerpo, la dirección del remitente y el nombre del remitente. Una versión sobrescribe solo los campos que le des — una versión que prueba el asunto conserva el cuerpo de la campaña, así que no hace falta repetirlo.

La hora de envío no está en esa lista. Es una propiedad del momento, no del mensaje: cuando se conoce la ganadora, la hora ganadora ya ha pasado, así que no queda nada que enviar al resto de la audiencia.

Cómo funciona el reparto

Eliges una muestra, entre el 5% y el 50% de la audiencia. Esa muestra se divide a partes iguales entre tus versiones; el resto de la lista no recibe nada hasta que hay una ganadora.

Qué contacto cae en qué versión lo decide un hash de su identificador, así que nunca cambia. Si un envío se reintenta tras una interrupción, la misma persona sigue en la misma versión en lugar de contar en las dos.

Elegir qué lo decide

Puedes decidir por clics o por ingresos atribuidos.

No puedes decidir por aperturas, y es deliberado. Apple Mail Privacy Protection carga las imágenes del mensaje en nombre del destinatario, lo que registra una apertura tanto si alguien lo leyó como si no. En una lista de consumo eso suele ser la mitad del tráfico o más, y afecta igual a las dos versiones — así que la diferencia que intentas medir queda enterrada bajo ruido idéntico. Un test de asunto medido por aperturas puede nombrar ganadora a la versión equivocada, o no encontrar ninguna cuando la había. Las aperturas siguen apareciendo en los resultados como contexto; simplemente no pueden decidir nada.

Por la misma razón, los ingresos cuentan solo los pedidos atribuidos mediante un clic. Bitelio también acredita a un email pedidos cuando solo hubo apertura y ningún clic, lo cual es una estimación razonable para los informes normales — pero dentro de un experimento repartiría dinero según qué versión abrió Apple, que es casi al azar.

Cuánto dura y cómo termina

Fijas un plazo y un tamaño de muestra. Bitelio vigila los resultados de forma continua y termina el test en cuanto equivocarse deja de ser caro — no en cuanto una versión va por delante.

Esa distinción es lo esencial. "La versión B va ganando" no dice nada sobre cuánto pierdes si la eliges y te equivocas: un 96% de probabilidad de que B sea mejor por un 0,1% no merece actuar, y un test que se para en cuanto pinta bien es un test que siempre encuentra una ganadora, exista o no. Bitelio mide el coste esperado de la decisión, y concluye cuando ese coste baja del que has fijado.

Mientras el test corre puedes ver a cuántos destinatarios llegó cada versión, pero ninguna aparece marcada como ganadora. Es a propósito: una clasificación invita a parar antes de tiempo, y parar antes de tiempo es lo que hace que los resultados A/B no sean fiables.

Si llega el plazo sin una respuesta clara, gana la versión de control y el resultado dice que no se detectó ninguna diferencia. Eso es un resultado real, no un fallo — significa que el efecto, si lo había, era más pequeño de lo que esta audiencia podía resolver. Bitelio no inventa una ganadora para parecer concluyente.

Guardrails

Las bajas, las quejas de spam y los rebotes se miden por versión. Una versión que supere tu umbral queda descalificada: no puede ganar, y no se enviará al resto de la lista por bien que le fuera en clics o ingresos.

Las quejas son las que más pesan. Dañan la entregabilidad de todo tu proyecto, no solo de esta campaña, así que una versión que las provoca no es una ganadora aunque ingrese más — ni llegará a serlo agotando el plazo.

Un solo evento nunca descalifica a una versión. Un guardrail necesita al menos dos para actuar, porque uno no es una tasa: los resultados se revisan cada pocos minutos, así que un test recién lanzado suele estar sobre una muestra a medio entregar, y una queja temprana entre los primeros doscientos destinatarios se leería muy por encima de cualquier umbral razonable. Una queja es lo normal en cualquier lista. Dos ya es un patrón.

Si todas las versiones quedan descalificadas, el experimento se detiene y la audiencia restante se queda sin enviar.

Qué hace falta para lanzar uno

Un test necesita gente suficiente para llenar cada versión. Bitelio rechaza un experimento cuya audiencia no alcance el mínimo para cada versión con el tamaño de muestra elegido, y te dice cuántos contactos harían falta — porque un experimento que no puede concluir gasta el envío y no enseña nada.

Crear un experimento requiere el permiso campaigns:edit. Decidir una ganadora a mano requiere campaigns:send, porque liberar el resto es un envío: manda la versión ganadora al resto de la lista y no se puede recuperar.

Un experimento solo se puede añadir a una campaña que siga siendo borrador o esté programada — no a una que ya espera aprobación, porque quien aprobó dio el visto bueno a una campaña concreta.

Referencia de la API

• POST /experiments — crea un experimento. Cuerpo: { campaignId, metric, samplePct, decideBy, lossThreshold, minExposurePerArm?, autoDecide?, variants }. Exactamente una variante debe llevar isControl. Requiere campaigns:edit.
• GET /experiments/:campaignId — el experimento y sus versiones, incluyendo cuáles están descalificadas y por qué.
• POST /experiments/:id/decide — termina el test tú mismo. Cuerpo: { variantId }. Requiere campaigns:send. Se rechaza una versión descalificada, y también una que pertenezca a otro experimento.
• DELETE /experiments/:id — elimina un experimento que aún no ha empezado a enviarse.