Wie man Daten einer B2B-Veranstaltung in das CRM überträgt

Das Datenübertragungsschema einer B2B-Veranstaltung in das CRM: Entitäten, IDs, Status, Felder, Einwilligungen, Duplikate und die Prüfung des übernommenen Datensatzes.

Daten von Veranstaltungen für Unternehmen (B2B, business-to-business) verlieren oft zwischen dem Veranstaltungsort und dem CRM – dem System zur Verwaltung von Kundenbeziehungen – ihre Bedeutung. Im Formular stehen Name und E-Mail, auf dem Badge erscheint eine Nummer, der Scanner erfasst eine Aktion, und im Zielsystem bleibt ein neuer Kontakt ohne erkennbare Veranstaltung, Session, Begegnung oder Einladungsquelle.

Wir bei Aventura beginnen von der anderen Seite: Wir beschreiben die Fakten, die bis zum System des Auftraggebers gelangen müssen, und vereinbaren, wie das CRM deren Empfang bestätigt. Ein solcher Vertrag ist vor der Öffnung der Registrierung erforderlich. Später sind Änderungen an Identifikatoren (IDs), Status und Feldzweck deutlich schwieriger: Die Daten kommen bereits gleichzeitig aus mehreren Punkten.

Wenn Sie eine Geschäftsveranstaltung vorbereiten und die Registrierung, die Anwesenheitsmarkierung (Check-in) und die Aktivitäten am Veranstaltungsort im Voraus mit dem System des Auftraggebers verknüpfen möchten, fordern Sie ein Arbeitstreffen zum Projekt an. Wir helfen dabei, das Datenmodell der Veranstaltung und die Anforderungen an einen gemeinsamen Test zu beschreiben. Einrichtung und Administration des CRM bleiben beim Fachteam des Auftraggebers.

Welche Daten müssen in die CRM gelangen?

Übermitteln Sie nur die Daten, die eine konkrete Aktion in der CRM unterstützen. Benennen Sie für jedes Feld und jeden Fakt im Voraus Zweck, Verantwortlichen und Empfänger. Wenn das Team nicht erklären kann, wer den Wert nutzt und was als Nächstes damit geschieht, sollte das Feld besser aus dem Formular oder dem Datenaustausch entfernt werden.

Bei einer B2B-Veranstaltung gibt es mehrere Quellen. Die Einladung liefert die Kampagne und den Zugangskanal. Die Registrierung zeigt, wer die Teilnahme angemeldet hat.

Die Anwesenheitsmarkierung bestätigt die Präsenz. Eine Session, ein Meeting oder eine Aktion am Stand fügen einen neuen Fakt hinzu. Die CRM muss diese Teile mit gemeinsamem Kontext erhalten, ist aber nicht verpflichtet, sie in einem einzigen Objekt zu speichern.

Die minimale Frage an jede Quelle lautet so:

UTM-Metriken (Urchin Tracking Module) helfen, Quelle, Kanal und Kampagne des Übergangs zu unterscheiden. Sie gehören zum Kontext der Registrierung und ersetzen nicht die Kennung der Person oder der Anmeldung. Auch die Badge-Nummer sollte kein universeller Schlüssel werden: Ihre Aufgabe ist auf ein konkretes Projekt und eine Zugangsart beschränkt.

Ein separater Artikel zur Registrierung und zu den Anforderungen des Federal Law No. 152-FZ behandelt die rechtliche und organisatorische Seite des Formulars. Hier ziehen wir eine engere Grenze: welche Entitäten und Felder den Weg bis zum übernommenen Datensatz in der CRM durchlaufen.

Fünf Entitäten statt eines überladenen Kontakts

Person, Unternehmen, Registrierung, Teilnahme und Aktivität beantworten unterschiedliche Fragen. Fasst man sie in einer Kontaktkarte zusammen und überschreibt die Felder ständig, verliert das System die Historie. Verknüpfte Datensätze bewahren die Reihenfolge der Fakten und ermöglichen es, jede Übertragung einzeln zu prüfen. So sieht das Team nicht nur den aktuellen Zustand des Kontakts, sondern auch den Weg des Teilnehmers durch eine bestimmte Veranstaltung.

