Gastausgabe
„Ich bin Johannes und berate seit mehreren Jahren Kunden aus unterschiedlichsten Branchen bei der Nutzung von Dynamics 365 Customer Insights und Power Automate. In der Vergangenheit habe ich auch als Webentwickler gearbeitet, was in meiner heutigen Arbeit häufig hilfreich ist. Ich bin als Project Lead Dynamics 365 Customer Insights bei der KC | KAISERSTADT CONSULTING GmbH & Co. KG in Aachen angestellt und arbeite meistens von meiner Heimat Berlin aus. Ich liebe den offenen Wissensaustausch in der IT-Welt, habe in der Vergangenheit viel über Blogger aus aller Welt gelernt und freue mich, auf diesem Weg etwas davon zurückgeben zu dürfen.“
Eine kleine Vorab-Bemerkung: Dieser Artikel ist länger geworden, als ich anfangs geplant habe. Ich habe mich dennoch dazu entschlossen, ihn als Ganzes zu veröffentlichen, da ich gern das Zusammenwirken der unterschiedlichen Teilbereiche aufzeigen wollte. Ob mir das gelungen ist, entscheidet ihr 😊 Dynamics Customer Insights – Journeys hat durch den Wechsel vom alten Outbound Marketing Modul zum Realtime Marketing Modul viele neue und teilweise mächtige Features vorgestellt. Auslöser und auslöserbasierte Kontaktverläufe gehören zu meinen absoluten Favoriten.
Denn der Auslöser (Trigger) sorgt nicht nur für den individuellen Startpunkt eines Kontaktverlaufs, sondern über ihn erhalten wir auch Informationen zum Kontext, etwa bei einer neuen Ereignisregistrierung alle Informationen aus der Registrierung und dem zugehörigen Ereignis. So können wir in E-Mails, die in einem solchen Kontakterlauf verschickt werden, nicht nur auf Informationen rund um den Empfänger zugreifen, sondern eben auch auf Informationen rund um die Registrierung und das zugehörige Ereignis. Wir können also einen Kontaktverlauf aufsetzen, der dauerhaft angelegt ist und für alle neuen Ereignisse (oder über Bedingungen gefilterte Ereignisse) ab dem Moment der Ereignisregistrierung bis nach dem Ereignis vollständig automatisch abläuft. Die potenzielle Zeitersparnis im Eventmanagement ist riesig. Klingt zu gut, um wahr zu sein? Hier präsentiere ich meinen Ansatz mit einigen Tricks und Kniffen, wie es gelingen kann.
Inhalt dieses Artikels:
E-Mails vorbereiten: Alles aus dynamischem Text herausholen
In keiner E-Mail des Kontaktverlaufs sollte statischer Inhalt stehen, der sich auf ein Ereignis bezieht. Um Informationen zum Ereignis in die E-Mail dynamisch zu hinterlegen, klicken wir auf „Personalisierung“ und dann auf „Neuer dynamischer Text“ und wählen unter „Auslöser“ das Attribut „Marketingregistrierung erstellt“ aus. Hier finden sich drei referenzierte Datensätze, für uns ist in diesem Fall der erste „Referenz für Marketingereignis“ wichtig. Hierunter finden sich alle Felder des Ereignisdatensatzes. Theoretisch können wir von hier auch noch tiefer gehen (zum Beispiel in den Lookup Datensatz der Location) – insgesamt bis zu fünf Ebenen!
Dynamisches Eventbild: Individueller Look für unsere E-Mails
Wir können auf dem Ereignis auch Bilder aus der Bibliothek referenzieren. Dazu gibt es zum Beispiel das Standard Lookup-Feld „Ereignisbild“.
Hinweis: Eventuell müssen wir dieses Feld zunächst über den Formulareditor auf das verwendete Ereignisformular hinzufügen, damit wir es auch nutzen können.
Um ein im Lookup „Ereignisbild“ hinterlegtes Bild in die E-Mail zu bekommen, fügen wir im E-Mail Editor ein neues Bild hinzu und wählen als Quelle „Bild aus URL hinzufügen“. Anschließend fügen wir dynamischen Text in das URL-Feld hinzu und wählen wieder das referenzierte Marketingereignis über den Auslöser aus. Von hier aus suchen wir nach „Ereignisbild“ und klicken auf die Referenz, um in den Datensatz zu kommen. Ereignisbilder gehören wie alle Dateien aus der Bibliothek der Tabelle „Datei“ an. Diese Tabelle hat mehrere URL-Felder. Wichtig ist, dass für unser Bild der Wert auf dem Feld „BLOB-CDN-URL“ genutzt wird, da dies die öffentlich zugängige URL für unser Bild ist.
Hinweis: Hinterlege unbedingt eine Bild-URL als Standardwert, damit die E-Mail nicht komisch aussieht, wenn mal in einem Ereignis kein Bild hinterlegt wurde.
Teams-Teilnahme Link: Mit ein wenig HTML-Magie
Die einfache Variante wäre, als Teilnahmelink zum Webinar den Link aus dem Feld “Teams-URL” auf dem Ereignis zu wählen. Allerdings führt dieser Ansatz zu kurz, denn so können wir eine überaus smarte Lösung von Dynamics Customer Insights – Journeys nicht nutzen: die automatische Erfassung von Check-Ins.
Um die zu nutzen, müssen wir mit der eingebauten Funktion „Teams meeting” in der Link-Konfiguration des E-Mail Editors arbeiten (siehe Screenshot). Leider muss man hier in einem Lookup-Feld ein eindeutiges Ereignis auswählen, was natürlich blöd ist, wenn das Ereignis dynamisch erkannt werden soll.
Dennoch wählen wir zunächst diesen Weg, um die grundsätzliche Linkstruktur zu generieren. Ab hier geht’s nun weiter im HTML-Editor:
Linkstruktur und Zweck verstehen
Suchen wir zunächst den erstellten Link im Quelltext. Der Link (ein <a>-Tag) hat zunächst die folgende Struktur:
<a class="<<some styling classes>>"
href=https://public-eur.mkt.dynamics.com/api/v1.0/orgs/<<ID der Organization>>/eventmanagement/checkin/stream?eventRegistrationId={{event_registration_1}}&redirectUri=https%3A%2F%2Fteams.microsoft.com%2Fl%2Fmeetup-join%2F19%253ameeting_ZWQyNGZjMGItYTFiOS00ZmY1LWEwYTktMDFkMTQyMjljZDNh%2540thread.v2%2F0%3Fcontext%3D%257b%2522Tid%2522%253a%252207a4d75e-ef15-4ea1-9913-5ef5ffd3ce38%2522%252c%2522Oid%2522%253a%25226f6b301a-522e-48ab-aa38-b5665320b93c%2522%257d#_msdynmkt_donottrack=0
style="<<some styling information>>"
data-msdyn-tracking-id="<<some tracking ID>>"
data-lookup-name="TestEreignis Checkin 1"
data-lookup-id="2a7e752f-2af2-4802-8a03-b26a5f6e9e4c"
data-lookup-type="msevtmgt_event">Your personal webinar link
</a> Auch wenn das vielleicht etwas abschreckend wirkt, grundsätzlich sind <a>-Tags im HTML (wie andere Elemente auch) sehr klar strukturiert. Es können beliebig viele Attribute mit entsprechenden Werten hinzugefügt werden. Ein Attribut ist zum Beispiel das „style“ Attribut, welches dem Element Styling-Informationen mitgeben kann. Im Attribut „href“ versteckt sich das Ziel des Links. Wir sehen hier, dass das Ziel des Links nicht direkt die Teams-URL ist, sondern zunächst die URL https://public-eur.mkt.dynamics.com/ mit jeder Menge weiterer Angaben. Ich werde hier nicht zu tief gehen, aber im Klartext bedeutet das, dass ein Request an diese von Microsoft gehostete API gesendet wird. Die dortige API prüft die Angaben und schickt dann an unser Dynamics (welches über die Org. ID definiert ist) den Auftrag, einen Check-In für den zugehörigen Teilnehmer zu erstellen. Anschließend leitet die API zum eigentlichen Teams-Event weiter. Um den Request wirklich dynamisch zu gestalten, müssen wir nun alle rot hinterlegten Teile durch dynamische Elemente ersetzen. Erfreulicherweise können wir dynamischen Text sowohl im normalen Editor, als auch im Quelltext problemlos einfügen.
Dynamischen Text erstellen
Normalerweise reicht es aus, dynamischen Text einfach in der Form {{dynamic_text}} im Fließtext einzufügen, der Editor erkennt diesen Platzhalter sofort und zeigt eine neue, unvollständige Datenquelle im rechten Seitenbereich unter „Personalize“ an. Auf diese Datenquelle kann man nun klicken und die gewünschte Quelle hinterlegen.
Wer vorher genau hingesehen hat, konnte im HTML-Code des Teams-Teilnahme-Links bereits einen vordefinierten Platzhalter {{event_registration_1}} sehen. Dieser wird vom System erstellt und für ihn gelten gewisse Ausnahmen, so erscheint er auch nicht im Bereich „Personalize“ im rechten Fensterbereich. Da wir die Linkstruktur manipulieren, funktioniert auch dieser Platzhalter nicht korrekt, weshalb wir ihn durch unseren eigenen {{Registration_ID}} ersetzen werden.
Außerdem werden Platzhalter, die nicht im Text der E-Mail erscheinen (sondern z.B. nur als Attribute von HTML-Tags), nicht vom Editor erkannt. Da wir sicherlich vermeiden wollen, die Event-ID oder die Registration-ID sichtbar im Text zu platzieren, können wir Folgendes tun:
Am Ende der E-Mail im HTML-Editor zwischen dem vorletzten schließenden </div> Element und dem letzten schließenden </div> Element fügen wir ein neues <span> Element mitsamt Styling-Attribut „display: none;“ hinzu. Die benötigten Platzhalter können wir dort hinterlegen. Auf die Weise erkennt der E-Mail Editor die Platzhalter und sie sind dennoch für den Empfänger unsichtbar.
Bearbeiten wir also nun den Link an den erforderlichen Stellen und fügen das o.g. <span>-Element im Body der E-Mail hinzu. Nach der Bearbeitung sieht der Link wie folgt aus:
<a class="<<some styling classes>>"
href=https://public-eur.mkt.dynamics.com/api/v1.0/orgs/<<ID der Organization>>/eventmanagement/checkin/stream?eventRegistrationId={{Registration_ID}}&redirectUri={{Teams_URL}}#_msdynmkt_donottrack=0
style="<<some styling information>>;"
data-msdyn-tracking-id="<<some tracking ID>>"
data-lookup-name="{{Eventname}}"
data-lookup-id="{{Event_ID}}"
data-lookup-type="msevtmgt_event">Your personal webinar link
</a> Hinweis: Im Attribut “data-msdyn-tracking-id” liegt eine eindeutige ID, über die Verhaltensdaten erfasst und zugeordnet werden können. Wenn also ein Link geklickt wird, wird über diese ID festgehalten, um welchen Link es sich handelt und wer ihn geklickt hat. Für meine Zwecke habe ich an dieser ID nichts verändert und den Standardwert verwendet.
Nach diesen Anpassungen kann der HTML-Editor wieder geschlossen werden. Nun können wir in allen neu erkannten und bislang unvollständigen Platzhaltern im Bereich „Personalize“ die Datenquellen wie folgt festlegen:
Datenquellen der Platzhaltertexte
Folgende Platzhaltertexte werden benötigt, um den Link dynamisch zu gestalten.
- {{Registration_ID}}: Es handelt sich hierbei um den Wert aus dem Feld „Registrierungs-ID“ auf der Ereignisanmeldung (Schemaname: msevtmgt_name)
- {{Teams-URL}}: Es handelt sich hierbei um eine URL-kodierte Form des Teams-Links, der im Ereignis im Feld „Teams-URL“ (msevtmgt_attendeeurl) gespeichert ist. In meinen Tests führte es zu keinen Problemen, die URL vorher nicht zu kodieren, ich konnte direkt den Wert aus dem Feld verwenden.
- {{Eventname}}: Wir nutzen hier den Wert aus dem Feld „Ereignisname“ (msevtmgt_name)
- {{Event_ID}}: Dies ist die System-ID des Ereignisses (msevtmgt_eventid)
Wichtig: Für alle hier genannten Referenzen verwenden wir den weiter oben beschriebenen dynamischen Inhalt über den Auslöser „Marketing event registration created“.
Kalendericon Download
Häufig wird auch ein Kalendereintrag zum Download angeboten. Dieser Link muss im E-Mail Editor eigentlich auch über ein Lookup-Feld mit einem eindeutigen Ereignisdatensatz verbunden werden. Es ist aber in ganz ähnlicher Form möglich, den Link zu modifizieren, wie wir es zuvor schon mit dem Teams Teilnahmelink getan haben.
<a href="https://public-eur.mkt.dynamics.com/api/v1.0/orgs/<<your organziation ID>>/eventmanagement/calendar/personal/ics?data=[{"eId":"{{readable_event_id}}","d":{"er":"{{Registration_ID}}","type":"2"}}]#_msdynmkt_donottrack=0"
data-lookup-name="{{Eventname}}"
data-lookup-id="{{Event_ID}}"
data-lookup-type="only_event">Add to calendar
</a> Der einzige neue Platzhalter ist hier die {{readable_event_id}}, wobei es sich hierbei um den Wert aus dem Feld „Lesbare Ereignis ID“ (msevtmgt_readableeventid) vom Ereignisdatensatz handelt. Die anderen Platzhalter haben wir bereits über den Teams-Teilnahme-Link generiert und können sie hier wiederverwenden.
Weitere Möglichkeiten
Es gibt zahllose Möglichkeiten, die E-Mails in Bezug auf das Ereignis oder die Registrierung weiter zu personalisieren. Dabei können natürlich auch benutzerdefinierte Felder ins Spiel kommen.
Denkbar ist etwa, dass jedes Ereignis einen eigenen Downloadbereich für Materialien erhält oder auch individuelle Umfragen zu Ereignissen verschickt werden sollen. Entsprechende Zugangslinks könnten auf dem Ereignis in eigenen Feldern gespeichert werden und dann in der E-Mail referenziert werden.
Den Kontaktverlauf erstellen
Wenn wir einen neuen Kontaktverlauf erstellen, können wir zwischen klassischen segmentbasierten und sogenannten auslöserbasierten Kontaktverläufen wählen. Wir benötigen für unser Szenario einen auslöserbasierten Kontaktverlauf, den wir mit dem OOB (out of the box) Auslöser „Marketing Event Registration Created“ auslösen.
Filter für den Auslöser
Optional können wir einen Filter erstellen, um zu verhindern, dass der Kontaktverlauf bei allen Ereignisregistrierungen startet. Da wir die E-Mails auf Webinare ausgerichtet haben, wäre es vielleicht sinnvoll, einen Filter auf den Ereignis-Typ „Webcast“ (oder einen eigenen Typ) auszurichten. Dann müssen wir allerdings auch dafür sorgen, dass der Ereignistyp immer korrekt gepflegt wird.
Zieleinstellungen
Um später Auswertungen auf den Kontaktverlauf tätigen zu können, können wir im Bereiche Ziele zum Beispiel das Ziel „Partizipation“ definieren. Dafür kann der ebenfalls „out of the box“ existierende Auslöser „Marketing Event Check-in“ hinterlegt werden.
Beachte dabei: Da wir einen ereignisübergreifenden Kontaktverlauf bauen, kann an dieser Stelle auch nur ereignisübergreifend ausgewertet werden. Das bedeutet auch, dass im Falle mehrerer zeitgleich offener (also noch aktiver und nicht abgeschlossener) Durchläufe des Kontaktverlaufs desselben Kontakts ein neuer Check-In für irgendein Ereignis auf alle offenen Durchläufe bezogen würde, egal für welches Ereignis der Check-In nun erstellt wurde.
Keine E-Mails an stornierte Registrierungen
Im Falle einer Stornierung soll der Kontaktverlauf gestoppt werden. Der erste Impuls sollte eigentlich sein, dies mit einem Ausschlusstrigger („Exit when a trigger occurs“) zu erreichen. Dies stellt uns jedoch vor eine Herausforderung, denn genau wie beim beschriebenen Auslöser für Check-Ins würden auch im Falle eines aktivierten „Marketing Ereignis Registration Canceled“ Auslösers alle aktiven Instanzen des Kontaktverlaufs mit demselben Kontakt gestoppt werden. Das bedeutet, dieser Ansatz kann eigentlich nur dann gewählt werden, wenn sich die Kontaktverläufe zweier Webinare zeitlich nie überschneiden werden.
Mein Ansatz zur Lösung dieses Problems ist es, alle relevanten Schritte im Kontaktverlauf mit einer Attributsverzweigung zu umrahmen und jedes Mal zu prüfen, ob der Status der Ereignisregistrierung weiterhin aktiv ist. Ist dies nicht der Fall (weil die Ereignisregistrierung deaktiviert oder gelöscht wurde), dann wird der E-Mail-Versand einfach übersprungen. Technisch gesehen bleiben so alle Instanzen des Kontaktverlaufs immer bis zum Ende offen und werden nicht vorzeitig beendet. Faktisch führt der Ansatz aber zum gewünschten Verhalten, dass ab dem Zeitpunkt einer Stornierung keine E-Mails mehr versandt werden.
Versand eines Reminders einen Tag vor Eventstart
Nach dem initialen Versand einer Anmeldebestätigung soll in unserem Fall einen Tag vor dem Ereignis ein Reminder mit den Zugangsdaten zugesandt werden. Wenn aber die Anmeldung selbst weniger als einen Tag vor Eventstart ausgeführt wird, wäre ein Reminder überflüssig und muss nicht verschickt werden. Um dies zu erreichen, können wir mit einer Attributsverzweigung prüfen, ob das Ereignis mehr als einen Tag in der Zukunft liegt.
Die ein wenig sperrige Konfiguration für die Verzweigung lautet „Ereignisstartdatum – ist nach – Relatives Datum – Morgen“. Im Klartext bedeutet das: Zum Zeitpunkt, bei dem sich der Kontakt an diesem Punkt im Kontaktverlauf befindet, ist das Ereignisstartdatum weiter in der Zukunft als einen Tag.
Im „Ja“-Zweig der Verzweigung erstellen wir nun eine Wartebedingung bis genau einen Tag vor Ereignisstart, um genau dann den Reminder zu verschicken.
Der ganze Teil für den Versand einer Remindermail (inklusive einer Prüfung des Registrierungsstatus) sieht dann wie folgt aus:
Auf den Check-In reagieren
Wenn das Ereignis stattfindet, wollen wir auf Check-In Ereignisse reagieren. Wir erinnern uns, ein Check-In wird in dem Moment erstellt, in dem ein Kontakt auf den persönlichen Teams-Teilnahme Link klickt. Dafür erstellen wir eine weitere Wartebedingung relativ zum Ereignisstartdatum. Als Zeitpunkt wählen wir hier zum Beispiel 30min vor der angegebenen Zeit.
Anschließend beginnen wir, auf das Check-In Ereignis zu warten. Dafür fügen wir eine „Wait for Trigger“ Aktion hinzu und wählen den Auslöser „Marketing Event Check-In“. Als Zeitlimit müssen wir einen statischen Wert eintragen. Dieser sollte sich an der üblichen Länge von unseren Webinaren orientieren, da er sich leider nicht pro Ereignis ändern lässt. In meinem Fall habe ich hier einen Wert von 4 Stunden eingestellt. Das bedeutet im Klartext, dass der Kontaktverlauf an diesem Punkt (also ab 30min vor Beginn des Ereignisses) für insgesamt 4 Stunden auf einen Check-In des Kontakts wartet. Erfolgt der Check-In vor oder nach diesem Zeitraum (etwa im Rahmen eines anderen Ereignisses), wird der Check-In ignoriert. Erfolgt der Check-In während der vierstündigen Wartezeit, wird der Kontaktverlauf sofort im „Ja“-Zweig fortgeführt. Erfolgt während der gesamten vier Stunden kein Check-In, geht der Kontaktverlauf nach Ablauf der 4 Stunden in den „Nein“ Zweig.
Anschließend können wir nun noch im „Ja“ und im „Nein“ Zweig eine Wartebedingung bis zum Ende des Ereignisses hinzufügen und anschließend eine Dankesmail verschicken oder eben im Fall der Nicht-Teilnahme einen Fragebogen oder Hinweis zu anderen Seminaren verschicken.
Für den eher unwahrscheinlichen Fall, dass sich derselbe Kontakt für zwei zeitlich überschneidende Ereignisse anmeldet, kommen wir hier an technische Grenzen. Denn checkt dieser Kontakt nun für eines der beiden Events ein, während auch die Kontaktverlauf-Instanz für das andere Ereignis auf ein Check-In Ereignis wartet, dann würde auch diese Instanz darauf reagieren und den Kontakt entsprechend in den „Ja“-Zweig schicken. Ich halte diesen Umstand für vertretbar, da die Situation sehr selten bis nie auftreten sollte, dass eine physische Person in zwei parallel stattfindenden Webinaren teilnehmen will.
Weitere Möglichkeiten – mit Aufgaben in Dynamics365 arbeiten
Je nachdem, ob die Teilnahme oder auch die Nicht-Teilnahme am Ereignis relevant für den Vertrieb ist, könnte im einen oder anderen Fall (oder beiden) beispielsweise eine Aufgabe erstellt werden, die dem entsprechenden Lead oder Kontakt zugeordnet wird.
Grundsätzlich können wir Aufgaben direkt im Kontaktverlauf über eine eigene Aktion erstellen. Wir sind allerdings inhaltlich eingeschränkt, da wir auf diese Weise keinen dynamischen Text (wie zum Beispiel den Namen des Ereignisses) einfügen können.
Ist dies nötig, wäre das ein perfekter Use-Case für einen benutzerdefinierten Auslöser, dem wir beliebig viele Attribute mitgeben können (etwa die ID oder den Namen des Ereignisses). Diesen Auslöser wiederum könnten wir anschließend als Startpunkt für einen Flow nutzen, der die mitgegebenen Attribute verarbeitet und die Aufgabe dann mit entsprechendem dynamischem Inhalt erstellt. Dies ist aber ein ganz eigenes Thema für einen künftigen Blogbeitrag.
Schlussbemerkung
Natürlich stellt die hier dargestellte Kontaktverlaufsdefinition nur eine Möglichkeit dar, wie ein solcher Ereignislebenszyklus aussehen kann. Der Ablauf kann je nach den üblichen Abläufen im Unternehmen angepasst oder erweitert werden. Mit den hier vorgestellten Logiken und Tools sollten jedoch sehr viele verschiedene Szenarien abbildbar sein, ohne dass dafür auch nur eine Zeile Code geschrieben werden muss.
Mir war es in diesem Ansatz wichtig, einen Weg zu finden, die Bordmittel von Dynamics Customer Insights – Journeys wirklich auszureizen und ohne das Hinzufügen von eigenem Code auszukommen. Dieser Weg eignet sich daher prinzipiell für alle Anwender, egal ob mit oder ohne Entwicklerkenntnisse. In sehr seltenen Szenarien könnte dieser Ansatz zu nicht gewolltem Verhalten führen (etwa, wenn sich Ereignisse zeitlich überschneiden).
Ein möglicher Ansatz mit dem Einsatz von eigenem Code oder Flows zur Vermeidung der genannten Risiken könnte darin bestehen, eine Verbindung zwischen der Instanz der Kontaktverläufe und der zugehörigen Ereignisregistrierung aufzubauen und dann auf Änderungen an der Ereignisregistrierung mit eigenen Algorithmen zu reagieren, um die zugehörige Instanz des Kontaktverlaufs dann zu stoppen oder die Check-In Ereignisse zu erfassen, wenn entsprechende Trigger ausgelöst werden.
Dies ist mein erster Beitrag in dieser Form. Ich freue mich über Anmerkungen, Tipps oder Fragen in den Kommentaren.
Johannes Fleischhut, Project Lead Dynamics 365 Customer Insights, KC | KAISERSTADT CONSULTING GmbH & Co. KG
***Hinweis: Der Inhalt ist zum Zeitpunkt der Erstellung korrekt. Microsoft mag in der Zwischenzeit Änderungen vorgenommen haben.***