Cómo mejoramos la conversión de facturación

Los pagos en línea se han convertido en algo tan familiar como el wifi en el hogar y la Internet móvil de alta velocidad. Y continúan evolucionando, cada vez se pueden pagar más servicios con un par de clics o desde aplicaciones móviles, y aquí también pagos automáticos, recordatorios, control de costos y mucho más.

En la búsqueda de la funcionalidad, no se olvide del usuario, porque nuestra tarea principal es hacer que le resulte conveniente realizar cualquier pago en cualquier escenario. Esto significa que el formulario de pago debe ser lo más claro posible, y también ofrecer al usuario opciones para resolver problemas si surgen de repente.



Mi nombre es Georgy Konnov, soy el director de desarrollo de productos para comercio electrónico en QIWI, y hoy les contaré cómo desarrollamos un formulario de pago que cualquier tienda puede conectarse rápidamente para aceptar pagos.

Bajo el corte: sobre conversión, motivación del usuario, nuestro protocolo, caridad y código abierto.

Uno de los principales indicadores del éxito de un formulario de pago es, por supuesto, la conversión. Bueno, en serio, si hiciste una forma increíblemente hermosa usando las últimas tecnologías y guías de las mejores compañías, pero estúpidamente no trae dinero debido a la baja conversión, eso significa que hiciste basura, no una forma de pago.

Casi todo el mundo ahora dice que la tasa de conversión de los formularios de pago es de aproximadamente el 99 por ciento, o incluso más. Esto no es asi.

Si honestamente medimos y evaluamos la motivación de las personas para hacer pagos, puede ver que depende mucho de la categoría de pago (si se mide desde la apertura del formulario de pago hasta que se realiza el pago). La motivación máxima es completar el proceso de pago donde el usuario ya pasó una serie de procedimientos complejos: identificación, etc., varios pagos b2b y la misma renovación de dominio, por ejemplo. Luego, la persona abrió el formulario con un claro deseo de renovar el dominio (de lo contrario, se caerá) o realizar un pago importante, y lo hará.

Pero si se trata de una compra regular, aquí puede perder fácilmente inmediatamente una cuarta parte de los clientes en el proceso de pago. Aquí, la conversión ya está en la región del 75-85 por ciento.

Hay muchas razones Si fue algún tipo de compra espontánea ("Estoy cansado, compraré oro rápidamente y me doblaré"), entonces el cliente puede no tener suficiente dinero. O en la ventana final verá una vez más la cantidad que ya está lista para ser debitada de su cuenta, y decidirá que no está mal sin oro. Y cerrará el formulario sin completar el pago.

Y parece que con bienes reales: aquí se pueden distraer campos adicionales, la persona finalmente quiere comprar una aspiradora, y el formulario solicita su número de teléfono, correo y el apodo del gato (estamos aquí para solicitar el formulario de pago, no la cuenta personal de la tienda) que necesita una serie de datos para la entrega y el seguimiento de pedidos). O todo está bien con el formulario, pero al mirar el precio, la persona decide verificar los precios en el mismo mercado de manera más ventajosa y deja el formulario.

Sin embargo, fue un poco sorprendente ver un comportamiento similar al pagar por los servicios educativos. Parece que aquí la determinación es claramente mayor que el deseo de comprar algo para usted yendo al sitio web de la tienda desde una carta con el tema "¡Solo hoy, un 80% de descuento en todo *!".
* para casi todo
** en esos dos hierros y SE reconstruido

Es decir, la persona simplemente eligió el curso correcto para la especialidad deseada, abrió el formulario de pago, y aún las mismas cifras de conversión son pequeñas, como en la caridad.

Medido

La mayoría toma medidas como esta.

Existe una entidad como una transacción. Puede ser exitoso o no exitoso. Si de repente no hay dinero en la cuenta del cliente, se muestra un error que el formulario no puede afectar. Bueno, no hay dinero y no, no lo regales. O se ha producido un error técnico. Como resultado, resulta que del total de pagos con este enfoque, 98-99 se consideran exitosos.

