What Your Reader Can and Cannot Find Out About Themselves

Every article about tracked links is written from the sender’s chair. This one is written from the other one, because the person opening your document has a set of questions too, and you will be the one answering them.

It is also the fastest way to work out whether the arrangement you are part of is a fair one. If the reader’s side of it reads badly, it is bad, whatever the dashboard looks like.

What is on their screen

Open a Quixli document and there is a fixed bar at the foot of the viewport that says: “The author of this document can see view statistics.” It is present from the first paint, on every kind of share, and it does not go away when you scroll.

It deliberately does not list the fields. That is a real design decision with a real cost, and it is worth stating the cost: a reader who wants the specifics cannot get them from the notice. The reasoning is that an enumerated wall of technical detail is read by nobody and functions as a shield rather than as information, whereas one plain sentence is read by almost everybody. Reasonable people disagree with that trade. You should know it was made.

If the sender switched on an email gate, the reader also sees why they are being asked: that the person who shared the document wants to know who is opening it. The gate is the one moment where the reader is asked to do something rather than told something.

What a reader can work out for themselves

A technically curious reader can establish quite a lot without any cooperation, and it is better that you know what they can see than that you assume they see nothing.

• That a cookie was set. One first-party cookie with a random value. It is visible in any browser’s storage inspector. It is marked so that scripts on the page cannot read it, which means the sender’s document cannot be made to leak it, but the reader can see it exists.

• That the visit is being reported while it happens. Anyone watching their network tab will see the document telling the sender’s service that it is being read. There is no way to hide this and no attempt is made to.

• That their address was not collected unless they gave it. If they did not sign in and did not type anything into a gate, there is no address attached to their visit — and they can verify that by the absence of anywhere it was asked for.

• That nothing is fingerprinting them. There is no canvas probing, no font or screen enumeration, no fingerprinting library. A reader who checks will find the cookie and the standard request headers, and that is all.

What they cannot find out from the document

• Who else has opened it. A reader sees nothing about other readers.

• Whether the sender has been notified yet, or what the notification said.

• Which of their own visits were counted and which were discarded as automated.

• What the sender’s screen actually shows — that depends on the sender’s plan, and a reader cannot tell from the outside whether their name, location and device are visible or withheld.

That last one is worth a sentence of its own, because it is genuinely asymmetric. On a free plan the reader’s label, device, location and per-browser identifier are withheld from the sender outright — nulled before the data ever reaches the sender’s browser, rather than blurred behind an upgrade prompt with the answer underneath. On a paid plan they are shown. The reader has no way to know which of those they are in. The plans set out where that line falls.

What a reader can actually do about it

This is the part where most vendor writing goes quiet, so here it is with the unflattering bits included.

• Clearing cookies works. The link between two visits is that one cookie and nothing else, so clearing it — or reading in a private window — genuinely makes the next visit look like a new reader. It is not a placebo. It is the reason a unique-reader count is published as a floor rather than as a total, which what “unique readers” actually counts goes through in detail.

• Not loading the link at all works completely. A document read from a projected screen, a screenshot, a printout or a forwarded export produces no visit. There is no fallback that catches those.

• Do Not Track and Global Privacy Control do nothing here. Quixli does not currently detect or act on either signal on shared documents. If a reader has set one and expects it to be honoured, it is not being honoured, and pretending otherwise would be the single most damaging thing this article could do.

• There is no reader-facing opt-out and no cookie banner on a shared document. The reader is told; they are not asked. Whether that is adequate where you are is a question about your jurisdiction and your compliance position, and the instruments involved names them without pretending to be advice.

The request that has to go to you, not to us

If a reader wants to know what is held about them, or wants it erased, the person who has to answer is the sender. Under the GDPR the sender is the controller — they decided the document would be measured and why — and the tool is the processor acting on their instructions.

Practically, that means a reader emailing the vendor gets redirected to you. So the useful preparation is on your side: be able to say what is held, and be able to delete it. A document owner can erase every visit, event and captured address for one document in a single action, across all of its links, and it is immediate and irreversible. It cannot recall an alert email that already went out.

A sender who can do that within a day of being asked has a stronger position than one with a long privacy policy and no mechanism.

The fairness test

Read the four bullets under "what a reader can actually do" again and ask whether you would find that acceptable if you were the one opening the document.

For most professional readers, most of the time, the answer is yes: they were sent something they asked for, they were told, and the sender knows when it was read and nothing more. Where it gets uncomfortable is the reader who never asked for anything — the colleague it was forwarded to. There is no clean fix for that, only care about what you conclude.

The wider version of that argument is in is it ethical to track a document you sent, and what a tracked link collects and what it does not is the field-by-field inventory a reader would want if they asked.