Cómo usar análisis avanzados para reducir las aplicaciones de baja calidad y aumentar las conversiones

El panorama digital en rápida evolución abarca todo tipo de negocios, desde el comercio electrónico y el comercio minorista hasta las compañías de seguros y los bancos. Y a medida que los servicios y productos bancarios se convierten en productos básicos, su objetivo es transformar los servicios en un formato en línea junto con la optimización general de los procesos comerciales. Al igual que cualquier otra empresa que entra en línea, los bancos también quieren maximizar su ROI, crear nuevos servicios más rápido y obtener una ventaja competitiva. Para explorar una enorme cantidad de conjuntos de datos, los sistemas bancarios aplican análisis avanzados.

En este caso, describimos la solución proporcionada por el equipo de BI de OWOX para uno de nuestros clientes bancarios que tenía desafíos para mejorar la calidad de la previsión de préstamos y la detección inmediata de aplicaciones irrelevantes.

Para el banco, el desafío consistía en mejorar la calidad de las solicitudes de préstamos rápidos para clientes en el sitio web. La calificación previa mejorada puede reducir la cantidad de solicitudes de préstamo fallidas y reducir la carga de los empleados de la oficina principal.

El banco utilizó un formulario abreviado con 23 campos, 19 de los cuales son obligatorios. En un esfuerzo por brindar a los clientes una respuesta lo más cercana posible a la decisión tomada en el departamento fuera de línea, la decisión fue recopilar la información faltante en línea (ampliar el formulario de solicitud a 33 campos con 25 obligatorios para completar). Se temía que un formulario complicado redujera el número de cuestionarios. Al mismo tiempo, se esperaba que un cuestionario más informativo mejoraría la calidad de las solicitudes y ahorraría tiempo a los clientes y empleados del banco.

Hipótesis: Un formulario de solicitud de préstamo ampliado reducirá la tasa de conversión de solicitudes, pero al mismo tiempo aumentará la calidad de las solicitudes.

Preguntas de investigación:

• ¿Cuánto disminuirá la conversión a aplicaciones?
• ¿Mejorará la calidad de las solicitudes de préstamo?

La prueba A/B de las solicitudes de tarjetas de crédito se realizó mediante el lanzamiento de un experimento con dos opciones de formulario: corto y largo. En el formulario corto había 23 campos, 19 de los cuales eran obligatorios. El formulario extendido tenía 33 campos, de los cuales 25 eran obligatorios.

Se necesitaron 65 días para lograr un cambio de conversión mínimo detectable del 1 %. La métrica principal rastreada fue la tasa de conversión a aplicaciones, ya que es más alta que la conversión a contratos. El seguimiento de la conversión a aplicaciones permitió completar la prueba en menos tiempo: cuanto mayor es la tasa de conversión, más rápido se reúne la audiencia necesaria. Centrarse en la conversión a la firma de un contrato habría significado varios meses de prueba. Para el banco, esto fue demasiado tiempo.

El banco estaba dispuesto a abandonar el cuestionario ampliado si disminuía el número de tarjetas de crédito emitidas. La disminución en la conversión a ventas no debía exceder el beneficio económico de reducir la carga sobre los empleados bancarios.

Dado que los cambios en el formulario fueron significativos y afectaron la lógica de su trabajo, se utilizó un mecanismo de reemplazo del lado del servidor para implementar la prueba.

La versión del cuestionario para mostrar a un posible cliente bancario fue determinada por una secuencia de comandos del servidor y se cargó sin demoras visibles para el usuario.

Google Optimize se utilizó para monitorear datos y evaluar la conversión a aplicaciones. Los datos sin procesar recopilados en BigQuery mediante OWOX BI y los datos de contratos cargados desde el sistema CRM del banco se usaron para calcular las conversiones de contratos. Las aplicaciones en el sitio web se registraron como transacciones de comercio electrónico de Google Analytics y, por lo tanto, terminaron en BigQuery utilizando OWOX BI Pipeline.

Los números de transacción se enviaban al sistema CRM del banco. Al cargar datos del CRM a Google BigQuery, el número de transacción se usó como clave para fusionar datos. Según los números de transacción, todas las etapas de una solicitud podrían atribuirse a la sesión en la que se recibió la solicitud.

La principal ventaja de este enfoque es la ausencia de compensación temporal de contratos y solicitudes: el acuerdo se atribuye al día en que se recibió la solicitud.

Según Google Optimize, se esperaba que la tasa de conversión del formulario de solicitud ampliado disminuyera en un 1 %.

Según los datos de la prueba, parecía que la prueba no tuvo éxito. Mientras que para llegar a una conclusión final, el equipo necesitaba ver cómo las aplicaciones experimentales se convertían en contratos. Este tiempo adicional requería, ya que pueden pasar hasta 60 días entre la presentación de una solicitud y la celebración del contrato.

Los datos finales mostraron una mejora notable en la calidad de las aplicaciones. La conversión de solicitud a contrato aumentó un 0,52%, mientras que la conversión final de visita a contrato aumentó un 0,02%. Los clientes que completaron un formulario extendido tenían más probabilidades de recibir una tarjeta de crédito.

• Conversión a aplicaciones: aplicaciones de sitios web/sesiones piloto
• Conversión de solicitud a contrato: contratos/solicitudes celebrados desde el sitio web
• Conversión a contrato: contratos concluidos/sesiones piloto

Vale la pena reiterar que el objetivo no era aumentar la tasa de conversión sino mantenerla mientras se presentaba un formulario de solicitud complicado. Se necesitaban pruebas para controlar la altura de la caída.

Resultó que si evalúas los resultados confiando solo en las aplicaciones, la tasa de conversión cae. Pero gracias al análisis avanzado, fue posible rastrear que la conversión a contratos no solo no disminuyó sino que creció ligeramente.

Según las pruebas A/B realizadas, el banco agregó campos al formulario de solicitud, complicándolo deliberadamente. Se pudo confirmar la hipótesis del banco de que se reduciría la conversión a aplicaciones pero aumentaría la calidad de las aplicaciones. Se confirmó mediante la recopilación de datos sin procesar con OWOX BI Pipeline y la fusión de esos datos con los datos del contrato en Google BigQuery.

• El nuevo formulario excluyó a los clientes potencialmente no interesados: la conversión a aplicaciones disminuyó un 1,1 %.
• El proceso de prepuntuación mejoró y la calidad de las solicitudes mejoró: la conversión de solicitud a contrato aumentó un 0,52 %, y la conversión final a contrato de líder aumentó un 0,02 %.
• Gracias al formulario ampliado, la información requerida para que el banco tome una decisión ya se procesa en la etapa de solicitud en línea. Se ha reducido la carga de los empleados de las sucursales y también se han reducido los costes del banco.

En general, el cambio de formulario de solicitud afectó significativamente la tasa de conversión. La prueba mostró que cuando aumenta el número de campos, principalmente no se envían solicitudes de baja calidad, lo que no afecta la conversión final a contrato. Esto significa que el banco no pierde nada. Además, un formulario largo aumenta la tasa de aprobación final. Es importante que el número de contratos no disminuya cuando el formulario se hizo más complejo.