Pero si mide desde el momento en que se abre el formulario de pago hasta que el pago se realiza correctamente, los números serán diferentes.

Vinculamos toda esta historia a las cuentas. Hay una factura, al momento de abrir el formulario está expuesto y vive 45 días. Es decir, una persona puede regresar a la misma forma de pago dentro de estos 45 días y completarla si, por alguna razón, cambia de opinión antes. Esto nos permite ver la conversión completa, incluso si la persona regresó después de unos días, solo una cuenta y se obtiene el monto total. Bueno, como lo demuestra la práctica, las personas pueden volver al proceso de pago con bastante frecuencia.

Sobre recordatorios

Los recordatorios son otra historia por completo. Intentamos diferentes mecánicas aquí. Como era de esperar, la cosa fue con la web empujando. Por ejemplo, había una persona en el sitio web de la tienda, marcó una canasta, recibió una factura en el formulario de pago, que no pagó, y cerró la ventana, y luego recibió el impulso web "Pagar la factura". Tal cosa es molesta. Además, el empuje web sin un contexto adecuado ya se percibe como spam.

Bueno, el 10 por ciento de los usuarios se suscribirá a ese impulso. Entonces el 10 por ciento los cruzará. En general: para un sitio promedio, teniendo en cuenta el tráfico, estos números hacen que la inserción web no sea el canal de recordatorio más útil. Y si también tiene en cuenta que la base de tales cañones por mes está podrida en un 15 por ciento ...

Pero lo que funciona con una explosión: si una persona en el momento del pago muestra su pago olvidado anterior, entonces esto se percibe como un recordatorio útil.

Por ejemplo Jodete, compra un juguete nuevo en Steam. Elegí, comencé a hacer un pedido, me di cuenta de que no habría suficiente dinero ahora, o simplemente decidí posponerlo para más tarde. Una semana después, fui a comprarle una mecha a Ali, usted hizo un pago y luego el formulario: "Pst, quería comprar un juguete hace una semana, mire". Y dichos usuarios suelen ir y completar el pago anterior.

Por números: el empuje web aporta 3 rublos a la lista de correo.
Un recordatorio similar es de 60 rublos.

Dicha mecánica funciona para proveedores conectados a Wallet. Y resulta una situación de ganar-ganar, cuando cada proveedor conectado puede aumentar la conversión de otro.

Operación de protocolo

Anteriormente, teníamos un protocolo de cartera, ya escribí sobre eso aquí .

Solo había una billetera en ella . Y este año anunciamos un nuevo protocolo en el que ahora Wallet, y las adquisiciones, el comercio móvil y las cuotas de acuerdo con nuestra conciencia, serán un montón de otros métodos de pago. Todo esto en una solución, en un solo protocolo.

Nuestro objetivo era hacer estadísticas transparentes para todos. Por lo tanto, dejamos cuentas, que nos permiten monitorear la conversión real de la tienda de la manera más transparente posible, en lugar de técnica. Y agregamos todas las mecánicas que ayudan a aumentar la rotación. Todo llave en mano.

Desde el exterior puede parecer bastante simple todo esto: coloque alguna forma de pago y solo tenga tiempo para contar el dinero. Pero, de hecho, resulta que el comprador puede no tener fondos en la tarjeta. Bueno, eso pasa.

Y aquí, en el formulario, ofrecemos de inmediato una alternativa en tales casos. ¿No es suficiente para pagar? Mire, es posible pagar rápidamente desde nuestro teléfono móvil por SMS. O, en general, según la conciencia, aquí. O algo mas.



Es importante que el cliente vea en este caso no solo un problema, sino también opciones para resolverlo. Es decir, en ausencia de dinero, no es "No hay suficiente dinero" como un error que solo lleva a cerrar la ventana o tratar de ingresar otra tarjeta, sino que ofrece inmediatamente otros métodos de pago sin implementar el usuario.

