Skip to content

Metrics glossary

This page defines every metric Kreel computes and shows where the number you see in the API differs from what the dashboard displays. Every ratio metric is computed by exactly one formula in Kreel’s backend, reused by the dashboard, the REST API, MCP tools, and the query DSL, so the same metric name means the same math everywhere. The differences documented below are about representation, a 0-1 fraction versus a percentage, gross versus net revenue, not different formulas.

For the full rules behind revenue and refunds, see Revenue accounting. For how date ranges and period comparisons work, see Dates and comparisons.

Net revenue divided by order count, both taken from the same refund-correct basis. Because the order count is not mixed with a differently-filtered count from a cached table, AOV always reconciles with the headline revenue number for the same period.

Each ad platform’s (Meta, Google, TikTok) or Klaviyo’s own conversion-value report, tagged revenue_kind: "platform_attributed" on MCP responses. The provider’s attribution model and click/view windows apply; this is not necessarily last-click attribution, and equal labels do not make different platforms directly comparable. Attributed revenue overlaps across channels, the same sale can be attributed by more than one platform, so it is never additive. Do not add Meta’s attributed revenue, Google’s attributed revenue, and store revenue together to get a “total” - see Revenue below. Klaviyo email revenue counts campaigns and flows sent by email only; revenue from SMS sends is reported separately as SMS revenue.

The share of a campaign’s sends that bounced, computed over recipients. Klaviyo’s flow-series reporting does not measure bounces, so Kreel reports bounce rate for email campaigns only, never for flows.

Unique clicks divided by emails delivered, not raw click events (which count every click, including repeats from the same person) and not divided by recipients. The dashboard shows this as a percentage. The API (Klaviyo REST v2, the compact REST API, MCP get_performance, and the query DSL) returns a 0-1 fraction to 4 decimal places, for example 0.0821 for 8.21%. One exception: the get_entities tool’s metrics_7d rollup and the legacy email-summary avg_* fields still use 0-100 percentages.

Conversions divided by clicks, for ad-platform entities such as campaigns, ad sets, and ads. Returned as a ratio to 4 decimal places, and omitted (not shown as 0) when clicks is 0.

Net merchandise revenue (excluding tax and shipping) minus current-cost COGS, plus refunded COGS, minus an optional blended fulfillment cost. Always ex-tax/ex-shipping regardless of your brand’s Revenue Basis setting, and always current-cost, not cost-at-sale. Only reported once cost coverage across the window reaches 80% of sold revenue; below that, Kreel reports coverage only, never a margin computed from an incomplete catalog. See Contribution margin for the full model, cost precedence, and coverage rule.

Meta and Klaviyo report conversions as whole numbers. Google reports conversions as fractional numbers, because its data-driven attribution can assign part of a conversion, for example 0.63, to one ad and the rest to another. Kreel never floors these to integers - a low-volume Google campaign showing “2.4 conversions” is correct, not a bug; flooring it to 2 would overstate cost per acquisition.

Spend divided by count, where count is orders at the account level and platform conversions or purchases at the campaign, ad set, or ad level. Because the denominator changes by level, CPA is not directly comparable between an account-level number and a campaign-level number. Currency value, 2 decimal places.

Spend divided by clicks. Currency value, 2 decimal places.

Spend divided by impressions, times 1,000 - the cost to reach a thousand impressions. Currency value, 2 decimal places; guarded on impressions being present, not on spend.

Clicks divided by impressions. Ratio, 4 decimal places.

Google Analytics 4’s count of purchase events on the connected web stream. It measures what GA4 observed, not your orders: Shopify orders remain the canonical sales count, and the two can differ because of tagging, consent, and attribution.

The share of a campaign’s sends that were actually delivered, computed over recipients. Kreel does not compute this for flows.

Google Analytics 4 engaged sessions divided by sessions, both summed over the whole range. An engaged session lasted 10 seconds or more, had a key event, or viewed 2 or more pages.

