Email Reports and Recipient Outcomes

Zero can mean pending data

Sending progress and engagement arrive through different processes. An accepted send can precede delivery or click statistics. Check the time range, provider event availability, campaign state, and recipient records before treating an empty chart as no activity.

Do not publish private emails or complete recipient records in a support screenshot. Use redacted examples and the campaign ID when asking for help.

Reconcile with usage separately

Monthly usage aggregates qualifying sends across campaigns and automations. A campaign's engagement chart is not the monthly invoice. Use the usage guide and statement for the charge recorded.

Retry the failed send, not the whole campaign

SoundSync automatically retries eligible failures that happened before provider acceptance, within a bounded retry policy. Retry failed sends handles the remaining safe failures without resending successful recipients.

If a connection fails after the provider may have accepted a message, its outcome needs review. An uncertain-send retry requires a separate confirmation because it can duplicate a message. Provider acceptance is not proof of inbox delivery.

Deletion and billing are different

A deleted campaign no longer offers its recipient report. Provider-accepted usage remains part of the billing record, even if a message later bounces. Suppressions and old unsubscribe links remain effective; deleting a campaign does not re-subscribe anyone.

Read Growth Flow reporting in the selected range

Choose a day window or All time. GET /api/developer/marketing/growth-flows/summary?range=all returns range:"all" and rangeDays:null. A bounded report returns range:"days" and an integer rangeDays; the default is 30 days. The list endpoint also accepts range=all. The ordinary flow list hides archived flows.

Archiving stops a flow from appearing in the ordinary list without erasing its history. Summary totals include archived activity; totalFlows includes that history, while activeFlows counts active entries. archivedFlows and archivedActivity identify the archived contribution. Do not expect summing only the visible flow cards to reproduce every historical total.

emailsSent, conversions and revenue use the selected reporting window. queuedNow, sentTotal, failedTotal and unresolvedTotal are current queue-lifecycle snapshots, with queueSnapshotAt showing when they were read. They are not alternative names for the ranged send count.

Attributed sales are not payout earnings

Marketing revenue uses attributable net product revenue from the canonical sale records: product subtotal less discounts, product refunds, chargebacks and dispute adjustments, excluding tax. Keep live and test scope aligned. Imported, administrative and migration-only rows are not funded managed-sale revenue. Provider event amounts are not the financial source of truth.

Direct campaign or flow attribution and supported click-to-purchase attribution are different evidence paths; the click path uses a fourteen-day window. This associates a recorded sale with marketing activity, not proof the message caused it. Counts are deduplicated at the reporting level; flow, campaign and whole-workspace totals are not automatically additive.

Campaign recipient reports use actual recipient rows once sending is finalized rather than an earlier audience estimate. Queue/provider reconciliation avoids treating one send as separate queued and sent messages. Acceptance is not proof of inbox delivery, and privacy features can affect observed opens and clicks.

Audience health separates customers from imported contacts

The marketing summary exposes pendingContacts separately from activeMarketingContacts. transactionalOnlyCustomers is derived from linked developer-customer records; imported standalone contacts do not reduce that population by simple subtraction. unscopedTransactionalOnlyContacts is a separate contact count. Pending, unsubscribed, suppressed, bounced, complained and invalid records are not interchangeable, and none is permission to send.

Keep partial totals separate from delivery failures

delivered, providerBounced, providerUnsubscribed and providerComplaints can be null. Do not replace null with zero. performanceSource distinguishes elastic_channel from recorded_events; recordedOpenEvents and recordedClickEvents remain independent of a provider snapshot.

Recorded deliveries counts saved, matched delivery receipts when a complete provider total is unavailable; Report details explains coverage. Do not treat that incomplete count as total delivery or add it to the same campaign provider total. Rates use delivered messages when available, otherwise sent messages, never the incomplete receipt count; inspect engagementDenominator and availability. Detail report openRate/clickRate are raw ratios. Campaign list reports use {percent,status} rate objects. The UI can show Pending sync, History unavailable, Not tracked or Awaiting consistent data instead of a percentage.

Unavailable history is not a failed recipient and must not cause a resend. Preserve accepted sends, consent/suppression rules, known events and attributed net sales. Guarded delivery review/retries concern supported recipient states, not missing analytics. Open/click measurements are not proof of inbox placement or permission to send.

Read coverage before comparing campaigns

Campaign reporting uses saved provider snapshots and recorded events. Delivery receipts are matched to the developer, campaign and recipient using provider identifiers and timing; provider acceptance, opens and clicks do not count as delivery receipts.

Recorded deliveries and Report details make incomplete coverage visible. Across campaigns, use provider totals where available and receipt evidence only for campaigns without a complete provider total. Never double-count both sources for one campaign or relabel a partial aggregate as complete.

Open/click rate denominators use complete delivered totals when available, otherwise sent counts. They never use incomplete recordedDelivered counts. Reporting reads do not send emails, fetch provider history or change recipients, consent, usage charges or financial records. Missing history is not a reason to retry delivery.