Salesforce erfasst einen Klick, wenn Salesforce den Link verschickt hat. Account Engagement schreibt die URLs in seinen eigenen E-Mails um und ordnet den Klick einem Prospect zu, und Custom Redirects erweitern das auf Links, die du anderswo einfügst. Das ist die gesamte native Geschichte.
Alles andere, was dein Unternehmen verschickt, erzeugt keinen Klick im CRM. Das Follow-up eines Vertriebsmitarbeiters aus dem eigenen Postfach, eine SMS-Sequenz, ein QR-Code auf einem Messestand, eine bezahlte Anzeige, ein Partner-Newsletter: alles unsichtbar. Um diese Lücke zu schließen, braucht es einen getrackten Link, den du selbst besitzt, und einen Webhook, der nach Salesforce schreibt - die interessanten Entscheidungen betreffen dabei, was geschrieben wird, nicht wie es gesendet wird. Für dasselbe Problem in einem anderen CRM behandelt HubSpot-Link-Klicks in der Kontakt-Timeline, wie diese Integration aussieht.
Was die nativen Tools abdecken
Zwei Mechanismen, beide beschränkt auf von Salesforce versendete Nachrichten.
Das E-Mail-Link-Tracking in Account Engagement schreibt jeden Link über eine Tracker-Subdomain um, sodass der Klick dem Prospect zugeordnet wird, an den die Mail ging. Es funktioniert gut - und nur dort.
Custom Redirects gehen einen Schritt weiter: Du erzeugst eine getrackte URL und setzt sie in einem Banner, einem Social-Post oder einem Dokument ein, und Klicks erscheinen als Prospect-Aktivität. Zwei Einschränkungen bestimmen, wie nützlich das ist. Wiederholte Klicks desselben Prospects werden innerhalb eines Zeitfensters gedrosselt, sodass die Zählung bewusst keine reine Gesamtsumme ist. Und die Zuordnung zu einem namentlich bekannten Prospect hängt davon ab, dass der Besucher bereits identifiziert ist, was bei kaltem Traffic bedeutet, dass der Klick ohne zugehörige Person erfasst wird.
Marketing Cloud hat sein eigenes Modell für getrackte Links, nach demselben Prinzip: Es misst, was es selbst verschickt hat.
Das ist keine Kritik. Es ist ein Geltungsbereich, und wer diesen Geltungsbereich kennt, weiß genau, wofür der dritte Weg gebraucht wird.
Die Lücke und wie man sie schließt
Das Muster ist kurz. Dein Shortener löst bei jedem Klick einen Webhook aus. Ein Endpoint empfängt ihn, verifiziert ihn und macht daraus einen Datensatz.
Drei Implementierungsentscheidungen bestimmen, ob das ein Wochenendprojekt bleibt oder ein wiederkehrender Incident wird.
Ein Platform Event veröffentlichen statt direkt zu schreiben. Ein Platform Event entkoppelt die Aufnahme von der Entscheidung, was ein Klick bedeutet. Die Integration veröffentlicht Link_Click__e; Subscriber entscheiden, ob das einen Campaign Member aktualisiert, einen Task erzeugt oder für diese Kampagne gar nichts auslöst. Wenn Marketing seine Meinung ändert, was ein Klick auslösen soll, bearbeitest du einen Flow statt einen Webhook-Consumer.
Die Signatur verifizieren, bevor du dem Payload vertraust. Der Endpoint ist per Definition öffentlich. Den HMAC gegen das Shared Secret prüfen, bei Abweichung ablehnen, und die Contact-ID niemals ungeprüft aus dem Request-Body übernehmen, ohne sie gegen etwas zu validieren, das du selbst ausgestellt hast.
Über die Klick-ID deduplizieren. Webhook-Zustellungen wiederholen sich nach einem Timeout, wodurch derselbe Klick zweimal ankommen kann. Die ID speichern und den Schreibvorgang idempotent machen; die Alternative ist ein Kontakt mit vier identischen Klick-Datensätzen von einem einzigen Tap. Rate-Limits und Idempotenz bei einer Link-API behandelt dieselbe Disziplin auf der ausgehenden Seite.
Einen Klick ehrlich einer Person zuordnen
Genau hier lügen Integrationen gerne leise, deshalb lohnt es sich, es klar auszusprechen.
Ein Klick trägt genau das, was der Link mitgegeben hat. Wenn du einen eigenen Kurzlink pro Empfänger erzeugt hast, identifiziert der Payload den Empfänger, und du kannst mit Zuversicht in dessen Datensatz schreiben. Wenn vierhundert Personen denselben Link erhalten haben, hast du vierhundert Klicks und keine Namen, und kein noch so cleverer Join holt sie zurück.
Entscheide also je Use Case. Outbound-Sequenzen und Eins-zu-eins-Follow-ups rechtfertigen einen Link pro Empfänger, erzeugt über die API, wenn die Nachricht in die Warteschlange kommt. Breit angelegte Kampagnen rechtfertigen das nicht, und Zählungen auf Kampagnenebene sind dort der ehrliche Output: Klicks pro Kampagne, pro Medium, pro Link, verknüpft mit dem Campaign-Objekt statt mit einzelnen Personen. URL-Shortener für B2B-Vertriebsteams behandelt, wo sich die Variante pro Empfänger auszahlt.
Das eine, was du nicht tun solltest, ist Identität aus einer IP-Adresse oder einer zeitlichen Koinzidenz abzuleiten. Das liegt oft genug falsch, um einen Pipeline-Report zu verfälschen, und in Europa ist es eine Verarbeitungsentscheidung, die du lieber nicht verteidigen musst.
Baust du das gerade auf? Elidos Webhooks signieren jede Zustellung und wiederholen mit Backoff, und die Webhook-Referenz in den Docs listet die Klick-Payload-Felder auf, die du mappen wirst.
Was geschrieben wird, und wohin
Vier Ziele, in aufsteigender Reihenfolge dessen, wie viel Nachdenken sie erfordern.
- Ein Custom-Click-Object.
Click__cmit Lookups auf Contact und Campaign, plus Link, Kampagnenparameter, Land, Gerät und Zeitstempel. Das ist die dauerhafte Wahl; Reporting bleibt schnell und der Activity-Feed bleibt lesbar. - Der Campaign-Member-Status. Einen Member beim ersten Klick von Sent auf Responded zu verschieben, ist hier die mit Abstand nützlichste Automatisierung, weil sie jeden Kampagnenreport speist, den du bereits hast.
- Ein Task, sparsam eingesetzt. Nützlich bei hochwertigen Links, bei denen ein Vertriebsmitarbeiter den Touchpoint in seinem Feed sehen soll. Als Standard katastrophal, weil ein paar tausend Tasks pro Woche alles andere begraben.
- Ein Rollup-Feld auf dem Kontakt. Datum des letzten Klicks und ein laufender Zähler sind günstig zu pflegen und beantworten die meisten Fragen eines Vertriebsmitarbeiters, ohne dass eine Related List geöffnet werden muss.
Kampagnenparameter in Felder mappen, statt sie später zu parsen. utm_campaign auf dem Klick-Datensatz ist das, was einem Sales-Ops-Report erlaubt, nach Kampagne zu gruppieren, ohne irgendetwas zu joinen.
Volumen ist die Grenze, mit der niemand plant
Klicks kommen in Schüben. Ein Newsletter an fünfzigtausend Personen erzeugt in den ersten zehn Minuten tausende Klicks, und eine naive Integration macht aus jedem einzelnen einen API-Aufruf.
Salesforce-Orgs haben tägliche API-Kontingente, und das Veröffentlichen von Platform Events hat eigene Quoten. Diese Rechnung lohnt sich vor dem Launch, nicht während dessen: Spitzen-Klicks pro Minute gegen dein Kontingent, wobei die Antwort meist lautet, dass Schreibvorgänge pro Klick nicht hineinpassen.
Drei Auswege, in Reihenfolge der Präferenz. Nur Threshold-Events veröffentlichen, sodass das CRM vom dritten Klick erfährt statt von jedem einzelnen. Auf deiner Seite aggregieren und stündliche Zusammenfassungen für Reporting auf Kampagnenebene schreiben. Oder batchen: Events kurz zurückhalten und gesammelt einfügen. Webhooks versus Polling beim Click-Tracking behandelt die Abwägung, wenn das Volumen ganz in die andere Richtung spricht.
Ich habe das genau einmal scheitern sehen, um 9 Uhr morgens an einem Launch-Tag, und der Fix unter Druck ist immer grober als der Fix, der im Voraus entworfen wurde.
Es testen, bevor du ihm vertraust
Fünf Prüfungen. Einen signierten Test-Klick senden und bestätigen, dass daraus ein Datensatz mit zugeordneter Kampagne wird. Denselben Klick zweimal senden und einen einzigen Datensatz bestätigen. Einen Klick für einen unbekannten Kontakt senden und bestätigen, dass er als nicht zugeordnete Zeile landet statt einen Fehler zu werfen. Einen Payload mit falscher Signatur wiederholen und eine Ablehnung bestätigen. Dann eine echte Kampagne bei geringem Volumen laufen lassen und die Zählung des Shorteners mit der Datensatzzahl für denselben Zeitraum abgleichen; eine Abweichung von ein paar Prozent sind sich einpendelnde Zustell-Retries, eine Abweichung von dreißig Prozent ist ein Bug.
Die Cornerstone-Serie lesen
Dieser Beitrag gehört zum Integrations-Cluster. URL-Shortener für Marketer ist der Cornerstone für die Reporting-Seite, und Webhooks für Link-Events behandelt die Payload-Formen im Detail.
Verwandte Beiträge
Häufig gestellte Fragen
Verfolgt Salesforce Link-Klicks nativ?
Es verfolgt Klicks auf Links, die es selbst versendet hat. Account Engagement schreibt Links in seinen E-Mails über eine Tracker-Subdomain um und erfasst den Klick beim Prospect, und Custom Redirects erweitern das auf Links, die du anderswo platzierst. Alles, was außerhalb dieser Tools verschickt wird, etwa aus dem eigenen Postfach eines Vertriebsmitarbeiters, eine SMS-Kampagne oder ein gedruckter Code, erzeugt in Salesforce überhaupt keinen Klick.
Was ist ein Custom Redirect in Account Engagement?
Ein getrackter Link, der innerhalb von Account Engagement erzeugt wird und einen Klick als Aktivität auf dem Prospect-Datensatz erfasst. Er eignet sich für Banner-Anzeigen, Social-Posts und anderswo gehostete Dateien. In der Praxis zählen zwei Einschränkungen: Wiederholte Klicks desselben Prospects werden innerhalb eines kurzen Zeitfensters gedrosselt, und der Link identifiziert eine Person nur, wenn der Besucher bereits einen Cookie trägt.
Wie bekomme ich Kurzlink-Klicks in Salesforce?
Indem du vom Shortener einen Webhook an Salesforce sendest und daraus einen Datensatz schreibst. Das saubere Muster besteht darin, ein Platform Event zu veröffentlichen und einen Subscriber entscheiden zu lassen, was damit geschieht, sodass der Klick als Zeile eines Custom Objects, als Task oder als Statusänderung eines Campaign Members landet, ohne dass deine Integration wissen muss, welches davon. Signatur verifizieren, über die Klick-ID deduplizieren und unter Last batchen.
Lässt sich ein Klick einem bestimmten Kontakt zuordnen?
Nur wenn der Link für diesen Kontakt eindeutig war. Ein einzelner Kampagnen-Link, auf den vierhundert Personen klicken, ergibt vierhundert anonyme Klicks, und nichts im Payload ändert daran etwas. Erzeuge einen Link pro Empfänger, wenn Attribution auf Personenebene zählt, und akzeptiere Reporting auf Kampagnenebene, wenn nicht.
Sollten Klicks als Tasks oder als Custom Object abgebildet werden?
Ein Custom Object, sobald das Volumen real wird. Tasks sind bequem, weil sie auf der Activity-Timeline auftauchen, werden aber bei ein paar tausend Zeilen pro Woche zu Rauschen und blähen den Speicherbedarf auf. Ein Custom-Click-Object mit Lookup auf Contact und Campaign hält das Reporting schnell und erlaubt Rollup-Zählungen, ohne den Activity-Feed anzufassen.
Stößt das Klick-Volumen an Salesforce-API-Limits?
Ja, und zwar schnell. Eine stark frequentierte Kampagne erzeugt mehr Klicks pro Stunde, als eine kleine Org an täglichem API-Kontingent hat, weshalb ein API-Aufruf pro Klick genau der Fehler ist, den es zu vermeiden gilt. Vor dem Senden aggregieren, Threshold-Events statt jedes einzelnen Klicks veröffentlichen, oder nach Zeitplan batchen.
Elido testen
URL einfügen, kurzer Link in Sekunden
Kein Konto nötig. Link bleibt 30 Tage aktiv. Konto erstellen, um ihn dauerhaft zu behalten.
Kostenlos, keine Anmeldung erforderlich · 2 pro Tag