Sie teilen einen Angebotslink mit einem Interessenten. Zwei Minuten spaeter zeigt Ihr Tracking-Tool, dass er ihn geoeffnet, sechs Seiten durchgescrollt und jeweils 30 Sekunden darauf verbracht hat.
Sie schicken eine Follow-up-E-Mail. Der Interessent hat keine Ahnung, wovon Sie reden — er hat den Link noch gar nicht geoeffnet.
Was passiert ist: Der E-Mail-Sicherheitsscanner seines Unternehmens hat Ihren Link vor ihm geoeffnet. Der "Aufruf" war ein Bot. Und wenn Ihre Analyseplattform das nicht gezielt behandelt, koennen Sie den Unterschied nicht erkennen.
Das ist kein seltener Randfall. Es passiert bei praktisch jeder E-Mail, die an Unternehmensempfaenger mit Microsoft 365 oder Google Workspace gesendet wird.
Die Bots, die Ihre Analytics aufblaahen
Es gibt drei Kategorien automatisierten Traffics, die auf geteilte Deck-Links treffen:
Link-Vorschau-Bots
Wenn Sie einen Link in Slack, LinkedIn, Twitter oder iMessage einfuegen, ruft ein Bot sofort die Seite ab, um eine Vorschaukarte zu generieren. Diese Anfragen kommen von identifizierbaren User Agents — Slackbot-LinkExpanding, LinkedInBot, Twitterbot. Sie sind leicht zu erkennen und zu filtern. Die meisten Tracking-Tools behandeln sie korrekt.
Suchmaschinen-Crawler
Googlebot, Bingbot und deren Varianten indexieren routinemaessig oeffentlich zugaengliche Inhalte. Auch sie geben sich offen zu erkennen und sind einfach zu filtern. Wenn Ihre geteilten Links hinter einer Authentifizierung liegen oder einzigartige Slugs verwenden, finden Crawler sie ohnehin selten.
E-Mail-Sicherheitsscanner
Das ist die Kategorie, die Analytics zerstoert.
Microsoft Defender SafeLinks, Proofpoint URL Defense, Mimecast und Google Safe Browsing scannen jeden Link in eingehenden E-Mails, bevor der Empfaenger sie sieht. Ihre Aufgabe ist es, Phishing-Seiten und Malware zu erkennen. Sie tun dies, indem sie den Link tatsaechlich oeffnen, die Seite laden und in vielen Faellen durch deren Inhalt navigieren.
Was sie nahezu unmoeglich von echten Nutzern unterscheidbar macht:
- Gefaelschte User Agents. SafeLinks gibt sich nicht als Bot zu erkennen. Es verwendet echte Browser-User-Agents — Dinge wie "Chrome 120 on Windows 11" oder sogar Mobile-Geraete-Strings wie "itel A27 Android." Ihr Server sieht etwas, das wie ein legitimer Browserbesuch aussieht.
- Seitennavigation. SafeLinks laedt nicht nur die erste Seite. Es navigiert durch ungefaehr 6 Seiten Ihres Decks, unabhaengig von der Gesamtlaenge. Proofpoint macht aehnliches mehrseitiges Scanning.
- Realistisches Timing. Diese Sitzungen dauern 22–48 Sekunden. Sie rasen nicht sofort durch wie ein primitiver Scraper — das Timing sieht plausibel fuer ein kurzes Durchblaettern aus.
- Synthetische DOM-Events. Einige Scanner feuern JavaScript-Events ab — programmatische Scrolls, simulierte Touches, sogar Click-Events — um boeswillige Skripte auszuloesen, die moeglicherweise hinter Benutzerinteraktionen versteckt sind.
Der Nettoeffekt: Jedes Mal, wenn Sie einen Deck-Link an jemanden in einem Unternehmen mit Microsoft 365 senden (das sind die meisten Ihrer Enterprise-Interessenten), erhalten Sie einen gefaelschten "Aufruf", der wie ein echter aussieht. Manchmal zwei — einen vom Sicherheits-Stack des Absenders und einen vom Empfaenger.
So sieht eine SafeLinks-Bot-Sitzung im Vergleich zu einem echten menschlichen Betrachter aus:
URL-Umschreibung macht es schlimmer
Einige Sicherheitstools scannen Links nicht nur vorab — sie schreiben sie komplett um. SafeLinks ersetzt jede URL im E-Mail-Text durch eine Weiterleitung ueber Microsofts eigene Server (https://nam02.safelinks.protection.outlook.com/...). Proofpoint macht dasselbe mit seinen URL Defense Rewrites (https://urldefense.proofpoint.com/v2/...).
Wenn der Empfaenger schliesslich auf den Link in seiner E-Mail klickt, oeffnet er nicht Ihre Original-URL direkt. Er klickt auf die umgeschriebene SafeLinks-URL, die zuerst ueber Microsofts Proxy laeuft — und Microsofts Proxy oeffnet Ihre Seite, um sie in diesem Moment erneut zu scannen. Dann leitet er den Browser des Nutzers auf Ihre tatsaechliche Seite weiter.
Das Ergebnis: Der Bot-Scan und der echte Besuch geschehen gleichzeitig. Der Sicherheitsscanner oeffnet Ihr Deck von einer Datacenter-IP im exakt gleichen Moment, in dem der echte Nutzer es von seinem Buero aus oeffnet. Sie erhalten zwei gleichzeitige Sitzungen — eine vom Bot, eine vom Menschen — mit nahezu identischen Zeitstempeln. Wenn Ihre Analytics sie nicht unterscheiden koennen, zaehlen Sie entweder beide (aufgeblasen) oder riskieren, die echte herauszufiltern (unterzaehlt).
Das ist das schwierigste Szenario, das korrekt behandelt werden muss. Der Scan vor der Zustellung ist isoliert betrachtet leicht zu identifizieren — er trifft Minuten ein, bevor jemand klickt. Aber der Klick-Rescan trifft zusammen mit dem echten Nutzer ein, von einer anderen IP, mit einem anderen User Agent, und erzeugt eine separate Sitzung, die sich mit der legitimen ueberschneidet.
Die Follow-up-Falle
Wenn Sie Aufruf-Benachrichtigungen nutzen, um Ihre Follow-ups zu timen, sind Bot-Aufrufe aktiv schaedlich. Sie rufen einen Interessenten an, "waehrend er sich Ihr Deck ansieht", und er hat seine E-Mail noch nicht einmal geoeffnet. Sie wirken aufdringlich statt aufmerksam. Und durch URL-Umschreibung ist selbst das Timing truegerisch — die Bot-Sitzung beginnt im selben Moment wie die echte.
Warum Standard-Bot-Erkennung nicht funktioniert
Der Standardansatz — User Agents gegen eine Liste bekannter Bots zu pruefen — faengt Link-Vorschau-Bots und Crawler ab, verfehlt aber E-Mail-Sicherheitsscanner komplett. SafeLinks verwendet absichtlich echt aussehende User Agents, um gezielt nicht per Fingerprinting erkannt zu werden, weil Phishing-Seiten, die Bots erkennen, anderen Inhalt ausliefern als echten Nutzern.
IP-basiertes Rate Limiting hilft ebenfalls nicht. SafeLinks rotiert durch einen Pool von Azure-Datacenter-IPs, sodass jeder Scan von einer anderen Adresse kommt. Sie koennen nicht nach IP blockieren, ohne legitime Nutzer ueber Firmen-VPNs zu blockieren.
Browser-Fingerprinting (Canvas, WebGL, Font Enumeration) funktioniert nicht, weil SafeLinks einen vollstaendigen Chromium-basierten Browser betreibt. Sein Fingerprint ist nicht von einer echten Chrome-Installation zu unterscheiden.
So loesen wir es: drei Erkennungsschichten
Wir haben ein Erkennungssystem entwickelt, das E-Mail-Sicherheitsscanner auffaengt, ohne legitime Nutzer zu blockieren — einschliesslich solcher ueber Firmen-VPNs und Proxies.
So fliesst der Traffic durch die drei Schichten. Bewegen Sie den Mauszeiger ueber einen beliebigen Knoten, um seinen Pfad nachzuverfolgen:
Schicht 1: User-Agent-Abgleich
Der unkomplizierte Teil. Wir pruefen eingehende Anfragen gegen 60+ bekannte Bot-Muster — Link-Vorschau-Bots, Such-Crawler, Headless Browser, HTTP-Client-Bibliotheken. Wenn sich eine Anfrage als Slackbot oder python-requests identifiziert, lehnen wir sie sofort ab. Keine Sitzung wird erstellt.
Das faengt etwa 40 % des Bot-Traffics ab. Die einfachen 40 %.
Schicht 2: Datacenter-IP-Erkennung
E-Mail-Sicherheitsscanner faelschen ihren User Agent, aber sie koennen nicht verbergen, wo sie laufen. SafeLinks operiert aus Azure-Datacentern. Proofpoint laeuft auf AWS. Das sind bekannte Hosting-Provider-IP-Bereiche.
Wenn ein Betrachter einen geteilten Link oeffnet, pruefen wir seine IP gegen einen Geolocation-Dienst, der meldet, ob die IP einem Hosting-Provider gehoert. Wenn ja, wird die Sitzung als Bot markiert.
Das faengt den Grossteil des E-Mail-Sicherheitsscanner-Traffics ab. Ein Betrachter, der sich von "Quincy, Washington" ueber eine Microsoft-Azure-IP um 2 Uhr morgens verbindet, ist mit ziemlicher Sicherheit nicht Ihr Interessent, der Ihr Angebot liest.
Es gibt hier eine Feinheit: Wir blockieren diese Sitzungen nicht. Wir erstellen den Aufruf-Datensatz, markieren ihn aber als Bot, schliessen ihn von der Analyse aus und senden Ihnen keine Benachrichtigung. So koennen wir False Positives pruefen, und Nutzer haben die Moeglichkeit, Bot-Sitzungen zu inspizieren, wenn sie nachforschen moechten.
Was ist mit VPN-Nutzern?
Firmen-VPN-Nutzer routen manchmal ueber Datacenter-IPs, was bedeutet, dass Schicht 2 einen echten Nutzer als Bot markieren koennte. Deshalb gibt es Schicht 3 — sie gibt Menschen einen Weg zu "beweisen", dass sie echt sind, selbst wenn ihre IP wie ein Datacenter aussieht.
Schicht 3: Gestenbasierte menschliche Bestaetigung
Das ist die entscheidende Schicht. Sie basiert auf einer einfachen Beobachtung: Echte Menschen interagieren physisch mit der Seite. Bots nicht — oder wenn sie es tun, haben ihre Interaktionen eine charakteristische Signatur.
Wenn eine Sitzung anfangs als Bot markiert wird (durch Schicht 2), zaehlen wir sie nicht als echten Aufruf. Stattdessen beobachten wir auf genuinen menschlichen Input:
Was wir ueberwachen: Mausbewegung, Touch-Events, Tastatureingaben und Scroll-Aktivitaet.
Was wir ignorieren: Seitennavigation, Link-Klicks und Downloads. Das ist kontraintuitiv — diese scheinen starke Signale fuer menschliches Verhalten zu sein. Aber SafeLinks navigiert durch 6+ Seiten jedes Decks, das es scannt. Headless Browser wie Puppeteer koennen programmatisch Buttons klicken und Downloads ausloesen. Diese Aktionen sind trivial zu faelschen. Low-Level-Eingabegeraete-Events sind viel schwieriger ueberzeugend zu synthetisieren.
Das 3-Sekunden-Fenster: Wir ignorieren alle Gesten in den ersten 3 Sekunden nach dem Laden der Seite. SafeLinks und Proofpoint feuern ihre synthetischen Events fast sofort ab — innerhalb von 500 Millisekunden nach dem Laden der Seite. Echte Menschen brauchen mindestens 3 Sekunden, um sich zu orientieren und mit der Interaktion zu beginnen. Dieser einzelne Zeitschwellenwert eliminiert den Grossteil des synthetischen Event-Rauschens.
Mausbewegungsanalyse: Wenn wir nach dem 3-Sekunden-Fenster eine Mausbewegung erkennen, protokollieren wir die Trajektorie — Koordinaten und Zeitstempel von bis zu 20 Bewegungsereignissen. Bot-generierte Mausbewegungen folgen geometrischen Pfaden (perfekt gerade Linien, exakte Kreise) oder feuern ein einzelnes Event. Menschliche Mausbewegungen haben organische Beschleunigung und Verzoegerung, leichte Kurven und Mikrokorrekturen.
Wenn eine genuine Geste erkannt wird, wird die Sitzung atomar von Bot zu echt "befoerdert". Ab diesem Punkt — und nur ab diesem Punkt — erhoehen sich die Aufrufzahlen und Sie erhalten eine Benachrichtigung.
Das Timing ist entscheidend
Das gesamte System ist um eine spezifische Race Condition herum konzipiert: Was passiert, wenn ein echter Nutzer einen Link oeffnet, einmal die Maus bewegt und sofort den Tab schliesst?
Die Bestaetigungsanfrage wird moeglicherweise nicht abgeschlossen, bevor der Tab geschlossen wird. Browser brechen laufende fetch()-Anfragen bei der Navigation ab. Deshalb verwenden wir sendBeacon() — eine Browser-API, die speziell fuer Fire-and-Forget-Anfragen entwickelt wurde, die das Entladen der Seite ueberleben — als Backup. Der letzte Beacon traegt die Bestaetigungsdaten zusammen mit den Engagement-Metriken der Sitzung.
Serverseitig ist die Befoerderung atomar: ein einzelnes SQL-Update, das nur erfolgreich ist, wenn die Sitzung nicht bereits befoerdert wurde. Das verhindert doppeltes Zaehlen, wenn sowohl die regulaere Bestaetigung als auch das Beacon-Backup eintreffen.
Was das fuer Ihre Analytics bedeutet
Die praktische Auswirkung ist erheblich. In unseren Tests mit Enterprise-fokussierten Vertriebsteams waren 15–40 % der scheinbaren Deck-Aufrufe Bot-Sitzungen — hauptsaechlich von SafeLinks und Proofpoint. Fuer Teams, die an grosse Unternehmen mit strengen E-Mail-Sicherheitsrichtlinien verkaufen, war die Zahl noch hoeher.
Ohne Filterung:
- Aufrufzahlen sind um 15–40 % aufgeblasen
- Die "am staerksten engagierten" Interessenten sind moeglicherweise diejenigen mit der aggressivsten E-Mail-Sicherheit
- Das Timing der Aufrufe ist unzuverlaessig — Sie denken, jemand hat Ihr Deck um 14 Uhr angesehen, waehrend der Sicherheitsscanner es um 13:58 Uhr geoeffnet hat
- Follow-up-Signale sind Rauschen
Mit Filterung:
- Jeder Aufruf repraesentiert eine echte Person, die sich Ihre Inhalte tatsaechlich angesehen hat
- Engagement-Metriken (verbrachte Zeit, angesehene Seiten, Abschlussrate) spiegeln genuines Interesse wider
- Aufruf-Benachrichtigungen werden ausgeloest, wenn ein Mensch aktiv engagiert ist, nicht wenn ein Bot vorscannt
Bot-Sitzungen in HummingDeck pruefen
Der Activity-Feed enthaelt einen Filter "Bot-Sitzungen anzeigen", mit dem Sie herausgefilterte Sitzungen inspizieren koennen. Nutzen Sie ihn, um zu ueberpruefen, ob das System fuer Ihre spezifischen Interessenten korrekt funktioniert — wenn Sie sehen, dass ein legitimer Betrachter als Bot markiert wird, sollte die Gesten-Bestaetigungsschicht ihn befoerdern, sobald er mit der Seite interagiert. Wenn das nicht geschieht, wenden Sie sich an den Support.
Die uebergeordnete Erkenntnis
E-Mail-Sicherheitsscanning wird nicht verschwinden — es wird gruendlicher. Microsoft und Google erweitern das automatisierte Link-Scanning, da Phishing-Angriffe immer ausgefeilter werden. Jede Analyseplattform, die sich auf Seitenaufrufe als Proxy fuer menschliche Aufrufe verlaesst, wird zunehmend ungenauer.
Das Signal, das Sie brauchen, ist nicht "Wurde mein Link geoeffnet." Es ist "Hat ein Mensch sich mit meinem Inhalt beschaeftigt." Das erfordert, den Unterschied zu erkennen — und der Unterschied liegt in den Gesten, nicht im Seitenaufruf.