HubSpot-Tracking auf server-side: Vollständige Einrichtungsanleitung

Wenn du Marketing oder Vertrieb über HubSpot abwickelst, sind deine Lead-Daten nur so gut wie das Tracking, das sie speist. Und dieses Tracking hat ein Problem: Der Browser macht ihm einen Strich durch die Rechnung.

Es fängt mit einem einzigen Cookie an. Der Standard-Tracking-Code von HubSpot setzt ein Cookie namens „hubspotutk“, um wiederkehrende Besucher zu erkennen und die Customer Journey eines Kontakts zusammenzufügen, noch bevor dieser überhaupt ein Formular ausfüllt. Die „Intelligent Tracking Prevention“ von Safari begrenzt die Lebensdauer dieses Cookies auf sieben Tage, wenn es per JavaScript gesetzt wird – und genau so setzt HubSpot es standardmäßig. Werbeblocker und die strengen Datenschutzeinstellungen in Firefox, Edge und Safari gehen noch einen Schritt weiter. Sie blockieren das HubSpot-Skript und die darin eingebetteten Formulare komplett, sodass manchmal nichts als eine leere Stelle an der Stelle übrig bleibt, an der sich zuvor dein Lead-Formular befand.

Das alles ist kein zukünftiges Risiko. Es passiert bereits auf deiner Website, und genau das ist ein wichtiger Grund dafür, dass sich die „Original Source“- und Multi-Touch-Attributionsberichte von HubSpot weiter von der Realität entfernen, als den meisten Teams bewusst ist.

Das server-side Tracking von HubSpot behebt die eigentliche Ursache. Anstatt dass der Browser die Endpunkte js.hs-scripts.com und hsforms.net von HubSpot direkt aufruft, übernimmt dein eigener Server die Kommunikation im Namen des Kontakts. Diese Anleitung führt dich durch die Einrichtung des server-side Trackings für HubSpot mithilfe von Google Tag Manager und TAGGRS.

Vorteile des server-side Trackings von HubSpot

Beim clientseitigen Tracking läuft das HubSpot-Skript im Browser des Besuchers. Es liest die benötigten Daten von der Seite aus, setzt die Cookies „hubspotutk“ und „__hstc“ und ruft die Server von HubSpot direkt auf, um Seitenaufrufe zu protokollieren, Besucher zu identifizieren und Formulare zu übermitteln.

Beim server-side Tracking wird diese Verbindung auf deinen eigenen Server verlagert. Der Browser sendet eine Anfrage an deine Domain (über einen Google Tag Manager-Servercontainer), und dein Server leitet die relevanten Daten über eine private, authentifizierte Verbindung an die HubSpot-API weiter. Der Browser des Besuchers kommuniziert zu keinem Zeitpunkt mit den Domains von HubSpot.

Die server-side Entsprechungen des clientseitigen Skripts von HubSpot sind die CRM-Objekte-API für Kontakte und die API für benutzerdefinierte Verhaltensereignisse für alles andere: Seiteninteraktionen, Produktansichten, das Absenden benutzerdefinierter Formulare – einfach alles, was du mit einem Kontaktdatensatz verknüpfen möchtest.

Einfach ausgedrückt: Alles, was das HubSpot-Skript heute im Browser macht, hat ein server-side Pendant. Du verzichtest also nicht auf Funktionen, wenn du sie verlagerst, sondern änderst lediglich, wo die Arbeit stattfindet. Für ein Marketingteam bedeutet das in der Praxis, dass die Daten, die in eure Listen, Workflows und Berichte einfließen, vollständiger ankommen und nicht mehr davon abhängen, ob der Browser des jeweiligen Besuchers mitgespielt hat.

Server-side Tracking lohnt sich besonders, wenn du deine Entscheidungen in HubSpot triffst: beim Scoring von Leads, beim Auslösen von Workflows, beim Berichten der Attribution an die Geschäftsleitung oder beim Optimieren der Werbeausgaben anhand von Kontakt- und Deal-Daten. Je mehr Gewicht du diesen Daten beimisst, desto teurer kommen dir die Lücken.

Bist du noch nicht daran gewöhnt, mit Google Tag Manager zu arbeiten? TAGGRS bietet Anleitungen, die die Grundlagen behandeln, bevor du dich konkret mit HubSpot beschäftigst:

