Power Pages Consent Management für React und externe Dienste

Inhalt

• Warum ein Cookie Banner in Power Pages nicht ausreicht
• Welche Grenze trennt Einwilligung und Dienstbetrieb
• Wie vier Bausteine zusammenarbeiten
• Was Unternehmen durch die Trennung gewinnen
• Welche technischen Entscheidungen dokumentieren die Deep Dives
• Wie du die Architektur auf dein eigenes Portal überträgst

Warum ein Cookie Banner in Power Pages nicht ausreicht

Für externe Dienste in Power Pages nutze ich eine gemeinsame Consent-Service-Registry. Die CMP Bridge synchronisiert Entscheidungen aus consentmanager, der eingesetzten Consent Management Plattform, mit dieser Registry. Die Registry veröffentlicht daraus den Browser Snapshot und stößt je Dienst den passenden Lifecycle an. Application Insights nutzt einen eigenen Adapter. Für Google Maps lesen React und JavaScript im Web Template den Consent-Status und verantworten das SDK selbst.

Ein Cookie Banner zeigt Auswahlmöglichkeiten. Es steuert nicht automatisch, welche Web Templates oder React Komponenten ein externes SDK laden. Die hybride Architektur von Power Pages und React braucht deshalb einen technischen Vertrag statt wiederholter CMP Abfragen in einzelnen Komponenten.

Die CMP bleibt Quelle der Vendor-Entscheidungen. Die Registry ist eigene Projektlogik. Sie übersetzt diese Entscheidungen in einen gemeinsamen Browservertrag, ersetzt die CMP aber nicht. Ein Banner oder ein technischer Consent-Flow allein belegt keine rechtliche Konformität.

Welche Grenze trennt Einwilligung und Dienstbetrieb

Ich trenne in der Registry Consent-Status und Runtime-Status. Ein Snapshot kann true melden, obwohl ein SDK noch nicht geladen oder die Telemetrie-Instanz nicht aktiv ist. Der Wert beschreibt die CMP-Entscheidung. Er belegt nicht, dass ein Dienst tatsächlich läuft.

Beim Widerruf beendet der Application Insights Adapter die Telemetrie-Instanz, löscht die Tracking-Cookies und entfernt das globale telemetry Objekt. Bereits geladene SDK-Skript-Elemente bleiben jedoch im Dokument. Trifft ein Widerruf während des SDK-Downloads ein, kann der laufende Aktivierungs-Callback zuerst abgeschlossen werden. Die Warteschlange verarbeitet den Deaktivierungs-Callback danach. Eine sofortige Beendigung während des Downloads ist damit nicht garantiert.

Die Application Insights Fallstudie ordnet Analytics und Datenschutz im Projektkontext ein. Dieser Beitrag betrachtet die technische Zuständigkeit zwischen CMP, Registry und Dienst.

Wie vier Bausteine zusammenarbeiten

Ich nutze die Hero-Grafik, um vier koordinierende Bausteine und zwei Dienst-Consumer zu unterscheiden. Das Web Template setzt den Seitenkontext und die Dienstkonfiguration. Danach lädt es die drei Webfiles in fester Reihenfolge:

<script src="~/consent-services.js"></script>
<script src="~/application-insights-consent.js"></script>
<script src="~/consentmanager-bridge.js"></script>

Das erste Script legt die Registry an und registriert konfigurierte Dienste. Das zweite ergänzt Application Insights um Aktivierungs- und Deaktivierungs-Callbacks. Das dritte wartet auf window.__cmp und synchronisiert die Vendor-Entscheidungen mit der Registry.

Die Registry veröffentlicht einen Snapshot und das projektspezifische consentserviceschange Ereignis. Application Insights besitzt einen Adapter, der sein SDK nach Zustimmung lädt und die Telemetrie-Instanz beim Widerruf beendet. Google Maps ist anders angebunden. Die Registry veröffentlicht nur den Einwilligungsstatus. Der jeweilige Consumer verwaltet das Maps SDK und die Google Maps Instanz selbst.

Google Maps nutzt diesen Vertrag in zwei Varianten. Die React-Anwendung verwaltet die Google Maps Instanz innerhalb ihres Komponenten-Lifecycles. Auf einer Detailseite übernimmt das JavaScript im Power Pages Web Template die Anzeige von Google Maps. Beide Consumer lesen dieselbe Einwilligung, ohne eigene CMP-Abfragen aufzubauen.

Was Unternehmen durch die Trennung gewinnen

Ich ordne jedem Dienst eine Vendor-Zuordnung und eine klare Zuständigkeit für seinen Lifecycle zu. Web Templates halten die Vendor-Konfiguration getrennt vom React Bundle. React und anderes Browser-JavaScript können dieselbe Registry lesen, statt jeweils eine eigene CMP Abfrage aufzubauen.

Die ECE Fallstudie zur Power Pages Enterprise-Suche zeigt, wie diese Consent-Architektur als portalweite Erweiterung neben einer eigenständigen Suchanwendung eingesetzt wird.

Der Application Insights Abschnitt des E-Commerce Projekts zeigt den geschäftlichen Analytics-Kontext. Die Trennung schafft technische Governance und nachvollziehbare Zuständigkeiten. Sie ist keine rechtliche Zertifizierung.

Welche technischen Entscheidungen dokumentieren die Deep Dives

Im Deep Dive zur Consent-Service-Registry in Power Pages beschreibe ich Browservertrag, Snapshot und CMP Bridge im Detail.

Der Beitrag zu Application Insights und Einwilligung behandelt SDK-Laden, Widerruf, erneute Zustimmung und die Grenze beim laufenden Download.

Im Beitrag zu Google Maps in Power Pages mit React und Web Templates beschreibe ich die Anzeige von Google Maps in beiden Varianten und grenze den veröffentlichten Status von der Verantwortung des jeweiligen Consumers ab.

Wie du die Architektur auf dein eigenes Portal überträgst

Wenn du diese Architektur in deinem eigenen Power Pages Portal einsetzt, prüfe vier Punkte:

1. Vendor-Zuordnung: Ist für jede Umgebung klar, welche CMP-Entscheidung zu welchem Dienst gehört?
2. Ladereihenfolge: Stehen Konfiguration, Registry, Adapter und CMP Bridge in der benötigten Reihenfolge?
3. Lifecycle: Startet ein Adapter den Dienst, oder veröffentlicht die Registry nur einen Status für einen eigenen Consumer?
4. Widerruf: Welche SDK-Skripte, Instanzen, Cookies und Requests bleiben nach einem Widerruf bestehen?

Prüfe Snapshot, Netzwerkverkehr und Cookies getrennt. Eine erteilte Einwilligung bestätigt nicht den Runtime-Status. Die technische Umsetzung ersetzt außerdem keine separate rechtliche Bewertung.

Du ordnest gerade externe Dienste in einem Power Pages Portal neu? Lass uns die Zuständigkeitsgrenzen gemeinsam prüfen.