The short answer
Can you tell if someone has opened a link? Not from the URL itself. A URL records nothing. Something around it has to record an event: the app you sent it from, a redirect in front of it, or the page at the destination. Even then the honest conclusion is "a request happened," not "this person read my page."
So: yes, partly, through one of four signals. Each answers a different question, and each is easier to fool than it looks.
Start with the question you actually have
"Did they open it?" hides one of four questions:
- Did the page get any traffic after I sent it? Destination analytics are enough.
- Which copy or channel brought the visit? A separate campaign label per path.
- Did this specific person access it? They have to identify themselves, or get an individual link whose limits you accept.
- Did they do the important thing? Record the real action: a reply, an approval, a form, a sign-in.
Pick the least intrusive method that answers your question. Aggregate traffic answers "did the launch get attention?" and not "did Maria review the contract?" If you have not yet decided whether to send a file, a document or a public page, the online sharing guide compares those first.
Four ways to observe a shared link
1. Analytics on the destination page
When you control the page and only need to know whether it received traffic: publish, note the baseline, send, look at the trend later. Server-side counting works even when scripts are blocked; browser-side analytics sees more but only when its code loads.
It fits a launch, a portfolio, a prototype shared for review or a client page. It does not identify anyone, and your own check, a preview service or a bot moves the same counter. "Unique visitor" is the product's rule (cookie, account, device, request fingerprint), so two tools give two totals. If the page is on Birta, this method needs no setup: see below.
2. Campaign labels on the links you send
Give each distribution path its own URL to compare them: email, chat, social, two versions of one message.
https://example.com/proposal?utm_source=client-email&utm_medium=email&utm_campaign=august-follow-upUTM parameters are labels, not counters: Google's campaign URL documentation describes them as labels for referring campaigns that destination analytics has to read. They answer "which labelled link preceded this session?", not "who was the person?" Links get forwarded and query strings get stripped. Keep people out of the label: Google's PII guidance prohibits personal information in URLs and campaign fields.
The observed alternative, the HTTP Referer header, is a clue rather than a guarantee:
referrer policy
can omit it, cut it to an origin, or suppress it on one link.
3. A tracked redirect in front of the destination
A short link you control records the request, then sends the browser onward. Useful when you do not control the destination, or when the click itself is the metric.
A click and a visit are recorded in different places, so they disagree without either being broken: the redirect can count while the destination fails, gets blocked or is closed before it loads, and someone can paste the final URL and visit without touching the tracked link. A scanner requests tracked addresses too.
One random link per recipient ties a request to the link you distributed. Say exactly that. Do not upgrade "Alice's link was requested" to "Alice read the page": a forwarded link keeps the original token.
4. An identifiable action
For approval, access or audit work, make the action explicit: sign in, submit an approval, send a short form, download from an authenticated page, or reply where the work was sent. Authentication establishes which account acted; a reply establishes what the person chose to say. Neither proves comprehension, and both add friction.
Often the best version is "Could you confirm the page opens and send your notes by Thursday?" That records the outcome you need without building surveillance around a normal relationship.
| Method | Best for | Strongest safe conclusion | Main blind spot |
|---|---|---|---|
| Destination analytics | public or one-to-many pages | the page received measured traffic | identity and reading |
| Campaign-labelled URL | comparing known distribution paths | a visit carried your label | forwarding, stripping |
| Tracked redirect | counting requests before a destination | the tracked address got a request | destination load and human intent |
| Explicit action | access, approval, accountable handoff | an account or recipient acted | comprehension, added friction |
What fools every method
Before acting on a small number, check the likely distortion:
- Bots and link previews. Messaging apps, crawlers and security systems request a URL
without anyone reading. The preview card comes from
og:title, one of four things called the website title. - Prefetching. A browser may fetch a likely destination before navigation; the
Sec-Purpose: prefetchheader marks some of these but is not available across all major browsers. - Security scanning. Microsoft documents Safe Links rewriting, time-of-click checks and URL detonation in its Defender documentation.
- Self-visits, shared devices, forwarding. Your own test is the first event; a per-recipient token identifies the token, not who holds it now.
- Email opens are a different signal again. Apple's Mail Privacy Protection downloads remote content whether or not the recipient engages, so a pixel is not proof the page was opened.
"Engagement" is also a rule, not mind reading: Google Analytics calls a session engaged after ten seconds, a key event or two page views (engagement-rate guide). Write "the tracked link received one request", not "the client read it".
What Birta can tell you today
A published Birta project shows approximate visitors by day, with totals for the last 7, 30 and 90 days, to the owner only. No cookie and no tracking script: a visitor is a one-way daily token built from the request, so the same person counts once a day and obvious bots are skipped on a best-effort basis. It does not say who the visitor was or which link they used.
That is method 1 with nothing to install. Publish the page, send its address, and if the count moves after you sent one link, follow up normally. A reason to ask, not a read receipt.
Use the weakest tracking that answers the job
Aggregate measurement first, channel labels when the channel matters, identity only when access, approval or an audit record is worth the recipient's friction and the privacy cost. Tell people when individual actions are logged, keep names and emails out of URLs, and decide a reason and a retention period. The UK ICO's statistical measurement guidance separates aggregate statistics from monitoring individuals and still requires information and safeguards for the former; "cookieless" is a mechanism, not a compliance verdict.
Then the follow-up rule:
- No measured visit: check the link yourself once, allow for reporting delay, then resend or ask whether it arrived.
- A visit but no action: do not infer approval or rejection. Ask for the response you need.
- The action happened: use the action, not the click count, as the record.
Want to see whether your page gets opened? Publish it on Birta
Describe the page in Birta's chat and its agent builds and publishes it, or connect the agent you already use. Send its address, and the project shows approximate visitors by day. No pixel, no redirect, no script.