Warum clientseitiges Tracking für HubSpot-Nutzer derzeit unzuverlässig ist

Das ist keine allgemeine Feststellung à la „Browser sind heutzutage streng“. Ein paar konkrete, aktuelle Änderungen wirken sich direkt auf das Tracking von HubSpot aus, und jede davon betrifft einen Bericht oder einen Workflow, auf den du dich bereits verlässt. Hier erfährst du, was das clientseitige HubSpot-Tracking beeinträchtigt und was dich jede dieser Beeinträchtigungen kostet.

Das Tracking-Cookie ist begrenzt, und es ist dasjenige, auf das sich HubSpot am meisten verlässt. „hubspotutk“ wird über „document.cookie“ gesetzt, und die WebKit-eigenen Regeln zur Tracking-Verhinderung löschen jedes auf diese Weise gesetzte Cookie nach sieben Tagen ohne Besuch.

Die Obergrenze sinkt speziell auf 24 Stunden, wenn ein Besucher über einen Link mit Abfrageparametern auf deiner Website landet, der von einer Domain stammt, die Safari als „Cross-Site-Tracker“ eingestuft hat – genau das Muster, das hinter den meisten Klicks auf bezahlte Anzeigen steckt. Ein potenzieller Kunde, der sich zwei Wochen vor dem Ausfüllen eines Formulars informiert hat, wird bei seiner endgültigen Konversion als neuer Erstbesucher angezeigt, da das Cookie, das seine früheren Sitzungen miteinander verknüpft hat, bereits Tage zuvor abgelaufen ist.

Bei einem wohlüberlegten Kauf mit einem mehrwöchigen Recherchezyklus ist das die Regel. Der Kanal, über den der Interessent ursprünglich hereingekommen ist (oft ein teurer wie bezahlte Suche oder ein Webinar), geht leer aus, während das, was er am Tag der Konversion in die Adressleiste eingegeben hat (meist „direkt“), den ganzen Ruhm einheimst. Multipliziere das mal mit einem ganzen Quartal, und dein „Original Source“-Bericht gewichtet „Direct“ und organische Zugriffe übermäßig hoch, während die Kampagnen, die die eigentliche Arbeit geleistet haben, leer ausgehen.

Werbeblocker und Browser-Tracking-Schutz blockieren das Skript, nicht nur das Cookie. Im HubSpot-Community-Forum gibt es mehrere offene Threads zu diesem Thema: Der erweiterte Tracking-Schutz von Firefox und die strenge Tracking-Verhinderung von Edge blockieren Anfragen an hsforms.net, was bedeutet, dass hbspt.forms.create() nie ausgeführt wird und Besucher anstelle des Formulars nur ein leeres Feld sehen. Keine Fehlermeldung, kein Fallback. Der Besucher verlässt die Seite meist einfach, und du erfährst nie, dass es diesen Lead überhaupt gab.

Apples Blockierung auf Browserebene wird ausgeweitet. Safari 27 führt die Blockierung von IP-Bereichen auf Netzwerkebene ein und nimmt CDPs wie Segment und Tealium in seine Liste der Fingerprinting-Skripte auf. Wenn du Tracking-Daten, die an HubSpot gesendet werden sollen, über eine CDP oder über ein Skript-Tag leitest, das Safari als Fingerprinting-Tool einstuft, kann der Zugriff auf Referrer-Daten und Abfrageparameter verloren gehen, noch bevor die Daten HubSpot erreichen.

Mit anderen Worten: Die Daten dazu, „woher dieser Lead stammt“, werden bereits im Browser entfernt, bevor HubSpot sie überhaupt zu Gesicht bekommt. Da etwa jeder vierte Besucher mit Safari surft, ist das ein großer, wachsender und besonders kaufwilliger Teil deiner Zielgruppe, der aus dem Blickfeld verschwindet – genau die Käufer von Apple-Geräten, die viele B2B- und Premium-Marken am liebsten ihrer Kundenbasis zuordnen möchten.

Die Nutzung von Werbeblockern ist längst kein Nischenproblem mehr. Etwa ein Drittel der Internetnutzer nutzt irgendeine Art von Werbeblocker, und diese Zahl steigt weiter an. Kurz gesagt: Ein beträchtlicher Teil deiner Besucher lässt das HubSpot-Skript gar nicht erst laden.

