Email Report

Tells you what each email campaign is worth: who it reached, who opened and clicked, and how much money followed.

Use it when you are deciding which campaign to send again, or when someone asks whether the newsletter earns anything.

The question it answers: which emails move money, and which ones just get opened?

Two ways to call it

What you get

Where the numbers come from. A campaign is one Amazon SES (Simple Email Service) configuration set. Product events count exact unique people over the report's range, not estimates or samples, and they are aggregate only: the report returns no personally identifiable information (PII). The Precision notes at the end of this page give the exact warehouse wording.

Reach revenue vs causal revenue

They answer different questions, and reach is always the larger number:

• Reach revenue — money from everyone the campaign touched, whenever they paid. It says "these people are on this list and they spend"; it is not a claim that the email caused the purchase.
• Causal revenue — money from people who bought in the same session as the email, or who were demonstrably influenced by it. It is the narrower, defensible number.

Use reach to size an audience. Use causal to argue that a send worked.

Group form — omit campaign

One row per configuration set (the campaign bucket), ranked by reach revenue.

Single form — supply campaign

That campaign's:

Parameters

The series array — granularity

granularity is purely additive: rows is unchanged, and omitting it returns exactly the previous response. Each point carries sent, delivered, opened, clicked, bounced, open_rate, click_rate and bounce_rate.

The series is engagement only. Reach revenue overlaps across campaigns, so it is deliberately absent — bucketing it over time would read as additive when it is not.

Buckets are labelled with their start date (Monday for weekly), oldest first, and the trailing bucket may be partial — compare it against range.to. Do not add the buckets up to get the range totals — rate metrics are recomputed per bucket. Use rows for totals.

Use Channel Report to compare email against the other acquisition channels.

Ranking, totals and comparison

Three group-form parameters, each independently opt-in. Omit all three and the response is exactly the one you got before they existed — no totals, no totals_meta, no prior.

Re-ranking the list — order_by

order_by is a closed enum per report — the legal columns are listed in the order_by dropdown of the API panel above. Omit it and you keep the default reach-revenue ranking, unchanged. order_dir is asc or desc, defaults to desc, and does nothing on its own.

• The re-rank applies to the complete campaign list, before limit — a campaign the revenue ranking buried below the limit surfaces, rather than the same top-20 reshuffled.
• Nulls sort last in both directions. A campaign with no deliveries has no open_rate; that is unknown, not worst, and floating it to the top of an ascending sort would bury the campaigns you asked to see.
• Ties always break on config_set ascending, so the order is total and repeated calls return the campaigns in the same order.

Whole-set totals — totals

totals=true adds a totals object covering the complete filtered set before limit — every campaign, not just the returned ones — plus a totals_meta sidecar. Anything other than true/false is a 400; nothing is coerced.

Rates are recomputed from their bases over the whole set, never summed or averaged across rows: open_rate is whole-set opens over whole-set deliveries, not the average of the per-campaign rates.

totals_meta.upper_bound names the columns whose total overcounts, because per-row values overlap between rows. Render these as approximations, not counts — this is the same overlap the warning at the top of this page describes:

The causal revenue columns are not marked: they are the MECE per-charge complement, so they sum exactly.

totals_meta.omitted names the columns deliberately left out, so their absence reads as a decision rather than a bug:

A fields trim trims totals with it: neither totals nor prior ever describes a column the response itself does not carry.

Comparing against a prior window — compare_to

compare_to attaches a prior object to each row, measured over a second window:

• prior: null means the campaign did not exist in that window. That is a different claim from a prior object of zeros, which means present and measured zero; conflating them reports a brand-new campaign as flat.
• Prior-only rows are not introduced. A campaign that sent then and is dormant now does not appear — the list is still the current window's.
• The prior window differs only in its dates: same workspace, same filters, same fields.
• Independent of totals. A nested totals.prior appears only when both are set.
• compare_to roughly doubles the cold-path work — every query this report issues runs a second time over the prior window. Only Page Report memoizes its ranked set; this one does not.

Trimming the response — fields

fields is a comma-separated list of response blocks. Omit it and you get every block — it only ever narrows a response, never widens one, so every existing call keeps its exact shape.

?fields=delivery           → the engagement funnel only
?fields=delivery,revenue   → both, still one upstream query
?fields=events             → the campaign list with only the events column

Rules that bite:

• delivery and revenue share one query, entirely. Both are filled by email-channel-performance, so asking for one instead of both saves no round trip — the split between them is response-level. Trimming here buys payload size and context, not latency.
• Trimming does not guarantee a query saved per block. Following from the above, the same query also decides which campaigns are in the list, so it runs whatever you ask for. ?fields=events returns the same campaigns the untrimmed call does. The Precision notes name it.
• Row identity is never droppable. config_set and range survive every trim.
• Empty, duplicated, unknown, and * are all 400s — fields=, fields=revenue,revenue, fields=nope, fields=*. The error names the legal blocks.
• granularity is independent. The series array is not a block.
• fields never lowers the scopes the endpoint requires.
• Reach revenue still overlaps across campaigns after a trim — fields never changes what a number means, only whether it is returned.

Segmenting the series — series_by

Supply series_by alongside granularity (group form only) to split the series by one dimension instead of returning scope-level totals. series then holds one point per (bucket × segment), each carrying key — the segment value — so the response can feed a stacked or multi-line chart directly.

Accepted here: campaign.

granularity=weekly                 → [{ date, <metrics> }, …]
granularity=weekly&series_by=campaign  → [{ date, key, <metrics> }, …]

Notes that bite:

• A source view that has no breakdown for the requested dimension is dropped from the segmented series, not smeared across every segment — copying a scope-level total onto each segment would read as per-segment data and be wrong. So a segmented series can carry fewer metric keys than the flat one.
• Rows whose dimension value is blank are skipped: an unnamed series cannot be labelled or filtered by the caller.
• An unrecognised series_by returns an empty series (not an error, and not a silent fallback to the flat series).
• Segment values may contain spaces (search queries, campaign names) — key is the full value.
• rows is unaffected. Do not sum segmented buckets to get range totals; use rows.