Person (Person) – der Master-Datensatz des Teilnehmers. Im Master-Datensatz stehen stabile Kontaktdaten und akzeptierte Identifikatoren. Eine Person kann an mehreren Events teilnehmen, sich mehrfach registrieren und verschiedene Aktionen ausführen.

Unternehmen (Company) – die Organisation. Das Unternehmen ist nicht in allen Fällen gleich der E-Mail-Domain, daher muss die Verknüpfungsregel festgelegt werden. Eine Unternehmensdomain kann ein starkes Merkmal sein. Eine öffentliche E-Mail-Adresse, eine Tochtergesellschaft oder ein Berater erfordern eine andere Entscheidung und manchmal eine manuelle Prüfung.

Registrierung (Registration) – die Anmeldung einer Person für eine bestimmte Veranstaltung. Sie hat eine eigene ID, Event-ID, Quelle, Erstellungszeit und einen Status. Die erneute Teilnahme derselben Person an einem anderen Event erzeugt eine neue Registrierung und keine neue Person.

Teilnahme (Attendance) – der Tatsache des Anwesens. Eine Registrierung beweist keinen Besuch. Microsoft Customer Insights trennt ebenfalls Event Registration und Check-in, wobei sich der Check-in auf das gesamte Event oder eine einzelne Session beziehen kann. Daher dürfen die Felder „registriert“ und „anwesend“ nicht als Synonyme gelten.

Aktivität (Activity) – eine einzelne Aktion: der Besuch einer Session, ein Meeting, das Scannen eines Materials, ein Besuch am Stand oder ein anderer vereinbarter Fakt. Die Aktivität speichert ihre eigene ID, ihren Typ, ihre Zeit und ihren Kontext. Die HubSpot Meetings API folgt derselben Logik: Ein Meeting existiert als separate CRM-Aktivität und wird mit Kontakten und Unternehmen verknüpft.

Dieses Modell erfordert keine einheitliche Struktur in allen CRMs. In einem System wird die Registrierung ein separates Objekt, in einem anderen eine Teilnahme an einer Kampagne und die Aktivität ein Eintrag im Aktivitätsfeed. Der Sinn muss bei jeder technischen Darstellung erhalten bleiben.

Ein System von Identifikatoren für den gesamten Weg

Jedes Objekt und jeder Fakt muss eine eigene stabile ID haben. Die Quelle vergibt einen Identifikator einmal, und die nachfolgenden Systeme geben ihn weiter, ohne ihn neu zu erzeugen. Dann wird eine erneute Zustellung als Wiederholung erkannt, und das Team kann denselben Datensatz im Formular, im Austauschprotokoll und im CRM finden.

Das Arbeitsset kann Folgendes umfassen:

1. event_id – eine konkrete Veranstaltung.
2. person_id – der Master-Datensatz einer Person in einem abgestimmten Umfeld.
3. company_id – die Organisation im System des Auftraggebers oder im Austauschverzeichnis.
4. registration_id – die Anmeldung einer Person für dieses Event.
5. attendance_id – der einzelne Check-in-Fakt.
6. activity_id – eine Session, ein Meeting, ein Stand oder eine andere Aktion.
7. source_system – das System, das den Fakt erzeugt hat.
8. schema_version – die Version des Datenvertrags.

Der RFC-Standard beschreibt UUID – einen universell eindeutigen 128-Bit-Identifikator, der ohne zentrale Registrierung vergeben werden kann. Das ist praktisch, wenn Formular, mobile App und Geräte vor Ort von unterschiedlichen Systemen betreut werden. UUIDv7 unterstützt zusätzlich die zeitliche Reihenfolge, doch die konkrete Version ist zweitrangig. Entscheidend ist etwas anderes: Ein Team legt die Vergaberegeln fest, und alle Beteiligten behalten den Wert bei.