Wie clientseitiges Tracking die HubSpot-Attribution und die Lead-Daten beeinträchtigt

Die Auswirkungen zeigen sich in den Bereichen, die du tatsächlich für deine Kampagnen nutzt.

„Original“ und „Aktuelle Traffic-Quelle“ werden anhand des Sitzungsverlaufs des Tracking-Cookies festgelegt. HubSpot versucht, einen neuen Kontaktdatensatz mit anonymen Aktivitäten abzugleichen, die unter dem Cookie dieses Besuchers erfasst wurden. Wenn das Cookie vorzeitig zurückgesetzt wird, geht diese frühere Aktivität verloren, sodass HubSpot nichts zum Abgleichen hat und die „ursprüngliche Quelle“ anhand der Sitzung festlegt, die gerade aktiv ist, wenn der Kontaktdatensatz erstellt wird – nicht anhand des tatsächlichen ersten Besuchs des Besuchers.

Attributionsberichte, die einem Kanal die Generierung eines Kontakts oder eines Geschäfts zuschreiben, stützen sich auf denselben Interaktionsverlauf. Weniger erfasste Seitenaufrufe und Touchpoints führen zu einer flacheren, weniger aussagekräftigen Attribution. Dein Marketing hat nicht aufgehört zu funktionieren. HubSpot hat es einfach nicht mehr erfasst.

Benutzerdefinierte Verhaltensereignisse und E-Commerce-Events, die über clientseitiges JavaScript ausgelöst werden, weisen jedes einzelne dieser Probleme auf. Wenn das Skript blockiert wird, wird das Event nie ausgelöst. Jeder Workflow oder jede Lead-Bewertung, die auf diesem Event basiert, bleibt einfach stehen, ohne etwas zu tun, und es gibt keinen Fehler, der dir sagt, warum.

Eines funktioniert aber auch dann noch, wenn das Cookie blockiert ist: Die Formulare von HubSpot können zum Zeitpunkt der Übermittlung UTM-Parameter direkt aus der URL der aktuellen Seite abrufen, sodass die Attribution auf Kampagnenebene für diese konkrete Übermittlung in der Regel erhalten bleibt. Was nicht erhalten bleibt, ist alles, was davon abhängt, diese Übermittlung mit früheren, per Cookie nachverfolgten Sitzungen des Besuchers zu verknüpfen.

Was HubSpot-Nutzer vom server-side Tracking profitieren

Das server-side Tracking verändert, worauf du dich bei HubSpot verlassen kannst. Folgendes verbessert sich, sobald die Verbindung auf deinen eigenen Server verlagert wird:

- Formulare, die tatsächlich geladen werden – das ist der Punkt auf dieser Liste, der sich am direktesten auf den Umsatz auswirkt. Ein blockiertes Formular ist ein Lead, den du nie zu Gesicht bekommst und für dessen Akquise du nie zweimal bezahlen musst. Eine Formularanfrage, die von deiner eigenen Domain über deinen Server-Container bereitgestellt wird, steht nicht auf denselben Blocklisten wie hsforms.net, sodass Besucher mit strengen Datenschutzeinstellungen oder Werbeblockern das Formular trotzdem sehen und absenden können.

- Ein Tracking-Cookie, das länger als eine Woche gültig bleibt. Cookies, die über einen HTTP-Response-Header gesetzt werden, unterliegen nicht der siebentägigen JavaScript-Beschränkung, die Safari für „hubspotutk“ anwendet – allerdings nur, wenn dein Server die separate CNAME- und IP-Adress-Verschleierungsschutzfunktion von WebKit umgeht, die bei Auslösung ebenfalls HTTP-Cookies auf sieben Tage begrenzt.

Um hier den vollen Nutzen zu erzielen, muss dein Server auf einer echten First-Party-Subdomain mit einem IP-Bereich laufen, der mit dem deiner Hauptwebsite übereinstimmt – das wird im Abschnitt zur Einrichtung weiter unten behandelt. Der zuverlässigste Weg, diese Übereinstimmung zu gewährleisten, ist, deinen Server-Container über einen Cloudflare Worker mit demselben Ursprung wie deine Hauptwebsite zu leiten – also über einen Pfad wie yourdomain.com/metrics statt über eine separate Subdomain –, da die IP-Übereinstimmungsprüfung von Safari überhaupt nicht zum Tragen kommt, sobald alles wirklich denselben Ursprung hat.

