Cuando pienso en optimizar ingresos, no me interesa tanto subir precios al tuntún como entender cuánto valor percibe cada segmento de mis usuarios y diseñar pruebas que validen hipótesis con datos. En este artículo cuento cómo diseño pruebas de pricing basadas en valor percibido y cómo aprovecho Stripe (Billing, Prices, Checkout y webhooks) para ejecutar experimentos que aumenten el ARPU por cohortes de forma ordenada y reproducible.
Por qué probar precios por valor percibido (y no solo por elasticidad)
La elasticidad precio-demanda es útil, pero muchas decisiones de pricing que funcionan a largo plazo se basan en el valor percibido: lo que un cliente piensa que gana con tu producto. Dos usuarios con la misma actividad pueden valorar tu producto de forma diferente por sector, tamaño de empresa, caso de uso o etapa del funnel. Si no segmentas y pruebas por cohortes, acabarás aplicando un solo precio que deja dinero sobre la mesa para algunos y espanta a otros.
Defino cohortes por hipótesis de valor
Antes de tocar Stripe, defino cohortes basadas en hipótesis claras de valor. Ejemplos:
Startups en etapa seed vs. pymes establecidas (hipótesis: pymes pagan más por soporte y estabilidad).Usuarios con alta frecuencia de uso vs. usuarios esporádicos (hipótesis: los de alta frecuencia aceptan pagar más por productividad).Cohortes por canal de adquisición: orgánico vs. pago (hipótesis: tráfico orgánico tiene mayor LTV y tolera mejores precios).Cada cohorte debe tener una justificación de por qué puede valorar el producto de manera distinta. Estas hipótesis guían el diseño de los precios que vamos a probar.
Cómo preparo Stripe para pruebas de pricing
Stripe no tiene un "A/B testing" nativo para precios al nivel de producto, pero su modelo con Products y Prices, junto con Checkout, metadata y webhooks, me permite orquestar experimentos robustos.
Crear un Product por oferta o mantener uno y crear múltiples Price objects. Por ejemplo: price_basic_A, price_basic_B, price_basic_premium.Usar metadata en Customers y Checkout Sessions para marcar la cohorte y la variante del experimento (ej. metadata: cohort=seed, variant=B).Generar Checkout Sessions con el Price id correspondiente según la asignación aleatoria o regla de segmentación.Exportar datos a BigQuery (Stripe tiene integración nativa) o a tu datastore para análisis por cohortes.Activar webhooks para eventos relevantes: checkout.session.completed, invoice.paid, invoice.payment_failed, customer.subscription.updated, customer.deleted.De esta forma, cada suscripción queda etiquetada y podrás analizar métricas por variante y cohorte.
Diseño experimental: asignación y tamaño de muestra
No improvises la asignación. Yo suelo aplicar dos enfoques según riesgo:
Prueba de bajo riesgo (pricing cercano): asignación aleatoria 50/50 entre control y variante para cohorts grandes.Prueba escalonada (pricing arriesgado): empezar con 5-10% del tráfico o cohortes seleccionados y escalar si los indicadores son positivos.Necesitas estimar el tamaño mínimo para detectar una diferencia en conversión o ARPU. Si tu métrica clave es ARPU, la varianza puede ser alta; conviene estimar la desviación estándar histórica y calcular tamaño muestral para lograr potencia estadística (80%) y un alfa aceptable (5%). Si no tienes suficiente tráfico, prioriza pruebas que midan conversiones (tasa de compra), que suelen necesitar menos datos.
Métricas que seguimiento
Al diseñar las pruebas marco mis métricas primarias y secundarias:
Métrica primaria: ARPU por cohorte (ingresos recurrentes / número de usuarios activos de la cohorte) en ventana definida (ej. 30/90 días).Métricas de apoyo: tasa de conversión desde prueba o free trial a pago, MRR por cohorte, churn mensual, LTV estimado, revenue retention (GRR/NRR).Señales de alarma: aumento del churn > X%, disminución de NRR, o caída significativa en la conversión que anule cualquier ganancia en ARPU.Registrar la fecha de asignación, precio aplicado, descuentos y trial lengths es esencial para aislar efecto precio de otras variables.
Implementación técnica paso a paso con Stripe
Así es como lo hago, paso a paso:
1) Crear Prices en Stripe: por cada variante del experimento creo un Price (puede ser recurrente mensual/anual o un one-off). Uso nombres y metadata claros, por ejemplo: price_123 (variant=A, cohort=seed).2) Control de sesión de compra: cuando un usuario llega al checkout, aplico la regla de asignación (aleatoria o basada en cohort). Creo la Checkout Session con el Price id correspondiente. En la sesión incluyo metadata: cohort, variant, experiment_id, acquisition_channel.3) Registrar evento de exposición: si es una prueba de exposición (mostrar precio pero no obligar), guardo en mi base de datos quién vio qué precio. Esto permite intención-to-pay analysis.4) Webhooks para finalización: en checkout.session.completed, associo el customer.id con la cohorte y la variante y empiezo a monitorear ingresos y facturación.5) Exportación y almacenamiento: uso la exportación a BigQuery de Stripe o envío los datos via webhook a mi ETL hacia Postgres. Dejo campos clave: customer_id, price_id, product_id, currency, amount, created, trial_end, coupon_applied.Análisis: cómo calcular ARPU por cohorte y variante
Mi fórmula básica para ARPU en una ventana T es:
ARPU = (Ingresos totales generados por la cohorte en ventana T) / (Número de usuarios asignados a la cohorte que estaban activos en el periodo)
Importante: definir “activo” según tu negocio. Para SaaS suele ser “usuarios con suscripción activa” al final de la ventana o “usuarios con login/uso”.
Una tabla simple que me gusta mantener en el dashboard:
| Cohorte | Variant | Users | MRR | ARPU (30d) | Churn 30d |
|---|
| Seed | A | 1,200 | €12,000 | €10 | 2.1% |
| Seed | B | 1,150 | €14,950 | €13 | 2.5% |
Interpretación y decisiones
No basta con ver que una variante genera más ARPU: hay que mirar el conjunto de métricas y el impacto en LTV. Una subida de ARPU que acompaña un aumento de churn puede ser peor a largo plazo. Por eso defino reglas de decisión antes de lanzar:
Si ARPU aumenta y churn no sube > X%, considerar rollout.Si ARPU sube pero churn aumenta > X% o NRR cae, detener y analizar segmentación.Si conversión cae mucho (p. ej. -20%) a pesar de mayor MRR por cliente, quizá el precio está sacando usuarios y limita crecimiento.Ejemplos prácticos de pruebas que he lanzado
Algunos experimentos concretos que he probado:
Segmentación por actividad: poner un precio Premium a usuarios con >10 acciones/mes. Resultado: ARPU +18% en la cohorte alta, churn estable.Prueba de anchura de planes (feature tiers): añadir un plan intermedio orientado a pymes. Resultado: migración desde plan básico al intermedio, ARPU por cohorte pymes +24%.Trial length: reducir trial de 30 a 14 días para una cohorte con alta fricción. Resultado: conversión a pago mejoró (porque la urgencia aumentó) y ARPU por cohorte subió ligeramente.Automatización y escalado
Una vez que la prueba está validada, convierto el flujo en algo repetible:
Promuevo el Price ganador a oferta estándar y actualizo la documentación interna.Automatizo etiquetado de clientes antiguos y/o migración mediante Stripe Subscription Schedules o creando nuevas suscripciones con el Price ganador y comunicando el cambio.Monitoreo continuo con dashboards en Looker/Metabase que unan datos de Stripe con producto (uso) y adquisición.Si quieres, puedo compartir una plantilla de datos (schema) para analizar ARPU por cohorte con BigQuery o SQL y un ejemplo de payload de webhook que uso para etiquetar clientes en tiempo real.
