Consent-Management-Plattform wechseln, ohne das Tracking zu beschädigen

Alle Beiträge

Wechseln Sie in dieser Reihenfolge: Installieren Sie die neue Plattform neben der alten, stellen Sie jede Einwilligungsbedingung auf das neue Signal um und entfernen Sie die alte Plattform zuletzt. Eine Migration scheitert selten am neuen Banner. Sie scheitert an dem, was das alte in Ihrem Tag-Manager zurücklässt: Variablen, die Cookies lesen, die es nicht mehr gibt, und die darauf aufgebauten Ausnahmen.

Warum ist das neue Banner die leichte Hälfte?

Die Migrationsseiten der Consent-Anbieter sind sich bei der Reihenfolge weitgehend einig: Audit, Einwilligungsnachweise exportieren, neues Skript ausrollen, live gehen. Meist nennen sie dafür drei bis zehn Tage. Diese Reihenfolge stimmt, und es ist die Hälfte der Arbeit, die sich bemerkbar macht, wenn etwas schiefgeht.

Über die andere Hälfte schreibt niemand: was die scheidende Plattform im Container zurücklässt. Ein in einem Tag-Manager installiertes Consent-Tool ist nie nur ein Tag. Es ist ein Template, dazu Variablen, die seine Cookies lesen, Trigger, die auf seine Events hören, und, mit den größten Folgen, die Ausnahmen, die andere in den Jahren danach auf diesen Variablen aufgebaut haben. Löschen Sie das Tag, bleibt all das genau dort, wo es ist, weiterhin aktiv und bei jedem Seitenaufruf ausgewertet.

Was macht eine tote Variable mit einer Blockierregel?

Eine Variable, die ein Einwilligungs-Cookie liest, liefert den Wert dieses Cookies. Ist die Plattform weg, die es geschrieben hat, ist auch das Cookie weg, und die Variable liefert auf jeder Seite undefined.

Sehen Sie sich jetzt die Regel an, die darauf aufbaut. Blockierbedingungen sind negativ formuliert: Blockiere dieses Tag, wenn die Einwilligungsvariable die benötigte Kategorie „does not contain“. Bei einem echten Cookie ist das falsch, sobald eingewilligt wurde, und das Tag löst aus. Bei undefined ist es wahr. Immer, für jeden Besucher, auch für die, die alles akzeptiert haben.

Eine Ausnahme, die immer wahr ist, ist ein Tag, das nie wieder auslöst.

Bei einem Live-Bestand, den wir nach einem Plattformwechsel geprüft haben, waren vier Tags auf diese Weise still blockiert, darunter die wichtigste Werbe-Conversion, und zwar rund acht Monate lang. Niemand hatte diese Tags angefasst. Der Container war gültig, das neue Banner funktionierte, und das Consent-Mode-Signal stimmte. Die Blockierregeln zeigten schlicht auf eine Plattform, die nicht mehr da war.

Wie wechseln Sie die Plattform ohne Tracking-Lücke?

1. Erfassen, was zur alten Plattform gehört

   Exportieren Sie den Container als JSON und durchsuchen Sie ihn nach dem Namen des alten Anbieters. Sie suchen nach vier Dingen, nicht nach einem: seinem Tag-Template, den Variablen, die seine Cookies lesen, den Triggern, die auf seine Events hören, und jeder Ausnahme, die auf diesen Variablen aufbaut.

2. Notieren, welches Signal jedes Tag absichert, jetzt und danach

   Eine Zeile pro abgesichertem Tag: die Bedingung, die es heute absichert, und die Bedingung, die es absichern wird, sobald die neue Plattform läuft. Erledigen Sie das, solange das alte Setup noch live ist und sich auslesen lässt. Nur so können Sie den Wechsel danach überprüfen.

3. Der neuen Plattform die Standardwerte überlassen

   Die neue Plattform kommt auf „Consent Initialization“ und setzt die „denied“-Standardwerte für ad_storage, analytics_storage, ad_user_data und ad_personalization. Googles Leitfaden zum Consent Mode verlangt diese Standardwerte, bevor ein Tag Messdaten sendet. Entfernen Sie die alten Standardwerte in derselben Version: Zwei konkurrierende Default-Befehle sind ein echtes Risiko und kein doppelter Boden.

4. Die Ausnahmen neu bauen, bevor Sie etwas löschen

   Jede Blockierregel, die auf den Variablen der alten Plattform aufbaut, wird zuerst gegen den neuen Einwilligungsstatus neu geschrieben, solange die alten Variablen noch echte Werte liefern und Sie das Verhalten vergleichen können. Diesen Schritt lassen Migrationen aus, weil die Ausnahmen an einer anderen Stelle im Container liegen.

5. Alte Variablen und Templates zuletzt löschen

   Erst, wenn nichts mehr auf sie verweist. Ein Tag-Manager zeigt Ihnen, was noch auf eine Variable zeigt. Arbeiten Sie, bis diese Liste leer ist, und entfernen Sie dann die Variablen und das Template des Anbieters. Ein verwaistes Template bleibt registriert.