Kreel’s blended efficiency metric: store revenue (net) divided by total paid ad spend across Meta, Google and TikTok combined. It is the same ROAS formula, value divided by spend, applied to a blended numerator and denominator instead of a single platform’s own numbers. Email and organic carry no spend, so they are excluded from the denominator. Surfaced as a summary block when the MCP get_performance tool is called with platform="all" and entity_type="account", and on the per-brand rows of get_portfolio - both show the numerator and denominator alongside the ratio so it is checkable, not a black box. It is null with a reason, never 0, when no Shopify store is in the account scope (or, on Portfolio, the brand has no store connected).

Blended contribution margin divided by total paid ad spend - the same ratio shape as MER, with a margin numerator instead of a revenue numerator. Null when there’s no ad spend to divide by, or when margin isn’t reported because cost coverage is too low. See Contribution margin.

A customer’s first included order (per the brand’s Revenue Basis and sales-channel settings), counted over one of two scopes depending on whether the account filter is narrowed:

  • Brand-new - first included order anywhere across every connected account in the brand. This is the default, shown whenever the account filter is set to all accounts.
  • Account-new - first included order within the currently selected account subset only, so a newly connected store or market doesn’t read as having zero new customers just because those customers bought elsewhere in the brand before.

Narrowing the account filter to anything less than every account switches the label and the count from Brand-new to Account-new. Currently shown only on the Overview page’s Verify-mode Shopify tile, labeled “New customers (brand)” or “New customers (store).”

Unique opens divided by emails delivered, not raw open events and not divided by recipients. The dashboard shows this as a percentage. The API returns a 0-1 fraction to 4 decimal places. The legacy avg_open_rate field predates this definition: it is a percentage (not a 0-1 fraction) blended across every campaign and flow in the selected period, rather than reported per entity - keep that difference in mind if the two numbers do not match for a single campaign.

Order count follows two different, deliberate rules depending on the table. Headline order counts (the dashboard, revenue endpoints, MCP get_performance) include voided and cancelled orders, matching Shopify’s own Total Sales report - they add roughly nothing to revenue, but must still appear in the count. The pre-computed trend and cohort tables exclude voided and cancelled orders, since a never-charged order is just noise in an AOV or retention average.

The share of Google Analytics 4 sessions that included a purchase key event (GA4’s sessionKeyEventRate:purchase), recalculated from summed purchase sessions and sessions for the range. It is not purchases per session, the generic key-event rate, or Shopify orders divided by GA4 sessions. It is unavailable, shown as a dash, when purchase is not marked as a key event in the GA4 property.

A customer is overdue when the whole Brand-calendar days since their last order exceed the 75th percentile (p75) of time between orders for customers whose first order had the same top product. A product with fewer than 30 gaps between orders falls back to the whole store’s repeat gaps, and one-time buyers are judged on the store’s first-to-second order interval. Past the 90th percentile, or past the Brand lapse threshold, the customer is lapsed instead; RFM New Customers are never overdue. The flag is recomputed with every weekly RFM run, so overdue, lapsed, not-due and insufficient-history customers sum to the week’s RFM population. Overdue share is overdue customers over all scored customers. Revenue at risk is an estimate from trailing history, not a forecast: each overdue customer’s lifetime net revenue divided by their tenure in years (at least one). Shown on Customers → Segments with the rule and each interval’s n; agents read the aggregates through the query DSL’s at_risk_summary table.

The share of customers with at least N orders who went on to place order N+1, for example the share of first-time customers who ordered a second time. It is observed from retained order history, not predicted. The 90-day repeat rate counts only customers whose Nth order is at least 90 days old, so newer customers who have not had the full 90 days are left out of the denominator rather than counted as non-repeaters. Median days to next order is the median gap between order N and order N+1 among customers who placed both. Shown on Performance → Repeat; first-product cohorts overlap, so their rates are never summed.

Every identified customer is scored 1-5 on recency (days since the last order), frequency (orders) and monetary value (spend) against the Brand’s own quintiles, and placed in one of 11 fixed segments such as Champions, At Risk or Lost. A person who buys in two of the Brand’s stores with the same email is one customer, counted once. RFM runs weekly; each run keeps a snapshot for the Brand-calendar ISO week, retained for 104 weeks, so segment migration (for example Champions who slid to At Risk over 4 or 13 weeks) is counted from stored snapshots rather than estimated. Champions share and At Risk share are those segments’ customers over all scored customers. At-risk revenue is the trailing-365-day net revenue, ending yesterday, of customers now in At Risk and Can’t Lose Them. Shown on Customers → Segments; agents read the aggregates through the query DSL’s rfm_segment_summary and rfm_migration tables.

