How to know if someone opened your link

A normal URL cannot tell you that someone opened it. Something around the URL has to record an event: the app where you sent it, a redirect in front of it, or the page at the destination. Even then, the honest conclusion is usually “a request happened,” not “this person read and understood my page.”

Use the signal that matches the decision you need to make:

That is enough to remove useful uncertainty. It is not a read receipt for the web.

Start with the answer you actually need

“Did they open it?” often hides one of four different questions:

1. Did this page receive any traffic after I sent it? Destination visitor analytics are usually enough.
2. Which copy or channel brought the visit? Use a separate campaign label for each distribution path and analytics that reads those labels.
3. Did this specific person access it? The person has to identify themselves, or receive an individual access link whose limits you accept.
4. Did the recipient do the important thing? Record the real action—a reply, approval, form submission, download, or authenticated step—instead of treating a page load as a substitute.

Choose the least intrusive method that answers the real question. Aggregate traffic is enough for “did the launch link get attention?” It is not enough for “did Maria review the contract?” Giving each recipient a traceable link may answer more, but it also collects more and still cannot prove who held a forwarded link.

If you have not decided whether to send a file, document, shared workspace, or public page, solve that first. The online sharing guide compares those delivery jobs. This article starts after you have a browser link to send.

Click, visit, source, and engagement are different

Analytics products use similar words for events recorded at different places. The numbers can disagree without either system being broken.

A click belongs to the link or sending surface

A newsletter platform can record a click before it sends the browser to the destination. A short-link service does the same by receiving a request at its own address, recording it, then redirecting.

That means a click can exist without a destination visit. The recipient might close the tab, lose the connection, hit a security warning, or be represented by an automated request. Conversely, someone can copy the final destination into a browser and create a visit without touching the tracked link.

A visit belongs to the destination

A destination visit is recorded when the page's server or analytics code sees the page request. Server-side counting can record a request even if scripts are blocked. Browser-side analytics can observe more interaction, but only when its code loads and is allowed to send data.

Neither automatically knows a person's name. “Unique visitor” also depends on the product's rule: a cookie, an account, a device identifier, or a short-lived combination of request properties can all produce different totals.

A source can be observed or assigned

The HTTP Referer header is a clue about the page that initiated a navigation. It is not guaranteed. Browser referrer policy can omit it, reduce it to an origin, or suppress it on a particular link.

UTM parameters are different. You add values such as utm_source and utm_campaign to a destination URL, then compatible analytics reads them. Google's campaign URL documentation describes them as labels for referring campaigns. The parameters do not count anything by themselves, and the value utm_source=client-email is a label you wrote—not independent evidence about who clicked.

Engagement is a rule, not mind reading

An analytics tool can define engagement from time, page views, or an event. For example, Google Analytics currently calls a session engaged if it lasts more than ten seconds, includes a key event, or reaches at least two page or screen views. That is a useful operational definition, documented in its engagement-rate guide. It is not proof that someone read the argument or approved the work.

For a client handoff, define the action that actually matters. A submitted approval, completed form, downloaded file, or direct reply is more useful than inventing intent from time on page.

Four ways to observe a shared link

1. Use analytics on the destination page

This is the simplest method when you control the page and only need to know whether it received traffic. Publish the page, note the baseline, send the link, then inspect the visitor trend after a reasonable interval.

It works well for a public launch, portfolio update, prototype shared for stakeholder review, or client page where aggregate attention is the job. It does not identify the recipient. If the page is public, your own check, another visitor, a preview service, or a bot can also affect the total.

Do not turn “one new visit after I sent one link” into certainty. The timing is consistent with the recipient opening it. It is not proof.

2. Add campaign labels to links you distribute

Use a distinct campaign URL when you need to compare known distribution paths: an email, a chat, a social post, or two versions of the same message.

https://example.com/proposal?utm_source=client-email&utm_medium=email&utm_campaign=august-follow-up

This method requires destination analytics that collects those parameters. It answers “which labelled link preceded this measured session?” more readily than “who was the person?” Links can be copied or forwarded, and a recipient can strip the query string.

Keep people out of the label. Do not put a name or email address in a UTM value. Google's PII guidance for Analytics explicitly prohibits recognizable personal information in URL paths, parameters, and campaign fields. Other analytics providers and applicable laws have their own rules, so inspect the system you actually use.

3. Put a tracked redirect in front of the destination

A short link or redirect under your control records the request, then sends the browser onward. It is useful when you do not control the destination or when the click itself is the distribution metric.

The key limitation is structural: the redirect sees its own request, not what happens after it. A scan can request the tracked address. The destination can fail. A person can leave before it loads. A forwarded link keeps the original tracking token.

