Entender el modelo de datos de Abler
Cargando…
Cómo encajan los programas, inscripciones, grupos, sesiones y asistencia en la API de Abler, y cómo representarlos en tu propio CRM, base de datos o herramienta de informes sin perder las relaciones importantes.
Todo en Abler depende de dos cadenas de registros que terminan en una persona. Una describe la inscripción : quién se apuntó a qué. La otra describe la actividad operativa : qué se impartió realmente y quién participó.
Inscripción
User→Subscription→Service
Una Subscription te indica que alguien se ha inscrito en un programa.
Actividad operativa
Service→Group→Event→Event Participant→User
La participación en eventos te indica en qué ha participado realmente esa persona.
Por tanto, el mismo usuario puede aparecer en ambos lados. El resto de esta guía repasa cada objeto uno por uno y después muestra cómo unirlos en tu propio sistema.
1
El primer punto de terminología que debes tener en cuenta: lo que la interfaz de Abler llama Program se representa en la API como Service. Fútbol U10, primavera 2026 es un programa desde el punto de vista del usuario, pero el objeto subyacente de la API es el Service.
En tu propio sistema, represéntalo como sea que llames a un programa o curso, y guarda el ID del Service de Abler como identificador externo. Así tendrás una clave estable con la que hacer coincidir las Subscriptions, Groups, Events y otros registros que lleguen después.
Nunca vincules registros por nombre
Los nombres cambian, y distintos programas pueden tener nombres idénticos. Usa los IDs de Abler para establecer todas las relaciones.
2
Un programa puede tener uno o varios productos asociados. La diferencia es, básicamente:
Service
En qué participa alguien: Fútbol U10, primavera 2026.
Product
Qué puede comprar o en qué puede inscribirse: las opciones de inscripción o de pago asociadas a ese programa, como Full Season o Monthly.
Que los productos necesiten sus propios registros en tu sistema depende de lo que necesites hacer. Si principalmente haces seguimiento de personas y participación, lo más importante es la relación entre programa y Subscription. Si también necesitas información comercial detallada, mantén también Product como un objeto independiente.
3
Una Subscription representa la inscripción o membresía de una persona en un programa. Contiene un serviceId, un productId y el userIdde Abler del usuario, junto con su propio ID único, estado, fecha de inicio, fecha de fin y fecha de creación.
User→Subscription→Service
Subscription { userId: 123, serviceId: 456, productId: 789 }
→ El usuario 123 está inscrito en el programa 456 a través del producto 789.
En tu sistema, la Subscription se convierte en un registro de unión entre la persona y el programa: llámalo matrícula, inscripción o participación. Una persona puede tener muchas Subscriptions a lo largo del tiempo, y un programa tiene naturalmente muchos inscritos, así que la Subscription es lo que te indica quién está inscrito en qué.
4
Una Subscription te indica que una persona está inscrita en un programa. No te indica si asistió a cada una de sus sesiones.
Jane está inscrita en Fútbol U10, primavera 2026 , un programa de tres meses con 24 entrenamientos. Tu sistema debería tener una Subscription para la inscripción de Jane (en ocasiones más de una), luego 24 Events para cada sesión y, potencialmente, 24 registros de asistencia que indiquen si asistió a cada una.
Subscription
La inscripción general.
Participación en eventos
Actividad en una fecha y hora concretas.
Mantener ambas cosas separadas es lo que te permite elaborar informes sobre inscripciones, participantes activos, frecuencia de participación, asistencia, retención, sesiones impartidas y compromiso por programa.
5
Cuando se configura un programa, los participantes se organizan en Groups. En algunas partes de la API también pueden aparecer como ageGroupId o un identificador de grupo equivalente. La actividad operativa normalmente se organiza en torno a los grupos: el programa Fútbol U10, primavera 2026 podría contener el grupo Entrenamiento U10 de los martes, y el grupo contiene los eventos que realmente se imparten.
Service→Group→Event
Dos cosas a tener en cuenta
No trates campos como productOption.groupIds como el vínculo definitivo entre un producto y su grupo operativo: pueden ser nulos y la relación puede cambiar en cualquier momento. Además, los programas pueden compartir grupos, y a menudo lo hacen; depende de cómo esté configurado el club.
6
Un Event es una actividad programada real: una ocurrencia dentro de la impartición de un programa.
Programa Fútbol U10, primavera 2026
Grupo Entrenamiento U10 de los martes
Eventos Mar 8 sep 17:00 · Mar 15 sep 17:00 · Mar 22 sep 17:00 · …
Por eso, un programa nunca debe asignarse como un Event en tu sistema. El programa es aquello en lo que alguien se inscribe; el Event es una sesión dentro de él. Guarda cada Event con su ID de Event original de Abler y, cuando esté disponible, conserva su identificador de grupo y el contexto del programa en lugar de depender solo del nombre del evento.
7
La última capa es el participante individual de un Event. Responde a quién participó en esta sesión concreta y, cuando se incluye información de asistencia, si asistió. Es una pregunta distinta de quién está inscrito en el programa, que se obtiene de las Subscriptions.
Event→Event Participant→User
Contacto Jane Smith
→ Subscription → Fútbol U10, primavera 2026
→ Participación en evento → Entrenamiento, 8 de septiembre
→ Participación en evento → Entrenamiento, 15 de septiembre
→ Participación en evento → Entrenamiento, 22 de septiembre
Asistir sin Subscription es normal
Es posible asistir a un Event sin tener una Subscription: las sesiones abiertas (drop-in) son habituales en algunos programas. Tu modelo debe contemplarlo.
8
A veces puede aparecer información de Subscription junto a la participación en eventos, pero la integración no debe depender de que un Event Participant lleve un ID de Subscription fiable. La estructura más segura vincula cada hecho de forma independiente:
Asistencia
Event Participant→User
Event Participant→Event
Después, obtén el contexto del programa a partir de Event → Group → Service.
Inscripción
Subscription→User
Subscription→Service
Totalmente separado de la asistencia.
Así la inscripción y la asistencia se mantienen como hechos separados, lo que da un modelo mucho más limpio, y se cubren los casos en que un participante está en un Event sin una Subscription simple de uno a uno detrás.
9
En conjunto, la estructura queda así. El lado de inscripción está a la izquierda, el lado de impartición a la derecha, y ambos se encuentran en el User y en el Service.
Vista de inscripción
¿Quién se inscribió en qué programas? — Service + Subscription + User
Vista de participación
¿En qué eventos participó realmente esa persona? — Group + Event + Event Participant + User
10
Un punto de partida razonable para la mayoría de CRMs y bases de datos. Los nombres de tus objetos pueden seguir tu arquitectura actual; lo importante es conservar las relaciones.
Abler | En tu sistema | Finalidad |
|---|---|---|
UserProfile / User | Contacto / Persona | La persona |
Service | Programa | El programa o actividad general |
Product | Producto / Opción de programa | Oferta comercial opcional |
Subscription | Matrícula / Inscripción | Conecta a una persona con un programa |
Group / Age group | Grupo del programa / Cohorte | Agrupación operativa |
Event | Sesión / Evento | Actividad individual impartida |
EventPlayer / Participant | Asistencia / Participación en eventos | Conecta a una persona con un Event |
11
Para cada objeto importado desde Abler, guarda el ID original de Abler como identificador externo, por ejemplo abler_user_id, abler_service_id, abler_subscription_id, abler_group_id, abler_event_id y abler_event_participant_id.
Esto permite que la integración haga upsert en lugar de crear registros nuevos en cada extracción, y simplifica la resolución de relaciones: cuando llega la Subscription 98765 con serviceId = 456, busca el programa donde abler_service_id = 456 y vincúlalo.
12
Importa los registros padre antes que los hijos para que cada relación pueda resolverse al llegar.
Crea o actualiza registros de programas, conservando el ID del Service de Abler.
Crea las opciones comerciales o de inscripción que quieras representar.
Para cada una, usa userId para encontrar a la persona y serviceId para encontrar el programa. Así se crea la matrícula.
Extrae la estructura de grupos operativos, conservando el ID de Group / age group de Abler.
Crea las sesiones individuales y asócialas con su grupo y su contexto de programa.
Para cada participante, vincula a la persona con el Event. Así obtienes el conjunto de datos de participación y asistencia.
13
User id 1001 · Jane Smith
Service id 2001 · Fútbol U10, primavera 2026
Product id 2101 · Full Season
Subscription id 3001 · userId 1001 · serviceId 2001 · productId 2101
Group id 4001 · U10 martes
Event id 5001 · group 4001 · Entrenamiento U10 · 15 de septiembre
Event Participant user 1001 · event 5001 · Attended
Jane Smith
→ Matrícula → Fútbol U10, primavera 2026 (desde la Subscription)
→ Asistencia → Entrenamiento U10, 15 de septiembre (desde el Event Participant)
Ambos se refieren a la misma persona, pero describen cosas distintas.
14
En una primera fase, asegúrate de que estas relaciones son correctas antes de importar todos los campos que ofrece la API. Los identificadores críticos son el User ID (la persona), Service ID (el programa), Subscription ID (la inscripción de esa persona), Group / ageGroup ID (el grupo operativo), Event ID (una sesión individual) y Event Participant ID / User ID (la participación en esa sesión).
Una vez que los tengas, puedes añadir con relativa facilidad los atributos del programa, fechas, estado, datos demográficos, estado de asistencia e información de pagos.
Lo único que debes evitar
No aplanes todo en un único objeto. Los programas, las inscripciones y los eventos tienen ciclos de vida distintos y relaciones de muchos a muchos diferentes. Piensa que Abler te ofrece dos conjuntos de datos relacionados, quién se ha inscrito en qué y en qué ha participado realmente , que juntos dan una imagen mucho más completa del compromiso que cualquiera de ellos por separado.