6. Prüfen, was auslöst, nicht nur, was durchsickert

   Lehnen Sie in einem frischen Profil alles ab und prüfen Sie, dass keine Werbe- oder Analytics-Cookies gesetzt werden. Akzeptieren Sie dann und gehen Sie Ihre Liste aus Schritt zwei durch, um zu bestätigen, dass jedes Tag tatsächlich auslöst. Vergleichen Sie zum Schluss die Conversions dieser Woche mit der Woche vor dem Wechsel.

Die Ablehnungsseite dieser Prüfung sollten Sie gründlich durchgehen statt schnell: die vollständige Prüfung vor dem Livegang steht hier, und die zwei Prüfungen, die das Consent-Mode-Signal bestätigen, stehen hier.

Was übersteht eine Migration, obwohl es nicht sollte?

Verwaiste Variablen-Templates. Wer die Tags eines Anbieters löscht, deinstalliert damit nicht seine Templates. Sie bleiben im Container, ungenutzt, aber registriert, und werden leicht übersehen. Entfernen Sie sie zusammen mit den Variablen.

Einwilligungs-Mappings nach dem Prinzip Alles oder Nichts. Ältere Setups sichern oft alles über ein einziges Event „alles akzeptiert“ ab statt über Kategorien. Wenn Sie so etwas migrieren, war jeder Besucher, der manche Kategorien akzeptiert und andere abgelehnt hat, schon vorher unsichtbar, unabhängig vom Wechsel. Sie fassen ohnehin jedes abgesicherte Tag an. Stellen Sie also auf Bedingungen pro Kategorie um, statt die alte Form in einem neuen Tool nachzubauen.

Skripte, die nie im Container waren. Ein Anbieter-Skript, das direkt in den Head der Website eingefügt wurde, war auch von der alten Plattform nicht abgesichert, und die neue erreicht es nur, wenn Sie es in den Container verschieben oder umhüllen. Ob sich ein bestimmtes Skript verschieben lässt, klären Sie am besten Skript für Skript, und eine Migration ist dafür der natürliche Zeitpunkt.

Was passiert mit den Einwilligungen, die Besucher schon erteilt haben?

Rechnen Sie damit, dass Besucher erneut gefragt werden. Jede Plattform liest ihre eigene „gespeicherte Entscheidung“. Sofern die neue nicht so eingerichtet ist, dass sie das Cookie der alten liest, sehen wiederkehrende Besucher nach dem Wechsel noch einmal das Banner.

Bewahren Sie die alten Aufzeichnungen auf. Beruht die Verarbeitung auf einer Einwilligung, muss der Verantwortliche nach Art. 7 Abs. 1 DSGVO „nachweisen können“, dass der Besucher eingewilligt hat. Diese Pflicht endet nicht, wenn das Tool entfernt wird, das die Einwilligung protokolliert hat. Exportieren Sie das Einwilligungsprotokoll der alten Plattform, bevor der Vertrag endet, und notieren Sie das Datum, an dem die neue Plattform übernommen hat. Was ein brauchbarer Einwilligungsnachweis enthält, steht hier.

Wie erkennen Sie, ob Ihnen das schon passiert ist?

Wenn Sie früher die Plattform gewechselt und Schritt sechs nie ausgeführt haben, zeigen Ihnen zwei Prüfungen, wo Sie stehen.

Suchen Sie im Container nach dem Namen des bisherigen Anbieters. Alles, was dabei auftaucht, ist Altlast. Jede Ausnahme, die auf einer Variable aufbaut, die ein Cookie liest, das keine Plattform mehr schreibt, blockiert ihr Tag genau jetzt. Und zwar seit dem Tag, an dem das alte Tool entfernt wurde.

Nehmen Sie in den Daten Ihre wichtigste Conversion und sehen Sie sich einen Zwölfmonatsverlauf an statt eines Dreißigtageverlaufs. Eine stille Blockierung sieht nicht wie ein Rückgang aus. Sie sieht aus wie eine saubere Stufe nach unten auf nahezu null an einem einzigen Datum, danach flach. Diese Form erzeugt keine Veränderung bei Zielgruppe oder Markt. Gleichen Sie das Datum mit dem Plattformwechsel ab. Die anderen Ursachen für einen Einbruch über Nacht finden Sie hier. Diese hier fällt am spätesten auf, denn die Tags, die ihre Absicherung verloren haben, sind nur ein Teil, und die Summe sinkt, ohne ganz zu verschwinden.

Velo ist oft die Plattform, zu der gewechselt wird, dieser Rat ist also nicht ganz uneigennützig. Er gilt trotzdem: Die Altlasten gehören zum Tool, das Sie verlassen, und kein neues Banner kann sie für Sie beseitigen. Planen Sie Zeit für die Arbeit am Container ein, nicht nur für die Installation.