c15t

Was ist c15t?

c15t ist ein Open-Source-Framework zur Verwaltung von Cookie-Consent und Script-Loading in modernen Web-Anwendungen. Sein Kernzweck ist es, Entwicklern zu helfen, die Einholung von Consent zu steuern und Tracking- oder andere Scripts basierend auf dem Consent-Status zu aktivieren (oder zu blockieren).

Das Projekt ist als „developer-first“ und „headless“ positioniert, d. h. die zugrunde liegende Consent-Logik ist von der Benutzeroberfläche getrennt, sodass Teams den Banner und Dialog in ihrem eigenen Stack erstellen können, statt auf undurchsichtige Vendor-Logik angewiesen zu sein.

Wichtige Funktionen

• Open-Source-Consent-Framework für Cookies, Consent und Privacy-Compliance-Workflows, fokussiert auf moderne Web-Apps.
• Consent- und Script-Loading-Steuerung für Client/Edge-Ausführung, mit dem Ziel, Anfragen zu blockieren, bis der relevante Consent-Status gesetzt ist.
• Headless-Core, der mit mehreren Frameworks funktioniert (aufgelistet: React, Vue, Svelte, Angular, Next.js, Nuxt, SvelteKit, Astro, Solid, Qwik und mehr).
• CLI-Scaffolding zum schnellen Generieren eines Cookie-Banners oder Option, die „headless Logic“ einzubinden und die Erfahrung vollständig selbst zu steuern.
• Entwicklergesteuerte UI-Anpassung über eigenes CSS/Design-Tokens, wobei Banner-/Dialog-Komponenten mit dem Styling integrieren.
• i18n-Unterstützung für Banner-Sprache/Locale-Handling (einmal übersetzen, überall Consent).
• Geolocation-basierte Sprache- und Darstellungsoptionen, inkl. „End-Banner in End-Sprache servieren“ und optional gar nicht anzeigen.
• Jurisdiction-Targeting für 15+ Datenschutz-Rechtsordnungen, inkl. GDPR und CCPA/CPRA, mit Beispielen für LGPD, PIPEDA, PIPL und APPI.

So nutzt du c15t

Ein typisches Setup beginnt mit dem Hinzufügen des framework-spezifischen Providers und UI-Komponenten von c15t, gefolgt von der Konfiguration mit Consent-Modus, Backend-URL und Scripts, die hinter Consent gesperrt werden sollen.

Aus dem Next.js-Beispiel der Seite:

1. Provider und UI-Komponenten importieren (z. B. ConsentManagerProvider, ConsentBanner, ConsentDialog).
2. Scripts zur Provider-Konfiguration hinzufügen (Beispiel: Meta Pixel via metaPixel({ pixelId: "..." })).
3. Optionen setzen, inkl. mode (Beispiel: hosted) und backendURL (aus Umgebungsvariable).
4. <ConsentBanner /> und <ConsentDialog /> rendern, damit Nutzer Privacy-Einstellungen verwalten können.

Die Seite verweist auch auf einen Quick-Start via CLI (npx @c15t/cli).

Anwendungsfälle

• Next.js-Apps, die einen Consent-Banner und Einstellungen-Dialog brauchen, während der Consent-Status mit Script-Loading verknüpft bleibt (z. B. Analytics-Scripts nur nach Nutzerwahl aktivieren).
• Multi-Framework-Teams, die eine einheitliche Consent-Logik mit UI aus eigenen Komponenten wollen, da der Core headless und mit vielen Frameworks kompatibel ist.
• Lokalisierungsintensive Produkte, die Consent-Banner-Text in der Nutzersprache brauchen, via integriertem i18n/Locale-Handling.
• Produkte in mehreren Regionen, wo Datenschutz-Messaging (oder Banner-Anzeige) je Jurisdiction und Sprache variiert, unterstützt durch Geo-Location und Jurisdiction-Konfiguration.
• Teams, die Custom-Styling und Design-Token-Integration für Banner/Dialog bevorzugen, statt vorgefertigter UI.

FAQ

• Ist c15t nur eine UI-Lösung?
  Nein. Die Seite beschreibt c15t mit headless Core, bei dem Entwickler die „headless Logic“ einbinden und Erfahrung/Styling steuern können.

• Welche Frameworks werden unterstützt?
  Die Seite listet Kompatibilität mit React, Vue, Svelte, Angular, Next.js, Nuxt, SvelteKit, Astro, Solid, Qwik und mehr.

• Kann ich das Banner-Design anpassen?
  Ja. Die Seite gibt an, dass du mit eigenem CSS und Design-Tokens stylen und die Erfahrung steuern kannst.

• Unterstützt c15t mehrere Sprachen?
  Ja. Die Seite nennt i18n-Unterstützung mit integriertem Locale-Handling.

• Wie handhabt es verschiedene Datenschutz-Rechtsordnungen?
  Die Seite beschreibt Geo-Location und Jurisdiction-Targeting, inkl. Beispiele wie GDPR und CCPA/CPRA, und erwähnt 15+ Jurisdiktionen.

Alternativen

• Headless Consent-Management-Bibliotheken/framework-agnostisch: Statt eines dedizierten Consent-Frameworks können Teams den Consent-Zustand selbst managen und Script-Loading hinter eigener UI schalten. Dies verschiebt den Implementierungsaufwand von einem fertigen Framework weg.
• Cookie-/Banner-Komponenten mit UI-Fokus: Einige Lösungen bieten hauptsächlich einen fertigen Consent-Banner mit Konfiguration. Diese opfern typischerweise die Entwicklerkontrolle über Consent-Logik und Script-Gating im Vergleich zu einem headless Ansatz.
• Tag-/Script-Management-Tools mit Consent-Modi: Alternativen im Analytics/Tag-Management-Bereich bieten oft consent-bewusstes Script-Triggering. Workflows drehen sich meist um Tag-Regeln statt einem headless Consent-Core, den Entwickler direkt integrieren können.
• Privacy-/Compliance-Plattformen: Diese managen breitere Compliance-Workflows. Sie passen oft weniger zu framework-agnostischen, entwicklungsgesteuerten Consent- und Script-Loading-Mustern wie bei c15t.