- Eine Attribution, die die tatsächlichen Abläufe widerspiegelt. Da unterwegs weniger Sitzungen verloren gehen, kommen die Berichte zu „Originalquelle“, „Letzte Quelle“ und Multi-Touch der Realität näher. Das ist besonders wichtig, wenn du über dein Budget entscheidest: Eine Attribution, die bezahlte oder organische Leads zu niedrig beziffert, führt dazu, dass du Kanäle streichst, die eigentlich gut funktionieren.

- Zuverlässige benutzerdefinierte Verhaltensereignisse. Wenn Events server-side über die HubSpot-API gesendet werden, hat ein Werbeblocker auf Seiten des Besuchers keinen Einfluss darauf, ob das Ereignis HubSpot erreicht.

- Mehr Kontrolle darüber, was du übermittelst. Du entscheidest genau, welche Felder wann an HubSpot weitergeleitet werden – so werden Datenminimierung und die Einhaltung der Einwilligungsvorschriften eher eine Frage der Konfiguration als des Zufalls.

- Eine schlankere Seite. Weniger clientseitige Skripte, die um den Hauptthread konkurrieren, bedeuten eine geringere Auswirkung auf die Ladezeit – was sowohl für die Konversionsrate als auch für die Core Web Vitals wichtig ist.

Insgesamt führt das dazu, dass mehr der Leads, die du ohnehin schon generierst, in HubSpot landen – korrekt zugeordnet und bereit für deine Workflows und Berichte, damit du darauf reagieren kannst.

Was du brauchst, bevor du loslegst

Für die Einrichtung des server-side Trackings für HubSpot ist kein Neuaufbau erforderlich. Das meiste davon machst du nur einmal, und einige Elemente hast du vielleicht schon, wenn du GA4 server-side nutzt.

Hier ist die vollständige Checkliste, bevor du HubSpot-Tags erstellst:

• Ein Google Tag Manager-Konto mit einem Web-Container und einem Server-Container. Wenn du noch keine Erfahrung mit GTM hast, fang am besten mit dem Einsteigerleitfaden an.
  
• Eine funktionierende Datenschicht auf deiner Website oder zumindest ein GA4-Konfigurations-Tag, das grundlegende Seiten- und Event-Daten an deinen Server-Container weiterleitet. Die Anleitung zur server-side Einrichtung von TAGGRS führt dich Schritt für Schritt durch die Einrichtung dieser Verbindung, da die meisten HubSpot-Tags im Server-Container auf Daten angewiesen sind, die bereits über diesen Weg dort ankommen.
  
• Ein TAGGRS-Server-Container, der mit einer First-Party-Subdomain auf deiner eigenen Domain bereitgestellt wird. Erstelle ein kostenloses Konto, um loszulegen; die kostenlose Stufe umfasst bis zu 10.000 Anfragen pro Monat, was für die meisten Ersteinrichtungen ausreicht.
  
• Ein Zugriffstoken für eine private HubSpot-App. HubSpot hat seine alten API-Schlüssel am 30. November 2022 außer Kraft gesetzt. Erstelle eine private App unter „Einstellungen“ > „Integrationen“ > „Private Apps“ und erteile ihr nur die Berechtigungsbereiche, die du tatsächlich benötigst: „crm.objects.contacts.write“ und „crm.objects.contacts.read“ für Kontaktdatensätze sowie „analytics.behavioral_events.send“, falls du benutzerdefinierte Verhaltensereignisse sendest. Wenn du Event-Definitionen auch über die API statt über die Benutzeroberfläche erstellen oder bearbeiten möchtest, ist dafür ein separater Bereich erforderlich: behavioral_events.event_definitions.read_write. Die Anleitung zu privaten Apps von HubSpot beschreibt die genauen Schritte. Kopiere das Token, sobald es generiert wurde. HubSpot zeigt dir den vollständigen Wert danach nicht mehr an.
  
• Wenn du benutzerdefinierte Verhaltensereignisse sendest, musst du die Ereignisdefinitionen zuerst in HubSpot erstellen. HubSpot benötigt die Definition des Ereignisses und seiner Eigenschaften, bevor es ein über die API gesendetes Ereignis akzeptiert. Du kannst dies über „Datenverwaltung“ > der „Ereignisverwaltung“ in der Benutzeroberfläche vornehmen oder über die Ereignisdefinitions-API, falls du es lieber per Skript umsetzen möchtest.
  
