Ein Konto. Alle Fans. Jede App.

Die meisten Ligen und Vereine kennen ihre Fans nur in Bruchstücken – verteilt auf so viele Systeme, wie sie digitale Angebote haben.

• Ein Konto pro Angebot. Ticketshop, Fanshop, App, Streaming und Gewinnspiel haben jeweils eine eigene Registrierung. Fans geben dieselben Daten fünfmal ein und vergessen fünf Passwörter.
• Kein Gesamtbild. Wer ein Dauerkarteninhaber ist, regelmäßig im Fanshop kauft und den Newsletter liest, steht in drei Datenbanken – ohne Verbindung.
• Einwilligungen ohne Nachweis. Opt-ins liegen als Häkchen in verschiedenen Systemen. Welchem Text ein Fan zugestimmt hat und wann, lässt sich oft nicht mehr belegen.
• Newsletter nach dem Gießkannenprinzip. Ohne verbundene Daten bekommen alle dieselbe Mail – statt der Fans, für die ein Angebot wirklich passt.
• Datenschutz als Handarbeit. Auskunft, Widerruf und Löschung müssen in jedem System einzeln erledigt werden.
• Jede neue App fängt bei null an. Login, Passwort-Reset, Zwei-Faktor-Schutz und Registrierung werden immer wieder neu gebaut und gepflegt.

Ein Login für alle Anwendungen Ihrer Liga oder Ihres Vereins – sicher, in Ihrem Design und in der Sprache Ihrer Fans.

• Single Sign-on. Einmal anmelden, dann in jede weitere Anwendung ohne erneutes Passwort. Ohne „Angemeldet bleiben“ gilt die Anmeldung bis zum Schließen des Browsers, höchstens 12 Stunden; mit Haken 30 Tage ab der letzten Nutzung.
• Offener Standard. PuckID spricht OpenID Connect (Authorization Code Flow mit PKCE). Server-Anwendungen können sich zusätzlich mit einem Client-Secret ausweisen.
• Zwei-Faktor-Schutz. Authenticator-App mit QR-Code und Wiederherstellungscodes oder Code per E-Mail. Fans richten ihn freiwillig ein; Sie können ihn je Anwendung verlangen. Das Admin-Portal verlangt ihn immer.
• Registrierung nach Ihren Regeln. Offen für alle, nur für bestimmte E-Mail-Domains oder nur auf Einladung. Neue Mitglieder erhalten automatisch die Standardrollen des Projekts.
• Einladungen mit Rolle. Mitarbeitende, Partner oder Lizenznehmer laden Sie per E-Mail ein – die Rolle steht schon fest.
• Rollen je Projekt. Ihre Anwendungen bekommen die Rollen des Fans direkt im Token und entscheiden selbst, was er darf.
• Passwortregeln. Mindestlänge sowie Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen sind einstellbar. „Passwort vergessen“ schickt einen Link, der 15 Minuten gilt.
• Ihr Design. Die Login-Seiten tragen Ihr Logo, Ihre Farben und Schriften, auf Wunsch mit großem Bild. Jedes Projekt und jede Anwendung kann ein eigenes Design bekommen.
• Mehrsprachig. Deutsch und Englisch, weitere Sprachen sind vorbereitet. PuckID wählt die Sprache des Browsers, Fans können umschalten, die Wahl bleibt am Konto. Anwendungen können die Sprache beim Login vorgeben.
• Nutzungsbedingungen mit Versionen. Geben Sie eine neue Fassung frei, stimmen Fans beim nächsten Login zu – jede Zustimmung wird gespeichert.
• Volle Kontrolle für Anwendungen. Stille Anmeldung im Hintergrund, erzwungene Neuanmeldung für heikle Aktionen und Abmelden, das die PuckID-Anmeldung beendet – danach startet keine Anwendung mehr ohne Passwort.

Sie bestimmen, welche Angaben Sie brauchen – PuckID fragt sie im richtigen Moment ab und hält fest, welchem Text ein Fan wann zugestimmt hat.

