En varios proyectos he querido responder una pregunta aparentemente sencilla pero vital: ¿cuánto están dispuestos a pagar realmente mis usuarios por este producto o característica? Montar un test de precio controlado me ha permitido medir la willingness-to-pay (WTP) por cohortes y tomar decisiones de producto y pricing con datos reales, no con suposiciones. Aquí te cuento cómo lo hago combinando Google Optimize para la experimentación front y Stripe para gestionar precios y pagos, junto con algunas piezas de backend y análisis para que puedas reproducirlo paso a paso.

Por qué usar Google Optimize + Stripe

Google Optimize es ideal para mostrar variantes de experiencia (precio visible, copy, ofertas). Stripe maneja la lógica de suscripción/pago y facilita recoger conversiones económicas reales. Juntos te permiten exponer a usuarios a precios distintos, capturar su comportamiento hasta la compra y agrupar resultados por cohortes (origen, fecha, plan, dispositivo, etc.).

Arquitectura general del test

La arquitectura que recomiendo es simple pero robusta:

  • Google Optimize controla qué variante ve cada visitante (precio A, precio B, cupón, etc.).
  • Tu front (landing o página de pricing) muestra el precio según la variante.
  • Cuando un usuario inicia el flujo de compra se crea un registro en tu backend con la variante asignada y metadatos de cohortes (utm, device, signup date...).
  • Stripe procesa el pago y webhooks informan a tu backend del resultado (éxito, fallo, suscripción recurrente).
  • Unida la información, analizas WTP por cohortes: conversión a pago, ARPU, LTV estimado, churn inicial.

    • Diseño del experimento en Google Optimize

    Mi objetivo es que la asignación de variantes sea aleatoria y que puedas segmentar por cohorts. En Optimize creo un experimento tipo A/B con variantes que cambian el precio mostrado y, opcionalmente, el copy:

  • Control: precio actual (p. ej. €10/mes).
  • Variante 1: precio alto (p. ej. €15/mes).
  • Variante 2: precio bajo (p. ej. €7/mes).

    • Para cada variante uso un custom dimension en Google Analytics o un atributo en el dataLayer que marca la variante (por ejemplo, optimizeVariant = 'price_15'). Esto me permite cruzar datos Behavioral + Revenue.

    Mostrar el precio correcto en el front

    Es crítico que el precio visible y el precio que Stripe cobra coincidan. No quiero sorpresas legales ni usuarios enfadados. Hay dos enfoques:

  • Cliente: Google Optimize modifica el DOM y muestra el precio. Cuando el usuario hace clic en "Comprar", el front envía la variante al backend y el backend crea la sesión de Stripe con el precio correspondiente.
  • Server-side (más seguro): Antes de renderizar la página (o al iniciar checkout), tu backend consulta la asignación de Optimize (o un servicio propio) y devuelve el precio correcto. Esto evita discrepancias y manipulaciones.

    • En proyectos con recursos, prefiero la versión server-side. En MVPs, la versión cliente es más rápida de montar pero exige verificaciones extra.

    Registrar la variante y crear la sesión en Stripe

    Cuando el usuario inicia el checkout, envía al backend:

  • user_id (si existe o anonymous_id),
  • optimize_variant,
  • utm_campaign/medium/source,
  • plan_id (si aplica).

    • El backend crea un registro de "intent" con esos campos y crea una sesión de Checkout en Stripe usando la price_id correspondiente. Importante: guarda la referencia de Stripe (session_id) con la intent para poder unificar más tarde.

    Ejemplo conceptual en pseudo-Node.js:

    <!-- Pseudo-código, no pegues sin adaptar -->

    fetch('/create-checkout', {method:'POST', body: {variant: 'price_15', userId}})

    En el servidor:

    1) registrar intent en BD con variant y meta.

    2) stripe.checkout.sessions.create({line_items:[{price: PRICE_ID_FOR_VARIANT, quantity:1}], success_url, cancel_url})

    Usar webhooks de Stripe para medir conversiones reales

    Los webhooks son la clave para medir conversiones económicas reales (no solo clicks). Registro eventos como:

  • checkout.session.completed — pago inicial hecho;
  • invoice.paid — suscripción renovada;
  • payment_intent.payment_failed — fallos;
  • customer.subscription.deleted — churn.

    • Cada webhook actualiza el registro inicial (intent) con el resultado y la información de revenue. Así tienes una tabla donde cada fila es un intento con variante, cohortes y resultado monetizado.

    Definir cohortes útiles

    No todas las cohortes aportan valor. Yo suelo empezar con:

  • Cohorte por canal (utm_source/medium/campaign).
  • Cohorte por fecha de adquisición (semana/mes).
  • Segmentos por tipo de usuario (free trial vs cold visitors).
  • Dispositivo o geografía si sospechas sensibilidad al precio local.

    • La idea es ver si la sensibilidad al precio varía entre grupos: quizá usuarios de una campaña paguen más que el tráfico orgánico, o clientes en un país X acepten precios más altos.

    Métricas a calcular

    Para evaluar WTP por variante y cohorte calculo:

  • Tasa de conversión (visita → pago inicial).
  • ARPU (ingreso medio por usuario) en el periodo de observación.
  • Tasa de fallo en pago (indica fricción).
  • Churn a 7/30/90 días para estimar LTV.
  • Elasticidad del precio: porcentaje de caída en conversión vs aumento de precio.
    • MétricaQué me dice
    Tasa de conversiónSensibilidad inmediata al precio
    ARPUIngreso medio y trade-off entre precio y volumen
    Churn inicialCalidad del buyer (si sube con precio alto, quizá atraes different profile)

    Ejemplo de interpretación

    En un experimento reciente, aumentar el precio 50% redujo conversión un 30% pero aumentó ARPU global un 10% y no empeoró churn a 30 días. Con esos datos decidimos subir precio para nuevos clientes mientras manteníamos descuentos de migración para usuarios existentes. Esa segmentación fue posible gracias a medir por cohortes (nuevos vs existentes) y por canal.

    Precauciones legales y experiencia de usuario

    Dos aspectos que no puedes ignorar:

  • Transparencia y contratos: el precio que muestras debe ser el que cobras. Evita discrepancias y asegúrate de que términos y política de reembolso están claros.
  • Consentimiento y privacidad: si recoges UTMs, user_ids y cruzas con datos de pagos, respeta RGPD/LPD. Anonimiza cuando sea posible y documenta el uso de datos.

    • Errores comunes que he cometido

    - No guardar la variante en el backend: perdí muchos datos porque dependía solo del cookie de Optimize que caducó.

    - No vincular webhooks con el intent: atribuía pagos a la variante incorrecta.

    - Ignorar la tasa de fallo de pago: un precio más alto puede implicar más intentos fallidos por métodos de pago rechazados en ciertos países.

    Próximos pasos para implantar tu propio test

    Si te interesa, te dejo una checklist rápida para arrancar:

  • Define variantes y hipótesis (qué esperas ver).
  • Implementa variante visible con Google Optimize y envía la variante al backend al iniciar checkout.
  • Registra intent en BD con meta datos de cohortes.
  • Usa Stripe Checkout o Payment Intents y vincula session_id con intent.
  • Procesa webhooks y actualiza resultados.
  • Mide métricas por cohorte y decide acciones (precio definitivo, segmentación, promociones).

    • Si quieres puedo compartir un diagrama más técnico o snippets adaptados a tu stack (Node.js, Rails, Django). También puedo ayudarte a elegir variantes de precio iniciales basadas en la psicología del pricing (p. ej. anclajes, precio psicológico, ofertas por tiempo limitado). Es un ejercicio tan técnico como estratégico: con la instrumentación correcta, los datos te cuentan justo lo que necesitas saber.