Die CloudEvents-Spezifikation liefert ein nützliches Modell für die Übertragung von Events. Das Paar source + id bestimmt ein einzelnes Event, und ein erneut gesendeter Fakt kann dieselbe ID behalten. Der Empfänger erkennt dann das Duplikat ohne Vermutungen über Name, E-Mail und Zeitpunkt.

Wichtig. Der Identifikator eines übertragenen Fakts ist nicht gleich dem Identifikator einer Person oder der event_id einer Veranstaltung. Das Event-Modell Adobe XDM ExperienceEvent trennt ausdrücklich die _id des Event-Datensatzes und die Identity einer Person. Ein Teilnehmer kann viele Aktivitäten erzeugen, und jede erhält einen eigenen Identifikator.

Bei einer Konferenz oder einem Forum ist dieser Ansatz besonders nützlich: Anmeldung, allgemeiner Einlass, Besuch von Tracks und vereinbarte Meetings kommen aus verschiedenen Teilen des Projekts, werden aber um gemeinsame event_id und person_id herum gesammelt. So kann das Team den Weg jedes Fakts prüfen, ohne verschiedene Entitäten in der Kontaktkarte zu vermischen.

Das Datenmodell der Veranstaltung muss abgestimmt werden, bevor die Dienstleister Formulare, Badges und Scanner einrichten. Fordern Sie ein Gespräch zum Datenmodell und einen vorläufigen Kostenvoranschlag an. Wir verbinden die Touchpoints der Veranstaltung in einer einzigen Leistungsbeschreibung und führen den Test gemeinsam mit dem CRM-Verantwortlichen auf Seiten des Auftraggebers durch.

Wie einigt man sich auf Status?

Ein Status muss einen Code, eine Definition, einen Verantwortlichen und zulässige Übergänge haben. Freitext wie „kam“, „nahm teil“ oder „interessierte sich“ verliert schnell an Bedeutung. Ein Verzeichnis legt fest, welcher Sachverhalt den Zustand ändert und was das CRM erhält. Getrennte Wörterbücher für Registrierung, Teilnahme und Meetings verhindern, dass ein und dasselbe Wort unterschiedliche Ereignisse bezeichnet.

Beginnen Sie mit getrennten Wörterbüchern. Registrierungsstatus dürfen nicht mit Anwesenheitsstatus und Meeting-Ergebnissen vermischt werden.

Die Bezeichnungen in der Tabelle dienen als Beispiel für die Struktur. Die endgültigen Codes wählt das Team des Auftraggebers. Existiert im CRM bereits ein Verzeichnis, passt sich der Sender über eine explizite Zuordnung daran an. Verwendet der Sender sein eigenes Wörterbuch, muss die Zuordnung jede Entsprechung und das Verhalten für einen unbekannten Wert zeigen.

Legen Sie für jeden Status vier Regeln fest:

1. Welcher beobachtbare Sachverhalt ihn setzt.
2. Wer berechtigt ist, den Wert zu ändern.
3. Ob eine Rückkehr zum vorherigen Zustand möglich ist.
4. Was bei einem verspäteten oder wiederholten Ereignis geschieht.

Beispielsweise entsteht checked_in nach einem akzeptierten Scan am Eingang. Ein erneuter Scan derselben attendance ID erzeugt keine zweite Teilnahme. Eine verspätete Stornierung der Registrierung löscht nicht die bereits bestätigte Anwesenheit, wenn die Richtlinie des Auftraggebers die Historie erhalten soll.

Ändern Sie den Wert eines bestehenden Codes nicht während der Kampagne. Fügen Sie eine neue Schemaversion hinzu und einigen Sie sich auf den Übergang. Andernfalls bedeutet ein identisches status=confirmed vor und nach der Änderung unterschiedliche Dinge.

Wie erstellt man eine Feld- und Kontextzuordnung?