Este enfoque aumenta la conversión final a pagos exitosos. Debido a que para aumentar la conversión, no puede centrarse en la tasa de adquisición. En general, cualquier intento de enfocarse en la tasa son intentos de competir con un gran banco verde, que tiene el costo de adquisición más bajo, como puede permitirse.

Pero puedes competir en la conversión de pago. Es mucho más fácil aumentarlo en un 2-3 3-5 por ciento que tratar de reducir la tasa de adquisición (que ya está en la región 2).

Por lo tanto, decidimos simplificar la parte de TI tanto como sea posible y agregar todas las mecánicas disponibles al pago. Simplemente tomarlo y conectarlo rápidamente, y todo funcionó para usted.

Ni una sola web

En mi opinión, solo los perezosos no hablaron sobre el papel de los teléfonos móviles en las compras en línea. Así que repetiré la tesis bien conocida y agregaré un poco de nuestros números.

En 2015, recibimos alrededor del 10 por ciento de las llamadas desde teléfonos móviles. Y había aplicaciones móviles geniales en el top 3 de los mercados. Había una opción: ver una aplicación web separada para dispositivos móviles o hacer un pago adaptable simple. Decidimos no molestarnos entonces y, como experimento, hicimos una simple adaptación al móvil. Y durante seis meses, esta cifra ha aumentado del 10% al 30%.

Hace un año, alrededor del 40 por ciento.
Ahora - 51-52.

En general, comprar desde teléfonos móviles es realmente dofiga. Por lo tanto, hicimos un muy buen diseño móvil. Vimos un aumento en los pagos, decidimos realizar un par de estudios más y conversamos con socios en el mercado. Resultó que aquellos que se adaptaron al móvil tuvieron un crecimiento en las ventas. Los que obtuvieron puntajes en el móvil tuvieron aproximadamente el mismo 10%.

Aquí, por cierto, hay un diagrama que muestra la distribución de ventas dependiendo de si la tienda está adaptada o no. Hay 14 grandes tiendas en línea, a las que no llamaremos, pero solo sabremos, grandes.



Quién tiene una aplicación móvil: ya tiene 1.5 veces más compras. Quien tiene una adaptación o aplicación también tiene mejoras de ventas, al igual que una adaptación muy ligera.

Violet en el diagrama son tipos sin adaptabilidad. Pero incluso ellos no son tan tristes como el azul: nada funciona en estos teléfonos móviles.

Yo quería decir eso. No es tan necesario crear una aplicación móvil de primer nivel en busca del tráfico. Incluso la aplicación no niega el hecho de que la adaptación debe hacerse. Incluso las adaptaciones de página más simples ya le mostrarán buenos resultados.

Dimos el primer paso en 2015, como escribí anteriormente. Y ahora tenemos una nueva versión que se adapta muy bien al teclado en pantalla, funciona muy bien con las API de Google y con iOS en términos de mapas de autocompletar. Y todo esto sobre una base llave en mano para que sea rápido y conveniente. Y ahora tenemos una conversión en teléfonos móviles casi igual a la de escritorio. La adaptación misma determina cómo debe aparecer ahora en qué pantalla.

Monedero e Integración

Wallet no se posiciona como el único medio de pago. No tiene que pagar nada, simplemente puede vincular tarjetas o aceptar un pago simplificado, en cuyo caso la billetera actuará como un acelerador de pagos ya conocidos. Si vemos que el usuario nos conoce exactamente (para una serie de signos), podemos dar la oportunidad de desactivar 3DS, por ejemplo. Por supuesto, esta es solo una opción, y si no desea deshabilitar la verificación adicional, entonces no es necesario.

Recordamos la autorización por seis meses, tanto por contraseña como por SMS. Las sesiones se dividen en medias fichas, es decir, la mitad de la ficha con nosotros y la otra mitad en el dispositivo del usuario. Si eso, en 1 clic, la sesión se puede restablecer.

