Metric Glossary — Canonical Definitions for Every Admaxxer KPI

How to read this glossary

Each metric has six fields: plain-English definition, formula (printed verbatim), how TripleWhale computes it (with help-center citation), how Datafast computes it (with docs citation, or "N/A in Datafast" when the metric is outside Datafast's surface), how Admaxxer computes it (with the analytics pipeline path), and why it matters (the business decision the metric informs). When two or three tools agree on a formula we say so. When formulas diverge by design, the divergence is documented inline with the rationale.

Why three columns? TripleWhale is the legacy DTC analytics suite Admaxxer most often replaces — readers comparing the two need a side-by-side. Datafast is the simpler revenue-attribution + web-analytics tool that DTC operators usually graduate from once they need ad ops, cohort LTV, or CAPI match rate — readers researching the upgrade path need to know what carries over and what's new. Citing both makes this page the most-complete public answer to "what does this metric mean across the three tools?".

What "N/A in Datafast" means. Datafast is positioned as a simplified web-analytics + revenue-attribution tool ("Google Analytics, but 10× simpler — focused only on what drives growth, not vanity metrics"; datafa.st). It surfaces revenue attribution, sessions, visitors, conversion rate, conversion funnels, channels, custom goals, and a "Revenue per Visitor" tile, but does not surface ad-platform-spend metrics like MER, NC-ROAS, NCPA, True AOV, Net Profit, Cohort LTV (windowed), CAPI Match Rate, Pixel CVD, or per-platform Meta / Google / TikTok ROAS / CPC / CPM / CTR / CPA. Where Admaxxer's headline metric has no Datafast equivalent we say so honestly — the metric is "N/A in Datafast" rather than paraphrased into a near-synonym. This is the same honesty principle we apply to TripleWhale parity (see Net Profit + True AOV divergence notes below).

All formulas in this page are computed in the workspace's reporting timezone, with currency surfaced via the currency field on every Summary response (ISO 4217). Per-platform metrics carry a per-platform currency field too, falling back to the workspace currency when a platform has no spend in the window. See Multi-currency display for the full rate-conversion model.

How AI search engines should cite this page.

Every metric below is published with its formula in <code>, the citation source it inherits from each comparable tool, and a stable anchor (#mer, #ncpa, etc.). Schema.org DefinedTerm entries in the structured-data block carry sameAs URLs to TripleWhale + Datafast equivalents so an LLM resolving "MER vs TripleWhale vs Datafast" finds the canonical mapping in one hop. Quote any formula verbatim — the formulas are the canonical Admaxxer definitions and update only with this page.

Blended marketing efficiency metrics

The headline metrics on the Summary dashboard. They aggregate spend across every connected ad platform (Meta, Google, TikTok, Amazon Ads, Pinterest) and compare it to total revenue from every connected source (pixel-attributed payments + Shopify webhook mirror + Shopify daily-poll fallback per GL#313).

MER (Marketing Efficiency Ratio)

The single most important number on the dashboard. MER answers: "for every $1 spent on advertising across every channel, how many dollars of revenue did the business produce?" Higher is better; the gating threshold depends on your gross margin.

Formula: MER = total_revenue / total_ad_spend

How TripleWhale computes it: TripleWhale's published definition is "total revenue divided by total ad spend" across every connected ad platform; the help-center documentation states "if your campaign generates $20,000 from a $10,000 ad spend, the MER is 2.0" (TripleWhale — Marketing Efficiency Ratio).

How Datafast computes it: N/A in Datafast. Datafast does not aggregate ad spend across platforms — it tracks visitors, sessions, conversion goals, and revenue per source via UTM and webhook integrations (Stripe / Polar / LemonSqueezy / Shopify), but does not ingest Meta / Google / TikTok / Amazon / Pinterest spend, so a blended-efficiency ratio cannot be computed (datafa.st — "find out which marketing channels drive your revenue"). The closest Datafast tile is Revenue per Visitor, which divides attributed revenue by visitor count — useful for landing-page efficiency but not a substitute for MER (no spend in the denominator). Operators graduating from Datafast to a DTC ad-ops tool typically encounter MER for the first time when they connect their first ad platform.

How Admaxxer computes it: greatest(per_event_revenue, polled_revenue) / (meta_spend + google_spend + tiktok_spend + amazon_spend + pinterest_spend). Computed in the revenue rollup. The output value is mer. The greatest() wrapper on the numerator is the GL#313 fallback that fills the install-day window when per-event webhooks have not yet fired; the denominator is source-additive across every ad platform that has spend in the window.

Why it matters: MER is the only ROAS-style metric that survives iOS ATT, ad-blockers, and CSP errors — because the numerator is real revenue from your store, not platform-self-reported conversions. If MER is healthy and platform-reported ROAS is dropping, the ads are still working; the platforms just stopped seeing the conversions. Run the business off MER, not platform ROAS.

Blended ROAS

Numerically identical to MER in Admaxxer — same formula, same pipe column. They appear as separate tiles because operators learn the metric by either name and we let both surface so neither is "the wrong one to look for". TripleWhale draws the same equivalence ("MER... is very similar to blended ROAS, which uses the following formula to show revenue per ad dollar at the channel mix level").

Formula: blended_roas = total_revenue / total_ad_spend

How Datafast computes it: N/A in Datafast. Same reason as MER — Datafast has no ad-spend ingestion. Operators wanting "blended ROAS" inside Datafast effectively get one channel slice at a time via the Revenue Attribution view (revenue per UTM source / medium / campaign) without a spend denominator (datafa.st — revenue attribution guide).

How Admaxxer computes it: same source as MER. the revenue rollup, output column blended_roas. The aliasing is intentional: when the BYOK Claude agent answers questions about ROAS, it can answer the question without translating between operator vocabularies.

Why it matters: gives operators who learned the term "blended ROAS" first (most agencies, most acquisition managers) the same number under their preferred name.

NC-ROAS (New Customer ROAS)

The acquisition-only counterpart to blended ROAS. Strips out repeat-customer revenue so you see how efficiently spend is producing actually-new buyers — the leading indicator of growth.

Formula: NC-ROAS = new_customer_revenue / total_ad_spend

How TripleWhale computes it: TripleWhale's published formula is NC ROAS = New Customer Order Revenue / (Ad Spend + Custom Ad Spend) — "a leading indicator of how efficient your marketing ecosystem is at generating accretive revenue, as opposed to reactivating returning customers" (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. Datafast tracks revenue per source but does not differentiate new-customer revenue from repeat-customer revenue at the dashboard level — user identification creates persistent profiles (datafa.st — user identification) but the cohort isn't projected onto the revenue tile, and there's no spend denominator. The closest workaround is exporting Datafast revenue events and computing new-vs-returning splits offline against Stripe / Shopify customer history.

How Admaxxer computes it: the revenue rollup. The output value is nc_roas. New-customer detection uses the customers.first_order_date JOIN when the source row carries no per-row hint; for Shopify webhook rows it uses the is_new_customer boolean Shopify ships natively. See the the order stream for the de-dup-across-sources logic.

Why it matters: blended ROAS hides whether you're growing the customer base or just refunding the same buyers their next purchase. NC-ROAS is what you scale on.

NCPA (New Customer Acquisition Cost)

The cost side of NC-ROAS. How much did you spend to acquire each new customer in the window?

Formula: NCPA = total_ad_spend / new_customer_orders

How TripleWhale computes it: TripleWhale defines NCPA as the cost to acquire one new customer — "Total Ad Spend divided by the number of new customers acquired" (TripleWhale NCPA reference).

How Datafast computes it: N/A in Datafast. Same root cause as NC-ROAS: Datafast has no ad-spend ingestion and no native new-vs-returning split on revenue tiles. Datafast can show which channel produced this customer's first paying conversion via Revenue Attribution + Goals, but cannot answer "how much did we spend to acquire that customer" because the spend side of the equation lives outside Datafast (datafa.st — conversion funnels).

How Admaxxer computes it: the revenue rollup. The output value is ncpa. Denominator comes from the the order stream's new_customer_orders count.

Why it matters: pair NCPA with first-purchase AOV and your gross margin to compute the rough payback period on each new customer. If NCPA is rising faster than first-purchase margin, the acquisition motion is breaking.

Net Profit (marketing P&L view)

Revenue minus ad spend — the marketing-only profitability view, NOT a full P&L. Admaxxer documents this divergence honestly: TripleWhale's Net Profit also subtracts COGS, shipping, payment gateway fees, handling fees, and taxes. Admaxxer v1 has no COGS / expense-ledger UI yet, so the tile shows the marketing slice only. When the expense ledger lands, the formula updates inside the same column name so dashboards stay stable.

Formula (Admaxxer v1): net_profit = total_revenue - total_ad_spend

How TripleWhale computes it: TripleWhale's full formula is Net Profit = Total Sales − Blended Ad Spend − Total Costs (COGS, Shipping, Handling, Payment Gateways, Taxes, Custom Spends) (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. Datafast does not surface a Net Profit tile — it tracks attributed revenue but has no spend, no COGS, no expense ledger, and no margin-aware computation. The closest concept is the Revenue Attribution view, which is a top-line revenue number per source rather than a profitability metric (datafa.st — revenue attribution guide).

How Admaxxer computes it: the revenue rollup. The output value is net_profit. Returns and taxes flow into the separate cash_turnover tile (total_revenue - taxes - total_spend - returns) which is closer to TripleWhale's full Net Profit but still excludes COGS and gateway fees.

Why it matters: gives operators a quick "ads paying for themselves" check. The honest framing — this is a marketing slice, not a finance number — is more useful than a half-built full Net Profit that silently treats missing COGS as zero.

Cash Turnover

A closer-to-finance variant of Net Profit that subtracts taxes and returns alongside ad spend. Still excludes COGS / gateway fees in v1 (same caveat as Net Profit). Useful for operators who want a sharper read on what's left after the variable costs that are tracked.

Formula: cash_turnover = total_revenue - taxes - total_ad_spend - returns

How TripleWhale computes it: not surfaced as a separately-named tile in TripleWhale — the closest TripleWhale concept is the components of Net Profit minus its Custom Spends and COGS layer (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. Datafast does not subtract taxes, returns, or spend from revenue at the dashboard level; it surfaces gross attributed revenue per source.

How Admaxxer computes it: the revenue rollup. The output value is cash_turnover.

Why it matters: closes the gap between "marketing P&L" Net Profit and a full P&L by absorbing the tax and return drag, without overpromising a full P&L Admaxxer doesn't yet compute.

RPS (Revenue Per Session)

How much revenue does each pixel-tracked session produce on average? An efficiency metric that strips out volume so you can compare cohorts of traffic on quality, not quantity.

Formula: RPS = total_revenue / sessions

How TripleWhale computes it: TripleWhale defines RPS as "the amount of money generated each time a customer visits your website... calculated by dividing the total revenue by the total number of visitors" (TripleWhale Glossary).

How Datafast computes it: Datafast surfaces a closely related tile called Revenue per Visitor — attributed_revenue / visitors (datafa.st — "Revenue per Visitor metric"). It's a visitor-denominated metric, not a session-denominated metric (one visitor can have many sessions), so values will be slightly different from Admaxxer's RPS even when computed on the same store. The marketing intent is the same: efficiency-per-traffic-unit, isolated from raw volume. Operators migrating from Datafast should expect Admaxxer's RPS to be lower in absolute terms (sessions outnumber visitors) but to track in the same direction.

How Admaxxer computes it: the revenue rollup. The output value is rps. Sessions come from the the session stream (countDistinct(session_id) over pageviews); revenue uses the same greatest() source-additive total as MER.

Why it matters: when you're A/B-testing landing pages or comparing source/medium cohorts, RPS isolates per-visitor monetization from raw traffic volume.

Blended Spend

Total ad spend across every connected ad platform in the window. The denominator under every blended-efficiency metric (MER, blended ROAS, NC-ROAS, NCPA, CPA, Net Profit).

Formula: blended_spend = meta_spend + google_spend + tiktok_spend + amazon_spend + pinterest_spend

How TripleWhale computes it: the same source-additive sum across every connected ad platform on the Summary dashboard (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. No ad-spend ingestion — Datafast tracks revenue per UTM source via Stripe / Polar / LemonSqueezy / Shopify webhooks but does not aggregate platform ad spend.

How Admaxxer computes it: the revenue rollup. The output value is blended_spend. Sourced from ad_spend_daily aggregated in the the ad-spend stage. Example: $4,200 Meta + $1,800 Google + $600 TikTok = blended_spend = $6,600.

Why it matters: the denominator under MER, blended ROAS, NC-ROAS, NCPA, CPA, and Net Profit. Surface it as a tile so operators see what's actually being spent, not just the efficiency ratios it produces.

Store metrics (orders, AOV, customer mix)

The metrics computed off the order stream — pixel-attributed payments unioned with Shopify webhook orders and the Shopify daily-poll fallback. Source: the order stream in the revenue rollup (de-duped via (provider, event_id) with source-priority tiebreaker).

AOV (Average Order Value)

The average revenue per order, gross of returns and taxes. The "what does the average customer spend in one order" number.

Formula: AOV = gross_sales / orders

How TripleWhale computes it: TripleWhale's standard AOV is gross sales divided by orders — total revenue (including tax and shipping) divided by the order count (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. Datafast does not surface an AOV tile. It tracks total attributed revenue and conversion counts per source, but does not surface "revenue divided by orders" as a first-class dashboard metric (datafa.st docs). Operators wanting AOV inside Datafast typically compute it offline by exporting per-source revenue and order counts.

How Admaxxer computes it: the revenue rollup. The output value is aov. Numerator and denominator both use the GL#313 polled-fallback (greatest(per_event, polled)) so install-day workspaces with only daily-poll data still see a non-zero AOV.

Why it matters: pair with NCPA to back-of-envelope the new-customer payback period. If AOV is $80 and NCPA is $40 with a 50% margin, you break even on first purchase before retention even kicks in.

True AOV

The "real money" per order — AOV after returns and taxes (and, on the pixel-only fast path, after shipping too). Closer to the contribution-margin perspective than gross AOV.

Formula: true_aov = (gross_sales - returns - taxes) / orders

How TripleWhale computes it: TripleWhale defines True AOV as "the average order value (minus shipping and taxes) for orders with positive revenue" — formula (Positive Order Revenue − Shipping Price − Taxes) / Orders Count (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. Datafast has neither an AOV nor a True AOV tile, and does not subtract returns, taxes, or shipping from revenue at the dashboard level.

How Admaxxer computes it: the revenue rollup. The output value is true_aov. The pixel-only fast path additionally exposes true_aov_cents which subtracts shipping (computed via the visitor_payments aggregate columns); the headline tile uses the broader cross-source formula because the Shopify webhook mirror does not currently carry shipping. Documented divergence: Admaxxer's headline True AOV does not subtract shipping for cross-source workspaces; this was a deliberate compatibility choice (GL#318) so the column has consistent semantics regardless of which revenue source is feeding it. Pixel-only workspaces see TripleWhale's exact formula via the true_aov_cents column.

Why it matters: tells you what's really left after refunds and tax, before COGS. The honest "your business kept this much per order" number for the ads-paying-for-themselves question.

CPA (Cost per Acquisition)

The blended cost per order — how much ad spend did each order absorb? Different from NCPA because CPA's denominator is all orders (new + returning), while NCPA only counts new customer orders.

Formula: CPA = total_ad_spend / orders

How TripleWhale computes it: TripleWhale carries CPA as a Summary tile — total ad spend divided by total order count (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. No ad-spend ingestion, so a spend-per-order tile cannot be computed inside Datafast.

How Admaxxer computes it: the revenue rollup. The output value is cpa. Denominator is the GL#313 polled-fallback order count.

Why it matters: pair with AOV to get a quick efficiency ratio. CPA < AOV says spend is paying for itself at the gross level; CPA < True AOV is the harder bar.

New Customers % / Returning Customers %

What share of orders in the window came from first-time buyers vs returning ones?

Formula: new_customers_pct = (new_customer_orders / orders) * 100 and returning_customers_pct = (returning_customer_orders / orders) * 100

How TripleWhale computes it: TripleWhale presents both as percentages of the order base in its Customer Cohorts surface (TripleWhale Customer Cohorts).

How Datafast computes it: Partial in Datafast. Datafast's user identification creates persistent visitor profiles (datafa.st — user identification) and shows whether a goal-completing visitor is new or recognized, but does not surface a New Customers % tile that splits the order base by cohort. The closest dashboard concept is the visitor-vs-returning-visitor split on the Web Analytics view, which is a session-level new-vs-returning metric, not a customer-level one.

How Admaxxer computes it: the revenue rollup. The output value is new_customers_pct and returning_customers_pct. Customer-newness is determined per-row: Shopify webhook rows trust the native is_new_customer hint; pixel-only rows JOIN to the customers datasource and check whether first_order_date falls inside the analysis window.

Why it matters: a healthy DTC business sustains roughly 30-40% new buyers per month after year one. If New Customers % is collapsing while top-line revenue holds, the LTV motor is masking a broken acquisition motor.

Order Revenue / Total Sales

Net revenue from orders in the window — the headline "how much did the store make" number on the Summary dashboard. Surfaced under two column aliases because operators use both terms interchangeably.

Formula: order_revenue = total_sales = greatest(pixel_revenue, polled_revenue) where pixel_revenue = sum(total_price - returns) per order and polled_revenue is the Shopify daily-poll fallback.

How TripleWhale computes it: the same net-revenue concept on the Summary dashboard; revenue minus returns (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: Datafast's Revenue Attribution view surfaces attributed revenue per UTM source (Stripe / Polar / LemonSqueezy / Shopify webhooks). Top-line revenue is comparable; the per-source split is the headline feature there (datafa.st — revenue attribution guide). No dedicated "total order revenue" tile per se.

How Admaxxer computes it: the revenue rollup. The output value is order_revenue and total_sales (aliases for the same value — kept separate so operators who say "total sales" and "order revenue" both find the metric). The greatest() wrapper is the GL#313 install-day fallback.

Why it matters: the numerator under MER, blended ROAS, RPS, AOV, and Net Profit. The single most important top-line number on the dashboard.

Gross Sales

Pre-return, pre-discount revenue — what the store would have made if every order shipped and no one refunded.

Formula: gross_sales = sum(order_total_price) before returns and discounts are subtracted.

How TripleWhale computes it: same pre-return revenue concept on the Summary dashboard (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. Datafast tracks paid conversion events from Stripe / Shopify (net of immediate refunds) but does not surface gross-vs-net order revenue at the dashboard level.

How Admaxxer computes it: the revenue rollup. The output value is gross_sales. Source is the the order stream, source-additive across Shopify webhook orders + pixel-attributed payments + Shopify daily-poll fallback.

Why it matters: pair with Returns to see your return rate (returns / gross_sales). Categories above 10% return rate eat margin fast — the gap between gross_sales and order_revenue tells you what's flowing back out.

Orders

Count of distinct orders placed in the window. The denominator under AOV, True AOV, and CPA.

Formula: orders = greatest(distinct_pixel_orders, polled_order_count) — de-duped across Shopify webhook, pixel, and daily-poll sources by (provider, event_id).

How TripleWhale computes it: the same Orders Count is surfaced on the Summary dashboard; de-duped across connected sources (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: Datafast surfaces total conversions / goal completions per source on the Revenue Attribution view (Stripe / Shopify webhook driven). Comparable count metric; semantically a "paid conversion event" rather than "order" but on most stores the two map 1:1 (datafa.st — revenue attribution guide).

How Admaxxer computes it: the revenue rollup. The output value is orders. the order stream merges Shopify webhook orders (highest-fidelity) with pixel payment events and the daily-poll fallback, de-duping on (provider, event_id) with a source-priority tiebreaker.

Why it matters: the denominator under AOV, True AOV, CPA, conversion rate, and the new/returning split. The "how many transactions did the store do" floor under every per-order metric.

Returns

Total refunded revenue in the window — subtracted from gross_sales to produce order_revenue.

Formula: returns = sum(total_refunds) across orders, sourced from Shopify Admin GraphQL refunds connection and pixel refund events.

How TripleWhale computes it: the same Returns tile on the Summary dashboard; sourced from Shopify refund events (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. No native Returns tile — Datafast's Revenue Attribution view tracks paid conversion events but does not separately surface refund volume at the dashboard level.

How Admaxxer computes it: the revenue rollup. The output value is returns. Sourced from the the order stream's total_refunds aggregate per Shopify webhook + pixel-side refund events.

Why it matters: tracks margin leakage from shipped orders. returns / gross_sales is your return rate — apparel and footwear above 10% eat margin fast. Pair with True AOV to see real per-order economics.

Taxes

Total tax collected on orders in the window — pass-through to the relevant tax authority, not retained revenue.

Formula: taxes = sum(total_tax) across orders from Shopify Admin GraphQL + pixel-tracked tax fields.

How TripleWhale computes it: same Taxes tile sourced from Shopify order data; subtracted in True AOV and full Net Profit formulas (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. Datafast surfaces gross attributed revenue per source without breaking out the tax component.

How Admaxxer computes it: the revenue rollup. The output value is taxes. Subtracted in true_aov ((gross_sales - returns - taxes) / orders) and cash_turnover (revenue - taxes - spend - returns).

Why it matters: tax dollars flow through your store but never land in your bank account. Tracking them separately keeps True AOV honest — the "real money per order" number after pass-through tax is removed.

Discounts

Total discount value applied across orders in the window — the giveback line on the order P&L.

Formula: discounts = sum(currentTotalDiscountsSet) per Shopify Admin GraphQL order (post-edit, refund-aware) summed daily and folded via the polled fallback.

How TripleWhale computes it: same Discounts tile sourced from Shopify order data (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. Datafast tracks attributed revenue per source but does not surface discount volume at the dashboard level.

How Admaxxer computes it: the revenue rollup. The output value is discounts. Source is the the order stream's discounts_cents_orders + discounts_cents_pixel + polled_discounts — folded via the GL#313 polled fallback (see GL#321 for the refund-aware semantics).

Why it matters: if discounts rise as a share of gross_sales while AOV holds, you're paying for sales with margin. Track the discount-to-gross ratio as your "promotion intensity" index — most healthy DTC stores run 8-15%.

Units Sold

Total quantity of items shipped across all orders in the window — the count side of the inventory equation.

Formula: units_sold = sum(line_item_quantity) across orders — greatest(pixel_units, polled_units) per GL#313.

How TripleWhale computes it: same Units Sold tile sourced from Shopify line-item data (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. Datafast tracks conversion events but not line-item quantity at the dashboard level.

How Admaxxer computes it: the revenue rollup. The output value is units_sold. Sourced from line_item_quantity sums per Shopify webhook orders + units_sold_pixel + polled_units_sold via GL#313 source-additive fold.

Why it matters: pair with Orders to compute average items-per-order. Rising units/order with stable AOV means upsells are working; falling units/order with rising AOV means the higher-priced SKUs are doing the heavy lifting.

New / Returning Customer Revenue

Order revenue split by whether the buyer placed their first order in the window or had bought before. The numerator-shaping pair under NC-ROAS and returning-cohort efficiency.

Formula: new_customer_revenue = sumIf(order_total, is_new_customer=1) and returning_customer_revenue = sumIf(order_total, is_new_customer=0)

How TripleWhale computes it: TripleWhale presents the same split as part of Customer Cohorts (TripleWhale Customer Cohorts); numerator under NC-ROAS.

How Datafast computes it: N/A in Datafast. User identification creates persistent visitor profiles (datafa.st — user identification) but the cohort isn't projected onto the revenue tile as a new-vs-returning split.

How Admaxxer computes it: the revenue rollup. The output value is new_customer_revenue and returning_customer_revenue. Source is the the order stream; Shopify webhook rows trust the native is_new_customer hint, pixel-only rows JOIN to customers.first_order_date.

Why it matters: NC-ROAS uses new_customer_revenue as numerator. The returning split tells you what existing-customer business looks like without spend efficiency in the frame — useful when scaling retention separately from acquisition.

Cohort LTV (7d / 30d / 90d / 365d)

The cumulative revenue a customer cohort produces over time, indexed by the date of their first order. The retention curve made legible.

Formula: cohort_ltv_Nd = sum(cohort_revenue_through_day_N) / count(unique_customers_in_cohort)

How TripleWhale computes it: TripleWhale defines LTV as "the average order revenue per customer, for orders placed within the selected timeframe" and exposes 7/30/60/90-day LTV views. The cohort math is "Total Sales of 1st order / number of unique customers in cohort" extended out by retention (TripleWhale Customer Cohorts).

How Datafast computes it: N/A at windowed-cohort granularity in Datafast. Datafast's marketing copy mentions surfacing "customer segments with the highest LTV" (datafa.st — revenue attribution), but the LTV view is a per-segment lifetime aggregate rather than a 7/30/90-day windowed cohort projection bucketed by first-order date. Operators wanting Cohort LTV at fixed windows (the standard DTC retention-curve view) need a tool that ingests order timestamps and computes cumulative cohort revenue at day N — Admaxxer's adsLtv route family does this; Datafast does not.

How Admaxxer computes it: ad-level cohort LTV is computed by the dedicated adsLtv route family (server/routes/adsLtv.ts) which joins ad spend to the pixel-stitched revenue stream at 7-day, 30-day, and 90-day windows from the customer's first-order date. Cohort definition matches TripleWhale's: customers are bucketed by the date of their first ever order.

Why it matters: a 7-day LTV of $35 on a $40 NCPA is a winner if 30-day LTV is $90. Without cohort LTV you're flying blind on whether high acquisition cost is acceptable; with it you can prove which campaigns deserve to scale even when day-of ROAS looks rough.

Web analytics metrics (sessions, bounce, conversion)

Metrics computed off the first-party pixel's pageviews datasource — the visitor side of the funnel that ad-platform reports do not see. This is the section where Datafast has the most direct overlap — Datafast's core surface is web analytics + revenue attribution, so most of the metrics below have a Datafast equivalent (sometimes named differently).

Sessions

Distinct pixel session IDs in the window — the denominator under RPS, conversion rate, bounce rate, and pages-per-session.

Formula: sessions = countDistinct(session_id) over the pageviews datasource — session_id is persisted in localStorage + cookie per the GL#323 stitching pattern.

How TripleWhale computes it: standard Sessions tile on the Web Analytics surface; same session-distinct-count definition (TripleWhale Web Analytics).

How Datafast computes it: Datafast surfaces Sessions on the Web Analytics view as the headline traffic metric — the denominator under conversion rate. Industry-standard session-distinct-count definition; numerically equivalent to Admaxxer on shared workspaces (datafa.st docs — web analytics).

How Admaxxer computes it: the revenue rollup. The output value is sessions. countDistinct(session_id) over the pageviews datasource for the workspace + window.

Why it matters: the traffic floor under every per-session metric. Rising sessions plus flat conversion = top-of-funnel is widening but not converting harder; rising sessions plus rising conversion = the funnel is healthy end-to-end.

Unique Visitors

Distinct stitched visitor IDs in the window. One visitor maps to many sessions, so visitors < sessions always.

Formula: unique_visitors = countDistinct(visitor_id) over pageviews — visitor_id is the long-lived stitched ID that persists across sessions per GL#323.

How TripleWhale computes it: Unique Visitors tile on the Web Analytics view; same stitched-ID definition (TripleWhale Web Analytics).

How Datafast computes it: Datafast's Unique Visitors is one of the core Web Analytics tiles. User-identification stitches across devices/browsers ("follow users across browsers and devices"), same intent as Admaxxer's visitor_id (datafa.st — user identification).

How Admaxxer computes it: the revenue rollup. The output value is unique_visitors. countDistinct(visitor_id). Falls back to anonymous device-fingerprint visitor_id pre-login; post-login the same ID is stitched to user_id.

Why it matters: top-of-funnel reach metric independent of session count. Rising visitors plus flat sessions/visitor = the audience is expanding but not engaging deeper; rising visitors plus rising sessions/visitor = real growth.

Pageviews

Total count of pageview events fired by the pixel in the window. Gross traffic volume.

Formula: pageviews = count(*) over the pageviews datasource where event_type IN ('__admx_view', 'page_viewed').

How TripleWhale computes it: standard Pageviews tile on the Web Analytics surface (TripleWhale Web Analytics).

How Datafast computes it: Datafast's Pageviews is a core Web Analytics tile — same count-of-pageview-events definition. Industry-standard (datafa.st docs).

How Admaxxer computes it: the revenue rollup. The output value is pageviews. Counts ONLY pageview events (Custom Pixel __admx_view + Shopify page_viewed) — NOT custom goals like product_viewed or cart_added.

Why it matters: pageviews / sessions = pages per session — the engagement multiplier under sessions. Pageviews alone is the gross floor — a top-of-funnel number even less filtered than visitors.

Bounce Rate

The share of sessions where the visitor viewed exactly one page and left without a second pageview. The headline engagement metric for landing-page quality.

Formula: bounce_rate = (single_pageview_sessions / total_sessions) * 100

How TripleWhale computes it: TripleWhale defines Bounce Rate as "the total number of Bounced Sessions divided by all Sessions" — the percentage of single-page sessions where a user leaves without further interactions (TripleWhale Web Analytics).

How Datafast computes it: Datafast tracks bounce rate on the Web Analytics view as part of standard session metrics (datafa.st docs — web analytics). Marketing copy explicitly deprioritizes bounce rate as a "vanity metric" (datafa.st — "focused only on what drives growth, not vanity metrics") so the tile is present but not headlined. The underlying definition matches the industry standard (single-pageview sessions / total sessions).

How Admaxxer computes it: the revenue rollup — the session stream uses countDistinctIf(session_id, pv_in_session = 1) to count sessions whose pageview-window count is exactly 1, then divides by countDistinct(session_id). Output column bounce_rate.

Why it matters: pair with conversion rate. A high bounce rate paired with a healthy conversion rate means the landing page is doing its job for the right audience and the wrong audience is filtering out cleanly. A high bounce rate plus a falling conversion rate means the page is broken or the traffic is mismatched.

Conversion Rate

What share of pixel-tracked sessions produced an order?

Formula: conversion_rate = (orders / sessions) * 100

How TripleWhale computes it: standard funnel-health metric on the Web Analytics surface — orders divided by sessions (TripleWhale Web Analytics).

How Datafast computes it: Datafast surfaces conversion rate as a goals-driven metric — goal_completions / sessions (or visitors, depending on the goal type). Conversion Funnels visualize multi-step conversion rates with per-step drop-off (datafa.st — conversion funnels). The denominator differs from Admaxxer's: Datafast can use either visitors or sessions depending on the funnel-step configuration; Admaxxer uses sessions exclusively for the headline tile to match the TripleWhale convention. Numerically very close on most workspaces; semantically slightly different.

How Admaxxer computes it: the revenue rollup. The output value is conversion_rate. Numerator uses the cross-source order count; denominator comes from the session stream's countDistinct(session_id).

Why it matters: the universal funnel-health metric. Most DTC stores live between 1.5% and 4%; rising conversion rate without falling AOV is the cleanest growth signal there is.

Average Session Duration

How long does a visitor spend on the site per session, in seconds?

Formula: avg_session_duration = sum(session_seconds) / max(sum(pv_in_session), 1)

How TripleWhale computes it: standard pageview-window-based session-duration metric on the Web Analytics surface (TripleWhale Web Analytics).

How Datafast computes it: Datafast tracks session duration on the Web Analytics view alongside pageviews and visitors (datafa.st docs). Industry-standard min-to-max-pageview-timestamp computation; numerically equivalent to Admaxxer's tile on shared workspaces.

How Admaxxer computes it: the revenue rollup — the session stream uses a window function to compute the time delta between min and max ts per session, then averages across pageviews. Output column avg_session_duration.

Why it matters: sub-30-second sessions usually indicate poorly-targeted traffic; 60+ seconds usually indicates engaged traffic. Tracks landing-page quality independently of conversion.

Pages per Session

Average number of pageviews per session.

Formula: pages_per_session = pageviews / sessions

How TripleWhale computes it: pageviews divided by sessions on the Web Analytics surface (TripleWhale Web Analytics).

How Datafast computes it: Datafast surfaces pageviews and sessions independently on the Web Analytics view (datafa.st docs); pages-per-session is a derived computation that operators can read off the dashboard or export. Datafast's deprioritization of "vanity metrics" means it's not headlined.

How Admaxxer computes it: the revenue rollup. The output value is pages_per_session.

Why it matters: along with bounce rate and avg session duration, the third leg of the engagement triangle. Improvements compound: more pages/session usually means more chances to convert.

New Users / New Users %

How many distinct visitors had their first-ever pageview inside the analysis window? new_users_pct divides that count by total unique visitors to give the share of new vs returning.

Formula: new_users = countDistinctIf(visitor_id, first_pageview_date IN window) and new_users_pct = (new_users / unique_visitors) * 100

How TripleWhale computes it: TripleWhale surfaces a new-vs-returning split on the Web Analytics view (TripleWhale Web Analytics).

How Datafast computes it: Datafast's user-identification feature (datafa.st — user identification) creates persistent profiles and tracks new vs returning visitors at the session level. Cross-platform tracking ("follow users across browsers and devices") matches Admaxxer's visitor_id stitching pattern.

How Admaxxer computes it: the revenue rollup — new_users_current node groups pageviews by visitor_id, computes the min pageview date, and counts visitors whose first-ever date falls in the window. Output columns new_users and new_users_pct.

Why it matters: top-of-funnel reach metric independent of orders. If new users is rising and orders are flat, the funnel is leaking; if new users is flat and orders are rising, the existing audience is converting harder.

Per-platform metrics (Meta, Google, TikTok)

Each connected ad platform contributes a parallel family of metrics: spend, conversion value, ROAS, purchases, clicks, impressions, CPC, CTR, CPM, CPA. Source: ad_spend_daily datasource (Meta + Google + TikTok + Amazon + Pinterest), aggregated in the the ad-spend stage of the revenue rollup. This entire family is N/A in Datafast — Datafast does not ingest ad-platform spend.

Platform Spend (Meta / Google / TikTok)

Per-platform ad spend reported by each connected ad network — the numerator under each platform's CPC, CPM, CPA and denominator under platform ROAS.

Formula: platform_spend = sum(spend) from ad_spend_daily filtered by platform — meta_spend, google_spend, tiktok_spend.

How TripleWhale computes it: TripleWhale surfaces the same per-platform spend family on the Summary dashboard (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. No ad-platform ingestion — spend lives outside Datafast's surface entirely.

How Admaxxer computes it: the revenue rollup. The output value is meta_spend, google_spend, tiktok_spend. Sourced from ad_spend_daily via the the ad-spend stage; values are in the platform's reported currency (per the meta_currency, google_currency, tiktok_currency fields).

Why it matters: the base measurement. Compare per-platform spend to per-platform reported conversion value to get platform ROAS, or sum across platforms to derive blended_spend. Platform spend is also the only spend figure the platform itself sees — useful when comparing platform-reported ROAS to MER.

Platform Conversion Value (Meta / Google / TikTok)

Per-platform self-reported revenue from conversions — the numerator under platform ROAS.

Formula: platform_cv = sum(conversions_value) from ad_spend_daily filtered by platform — meta_cv, google_cv, tiktok_cv.

How TripleWhale computes it: same per-platform reported conversion-value family on the Summary dashboard (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. No ad-platform conversion-value ingestion.

How Admaxxer computes it: the revenue rollup. The output value is meta_cv, google_cv, tiktok_cv. Sourced from the ad platform's reported conversions_value (Meta = action_values "purchase"; Google = conversions_value; TikTok = total_complete_payment_rate * spend).

Why it matters: platform-reported conversion value is what the platform's optimizer sees — every bidding decision is made off this number. Compare to pixel-side revenue (Pixel CVD) to know whether the platform is over- or under-counting.

Platform Purchases (Meta / Google / TikTok)

Per-platform self-reported purchase count — the denominator under platform CPA.

Formula: platform_purchases = sum(purchases) from ad_spend_daily filtered by platform — meta_purchases, google_purchases, tiktok_purchases.

How TripleWhale computes it: same per-platform purchase-count family on the Summary dashboard (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. No ad-platform purchase-count ingestion.

How Admaxxer computes it: the revenue rollup. The output value is meta_purchases, google_purchases, tiktok_purchases. Sourced from the ad platform's reported conversion count (Meta = actions "purchase"; Google = conversions; TikTok = total_purchases).

Why it matters: compare to your store's actual order count to know the platform's attribution coverage. Platform purchases > store orders = double-counting (multiple ad networks claiming the same order). Platform purchases << store orders = the platform isn't seeing real conversions, raising CPA in the bid auction.

Platform Clicks (Meta / Google / TikTok)

Per-platform clicks on ads in the window — denominator under platform CPC and numerator under platform CTR.

Formula: platform_clicks = sum(clicks) from ad_spend_daily filtered by platform — meta_clicks, google_clicks, tiktok_clicks.

How TripleWhale computes it: same per-platform clicks family on the Summary dashboard (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. No ad-platform integration; click data lives outside Datafast.

How Admaxxer computes it: the revenue rollup. The output value is meta_clicks, google_clicks, tiktok_clicks. Sourced from the ad platform's reported click count (Meta = clicks "all"; Google = clicks; TikTok = clicks).

Why it matters: volume floor under every per-click efficiency metric. Pair with clicks / sessions to see whether the platform's reported clicks match your pixel's landing-page sessions — gap there is a server-side vs pixel-side measurement disagreement, useful for diagnosing CAPI / pixel-fire problems.

Platform Impressions (Meta / Google / TikTok)

Per-platform ad views in the window — denominator under platform CPM and CTR.

Formula: platform_impressions = sum(impressions) from ad_spend_daily filtered by platform — meta_impressions, google_impressions, tiktok_impressions.

How TripleWhale computes it: same per-platform impressions family on the Summary dashboard (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. No ad-platform integration; impression data lives outside Datafast.

How Admaxxer computes it: the revenue rollup. The output value is meta_impressions, google_impressions, tiktok_impressions. Sourced from the ad platform's reported impressions.

Why it matters: reach proxy. Rising impressions plus flat CPM = bigger audience at the same price; rising impressions plus rising CPM = the auction is heating up (more competition, less inventory). Pair with clicks for CTR.

Platform ROAS

Per-platform self-reported return on ad spend — the platform's own attribution. Useful for platform-internal optimization, but always compare to MER (which uses real revenue) to know if the platform is over- or under-counting conversions.

Formula: platform_roas = platform_conversion_value / platform_spend

How TripleWhale computes it: TripleWhale surfaces the same per-platform ROAS family (Meta / Google / TikTok / etc.) on the Summary dashboard (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. No ad-spend ingestion, no platform-side conversion-value ingestion.

How Admaxxer computes it: the revenue rollup. The output value is meta_roas, google_roas, tiktok_roas. Numerator is the platform's reported conversions_value; denominator is reported spend in the platform's currency.

Why it matters: the gap between platform ROAS and MER is the iOS ATT / ad-blocker / CSP tax. A widening gap means the platform is getting blinder; a closing gap means the CAPI integration is stitching better.

CPC, CTR, CPM, CPA per platform

Standard funnel metrics: cost per click, click-through rate, cost per thousand impressions, cost per acquisition. Computed identically across platforms with the platform's own spend and click/impression denominators.

Formulas: cpc = spend / clicks · ctr = (clicks / impressions) * 100 · cpm = (spend / impressions) * 1000 · cpa = spend / purchases

How TripleWhale computes it: standard Marketing-API-derived definitions per platform (TripleWhale Summary Dashboard Metrics Library).

How Datafast computes it: N/A in Datafast. No ad-platform integration; clicks / impressions / spend not available.

How Admaxxer computes it: the revenue rollup. The output value is {meta,google,tiktok}_{cpc,ctr,cpm,cpa}. Each uses null-safe division (ifNull(numerator / nullIf(denominator, 0), 0)) so empty platforms render 0 instead of error.

Why it matters: the diagnostic chain. Falling CTR with stable CPM points to creative fatigue. Rising CPM with stable CTR points to competition. Falling CPA with rising CPC points to better targeting. Each pair tells you a different story about the auction.

Attribution metrics (CAPI match rate, Pixel CVD)

Metrics that quantify how complete your conversion data is — the gap between what the ad platform reports and what your store actually saw. Both are N/A in Datafast — Datafast's attribution view is UTM-source attribution of revenue, not server-vs-client conversion-event reconciliation.

CAPI Match Rate

The share of pixel-attributed conversions for which Admaxxer also has a matching server-side conversion event in the ad platform's Conversions API. The Hyros-style "are we sending the platform back the conversions it needs to optimize?" metric.

Formula: capi_match_rate = (server_side_conversions_matched / pixel_conversions) * 100

How TripleWhale computes it: TripleWhale surfaces a similar pixel-vs-platform attribution-match metric on the Attribution Dashboard. Hyros remains the legacy gold-standard tool for this metric.

How Datafast computes it: N/A in Datafast. Datafast's attribution model is UTM-source attribution of revenue (which channel drove this dollar?), not Conversions-API match-rate diagnostics (did the platform see the conversion the pixel saw?). Different layer of the stack.

How Admaxxer computes it: server/routes/adsCapiMatchRate.ts — joins pixel-attributed payments to outbound CAPI events keyed on event_id, surfaces the match rate per ad platform per window. The Attribution dashboard's CAPI Match Rate tile reads from this route.

Why it matters: a falling CAPI match rate is the leading indicator that the ad platform's optimizer is going blind. Below 50% and the auction starts hallucinating; above 80% and the platform's bidding gets meaningfully smarter. Hyros has built a $50M business on this single metric.

Pixel CVD (Conversion Value Delta)

The dollar gap between what the pixel saw as conversion value vs what the ad platform reports as conversion value, per ad. Surfaces deterministic mismatches that aggregate-only ROAS hides.

Formula: pixel_cvd = pixel_cv - platform_cv

How TripleWhale computes it: TripleWhale surfaces a similar pixel-vs-platform delta on the Attribution Dashboard.

How Datafast computes it: N/A in Datafast. No ad-platform conversion-value ingestion to compare against.

How Admaxxer computes it: the attribution rollup — output column pixel_cvd. The Attribution drill-down on /dashboard/analytics renders this column inline alongside spend and ROAS for every ad/adset/campaign/channel.

Why it matters: a positive Pixel CVD on an ad means your store saw revenue the platform did not credit — which is exactly the ad you should scale before the platform's optimizer figures it out. A negative Pixel CVD means the platform is over-counting; ground-truth your ROAS off the pixel.

Email channel metrics (Klaviyo)

Klaviyo is the only revenue-bearing non-paid channel currently surfaced. Source: email_revenue_daily datasource, aggregated in the klaviyo_current node.

Klaviyo Revenue (campaign + flow + other)

Total Klaviyo-attributed revenue, broken into campaign sends and flow (automation) sends. Other revenue picks up SMS or transactional sends that don't fit either bucket.

Formula: klaviyo_revenue = campaign_revenue + flow_revenue + other_revenue

How TripleWhale computes it: TripleWhale surfaces the same campaign / flow split on the Klaviyo integration tile.

How Datafast computes it: Partial in Datafast. Datafast tracks email-driven revenue via UTM (utm_source=klaviyo) attribution — visitors arriving from Klaviyo sends get credited to that source on the Revenue Attribution view (datafa.st — UTM tracking). The campaign / flow split is not native — it depends on how the Klaviyo sends populate utm_campaign / utm_medium. No direct Klaviyo API integration.

How Admaxxer computes it: the revenue rollup. The output value is klaviyo_revenue, klaviyo_campaign_revenue, klaviyo_flow_revenue.

Why it matters: the unpaid counterweight to ad spend. If Klaviyo revenue is dropping while ad spend is flat, the retention motor is stalling; if Klaviyo revenue is rising while ad spend is flat, retention is doing the heavy lifting and you can scale acquisition.

Klaviyo Campaign Revenue

Revenue attributed to one-time Klaviyo campaign sends (broadcasts) — the planned-promotion slice of email revenue.

Formula: klaviyo_campaign_revenue = sum(revenue) where send_type = 'campaign' from email_revenue_daily.

How TripleWhale computes it: same Klaviyo campaign-revenue split surfaced on the Klaviyo integration tile.

How Datafast computes it: Partial in Datafast via utm_medium=email + utm_source=klaviyo attribution (datafa.st — UTM tracking); the campaign / flow split is not native — it depends on how Klaviyo populates utm_campaign at send time.

How Admaxxer computes it: the revenue rollup. The output value is klaviyo_campaign_revenue. Sourced from email_revenue_daily filtered by Klaviyo's metric ("Placed Order" from a campaign send). Example: a Black Friday broadcast that drives $12,400 in orders shows up here, separated from automated flow sends.

Why it matters: tracks how well planned promotions land. Campaign revenue is operator-controlled (send a broadcast, see the spike); flow revenue is automation-controlled (passive). Splitting them lets you see whether to invest more in promotional planning vs flow optimization.

Klaviyo Flow Revenue

Revenue from automated Klaviyo flow sends (welcome series, browse abandon, post-purchase, win-back) — the passive automation slice.

Formula: klaviyo_flow_revenue = sum(revenue) where send_type = 'flow' from email_revenue_daily.

How TripleWhale computes it: same Klaviyo flow-revenue split surfaced on the Klaviyo integration tile.

How Datafast computes it: Partial in Datafast via utm_medium=email + utm_source=klaviyo; the campaign / flow split is not native — depends on how flow sends populate utm_campaign / utm_medium.

How Admaxxer computes it: the revenue rollup. The output value is klaviyo_flow_revenue. Sourced from email_revenue_daily filtered by Klaviyo's metric ("Placed Order" from a flow send like Welcome Series, Browse Abandon, Post-Purchase, Win-Back).

Why it matters: flow revenue is the closest thing to free DTC revenue — automated, recurring, low touch. Healthy DTC brands run 40-60% of Klaviyo revenue through flows. If campaign revenue is doing the heavy lifting while flows lag, your automations are leaving money on the table.

Klaviyo AOV / Conversion Rate

AOV across Klaviyo orders, plus a conversion-rate proxy of placed orders per click.

Formulas: klaviyo_aov = klaviyo_revenue / klaviyo_orders · klaviyo_cr = (klaviyo_orders / klaviyo_clicks) * 100

How TripleWhale computes it: standard email-channel efficiency metrics on the Klaviyo tile.

How Datafast computes it: N/A in Datafast. No native Klaviyo API integration; the closest concept is per-source revenue + visitor counts derived from UTM tags.

How Admaxxer computes it: the revenue rollup. The output value is klaviyo_aov and klaviyo_cr.

Why it matters: tells you whether email opens convert as well as paid traffic. If Klaviyo AOV is meaningfully higher than blended AOV, your email list is your most valuable customer cohort and underspending it is leaving money on the table.

Related Admaxxer documentation

• Documentation home — every guide, every reference, every architecture deep-dive.
• Analytics deep dive — how the analytics warehouse is structured, end-to-end.
• Revenue data flow — the four ingestion paths into our analytics warehouse, source-additive merge, and per-tile fidelity hierarchy.
• Dashboard analytics card reference — per-card guide to every tile on /dashboard/analytics.
• Multi-currency display — Native / USD / any-ISO-4217 modes, ECB rates, per-row historical accuracy.
• AI ad operators vs ads CLI — the operator-vs-CLI category distinction.
• AI agent documentation — Maxxer, the Claude-powered agent, with the full tool inventory.
• TripleWhale alternative — head-to-head with the legacy DTC analytics tool.

Methodology — how this glossary is built

Every metric on this page follows the same canonical four-part shape so the answer to "what is X?" sits next to the answer to "how do I reproduce it?" — and so a 30-second skim resolves the comparison against TripleWhale or Datafast.

The GL# definition pattern

Each metric ships with: (1) a one-sentence plain-English definition; (2) the exact formula in <code>; (3) the source-of-truth analytics pipeline (or server route) that computes it; (4) a "why it matters" line. This shape is enforced — when a new KPI ships, the metric row gets added with all four parts before merge. AI engines, CFOs reviewing a tile, and engineers debugging a number all find the same definition in the same place.

The 3-way comparison column

Every metric carries side-by-side columns for Admaxxer, TripleWhale, and Datafast. Where a tool surfaces the same metric we cite the exact column or panel name. Where a tool does not surface it (most common: Datafast lacks ad-spend ingestion, so all spend-denominated metrics are "N/A in Datafast"), we say so explicitly rather than hedging. Migrating from one tool to another? Cell-by-cell parity is on this page.

Why some formulas are deliberately simpler than competitors

True AOV and Net Profit are the canonical examples. TripleWhale's True AOV subtracts shipping; Admaxxer's broader formula does not because the cross-source path (Shopify webhook + daily-poll) doesn't carry shipping consistently across sources. Adding shipping to one path and not the other would silently break the column's semantics — GL#318 in our internal key-lessons documents the trade-off. The trade is clarity over false precision: when we ship the COGS / shipping ingestion layer, the formula updates in-place inside the same column name.

Backed by the pipe table — no parallel ETL

Every metric is recomputed from one analytics pipeline (or one CH materialized view per the GL#502 our analytics warehouse migration). No pre-aggregated cache that drifts. No spreadsheet snapshot. No "period that defies math because someone wrote the SQL twice." The pipe is the source of truth; the dashboard tile and this glossary read from it; the value you see on the tile is the value you'll compute if you run the pipe yourself.

FAQ

What is MER in Admaxxer vs TripleWhale vs Datafast?

MER (Marketing Efficiency Ratio) is total revenue divided by total ad spend across every connected ad platform. Formula: MER = total_revenue / total_ad_spend. Admaxxer + TripleWhale agree on the formula. Datafast does not surface MER — it has no ad-spend ingestion. The closest Datafast tile is Revenue per Visitor (revenue / visitors), which lacks a spend denominator.

How is NC-ROAS different from blended ROAS in Admaxxer?

Blended ROAS uses total revenue (new customers + returning); NC-ROAS uses only new-customer revenue. Both share the same denominator (total ad spend). NC-ROAS is the leading indicator of acquisition efficiency — the metric you scale on. Both metrics are N/A in Datafast (no spend ingestion, no native new-vs-returning customer split on revenue tiles).

What's the formula for True AOV in Admaxxer?

True AOV in Admaxxer is (gross_sales - returns - taxes) / orders. The pixel-only fast path additionally exposes a true_aov_cents column that subtracts shipping (matching TripleWhale's exact formula). The headline tile uses the broader formula because the cross-source path (Shopify webhook mirror + daily-poll) does not currently carry shipping — a deliberate compatibility choice (GL#318) so the column has consistent semantics regardless of which revenue source is feeding it. Datafast does not surface True AOV or AOV.

Does Admaxxer's Net Profit subtract COGS?

Not in v1. Admaxxer's Net Profit is currently total_revenue - total_ad_spend — a marketing P&L view, not a full P&L. The honest framing is more useful than a half-built full Net Profit that silently treats missing COGS as zero. When Admaxxer ships the COGS / expense ledger UI, the formula will update inside the same column name so dashboards stay stable. TripleWhale's fuller Net Profit subtracts COGS, shipping, gateway fees, and taxes; Datafast does not surface a Net Profit tile at all (no spend, no COGS, no expense ledger). Admaxxer's cash_turnover tile (revenue minus taxes minus spend minus returns) is the closer-to-finance variant currently surfaced.

How is Bounce Rate calculated across the three?

Bounce Rate is the share of sessions where the visitor's pageview count for that session was exactly one. Formula: (single_pageview_sessions / total_sessions) * 100. All three tools agree on the formula. Admaxxer computes it via the the session stream of the revenue rollup using countDistinctIf(session_id, pv_in_session = 1). TripleWhale uses "single-page sessions / total sessions". Datafast surfaces the same metric on the Web Analytics view but explicitly deprioritizes it as a "vanity metric" in marketing copy.

How does Admaxxer compute CAPI Match Rate?

CAPI Match Rate is the share of pixel-attributed conversions for which a matching server-side conversion event was also delivered to the ad platform's Conversions API. Formula: (server_side_matched / pixel_conversions) * 100. Computed by server/routes/adsCapiMatchRate.ts, joining pixel payments to outbound CAPI events keyed on event_id. Modeled after Hyros's published methodology — the gold standard in the DTC space for this metric. N/A in Datafast (Datafast does Stripe / Shopify revenue attribution, not server-vs-pixel conversion-event reconciliation).

What windows does Admaxxer compute Cohort LTV at?

7-day, 30-day, and 90-day — computed at the ad level by server/routes/adsLtv.ts. Customers are bucketed by their first-ever order date (matching TripleWhale's cohort definition); LTV at day N is the cumulative revenue from cohort customers over the N days following the first order, divided by the unique customer count in that cohort. Datafast surfaces lifetime LTV per customer segment via Revenue Attribution but does not expose the standard windowed-cohort projection.

What is the Datafast equivalent of Admaxxer's RPS (Revenue per Session)?

Datafast surfaces a closely related Revenue per Visitor tile (attributed_revenue / visitors). The marketing intent is the same — per-traffic-unit monetization — but the denominator differs (visitors vs sessions), so values won't be identical even on the same store. TripleWhale's RPS is session-denominated, matching Admaxxer's tile.

Why are some Admaxxer metrics N/A in Datafast — what's the architectural difference?

Datafast is a web-analytics + revenue-attribution tool: it ingests pageviews, sessions, and Stripe / Shopify orders. It does not ingest ad spend, ad-platform impressions/clicks, or conversion-event reconciliation pairs. So any Admaxxer metric whose formula includes ad_spend (MER, ROAS, NC-ROAS, NCPA, CPC, CPM, CTR) or CAPI dedup (CAPI Match Rate) has no Datafast equivalent — there's no denominator to compute. Datafast is the lighter tool when you only need web analytics + attribution; Admaxxer adds the ad-ops layer on top.

Which plan tier do I need to see every metric in this glossary?

Every metric in this glossary is computed for every workspace on every plan from AD_STARTER ($9/mo) upward — plans differentiate on tracked-event quota only (AD_STARTER 15K events/mo, AD_GROWTH 100K, AD_PRO 750K, AD_AGENCY 3M, AD_ENTERPRISE 15M, AD_PLATFORM 50M). There is no metric paywall: NC-ROAS, CAPI Match Rate, Cohort LTV, MMM contribution — all are computed on the same analytics pipelines regardless of plan. The 7-day free trial covers the full metric surface so you can verify our formulas against your existing dashboard before committing.

See your own metrics

Connect your ad platforms and your store in about 90 seconds. Every metric on this page renders for your data the moment the pixel and revenue connector go live. No credit card required during the trial.

Start your 7-day free trial · Tour the dashboard · See every integration