Automated link visits
Security tools may inspect links. Validate filtering or annotate the uncertainty before treating every event as employee behavior. Keep raw event counts separate from unique-recipient counts.
Measurement guide
Phishing simulation reporting with context.
A report should help the next person make a decision. Show what happened, how you counted it, and what your team will change.
Use these definitions and a worked example to make campaign results easier to interpret.
Metric definitions · Worked example · Review framework
01Definitions
Define the metrics before comparing them
The formulas below use delivered recipients unless stated otherwise. Your platform may calculate metrics differently; document the actual definition used in each export.
| Metric | Suggested calculation | Interpretation |
|---|---|---|
| Delivery rate | Delivered recipients ÷ intended recipients × 100 | Shows campaign reach. Separate bounces and exclusions. |
| Click rate | Unique recipients with a recorded click ÷ delivered recipients × 100 | A recorded interaction; validate scanner and tracking effects. |
| Submission rate | Unique recipients with a simulated submission event ÷ delivered recipients × 100 | Count the event without retaining real secrets. |
| Report rate | Unique recipients who reported the exercise ÷ delivered recipients × 100 | Use only if reporting can be reliably reconciled with recipients. |
| Training completion | Completed assignments ÷ relevant assignments × 100 | Shows completion, not proof of changed behavior. |
| Time to report | Elapsed time from delivery to a recipient's first report | Describe the distribution and account for working hours. |
02Worked example
Read a campaign with 200 intended recipients
Illustrative example, not Phishmake customer results: a campaign targets 200 employees. Ten messages bounce and 190 are delivered. Among delivered recipients, 19 record a click and 38 submit a verified report. Twenty follow-up assignments are created and 15 are completed by the review date.
The delivery rate is 190 ÷ 200 = 95%. The click rate is 19 ÷ 190 = 10%; the report rate is 38 ÷ 190 = 20%. Follow-up completion is 15 ÷ 20 = 75%. These percentages describe different denominators and should not be combined into one score.
A person may both click and report, so those groups can overlap. Do not subtract reports from clicks or assume the remaining employees recognized the message. They may have been away, missed the message, or ignored it for other reasons.
03Data quality
Check what the events actually mean
Open tracking
Image blocking, preloading, and privacy controls can distort opens. An open event does not prove that a person read the message, and a missing event does not prove they did not.
Reporting coverage
Reports may arrive through a mailbox, help desk, or reporting tool. State which channels were included, deduplicate recipients, and identify gaps before publishing a report rate.
Changing audiences
New starters, absences, team changes, and exclusions affect comparisons. Preserve campaign scope so a change in the audience is not mistaken for a change in behavior.
04Trend analysis
Explain differences between campaigns
NIST's Phish Scale assesses human phishing detection difficulty. That context helps reviewers distinguish a change in the message's difficulty from a change in employee decisions.
Compare similar audiences, work schedules, scenario types, and delivery conditions. Show the size of each group alongside its percentage. Avoid league tables for tiny teams, where one event can create a large apparent change.
Source: NIST Phish Scale User Guide
05Report structure
Give each audience a useful next action
- 1
Start with the decision
State the question the exercise was intended to inform and the main finding. Separate observed events from explanations that still need investigation.
- 2
Attach the context
Record the dates, audience size, scenario, exclusions, metric definitions, and limitations. Use aggregate results for broad leadership updates.
- 3
Connect follow-up
Summarize assignments, completion, feedback, reporting delays, and process problems. Keep individual records restricted to the appropriate owners.
- 4
Assign and revisit
Record an action, responsible team, and review date. The next report should say whether that action happened and what evidence is available about its effect.
Common questions
What is a good phishing simulation click rate?
There is no universal good rate. Scenario difficulty, audience, delivery, prior learning, and tracking all affect results. Use consistent definitions and compare similar campaigns, with reporting and follow-up evidence beside the click rate.
Is reporting more useful than measuring clicks?
Reporting shows whether a person used a defensive process, while clicks show a different type of interaction. Both need context. Measure reports only when the relevant channels and recipients can be reconciled, and examine whether the team can respond to those reports.
Can a simulation report prove that training worked?
A single report cannot establish that training caused an improvement. Repeated comparable exercises, employee feedback, operational outcomes, and documented changes give a more useful picture, but other factors can still influence the result.
Does every platform measure all these metrics?
No. The metric framework is an evaluation guide. Verify which events, report channels, filters, exports, and training records your platform supports before promising a particular report to stakeholders.
Sources & further reading
Published by Phishmake · Updated
Keep building your program
All resourcesPut it into practice
Connect activity with follow-up.
Review Phishmake's campaign events, employee records, and training workflow with your reporting requirements in mind.