Je deelt een offertelink met een prospect. Twee minuten later meldt je trackingtool dat ze het hebben geopend, door zes pagina's hebben gescrolld en 30 seconden op elk hebben besteed.
Je stuurt meteen een follow-up e-mail. Ze hebben geen idee waar je het over hebt — ze hebben het nog niet geopend.
Wat er gebeurde: de e-mailbeveiligingsscanner van hun bedrijf opende je link voordat zij dat deden. De "weergave" was een bot. En tenzij je analyticsplatform dit specifiek afhandelt, kun je het verschil niet zien.
Dit is geen zeldzaam randgeval. Het gebeurt bij vrijwel elke e-mail die wordt verzonden naar enterprise-ontvangers die Microsoft 365 of Google Workspace gebruiken.
Weinig tijd?
Spring naar hoe wij het oplossen met drie lagen van botdetectie, of bekijk wat dit betekent voor je analytics.
De bots die je analytics opblazen
Er zijn drie categorieën geautomatiseerd verkeer die getrackte decklinks treffen:
Linkpreviewbots
Wanneer je een link plakt in Slack, LinkedIn, Twitter of iMessage, haalt een bot onmiddellijk de pagina op om een previewkaart te genereren. Deze verzoeken komen van herkenbare user agents — Slackbot-LinkExpanding, LinkedInBot, Twitterbot. Ze zijn makkelijk te detecteren en filteren. De meeste trackingtools handelen deze correct af.
Zoekmachinecrawlers
Googlebot, Bingbot en hun varianten indexeren routinematig publiek beschikbare content. Deze identificeren zichzelf ook openlijk en zijn eenvoudig te filteren. Als je gedeelde links achter authenticatie zitten of unieke slugs gebruiken, vinden crawlers ze zelden.
E-mailbeveiligingsscanners
Dit is de categorie die analytics breekt.
Microsoft Defender SafeLinks, Proofpoint URL Defense, Mimecast en Google Safe Browsing scannen elke link in binnenkomende e-mails voordat de ontvanger ze ziet. Hun taak is het detecteren van phishingpagina's en malware. Ze doen dit door de link daadwerkelijk te openen, de pagina te laden en in veel gevallen door de content te navigeren.
Wat ze bijna onmogelijk maakt om van echte gebruikers te onderscheiden:
- Gespoofde user agents. SafeLinks kondigt zichzelf niet aan als bot. Het gebruikt echte browser-user-agents — dingen als "Chrome 120 op Windows 11" of zelfs mobiele apparaatstrings zoals "itel A27 Android." Je server ziet wat eruitziet als een legitiem browserbezoek.
- Paginanavigatie. SafeLinks laadt niet alleen de eerste pagina. Het navigeert door ongeveer 6 pagina's van je deck, ongeacht de totale lengte. Proofpoint doet vergelijkbare meerpaginascans.
- Realistische timing. Deze sessies duren 22–48 seconden. Ze razen er niet doorheen zoals een simpele scraper — de timing ziet er plausibel uit voor een snelle blik.
- Synthetische DOM-events. Sommige scanners vuren JavaScript-events af — programmatische scrolls, gesimuleerde aanrakingen, zelfs klikevents — om kwaadaardige scripts te triggeren die mogelijk verborgen zijn achter gebruikersinteractie.
Het netto-effect: elke keer dat je een decklink e-mailt naar iemand bij een bedrijf dat Microsoft 365 gebruikt (dat zijn de meeste van je enterprise-prospects), krijg je een nep-"weergave" die eruitziet als een echte. Soms twee — één van de beveiligingsstack van de afzender en één van die van de ontvanger.
Zo ziet een SafeLinks-botsessie er naast een echte menselijke kijker uit:
URL-herschrijving maakt het erger
Sommige beveiligingstools scannen niet alleen links vooraf — ze herschrijven ze volledig. SafeLinks vervangt elke URL in de e-mailbody door een redirect via Microsoft's eigen servers (https://nam02.safelinks.protection.outlook.com/...). Proofpoint doet hetzelfde met zijn URL Defense-herschrijvingen (https://urldefense.proofpoint.com/v2/...).
Wanneer de ontvanger uiteindelijk op de link in hun e-mail klikt, openen ze niet je oorspronkelijke URL direct. Ze klikken op de herschreven SafeLinks-URL, die eerst via Microsoft's proxy routeert — en Microsoft's proxy opent je pagina om deze op dat moment opnieuw te scannen. Vervolgens stuurt het de browser van de gebruiker door naar je daadwerkelijke pagina.
Het resultaat: de botscan en het echte bezoek vinden gelijktijdig plaats. De beveiligingsscanner opent je deck vanaf een datacenter-IP op exact dezelfde seconde dat de echte gebruiker het opent vanaf kantoor. Je krijgt twee gelijktijdige sessies — één bot, één mens — met bijna identieke tijdstempels. Als je analytics ze niet uit elkaar kan houden, tel je ofwel beide (opgeblazen) of riskeer je de echte eruit te filteren (onderteld).
Dit is het moeilijkste scenario om correct af te handelen. De pre-delivery scan is geïsoleerd makkelijk te identificeren — die arriveert minuten voordat iemand klikt. Maar de klik-moment herscan arriveert samen met de echte gebruiker, vanaf een ander IP, met een andere user agent, en creëert een aparte sessie die overlapt met de legitieme.
De follow-upval
Als je weergavemeldingen gebruikt om je follow-ups te timen, zijn botweergaven actief schadelijk. Je belt een prospect "terwijl ze naar je deck kijken" en ze hebben hun e-mail nog niet geopend. Je komt agressief over in plaats van attent. En met URL-herschrijving is zelfs de timing misleidend — de botsessie start op hetzelfde moment als de echte.
Waarom standaard botdetectie niet werkt
De standaardaanpak — user agents controleren tegen een lijst van bekende bots — vangt linkpreviewbots en crawlers maar mist e-mailbeveiligingsscanners volledig. SafeLinks gebruikt opzettelijk echte user agents, specifiek om niet gefingerprint te worden, omdat phishingpagina's die bots detecteren andere content serveren dan aan echte gebruikers.
IP-gebaseerde snelheidsbeperking helpt ook niet. SafeLinks roteert door een pool van Azure-datacenter-IP's, dus elke scan komt van een ander adres. Je kunt niet blokkeren op IP zonder legitieme gebruikers op bedrijfs-VPN's te blokkeren.
Browserfingerprinting (canvas, WebGL, lettertype-enumeratie) werkt niet omdat SafeLinks een volledige Chromium-gebaseerde browser draait. De fingerprint is niet te onderscheiden van een echte Chrome-installatie.
Hoe wij het oplossen: drie lagen van detectie
We bouwden een detectiesysteem dat e-mailbeveiligingsscanners vangt zonder legitieme gebruikers te blokkeren — inclusief gebruikers op bedrijfs-VPN's en proxy's.
Zo stroomt verkeer door de drie lagen. Beweeg over een knooppunt om het pad te volgen:
Laag 1: User agent-matching
Het eenvoudige deel. We controleren binnenkomende verzoeken tegen 60+ bekende botpatronen — linkpreviewbots, zoekmachinecrawlers, headless browsers, HTTP-clientbibliotheken. Als een verzoek zichzelf identificeert als Slackbot of python-requests, wijzen we het onmiddellijk af. Er wordt geen sessie aangemaakt.
Dit vangt ongeveer 40% van het botverkeer. De makkelijke 40%.
Laag 2: Datacenter-IP-detectie
E-mailbeveiligingsscanners spoofen hun user agent maar ze kunnen niet verbergen waar ze draaien. SafeLinks opereert vanuit Azure-datacenters. Proofpoint draait op AWS. Dit zijn bekende hostingprovider-IP-reeksen.
Wanneer een kijker een gedeelde link opent, controleren we hun IP tegen een geolocatieservice die rapporteert of het IP tot een hostingprovider behoort. Als dat zo is, wordt de sessie gemarkeerd als bot.
Dit vangt het merendeel van het e-mailbeveiligingsscannerverkeer. Een kijker die verbindt vanuit "Quincy, Washington" op een Microsoft Azure-IP om 2 uur 's nachts is vrijwel zeker niet je prospect die je offerte leest.
Er zit een subtiliteit in: we blokkeren deze sessies niet. We maken het weergaverecord aan maar markeren het als bot, sluiten het uit van analytics en sturen je geen melding. Dit laat ons valse positieven auditen en geeft gebruikers de optie om botsessies te inspecteren als ze willen onderzoeken.
Hoe zit het met VPN-gebruikers?
Bedrijfs-VPN-gebruikers routeren soms via datacenter-IP's, wat betekent dat Laag 2 een echte gebruiker als bot zou kunnen markeren. Daarom bestaat Laag 3 — het geeft mensen een pad om te "bewijzen" dat ze echt zijn, zelfs als hun IP eruitziet als een datacenter.
Laag 3: Gebaargebaseerde menselijke bevestiging
Dit is de kritieke laag. Het is gebaseerd op een eenvoudige observatie: echte mensen interacteren fysiek met de pagina. Bots niet — of wanneer ze dat doen, hebben hun interacties een kenmerkende signatuur.
Wanneer een sessie aanvankelijk als bot wordt gemarkeerd (vanuit Laag 2), tellen we het niet als echte weergave. In plaats daarvan letten we op daadwerkelijke menselijke invoer:
Wat we monitoren: Muisbewegingen, aanraakevents, toetsenbordinvoer en scrollactiviteit.
Wat we negeren: Paginanavigatie, linkklikken en downloads. Dit is contra-intuïtief — deze lijken sterke signalen van menselijk gedrag. Maar SafeLinks navigeert door 6+ pagina's van elk deck dat het scant. Headless browsers zoals Puppeteer kunnen programmatisch op knoppen klikken en downloads triggeren. Deze acties zijn triviaal te faken. Laagniveau-invoerapparaatevents zijn veel moeilijker overtuigend te synthetiseren.
Het 3-secondevenster: We negeren alle gebaren in de eerste 3 seconden na het laden van de pagina. SafeLinks en Proofpoint vuren hun synthetische events bijna onmiddellijk af — binnen 500 milliseconden na het laden van de pagina. Echte mensen hebben minstens 3 seconden nodig om zich te oriënteren en te beginnen met interacteren. Deze enkele timingdrempel elimineert het merendeel van de synthetische eventruis.
Muisbewegingsanalyse: Wanneer we een muisbeweging detecteren na het 3-secondevenster, loggen we het traject — coördinaten en tijdstempels van maximaal 20 bewegingsevents. Botgegenereerde muisbewegingen volgen geometrische paden (perfect rechte lijnen, exacte cirkels) of vuren één enkel event af. Menselijke muisbewegingen hebben organische versnelling en vertraging, lichte bochten en microcorrecties.
Wanneer een echt gebaar wordt gedetecteerd, wordt de sessie atomair "gepromoveerd" van bot naar echt. Op dat moment — en alleen op dat moment — wordt het weergaveaantal verhoogd en ontvang je een melding.
De timing is belangrijk
Het hele systeem is ontworpen rondom een specifieke race condition: wat gebeurt er wanneer een echte gebruiker een link opent, hun muis één keer beweegt en onmiddellijk het tabblad sluit?
Het bevestigingsverzoek bereikt de server mogelijk niet voordat het tabblad sluit. Browsers annuleren lopende fetch()-verzoeken bij navigatie. Dus gebruiken we sendBeacon() — een browser-API specifiek ontworpen voor fire-and-forget-verzoeken die paginaunloads overleven — als backup. Het laatste beacon draagt de bevestigingsdata samen met de betrokkenheidsmetrieken van de sessie.
Aan de serverkant is de promotie atomair: een enkele SQL-update die alleen slaagt als de sessie nog niet is gepromoveerd. Dit voorkomt dubbeltelling wanneer zowel de reguliere bevestiging als de beacon-backup aankomen.
Wat dit betekent voor je analytics
De praktische impact is aanzienlijk. In onze testen bij enterprise-gerichte salesteams was 15–40% van de schijnbare deckweergaven botsessies — voornamelijk van SafeLinks en Proofpoint. Voor teams die verkopen aan grote enterprises met strenge e-mailbeveiligingsbeleiden was het percentage nog hoger.
Zonder filtering:
- Weergaveaantallen zijn opgeblazen met 15–40%
- "Meest betrokken" prospects zijn mogelijk degenen met de meest agressieve e-mailbeveiliging
- Weergavetiming is onbetrouwbaar — je denkt dat iemand je deck om 14:00 uur bekeek terwijl de beveiligingsscanner het om 13:58 uur opende
- Follow-upsignalen zijn ruis
Met filtering:
- Elke weergave vertegenwoordigt een echt persoon die daadwerkelijk naar je content heeft gekeken
- Betrokkenheidsmetrieken (bestede tijd, bekeken pagina's, voltooiingspercentage) weerspiegelen oprechte interesse
- Weergavemeldingen worden getriggerd wanneer een mens actief betrokken is, niet wanneer een bot voorscant
Botsessies controleren in HummingDeck
De Activiteitenfeed bevat een "Toon botsessies"-filter waarmee je uitgefilterde sessies kunt inspecteren. Gebruik het om te verifiëren dat het systeem correct werkt voor je specifieke prospects — als je ziet dat een legitieme kijker wordt gemarkeerd, zou de gebaarbevestigingslaag ze moeten promoveren zodra ze interacteren met de pagina. Als dat niet gebeurt, neem contact op met support.
De bredere les
E-mailbeveiligingsscanning gaat niet weg — het wordt grondiger. Microsoft en Google breiden geautomatiseerde linkscanning uit naarmate phishingaanvallen geavanceerder worden. Elk analyticsplatform dat vertrouwt op paginalaadmomenten als proxy voor menselijke weergaven zal steeds onnauwkeuriger worden. Dezelfde bots die deck-weergaven opblazen, vervalsen ook e-mail open rates.
Het signaal dat je nodig hebt is niet "werd mijn link geopend." Het is "heeft een mens zich beziggehouden met mijn content." Dat vereist het detecteren van het verschil — en het verschil zit in de gebaren, niet in het laden van de pagina.