La conversión cayó y ambos segmentos mejoraron: cómo leer el embudo de pago

Se puede mejorar el pago en cada segmento y obtener un porcentaje total peor. Se pueden añadir reintentos y reducir la tasa de éxito de los intentos, mientras se completan más pedidos. Antes de cambiar rutas e interfaz por una caída en la conversión de pagos, revise la unidad de medida, la composición de clientes y el tiempo que les dio a los pagos para completarse.

Cuando el porcentaje total culpa a una integración inocente

Veamos un ejemplo didáctico aislado. En el primer período, el segmento A generó 900 pedidos con una conversión del 90% y el segmento B, 100 pedidos con una conversión del 60%. El resultado fue 810 + 60 = 870 pedidos exitosos de 1 000, es decir, el 87%.

En el segundo período, A mejoró hasta el 92%, pero ahora contiene solo 200 pedidos. B mejoró hasta el 65% y contiene 800 pedidos. Los éxitos fueron 184 + 520 = 704 y la conversión total, del 70,4%. Ambos segmentos crecieron, pero el resultado total bajó 16,6 puntos porcentuales porque cambió la composición del flujo.

Para comprobarlo, compare los períodos con los mismos pesos por segmento. Con las proporciones anteriores del 90% y el 10%, el nuevo resultado sería del 89,3%: 0,9 × 92% + 0,1 × 65%. Es un recálculo analítico, no la conversión real del segundo período. Muestre ambas cifras con su etiqueta: el negocio necesita el total real, y la composición comparable ayuda a evaluar el cambio en el propio proceso.

Un ejemplo, cuatro resultados

Imaginemos una tienda hipotética en la que 1 000 pedidos únicos llegaron a la pantalla de pago. En 800 pedidos, los compradores enviaron al menos un intento. Las acciones repetidas sumaron 940 intentos, de los cuales 680 terminaron con una autorización exitosa y correspondían a 680 pedidos distintos. Al cierre de la ventana elegida, 660 pedidos habían completado la etapa de capture: el vendedor confirmó el cobro del importe autorizado previamente.

• Paso al intento de pago: 800 / 1 000 = 80%.
• Autorización exitosa entre los pedidos que intentaron pagar: 680 / 800 = 85%.
• Tasa de éxito de los intentos individuales: 680 / 940 ≈ 72,3%.
• Proporción de pedidos con capture completado entre los que abrieron el pago: 660 / 1 000 = 66%.

Estos indicadores responden a preguntas distintas. El primero ayuda a estudiar la interfaz y la disponibilidad de los métodos. El segundo muestra el resultado por pedido tras los reintentos permitidos. El tercero describe los intentos y el cuarto refleja el resultado comercial elegido. Si el dinero se cobra sin una etapa de capture separada o se usa una transferencia bancaria, defina el resultado confirmado equivalente para ese método.

Separe pedido, intento y evento

El modelo de datos necesita un identificador estable del pedido, un identificador propio del intento y un identificador del evento. Un intento puede generar varias notificaciones y un pedido puede incluir varios intentos. Mezclarlos infla el numerador o el denominador sin que cambie el comportamiento real de los clientes. En un proceso P2P, el equivalente del pedido puede ser una solicitud concreta, pero sus límites deben definirse de antemano.

Stripe recomienda reutilizar el PaymentIntent cuando se reanuda el mismo proceso de pago. Este objeto ayuda a vincular los intentos fallidos con un mismo carrito o sesión. Es un ejemplo de cómo enlazar un objeto de negocio con el proceso de pago, no un esquema universal para todos los proveedores. Fuente: Stripe, Payment Intents.

Mapa mínimo de eventos

Registre la apertura del pago, la elección del método, el envío del intento, la necesidad de una acción adicional, la finalización de esa acción y el resultado confirmado. Para cada evento, guarde la hora en que ocurrió y la hora en que se recibió, los identificadores, el importe, la moneda, el método y la versión de la integración. No hace falta incluir en los campos analíticos datos de la tarjeta ni datos personales excesivos.

Para el resultado, use la confirmación verificada del servidor que prevé la integración. El regreso del usuario a la página de éxito sirve para evaluar la interfaz, pero por sí solo no basta como prueba de pago. Y a la inversa, que se cierre el navegador no demuestra que la operación haya fallado. Ambas situaciones deben formar parte de los escenarios de prueba de la analítica.

Stripe advierte que los eventos de webhook pueden entregarse más de una vez y sin un orden garantizado. El manejador debe tolerar duplicados y actualizar el estado sin depender del orden de recepción. Fuente: Stripe, Webhooks.

Compare cohortes cerradas

Elija una regla para formar el grupo, por ejemplo, los pedidos que abrieron el pago por primera vez en un día determinado, y deles a todos la misma ventana de observación. Ajuste su duración al método concreto y al ciclo de compra. Mientras la ventana no se cierre, muestre el resultado preliminar y la proporción de operaciones pendientes. Los pagos confirmados tarde deben actualizar la cohorte de origen, no crear un nuevo intento exitoso en un día cualquiera.

Los cortes también exigen disciplina. Compare métodos, dispositivos, monedas y tipos de clientes similares. El porcentaje total puede bajar solo porque aumentó el peso de un segmento más difícil. Antes de culpar a la nueva versión de la integración, verifique el cambio en la composición del tráfico y si hay suficientes observaciones.

El Received payment details report de Adyen incluye datos sobre pagos autorizados y rechazados, la interacción y las respuestas de los participantes del procesamiento. Este informe es útil para conciliar la parte del embudo del lado del servidor, pero no describe a los visitantes que ni siquiera enviaron un pago. Fuente: Adyen, Received payment details report.

Reserve un lugar aparte para las operaciones sin completar

Los resultados preliminares no deben repartirse a la fuerza entre éxitos y rechazos. Separe las operaciones con resultado pendiente o desconocido. Si hoy hay más de ellas, la caída de la conversión puede reflejar un retraso en la confirmación y no una pérdida definitiva de compradores. Para decidir, necesita la antigüedad de la espera y los resultados tras una misma ventana de observación.

Antes de un experimento, anote qué cambia exactamente, quién entra en la comparación y qué se considera completado. Compruebe que un pedido no salte de un grupo a otro al reintentar. No cambie a la vez el denominador, la ventana de observación y la interfaz: de lo contrario, incluso un crecimiento real será difícil de explicar.

En el análisis final, tenga a la vista el número adicional de pedidos completados, el costo de procesamiento, los reembolsos y los reclamos por doble cobro. Estos últimos indicadores pueden aparecer después del primer pago, por lo que un resultado positivo temprano sigue siendo preliminar hasta la verificación de calidad elegida. La mejora que busca debe superar esa verificación, no solo lucir bien el día del lanzamiento.