Welche Tracking-Daten Sie mitschicken, wenn Sie einen UTM-Link in den Chat einfügen

Die volle Adresszeile ist noch kein versandfertiger Link

Marketing schickt die Landingpage in den Kanal. Support klebt die URL aus der Kundenmail ins Ticket. Entwicklung schreibt den Repro-Schritt in den Thread. In allen drei Fällen ist die billigste Bewegung dieselbe: Adresszeile markieren, kopieren, einfügen. Die Leiste zeigt die vollständige URL des aktuellen Dokuments. Nach dem WHATWG-URL-Modell gehören mindestens Schema, Host, Pfad, Query (hinter ?) und Fragment (hinter #) dazu. Das Fragment geht standardmäßig nicht ins HTTP – das steht in der vorigen Notiz. Die Query steht in der Anfragezeile und wandert mit der Zwischenablage mit.

Die Query ist oft kein Geschäftsbedarf. Sie sind über eine getrackte Mail gekommen, über eine bezahlte Anzeige oder über eine Social-Karte, die selbst ein Klickkennzeichen angehängt hat. Die Seite braucht /produkt/42. In der Leiste steht /produkt/42?utm_source=sommer-mailer&utm_medium=email&utm_campaign=sommer-sale&fbclid=…. Für die Analytics ist das ein zuordenbarer Besuch. Für die nächste Person, die die Zeichenkette liest, ist es ein Nebenprofil, das nicht ins Ticket gehört: aus welcher Kampagne Sie kamen, ob Sie gerade eine Anzeige geklickt haben, ob der Mailversender dieser Empfängerzeile eine Nummer gegeben hat.

HTTPS schützt nur den Hop vor Mithören. Es löscht weder Adresszeile noch Browserverlauf, Chatprotokoll, Screenshot oder Zugriffs-Log. Die OWASP-Notiz zur Informationspreisgabe über Query-Strings ist eindeutig: Auch auf einem verschlüsselten Kanal erscheint die Query in Referer, Web-Logs, geteilten Systemen, Browserhistorie, Caches und bei Blick über die Schulter. Vor dem Versand lautet die Frage nicht „ist diese Site sicher“, sondern „trägt dieses Fragezeichen Kennzeichen, die diesen Tab nicht verlassen dürfen“.

UTM benennt die Kampagne, eine Klick-ID benennt diesen einen Klick

Beide Arten sitzen oft auf derselben URL. Sie tun verschiedene Arbeit und leaken verschiedene Dinge. Die erste Art ist ein Kampagnen-Tag, das Sie (oder die Werbeplattform) absichtlich geschrieben haben. Die Google-Analytics-Hilfe nennt sie Campaign Parameters und gibt das Standardbeispiel: https://www.example.com/?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale. Die Dokumentation verlangt: Wenn Sie Parameter setzen, sollen utm_source, utm_medium und utm_campaign zusammenstehen. Erweiterungen sind utm_id, utm_term, utm_content und utm_source_platform. Werte unterscheiden Groß- und Kleinschreibung: utm_source=google und utm_source=Google werden im Bericht zwei Zeilen.

Diese Tags kodieren in der Regel keine einzelne Person. Sie beschreiben Kanal und Kampagne: welcher Newsletter, welcher Sommerschlussverkauf, der obere oder der untere Link. Trotzdem leakt das Weiterleiten nach außen die interne Mediastruktur. Die Gegenseite liest, welche Kampagne Sie gerade fahren und ob der Klick Mail oder Paid war, und kann daraus den Akquiseweg schätzen. Für Wettbewerb oder eine unbeteiligte Drittpartei ist das mehr, als „diese Seite öffnen“ verlangt.

Die zweite Art ist ein Klickkennzeichen, das Anzeigen- oder Mailplattform selbst anhängt. Häufige Namen: Google Ads gclid, Display & Video 360 dclid, im iOS-Umfeld gbraid / wbraid, Meta fbclid, Microsoft Advertising msclkid, X twclid und Mail-Tokens wie mc_eid. Ihr Zweck ist, „diesen einen Klick“ an die eigenen Ausspielungsdaten zu nähen, nicht Ihnen einen lesbaren Satz zu geben. Der Wert ist für Empfängerinnen und Empfänger undurchsichtig, für die Plattform lesbar. Wer eine Kette mit fbclid oder gclid weiterreicht, gibt ein verknüpfbares Klickcredential aus der Hand. Tokens wie mc_eid liegen näher an „diese Mail ging an diese Empfängerzeile“.

Es gibt eine dritte Schicht: hauseigene Attributions- oder Share-Parameter. Shops und Content-Seiten hängen oft spm, scm, pvid, share_token oder refer_share_id an; im deutschsprachigen Handel kommen dazu Affiliate-Tags und interne Empfehlungsschlüssel. Das ist nicht Googles UTM-Spezifikation. Es macht aus einer „normalen Produktseite“ trotzdem eine Spur, wer geteilt hat und von wo. Eine Regel, die nur utm_* löscht, lässt diese Schicht stehen.

Wohin die Query nach dem Einfügen wandert

CWE-598 – aktueller Titel: Use of HTTP Request With Sensitive Query String – schreibt den Fehler so: Sensible Daten liegen in der Query. Sie erscheinen dann in der Browserhistorie, reisen über Referer zu anderen Sites, landen in Web-Logs oder in weiteren Aufzeichnungen. Der Eintrag wurde in der Version 4.20 im April 2026 umbenannt, damit klar ist: Nicht nur GET trägt eine Query. POST, PUT und DELETE können das ebenfalls. Die Abhilfe ist konkret: Sensible Daten gehören in Body oder Header, nicht in die Query.

Die meisten Marketing-Parameter sind keine Passwörter und keine Sitzungstoken. Die Angriffsfläche ist dieselbe. Fügen Sie die volle URL in den Messenger ein, entstehen mindestens diese Kopien: der Nachrichtenspeicher des Chat-Anbieters, die lokale Historie der Gegenseite und – bei Weiterleitung – der Speicher des nächsten Hops. Öffnet jemand den Link, schreibt das Access-Log der Zielseite eine Anfragezeile, die die Parameter noch trägt. Lädt die Seite danach ein Dritt-Skript oder ein Bild, kann die volle URL zusätzlich im Referer zu einem Anzeigen- oder Analytics-Host wandern. OWASPs „geteilte Systeme“ sind intern alltäglich: Tickets, Confluence, Fehlerüberwachung, Session-Replay. Ein Link, der nur dem Repro dienen sollte, wird dort im Klartext durchsuchbar.

Deshalb beantwortet „die Site nutzt HTTPS“ die Versandfrage nicht. HTTPS erschwert es einem Beobachter auf dem Pfad, den Klartext zu lesen. Es hindert Sie nicht, denselben Klartext ins nächste System zu kleben. Unter den realen CWE-598-Fällen waren eine Kamera, die das Passwort in die Query schrieb, und ein Kommunikationsprodukt, das ein Access-Token per GET schickte. Das ist dieselbe Fehlerklasse, nur schwerer. UTM und Klick-IDs sind meist milder. Der Mechanismus ist identisch: Was hinter dem Fragezeichen steht, kopieren Menschen und protokollieren Systeme.

Der Referer kann den Query-Teil an Dritte weiterreichen

Kopieren und Einfügen ist ein aktiver Versand. Es gibt einen passiven: Nach dem Öffnen sagt der Browser späteren Anfragen nach Default-Politik, „woher ich komme“. Der Standardname des Headers ist Referer (ein r fehlt). Die MDN-Notiz zum Referer und zur Privatsphäre nutzt ein bekanntes Beispiel: Eine Passwort-Reset-Seite mit Social-Links im Footer – ein Klick nach draußen kann die tokenhaltige Adresse an das soziale Netz übergeben. Ein Dritt-Bild auf der Seite kann die aktuelle volle URL auf demselben Weg an den Bild-Host schicken.

Browser entscheiden mit Referrer-Policy, wie viel sie senden. Chrome und verwandte Engines nutzen standardmäßig strict-origin-when-cross-origin: Gleicher Ursprung darf die volle URL (Pfad und Query) tragen, eine Cross-Origin-Anfrage ohne Downgrade sendet nur den Origin (Schema + Host + Port), von HTTPS nach HTTP geht nichts. Die Referrer-Empfehlung auf web.dev behandelt diesen Default als Kompromiss zwischen Privatsphäre und Nutzbarkeit. Er blockiert einen Teil der Fälle „volle Query an einen anderen Host“. Er blockiert keine Analytics-Anfragen gleichen Ursprungs, und er hilft nicht, wenn die Site unsafe-url setzt oder die Politik auf einem älteren Client ungesetzt bleibt, der noch die volle URL schickt.

Für „ich habe das nur einer Kollegin geschickt“ bleibt Referer relevant: Sobald sie klickt, können die eingefügten utm_*-Tags und Klick-IDs einen weiteren Hop gehen. Hat die Landingpage ein Dritt-Pixel, ein Support-Widget oder eine Schrift auf einem CDN, und erlaubt die Politik eine volle URL, stehen diese Parameter in den Logs jener Hosts. Tracking-Parameter vor dem Versand zu entfernen, kürzt beide Hops: Klartext im Chatprotokoll und ein Referer, der nach dem Öffnen noch feuern kann.

Der Gegensatz zum Fragment verdient einen weiteren Satz. Ein Schlüssel hinter # ist so gebaut, dass er nicht in die Anfragezeile eingeht und damit in üblichen Referer-Implementierungen fehlt. Eine Query hat diese Schicht nicht. Kampagnen-Tags und Klick-IDs sitzen hinter ?, damit Server und Skripte sie lesen können – genau deshalb landen sie in Logs. Ob „Fragezeichen geht in die Anfrage, Raute in der Regel nicht“, prüfen Sie mit den Schritten in Warum ein URL-Fragment hinter der Raute ein passender Ort für einen Schlüssel ist – und wann dieser Schutz wegfällt.

Systeme entfernen manches automatisch – das ist keine Versandregel

Apple dokumentiert einen eingebauten Schnitt. Auf der Seite Privacy Features steht Link Tracking Protection so: Beim Teilen von Links in Nachrichten wird zusätzliche Information entfernt, die manche Sites an URLs hängen, damit diese Sites Sie oder die Empfangsseite nicht tracken können. Safari Privat: Link Tracking Protection entfernt Tracking, das URLs beim Surfen angehängt wird. Apple veröffentlicht die Fähigkeit, keine Parameterliste.

Eine offizielle Vollständigkeitsliste gibt es nicht. Community-Prüfungen (PrivacyTests.org und vergleichbare) nennen oft gclid, fbclid, mc_eid, twclid und dclid. Kampagnen-Tags wie utm_source bleiben in der Regel stehen. Die Abdeckung hat Ränder: Gewöhnliches Safari, ein Dritt-Browser und ein In-App-WebView sind nicht dieselben Pfade wie Nachrichten-Teilen oder Privat. Wer auf Android, in Desktop-Chrome oder aus Teams und WhatsApp öffnet, entfernt nichts für Sie.

Firefox hat seit Version 102 die Einstellung network.url.strip_on_share.enabled. Ist sie aktiv, streicht Firefox bekannte Tracker, wenn Sie aus diesem Browser kopieren oder teilen. Das gilt für diesen einen Client, nicht für die Zeichenkette, die Sie zuvor aus Chrome in die Zwischenablage gelegt haben. UTM bleibt auch hier oft stehen. Ein Android-Gerät, ein Ticket in Jira oder ein Klick in Outlook führen die Firefox-Regel nicht aus.

„Mein Telefon entfernt Tracking-Parameter schon“ heißt also nur: Auf einem bestimmten System, in einer bestimmten App, können einige Klick-IDs vor dem Öffnen wegfallen. Es heißt nicht: Die Zeichenkette, die Sie ins Ticket geklebt haben, war bereits bereinigt. Der Versand passiert im Moment des Kopierens, an einer Stelle, die das Betriebssystem oft noch nicht betreten hat. Sie steuern die Zwischenablage, nicht ob das Gerät der Gegenseite noch einmal streicht.

Was Sie entfernen, was Sie behalten

Eine Regel, die Sie ausführen können: Zuerst fragen, ob die Seite ohne diesen Schlüssel noch öffnet. Eine Produkt-id, eine Suche q, eine page, ein lang oder eine Query, die das Dokument selbst braucht, ändert die Ressource, wenn Sie sie streichen. Kampagnen-Tags, Klick-IDs, Empfängernummern aus dem Mailversand und Share-Tokens ändern in der Regel nur die Attribution, nicht die Seite.

Die zweite Frage ist der Zweck des Links. Eine Kollegin, die einen Fehler nachstellt, braucht eine stabile Ressourcenadresse, nicht utm_campaign=sommer-sale. Eine Kundin, die „dieses Produkt öffnen“ soll, braucht sku, nicht das gclid Ihres letzten Klicks. UTM behalten Sie nur, wenn die Aufgabe lautet: „Bitte über diesen getaggten Kampagnenlink eintreten, damit wir diese Weiterleitung zählen.“ Auch dann gehört Ihre eigene Klick-ID nicht dazu.

Manuelles Löschen verfehlt Schlüssel. Eine echte Paid-URL kann fünf oder sechs utm_*-Felder tragen, eine Klick-ID und zwei oder drei hauseigene Tokens. Von rechts nach links wischen löscht oft id und lässt fbclid stehen. Stabiler ist der Lauf nach Schlüsselnamen: jeden utm_-Präfix streichen; eine bekannte Klick-ID-Tabelle streichen; wenn die Aufgabe es erlaubt, zusätzlich gängige Analytics-Schlüssel (_ga, _gl, mc_eid, mkt_tok) und gängige Shop-Attribution. Pfad, Host und Geschäfts-Query bleiben. Danach die Liste der entfernten Namen prüfen – nicht nur, ob das Ergebnis „kürzer wirkt“.

Konservativ und Standard sind zwei Risikoneigungen, keine zwei Stufen von Anonymität. Konservativ: nur UTM und Klick-IDs anfassen, unbekannte Custom-Schlüssel stehen lassen, damit Sie keinen Geschäftsparameter löschen, den Sie noch nicht kennen. Standard: zusätzlich gängige Analytics- und Shop-Attribution entfernen, passend für einen Link, der das Unternehmen verlässt oder in einem öffentlichen Kanal landet. Keines von beiden darf behaupten „jetzt anonym“. Ein Pfad kann weiter einen Nutzernamen tragen. Eine Query email= steht nicht in der UTM-Tabelle. Regelbasierte Bereinigung behandelt bekannte Tracker-Schlüssel, nicht jedes sensible Feld. Telefonnummern, Ausweisnummern und Schlüssel im Nachrichtentext brauchen einen eigenen Schwärzungslauf. Erwarten Sie nicht, dass das Entfernen von URL-Parametern diese Arbeit mit erledigt.

Sofort prüfen: Entfernliste, dann Network

„Lokal bereinigt, nichts hochgeladen“ beweist sich nicht selbst. Was Sie auf der Stelle sehen können, sind drei Dinge: welche Schlüssel weg sind, welche noch da sind, und ob Ihre Original-URL als Geschäftsdaten den Tab verlassen hat.

Bauen Sie zuerst einen Canary. Öffnen Sie eine öffentliche Seite ohne echten Kundenbezug und hängen Sie ?utm_source=canary-share&utm_medium=email&utm_campaign=canary-2026&fbclid=canaryclid&id=42 an. Fügen Sie die ganze Zeichenkette in die Bereinigung ein. Nach dem Lauf sollen die vier Tracker-Schlüssel fehlen und id=42 noch stehen. Listet das Werkzeug entfernte Namen, prüfen Sie diese Namen einzeln. Halten Sie nicht bei „die URL ist kürzer geworden“.

Öffnen Sie danach DevTools Network, aktivieren Sie Preserve log und suchen Sie im Filter nach canary-share oder der vollen Canary-Query. Sie darf nicht in einer XHR-/Fetch-Anfragezeile, Query oder Body stehen und nicht in einer Analytics-Query oder einem Analytics-Body. Statische Ressourcen, Styles und Skripte dürfen vorkommen – das sind Dateien der Seite. Ein Fehler ist die Originalkette als Geschäftsfeld outbound. Ein Titel oder Pfad mit „Datenschutz“ oder „bereinigen“ ist erwartet. Der volle Inhalt des Eingabefelds ist es nicht.

1. Bauen Sie eine Canary-URL mit utm_*, fbclid und einer Geschäfts-id. Kein echter Kunde, kein laufender Kampagnenname.
2. Nach der Bereinigung die Tabelle prüfen: Tracker-Schlüssel auf der Seite „entfernt“, id weiter in der Ergebnis-URL.
3. Network nach der Canary-Zeichenkette durchsuchen. Ein Treffer auf einer Geschäftsanfrage heißt: Das Original hat diesen Tab verlassen.

Der Beweis ist eng: In diesem Lauf sind bekannte Tracker-Schlüssel regelbasiert verschwunden, der Geschäfts-Schlüssel ist geblieben, und das Original hat diesen Tab nicht als beobachtetes HTTP-Feld verlassen. Er beweist nicht, dass keine Erweiterung das Eingabefeld gelesen hat, und nicht, dass ein Custom-Tracker außerhalb der Regeltabelle behandelt wurde. Nach einem Wechsel von Browser oder Regelliste den Canary erneut laufen lassen.

Die Regeln auf einer sofort nutzbaren Bereinigungsseite üben

Wenn Sie die Entfernliste auf einer Seite sehen wollen, können Sie mit MakePwd Link bereinigen beginnen. Die Seite ist sofort nutzbar, ohne Registrierung und ohne Konto. URL-Zerlegung und Parameterentfernung laufen in diesem Tab. Laut Produktbeschreibung geht der Ausgangstext nicht als Anfrage raus und wird nicht in Analytics geschrieben. Der Standardmodus entfernt utm_*, Anzeigen-Klick-IDs, gängige Analytics-Parameter und häufige Shop-Tracker. Der konservative Modus entfernt nur UTM und Klick-IDs. Pfad sowie Geschäftsparameter wie id und q bleiben. Höchstens 100 URLs auf einmal. Eine einzelne Zeile über 8 KB wird abgelehnt. Nur http oder https.

Üben Sie mit dem Canary oben, nicht mit einer lebenden Klick-ID aus einer laufenden Kampagne. Nach dem Lauf zwei Stellen ansehen: die Entfernliste im Ergebnisbereich und Network auf die Originalkette. Die Liste beantwortet „habe ich die richtigen Schlüssel gelöscht“. Network beantwortet „wurde hochgeladen“. Beides muss passen, bevor Sie einer Kollegin sagen: Das sind die entfernten Schlüssel, und ich habe den Canary ohne Outbound-Treffer gesucht.

Bereinigen behandelt nur die Linkform. Telefonnummern, Ausweisnummern, E-Mails und API-Keys im Chat- oder Tickettext gehören auf derselben Seite zur Datenschwärzung, per Muster maskiert und danach von einem Menschen geprüft. MakePwd beansprucht keine DSGVO-Zertifizierung. Ist das bereinigte Ergebnis weiter ein Geheimnis, das nicht liegen bleiben darf, schicken Sie es einmal über den Einmal-Link und lassen den Schlüssel im URL-#-Fragment. Eine ganze Datei machen Sie in der Dateiverschlüsselung auf diesem Gerät zu .lock / .enc und schicken diese Datei über Laufwerk oder Mail. Keiner dieser Schritte verlangt eine Anmeldung.

Häufige Fragen

Erreicht die Gegenseite die Seite noch, wenn UTM weg ist?

Ja, sofern Geschäftsparameter und Pfad bleiben. UTM und Klick-IDs dienen der Attribution, nicht dem Routing. Streichen Sie utm_campaign oder fbclid, soll die Landingpage weiter über Pfad und id öffnen. Bekommen Sie 404 oder ein anderes Ergebnis, haben Sie einen Geschäfts-Schlüssel getroffen. Wechseln Sie auf Konservativ und vergleichen Sie Schlüssel einzeln.

Schützt HTTPS diese Parameter nicht schon?

Nicht im Moment des Versands. HTTPS senkt das Risiko, auf dem Pfad mitgehört zu werden. Es löscht weder Adresszeile noch Verlauf, Chat oder Logs. OWASP hält fest: Auch auf einem verschlüsselten Kanal erscheint die Query in Referer, Web-Logs, geteilten Systemen und der Browserhistorie. Ob Sie die volle URL einfügen dürfen, ist eine andere Frage als ob die Site ein Zertifikat hat.

Apple und Firefox streichen Tracker. Muss ich selbst noch entfernen?

Ja. Die Systemfähigkeit gilt auf dokumentierten Pfaden – Nachrichten und Safari Privat bei Apple, Kopieren und Teilen in Firefox, wenn network.url.strip_on_share.enabled aktiv ist. Eine vollständige Schlüsselliste veröffentlicht Apple nicht. UTM bleibt meist stehen. Kleben Sie den Link ins Ticket oder in den Chat auf Android, laufen diese Schutzschichten nicht für Sie. Eine Versandregel schaut auf die Zwischenablage, nicht darauf, ob das Betriebssystem der Gegenseite noch einmal streicht.

Löscht ein bereinigter Link auch die Produkt-id?

Das sollte er nicht, wenn das Werkzeug nach Namen entscheidet. id, q und sku sind kein utm_-Präfix und stehen nicht auf der gängigen Klick-ID-Tabelle. Die Prüfung ist ein Canary, der Tracker-Schlüssel und einen Geschäfts-Schlüssel gleichzeitig trägt, und dann bestätigt, dass nur die Ersteren verschwunden sind. Schreibt eine Site Tracking in einen Custom-Namen, kennt die Regeltabelle ihn nicht. Diesen Schlüssel von Hand löschen oder die Liste erweitern.

Drei Dinge vor dem nächsten Versand

Erstens: Die ganze Adresszeile markieren ist nicht dasselbe wie „versandfertig“. Teilen Sie die Query in Kampagnen-Tags, Klick-IDs, hauseigene Attribution und Geschäftsparameter. Nur die letzte Art bleibt standardmäßig. Zweitens: HTTPS und automatisches Streichen durch das System ersetzen keine Prüfung der Zwischenablage. Die Query landet in Verlauf, Ticket und Logs und kann im Referer noch einen Hop gehen. Drittens: Zwei Stellen prüfen: die Liste der entfernten Schlüsselnamen und eine Network-Suche nach Ihrem Canary.

Wenn die nächste Frage lautet, ob Klartext als Geschäftsdaten diesen Tab verlassen hat, gehört das in Im Browser verschlüsseln: so prüfen Sie, dass Klartext das Gerät nicht verlassen hat. Dieser Text macht aus „welche Query-Felder beim Teilen einer vollen URL nicht mitgehen dürfen“ einen Bereich, den Sie ins Fazit schreiben können.