Was passiert mit dem Consent, wenn sich eine E-Mail-Adresse in Customer Insights ändert?

Vor Kurzem bin ich in einer Forum-Diskussion über ein spannendes Thema gestolpert – Consent Management in Customer Insights, genauer: E-Mail-Änderungen und der dazugehörige Consent. Diese Frage taucht ziemlich häufig auf, ist also offensichtlich für viele relevant. In Outbound Marketing war Consent direkt an das E-Mail-Feld des Kontakts gebunden oder über Subscription Lists abgebildet. Eine Änderung der E-Mail-Adresse war in diesem Setup kein großes Thema. In Realtime Marketing hingegen ist der Consent an Contact Points gekoppelt. Wenn sich also eine E-Mail-Adresse ändert – zum Beispiel durch einen Jobwechsel oder eine Domain-Änderung – kann das dazu führen, dass der Consent verloren geht.

Kurzer Disclaimer: Da Consent Management auch rechtliche Aspekte umfasst, sind die Ideen und Vorschläge hier meine persönlichen Empfehlungen. Bitte sprich mit eurer Rechtsabteilung, um sicherzustellen, dass ihr alle relevanten Gesetze einhaltet.

Die Kernfrage lautet: Was passiert mit dem Consent- oder Unsubscribe-Status, wenn sich eine E-Mail-Adresse ändert? Bleibt der Consent gültig oder solltest du für die neue E-Mail-Adresse erneut um Zustimmung bitten?

Unten findest du zwei Optionen, wie du mit dieser Situation umgehen kannst.

Option 1: Consent erneut anfordern

Ein Ansatz ist, jedes Mal erneut Consent anzufordern, sobald die E-Mail-Adresse eines Kontakts aktualisiert wird. In dieser Methode wird automatisch eine E-Mail an den Kontakt geschickt, sobald sich die E-Mail-Adresse ändert – mit der Bitte, erneut Consent zu geben. Das ist die einfachere Lösung, und der Trigger dafür existiert bereits: Contact email address is updated.

Bevor du die Journey erstellst, solltest du die E-Mail designen. Du hast dabei zwei Optionen:

1. Button, der auf eine Landing Page führt: Die Seite zeigt eine Danke-Nachricht, und nach dem Klick triggert ein Power-Automate-Flow, der den neuen Contact-Point-Consent erstellt.
2. Button, der ins Preference Center führt: Dort kann der Kontakt seine Präferenzen aktualisieren, und der Consent wird automatisch erstellt.

Ich habe mich für die zweite Option entschieden.

Wenn du ein restriktives Enforcement Model für den „Commercial“-Purpose nutzt, muss die E-Mail transaktional sein.

Erstelle eine Journey, die so aussieht:

Diese Option ist schnell umgesetzt, und der Trigger existiert bereits. Der neue Consent-Datensatz wird automatisch erstellt und lässt sich später gut nachverfolgen. Allerdings bleibt der Consent zur alten E-Mail-Adresse im System – was die Frage aufwirft, ob er behalten oder gelöscht werden sollte. Außerdem erzeugt es eine Hürde, wenn der Kontakt erneut Consent geben muss, was das Risiko erhöht, ihn zu verlieren.

Option 2: Consent auf einen neuen Datensatz übertragen

Die zweite Option besteht darin, den Wert des bestehenden Consent-Datensatzes von der alten E-Mail-Adresse auf die neue zu übertragen. Das war in der Umsetzung komplexer, als ich am Anfang dachte. Ein Power-Automate-Flow, der auf E-Mail-Änderungen reagiert und bestehende Consent-Datensätze mit der neuen E-Mail-Adresse aktualisiert, ist nicht möglich – weil die E-Mail-Adresse in einem Consent-Datensatz nicht geändert werden kann.

Um weiterzumachen, musst du herausfinden, ob die alte E-Mail-Adresse den Status Opt-in oder Opt-out hatte, denn genau dieser Status soll auf die neue Adresse übertragen werden. Das Problem: Sobald die neue E-Mail gespeichert ist, ist es schwierig, den alten Wert noch zu bekommen.