• Eine Einwilligungslösung, die deinen Server-Container abdeckt – nicht nur das HubSpot-eigene Banner. Das integrierte Einwilligungsbanner von HubSpot blockiert lediglich HubSpot-Cookies und HubSpot-eigene Integrationen. Es hat keinen Zugriff auf einen benutzerdefinierten GTM-Server-Container, daher musst du dafür sorgen, dass deine Einwilligungsmanagement-Plattform ihr Signal direkt an GTM weiterleitet. Sowohl die Einrichtung des Consent Mode bei TAGGRS als auch die Anleitung zur CookieConfirm-Integration zeigen, wie diese Verbindung in der Praxis funktioniert.

Schritt für Schritt: Einrichten des server-side HubSpot-Trackings mit Google Tag Manager

Hier ist die komplette Anleitung, von Anfang bis Ende:

1. Starte deinen TAGGRS-Server-Container und verbinde ihn mit einer Subdomain deiner eigenen Domain (zum Beispiel measure.deinedomain.com). Dadurch gelten die von deinem Server gesetzten Cookies als First-Party-Cookies und nicht als Third-Party-Cookies.

2. Überprüfe, ob deine Datenschicht die Daten an den Server-Container weiterleitet. Bei den meisten Konfigurationen geschieht dies durch das Senden eines GA4-Konfigurationsereignisses aus dem Web-Container; der Server-Container hat dann Zugriff auf dieselben Ereignisdaten für jedes Tag, das du darauf aufbaust – einschließlich HubSpot.

3. Erstelle deine HubSpot-Private-App und kopiere den Zugriffstoken. Speichere ihn als server-side GTM-Variable und nicht als fest codierten Wert innerhalb eines Tags, damit du ihn später ändern kannst, ohne jedes Tag bearbeiten zu müssen, das ihn verwendet.

4. Füge deinem Server-Container ein Tag hinzu, das die HubSpot-API aufruft. Such zuerst in der Community-Template Gallery von Google Tag Manager nach einem vorhandenen HubSpot-Server-Tag.

5. Richte das Tag „Kontakt erstellen oder aktualisieren“ ein. Das hier sorgt dafür, dass aus einer Formularübermittlung ein Kontaktdatensatz wird. Du solltest mindestens eine E-Mail-Variable aus deiner Datenschicht der Anfrage zuordnen, da HubSpot anhand der E-Mail-Adresse entscheidet, ob ein neuer Kontakt angelegt oder ein bestehender aktualisiert wird.

Füge dann alle benutzerdefinierten Eigenschaften, die du nachverfolgen möchtest (Details zur Lead-Quelle, Seitenpfad, Formularname), als zusätzliche Felder im selben Request-Body hinzu. Was auch immer du hier zuordnest, wird deinem Vertriebsteam und in deinen Berichten angezeigt. Es lohnt sich also, mehr als nur das absolute Minimum zuzuordnen, wenn du schon dabei bist.

6. Richte bei Bedarf die Nachverfolgung benutzerdefinierter Events ein. Ordne den Namen des Events und seine Eigenschaften so zu, dass sie genau mit dem übereinstimmen, was du im obigen Einrichtungsschritt in HubSpot definiert hast. Die Namen müssen mit dem von HubSpot generierten internen Namen übereinstimmen, nicht mit der Anzeige-Bezeichnung, sonst wird der Event abgelehnt.

7. Füge für jedes Tag Auslöser hinzu. Ein „Kontakt erstellen“-Tag wird in der Regel bei Formularabsendungen ausgelöst, die bereits in deiner Datenschicht vorhanden sind. Ein Verhaltens-Event-Tag wird bei jedem benutzerdefinierten Event ausgelöst, das du trackst (z. B. Aufruf einer Preisseite, vollständiges Ansehen eines Videos oder Hinzufügen zum Warenkorb bei einer mit HubSpot verbundenen E-Commerce-Integration).

8. Teste alles im GTM-Vorschau-Modus, wobei die Vorschau gleichzeitig sowohl im Web- als auch im Server-Container aktiviert ist. Im Testleitfaden von TAGGRS wird erklärt, wie man den Anfragefluss zwischen den beiden Containern nachverfolgt. Sende ein echtes Testformular ab und überprüfe, ob der Kontakt in HubSpot angezeigt wird (oder aktualisiert wird). Löse anschließend ein Test-Verhaltensereignis aus und überprüfe, ob es in der Zeitleiste des Kontakts erscheint.

