Track
Primeros pasosGuíaIntermedio

Eventos de suscripción y SaaS: trials, suscripciones, renovaciones y bajas sin inflar los ingresos

Cómo modelar un negocio de suscripción con el vocabulario de eventos estándar — sign_up, start_trial, subscribe, purchase para renovaciones, refund para cancelaciones —, dónde debería originarse cada evento, qué valor enviar a las plataformas publicitarias y cómo mantener las renovaciones fuera de las métricas de adquisición.

Por
Equipo editorial de Track
Publicado
Última revisión
Tiempo de lectura
3 min de lectura

Puntos clave

  • Modela el ciclo de vida con sign_up, start_trial, subscribe, purchase con flags de renovación o expansión, refund y login; el sistema de facturación es la autoridad para todo lo que implica dinero.
  • Las renovaciones no deben enviarse como subscribe: asigna solo el evento de adquisición a las acciones de conversión publicitarias para que las plataformas no aprendan a perseguir a los clientes existentes.
  • Los valores se mantienen honestos: el importe de la primera factura para subscribe, como mucho constantes documentadas por plan, el delta en las expansiones e importes negativos en los reembolsos.
  • El consentimiento registrado en el alta viaja con el webhook de facturación; ser cliente no es consentimiento, y los IDs de factura o de suscripción como transaction_id absorben los reintentos del webhook.

El ciclo de vida en eventos

Momento del ciclo de vidaEventoOrigenPropiedades
Cuenta creadasign_upnavegador (híbrido)method
Trial iniciadostart_trialservidor (webhook de facturación)plan, trial_days
Primera suscripción de pagosubscribeservidor (webhook de facturación)plan, interval, value, currency, transaction_id
Factura de renovación pagadapurchase con props.renewal: trueservidorvalue, currency, transaction_id
Upgrade / expansiónpurchase con props.expansion: trueservidorvalue delta
Cancelación o reembolsorefundservidortransaction_id original, value negativo
Inicio de sesiónloginnavegador

El sistema de facturación es la autoridad para todo lo que implica dinero. El navegador puede mostrar una página de «suscripción confirmada», pero el evento que llega a las plataformas publicitarias sale del webhook, con los ID del sistema de facturación.

Por qué las renovaciones no deben ser subscribe

Las plataformas publicitarias optimizan hacia la conversión que les envías. Si cada renovación mensual llega como una suscripción nueva con valor, la plataforma aprende que los clientes existentes convierten bien y puja para volver a alcanzarlos. Mantén el evento de adquisición (subscribe, una vez por cliente) separado de la retención (purchase con el flag de renovación) y asigna solo el evento de adquisición a las acciones de conversión publicitarias. Las renovaciones siguen fluyendo hacia la analítica y hacia tus propios informes.

Valores para las plataformas publicitarias

  • subscribe: el importe de la primera factura es defendible y sencillo. Enviar una estimación del valor de vida del cliente solo está permitido como constante documentada por plan en el mapeo del destino, visible en el registro de auditoría; nunca como una conjetura por usuario.
  • start_trial: sin valor, o un valor esperado documentado por plan.
  • Expansión: el delta, no el nuevo total.
  • refund: valor negativo del importe reembolsado; GA4 procesa los reembolsos por ID de transacción, Google Ads mediante ajustes de conversiones y la mayoría de las demás plataformas lo ignoran: el conector aplica lo que admite cada proveedor.

Identidad entre dispositivos

Un cliente SaaS se registra en el escritorio, paga desde el móvil e inicia sesión en todas partes. Llama a identify con tu ID de usuario y, bajo consentimiento de marketing, con el correo electrónico con hash; los eventos de servidor llevan el mismo ID de usuario y el mismo hash. Eso es lo que permite a las plataformas asociar un subscribe server-side con el clic en el anuncio que ocurrió días antes en otro dispositivo, dentro de sus ventanas.

Trials y consentimiento

El webhook de facturación lleva el estado del consentimiento que tu sistema registró en el alta, junto con el ID de usuario. El router aplica ese estado: un usuario que rechazó el marketing al registrarse solo produce eventos de analítica, y un webhook sin información de consentimiento no llega a ningún destino publicitario. No vuelvas a derivar el consentimiento del hecho de que alguien se haya convertido en cliente; ser cliente no es consentir la medición publicitaria.

Deduplicación frente a los reintentos de facturación

Los sistemas de facturación reintentan los webhooks. Usa el ID de factura o de suscripción como transaction_id; la etapa de ingesta marca un segundo subscribe o purchase con el mismo ID de transacción como conversión duplicada, y las plataformas que deduplican por ID de pedido fusionan lo que haya conseguido pasar.

Informes que se mantienen honestos

  • Adquisición: número y valor de subscribe por campaña, desde las plataformas publicitarias y desde tus propios eventos.
  • Conversión del trial: start_trialsubscribe por plan, solo desde tus propios eventos.
  • Ingresos netos: purchase (todos los flags) menos refund, desde facturación, conciliados cada mes con los eventos.

Si alguna vez esas tres cifras discrepan de los informes del propio sistema de facturación, el desglose por origen en la página de eventos muestra qué vía está perdiendo qué.

Fuentes primarias

Documentación y estándares en los que se basa este artículo.

  1. Stripe — Webhook events for subscriptionsdocs.stripe.com

¿Te ha resultado útil este artículo?

Editor responsable

Equipo editorial de Track

Producto e ingeniería

Las personas que construyen Track: ingenieros y analistas que trabajan a diario en tracking server-side, herramientas de consentimiento e integraciones de conectores.