Die Feldzuordnung verbindet die Quelle und das CRM auf der Ebene von Name, Typ, Pflichtcharakter, Transformation und Verhalten bei Fehlern. Eine bloße Spaltenliste reicht nicht aus. Der Empfänger muss verstehen, woher der Wert stammt und zu welcher Entität er gehört. Bei strittigen Feldern werden sofort das Verzeichnis, die Schemaversion, der Entscheidungsverantwortliche und die Reaktion des Systems bei einem falschen Wert festgehalten.

Die HubSpot Properties API zeigt gut den Unterschied zwischen Datentyp und Feldoberfläche. Zeichenkette, Datum, Zahl und Enumeration werden unterschiedlich gespeichert. Für ein Statusverzeichnis eignet sich ein begrenzter Satz von Werten, nicht ein Textfeld. Eine eigene externe ID kann in ein Feld mit Eindeutigkeitsanforderung ausgelagert werden, wenn das Ziel-CRM einen solchen Modus unterstützt.

Die minimale Feldzuordnung sieht so aus:

Der Kontext ist besonders für den Stand wichtig. Die Übermittlung eines einzelnen badge_number=1842 sagt dem Empfänger nichts. Benötigt werden Event-ID, Activity-ID, Aktionstyp, Zeit, Quelle des Scans und Person- oder Registration-ID. Wenn ein Teilnehmer ein bestimmtes Material angefordert hat, wird der Materialcode nur dann in einem separaten Feld übermittelt, wenn beim Empfänger eine abgestimmte Aktion vorliegt.

Für die Teilnahme an einer Messe muss die Zuordnung nicht nur die allgemeine Registrierung abdecken. In ihr erscheinen Zonen, Stände, Scanner und verschiedene Datenverantwortliche. Je mehr Quellen es gibt, desto wichtiger sind ein einheitliches source_system, die Schemaversion und ein Protokoll abgelehnter Datensätze.

Es ist sinnvoll, den ursprünglichen Wert neben dem transformierten zu speichern, sofern dies die Regeln zur Datenminimierung erlauben. Dann lässt sich ein strittiger Status ohne erneute Anfrage an den Veranstaltungsort klären. Die Aufbewahrungsfrist für eine solche technische Spur legt der Auftraggeber fest.

Datenminimierung und Einwilligungen

Formular und Datenaustausch sollten nur den minimalen Datensatz erheben, der für den angegebenen Zweck erforderlich ist. Jedes zusätzliche Feld erhöht den Prüfaufwand, die Fehlerzahl und die rechtliche Belastung. Das W3C WAI empfiehlt, nur das abzufragen, was für den Abschluss des Prozesses nötig ist, und klare Beschriftungen, Anweisungen und Fehlermeldungen bereitzustellen.

Wir verwenden einen einfachen Feldfilter:

1. Welche Aufgabe erfüllt das Feld bei der Veranstaltung oder im CRM?
2. Wer ist Eigentümer des Werts?
3. Welche Aktion folgt nach dem Erhalt?
4. Ist die Genauigkeit bereits bei der Registrierung erforderlich?
5. Kann der Wert später aus dem Mastersystem bezogen werden?
6. Was passiert, wenn der Teilnehmer das Feld nicht ausfüllt?

Ein Feld ohne Antwort auf die ersten drei Fragen wird in der Regel entfernt. Ein detailliertes Branchenprofil kann beispielsweise für das Programm nützlich sein, sollte aber nicht erhoben werden, wenn niemand die Segmentierung nutzt und die Daten den Weg des Teilnehmers nicht beeinflussen.