El pago de extremo a extremo funciona en todas partes, por ejemplo, incluso en la aplicación de teléfono móvil AliExpress, se abre nuestro formulario, en el que todo ya está completado si el comprador lo usó antes.



Decidimos admitir la compatibilidad con versiones anteriores, y el nuevo protocolo incorporado funciona para aquellos socios que introdujeron el protocolo en 2010 y aquellos que lo instalaron ayer. Tenemos casi todos los ecommers activos en nuestra base de datos. Y arrastramos toda esta base a nuevas herramientas.

La versión anterior fue afilada debajo de las terminales. Un hombre ingresó su número de teléfono, se emitió una factura, y esta factura apareció en todas partes: en el sitio, en terminales, en el teléfono móvil. Diferentes proveedores que en qué cifras tan diferentes ponen máscaras de entrada, lo que solo complica la integración.

En la nueva versión de la cuenta que hemos guardado. La factura se emite sin ningún signo. El proveedor proporcionó el número de teléfono (OK, no transmitió), trabajamos sin él. El comercio móvil le permite facturar y pagar de inmediato, combinando dos acciones en una sola solicitud. Los socios no tienen que complicarse la vida. Si en algún lugar es posible reducir el número de solicitudes, nos alejamos del resto canónico, lo que simplifica la vida de los desarrolladores durante la integración.

La integración, por cierto, también se simplifica al máximo. El protocolo fue diseñado no solo por técnicos, sino también bajo la vigilancia de una empresa. Y no en términos de monitoreo y ajuste, sino en términos de tener en cuenta al principio todas las dificultades comerciales y simplificar todas las integraciones futuras. El antiguo protocolo tenía 5 parámetros: ID del proveedor, contraseña secreta, ID de autorización, moneda, contraseña para notificaciones.

En el nuevo - 2 parámetros. Una clave pública para formularios web que se puede mostrar fuera, y una clave secreta que se usa en la API del servidor con derechos de acceso completos, la capacidad de cancelar transacciones, realizar reembolsos y más.

Además, hicimos posible transferir cualquier información adicional. Anteriormente, tenía que conocer la identificación de la cuenta y el número de teléfono. Y ahora hay campos personalizados: quiero que el proveedor obtenga el identificador interno del cliente, por favor. Es necesario arrojar un número de teléfono, una dirección para la entrega, eso es todo. En general, para no escribir su propia lógica para todo esto, simplemente puede pasarnos. Y en todas las notificaciones, después del pago exitoso, dichos datos serán devueltos.

El protocolo es modular, puede sustituir cualquier widget y preorden, los probamos activamente para la caridad.

Anteriormente, todo estaba en un monolito. En el que hubo procesamiento. Luego comenzó a crecer demasiado en los costados con artilugios útiles adicionales. Ahora resulta que el procesamiento es realmente responsable de realizar las transacciones. Por cierto, para las tarjetas escribimos una nueva, acelerada para no arrastrar el legado de los tiempos.

Contribuciones de caridad

Hace un par de años nos sentamos y pensamos cómo combinar el pago y el apoyo de fundaciones caritativas de manera normal y completa. El primer pensamiento es simplemente lanzar un poco (por sí mismo, si el usuario lo desea y la casilla correspondiente) directamente en el cheque. Bueno, es decir, compra una tetera por 5000 rublos, marca "Quiero ayudar", y ahora tiene un cheque por 5050, por ejemplo, lo paga. Total de una transacción, en la que parte del dinero va a la tienda y parte al fondo.

Gizmo no es escalable a partir de la palabra en general. El departamento de contabilidad de la compañía a la que estamos transfiriendo está cayendo; aquí, en tales casos, debe hacer un triple acuerdo complicado (nosotros, la compañía, el fondo).

Y regresar es difícil. Cambiaste de opinión sobre la tetera y la devolviste. Y la cantidad para el hervidor y la tarifa fueron en una transacción.

Entonces decidimos hacer así.