• Eigene Formular-Felder. Textfeld, E-Mail, Telefon, Zahl, Datum, Auswahlliste mit Gruppen, Optionsfelder, Checkbox, mehrzeiliger Text und Hinweistexte ohne Eingabe. Mit Pflichtfeldern, Platzhaltern, Längen- und Datumsgrenzen.
• System-Felder für alle. Vorname, Nachname, Geburtsdatum, Geschlecht und Anschrift mit Land – 250 Länder, angezeigt in der Sprache des Fans.
• Formulare je Projekt. Felder in Gruppen anordnen, als eine Seite, in Schritten oder in Reitern, mit Breiten von 25 bis 100 Prozent. Jedes Projekt kann ein Feld zur Pflicht machen.
• Fehlende Angaben beim Login. Verlangt ein Projekt eine Angabe, die noch fehlt, fragt PuckID sie beim nächsten Login ab – einmal, nicht jedes Mal.
• Einwilligungen hängen am Konto. Ein Opt-in gibt der Fan einmal, es gilt für alle Projekte Ihrer Liga oder Ihres Vereins. Wo es je Projekt einen eigenen Wert braucht – etwa eine Trikotnummer je Team –, steht der zuletzt angegebene Wert schon im Formular.
• Nachweis jeder Antwort. Jede Änderung an Frage, Beschreibung, Optionen oder Pflicht ergibt eine neue Version. Jede Antwort merkt sich die Version, unter der sie gegeben wurde. So belegen Sie, welchem Wortlaut ein Fan zugestimmt hat.
• Datenfreigabe je Anwendung. Sie legen fest, was eine Anwendung erfährt: E-Mail, Name, einzelne Felder, Ereignisse, Zielgruppen. Die Freigabe gilt im Token, über die API und in Webhooks.

Aus Logins, Angaben und dem, was Ihre Anwendungen melden, werden Zielgruppen – und die erreichen Sie direkt in Ihrem Newsletter-Tool.

Ereignisse aus Ihren Anwendungen

• Ticketshop, Fanshop, App oder Gewinnspiel melden, was ein Fan tut: Ticket gekauft, Artikel angesehen, Spiel geschaut. Eine eigene Daten-API nimmt die Ereignisse entgegen.
• Je Ereignistyp legen Sie fest, welche Felder es hat (Text, Zahl, Ja/Nein, Datum, auch Listen wie die Positionen eines Warenkorbs) und wie lange es aufbewahrt wird.
• Ereignisse gehören immer zu Ihrem Tenant. Sie werden nie mit einer anderen Liga oder einem anderen Verein geteilt – auch nicht für dieselbe Person.

Zielgruppen

• Bedingungen auf Ereignisse: Anzahl oder Summe („mindestens 4 Tickets“), jemals, in den letzten N Tagen, seit oder zwischen zwei Daten, mit bis zu fünf Filtern auf Felder.
• Bedingungen auf das Profil: Zugang zu einem Projekt, Rolle, erster Zugang im Zeitraum, Wert eines Profilfelds (z. B. Opt-in „Ja“), Newsletter bestellt.
• Kombinieren mit „alle“ oder „mindestens eine“, jede Bedingung umkehrbar. Eine Vorschau zählt die Treffer vor dem Speichern und zeigt Beispiele.
• PuckID berechnet Zielgruppen nach dem Speichern und alle 15 Minuten neu. Sie sehen die Mitglieder, seit wann sie dabei sind und wie sich die Größe entwickelt.
• Ihre Anwendungen fragen über die API ab, zu welchen Zielgruppen ein Fan gehört – etwa für personalisierte Angebote.

Auswertung

• Diagramme zu Ereignissen, Feldwerten und dem Verlauf jeder Zielgruppe, mit Zeiträumen und Tabellenansicht.

Newsletter

