Aufbau einer Studierenden-Datenplattform: First-Party-Daten von der Anfrage bis zum Abschluss

Eine Universität, die 20.000 Studierende verwaltet, hat die Daten dieser Studierendenpopulation typischerweise auf 8–15 verschiedene Systeme verteilt: ein Zulassungs-CRM, ein Studierenden-Informationssystem, ein LMS, eine Finanzmanagementsoftware, ein Wohlfahrts-Fallmanagementsystem, ein Bibliothekssystem, eine Karriereplattform, ein Wohnheimmanagementsystem und mehrere abteilungseigene Tabellen.

Jedes System weiß eine Sache über den Studierenden. Keines von ihnen weiß alles. Das Zulassungs-CRM weiß, wie der Studierende rekrutiert wurde. Das Studierenden-Informationssystem kennt seine Noten. Das LMS kennt sein Engagement beim Online-Lernen. Das Wohlfahrtssystem weiß, dass er im Oktober drei Beratungsgespräche hatte. Das Bibliothekssystem weiß, dass er seit November nicht mehr zugegriffen hat. Keines dieser Systeme kommuniziert miteinander.

Das Ergebnis: Der Studierende mit dem höchsten Abbruchrisiko an der Institution ist für das Bindungssystem unsichtbar, weil kein einzelnes System das vollständige Bild hat. Der Studierende, der am ehesten auf einen Stipendienaufruf reagieren würde, ist für das Entwicklungsteam unsichtbar, weil das Finanzhilfesystem und das Alumni-Kommunikationssystem nicht verbunden sind.

Eine Studierenden-Datenplattform löst das, indem sie ein einheitliches Profil erstellt, das alle Datenquellen in einem einzigen Kontaktdatensatz aggregiert – in Echtzeit zugänglich, automatisch aktualisiert und durch verbundene Kommunikationskanäle umsetzbar.

Die zu vereinigenden Datenquellen

Vor-Einschreibungs-Daten:

• Anfragequelle (welcher Kanal, welche Kampagne, welche Veranstaltung)
• Anfragedatum und Antwortzeitplan
• Teilnahme am Tag der offenen Tür
• Bewerbungsabschlusszeitplan
• Stipendienanträge
• Annahmeentscheidung und Antwort

Einschreibungsdaten:

• Programm, Eintrittsjahr, Einschreibungskohorte
• Unterkunftsart und -standort
• Status und Höhe der Finanzhilfe
• Internationale/inländische Einstufung
• Eingangsqualifikationen

Akademische Engagement-Daten:

• Modul-Einschreibung und -abschluss
• Bewertungsnoten und -verlauf
• Anwesenheitsnachweise (Vorlesungen, Seminare, Tutorien)
• LMS-Login-Häufigkeit und -aktivität
• Bibliothekszugang und Ressourcennutzung

Campus-Leben-Daten:

• Sport- und außercurriculare Aktivitäten
• Studierendenunion-Mitgliedschaft
• Nutzung von Campuseinrichtungen (Fitnessstudio, Mensa, Gemeinschaftsräume)
• Peer-Netzwerk-Indikatoren (wenn verfügbar)

Finanzdaten:

• Gebührenzahlungsstatus
• Notfallfondsanträge
• Auszahlung von Stipendien und Bursarien
• Status der Teilzeitbeschäftigung (wenn angegeben)

Kommunikationsdaten:

• WhatsApp-Nachrichtenverlauf und Antwortquoten
• E-Mail-Öffnungs- und Klickraten
• SMS-Empfang und -Antwortverlauf
• Interaktionsprotokoll des Support-Teams

Die technische Architektur

Eine Studierenden-Datenplattform erfordert keinen Austausch bestehender Systeme. Sie sitzt als Integrationsschicht darüber:

Datenverbinder: APIs, die jedes bestehende System mit der zentralen Plattform verbinden. Das Zulassungs-CRM, SIS, LMS und die Finanzplattform übermitteln alle Updates per Webhook oder geplanter Synchronisierung an die Studierenden-Datenplattform.

Identitätsauflösung: Wenn derselbe Studierende über mehrere Systeme erscheint (oft mit leicht unterschiedlichen Namensschreibweisen, verschiedenen E-Mail-Adressen oder verschiedenen Studierenden-IDs), löst die Plattform diese mithilfe von Name + Geburtsdatum + Studierenden-Nummer-Abgleich in ein einziges kanonisches Profil auf.

Echtzeit-Event-Streaming: Hochprioritätssignale (ein Studierender besteht eine Prüfung nicht, eine Gebührenzahlung bounced, ein Studierender meldet ein Wohlfahrtsanliegen) werden in Echtzeit an das einheitliche Profil übermittelt und können sofortige Kommunikations-Workflows auslösen.

Kommunikationsschicht: Das einheitliche Profil verbindet sich mit der WhatsApp Business API, der E-Mail-Plattform und dem SMS-Gateway – ermöglicht allen Kommunikationskanälen den Zugriff auf dasselbe vollständige Studierendenprofil.

GDPR und Datenverwaltung

Eine Studierenden-Datenplattform aggregiert sensible persönliche Daten – akademische Leistung, Finanzstatus, Gesundheits- und Wohlfahrtsinformationen. Das erfordert einen klaren Datenverwaltungsrahmen:

• Eine Rechtsgrundlage für jede Datenverarbeitungsaktivität (typischerweise vertragliche Notwendigkeit für akademische Aufzeichnungen, berechtigtes Interesse für Engagement-Analysen, ausdrückliche Einwilligung für Marketingkommunikation)
• Eine Datenaufbewahrungsrichtlinie, die angibt, wie lange jede Datenkategorie nach dem Verlassen eines Studierenden aufbewahrt wird
• Zugriffskontrollen, die einschränken, welche Mitarbeiter welche Datenkategorien sehen können (akademisches Personal sollte keine Daten über finanzielle Notlagen sehen; Zulassungsmitarbeiter sollten keine Beratungsprotokolle sehen)
• Ein studierendengerichteter Datenschutzhinweis, der klar erklärt, welche Daten gehalten werden und warum

Der GDPR-Compliance-Aufwand einer Studierenden-Datenplattform ist überschaubar – die meisten Universitäten sind bereits Datenverantwortliche für diese Informationen. Die Plattform ändert, wie die Daten gespeichert und zugegriffen werden, nicht ob die Institution sie hält.

Für die QR-basierte Erfassung, die die Anfrage-Phasen-Daten speist, siehe Warum Schulen von Google Forms zur QR-basierten Datenerfassung wechseln. Für die Alumni-Datenstrategie, die die Plattform über den Abschluss hinaus erweitert, siehe Alumni-Engagement-Programme, die tatsächlich Spenden und Empfehlungen generieren.