Wenn du Marketing oder Vertrieb \u00fcber 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. <\/p>\n\n
Es f\u00e4ngt mit einem einzigen Cookie an. Der Standard-Tracking-Code von HubSpot setzt ein Cookie namens \u201ehubspotutk\u201c<\/em>, um wiederkehrende Besucher zu erkennen und die Customer Journey eines Kontakts zusammenzuf\u00fcgen, noch bevor dieser \u00fcberhaupt ein Formular ausf\u00fcllt. Die \u201eIntelligent Tracking Prevention\u201c<\/a> von Safari begrenzt die Lebensdauer dieses Cookies auf sieben Tage, wenn es per JavaScript gesetzt wird \u2013 und genau so setzt HubSpot es standardm\u00e4\u00dfig. 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 \u00fcbrig bleibt, an der sich zuvor dein Lead-Formular befand. <\/p>\n\n Das alles ist kein zuk\u00fcnftiges Risiko. Es passiert bereits auf deiner Website, und genau das ist ein wichtiger Grund daf\u00fcr, dass sich die \u201eOriginal Source\u201c-<\/a> und Multi-Touch-Attributionsberichte von HubSpot weiter von der Realit\u00e4t entfernen, als den meisten Teams bewusst ist. <\/p>\n\n Das server-side Tracking von HubSpot behebt die eigentliche Ursache. Anstatt dass der Browser die Endpunkte <\/em> js.hs-scripts.com<\/em> und hsforms.net <\/em>von HubSpot direkt aufruft, \u00fcbernimmt dein eigener Server die Kommunikation im Namen des Kontakts. Diese Anleitung f\u00fchrt dich durch die Einrichtung des server-side Trackings f\u00fcr HubSpot mithilfe von Google Tag Manager und TAGGRS. <\/p>\n\n Beim clientseitigen Tracking l\u00e4uft das HubSpot-Skript im Browser des Besuchers. Es liest die ben\u00f6tigten Daten von der Seite aus, setzt die Cookies<\/em> \u201ehubspotutk\u201c<\/em> und \u201e__hstc\u201c<\/em> und ruft die Server von HubSpot direkt auf, um Seitenaufrufe zu protokollieren, Besucher zu identifizieren und Formulare zu \u00fcbermitteln. <\/p>\n\n Beim server-side Tracking wird diese Verbindung auf deinen eigenen Server verlagert. Der Browser sendet eine Anfrage an deine Domain (\u00fcber einen Google Tag Manager-Servercontainer), und dein Server leitet die relevanten Daten \u00fcber eine private, authentifizierte Verbindung an die HubSpot-API weiter. Der Browser des Besuchers kommuniziert zu keinem Zeitpunkt mit den Domains von HubSpot. <\/p>\n\n Die server-side Entsprechungen des clientseitigen Skripts von HubSpot sind die CRM-Objekte-API<\/a> f\u00fcr Kontakte und die API f\u00fcr benutzerdefinierte Verhaltensereignisse<\/a> f\u00fcr alles andere: Seiteninteraktionen, Produktansichten, das Absenden benutzerdefinierter Formulare \u2013 einfach alles, was du mit einem Kontaktdatensatz verkn\u00fcpfen m\u00f6chtest. Server-side Tracking lohnt sich besonders, wenn du deine Entscheidungen in HubSpot triffst: beim Scoring von Leads, beim Ausl\u00f6sen von Workflows, beim Berichten der Attribution an die Gesch\u00e4ftsleitung oder beim Optimieren der Werbeausgaben anhand von Kontakt- und Deal-Daten. Je mehr Gewicht du diesen Daten beimisst, desto teurer kommen dir die L\u00fccken. <\/p>\n\n Bist du noch nicht daran gew\u00f6hnt, mit Google Tag Manager zu arbeiten?<\/strong> TAGGRS bietet Anleitungen, die die Grundlagen behandeln, bevor du dich konkret mit HubSpot besch\u00e4ftigst:<\/p>\n\n <\/p>\n\n Das ist keine allgemeine Feststellung \u00e0 la \u201eBrowser sind heutzutage streng\u201c. Ein paar konkrete, aktuelle \u00c4nderungen wirken sich direkt auf das Tracking von HubSpot aus, und jede davon betrifft einen Bericht oder einen Workflow, auf den du dich bereits verl\u00e4sst. Hier erf\u00e4hrst du, was das clientseitige HubSpot-Tracking beeintr\u00e4chtigt und was dich jede dieser Beeintr\u00e4chtigungen kostet. <\/p>\n\n Das Tracking-Cookie ist begrenzt, und es ist dasjenige, auf das sich HubSpot am meisten verl\u00e4sst.<\/strong> \u201ehubspotutk\u201c<\/em> wird \u00fcber \u201edocument.cookie\u201c gesetzt, und die WebKit-eigenen Regeln zur Tracking-Verhinderung<\/a> l\u00f6schen jedes auf diese Weise gesetzte Cookie nach sieben Tagen ohne Besuch. Bei einem wohl\u00fcberlegten Kauf mit einem mehrw\u00f6chigen Recherchezyklus ist das die Regel. Der Kanal, \u00fcber den der Interessent urspr\u00fcnglich hereingekommen ist (oft ein teurer wie bezahlte Suche oder ein Webinar), geht leer aus, w\u00e4hrend das, was er am Tag der Konversion in die Adressleiste eingegeben hat (meist \u201edirekt\u201c), den ganzen Ruhm einheimst. Multipliziere das mal mit einem ganzen Quartal, und dein \u201eOriginal Source\u201c-Bericht gewichtet \u201eDirect\u201c und organische Zugriffe \u00fcberm\u00e4\u00dfig hoch, w\u00e4hrend die Kampagnen, die die eigentliche Arbeit geleistet haben, leer ausgehen. <\/p>\n\n Werbeblocker und Browser-Tracking-Schutz blockieren das Skript, nicht nur das Cookie.<\/strong> 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<\/em>, was bedeutet, dass hbspt.forms.create()<\/em> nie ausgef\u00fchrt wird und Besucher anstelle des Formulars nur ein leeres Feld<\/a> sehen. Keine Fehlermeldung, kein Fallback. Der Besucher verl\u00e4sst die Seite meist einfach, und du erf\u00e4hrst nie, dass es diesen Lead \u00fcberhaupt gab. <\/p>\n\n Apples Blockierung auf Browserebene wird ausgeweitet.<\/strong> Safari 27<\/a> f\u00fchrt 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, \u00fcber eine CDP oder \u00fcber 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. Die Nutzung von Werbeblockern ist l\u00e4ngst kein Nischenproblem mehr.<\/strong> Etwa ein Drittel der Internetnutzer nutzt irgendeine Art von Werbeblocker, und diese Zahl steigt weiter an. Kurz gesagt: Ein betr\u00e4chtlicher Teil deiner Besucher l\u00e4sst das HubSpot-Skript gar nicht erst laden. <\/p>\n\n Die Auswirkungen zeigen sich in den Bereichen, die du tats\u00e4chlich f\u00fcr deine Kampagnen nutzt.<\/p>\n\n \u201eOriginal\u201c und \u201eAktuelle Traffic-Quelle\u201c<\/a> werden anhand des Sitzungsverlaufs des Tracking-Cookies festgelegt. HubSpot versucht, einen neuen Kontaktdatensatz mit anonymen Aktivit\u00e4ten abzugleichen, die unter dem Cookie dieses Besuchers erfasst wurden. Wenn das Cookie vorzeitig zur\u00fcckgesetzt wird, geht diese fr\u00fchere Aktivit\u00e4t verloren, sodass HubSpot nichts zum Abgleichen hat und die \u201eurspr\u00fcngliche Quelle\u201c anhand der Sitzung festlegt, die gerade aktiv ist, wenn der Kontaktdatensatz erstellt wird \u2013 nicht anhand des tats\u00e4chlichen ersten Besuchs des Besuchers. <\/p>\n\n Attributionsberichte<\/a>, die einem Kanal die Generierung eines Kontakts oder eines Gesch\u00e4fts zuschreiben, st\u00fctzen sich auf denselben Interaktionsverlauf. Weniger erfasste Seitenaufrufe und Touchpoints f\u00fchren zu einer flacheren, weniger aussagekr\u00e4ftigen Attribution. Dein Marketing hat nicht aufgeh\u00f6rt zu funktionieren. HubSpot hat es einfach nicht mehr erfasst. <\/p>\n\n Benutzerdefinierte Verhaltensereignisse und E-Commerce-Events, die \u00fcber clientseitiges JavaScript ausgel\u00f6st werden, weisen jedes einzelne dieser Probleme auf. Wenn das Skript blockiert wird, wird das Event nie ausgel\u00f6st. 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. <\/p>\n\n Eines funktioniert aber auch dann noch, wenn das Cookie blockiert ist: Die Formulare von HubSpot k\u00f6nnen zum Zeitpunkt der \u00dcbermittlung UTM-Parameter direkt aus der URL der aktuellen Seite abrufen, sodass die Attribution auf Kampagnenebene f\u00fcr diese konkrete \u00dcbermittlung in der Regel erhalten bleibt. Was nicht erhalten bleibt, ist alles, was davon abh\u00e4ngt, diese \u00dcbermittlung mit fr\u00fcheren, per Cookie nachverfolgten Sitzungen des Besuchers zu verkn\u00fcpfen. <\/p>\n\n Das server-side Tracking ver\u00e4ndert, worauf du dich bei HubSpot verlassen kannst. Folgendes verbessert sich, sobald die Verbindung auf deinen eigenen Server verlagert wird: <\/p>\n\n - Formulare, die tats\u00e4chlich geladen werden \u2013<\/strong> 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\u00fcr dessen Akquise du nie zweimal bezahlen musst. Eine Formularanfrage, die von deiner eigenen Domain \u00fcber deinen Server-Container bereitgestellt wird, steht nicht auf denselben Blocklisten wie hsforms.net<\/em>, sodass Besucher mit strengen Datenschutzeinstellungen oder Werbeblockern das Formular trotzdem sehen und absenden k\u00f6nnen. <\/p>\n\n - Ein Tracking-Cookie, das l\u00e4nger als eine Woche g\u00fcltig bleibt.<\/strong> Cookies, die \u00fcber einen HTTP-Response-Header gesetzt werden, unterliegen nicht der siebent\u00e4gigen JavaScript-Beschr\u00e4nkung, die Safari f\u00fcr \u201ehubspotutk\u201c<\/em> anwendet \u2013 allerdings nur, wenn dein Server die separate CNAME- und IP-Adress-Verschleierungsschutzfunktion von WebKit umgeht, die bei Ausl\u00f6sung ebenfalls HTTP-Cookies auf sieben Tage begrenzt. - Eine Attribution, die die tats\u00e4chlichen Abl\u00e4ufe widerspiegelt.<\/strong> Da unterwegs weniger Sitzungen verloren gehen, kommen die Berichte zu \u201eOriginalquelle\u201c, \u201eLetzte Quelle\u201c und Multi-Touch der Realit\u00e4t n\u00e4her. Das ist besonders wichtig, wenn du \u00fcber dein Budget entscheidest: Eine Attribution, die bezahlte oder organische Leads zu niedrig beziffert, f\u00fchrt dazu, dass du Kan\u00e4le streichst, die eigentlich gut funktionieren. <\/p>\n\n - Zuverl\u00e4ssige benutzerdefinierte Verhaltensereignisse.<\/strong> Wenn Events server-side \u00fcber die HubSpot-API gesendet werden, hat ein Werbeblocker auf Seiten des Besuchers keinen Einfluss darauf, ob das Ereignis HubSpot erreicht.<\/p>\n\n - Mehr Kontrolle dar\u00fcber, was du \u00fcbermittelst.<\/strong> Du entscheidest genau, welche Felder wann an HubSpot weitergeleitet werden \u2013 so werden Datenminimierung und die Einhaltung der Einwilligungsvorschriften eher eine Frage der Konfiguration als des Zufalls.<\/p>\n\n - Eine schlankere Seite.<\/strong> Weniger clientseitige Skripte, die um den Hauptthread konkurrieren, bedeuten eine geringere Auswirkung auf die Ladezeit \u2013 was sowohl f\u00fcr die Konversionsrate als auch f\u00fcr die Core Web Vitals wichtig ist.<\/p>\n\n Insgesamt f\u00fchrt das dazu, dass mehr der Leads, die du ohnehin schon generierst, in HubSpot landen<\/strong> \u2013 korrekt zugeordnet und bereit f\u00fcr deine Workflows und Berichte, damit du darauf reagieren kannst. <\/p>\n\n F\u00fcr die Einrichtung des server-side Trackings f\u00fcr 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. <\/p>\n\n Hier ist die vollst\u00e4ndige Checkliste, bevor du HubSpot-Tags erstellst:<\/p>\n\n Hier ist die komplette Anleitung, von Anfang bis Ende: <\/p>\n\n 1. Starte deinen TAGGRS-Server-Container<\/strong> und verbinde ihn mit einer Subdomain deiner eigenen Domain (zum Beispiel measure.deinedomain.com<\/em>). Dadurch gelten die von deinem Server gesetzten Cookies als First-Party-Cookies und nicht als Third-Party-Cookies. <\/p>\n\n 2. \u00dcberpr\u00fcfe, ob deine Datenschicht die Daten an den Server-Container weiterleitet.<\/strong> 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\u00fcr jedes Tag, das du darauf aufbaust \u2013 einschlie\u00dflich HubSpot.<\/p>\n\n 3. Erstelle deine HubSpot-Private-App und kopiere den Zugriffstoken.<\/strong> Speichere ihn als server-side GTM-Variable und nicht als fest codierten Wert innerhalb eines Tags, damit du ihn sp\u00e4ter \u00e4ndern kannst, ohne jedes Tag bearbeiten zu m\u00fcssen, das ihn verwendet.<\/p>\n\n 4. F\u00fcge deinem Server-Container ein Tag hinzu, das die HubSpot-API aufruft.<\/strong> Such zuerst in der Community-Template Gallery von Google Tag Manager nach einem vorhandenen HubSpot-Server-Tag.<\/p>\n\n 5. Richte das Tag \u201eKontakt erstellen oder aktualisieren\u201c ein.<\/strong> Das hier sorgt daf\u00fcr, dass aus einer Formular\u00fcbermittlung 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. <\/p>\n\n F\u00fcge dann alle benutzerdefinierten Eigenschaften, die du nachverfolgen m\u00f6chtest (Details zur Lead-Quelle, Seitenpfad, Formularname), als zus\u00e4tzliche 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. <\/p>\n\n 6. Richte<\/strong> bei Bedarf die Nachverfolgung benutzerdefinierter Events ein<\/strong>. Ordne den Namen des Events und seine Eigenschaften so zu, dass sie genau mit dem \u00fcbereinstimmen, was du im obigen Einrichtungsschritt in HubSpot definiert hast. Die Namen m\u00fcssen mit dem von HubSpot generierten internen Namen \u00fcbereinstimmen, nicht mit der Anzeige-Bezeichnung, sonst wird der Event abgelehnt. <\/p>\n\n 7. F\u00fcge f\u00fcr jedes Tag Ausl\u00f6ser hinzu.<\/strong> Ein \u201eKontakt erstellen\u201c-Tag wird in der Regel bei Formularabsendungen ausgel\u00f6st, die bereits in deiner Datenschicht vorhanden sind. Ein Verhaltens-Event-Tag wird bei jedem benutzerdefinierten Event ausgel\u00f6st, das du trackst (z. B. Aufruf einer Preisseite, vollst\u00e4ndiges Ansehen eines Videos oder Hinzuf\u00fcgen zum Warenkorb bei einer mit HubSpot verbundenen E-Commerce-Integration). <\/p>\n\n 8. Teste alles im GTM-Vorschau-Modus<\/strong>, wobei die Vorschau gleichzeitig sowohl im Web- als auch im Server-Container aktiviert ist. Im Testleitfaden von TAGGRS<\/a> wird erkl\u00e4rt, wie man den Anfragefluss zwischen den beiden Containern nachverfolgt. Sende ein echtes Testformular ab und \u00fcberpr\u00fcfe, ob der Kontakt in HubSpot angezeigt wird (oder aktualisiert wird). L\u00f6se anschlie\u00dfend ein Test-Verhaltensereignis aus und \u00fcberpr\u00fcfe, ob es in der Zeitleiste des Kontakts erscheint. <\/p>\n\n 9. Lass die neue Konfiguration f\u00fcr eine kurze Zeit parallel zu deinem bestehenden HubSpot-Tracking-Code laufen<\/strong>, anstatt sie sofort zu entfernen. So kannst du die Anzahl der neu angelegten Kontakte und das Volumen der Events vergleichen, bevor du vollst\u00e4ndig umstellst, und bist abgesichert, falls in der neuen Konfiguration etwas falsch eingerichtet ist. <\/p>\n\n 10. Ver\u00f6ffentliche deinen Server und deine Web-Container<\/strong>, sobald die Tests einwandfrei verlaufen sind.<\/p>\n\n Sobald die \u00c4nderung ver\u00f6ffentlicht ist, gilt sie sofort f\u00fcr alle Besucher, und die Daten werden ab der n\u00e4chsten Formular\u00fcbermittlung \u00fcber 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 \u00e4ndert. <\/p>\n\n 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 \u2013 daher bleibt das Problem oft unbemerkt, bis ein Bericht seltsam aussieht. Das sind die Fehler, die am h\u00e4ufigsten daf\u00fcr verantwortlich sind: <\/p>\n\n Wenn deine Leads \u00fcber Google Ads kommen, sch\u00fctzt 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\u00fchrt haben \u2013 dadurch sieht dein ROAS schlechter aus, als er tats\u00e4chlich ist, und der Algorithmus optimiert auf Basis falscher Daten. \u201eClick ID Recovery\u201c<\/a> stellt die GCLID-Werte wieder her, die Safari aus den URLs entfernt, noch bevor diese dein Formular erreichen. <\/p>\n\n HubSpot erfasst GCLID standardm\u00e4\u00dfig nicht. Du ben\u00f6tigst eine benutzerdefinierte Kontakteigenschaft, deren Name mit dem URL-Parameter \u00fcbereinstimmt. Diese musst du als verstecktes Feld zu deinem Formular hinzuf\u00fcgen, und HubSpots eigene Zuordnung f\u00fcr versteckte Felder f\u00fcllt sie dann aus, wenn ein Besucher mit diesem Parameter in der URL auf die Seite gelangt. Sobald das eingerichtet ist, erkl\u00e4rt unser Leitfaden zur Behebung von GA4-ROAS-Ungenauigkeiten<\/a>, wie die gespeicherte GCLID nach Abschluss eines Gesch\u00e4fts als Offline-Conversion hochgeladen wird, und unser Leitfaden zu \u201eEnhanced Conversions\u201c<\/a> geht noch ausf\u00fchrlicher auf den Upload-Prozess ein. <\/p>\n\n Das \u201eEnhanced Tracking Script\u201c<\/a> verschleiert und verschl\u00fcsselt die Anfrage zwischen Browser und Server, wodurch mehr Ereignisse den Musterabgleich von Werbeblockern \u00fcberstehen, noch bevor sie \u00fcberhaupt deinen Server-Container erreichen.<\/p>\n\n Wenn du EU-Traffic bedienst, kombiniere diese Konfiguration mit dem Consent Mode V2<\/a>, damit die Einwilligungssignale mit den Daten den ganzen Weg bis zu HubSpot mitreisen und nicht nur bis zu den Google-Tags. In unserer DSGVO-\u00dcbersicht zum server-side Tracking<\/a> erf\u00e4hrst du mehr dar\u00fcber, was das in der Praxis bedeutet. <\/p>\n\n Das clientseitige Tracking von HubSpot wurde f\u00fcr 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\u00dfen sollten. <\/p>\n\n Wenn du diese Verbindung server-side \u00fcber den Google Tag Manager und TAGGRS herstellst, wird die Anfrage \u00fcber deine eigene Domain statt \u00fcber die von HubSpot gesendet \u2013 dort finden Ad-Blocker und Einstellungen zum Tracking-Schutz nichts, worauf sie reagieren k\u00f6nnten. Au\u00dferdem hast du so die Kontrolle dar\u00fcber, was wann an HubSpot gesendet wird, was den Datenschutzaspekt vereinfacht statt zu erschweren. <\/p>\n\nVorteile des server-side Trackings von HubSpot<\/h2>\n\n
Warum clientseitiges Tracking f\u00fcr HubSpot-Nutzer derzeit unzuverl\u00e4ssig ist<\/h2>\n\n
Wie clientseitiges Tracking die HubSpot-Attribution und die Lead-Daten beeintr\u00e4chtigt<\/h2>\n\n
Was HubSpot-Nutzer vom server-side Tracking profitieren<\/h2>\n\n
Was du brauchst, bevor du loslegst<\/h2>\n\n
\n
Schritt f\u00fcr Schritt: Einrichten des server-side HubSpot-Trackings mit Google Tag Manager<\/h2>\n\n
H\u00e4ufige Fehler, die du vermeiden solltest<\/h2>\n\n
\n
Weitere Tools, die sich gut mit deiner HubSpot-Konfiguration kombinieren lassen<\/h2>\n\n
Fazit<\/h2>\n\n