If you issue one random link per recipient, you can associate a request with the link you distributed. Say exactly that. Do not silently upgrade “Alice's link was requested” to “Alice read the page.” Access control or authentication is needed when verified identity is genuinely part of the job.

4. Ask for an identifiable action

For approval, access, or audit work, make the important action explicit. Ask the recipient to sign in, submit an approval, send a short form, download from an authenticated page, or reply in the channel where the work was sent.

This produces a stronger signal because the action is closer to the business question. Authentication can establish which account acted; a reply establishes what the sender chose to say. Neither proves comprehension, and both add effort for the recipient.

Often the best version is simply: “Could you confirm that the page opens, and send your notes by Thursday?” That sentence records the outcome you need without building a surveillance system around a normal relationship.

Bots, previews, and privacy change the count

Every measurement method has false positives, false negatives, and a definition of “unique.” Before acting on a small number, check the likely distortion.

• Bots and link previews: messaging apps, search crawlers, monitoring tools, and security systems can request a URL without a person reading the page. The card those apps build comes from og:title, which is one of four things called the website title and the one most often left unset.
• Prefetching: a browser may fetch a likely destination before navigation. The Sec-Purpose: prefetch header can identify some such requests, but MDN marks it as not available across all major browsers. Absence of the header is not proof of a human click.
• Security processing: Microsoft documents Safe Links scanning, rewriting, checks before delivery, time-of-click verification, and in some cases asynchronous URL detonation in its Defender documentation. That does not mean every scanner reaches every destination; it means automated processing around shared links is real.
• Blockers and failed loads: a tracked redirect may count while destination analytics is blocked or the page never completes. Server and browser analytics can therefore disagree.
• Forwarding and shared devices: a recipient-specific URL identifies the distributed token, not necessarily the person holding it later.
• Self-visits: opening the final link to test it may create the first event. Record your baseline or use a documented exclusion where the tool supports one.
• Missing source: referrer policy, app behavior, and copied URLs can remove the route by which a visitor arrived.

An email-open report is a separate signal again. It often depends on remote content rather than the destination link. Apple's current Mail Privacy Protection description says remote email content can be downloaded in the background regardless of whether the recipient engages. Do not use an email pixel as proof that the linked page was opened.

What Birta can tell you today

As checked on August 19, 2026, Birta's visitor analytics answer a deliberately small question: did a published project receive approximate human traffic, and how did that change by day?

The count works without placing a persistent visitor identifier in the browser. When an existing published HTML page is requested, Birta combines the project, service-calendar day, IP address, and browser user-agent string into a salted one-way token. A matching token for that project on the same day counts once. The token changes the next day and is different for another project.

That privacy choice defines the number:

• a person returning on another day can count again;
• changing network, browser, or device can create another daily token;
• people whose request properties match can be combined;
• obvious bot user agents are skipped on a best-effort list, not with perfect bot detection;
• the current collector does not inspect the prefetch header described above.

Owners can see a total and time series for the last 7 days, 30 days, or 3 months. The report is owner-only and calls the metric “Visitors.” Read that label as an approximate daily visitor count, not a registry of people.

This means you can publish a client page, send its stable address, and see whether the project starts receiving visits. If you sent it to one person and the count moves, that is a useful reason to follow up normally. It is not a named read receipt.

Birta also does not create the attention being counted. The product boundary is explained in what we will never build: the page helps turn existing attention into an action; it does not generate demand.

Use the weakest tracking that answers the job

Start with aggregate measurement. Add channel labels when the channel matters. Require identity only when access, approval, or an audit record makes that extra step worth the privacy cost and recipient friction.

Four rules keep the setup proportionate:

• Be transparent. Tell people when access or individual actions are logged, especially when the record is tied to an account or recipient-specific token.
• Collect less. A total may answer the question without storing a person's identity, exact location, device history, or browsing trail.
• Keep labels impersonal. Put campaign names in URLs, not names, email addresses, or sensitive details.
• Set a reason and a retention period. “Maybe useful later” is not a decision about why individual-level data should exist.

Privacy obligations depend on purpose, technology, visitors, and jurisdiction. For one current example, the UK ICO's statistical measurement guidance draws a clear line between aggregate statistics and monitoring individual visitors, and still requires information and safeguards for its statistical exception. “Cookieless” is a description of one mechanism, not a universal compliance verdict.

Then use a simple follow-up rule:

• No measured visit: check the link yourself once, account for reporting delay, then resend or ask whether it arrived.
• A visit but no action: do not infer rejection or approval. Ask for the response you need.
• The intended action happened: use that action, not the earlier click count, as the record that moves the work forward.

Frequently asked questions