Ticketing y portales

Validación de socios y calidad de datos

Flujos de validación integrados con LALIGA y Data Lake.

Normalización de datos legacy y validación en puntos de entrada para evitar inconsistencias entre sistemas.

Rol

Software Engineer / Responsable de integraciones

Tipo

Ticketing y portales

Contexto

Este trabajo se ejecutó sobre portales de socios donde los usuarios tenían que validarse con sus credenciales, y después actualizar datos de perfil antes de acceder a servicios o flujos de compra.

Problema

Problema y restricciones

Los datos que llegaban desde sistemas legacy eran inconsistentes: códigos postales y municipios no coincidían, los países aparecían en formatos distintos y los formularios acumulaban años de valores sin normalizar.

Además, los usuarios se bloqueaban en login y actualización porque los campos de identidad y perfil muchas veces estaban mal desde origen, así que el portal tenía que distinguir entre credenciales inválidas, input mal formado y problemas de datos recuperables.

El flujo tenía que validar contra la API de la plataforma de gestión de socios de LALIGA y empujar los datos corregidos al Data Lake del CRM, así que no se podía aceptar entrada defectuosa para limpiarla después.

Enfoque

Enfoque y decisiones técnicas

Diseñé flujos de login, registro y actualización obligatoria de perfil con validación tanto en frontend como en backend, incluyendo comprobaciones de credenciales antes de dejar avanzar al usuario dentro del portal.

Para la normalización usé reglas explícitas y mapeos en JSON para comprobar pares de código postal y municipio, y añadí validación server-side, control de duplicados, índices y restricciones en base de datos antes de guardar y enviar la información aguas abajo.

Arquitectura

1Usuario
2Portal WordPress
3Credenciales
4Plataforma de gestión de socios de LALIGA
5Validación local (frontend + backend + restricciones de BBDD)
6Data Lake del CRM

Usuario → portal WordPress → credenciales → plataforma de gestión de socios de LALIGA
                          ↓
              Validación local (frontend + backend + restricciones de BBDD)
                          ↓
                     Data Lake del CRM

Decisiones

Decisiones clave

Soportar formatos legacy rotos sin convertir el flujo del usuario en un callejón sin salida.

Hacer obligatoria la corrección de datos en la entrada del portal sin volver inutilizable el camino del usuario.

Alinear reglas de validación, restricciones de BBDD y requisitos aguas abajo del Data Lake en un mismo flujo.

Resultado

Los portales dejaron de aceptar datos de perfil inconsistentes tal cual y pasaron a exigir actualizaciones normalizadas antes de continuar.

Eso redujo usuarios bloqueados por input mal formado en identidad y perfil, y bajó la cantidad de registros desajustados que llegaban al Data Lake y a flujos operativos aguas abajo.

El trade-off es que el portal ahora bloquea a usuarios con registros legacy mal formados hasta que actualizan — dejamos el camino recuperable, pero añadió fricción para cuentas que llevaban años sin tocarse.