En un embudo de prueba gratuita, la prueba que importa es que gente como el visitante empezó una prueba y después decidió pagar. Las compras verificadas llegan al final de ese embudo a través de Stripe, lo que significa que la señal más fuerte está disponible justo donde se toma la decisión más difícil. En este artículo recorremos el embudo etapa por etapa y explicamos qué mostrar, qué evitar y cómo mantenerlo honesto.
El embudo de prueba y dónde encaja la prueba social
Un embudo típico de SaaS de autoservicio tiene cuatro pasos:
- Landing o página de marketing. El visitante decide si lo prueba.
- Registro. Decide si vale la pena rellenar el formulario.
- Onboarding y activación. Decide si el producto le sirve.
- Conversión a pago. Decide si vale el dinero.
La prueba social reduce el riesgo percibido, y el riesgo cambia en cada paso. Arriba es "¿me va a hacer perder el tiempo?". Abajo es "¿me va a hacer perder dinero?". Ajustar la prueba al riesgo es todo el juego.
Etapas 1 y 2: el sitio de marketing y el registro
El sitio de marketing.
Aquí el visitante quiere saber que el producto es real, que otros lo usan y que probarlo cuesta poco. Prueba social adecuada:
- Notificaciones de compras verificadas en las páginas de precios y de funciones, que muestran que la gente pasa a planes de pago. Como los registros vienen de webhooks firmados de Stripe, cada uno lleva la marca de Compra verificada enlazada a tu página de verificación. Segméntalas con "solo estas páginas" y un límite por sesión bajo, como se explica en /blog/social-proof-on-pricing-page.
- Un contador en vivo en la página de precios si tiene suficiente movimiento para superar el mínimo con regularidad. El contador mide los visitantes de los últimos 90 segundos y, si no llega, se oculta.
- Prueba social estática en la página: logos con permiso, un número de cuentas con fecha, un enlace a /trust o a tu propia página de confianza.
No pongas notificaciones en el blog ni en la documentación. Ahí los lectores están aprendiendo, no decidiendo.
El formulario de registro.
Deja el widget fuera de la propia página de registro o, como mucho, permite una sola notificación temprana. Un formulario es una tarea, y las capas superpuestas durante una tarea cuestan registros completados. Si quieres dar tranquilidad en la página de registro, ponla en el texto junto al formulario: una frase sobre cuántas personas se registraron este mes, con fecha, es más útil que una notificación deslizante y no interrumpe mientras se escribe.
Etapas 3 y 4: onboarding y conversión
Onboarding.
Dentro del producto, durante la primera sesión, la atención del visitante debería estar en llegar al momento en que el producto demuestra lo que vale. Aquí las notificaciones de compra son sobre todo ruido, y recomendamos desactivarlas.
La excepción es una oferta de bienvenida real y que se aplica. Si las cuentas nuevas tienen un precio reducido durante un periodo fijo tras registrarse, una barra evergreen por visitante en la página de facturación es honesta y útil: cuenta la misma ventana que aplica tu cupón de Stripe, se mantiene entre visitas y desaparece cuando se cierra la ventana. Las condiciones que evitan que esto se convierta en un patrón oscuro están en /blog/evergreen-timers-without-dark-patterns. No muestres la barra si la oferta no se aplica de verdad.
La conversión a pago.
Aquí es donde la prueba verificada se gana el sueldo. En la página de facturación o de mejora de plan dentro de la app:
- Notificaciones de compras de planes verificadas, con límite bajo e intervalo amplio. Un usuario en prueba que está valorando pasar a pago ve que otros pagaron hace poco por el plan que está considerando, y puede hacer clic para ver de dónde salen esos datos.
- La barra evergreen, si existe una oferta de bienvenida y está dentro de su ventana.
- Nada de urgencia falsa. Un usuario en prueba ya usó el producto y se formó una opinión; una cuenta regresiva que se reinicia no la va a cambiar y puede darle la vuelta.
Cómo se ve lo "verificado" en un negocio de suscripción
En un SaaS con Stripe, el evento verificado es el que envía Stripe cuando empieza una suscripción o se completa un pago. El inicio de una prueba no es una compra y no recibe la marca de verificado; la marca está reservada a webhooks firmados que describen dinero cambiando de manos. Eso es una ventaja. "Alguien empezó una prueba gratuita" es una señal débil, y disfrazarla de compra sería engañoso. Si quieres mostrar registros de prueba, etiquétalos con claridad y mantenlos aparte.
| Evento | Fuente | Etiqueta |
|---|---|---|
| Prueba iniciada | Tu app | No es una compra; si acaso, como texto estático |
| Suscripción creada, pago completado | Webhook firmado de Stripe | Compra verificada |
| Clientes históricos importados por CSV | Subida | Imported |
Cómo funciona la cadena está en /blog/how-verified-purchase-notifications-work.
Medir sin engañarte
Los embudos de prueba son largos, y la atribución es donde los paneles de SaaS tienden a atribuirse de más. El conteo de pedidos asistidos por la prueba social de Provedly empareja un pedido verificado con un ID de visitante que vio una notificación en los 30 días anteriores, y nada más. Es un techo de influencia, no una afirmación sobre ingresos. En un embudo de prueba, léelo como "de las pruebas que convirtieron, esta proporción vio antes la prueba social", y haz de vez en cuando un periodo de encendido/apagado para ver si quitar el widget cambia la tasa de conversión. Los detalles y los límites están en /blog/measuring-proof-assisted-orders.
Una nota sobre la ventana de 30 días: si tu prueba dura más de 30 días, algunas conversiones quedarán fuera y se contarán como no asistidas. En ese caso el conteo se queda corto, que es la dirección más segura.
Una configuración de partida
- Notificaciones en
/pricingy/features*, límite de 3, intervalo de 30 segundos, valores por defecto en escritorio y reducidos en móvil. - Contador en vivo solo en
/pricing, solo en escritorio y solo si el tráfico lo permite. - Nada en el registro, la documentación, el blog ni durante el onboarding.
- Notificaciones y, si aplica, una barra evergreen de bienvenida en la página de facturación de la app.
- Stripe conectado para que cada notificación sea una compra verificada; los registros de ejemplo, archivados en cuanto lleguen los reales.
El plan Free de Provedly incluye compras verificadas, un sitio, un widget y una barra, con 2.000 impresiones al mes, lo que cubre un embudo de prueba pequeño. Los planes están en /pricing.
Preguntas frecuentes
¿Debería mostrar notificaciones del tipo "X personas empezaron una prueba hoy"?
Solo si el número es real y está etiquetado como prueba, no como compra. Provedly no verifica los inicios de prueba, así que una notificación así llevaría la etiqueta Imported o Sample, nunca la marca de verificado. Un texto estático con fecha suele ser mejor formato.
¿Dónde ayudan más las notificaciones en un embudo de prueba?
En la página de precios antes del registro y en la página de facturación antes de pasar a pago. Ambos son momentos en los que el visitante pone en la balanza el dinero frente al valor, que es justo la pregunta que responden las compras verificadas.
¿Puedo usar la prueba social dentro de la app y en el sitio de marketing con una sola cuenta?
El plan Free cubre un sitio y un widget. Starter, por $9, cubre dos sitios y cinco widgets, lo que encaja con un sitio de marketing más una app en dominios distintos.
Crea una cuenta gratuita de Provedly y conecta Stripe: /register.