• Newsletter bestellen Fans direkt in „Mein Konto“. Die Bestätigung (Double-Opt-in) verschickt PuckID selbst; gespeichert werden Wortlaut, Zeitpunkte und IP-Adressen.
• PuckID gleicht alle 5 Minuten mit Ihrem Newsletter-Tool ab – in beide Richtungen. Wer sich über den Link in einer Mail abmeldet, ist auch in PuckID abgemeldet. Angebunden ist listmonk; weitere Tools lassen sich über eine Adapter-Schnittstelle ergänzen.
• Zielgruppen ins Newsletter-Tool: PuckID legt für eine Zielgruppe eine eigene Liste an und hält sie aktuell. Über einen Newsletter landen dort nur Fans, die ihn bestätigt bestellt haben – und erst, wenn Sie bestätigt haben, dass Ihr Bestelltext die Personalisierung nennt.
• Eigene Listen: Alternativ wird eine Liste direkt aus allen Mitgliedern einer Zielgruppe gebildet, etwa aus allen mit Opt-in „Ja“. Wer die Einwilligung verantwortet, bestätigt das beim Anlegen; PuckID speichert, wer und wann.
• Wird ein Konto gelöscht, nimmt PuckID die Adresse aus allen Listen im Tool und löscht sie dort, wenn sie in keiner anderen Liste mehr steht.

PuckID ist darauf gebaut, dass Fans ihren Daten vertrauen können – und Sie Einwilligung, Widerruf und Löschung belegen können, ohne Handarbeit.

Datenschutz

• Einwilligung mit Nachweis. Opt-ins und Nutzungsbedingungen sind versioniert; für Newsletter speichert PuckID Wortlaut, Zeitpunkte und IP-Adressen der Bestätigung.
• Getrennte Mandanten. Jede Liga und jeder Verein sieht nur die eigenen Fans, Angaben, Ereignisse und Zielgruppen. Zwischen Mandanten werden keine Daten geteilt.
• Datensparsam je Anwendung. Jede Anwendung erhält nur die Angaben, die Sie für sie freigeben.
• Recht auf Löschung, eingebaut. Fans beenden einzelne Zugänge, löschen alles bei Ihrer Organisation oder ihr ganzes Konto. Ihre Anwendungen erfahren das sofort per Webhook mit dem Grund, Adressen verschwinden aus den Newsletter-Listen, Ereignisse werden innerhalb von 15 Minuten entfernt.

Sicherheit

• Keine Geheimnisse im Klartext. Passwörter, Client- und API-Secrets, Login-Codes und die Werte der Anmelde-Cookies speichert PuckID nur als Hash. Zugangsdaten zu Newsletter-Tools und die Schlüssel der Authenticator-Apps liegen verschlüsselt.
• Zwei-Faktor-Schutz für Fans auf Wunsch, je Anwendung erzwingbar, im Admin-Portal immer.
• Schutz vor Durchprobieren. Passwort, Zwei-Faktor-Codes und Passwort-Reset sind gegen wiederholte Versuche begrenzt.
• Sitzungen, die enden, wenn sie sollen. Nach Passwortwechsel, Änderung am zweiten Faktor oder Sperre gilt keine alte Anmeldung mehr. Cookies sind HttpOnly und Secure.
• Strenge Regeln für Anwendungen. Nur registrierte Rückleitungsadressen, PKCE für öffentliche Anwendungen, signierte Tokens mit wechselbaren Schlüsseln.

Fans pflegen ihre Daten, Sicherheit und Einwilligungen an einer Stelle – in Ihrem Design, ohne Anfrage an Ihren Support.

• Übersicht: Name, E-Mail-Adresse, Stand des Zwei-Faktor-Schutzes und alle Zugänge bei Ihrer Organisation mit Datum.
• Persönliche Angaben: Name, Anschrift und alle Angaben, die Ihre Projekte abfragen. Opt-ins stehen einmal da, auch wenn mehrere Projekte danach fragen.
• Passwort ändern: mit dem aktuellen Passwort und Ihren Passwortregeln. Andere Geräte müssen sich danach neu anmelden.
• Zwei-Faktor-Schutz: Authenticator-App oder E-Mail-Code einrichten, wechseln, neue Wiederherstellungscodes erzeugen oder abschalten – jeweils mit Passwort, beim ersten Einrichten zusätzlich mit einem Code ans eigene Postfach.
• Newsletter: bestellen und abbestellen, Bestätigungsmail erneut anfordern.
• Zugang beenden: bei Projekten, die das erlauben (etwa mit Selbstregistrierung). Die Seite erklärt vorher, was gelöscht wird und was bleibt.
• Daten löschen: alles bei Ihrer Organisation – oder das ganze PuckID-Konto bei allen Anbietern. Mit Passwort und ausdrücklicher Bestätigung, danach eine Bestätigungsmail. Wer als Einziger eine Organisation verwaltet, kann sein Konto erst löschen, wenn jemand anderes übernimmt.
• Sprache: jederzeit umschaltbar, die Wahl bleibt am Konto.

