Ich bin mal wieder über ein „spannendes“ Consent Management Thema im Customer Insights Forum gestolpert. Aber die Frage habe ich schon öfter gehört, also kann es nicht so ganz irrelevant sein. Es geht um die Frage, was bei Änderung der Email und dem dazugehörigen Consent passiert. In Outbound Marketing hing der Consent direkt am Kontakt am Massen-E-Mail Feld oder der Kontakt war in einer Subscriptionliste. Wenn sich dort die Emailadresse geändert hat, war das kein Problem. In Realtime Marketing haben wir nun die Kontaktpunkte (Contact Point Consents). Und wenn der Kontakt mal seinen Consent unter einer Emailadresse gegeben hat und sich die Emailadresse dann wegen Jobwechsel oder Domainwechsel ändert, geht der Consent erstmal verloren.
Kurzer Hinweis vorab: Das es hier um Consent Management geht und das auch ein rechtliches Thema ist, sind hier nur meine Ideen und Vorschläge. Bitte klärt das Thema vorher mit euer Rechtsabteilung ab.
Die Frage ist nämlich, was mit dem gegebenen Consent oder natürlich auch dem Unsubscribe der Emailadresse passiert. Bleibt der Consent erhalten? Muss man man den Consent für die neue Email neu anfragen?
Ich zeige euch hier zwei Optionen auf.
Option 1 - Consent neu anfragen
Eine Option ist es, den Consent komplett neu anzufragen. Das bedeutet, dass immer wenn die Emailadresse am Kontakt geändert wird, eine Email versendet werden soll. In dieser Email wird der Kontakt nach dem neuen Consent gefragt.
Das ist die einfachere Variante. Den Trigger gibt es sogar schon: Contact email address is updated.
Bevor wir die Journey erstellen, designen wir die Email. Hier gibt es zwei Möglichkeiten.
1. Ein Button, der auf eine Landing Page mit einem Danketext führt. Dann muss nach dem Klick darauf in der Journey ein Power Automate getriggert werden, der den neuen Contact Point Consent erstellt.
Wenn ihr für den Zweck „Commercial“ ein restriktives Enforcement Model habt (sorry für das Denglisch), muss die Email eine transaktionale sein.
Danach erstelle ich die Journey, die wie folgt aussieht:
Der Vorteil von dieser Option ist es, dass sie sehr schnell umzusetzen ist und selbst der Trigger bereits existiert. Der Consent wird automatisch erstellt und ist auch später gut nachzuvollziehen. Nichtsdestotrotz bleibt der Consent-Datensatz der alten Emailadresse im System erhalten. Hier bleibt die Fragen offen, was damit passiert. Kann er bleiben oder muss bzw. kann er gelöscht werden? Und es ist eine Hürde für den Kontakt, den Consent erneut zugeben. Die Wahrscheinlichkeit, dass wir den Kontakt verlieren, ist recht hoch.
Option 2 - Consent in neuem Datensatz speichern
Die zweite Option übernimmt den Wert des bestehenden Consent-Datensatzes der alten Adresse. Ich habe mich da ein bisschen rangetastet, denn es ist gar nicht so einfach wie gedacht. Ein Power Automate, der auf Änderung der Emailadresse reagiert und dann die bestehenden Contact Point Consent Datensätze mit der neuen Adresse anpasst, funktioniert nicht. Es ist nicht erlaubt, die Emailadresse in einem Contact Point Consent zu ändern.
Also brauchen wir neue Datensätze für die neue Emailadresse. Dafür müssen wir aber auch wissen, ob zu der alten Emailadresse ein Opt In oder Opt Out festgehalten wurde, denn das müssen wir ja für die neue Adresse übernehmen. Und genau das stellt uns vor die nächste Herausforderung. Sobald die neue Emailadresse eingetragen und der Datensatz gespeichert ist, können wir im Power Automate nicht mehr auf den alten Wert zurückgreifen.
Teil 1: Überwachungshistorie in Power Automate nutzen
Ich habe erst gedacht, die alte Emailadresse vorher in einem anderen Feld speichern zu müssen, z.B. mit einem synchronen Workflow. Aber nach etwas Überlegung, finde ich die Variante mir den alten Wert aus der Überwachungshistorie zu holen etwas charmanter. Es ist allerdings auch aufwendiger.
Starten wir mit dem Power Automate, der nur triggern soll, wenn sich die Emailadresse ändert und auch nur, wenn die Emailadresse nicht leer ist. Macht ja sonst keinen Sinn. Im Anschluss lade ich die Überwachungshistorie zum Objekttyp Kontakt.
Hinweis: Die Überwachungshistorie muss natürlich vorher für den Kontakt aktiviert sein.
_objectid_value eq '@{triggerOutputs()?['body/contactid']}'
Als nächstes baue ich eine Delay Aktion für 2 Minuten ein, denn ich habe festgestellt, dass die Überwachungshistorie nicht immer direkt nach Speichern des Kontaktes zur Verfügung steht.
Dann nutze ich die Compose Funktion, um die Änderungshistorie besser weiterverarbeiten zu können. Das json dafür findest du hier:
json(outputs('List_rows_-_Audits_of_contact')?['body/value'][0]['changedata'])['changedAttributes']
Es kann natürlich auch sein, dass jemand im Kontakt nicht nur die Email, sondern auch gleichzeitig noch andere Felder ändert. Dann gibt die Compose Funktion ein Array mit mehreren Blöcken zurück. Das sieht dann in etwa 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"
}
]
Hieraus benötigen wir nur den alten Wert des Email-Feldes. Daher nutze ich danach die Filter und dann die Select Aktion. Die Filter Aktion sucht sich nur den Teil der emailaddress1 raus.
Im erweitertem Modus der Filter Aktion sieht das ganze dann so aus:
equals(item()?['logicalName'], 'emailaddress1')
Die Select Funktion holt anschließend aus dem Filter Array den Wert der alten Email. Im Select Schritt klickst du am besten auf das kleine Icon Switch Map to text mode rechts neben den Map Feldern und trage dort folgendes ein, damit nur die Emailadresse zurückgegeben wird:
item()['oldValue']
Somit habe ich jetzt den alten Emailwert aus der Überwachungshistorie extrahiert. Noch ist er in einem Array, aber mit der join Funktion, kann ich das ganze in einen Text umwandeln.
join(body('Select'),';')
Teil 2: Consent der alten Email finden und verwenden
Jetzt da wir die alte Emailadresse haben, nutze ich sie um bestehende Contact Point Consents zu finden. Den Wert Opt In oder Opt Out aus dem alten Consent möchte ich im neuen Consent Datensatz für die neue Emailadresse übertragen.
Zuerst benötige ich dafür die GUID des Zwecks (msdynmkt_purpose) und muss die Topics (msdynmkt_topic) finden, zu denen sich der Kontakt an- oder abgemeldet haben kann.
Dann suche ich nach den existierenden Contact Point Consents für die alte Emailadresse über die Listenfunktion.
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 spezifiziert, ob es sich um einen Datensatz für Zwecke oder Themen handelt. 534120000 steht für Zweck und 534120001 steht für Thema. Und das Feld msdynmkt_contactpointtype mit dem Wert 534120000 definiert, dass es sich um den Kanal Email handelt.
In der anschließenden Bedingung prüfen wir, ob Werte aus der Listenfunktion zurückgegeben werden. Ich nutze das für den Ausdruck empty. Wenn keine Datensätze gefunden werden, wird der Wert true zurückgeben und wir können den Flow stoppen, es müssen keine Daten übertragen werden. Wenn Datensätze der alten Email gefunden werden, gibt der Ausdruck false zurück und wir erstellen für die neue Emailadresse auch neue Contact Point Consents.
empty(outputs('List_rows_-_Find_existing_CPCs_for_Purpose')?['body/value'])
In der nächsten Aktion erstelle ich den neuen Datensatz wie folgt:
- Channel: Email
- Consent status: Nutze den dynamischen Wert aus der Listenfunktion des bestehenden Contact Point Consents
- Contact point: Nutze die neue Emailadresse aus dem Trigger
- Reason: Ein Grund deiner Wahl, ich habe mich für No Reason entschieden
- Source: Eine Quelle deiner Wahl, ich habe mich für Loaded entschieden
- Consent type: Purpose
- Reason description: Trage hier eine eindeutige Beschreibung ein, die später noch gut nachvollziehbar ist.
- Purpose: Füge hier die GUID des Zweckes aus der Variable, die wir weiter oben definiert haben ein
Anschließend wiederhole ich das Ganze für die Topics. Im Prinzip nutze ich für die Auflistung, den gleichen Filter wie vorher, nur dass ich für msdynmkt_contactpointconsenttype dieses Mal den 534120001 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 anschließend wieder die Bedingung, die den Flow entweder beendet oder einen neuen Datensatz für die neue Emailadresse erstellt.
- Channel: Email
- Consent status: Nutze den dynamischen Wert aus der Listenfunktion des bestehenden Contact Point Consents
- Contact point: Nutze die neue Emailadresse aus dem Trigger
- Purpose: Füge hier die GUID des Zweckes aus der Variable, die wir weiter oben definiert haben ein
- Reason: Ein Grund deiner Wahl, ich habe mich für No Reason entschieden
- Source: Eine Quelle deiner Wahl, ich habe mich für Loaded entschieden
- Consent type: Topic
- Reason description: Trage hier eine eindeutige Beschreibung ein, die später noch gut nachvollziehbar ist.
- Topic: GUID aus der Listenfunktion weiter oben
Und das wars auch schon.
Der Power Automate startet bei der Änderung einer Emailadresse, sucht über die Überwachungshistorie nach der alten Emailadresse und legt, wenn es bereits einen Consent Datensatz gab, auch für die Emailadresse einen neuen Datensatz an.
Hinweis 1: Die Voraussetzung für diesen Flow ist es, dass es nur ein Compliance Profil gibt. Er ist nicht für mehrere Business Units ausgerichtet.
Hinweis 2: Bitte denkt auch an entsprechendes Error Handling im Flow, damit ihr informiert werden, wenn etwas schiefgeht. Es gibt dazu tolle Artikel aus der Community, die das bereits super erklären!
Zusammenfassung
In diesem Artikel geht es um die Frage, was mit dem Consent passiert, wenn sich die Emailadresse eines Kontakts ändert. Entweder wird der Consent neu angefragt (Option 1), oder der bestehende Consent wird auf die neue Emailadresse übertragen (Option 2). Beide Ansätze haben ihre Vor- und Nachteile. Ich tendiere dazu, den Kontakt explizit nach dem neuen Consent zu fragen, da sich auch Kunden bei geänderter Emailadresse erneut zu Newslettern anmelden müssen. Option 2 kann jedoch gerade im B2B-Bereich sinnvoll sein. Letztlich liegt die Entscheidung bei euch: Wie würdet ihr damit umgehen?