Einwilligung und sonstige Rechtsgrundlage der Verarbeitung werden nach Zwecken gestaltet. Der Europäische Datenschutzausschuss (EDPB) verlangt in seinen Leitlinien zur Datenschutz-Grundverordnung (DSGVO) eine konkrete, informierte und eindeutige Einwilligung sowie die Möglichkeit, nachzuweisen, wie und wann sie erteilt wurde. Dieses Dokument ersetzt keine russische rechtliche Prüfung, liefert aber ein nützliches Prinzip: Die Teilnahme an der Veranstaltung und nachfolgende Marketingkommunikation sollten nicht in einem einzigen ununterscheidbaren Feld verborgen werden.

Wenn die Verarbeitung auf einer Einwilligung beruht, können im Datenvertrag erforderlich sein:

• Zweck;
• Version des Textes;
• Zeitpunkt;
• Quelle der Schnittstelle;
• Ergebnis der Auswahl;
• Möglichkeit der Änderung oder des Widerrufs im System des Auftraggebers.

Der Service Google Customer Match zeigt eine weitere Grenze auf. Die Werbeplattform arbeitet mit den eigenen Online- und Offline-Daten des Unternehmens und verlangt für partnerschaftliche Uploads von Nutzerdaten aus dem Europäischen Wirtschaftsraum Einwilligungssignale. Die operative Übertragung der Registrierung in das CRM bedeutet an sich noch keine Erlaubnis für jede werbliche Aktivierung. Diesen Zweck, den Umfang der Felder und die Rechtsgrundlage stimmt der Auftraggeber gesondert ab.

Wie vermeidet man Duplikate?

Die Deduplizierung umfasst die Suche nach einem ähnlichen Datensatz und eine separate Entscheidung darüber, was mit ihm geschehen soll. Eine exakte Übereinstimmung einer stabilen externen ID kann automatisch verarbeitet werden. Eine wahrscheinliche Übereinstimmung bei Name, Unternehmen, E-Mail oder Telefon erfordert Regeln, Prioritäten und manchmal eine manuelle Prüfung. Vor dem Start legt das Team fest, welche Merkmale als exakt gelten und welche einen Datensatz nur zur Prüfung weiterleiten.

Salesforce unterscheidet zwischen Suchregeln für Übereinstimmungen (matching rules) und Regeln für die Behandlung von Duplikaten (duplicate rules). Erstere finden Kandidaten, letztere bestimmen die Aktion: warnen, zulassen oder das Anlegen blockieren. Diese Logik ist auch außerhalb einer konkreten Plattform nützlich.

Bewährte Reihenfolge:

1. Datensatz anhand von external_person_id suchen, falls dieser bereits bekannt ist.
2. Die exakte normalisierte E-Mail prüfen, sofern die Richtlinie des Kunden sie als Suchschlüssel zulässt.
3. Weitere bestätigte Identifikatoren prüfen.
4. Kandidaten anhand einer Kombination schwächerer Merkmale bilden.
5. Bei einem mehrdeutigen Ergebnis nicht automatisch zusammenführen.
6. Einen neuen Master-Datensatz erst nach Durchlaufen der Regeln anlegen.
7. Eine neue Registrierung oder Aktivität damit verknüpfen, ohne die Historie zu überschreiben.

Die Normalisierung erfolgt bei Sender und Empfänger auf dieselbe Weise. Die Telefonnummer wird in ein abgestimmtes Format gebracht. Die E-Mail wird von Leerzeichen bereinigt und nach der vereinbarten Regel zur Groß-/Kleinschreibung geprüft. Der Firmenname sollte nicht als einziger Schlüssel verwendet werden: Schreibvarianten und die Struktur einer Unternehmensgruppe führen zu falschen Übereinstimmungen.

Eine separate Aufgabe ist die Idempotenz, also das sichere erneute Senden. Wenn die Verbindung nach dem Schreiben abbricht, kennt der Sender möglicherweise das Ergebnis nicht und wiederholt die Anfrage. Dieselbe registration_id, attendance_id oder activity_id muss das bestehende Objekt aktualisieren oder bestätigen und darf kein zweites anlegen.

Prüfen Sie mindestens vier Fälle:

