Was That a Real Reader or a Link Preview? How to Tell
You send a proposal at 09:14 and by 09:14 it has already been opened. For about two seconds, that is a thrilling notification. Then you realise nobody read a fourteen-page document in four seconds, and you start wondering what else in your numbers is not a person.
This is the most under-discussed problem in link tracking, and the reason is uncomfortable: filtering non-human traffic makes every number smaller, and smaller numbers are harder to sell. Here is what the traffic actually is and how to recognise the part no filter can catch.
The three kinds of non-human open
Preview fetchers
Paste a link into a chat channel or a modern mail client and something fetches it immediately to build the little card with the title and image. Chat platforms, social networks, search crawlers and scripted fetchers all do it, and they identify themselves by name when they do.
These are matched by name and marked, and marked sessions stay out of your counters, your view alerts and your digest. A request that arrives with no identifying browser string at all is treated the same way, on the reasoning that every real browser sends one, so its absence means a script rather than a person.
Search and archive crawlers
Only relevant if your link is reachable — a link posted publicly or indexed somewhere will attract them. They are recognised on the same basis. They matter less than people fear, because a document shared to a named address is not somewhere a crawler can find.
Corporate security scanners
This is the hard case, and honesty demands a plain statement: these are not reliably distinguishable from people. A mail security product that opens every link in every inbound message, in a real browser, to check where it goes, produces a session that looks like a visit. It has a browser string because it is a browser.
How to recognise the scanner that got through
You cannot do it from any single field. You do it from the combination, and four of them together are usually conclusive:
- It arrived immediately. Within seconds or a minute of you sending. Real people take minutes at the very least; the gateway scans on receipt.
- It lasted almost no time. A scanner fetches and leaves. Note that a genuinely short read is a different thing with three real explanations — the tell is the combination with the timing, not the duration alone.
- It never came back. Scanners have no reason to return. This is the single most useful discriminator, and it is the one that requires patience.
- The location does not fit. Security infrastructure sits in data centres, often in a different country from the company you sent to. Country-level location is the reliable field — DB-IP puts it at 95–99% — so a UK client whose “first open” resolves to a hosting region is a strong hint. City is far weaker and should not carry this argument on its own.
If several arrived at once rather than one, that is a different pattern with a different reading — see what a burst of opens means.
Why filtered traffic is kept rather than deleted
Recognised automated visits are recorded and then excluded, which is a deliberately different thing from never recording them. Excluding gives you honest counters. Recording means that if a filter ever gets something wrong, the evidence still exists rather than having been thrown away at the door.
It also means the filter has a cost that is worth stating: no signature list is complete, and a scanner using an ordinary browser string will pass it. Anyone claiming perfect bot filtering is claiming something no one can deliver.
The practical habit that solves most of it
Rather than trying to classify every session, change what you count as the start of the story.
- Discount the first open if it is instant. An open in the same minute as your send is machinery until proven otherwise. Do not let it start a follow-up clock.
- Wait for the second signal. A return visit, a long visit, or a visit from a different environment. All three are things scanners do not do, and any one of them promotes the document from “delivered” to “being looked at”.
- Never quote a first-open time to a client. Even privately, to yourself, in a pipeline note. It is the number most likely to be wrong and the one most likely to be repeated.
The other traffic that is not your client
Non-human opens are one contaminant; the other is your own side. Reads by you and by active members of your workspace are marked and excluded from every client-facing number, alert and digest, and reported separately with no names attached — why internal views are separated rather than counted explains what that does and does not catch.
What you must not conclude
- Not “they opened it instantly, they must be keen”. The first open of the day is the least trustworthy event in the whole dataset.
- Not “the filtering means every remaining view is a person”. It means every remaining view is not a recognised machine, which is a weaker claim and the true one.
- Not “a view from another country means it was forwarded abroad”. Security infrastructure lives in data centres; that is frequently what you are looking at.
What is filtered, what is recorded and what is shown is set out on the features page. And once you are sure a visit was a person, the difference between opened and read is the next distinction to get right.