Notebook
What we refuse to do

A PDF cannot tell you it was opened

Our dashboard showed opens for tracked PDFs. Every one of them was our own server looking at the file it had just built.

The usual way to know a document was opened is a tracking pixel: a tiny image the reader's software fetches from your server, so the fetch is the receipt. It works in email. It does not work in a PDF, and we shipped a version that assumed it did.

A finished PDF embeds its images as raster content. No mainstream reader goes back to the network when somebody opens the file, so no fetch ever arrives from a recipient. The fetches we were counting had all happened seconds before the file was sent — from our own build process, rendering the document in order to produce it.

Section-level open tracking of a static PDF is architecturally impossible, not merely unimplemented. Every "open" the dashboard showed was our own build process looking at itself.

The fix was not a better pixel. We removed the number. What a PDF can honestly report is a click: the email, phone and website links inside it are rewritten to pass through us, and those fire when a real person follows them, in any reader that opens URLs. So that is what the file reports, and the notice printed at the bottom of every tracked PDF says exactly that — links report when clicked, opening the document is not reported.

The QR code is the other half. It leads to a web version, where a browser is running and section-by-section reading genuinely can be measured. If you need to know which parts were read, send the link. If you send the file, you learn who reached out — which is less, and is true.

Where this happened

The files this post is about. Named so the claim can be checked rather than taken.

  • app/api/pdf-tracked/[cvId]/route.ts
NextColour means measurement