Ihr Team verwaltet Projekte, Anwendungen, Formulare und Zielgruppen selbst – ohne Entwickler, ohne Ticket beim Anbieter.

• Projekte und Rollen. Projekte für jedes Angebot (Fanportal, Lizenzierung, Newsletter …), mit eigenen Rollen, Registrierungsregeln, erlaubten E-Mail-Domains und der Frage, ob Fans ihren Zugang selbst beenden dürfen.
• Benutzer. Rollen vergeben, Zugänge sperren oder entfernen, Einladungen verschicken. Die Detailseite zeigt Angaben mit dem damaligen Wortlaut der Frage, Ereignisse und Zielgruppen eines Fans.
• Anwendungen. Anwendungen registrieren, Rückleitungsadressen pflegen, Client- und API-Secrets erzeugen, Zwei-Faktor-Schutz verlangen und ein eigenes Design zuweisen.
• Datenfreigabe und Webhooks. Je Anwendung festlegen, was sie sieht; Webhooks für neue, geänderte und entfernte Zugänge. Webhooks sind signiert, werden bei Fehlern wiederholt und pausieren, wenn ein Empfänger dauerhaft nicht antwortet. Ein Protokoll zeigt jede Zustellung, einzelne lassen sich neu senden.
• Formular-Felder. Felder anlegen, mit Versionsverlauf, und je Projekt per Drag & Drop in Gruppen anordnen.
• Designs. Login-Seiten im eigenen Look gestalten – Logo, Farben, Schrift, Hintergrundbild.
• Nutzungsbedingungen. Neue Fassungen als Text oder PDF hinterlegen und freigeben.
• Ereignistypen, Zielgruppen, Auswertung. Ereignisse definieren, Zielgruppen mit Vorschau bauen und Entwicklungen in Diagrammen verfolgen.
• Newsletter. Newsletter-Tools verbinden, Newsletter anbieten, Zielgruppen und eigene Listen übergeben, den Abgleich jederzeit selbst starten.
• Geschützt und mehrsprachig. Anmeldung immer mit zweitem Faktor; Oberfläche auf Deutsch und Englisch.

PuckID ist ein OpenID-Connect-Provider: Jede gängige OIDC-Bibliothek bindet ihn mit Issuer-URL, Client-ID und Rückleitungsadresse an – ohne proprietäres SDK.

Login (OpenID Connect)

• Discovery unter /.well-known/openid-configuration, dazu Authorize, Token, Userinfo, JWKS, Token-Widerruf und Logout (RP-Initiated Logout).
• Authorization Code Flow mit PKCE (S256); vertrauliche Clients optional mit Client-Secret (client_secret_basic oder client_secret_post).
• Scopes openid, profile, email. ID-Token als JWT, signiert mit RS256; Claims u. a. sub, name, given_name, family_name, email, email_verified, roles, tenant, locale, amr, auth_time.
• prompt=none für stille Anmeldung, prompt=login und max_age für eine frische Anmeldung, ui_locales für die Sprache der Login-Seite.

Webhooks

• Ereignisse user.added, user.updated (mit den Namen der geänderten Angaben) und user.removed (bei Löschwünschen mit Grund data_deleted oder account_deleted).
• Webhooks enthalten nur Ereignis, User-ID und die Namen geänderter Angaben, keine Werte; die Daten holt die Anwendung über die API – so gelangt nichts Unfreigegebenes in fremde Logs.
• Signiert mit HMAC-SHA256 in den Headern webhook-id, webhook-timestamp und webhook-signature; automatische Wiederholung mit Pause bei dauerhaften Fehlern.

Was Ihre Anwendung nicht mehr bauen muss

Registrierung, Login, Passwort-Reset, Zwei-Faktor-Schutz, Profilpflege, Einwilligungen, Nutzungsbedingungen, Sprachwahl und Löschwünsche.