Get aggregate email statistics

The window the response covers (echoed back from the request, day or hour grain), plus data_as_of, the freshness boundary the data is current to.

Distinct email messages accepted, counted at the message level (one per accepted send regardless of recipient count) across the whole requested period. This field counts messages. delivery.accepted counts recipients, so the two values are not comparable (a single message to 500 recipients is 1 here and up to 500 there).

Delivery counts and rates for the scope of the containing row (a time bucket, a breakdown dimension, or the whole period). Lifecycle counts identify distinct recipients that reached the named stage in scope; oob_bounces counts distinct failure events. Period summaries count each identity once per metric across the whole window, so adding time-bucket distinct counts can overstate the summary. Event time determines attribution; send time does not. A recipient delivered on Monday counts in Monday's row. A recipient who bounced and then succeeded on a retry can appear in both bounced and delivered. Very large counts are close estimates rather than exact tallies.

These counts are successive lifecycle stages, so a recipient can appear in more than one:

• rejected: Happens before any send attempt, from suppression, policy, or a generation failure.
• deferred: A temporary in-flight delay that is still being retried.
• bounced: A delivery failure, with its own hard, soft, admin, block, and undetermined sub-types.
• complained: Post-delivery spam feedback.

Each rate is a fraction in the range 0 to 1 and is null when its denominator is zero. accepted is reported only where it can be attributed (time buckets and the period summary). Breakdown rows omit it.

Engagement counts and rates for the scope of the containing row (a time bucket, a breakdown dimension, or the whole period). opens, opens_non_prefetched and clicks count distinct engagement events (deduplicated occurrences). The unique_* fields count distinct recipients. unsubscribes counts distinct unsubscribe events. An event counts in the time bucket when it occurs, even if the message was sent in an earlier bucket. Counts are deduplicated with a scalable approximate counting method, so very large counts are close estimates rather than exact tallies. Each rate divides the counts in this scope and is null when its denominator is zero.

Latency percentiles (p50, p95, p99) in milliseconds for the bucket. On the summary endpoint these are computed across the whole period rather than per bucket. Three families are reported:

• processing: Time from accepting the send to handing the message off for delivery. Measured per processed recipient; null when no recipient in the bucket has reached the processed stage.
• delivery: Time from handoff to the receiving mail server accepting the message, dominated by recipient-side delivery behavior. Measured per delivered recipient; null when no deliveries occurred in the bucket.
• total: End-to-end time from accepting the send to delivery, and the number most worth watching against your own delivery targets. Measured per delivered recipient; null when no deliveries occurred in the bucket.

Each family is reported independently. A family is omitted when no qualifying event contributed a latency measurement in the bucket. This also applies when the workspace has not recorded latency for that stage yet. The processing family can therefore be present while delivery and total are absent. A client must handle a missing family, and a null p50/p95/p99 within a present family, by rendering a placeholder rather than assuming a number.

The same statistics for the equal-length, inclusive period ending the day immediately before the requested start, together with the change between the two periods. Present only when compare=previous_period is requested. The change is already computed, so a percentage difference needs no second request.