Part 1: Audit History in Power Automate nutzen

_objectid_value eq '@{triggerOutputs()?['body/contactid']}'

Zuerst hatte ich überlegt, die alte E-Mail-Adresse über einen synchronen Workflow in ein separates Feld zu schreiben. Eleganter fand ich allerdings, den alten Wert aus der Audit History zu ziehen – auch wenn das die Lösung komplexer macht.

Wir starten in Power Automate. Der Flow soll nur dann triggern, wenn sich die E-Mail-Adresse ändert – und nur, wenn das E-Mail-Feld nicht leer ist. Sonst ergibt es keinen Sinn. Danach lade ich die Audit History für den Contact-Objekttyp.

Hinweis: Die Audit History muss natürlich vorher für den Kontakt aktiviert sein. Und ja – das habe ich selbst beim ersten Mal auch vergessen..

Als nächsten Schritt füge ich eine Delay-Aktion für 2 Minuten hinzu, weil ich gemerkt habe, dass die Audit History nicht immer direkt nach dem Speichern des Kontakts verfügbar ist.

Dann nutze ich Compose, um die Audit History besser verarbeiten zu können. Das JSON dafür findest du hier:

json(outputs('List_rows_-_Audits_of_contact')?['body/value'][0]['changedata'])['changedAttributes']

Natürlich kann es auch sein, dass jemand nicht nur die E-Mail-Adresse ändert, sondern gleichzeitig noch weitere Felder. In diesem Fall gibt die Compose-Funktion ein Array mit mehreren Blöcken zurück. Das sieht dann zum Beispiel so aus:

[
  {
    "logicalName": "emailaddress1",
    "oldValue": "amanda@bestforyouorganicscompany.com",
    "newValue": "amanda.hegg@bestforyouorganicscompany.com"
  },
  {
    "logicalName": "telephone1",
    "oldValue": null,
    "newValue": "+4912345678"
  },
  {
    "logicalName": "jobtitle",
    "oldValue": null,
    "newValue": "Consultant"
  }
]

Daraus brauchen wir nur den alten Wert des E-Mail-Feldes. Deshalb nutze ich die Aktionen filter und danach select. Die filter-Aktion zieht nur den Teil des Arrays heraus, der die Werte für emailaddress1 enthält.

Im erweiterten Modus der Filter-Aktion sollte der Ausdruck so aussehen:

equals(item()?['logicalName'], 'emailaddress1')

Die select-Funktion holt sich dann den alten E-Mail-Wert aus dem gefilterten Array. Im Select-Step klickst du am besten rechts auf das kleine Switch Map to text mode-Icon und gibst Folgendes ein, damit nur die E-Mail-Adresse zurückgegeben wird:

item()['oldValue']

Damit habe ich den alten E-Mail-Wert aus der Audit History extrahiert. Er ist noch in einem Array – aber mit der join-Funktion kann ich ihn in Text umwandeln.

join(body('Select'),';')

Part 2: Consent der alten E-Mail finden und nutzen

Jetzt, wo wir die alte E-Mail-Adresse haben, nutze ich sie, um bestehende Contact Point Consents zu finden. Ich möchte den Opt-in- oder Opt-out-Wert vom alten Consent auf den neuen Consent-Datensatz für die neue E-Mail-Adresse übertragen.

Zuerst brauche ich die GUID des Purpose (msdynmkt_purpose) und muss die Topics (msdynmkt_topic) finden, zu denen der Kontakt möglicherweise subscribed oder unsubscribed ist.

Dann suche ich mit List Row nach bestehenden Contact Point Consents für die alte E-Mail-Adresse.

msdynmkt_contactpointvalue eq '@{variables('oldValueEmailaddress')}' and _msdynmkt_purposeid_value eq '@{variables('CommercialGUID')}' and msdynmkt_contactpointtype eq 534120000 and msdynmkt_contactpointconsenttype eq 534120000

Das Feld msdynmkt_contactpointconsenttype gibt an, ob es sich um einen Datensatz für Purposes oder Topics handelt. 534120000 steht für Purpose und 534120001 steht für Topic. Und das Feld msdynmkt_contactpointtype mit dem Wert 534120000 definiert, dass der Kanal E-Mail ist.