9. Lass die neue Konfiguration für eine kurze Zeit parallel zu deinem bestehenden HubSpot-Tracking-Code laufen, anstatt sie sofort zu entfernen. So kannst du die Anzahl der neu angelegten Kontakte und das Volumen der Events vergleichen, bevor du vollständig umstellst, und bist abgesichert, falls in der neuen Konfiguration etwas falsch eingerichtet ist.

10. Veröffentliche deinen Server und deine Web-Container, sobald die Tests einwandfrei verlaufen sind.

Sobald die Änderung veröffentlicht ist, gilt sie sofort für alle Besucher, und die Daten werden ab der nächsten Formularübermittlung über deine eigene Domain weitergeleitet. Von da an besteht die laufende Arbeit lediglich darin, Tags und Einwilligungsregeln zu pflegen. Du musst nicht mehr jedes Mal ein clientseitiges Skript debuggen, wenn ein Browser seine Datenschutzrichtlinien ändert.

Häufige Fehler, die du vermeiden solltest

Wenn bei einer server-side HubSpot-Konfiguration etwas schiefgeht, wird meist kein Fehler gemeldet. Die Tags scheinen zu funktionieren, aber die Daten kommen entweder gar nicht bei HubSpot an oder sind fehlerhaft – daher bleibt das Problem oft unbemerkt, bis ein Bericht seltsam aussieht. Das sind die Fehler, die am häufigsten dafür verantwortlich sind:

• Benutzerdefinierte Verhaltensereignisse senden, bevor sie in HubSpot definiert wurden. HubSpot lehnt jedes Ereignis ab, das es nicht bereits erkennt. Das bedeutet: Das Tag wird zwar ausgelöst, es wird aber nichts erfasst, und es gibt keinen offensichtlichen Fehler, der dir die Ursache aufzeigen könnte. Definiere das Ereignis und seine Eigenschaften daher jedes Mal zuerst in HubSpot.
• Fehlende oder falsche Bereiche im Token der privaten App. Ein Token ohne den richtigen Geltungsbereich führt nicht zu einem offensichtlichen Fehler. Das Tag wird als „ausgelöst“ angezeigt, während HubSpot die Anfrage stillschweigend ablehnt, sodass Kontakte oder events nie erscheinen. Überprüfe den tatsächlichen Antwortcode im Vorschau-Modus des Server-Containers, anstatt dich auf den Status „ausgelöst“ zu verlassen.
• Zum Zeitpunkt der Auslösung des Tags ist keine E-Mail-Adresse des Besuchers verfügbar. Anhand der E-Mail-Adresse entscheidet HubSpot, ob ein bestehender Kontakt aktualisiert oder ein neuer angelegt wird. Fehlt diese Angabe, schlägt der Vorgang entweder komplett fehl oder es entsteht ein doppelter Kontakt, für den es keinen Abgleich gibt – was deine Datenbank mit der Zeit unbemerkt überfüllt. Stell sicher, dass die E-Mail-Variable ausgefüllt ist, bevor das Tag ausgeführt wird.
• Alte und neue Tracking-Systeme laufen parallel, ohne dass ein Plan zur Bereinigung vorliegt. Beide ein paar Wochen lang laufen zu lassen, ist sinnvoll, um sie zu vergleichen, aber wenn beide auf unbestimmte Zeit weiterhin Kontakte und events erstellen, kommt es zu Doppelzählungen und alle Berichte, die auf diesen Daten basieren, werden aufgebläht. Entscheide dich von vornherein, welche Konfiguration deine „Quelle der Wahrheit“ ist, und schalte die andere aus, sobald du den Zahlen vertraust.
• Angenommen, das server-side Cookie überschreitet automatisch die Sieben-Tage-Frist. Das funktioniert nur, wenn deine Subdomain nicht (über DNS-CNAME) auf eine Domain eines Drittanbieters verweist und der IP-Bereich deines Servers mit dem deiner Hauptwebsite übereinstimmt. Wenn eine dieser beiden Bedingungen nicht erfüllt ist, wendet Safari wieder dieselbe Sieben-Tage-Beschränkung an, der du server-side entgehen wolltest – du hast also den ganzen Einrichtungsaufwand, profitierst aber nicht von den Vorteilen der Attribution. Das Routing über eine Cloudflare-Workers-Konfiguration mit derselben Herkunft ist der zuverlässigste Weg, um die Übereinstimmung zu gewährleisten.
• Weitergabe personenbezogener Daten vor der Einholung der Einwilligung. Server-side hast du mehr Kontrolle darüber, was du sendest – aber nur, wenn du die Einwilligungsprüfung tatsächlich in die Auslösebedingungen jedes Tags einbaust. Die Architektur erzwingt die Einwilligung nicht für dich, und wenn du davon ausgehst, dass sie es tut, wird aus einer datenschutzkonformen Konfiguration unbemerkt eine nicht konforme.
• Keine Datenschicht oder eine inkonsistente. Jedes Tag hier ist darauf angewiesen, dass die Daten in einer vorhersehbaren Form beim Server-Container ankommen. Wenn sich Namen von Events oder Parameterschlüssel von Seite zu Seite ändern, werden die Tags ohne ersichtlichen Grund nicht mehr ausgelöst, und du musst das Tag debuggen, obwohl das eigentliche Problem weiter oben in der Kette liegt. Leg eine einheitliche Namensgebung fest, bevor du darauf aufbaust.