The fraction of an acquisition cohort, customers who first ordered in a given month, that ordered again in a later snapshot month. It is a stored fraction per cohort/snapshot-month pair - never sum it across snapshots; average it if you need to aggregate. Related customer-segmentation fields, RFM recency, frequency, and monetary scores and segment labels such as champion or at_risk, are available through the query DSL’s customers_rfm table for agents building retention or win-back analyses.

Refunded units divided by sold units for a product, over the selected window - a read-time refund-activity signal, not a predictive return probability and not RTO/logistics data. Because a refund can land on an order from an earlier period, this rate can legitimately exceed 100%. Shown per product on Performance → Products next to a multiple of the store-wide baseline rate (for example “2.3× store average”) when a product runs notably above it.

Store revenue is what Kreel means by “revenue” on the dashboard headline and in the MCP get_performance tool: the refund-correct net total, real money the store took in for the window. The dashboard labels it Store revenue; Shopify’s Net sales excludes tax and shipping, and its Total sales books refunds on the refund day. It already subtracts refunds that landed inside the window for orders created before it (a cross-period refund). get_performance also returns gross_revenue (before that subtraction) and refund_adjustment (the amount subtracted), so an agent can see exactly what changed. The pre-computed tables behind trend charts and cohorts, and daily_channel_summary.revenue in the query DSL, store gross Shopify revenue only, not the refund-correct figure - a small gap between a headline number and a trend-chart number for the same period is expected, not a bug. Selecting that column through the query DSL returns a notices entry pointing back to get_performance for the net figure. See Revenue accounting for the full rules, including cross-period refunds and the Revenue Basis (tax and shipping) setting.

Klaviyo-attributed revenue divided by recipients, on the send-date basis, available for email campaigns, flows, and individual flow messages. The query DSL exposes it on the email_campaigns, email_flow_daily and email_flow_messages tables. Under group_by it is recomputed as summed revenue over summed recipients, never an average of per-row ratios. Email and SMS are reported separately; a query that groups them together returns a notice saying they were blended. Ratio, 4 decimal places.

Klaviyo-attributed revenue divided by delivered messages, on the send-date basis. It follows the same aggregation and channel rules as revenue per recipient, and is valid for SMS as well as email. Ratio, 4 decimal places.

Value divided by spend. Ratio, 2 decimal places, for example 3.45. ROAS is always one platform’s own attributed conversion value over that platform’s spend, labelled by its source. Platform claims overlap, so Kreel never sums them across platforms into a “blended ROAS”; for blended efficiency use MER, described above.

Google Analytics 4 sessions on the connected web stream, paid and unpaid. GA4 users and new users are not Shopify customers and are not reported.

The share of a campaign’s delivered emails marked as spam, computed over delivered sends. Like bounce rate, this is reported for email campaigns only - Klaviyo’s flow-series reporting does not measure spam complaints for flows.

Ad spend from Meta and Google. Dated performance spend is converted into the brand’s base currency using each row’s historical exchange rate before aggregation. Undated structural amounts, including Meta ad-set daily budgets, lifetime budgets, and bid amounts, remain in the source account’s native currency and must not be combined across mixed-currency accounts.

The share of a campaign or flow’s delivered emails that triggered an unsubscribe, computed over delivered sends.

  • Revenue accounting - the full net-vs-gross, cross-period refund, and Revenue Basis rules.
  • Contribution margin - the unit-cost margin model, cost precedence, and coverage rule.
  • Dates and comparisons - how date ranges, windows, and Compare To periods are resolved.
  • MCP data tools - the tools that return these metrics (get_performance, get_entities, compare, get_portfolio).
  • Query DSL - exact column types and precision for every metric, table by table.

Email support@kreel.ai if a number doesn’t match what you expect.