What a Tracked Link Actually Collects — and What It Doesn’t

Ask most vendors this and you get a benefit list. That is not the same question. A benefit list tells you what the product will show you; it does not tell you what is sitting in a database with your client’s name near it.

You need the second answer for three reasons: because somebody will eventually ask you, because you cannot decide whether a tool is proportionate to your work without it, and because the gap between what people assume is collected and what actually is runs in both directions.

Here is the full inventory for a tracked document link, in both columns.

What is collected when somebody opens the link

• That it was opened, and when. A timestamp per visit. This is the entire point of the thing.

• How long the visit lasted. Counted only while the document is actually on screen, so a tab left open in the background over lunch does not come back as a forty-minute read — the honest way to measure reading time explains why that distinction is the whole ball game.

• A random identifier for the browser. A first-party cookie holding a randomly generated value with a one-year lifetime. It is what lets a second visit be recognised as a return rather than as a new person. It is not readable by scripts on the page, and clearing cookies or opening a private window produces a fresh one.

• The IP address the request came from. Used to resolve an approximate country and city, and then coarsened on a schedule — see below.

• The user-agent string the browser sends. A browser name, an operating system name and a device category are read from it. The raw string is never shown back to the owner, because a full user agent is closer to a fingerprint than to a useful fact.

• An email address, only in two specific cases. If the reader was signed in to a Quixli account, that account’s address. If you turned on the email gate, the address they typed into it. Nothing else produces an address.

That is the list. There is no seventh item hiding behind a "and other technical information" clause.

What is not collected, including things people assume are

• Where in the document they read. No scroll depth, no per-section heatmap, no “they spent 40 seconds on the pricing”. This is the single most common assumption and it is wrong. Quixli records that a document was read and for how long, not which part.

• The referrer. The page a reader arrived from is not recorded at all. You will never learn that your proposal link was pasted into a particular internal tool, because the field is not stored.

• Any browser fingerprint. No canvas probing, no screen or font enumeration, no fingerprinting library. The only thing linking two visits is the cookie above, which the reader controls.

• Anything from a third party. No data broker enrichment, no “we matched this IP to a company”, no advertising network. The city lookup runs against a local database, which matters more than it sounds: your reader’s address is not handed to another company in order to answer a question about them.

• Anything about the reader outside your document. There is no cross-site tracking and no profile that follows a reader between documents from different senders.

• Verified identity, ever. This one is worth being blunt about because the industry is loose with it. An address typed into a gate is checked by nobody. Quixli labels it self-reported everywhere it appears, including in the alert email, and the address you mailed the link to is not treated as an identity at all — links forward, so it is a fact about your mailing list rather than about your reader.

What happens to it afterwards

Collection is only half the answer, and the half most vendors leave out. Three things are worth knowing.

The IP address is truncated after 30 days — the last part of an IPv4 address, the host portion of an IPv6 one — so what survives points at a network rather than at a machine. The raw event journal underneath the dashboard is deleted after 12 months. The visit records themselves are kept until you delete them, which is a default worth arguing with rather than accepting: it is chosen so that a dashboard does not silently empty out, and it is not the choice a strict reading of data minimisation would make. There is a one-action erase for every tracking row held about a document, and how long you should keep read data argues that you should use it far more often than you will want to.

Two things that are collected but are not about your reader

Automated fetches are recognised and stored with a flag rather than discarded — link-preview crawlers from chat apps, search engine crawlers, security scanners, scripted clients. They are excluded from every count, every average and every notification. The reason they are stored at all rather than dropped is that a fetch you cannot see is a fetch you cannot audit when a number looks wrong.

Opens by you and by active members of your own workspace are flagged the same way and kept out of the client-facing numbers, which is why proofreading your own proposal four times does not appear as a very engaged prospect.

How to use this list

Three ways. First, as a template for interrogating any tool in this category, including this one: ask for both columns, and treat a vendor that will only give you the first as having answered the question.

Second, as a sanity check on the arrangement itself. Read it again as though you were the recipient rather than the sender — what your reader can and cannot find out about themselves does exactly that, and it is the fastest way to notice whether any of this would bother you if it were pointed the other way.

Third, as the thing you paste into a reply when somebody asks. It is a much better answer than a paraphrase, and what to say when a client asks if you are tracking them has the wording for the sentence that goes in front of it. If the question came from a security team rather than from your contact, the questions a client’s IT team will ask is the one to read. The product side of the same boundaries is set out in full.