# Event email click anomaly investigation worksheet

Copy this file for **one campaign and one review period**. Keep the working copy in your team’s approved location. Use campaign totals and pseudonymous case references here; inspect identifiable recipient records only in the sending platform or another access-controlled system. Do not paste full tracking URLs, email addresses, IP addresses, or personal notes into a widely shared copy.

## 1. Decision and report basis

| Field | Working entry |
| --- | --- |
| Event edition and campaign ID | [ ] |
| Message purpose and intended recipient group | [ ] |
| Decision the investigation must support | [ ] |
| Investigation owner and reviewer | [ ] |
| Sender and source report | [ ] |
| Exported at / reporting window / time zone | [ ] |
| Tracked event link or link ID (no personal token) | [ ] |
| Link destination verified at / by | [ ] |
| Bot filtering at send and at export, per provider | [ ] |
| Metric meaning: unique clickers, all clicks, or link requests | [ ] |
| Comparison campaign uses same definitions and filter? | Yes / No / Unknown; reason [ ] |

## 2. Keep unlike outcomes separate

| Observation | Count | Source, period, definition and caveat |
| --- | ---: | --- |
| Sent / accepted messages | [ ] | [ ] |
| Provider-reported deliveries | [ ] | [ ] |
| Provider-reported unique clickers | [ ] | [ ] |
| Provider-reported total link requests | [ ] | [ ] |
| Requests to the registration link | [ ] | [ ] |
| Destination page activity, if available | [ ] | [ ] |
| Valid completed registrations | [ ] | [ ] |
| Ticket orders or tickets, if relevant | [ ] | [ ] |
| Relevant support replies | [ ] | [ ] |

**Observed gap:** [Describe the difference without subtracting unrelated populations.]
**Unavailable data:** [Name missing reports or fields; do not fill them from assumptions.]

## 3. Pseudonymous event review

Use one row per **case or request cluster** only when recipient-level review is necessary and permitted. Convert timestamps to the zone written above. Do not apply a fixed “seconds = bot” threshold.

| Case ref | Message/reference | Delivery or send time; which? | Request times and link IDs | Different-link cluster? | Provider flag and filter state | Later independent action | Working label and reason |
| --- | --- | --- | --- | --- | --- | --- | --- |
| EXAMPLE-A | example only | 09:00 send; delivery unknown | 09:01 link A, B and C | Yes | Unknown | None verified | Unresolved; review detail |
| [ ] | [ ] | [ ] | [ ] | Yes / No / Unknown | [ ] | [ ] | [ ] |
| [ ] | [ ] | [ ] | [ ] | Yes / No / Unknown | [ ] | [ ] | [ ] |

Working labels: **scanner-like**, **corroborated action**, or **unresolved**. These label an event or cluster, never a person. A later registration or substantive reply deserves its own review even if an earlier cluster looked automated. No website session is not proof of a bot, and a session is not proof that a named recipient made the click.

## 4. Decision and handoff

| Prompt | Decision / evidence |
| --- | --- |
| Which report count remains the provider’s original count? | [ ] |
| Which count is filtered? Can the two views be compared? | [ ] |
| What is the minimum defensible conclusion? | [ ] |
| What remains unresolved, and why? | [ ] |
| Is the registration or ticket destination currently usable? Checked by / at | [ ] |
| Does any planned reminder or follow-up rely only on clicks? | [ ] |
| What action will be taken now, by whom and when? | [ ] |
| What new evidence would change the conclusion? | [ ] |
| Reviewer sign-off and date | [ ] |

Suggested report wording: “The sender recorded **[defined click count]** during **[period]**, with bot filtering **[state]**. The registration system recorded **[defined completion count]** in **[period]**. **[Evidence]** suggests **[bounded interpretation]**; **[missing evidence]** prevents a precise human-click count. We will **[specific decision and owner]**.”