Ein Master-Datensatz bedeutet nicht eine einzige Zeile für alles. Der Master bezieht sich auf die Person. Registrierungen, Teilnahmen und Aktivitäten bleiben eine separate Historie rund um diese Person.

Verantwortliche für Versand, Empfang und Fehler

Der Datenaustausch muss zwei benannte Verantwortliche haben: einen auf der Senderseite und einen auf der Empfängerseite. Der erste ist für Vollständigkeit, Format und erneute Zustellung verantwortlich. Der zweite für das CRM-Schema, die Annahmeregeln, die Verknüpfungen und das Kontrolllesen des Datensatzes. Ohne dieses Paar verstehen die Teams nicht, wer einen Fehler behebt und wer den erneuten Empfang bestätigt.

Die Aufteilung lässt sich so festhalten:

Es braucht ein Fehlerprotokoll mit record_id, Zeitpunkt, Schema-Version, Ursachencode und Status der erneuten Verarbeitung. Personenbezogene Daten im Protokoll werden auf das notwendige Minimum reduziert. Dem Team genügt in der Regel eine technische ID und ein Verweis auf den geschützten Datensatz.

Wir bei Aventura implementieren nicht das CRM des Auftraggebers und legen keine Regeln darin fest. Wir können die Datenquellen der Veranstaltung beschreiben, das Übertragungsformat mit dem zuständigen Team abstimmen und prüfen, dass das Szenario am Veranstaltungsort die erwarteten Daten liefert. Für das empfangende Modell und die Zugriffsrechte ist der CRM-Verantwortliche des Auftraggebers zuständig.

Wie prüft man den Weg bis zur Eröffnung der Registrierung?

Ein End-to-End-Test beginnt mit der Aktion des Teilnehmers und endet mit dem Kontrolllesen des Datensatzes aus dem CRM. Zwischen diesen Punkten prüft das Team separat die Quelle, die Übertragung und die Verarbeitung der Daten. Die Antwort einer Programmierschnittstelle oder das Erscheinen einer Datei im Ordner bestätigt nur einen Zwischenschritt. Ein Datensatz gilt als angenommen, wenn im Zielsystem die Schlüsselfelder, Verknüpfungen, der Eigentümer und der Status geprüft wurden.

Bereiten Sie ein separates Testevent und einen Satz synthetischer Datensätze ohne Daten realer Personen vor. Führen Sie anschließend die Szenarien der Reihe nach aus.

1. Normale Registrierung. Füllen Sie das Formular aus, speichern Sie den UTM-Kontext und prüfen Sie die registration ID.
2. Bekannte Person. Wiederholen Sie die Registrierung mit der person ID eines bestehenden Test-Master-Datensatzes.
3. Check-in. Scannen Sie das Test-Badge und prüfen Sie die separate attendance ID.
4. Session oder Stand. Erstellen Sie activity_id mit event_id, Aktionstyp, Zeitpunkt occurred_at und Quellsystem source_system.
5. Meeting. Übergeben Sie Zeit, Eigentümer, Ergebnis und Verknüpfungen mit Person und Unternehmen.
6. Erneute Zustellung. Senden Sie denselben Datensatz-Identifikator noch einmal und stellen Sie sicher, dass kein Duplikat erstellt wurde.
7. Fehler im Verzeichnis. Übergeben Sie einen unbekannten Status und prüfen Sie, dass das System den Datensatz nach der vereinbarten Regel abgelehnt hat.
8. Fehlendes Pflichtfeld. Stellen Sie sicher, dass der Grund des Fehlers für den Absender verständlich ist.
9. Kontrolllesen. Lesen Sie den CRM-Datensatz und vergleichen Sie Werte, Verknüpfungen und Eigentümer mit der Erwartung.
10. Korrektur. Wiederholen Sie den Datensatz nach der Korrektur ohne Verlust der ursprünglichen ID und Historie.

Speichern Sie für jede Prüfung das erwartete und das tatsächliche Ergebnis. Eine Abweichung muss einen Eigentümer, eine Frist zur Behebung und einen erneuten Durchlauf desselben Szenarios erhalten.

