/Docs
ETEN

Email metrics

What it is

The core campaign-analytics numbers, sourced from Smaily: delivered emails, opens, clicks, unsubscribes. They describe how the email performed; for the engine's revenue impact see engine revenue and incrementality.

How it is computed

  • Delivered = sent minus bounces.
  • Open rate = opens / delivered.
  • Click rate = recipients who clicked / delivered.
  • Campaign statistics are synced from Smaily and keep updating for up to ~35 days after sending — late opens and clicks change the numbers for weeks.
  • Test sends that the operator has excluded from analysis are not part of campaign aggregates.
  • Computed from events. Smaily reports statistics for regular campaigns only. Automation (workflow) sends and A/B split sends are missing from that list, so for those the engine counts the numbers itself from the individual email events it receives: recipients = send events, opens/clicks/bounces/ unsubscribes = the matching events (opens counted per contact, so the same person opening the same send twice counts once), date = the first send. Such rows carry a "Computed from events" marker in the campaign table. Events are kept for 30 days, so a send older than that can be undercounted; a long-running automation can even show an open rate above 100%, because we saw more of its opens than of its sends. A send with no send events at all (it predates event collection) is left out entirely rather than shown as a row of zeros.

How to interpret it

  • Open rate is inflated. Apple Mail's privacy protection (MPP) opens emails automatically even when no human looked at them. Use open rate to compare your own campaigns against each other (the noise is roughly uniform), not as absolute truth or for cross-channel comparison.
  • Click rate is the most honest email-level signal — a click requires a human. The engine's rescue logic (engagement states) also trusts only clicks.
  • A small number of unsubscribes is normal hygiene; a sharp spike after one campaign is a content or frequency signal.

Common misreadings

  • "Yesterday's campaign is missing from analytics" — a campaign enters analytics after it reaches COMPLETED status in Smaily and the sync has run (it runs regularly). Also check that it was sent from the same Smaily account that is connected to the engine. Automation and A/B split sends arrive by the other route (see "Computed from events" above) — they appear once their send events have been polled.
  • "An automation send shows different numbers than Smaily's own report" — expected: those rows are counted from email events, not from Smaily statistics. Look for the "Computed from events" marker.
  • "The numbers changed after the fact" — yes, for up to ~35 days; that is the late-opens re-sync, not a bug.
  • "Lots of opens but no revenue" — see the MPP note and the "influenced purchase" explanation under attribution.

Technical background

Sync: lib/smaily/campaigns.ts (list + statistics for COMPLETED campaigns finished < 35 days ago; idempotent upsert). Drafts (DRAFT) are never brought into the campaign list, and campaigns deleted in Smaily are removed from the list on the next sync. Cron sync-smaily-campaigns + admin "Sync now". Test-send flag: smaily_campaigns.excluded. Event level (opens/clicks per customer): Smaily action-log polling → email_events.

Event-derived rows: lib/smaily/derived-campaigns.ts — automations are named from workflows.php / autoresponder.php, A/B sends from the action log's own campaign_name (both name variants are shown, "A / B"); the aggregates come from email_events. Marked by smaily_campaigns.source (campaign | workflow | events), which also keeps these rows out of the campaign-list deletion reconciliation.

Last updated: 2026-08-06