Weitere Tools, die sich gut mit deiner HubSpot-Konfiguration kombinieren lassen

Wenn deine Leads über Google Ads kommen, schützt diese Funktion direkt deine Anzeigenauswertungen. Die GCLID ist das Tag, mit dem Google einen Klick einer Conversion zuordnet. Wenn Safari sie aus der URL entfernt, kann Google Ads nicht erkennen, welche Klicks zu Kunden geführt haben – dadurch sieht dein ROAS schlechter aus, als er tatsächlich ist, und der Algorithmus optimiert auf Basis falscher Daten. „Click ID Recovery“ stellt die GCLID-Werte wieder her, die Safari aus den URLs entfernt, noch bevor diese dein Formular erreichen.

HubSpot erfasst GCLID standardmäßig nicht. Du benötigst eine benutzerdefinierte Kontakteigenschaft, deren Name mit dem URL-Parameter übereinstimmt. Diese musst du als verstecktes Feld zu deinem Formular hinzufügen, und HubSpots eigene Zuordnung für versteckte Felder füllt sie dann aus, wenn ein Besucher mit diesem Parameter in der URL auf die Seite gelangt. Sobald das eingerichtet ist, erklärt unser Leitfaden zur Behebung von GA4-ROAS-Ungenauigkeiten, wie die gespeicherte GCLID nach Abschluss eines Geschäfts als Offline-Conversion hochgeladen wird, und unser Leitfaden zu „Enhanced Conversions“ geht noch ausführlicher auf den Upload-Prozess ein.

Das „Enhanced Tracking Script“ verschleiert und verschlüsselt die Anfrage zwischen Browser und Server, wodurch mehr Ereignisse den Musterabgleich von Werbeblockern überstehen, noch bevor sie überhaupt deinen Server-Container erreichen.

Wenn du EU-Traffic bedienst, kombiniere diese Konfiguration mit dem Consent Mode V2, damit die Einwilligungssignale mit den Daten den ganzen Weg bis zu HubSpot mitreisen und nicht nur bis zu den Google-Tags. In unserer DSGVO-Übersicht zum server-side Tracking erfährst du mehr darüber, was das in der Praxis bedeutet.

Fazit

Das clientseitige Tracking von HubSpot wurde für eine Browser-Welt entwickelt, die es eigentlich gar nicht mehr gibt. Zwischen Safaris Sieben-Tage-Cookie-Begrenzung, Werbeblockern, die das Skript komplett entfernen, und Browsern, die immer mehr Teile des Marketing-Stacks als Fingerprinting-Risiko einstufen, bedeutet das Verlassen auf den Browser allein, dass du Kontakte verlierst, die verbleibenden falsch zuordnest und events verpasst, die eigentlich in deine Lead-Scores einfließen sollten.

Wenn du diese Verbindung server-side über den Google Tag Manager und TAGGRS herstellst, wird die Anfrage über deine eigene Domain statt über die von HubSpot gesendet – dort finden Ad-Blocker und Einstellungen zum Tracking-Schutz nichts, worauf sie reagieren könnten. Außerdem hast du so die Kontrolle darüber, was wann an HubSpot gesendet wird, was den Datenschutzaspekt vereinfacht statt zu erschweren.