In der folgenden Condition prüfen wir, ob die List-Funktion Werte zurückgibt. Dafür nutze ich den Ausdruck empty. Wenn keine Datensätze gefunden werden, wird true zurückgegeben und wir können den Flow stoppen – es gibt nichts zu übertragen. Wenn Datensätze zur alten E-Mail gefunden werden, liefert der Ausdruck false zurück und wir erstellen auch neue Contact Point Consents für die neue E-Mail-Adresse.

empty(outputs('List_rows_-_Find_existing_CPCs_for_Purpose')?['body/value'])

Im nächsten Schritt erstelle ich den neuen Datensatz so:

• Channel: Email
• Consent status: Nutze den dynamischen Wert aus der List-Rows-Funktion des bestehenden Contact Point Consent
• Contact point: Nutze die neue E-Mail-Adresse aus dem Trigger
• Reason: Ein Grund deiner Wahl, ich habe No Reason gewählt
• Source: Eine Source deiner Wahl, ich habe Loaded gewählt
• Consent type: Purpose
• Reason description: Füge eine Beschreibung hinzu
• Purpose: Füge die GUID des Purpose aus der Variable hinzu, die wir vorher definiert haben

Danach wiederhole ich alles für die Topics. Im Prinzip nutze ich den gleichen Filter wie beim Listing zuvor – nur dass ich diesmal 534120001 für msdynmkt_contactpointconsenttype eintrage.

msdynmkt_contactpointvalue eq '@{variables('oldValueEmailaddress')}' and _msdynmkt_purposeid_value eq '@{variables('CommercialGUID')}' and msdynmkt_contactpointtype eq 534120000 and msdynmkt_contactpointconsenttype eq 534120001

Und auch hier kommt wieder die Condition, die entweder den Flow beendet oder neue Datensätze für die neue E-Mail-Adresse erstellt.

• Channel: Email
• Consent status: Nutze den dynamischen Wert aus der List-Rows-Funktion des bestehenden Contact Point Consent
• Contact point: Nutze die neue E-Mail-Adresse aus dem Trigger
• Reason: Ein Grund deiner Wahl, ich habe No Reason gewählt
• Source: Eine Source deiner Wahl, ich habe Loaded gewählt
• Consent type: Topic
• Reason description: Füge eine Beschreibung hinzu
• Purpose: Füge die GUID des Purpose aus der Variable hinzu, die wir vorher definiert haben
• Topic: GUID aus der List-Rows-Funktion von vorhin

Und das war’s.

Power Automate startet, wenn eine E-Mail-Adresse geändert wird, sucht die alte E-Mail-Adresse über die Audit History – und wenn es bereits einen Consent-Datensatz gab, erstellt es auch einen neuen Datensatz für die neue E-Mail-Adresse.

Hinweis 1: Voraussetzung für diesen Flow ist, dass es nur ein Compliance Profile gibt. Er ist nicht für mehrere Business Units ausgelegt.

Hinweis 2: Bitte denke auch an Error Handling in deinem Flow. Dann wirst du informiert, falls etwas schiefgeht. Es gibt dazu draußen in der Community viel guten Content.

Zusammenfassung

In diesem Artikel geht es um die Frage, was mit Consent passiert, wenn sich die E-Mail-Adresse eines Kontakts ändert. Entweder wird Consent erneut angefragt (Option 1) oder der bestehende Consent wird auf die neue E-Mail-Adresse übertragen (Option 2). Beide Ansätze haben Vor- und Nachteile. Ich tendiere dazu, den Kontakt explizit um neuen Consent zu bitten, weil Kunden es gewohnt sind, Newsletter neu zu abonnieren, wenn sich ihre E-Mail-Adresse ändert. Option 2 kann aber hilfreich sein – besonders im B2B-Umfeld.

Am Ende liegt die Entscheidung bei dir: Wie würdest du damit umgehen?

Hast du Fragen, Ideen oder Anmerkungen? Meld dich gern.