Click rate is popular because it fits neatly into one cell. It becomes misleading when it is expected to summarise an entire defence. A click, a password submission, a successful sign-in and a completed fraud are four different events.
- Exposurethe request reached its target
- Risky actionclick, submission or approval
- Technical gatethe control blocks or allows it
- Simulated effectthe capability actually obtained
A human mistake can still end in a block
The Cloudflare case makes the distinction concrete. Three people entered credentials on a fake page, but the physical security keys required by the applications stopped the access described by the company. The submission rate measures how well the lure worked. The block measures how the system behaved after that first mistake.
Both figures are useful. Mixing them together either dismisses a convincing message or declares the defence useless when it did exactly what it was meant to do. The framework I use in the paper therefore follows four stages: exposure, risky action, technical passage and final effect.
The denominator changes the meaning
“A 12% click rate” says very little until we know who actually received the message. A rate calculated across the whole workforce is different from one calculated among delivered messages. Likewise, blocking after an error should be measured among the attempts that reached the control, not among every employee.
Every metric needs a population, a period and a unit. This sounds obvious, yet this is often where a dashboard quietly turns a local observation into a broad conclusion.
The difficulty of the lure matters as well. The NIST Phish Scale describes visible cues and how closely a pretext fits its target. Two campaigns are not comparable if one looks like an obvious test and the other blends into the work expected that day. The scale was designed for email. Calls and video meetings need their own description of the role, pretext and requested action.
Measure reporting and response
Someone may click and then report the message immediately. A quick report can help block the domain, warn other recipients and identify accounts that are already affected. A programme that records only the click counts this contribution as a simple failure.
I would track at least two delays: from the report to the first useful action, and from that action to evidence that the access has ended. An average can hide one dangerously slow case. When the sample is large enough, a median and a high percentile show different parts of the response.
Containment also depends on what was exposed. A password reset does not prove that stolen sessions were revoked. A deceptive OAuth authorisation requires a review of consent and applications. A fraudulent payment may require the finance team to act before anyone can prove that an IT system was compromised.
Training deserves a better test
A fifteen-month study involving more than 14,000 employees questioned the effect of some embedded training used during phishing simulations and found value in collective reporting. A 2025 preprint involving 12,511 participants at a financial technology company found no significant improvement in clicks or reports for the training formats it tested.
These studies do not establish that every form of training is useless. They show why attendance or rule recall is not enough to claim a reduction in risk. The expected effect must be named, lures of similar difficulty compared, and training changes separated from new filters or technical controls.
Training also works better when it reflects the job. Support teams deal with account recovery, finance teams with beneficiary changes, administrators with sessions and delegated access, and everyone with reporting. People do not need a detailed OAuth lecture to know when to stop a request and verify it through a known channel.
A simple and harmless protocol
A useful exercise can remain safe. No real password, unauthorised external access or payment is needed. The criteria are decided before the test. The team records what was delivered, what action occurred, what the system blocked, what people reported and how long containment took.
Operational friction belongs in the results too: false positives, legitimate delays, support requests and exceptions. A control that performs well in a test but drives everyday work into a permanent bypass has moved the risk rather than managed it.
A perfect score would say little on its own. The useful questions are more concrete: which transition is protected, how was that protection verified, and what remains possible afterwards?