Amey-Thakur Delivery tracking
Sending is not delivering. Between your system and the user sit providers, filters, devices, and permissions, each capable of dropping a message silently. Tracking is what turns an assumption into a fact.
Method
- Record each stage separately. Queued, sent, accepted by the provider, delivered, opened, acted on. Collapsing these hides where the loss happened.
- Consume provider webhooks. Bounces, deferrals, and complaints arrive asynchronously, and a system that only records the send call knows almost nothing (see webhooks-design).
- Alert on failure of critical messages. A failed password reset is an incident for that user, not a line in a report (see transactional-messaging).
- Distinguish hard from soft failures. A permanent address failure needs list removal; a temporary one needs retry. Treating them alike damages reputation (see email-deliverability).
- Correlate to the triggering event. Tracking that cannot answer whether this order's confirmation arrived is not answering the question support asks.
- Interpret open tracking cautiously. Image blocking and privacy proxies make opens an unreliable lower bound rather than a measurement.
- Retain long enough to answer disputes. Delivery evidence is what settles the argument about whether a notice was sent.
Boundaries
Tracking shows delivery to a device or mailbox, never that a human read it. Open and click tracking involves collecting behavioural data and needs privacy consideration (see data-minimization). Some channels provide no delivery feedback at all, and that limit should be acknowledged rather than assumed away.