Research protocols · Practical guide

Deliverability incident taxonomy worksheet

How can an incident be classified without confusing authentication, acceptance, placement and recipient response? Use this proposed protocol to collect and interpret evidence.

Reviewed · Examples are illustrative

Who this helps: Teams collecting evidence. Limited software observations are identified separately from unperformed campaign experiments and participant studies.

Define the decision

This page is a proposed research protocol, not a completed study or a report of findings. The decision is: How can an incident be classified without confusing authentication, acceptance, placement and recipient response? The observation unit is one incident bounded by sender, receiver, time and symptom. Define the population and owner before collecting records; do not substitute an available convenience dataset without documenting the change.

Work through the procedure

  1. Record SMTP response, authentication evidence, mailbox state, sending changes and scope. Keep raw evidence separate from the proposed cause.
  2. Assign a symptom category first: connection, authentication, rejection, deferral, suspected placement or response decline. Add cause confidence and an unresolved option.
  3. Before collection, write the primary outcome, observation window, exclusion rules and stopping conditions. Preserve excluded observations with a reason rather than quietly removing them.
  4. Pilot the procedure with fictional or owned test data, resolve ambiguous fields, and freeze a dated protocol version before the main run.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

symptom: receiver returns a temporary SMTP refusal; classification: deferral; cause: unconfirmed; next evidence: exact enhanced status and timing
Suggested record fields: observation_id, condition, evidence_reference, outcome, exclusion_reason, reviewer, protocol_version
Status: illustrative record only; no study has been run for this page.

Read the result

A taxonomy supports consistent triage; it does not establish causation. Several symptoms may share a cause, and one incident may have multiple causes. Keep the numerator, denominator and missing evidence visible. If the available observations cannot answer the registered question, report that limitation rather than selecting a more favorable metric after collection.

Collect the evidence

Observation unit: incident.

Redacted incident logs with bounded sender, receiver and time scope.

Classify symptom before proposed cause; preserve unconfirmed and multi-cause cases.

Analysis: Consistent symptom and confidence categories; response decline alone is not placement evidence.

Download the JSON collection template under Source references. Set an owner, eligibility rules, outcome definition, observation window and sample justification before collecting records. Templates contain no participant data or results; keep original private records outside the public website.

Check before moving on

  1. Name the person responsible for collection and review.
  2. Check that the evidence can be inspected without exposing private messages or credentials.
  3. Record deviations from the protocol and analyze their possible effect.
  4. Retain a dated, redacted evidence worksheet with the final interpretation.

Limits and next action

Do not label a response-rate decline as spam placement without independent evidence. Redact addresses and credentials before sharing incident records. Publish results only after the evidence, method and limitations have been reviewed. This protocol provides no benchmark, expected lift or completed-study claim.

Source: Method or workflow reference

Source references

Worked examples are illustrative. Editorial procedures are suggested methods, not measured performance claims or promises of additional product features.

Related guides

Explore the Zintara workflow