Das Abler-Datenmodell verstehen
Wird geladen…
Wie Programme, Anmeldungen, Gruppen, Termine und Anwesenheiten in der Abler-API zusammenhängen – und wie Sie sie in Ihrem eigenen CRM, Ihrer Datenbank oder Ihrem Reporting-Tool abbilden, ohne die wichtigen Beziehungen zu verlieren.
In Abler hängt alles an zwei Ketten von Datensätzen, die beide bei einer Person enden. Die eine beschreibt die Anmeldung – wer sich wofür angemeldet hat. Die andere beschreibt die operative Aktivität – was tatsächlich stattgefunden hat und wer daran teilgenommen hat.
Anmeldung
User→Subscription→Service
Ein Subscription-Datensatz zeigt an, dass sich jemand für ein Programm angemeldet hat.
Operative Aktivität
Service→Group→Event→Event Participant→User
Die Teilnahme an einem Event zeigt, woran diese Person tatsächlich teilgenommen hat.
Derselbe Benutzer kann daher auf beiden Seiten auftauchen. Der Rest dieses Leitfadens geht nacheinander auf jedes Objekt ein und zeigt anschließend, wie Sie diese in Ihrem eigenen System zusammenführen.
1
Der erste Begriff, den Sie kennen sollten: Was die Abler-Oberfläche als Programm bezeichnet, wird in der API als Service dargestellt. U10 Fußball, Frühjahr 2026 ist aus Sicht eines Nutzers ein Programm, aber das zugrunde liegende API-Objekt ist der Service.
Bilden Sie es in Ihrem eigenen System als das ab, was Sie als Programm oder Kurs bezeichnen, und speichern Sie die Abler-Service-ID als externe Kennung. Das gibt Ihnen einen stabilen Schlüssel, gegen den Sie abgleichen können, wenn später Subscriptions, Groups, Events und andere Datensätze eintreffen.
Verknüpfen Sie Datensätze nie anhand des Namens
Namen ändern sich, und unterschiedliche Programme können identische Namen haben. Verwenden Sie die Abler-IDs, um jede Beziehung herzustellen.
2
Einem Programm können ein oder mehrere Produkte zugeordnet sein. Der Unterschied besteht im Wesentlichen darin:
Service
Woran jemand teilnimmt – U10 Fußball, Frühjahr 2026.
Produkt
Was man erwerben oder wofür man sich anmelden kann – die mit diesem Programm verknüpften Anmelde- oder Zahlungsoptionen, wie Ganze Saison oder Monatlich.
Ob Produkte eigene Datensätze in Ihrem System benötigen, hängt davon ab, was Sie damit erreichen möchten. Wenn Sie hauptsächlich Personen und Teilnahme erfassen, ist die Beziehung zwischen Programm und Subscription am wichtigsten. Wenn Sie zusätzlich detaillierte kommerzielle Informationen benötigen, führen Sie das Produkt als separates Objekt.
3
Eine Subscription stellt die Anmeldung bzw. Mitgliedschaft einer Person in einem Programm dar. Sie enthält eine serviceId, eine productId und die Abler-userId der Person sowie eine eigene eindeutige ID, einen Status, ein Startdatum, ein Enddatum und ein Erstellungsdatum.
User→Subscription→Service
Subscription { userId: 123, serviceId: 456, productId: 789 }
→ Benutzer 123 ist über Produkt 789 für Programm 456 angemeldet.
In Ihrem System wird die Subscription zu einem Verbindungsdatensatz zwischen der Person und dem Programm – nennen Sie es eine Einschreibung, eine Anmeldung oder eine Teilnahme. Eine Person kann im Laufe der Zeit mehrere Subscriptions haben, und ein Programm hat naturgemäß viele Teilnehmer. Die Subscription zeigt also, wer für was angemeldet ist.
4
Eine Subscription zeigt an, dass eine Person für ein Programm angemeldet ist. Sie sagt nichts darüber aus, ob diese Person an den einzelnen Terminen innerhalb des Programms teilgenommen hat.
Jane ist für U10 Fußball, Frühjahr 2026 angemeldet – ein dreimonatiges Programm mit 24 Trainingseinheiten. Ihr System sollte eine Subscription für Janes Anmeldung enthalten (gelegentlich auch mehr als eine), dazu 24 Events für die einzelnen Einheiten und möglicherweise 24 Anwesenheitsdatensätze, die zeigen, ob sie jeweils teilgenommen hat.
Subscription
Die gesamte Anmeldung.
Teilnahme am Event
Aktivität an einem bestimmten Datum und zu einer bestimmten Uhrzeit.
Die Trennung dieser beiden Dinge ermöglicht es Ihnen, nach Programm über Anmeldungen, aktive Teilnehmer, Teilnahmehäufigkeit, Anwesenheit, Bindung, durchgeführte Einheiten und Engagement zu berichten.
5
Wenn ein Programm eingerichtet wird, werden die Teilnehmer in Groups organisiert. In Teilen der API können diese auch als ageGroupId oder eine entsprechende Gruppenkennung erscheinen. Die operative Aktivität ist in der Regel um Groups herum organisiert: Das Programm U10 Fußball, Frühjahr 2026 könnte die Group U10 Dienstagstraining enthalten, und die Group hält die Events, die tatsächlich stattfinden.
Service→Group→Event
Zwei Dinge, auf die Sie achten sollten
Behandeln Sie Felder wie productOption.groupIds nicht als die verbindliche Verknüpfung zwischen einem Produkt und seiner operativen Group – sie können null sein, und die Beziehung kann sich jederzeit ändern. Und Programme können sich Groups teilen, und tun dies oft; das hängt davon ab, wie der Verein aufgestellt ist.
6
Ein Event ist eine tatsächlich geplante Aktivität – ein einzelner Termin in der Durchführung eines Programms.
Programm U10 Fußball, Frühjahr 2026
Group U10 Dienstagstraining
Events Di, 8. Sep. 17:00 · Di, 15. Sep. 17:00 · Di, 22. Sep. 17:00 · …
Ein Programm sollte in Ihrem System also niemals als Event abgebildet werden. Das Programm ist das, wofür sich jemand anmeldet; das Event ist eine einzelne Einheit darin. Speichern Sie jedes Event mit seiner ursprünglichen Abler-Event-ID und, wo verfügbar, bewahren Sie seine Group-Kennung und den Programmkontext auf, statt sich allein auf den Event-Namen zu verlassen.
7
Die letzte Ebene ist der einzelne Teilnehmer an einem Event. Sie beantwortet die Frage, wer an dieser bestimmten Einheit teilgenommen hat und, sofern Anwesenheitsinformationen enthalten sind, ob diese Person anwesend war. Das ist eine andere Frage als die, wer für das Programm angemeldet ist – diese kommt von den Subscriptions.
Event→Event Participant→User
Kontakt Jane Smith
→ Subscription → U10 Fußball, Frühjahr 2026
→ Event-Teilnahme → Training, 8. September
→ Event-Teilnahme → Training, 15. September
→ Event-Teilnahme → Training, 22. September
Anwesenheit ohne Subscription ist normal
Es ist möglich, an einem Event teilzunehmen, ohne eine Subscription zu besitzen – Schnuppereinheiten sind in manchen Programmen üblich. Ihr Modell muss das zulassen.
8
Informationen zur Subscription können manchmal im Zusammenhang mit der Teilnahme an Events auftauchen, aber die Integration sollte nicht davon abhängen, dass ein Event-Teilnehmer eine zuverlässige Subscription-ID trägt. Die sichere Struktur verknüpft jede Tatsache unabhängig voneinander:
Anwesenheit
Event Participant→User
Event Participant→Event
Leiten Sie dann den Programmkontext aus Event → Group → Service ab.
Anmeldung
Subscription→User
Subscription→Service
Vollständig getrennt von der Anwesenheit.
Dadurch bleiben Anmeldung und Anwesenheit getrennte Tatsachen, was ein wesentlich saubereres Modell ergibt, und es deckt die Fälle ab, in denen ein Teilnehmer an einem Event beteiligt ist, ohne dass eine einfache Eins-zu-eins-Subscription dahintersteckt.
9
Zusammengefügt sieht die Struktur so aus. Die Anmeldeseite steht links, die Durchführungsseite rechts, und beide treffen sich beim User und beim Service.
Anmeldeansicht
Wer hat sich für welche Programme angemeldet? — Service + Subscription + User
Teilnahmeansicht
An welchen Events hat diese Person tatsächlich teilgenommen? — Group + Event + Event Participant + User
10
Ein vernünftiger Ausgangspunkt für die meisten CRMs und Datenbanken. Ihre eigenen Objektnamen können sich an Ihrer bestehenden Architektur orientieren – wichtig ist, dass die Beziehungen erhalten bleiben.
Abler | In Ihrem System | Zweck |
|---|---|---|
UserProfile / User | Kontakt / Person | Die einzelne Person |
Service | Programm | Das gesamte Programm oder die Aktivität |
Product | Produkt / Programmoption | Optionales kommerzielles Angebot |
Subscription | Einschreibung / Anmeldung | Verbindet eine Person mit einem Programm |
Group / Age group | Programmgruppe / Kohorte | Operative Gruppierung |
Event | Einheit / Termin | Einzelne durchgeführte Aktivität |
EventPlayer / Participant | Anwesenheit / Event-Teilnahme | Verbindet eine Person mit einem Event |
11
Speichern Sie für jedes aus Abler importierte Objekt die ursprüngliche Abler-ID als externe Kennung – zum Beispiel abler_user_id, abler_service_id, abler_subscription_id, abler_group_id, abler_event_id und abler_event_participant_id.
Das ermöglicht es der Integration, Datensätze per Upsert zu aktualisieren, statt bei jedem Abruf neue Datensätze anzulegen, und macht die Auflösung von Beziehungen einfach: Wenn Subscription 98765 mit serviceId = 456 eintrifft, suchen Sie das Programm, bei dem abler_service_id = 456 ist, und verknüpfen Sie es.
12
Importieren Sie übergeordnete vor untergeordneten Datensätzen, damit jede Beziehung bei Eintreffen aufgelöst werden kann.
Programmdatensätze anlegen oder aktualisieren, die Abler-Service-ID beibehalten.
Die kommerziellen oder Anmeldeoptionen anlegen, die Sie abbilden möchten.
Für jede Subscription anhand von userId die Person und anhand von serviceId das Programm finden. Dadurch entsteht die Einschreibung.
Die operative Group-Struktur abrufen, die Abler-Group- bzw. Altersgruppen-ID beibehalten.
Die einzelnen Einheiten anlegen und sie ihrer Group und ihrem Programmkontext zuordnen.
Für jeden Teilnehmer die Person mit dem Event verknüpfen. So erhalten Sie den Teilnahme- und Anwesenheitsdatensatz.
13
User id 1001 · Jane Smith
Service id 2001 · U10 Fußball, Frühjahr 2026
Product id 2101 · Ganze Saison
Subscription id 3001 · userId 1001 · serviceId 2001 · productId 2101
Group id 4001 · U10 Dienstag
Event id 5001 · group 4001 · U10 Training · 15. September
Event Participant user 1001 · event 5001 · Teilgenommen
Jane Smith
→ Einschreibung → U10 Fußball, Frühjahr 2026 (aus der Subscription)
→ Anwesenheit → U10 Training, 15. September (aus dem Event-Teilnehmer)
Beide beziehen sich auf dieselbe Person, beschreiben aber unterschiedliche Dinge.
14
Sorgen Sie in einer ersten Phase dafür, dass diese Beziehungen stimmen, bevor Sie jedes von der API angebotene Feld importieren. Die entscheidenden Kennungen sind die User-ID (die Person), die Service-ID (das Programm), die Subscription-ID (die Anmeldung dieser Person), die Group-/ageGroup-ID (die operative Group), die Event-ID (eine einzelne Einheit) und die Event-Participant-ID / User-ID (Teilnahme an dieser Einheit).
Sobald diese vorhanden sind, lassen sich Programmattribute, Daten, Status, demografische Angaben, Anwesenheitsstatus und Zahlungsinformationen relativ leicht ergänzen.
Die eine Sache, die Sie vermeiden sollten
Fassen Sie nicht alles in einem einzigen Objekt zusammen. Programme, Anmeldungen und Events haben unterschiedliche Lebenszyklen und unterschiedliche Viele-zu-Viele-Beziehungen. Betrachten Sie Abler als zwei zusammenhängende Datensätze – wer sich wofür angemeldet hat und woran diese Person tatsächlich teilgenommen hat –, die zusammen ein weitaus vollständigeres Bild des Engagements ergeben als jeder einzelne für sich.