The click happened. Now identify the actor.

The recipient does not receive a naked path from sender to website. Links can be inspected during mail flow, rewritten, checked again when selected, and passed through more than one security layer. Microsoft documents Safe Links URL scanning and rewriting during mail flow, followed by time-of-click verification. Google documents malicious-link checks for Gmail clients and, for some protected third-party clients, a proxied URL that leads through a check before the destination opens.

These protections are doing useful work. They also change the witness. A provider can assess a URL by reputation or an API without contacting your tracking server. Another system may fetch the URL, follow a redirect, or inspect the landing page. The absence of a tracking hit does not mean no security check occurred, and the presence of one does not reveal the actor on its own.

1. T−mail flow

   The receiver parses the message. A protection layer may classify, rewrite, or validate the links before delivery.

2. T+request

   The tracked URL receives GET or HEAD. Its token identifies the message context, not the person behind the request.

3. T+redirect

   The tracker returns the destination. A scanner may stop, while a browser can accept cookies, run JavaScript, and continue.

4. T+outcome

   A session, account action, reply, order, or other event supplies evidence closer to the campaign's purpose.

Keep request time in server precision, but read it beside send and delivery chronology. A cluster arriving moments after receipt, covering several unrelated links faster than a person could evaluate them, is useful machine evidence. It is still a classification, not an identity. Network ownership and user-agent text can be shared, proxied, or forged.

Consider a lifecycle campaign with three links: read the guide, compare plans, and confirm interest. The third URL is implemented as a tracking redirect whose GET handler also writes interested = true. Seconds after delivery, all three URLs are requested from the same network in message order. No cookies return, no JavaScript event arrives, and no product session follows. The automation nevertheless moves the recipient into a sales sequence.

The requests are real. The interpretation is the failure. The pattern is consistent with a link scanner walking the message, but the application had made a safe, fetchable request carry a business side effect. By the time anyone investigates, the false inference has already changed the audience and sent another message.

A security system should be able to inspect a link without volunteering the recipient for anything.

HTTP defines GET and HEAD as safe methods: the client does not request an origin-state change. The durable repair is to make the first GET render a neutral page, then require an explicit button or authenticated product action that uses an appropriate state-changing request. The tracker can record the first request, but the confirmation belongs to the second event.

Email has already learned this lesson in a particularly important place. RFC 8058 explains that anti-spam software sometimes fetches URLs in message headers and can accidentally trigger unsubscriptions. Its one-click mechanism therefore uses a specific, receiver-initiated HTTPS POST with user consent. Do not imitate that protocol for arbitrary actions, but keep its separation of inspection and intent.

Lists of scanner IPs and user agents help, then age. Security vendors change infrastructure, requests pass through shared clouds, and real people use privacy relays. A better model accumulates evidence while preserving the raw event. Each rung answers a narrower question than the one above it.

A likely-human label should be recomputable when the model improves. Keep provenance and the rule version, within a documented minimization and retention boundary, rather than replacing the source event. If a later product action contradicts the first classification, the timeline can be corrected without inventing history.

This follows the same evidence discipline as the field note on email opens. An image request is weak evidence of attention. A filtered link request moves closer to intent. A connected session or product outcome is closer again.

A raw click can start a reversible process. It can attach an observation to the contact, delay a branch while stronger evidence arrives, or ask an integrated product whether a related session occurred. It should not silently change permission, approve a financial action, expose private content, or treat a lead as sales-ready.

In Moosewave automations, the trigger should carry its provenance and confidence into every branch. A rule can say “likely human click plus authenticated pricing session within thirty minutes,” not merely “clicked pricing.” That sentence is longer because the decision is better specified.

Negative events retain priority. An unsubscribe, complaint, suppression, or permission change overrides any engagement score. A scanner hit cannot resurrect consent, and a high score cannot make an ineligible recipient eligible.

Click-through rate usually divides unique clickers by delivered messages. Click-to-open rate substitutes unique openers as the denominator. Both inherit every choice in “unique,” “click,” “open,” and “delivered.” Publish those definitions, the attribution window, bot policy, and any change in classification rules beside the chart.

Keep four counts visible: all requests, requests remaining after machine classification, likely-human sessions, and downstream actions. That prevents a stricter filter from looking like collapsing interest. Compare stable cohorts by provider, message stream, destination, and time period. Read conversions beside unsubscribes, complaints, and placement evidence.

For commercial messages, connect the email chronology to store-side truth through the commerce layer. Attribution can describe a path without proving causation. Use a comparable holdout when the decision requires incremental lift rather than a plausible sequence.

1. 01

   Preserve the request

   Keep message, link, destination, method, time, and limited necessary request context with provenance.

2. 02

   Version the classifier

   Store the rule or model version, confidence, and reasons so historical results can be explained and recomputed.

3. 03

   Look for impossible sequences

   Flag near-simultaneous traversal, message-order walking, unsupported methods, and absent browser continuity as evidence, not proof.

4. 04

   Separate redirect from session

   Do not let a tracker response stand in for a loaded, interactive destination or authenticated visit.

5. 05

   Keep GET free of side effects

   Render information first. Require a deliberate, appropriate request for consequential state changes.

6. 06

   Gate the automation

   Match the evidence threshold to the reversibility and impact of the action the workflow will take.

7. 07

   Join the source of truth

   Use product, CRM, support, and order events to confirm the outcome the email was meant to produce.

8. 08

   Audit drift

   Watch provider mix, unknown traffic, filter rates, and classifier changes before comparing one campaign with another.

Moosewave treats a click as an evidence chain. The raw request stays distinguishable from the classifier output, the connected session, and the event supplied by the customer’s system of record. Reports can show the count at every layer and explain why an event was included or excluded.

The same chain travels into audience and automation decisions. Reversible branches can use low-confidence evidence. Consequential branches can require an explicit or authenticated event. Connected destinations and product events preserve chronology across integrations, while retention and access controls keep the forensic record bounded to its purpose.

Open the interactive Moosewave walkthrough to follow a message from delivery through audience state and downstream action. The useful question is no longer “did it click?” It is “which evidence should this decision trust?”