Die Lastprüfung von Registrierung und Check-in löst eine benachbarte Aufgabe: Hält die Umgebung den geplanten Strom aus und was passiert bei einem Ausfall. Ihre Szenarien sind im Artikel über die Lastprobe von Registrierung und Check-in zusammengestellt. Hier ist das Abnahmekriterium auf den Sinn und die Integrität eines einzelnen Datensatzes auf dem gesamten Weg begrenzt.

Nach dem Test unterzeichnen beide Seiten die Version der Feldkarte, des Statusverzeichnisses und der Testergebnisse. Eine Änderung eines dieser Dokumente erfordert eine erneute Prüfung der betroffenen Szenarien.

Checkliste für die Startbereitschaft

Der Rahmen ist bereit, wenn alle Projektbeteiligten die Entitäten, Felder und das Kriterium für einen akzeptierten Datensatz gleich verstehen. Diese Checkliste kann in der abschließenden gemeinsamen Sitzung vor der Öffnung des Formulars verwendet werden. Sie wiederholt nicht die gesamte Feldkarte, sondern hält Entscheidungen fest, ohne die das Team Duplikate und strittige Status nur schwer kontrollieren kann.

1. Die Veranstaltung hat eine stabile event_id, und Registrierung, Teilnahme und Aktivität haben eigene Identifikatoren.
2. Person, Unternehmen, Registrierung, Teilnahme und Aktivität sind inhaltlich voneinander getrennt.
3. Status haben Codes, Definitionen, Verantwortliche und eine Wörterbuchversion.
4. Die Feldkarte legt Typen, Pflichtfelder, Transformationen, Kampagne und Fehler fest.
5. Regeln für die Suche nach Übereinstimmungen, erneutes Senden und die Behandlung von Duplikaten sind separat abgestimmt.
6. Die Verantwortlichen für Senden, Empfang und Fehlerkorrektur sind benannt.
7. Der End-to-End-Test umfasst einen normalen Datensatz, eine bekannte Person, ein Duplikat, einen Fehler und ein Kontrolllesen.
8. Der CRM-Verantwortliche hat die Verknüpfungen und die Schemaversion vor der Öffnung der Registrierung bestätigt.

Diese Bereitschaft ersetzt nicht die weitere Arbeit mit den Daten. Den allgemeinen Zusammenhang von Events mit dem kommerziellen System behandelt der Beitrag zu Event-led Growth und dem Funnel. Die Reihenfolge der Übergabe von Aktionen an Marketing und Vertrieb nach dem Event ist im Artikel zu SLA Follow-up beschrieben. Der aktuelle Rahmen endet in dem Moment, in dem das CRM einen prüfbaren Datensatz mit den richtigen Verknüpfungen und dem richtigen Verantwortlichen übernommen hat.

Wir bei Aventura können die Datenpunkte der Veranstaltung in einer einheitlichen technischen Spezifikation zusammenführen, den Weg des Gastes durchlaufen und gemeinsam mit dem Team des Auftraggebers einen Test durchführen. Fordern Sie eine Projektbesprechung und einen vorläufigen Kostenvoranschlag an. Im Gespräch legen wir die Datenquellen der Veranstaltung, die Grenzen unserer Arbeit und die Abnahmebeteiligten seitens des CRM fest.

Quellen

• European Data Protection Board - Guidelines 05/2020 on consent
• CloudEvents specification 1.0.2
• HubSpot - CRM Properties API Guide
• HubSpot - Meetings API Guide
• Google Analytics - URL builders and UTM parameters
• IETF - RFC 9562: Universally Unique IDentifiers
• Microsoft Learn - View and manage event attendance
• Salesforce Trailhead - Resolve and Prevent Duplicate Data
• Adobe Experience Platform - XDM ExperienceEvent class
• W3C WAI - Forms Tutorial
• Google Ads - About Customer Match