Después de un pago exitoso, el usuario está invitado a hacer una pequeña donación en 1 clic. Tal esquema funciona, alrededor del 3-5 por ciento están listos para hacerlo. Aquí la cantidad principal. Si no excede en gran medida los 50 rublos, entonces está bien y es simple. Si es más, entonces ya se necesita un contexto a dónde irá el dinero, y para el fondo, y qué hacen, y así sucesivamente.

Los jóvenes a este respecto son más simples: ven que hay una marca A que creen (una tienda), ven la marca B y todo está bien, están traduciendo. Y las personas mayores necesitan un contexto detallado para asegurarse de que el fondo sea real y que estos 50 rublos no sean para un nuevo BMW para un empleado de la tienda.

Intentamos calcular los montos de las donaciones de diferentes maneras. Por ejemplo, una persona compró algo y, después de la compra, quedarían en su cuenta 123 rublos. En tales casos, propusimos redondear y transferir al fondo 3 rublos o 23 rublos. Bueno, para ti esta bagatela de hierro en una billetera electrónica, bueno, la verdad.

Resultó que aquí estábamos demasiado motivados, y este enfoque no funcionó muy bien. Donde más pronunciadas son precisamente pequeñas cantidades fijas. Por lo general, alrededor del 5 por ciento del saldo.

Anteriormente, los pagos de caridad directamente reconocidos en el sitio web al fondo Khabensky eran de aproximadamente 20 por mes. Se convirtió en unos 30,000 - 35,000 por mes. Lo comenzamos y pensamos que sería bueno mostrar esto no solo con el pago de Wallet, sino también con cualquier otra tarjeta, etc.

Al final descubrimos que las personas no necesitan ese pago en 1 clic, si quieren hacer un pago desde la tarjeta, elegirán el método ellos mismos. Redujeron la hipótesis, por cierto, solo una semana antes de mayo.

Por cierto, puede probar nuestro formulario de pago y, al mismo tiempo, realizar una buena acción apoyando uno de los fondos:

• Fe - Atención sistémica para hospicios y sus pacientes
• Fundación Khabensky : ayuda a niños con enfermedades cerebrales graves
• {a todos - a varios fondos de caridad en partes iguales a la vez

Y los propietarios de sitios pueden ayudar a cualquier fondo publicando un widget o enlace por su cuenta: widget.qiwi.com/vera , my.qiwi.com/bfkh , my.qiwi.com/vsem o muchos otros. Escribe si lo deseas.

Código abierto

Ahora hacia el código abierto nos movimos bastante activamente. Publicamos documentación, ejemplos, SDK e integraciones en https://github.com/QIWI-API/ . Al leer la documentación , puede hacer clic en el botón "editar en GitHub" y solicitar una corrección.

En general, tratamos de arrastrar todo lo que no se está procesando a código abierto. Las API de GitHub QIWI y GitHub QIWI han cobrado vida. Queremos que los proyectos y componentes se ubiquen por separado, y la documentación, varios SDK y bibliotecas en la parte superior de la API QIWI, por separado. Llevamos muchas cosas en GitHub.

Abrimos la API de Wallet para que todas las oportunidades disponibles dentro de la empresa estén abiertas para desarrolladores externos. Básicamente, QIWI ahora se está volcando hacia BaaS, Bank as a Service. Y nuestra tarea aquí es hacer que todos los sitios sean simples, con prácticas comunes. Por lo tanto, nos estamos moviendo a código abierto.

Para el futuro

Queremos tomar todo excelente y trabajar para el pago con QIWI Wallet y usarlo para el trabajo completo con tarjetas: todos estos recordatorios, pagos olvidados, etc. Agregar métodos de facturación bancaria. Por supuesto, Apple Pay y Google Pay. , , , .

CMS-, QIWI . Wordpress , — .

54 2- .

Kassa.qiwi.com — . , .

, API, , .

, , — .

PS , : kassa.qiwi.com/team

React JS- Java-. JS Fullstack 15, , , . , . :)