Bist du bereit, loszulegen? Erstelle ein kostenloses TAGGRS-Konto oder vereinbare einen Termin für eine Demo, um deine individuelle HubSpot-Konfiguration zu besprechen.

FAQ

Was ist server-side Tracking bei HubSpot?

Server-side Tracking für HubSpot bedeutet, dass die Daten, die normalerweise direkt vom Browser eines Besuchers an die HubSpot-Server gesendet würden, zunächst über deinen eigenen Server geleitet werden. Anstatt dass das HubSpot-Skript direkt js.hs-scripts.com oder hsforms.net aufruft, empfängt dein Server das Ereignis und leitet es über eine authentifizierte Verbindung an die CRM- und Events-APIs von HubSpot weiter. Das Ergebnis sind Daten, die HubSpot auch dann erreichen, wenn Werbeblocker oder Datenschutz-Einstellungen des Browsers das standardmäßige clientseitige Skript blockiert hätten.

Unterstützt HubSpot server-side Tracking von Haus aus?

Nicht so, wie es die meisten Leute meinen. Der eigene Tracking-Code, die Formulare und das Einwilligungsbanner von HubSpot sind von Grund auf clientseitig ausgelegt, und die nativen Integrationen werden über die CRM-API synchronisiert und nicht über einen server-side Tag-Manager. Um echtes server-side Tracking zu erreichen, kombinieren die meisten Teams einen Google Tag Manager-Servercontainer mit den „Private App“-Zugriffstoken von HubSpot sowie dessen CRM-Objekt- und Custom Behavioral Events-APIs und nutzen dabei einen Hosting-Anbieter wie TAGGRS, um den Servercontainer auszuführen.

Wie wirkt sich das auf die Lead- und Kontakt-Attribution in HubSpot aus?

Im Allgemeinen verbessert es die Situation. Die Berichte „Original Source“, „Latest Source“ und die Attributionsberichte von HubSpot sind darauf angewiesen, dass ein Tracking-Cookie über mehrere Sitzungen eines Besuchers hinweg erhalten bleibt. Wenn dieses Cookie durch Safaris ITP auf sieben Tage begrenzt oder durch einen Werbeblocker komplett blockiert wird, verliert HubSpot den Zusammenhang zwischen der anfänglichen Recherche eines Besuchers und seiner späteren Formularübermittlung. Server-side Tracking in Kombination mit einer korrekt konfigurierten First-Party-Subdomain verlängert die Lebensdauer dieser Identität, was bedeutet, dass mehr Kontakte dem Kanal zugeordnet werden, über den sie tatsächlich gekommen sind.

Ist das server-side Tracking bei HubSpot DSGVO-konform?

Ja, wenn die Einrichtung unter Berücksichtigung der Einwilligung erfolgt. Da die Daten deinen eigenen Server durchlaufen, bevor sie HubSpot erreichen, hast du die volle Kontrolle darüber, was weitergeleitet wird. Das erleichtert die Anwendung des Grundsatzes der Datenminimierung und die Überprüfung des Einwilligungsstatus eines Besuchers, bevor personenbezogene Daten deinen Server verlassen. Das HubSpot-eigene Einwilligungsbanner erstreckt sich nicht auf einen benutzerdefinierten Server-Container, daher benötigst du weiterhin deine Einwilligungsmanagement-Plattform, um deren Signal direkt an dein Google Tag Manager-Setup weiterzuleiten, wie im obigen Abschnitt zur Einrichtung beschrieben.

Musst du den Standard-Tracking-Code von HubSpot entfernen?

Nicht sofort. Es ist sicherer, beide Varianten ein paar Wochen lang parallel laufen zu lassen. So kannst du die Kontakterstellung, das Volumen der Events und die Attribution zwischen den beiden Setups vergleichen, bevor du dich festlegst. Sobald du den server-side-Zahlen vertraust, kannst du entscheiden, ob du den clientseitigen Code komplett entfernen oder eine abgespeckte Version davon für Dinge wie das HubSpot-Chat-Widget beibehalten möchtest, das weiterhin auf das im Browser ausgeführte Besucher-Identifikationstoken angewiesen ist.