CRM-Brücke

Sobald eine Sitzung einen Namen bekommt, landet die Aufzeichnung als Notiz an dieser Person in Ihrem CRM - am Kontakt, den es schon gibt, nicht an einem neuen.

1. Was hier passiert, in einem Satz

In dem Augenblick, in dem eine Sitzung identifiziert wird, suchen wir die Person in Ihrem CRM anhand der Kennung, die Sie uns geschickt haben, und hängen eine Notiz mit dem Link zur Aufzeichnung an.

Mehr nicht. Keine neuen Kontakte, keine neuen Deals, keine Änderung an Ihrer Pipeline. Ein CRM, das bei jedem Besuch der Preisseite ein Duplikat bekommt, ist schlechter als gar keine Integration.

Finden wir die Person nicht, passiert nichts. Sie anzulegen hieße, aus einer Browsersitzung heraus einen Datensatz in Ihr CRM zu schreiben - und eine Browsersitzung ist keine verlässliche Auskunft darüber, wer Ihre Kunden sind.

2. Der Match Key: woran wir die Person erkennen

Das ist der Teil, der zehn Minuten Aufmerksamkeit wert ist, denn hier geht eine CRM-Anbindung üblicherweise still schief.

Wir kennen den Besucher unter dem, was Ihre Seite uns gesagt hat - MousePlayer.setUserId(), eine aus Ihrem Analysewerkzeug zurückgelesene Kennung oder ein serverseitiger Identify-Aufruf. Ihr CRM kennt ihn ebenfalls unter irgendetwas. Beides muss dasselbe sein.

Wir suchen nachÄnderbar
HubSpotder E-Mail-Adresse des Kontaktsnein - der Suchendpunkt ist darauf gebaut
PipedrivePersonen per Suchbegriff, E-Mail zuerstnein
Salesforceeinem Feld, das Sie benennen, Vorgabe Emailja

Warum ausgerechnet Salesforce fragt

Salesforce-Installationen hängen selten an der E-Mail-Adresse. Ihre hängt vielleicht an Kundennummer__c oder an einer externen Kennung aus Ihrer Abrechnung. Suchten wir trotzdem nach der E-Mail, fänden wir nichts und meldeten Erfolg - die schlimmste Art von Fehlschlag, weil die Anbindung dabei lebendig aussieht.

Deshalb fragt das Formular: welches Feld am Kontakt trägt den Wert, den wir Ihnen schicken? Tragen Sie den API-Namen ein, samt __c, wenn es ein eigenes Feld ist.

Der Feldname wird gegen ein striktes Muster geprüft, bevor er in eine Abfrage gerät. Ein CRM-Feldname besteht aus Buchstaben, Ziffern und Unterstrichen - alles andere wird abgelehnt statt maskiert, denn Maskieren kann man auf subtile Weise falsch machen, Ablehnen nicht.

3. Wann sie feuert - und wann bewusst nicht

Bei der Identifikation: wenn Ihre Seite MousePlayer.setUserId() aufruft, wenn unsere Analytics-Brücke eine Kennung aus PostHog, Mixpanel oder Amplitude zurückliest, oder wenn Ihr Server den Identify-Endpunkt aufruft.

Einmal je Sitzung, nicht einmal je Seite

Wer sich anmeldet und danach elf Seiten ansieht, bekommt eine Notiz, nicht elf. Die Zeitleiste in Ihrem CRM ist ein Ort, an dem Menschen lesen.

Nicht ohne Kennung

Eine anonyme Sitzung hat nichts, woran man sie zuordnen könnte. Wir raten nicht über die IP-Adresse und hängen die Aufzeichnung nicht an denjenigen, der sich diese Adresse zufällig teilt.

Nicht, wenn Ihr CRM die Person nicht kennt

Das gilt als erledigt, nicht als fehlgeschlagen - ein Interessent, der noch nicht im CRM steht, ist der Normalfall, und ein zweiter Versuch morgen änderte daran nichts.

4. Wie die Notiz aussieht, und wo der Zugang liegt

Eine Notiz in der Zeitleiste des Kontakts: eine Zeile, dass eine Sitzung aufgezeichnet wurde, und der Link. Ihr Vertrieb klickt darauf und sieht, was die Person tatsächlich getan hat, bevor sie sich gemeldet hat.

Die Zugangsdaten

AES-256-GCM verschlüsselt gespeichert. Nach dem Speichern nie wieder angezeigt - das Feld zeigt Sternchen, und wer das Formular mit den Sternchen darin speichert, lässt den gespeicherten Wert unangetastet. Sie werden außerdem bewusst aus der internen Warteschlange herausgehalten, die die Aufgabe trägt: die Warteschlange ist gemeinsamer Zustand, und gemeinsamer Zustand ist der falsche Ort für einen Schlüssel.

Salesforce braucht drei Angaben, die anderen zwei

Salesforce meldet sich über eine Connected App mit Refresh-Token an und fragt deshalb nach Consumer Key, Secret und Refresh-Token sowie Ihrer Instanz-URL. HubSpot und Pipedrive nehmen einen einzelnen API-Token. In allen drei Fällen gehört die App Ihnen - MousePlayer betreibt keine Marketplace-App, der Sie vertrauen müssten.

5. Zoho CRM und Freshsales

Zwei weitere CRMs, und sie liegen an den entgegengesetzten Enden des Einrichtungsaufwands.

Zoho CRMFreshsales
Sie hinterlegenRechenzentrum, Client-ID, Client-Geheimnis, Refresh-TokenAPI-Schlüssel und Ihre Freshworks-Domain
Wir suchen nacheinem Feld, das Sie benennen, Vorgabe Emaileinem Feld, das Sie benennen, Vorgabe email
Die Notiz landetam Kontakt, als Note-Datensatzam Kontakt, als Notiz

Zoho lebt in einem von sechs Rechenzentren

Ein Konto liegt in com, eu, in, com.au, jp oder com.cn, und nichts am Schlüssel verrät welches. Nimmt man das falsche, antwortet Zoho mit INVALID_TOKEN - das liest sich wie ein falscher Schlüssel und schickt einen an die falsche Stelle. Genau deshalb ist das Feld eine Auswahl.

Der Self Client, einmalig

Legen Sie in der Zoho-API-Konsole einen Self Client an, erzeugen Sie ein Grant-Token für ZohoCRM.modules.ALL und ZohoSearch.securesearch.READ und tauschen Sie es einmalig gegen ein Refresh-Token. Dieses läuft nicht ab; die stündlichen Zugriffstoken werden daraus geholt und nie gespeichert.

Zoho antwortet mit 200, wenn es nein meint

Sowohl der Tokentausch als auch das Schreiben eines Datensatzes können HTTP 200 mit einem Fehler oder einem Status je Datensatz im Rumpf zurückgeben. Wir lesen den Rumpf - eine Brücke, die dem Statuscode glaubte, meldete Erfolg für eine Notiz, die nie entstanden ist.

Alle genannten Marken gehören ihren jeweiligen Inhabern. MousePlayer steht in keiner geschäftlichen Verbindung zu diesen Anbietern.