Sie teilen einen Angebotslink mit einem Interessenten. Zwei Minuten später zeigt Ihr Tracking-Tool, dass er ihn geöffnet, 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 geöffnet.
Was passiert ist: Der E-Mail-Sicherheitsscanner seines Unternehmens hat Ihren Link vor ihm geöffnet. Der "Aufruf" war ein Bot. Und wenn Ihre Analyseplattform das nicht gezielt behandelt, können Sie den Unterschied nicht erkennen.
Das ist kein seltener Randfall. Es passiert bei praktisch jeder E-Mail, die an Unternehmensempfänger mit Microsoft 365 oder Google Workspace gesendet wird. Insbesondere im Cold-Outbound, wo jeder Link vor der Zustellung über SafeLinks oder Proofpoint umgeschrieben wird, sind 60–70 % der Klicks, die Ihr CRM aufzeichnet, Scanner und keine Menschen, abhängig vom E-Mail-Sicherheits-Stack des Empfängers.
Wenig Zeit?
Springen Sie direkt zu unserer Lösung mit drei Erkennungsschichten, oder sehen Sie, was das für Ihre Analytics bedeutet.
Die Bots, die Ihre Analytics aufblähen
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 einfügen, ruft ein Bot sofort die Seite ab, um eine Vorschaukarte zu generieren. Diese Anfragen kommen von identifizierbaren User Agents wie 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 routinemäßig öffentlich zugängliche 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 zerstört.
Microsoft Defender SafeLinks, Proofpoint URL Defense, Mimecast und Google Safe Browsing scannen jeden Link in eingehenden E-Mails, bevor der Empfänger sie sieht. Ihre Aufgabe ist es, Phishing-Seiten und Malware zu erkennen. Sie tun dies, indem sie den Link tatsächlich öffnen, die Seite laden und in vielen Fällen durch deren Inhalt navigieren.
Was sie nahezu unmöglich von echten Nutzern unterscheidbar macht:
- Gefälschte User Agents. SafeLinks gibt sich nicht als Bot zu erkennen. Es verwendet echte Browser-User-Agents, etwa "Chrome 120 on Windows 11" oder sogar Mobile-Geräte-Strings wie "itel A27 Android." Ihr Server sieht etwas, das wie ein legitimer Browserbesuch aussieht.
- Seitennavigation. SafeLinks lädt nicht nur die erste Seite. Es navigiert durch ungefähr 6 Seiten Ihres Decks, unabhängig von der Gesamtlänge. Proofpoint macht ähnliches mehrseitiges Scanning.
- Realistisches Timing. Diese Sitzungen dauern 22–48 Sekunden. Sie rasen nicht sofort durch wie ein primitiver Scraper, das Timing sieht plausibel für ein kurzes Durchblättern aus.
- Synthetische DOM-Events. Einige Scanner feuern JavaScript-Events ab: programmatische Scrolls, simulierte Touches, sogar Click-Events, um böswillige Skripte auszulösen, die möglicherweise 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 gefälschten "Aufruf", der wie ein echter aussieht. Manchmal zwei: einen vom Sicherheits-Stack des Absenders und einen vom Empfänger.
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 über Microsofts eigene Server (https://nam02.safelinks.protection.outlook.com/...). Proofpoint macht dasselbe mit seinen URL Defense Rewrites (https://urldefense.proofpoint.com/v2/...).
Wenn der Empfänger schließlich auf den Link in seiner E-Mail klickt, öffnet er nicht Ihre Original-URL direkt. Er klickt auf die umgeschriebene SafeLinks-URL, die zuerst über Microsofts Proxy läuft, und Microsofts Proxy öffnet Ihre Seite, um sie in diesem Moment erneut zu scannen. Dann leitet er den Browser des Nutzers auf Ihre tatsächliche Seite weiter.
Das Ergebnis: Der Bot-Scan und der echte Besuch geschehen gleichzeitig. Der Sicherheitsscanner öffnet Ihr Deck von einer Datacenter-IP im exakt gleichen Moment, in dem der echte Nutzer es von seinem Büro aus öffnet. Sie erhalten zwei gleichzeitige Sitzungen, eine vom Bot, eine vom Menschen, mit nahezu identischen Zeitstempeln. Wenn Ihre Analytics sie nicht unterscheiden können, zählen Sie entweder beide (aufgeblasen) oder riskieren, die echte herauszufiltern (unterzählt).
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 überschneidet.
Die Follow-up-Falle
Wenn Sie Aufruf-Benachrichtigungen nutzen, um Ihre Follow-ups zu timen, sind Bot-Aufrufe aktiv schädlich. Sie rufen einen Interessenten an, "während er sich Ihr Deck ansieht", und er hat seine E-Mail noch nicht einmal geöffnet. Sie wirken aufdringlich statt aufmerksam. Und durch URL-Umschreibung ist selbst das Timing trügerisch: 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 prüfen, fängt 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 können nicht nach IP blockieren, ohne legitime Nutzer über Firmen-VPNs zu blockieren.
Browser-Fingerprinting (Canvas, WebGL, Font Enumeration) funktioniert nicht, weil SafeLinks einen vollständigen Chromium-basierten Browser betreibt. Sein Fingerprint ist nicht von einer echten Chrome-Installation zu unterscheiden.
So lösen wir es: drei Erkennungsschichten
Wir haben ein Erkennungssystem entwickelt, das E-Mail-Sicherheitsscanner auffängt, ohne legitime Nutzer zu blockieren, einschließlich solcher über Firmen-VPNs und Proxies.
So fließt der Traffic durch die drei Schichten. Bewegen Sie den Mauszeiger über einen beliebigen Knoten, um seinen Pfad nachzuverfolgen:
Schicht 1: User-Agent-Abgleich
Der unkomplizierte Teil. Wir prüfen 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 fängt etwa 40 % des Bot-Traffics ab. Die einfachen 40 %.
Schicht 2: Datacenter-IP-Erkennung
E-Mail-Sicherheitsscanner fälschen ihren User Agent, aber sie können nicht verbergen, wo sie laufen. SafeLinks operiert aus Azure-Datacentern. Proofpoint läuft auf AWS. Das sind bekannte Hosting-Provider-IP-Bereiche.
Wenn ein Betrachter einen geteilten Link öffnet, prüfen wir seine IP gegen einen Geolocation-Dienst, der meldet, ob die IP einem Hosting-Provider gehört. Wenn ja, wird die Sitzung als Bot markiert.
Das fängt den Großteil des E-Mail-Sicherheitsscanner-Traffics ab. Ein Betrachter, der sich von "Quincy, Washington" über 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, schließen ihn von der Analyse aus und senden Ihnen keine Benachrichtigung. So können wir False Positives prüfen, und Nutzer haben die Möglichkeit, Bot-Sitzungen zu inspizieren, wenn sie nachforschen möchten.
Was ist mit VPN-Nutzern?
Firmen-VPN-Nutzer routen manchmal über Datacenter-IPs, was bedeutet, dass Schicht 2 einen echten Nutzer als Bot markieren könnte. 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 Bestätigung
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), zählen wir sie nicht als echten Aufruf. Stattdessen beobachten wir auf genuinen menschlichen Input:
Was wir überwachen: Mausbewegung, Touch-Events, Tastatureingaben und Scroll-Aktivität.
Was wir ignorieren: Seitennavigation, Link-Klicks und Downloads. Das ist kontraintuitiv, diese scheinen starke Signale für menschliches Verhalten zu sein. Aber SafeLinks navigiert durch 6+ Seiten jedes Decks, das es scannt. Headless Browser wie Puppeteer können programmatisch Buttons klicken und Downloads auslösen. Diese Aktionen sind trivial zu fälschen. Low-Level-Eingabegeräte-Events sind viel schwieriger überzeugend 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 Großteil 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 Verzögerung, leichte Kurven und Mikrokorrekturen.
Wenn eine genuine Geste erkannt wird, wird die Sitzung atomar von Bot zu echt "befördert". Ab diesem Punkt, und nur ab diesem Punkt, erhöhen 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 öffnet, einmal die Maus bewegt und sofort den Tab schließt?
Die Bestätigungsanfrage wird möglicherweise 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 für Fire-and-Forget-Anfragen entwickelt wurde, die das Entladen der Seite überleben, als Backup. Der letzte Beacon trägt die Bestätigungsdaten zusammen mit den Engagement-Metriken der Sitzung.
Serverseitig ist die Beförderung atomar: ein einzelnes SQL-Update, das nur erfolgreich ist, wenn die Sitzung nicht bereits befördert wurde. Das verhindert doppeltes Zählen, wenn sowohl die reguläre Bestätigung als auch das Beacon-Backup eintreffen.
Was das für Ihre Analytics bedeutet
Die praktische Auswirkung ist erheblich. In unseren Tests mit Enterprise-fokussierten Vertriebsteams waren 15–40 % der scheinbaren Deck-Aufrufe Bot-Sitzungen, hauptsächlich von SafeLinks und Proofpoint. Für Teams, die an große Unternehmen mit strengen E-Mail-Sicherheitsrichtlinien verkaufen, war die Zahl noch höher.
Ohne Filterung:
- Aufrufzahlen sind um 15–40 % aufgeblasen
- Die "am stärksten engagierten" Interessenten sind möglicherweise diejenigen mit der aggressivsten E-Mail-Sicherheit
- Das Timing der Aufrufe ist unzuverlässig: Sie denken, jemand hat Ihr Deck um 14 Uhr angesehen, während der Sicherheitsscanner es um 13:58 Uhr geöffnet hat
- Follow-up-Signale sind Rauschen
Mit Filterung:
- Jeder Aufruf repräsentiert eine echte Person, die sich Ihre Inhalte tatsächlich angesehen hat. Sie können sehen, wer Ihr Angebot wirklich angesehen hat
- Engagement-Metriken (verbrachte Zeit, angesehene Seiten, Abschlussrate) spiegeln genuines Interesse wider
- Aufruf-Benachrichtigungen werden ausgelöst, wenn ein Mensch aktiv engagiert ist, nicht wenn ein Bot vorscannt
Bot-Sitzungen in HummingDeck prüfen
Der Activity-Feed enthält einen Filter "Bot-Sitzungen anzeigen", mit dem Sie herausgefilterte Sitzungen inspizieren können. Nutzen Sie ihn, um zu überprüfen, ob das System für Ihre spezifischen Interessenten korrekt funktioniert: wenn Sie sehen, dass ein legitimer Betrachter als Bot markiert wird, sollte die Gesten-Bestätigungsschicht ihn befördern, sobald er mit der Seite interagiert. Wenn das nicht geschieht, wenden Sie sich an den Support.
Die übergeordnete Erkenntnis
E-Mail-Sicherheitsscanning wird nicht verschwinden, es wird gründlicher. Microsoft und Google erweitern das automatisierte Link-Scanning, da Phishing-Angriffe immer ausgefeilter werden. Jede Analyseplattform, die sich auf Seitenaufrufe als Proxy für menschliche Aufrufe verlässt, wird zunehmend ungenauer. Bei der Bewertung von Angebotsverfolgungs-Tools sollte Bot-Erkennung eine unverzichtbare Anforderung sein. Dieselben Bots, die Deck-Aufrufe aufblähen, fälschen auch E-Mail-Öffnungsraten.
Das Signal, das Sie brauchen, ist nicht "Wurde mein Link geöffnet." Es ist "Hat ein Mensch sich mit meinem Inhalt beschäftigt." Das erfordert, den Unterschied zu erkennen, und der Unterschied liegt in den Gesten, nicht im Seitenaufruf. Wenn Sie gerade eine Finanzierungsrunde durchführen und sich bei der Priorisierung von Follow-ups auf Deck-Analysen verlassen, lesen Sie unseren Leitfaden, wie Sie nachverfolgen, ob Investoren Ihr Pitch Deck tatsächlich lesen, für die belastbaren Daten.