Delivery rate is not an open rate

In the Delivery Intelligence Lab we ask every participant to split one campaign export into accept, retry, display, and tap before they are allowed to discuss creative. The first surprise is almost always the same: accept is high, display is materially lower on a popular Android OEM, and tap sits somewhere finance did not expect.

Vendor platforms have good reasons to report “delivered” early. Their job is to show that they handed a payload to Apple or Google. Your job is to learn whether the operating system showed it, whether a collapsed stack hid it, and whether a battery restriction delayed it until the user no longer cared.

Retries look like volume

If your worker retries without a stable message id, the same logical send can appear twice in a delivery column. Volume goes up. Unique devices do not. We have seen CRM teams celebrate a “record send” that was mostly backoff noise after a brief APNs timeout.

Collapsed notifications

Android collapse keys are a gift to users and a problem for naive impression counts. If three promotional pushes collapse into one shade on the tray, counting three impressions is fiction. Label collapse as its own outcome or you will overstate the delivery layer in the Grid Method.

What to put on the slide instead

Three numbers, same campaign: platform accept, estimated display (with OEM caveats written in plain language), and tap. If you cannot estimate display, write “unknown” rather than reusing accept. Unknown is an honest cell. Reused accept is a political one.

Related reading: token health before creative. Invalid tokens inflate the denominator before any of this even starts.