Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Fetch Sitewide Analytics

post

Get Sitewide Conversion Funnel

Retrieve the sitewide conversion funnel as a Sankey graph: visitors flow from entry point → landing page → second page → cart → checkout → conversion. The step-1 entry-point nodes default to device type (Mobile / Desktop); set entryPoint to pivot step 1 on traffic source, visitor type, or source site instead. Top-5 bucketing per step plus catch-all Other / Bounced rollups happen server-side; the wire format is already aggregated.

POST /v25-10-beta/analytics/sitewide/conversion-funnel

Request

Field
Required
Type
Notes

start

no

ISO 8601 datetime string

Beginning of the analysis window. Defaults to 30 days ago.

end

no

ISO 8601 datetime string

End of the analysis window. Defaults to now.

filters

no

filters object

Shared sitewide filters that narrow the underlying dataset — deviceType, visitorType, sourceSitesOrChannels, countryCodes, currencyCodes, onlyProductIds, landingPageFilters (preferred; landingPage is deprecated), landingPageTypes, etc. See the Filters Reference for the full list.

entryPoint

no

string enum

Pivots the funnel's step-1 entry-point dimension — it controls which buckets are rendered at step 1, not which sessions are included. One of "device_type", "visitor_type", "source_channel", "source_site". Unrecognized values silently default to "device_type". Renamed from audience (see note below). See "Entry point vs. filters" below.

conversionFunnel

no

conversionFunnel object

Funnel-specific filters. Stage flags + single landing/second page-type pins. See "Funnel-specific filters" below.

The conversionFunnel object

All funnel-specific filtering lives in a single optional conversionFunnel object. All fields are optional; combine any subset.

Stage flags (boolean) — narrow the funnel input to sessions that hit a behavioral stage:

  • addedToCart — sessions that added at least one item to cart

  • startedCheckout — sessions that started checkout

  • converted — sessions that converted

  • bounced — sessions that bounced (no second page)

  • abandonedCart — added to cart but did not convert

  • abandonedCheckout — started checkout but did not convert

  • exitedBeforeAtc — exited before adding to cart

  • viewedCollectionPage — viewed a collection page

  • viewedProductPage — viewed a product detail page

Page-type pins (landing-page enum) — pin the funnel to a single journey:

  • landingPageType — restrict to sessions whose landing page was this type

  • secondPageType — restrict to sessions whose second page was this type

Supported page-type values: "PDP", "Collection", "Content", "Blog", "Homepage", "Search", "Cart", "Other".

Funnel-specific vs. shared filters

Two distinct layers of filtering, and they behave differently:

  • filters.landingPageTypes (plural, array, inside the shared filters object) — narrows the underlying dataset to sessions starting on any of the selected page types. Same as the other /sitewide/* endpoints.

  • conversionFunnel.landingPageType / conversionFunnel.secondPageType (singular) — pin the funnel itself to a specific journey, so a caller can see how the PDP → 2nd-page-PDP path converted in isolation.

  • conversionFunnel stage flags (addedToCart, converted, etc.) — narrow the input population to sessions that hit a specific behavioral stage. Equivalent to the clickable node filters in the Intelligems dashboard.

conversionFunnel reuses the same schema the Intelligems dashboard sends internally, so the external contract matches the dashboard's funnel filtering exactly.

Entry point vs. filters

entryPoint and the shared filters look related but do completely different things. The simplest way to keep them straight:

filters change which sessions are included in the funnel. entryPoint changes which buckets are shown at step 1. They don't filter the same way — in fact, entryPoint doesn't filter at all.

Concrete contrast:

  • filters.deviceType: "mobile" → the funnel is computed over only mobile sessions. Every step in the response reflects mobile-only counts. Desktop sessions are gone from the dataset entirely.

  • entryPoint: "device_type" → the full dataset (mobile + desktop) is funneled, but step 1 of the Sankey is split into "Mobile" and "Desktop" nodes so you can see how each device cohort flows down. Nothing is filtered out.

Two questions, two different answers:

Question
Use

"How does the funnel look for mobile traffic specifically?"

filters: { deviceType: "mobile" }

"How does the funnel split between Mobile and Desktop visitors at the entry point?"

entryPoint: "device_type"

"How does the funnel split by channel, restricted to mobile US traffic?"

both: entryPoint: "source_channel" + filters: …

They compose without conflict — entryPoint controls the rendering of step 1, filters controls what data feeds into the funnel in the first place.

Supported entryPoint values

entryPoint value

Step-1 nodes

"device_type"

"Mobile", "Desktop"

"visitor_type"

"New", "Returning"

"source_channel"

Channel buckets: "Paid Social", "Paid Search", "Direct", "Organic Search", "Email", "Affiliate", … with top-5 + "Other" rollup

"source_site"

Referrer display names ("Google", "Facebook", "Instagram", "Klaviyo", "TikTok", …) — not hostnames — with top-5 + "Other" rollup

Reserved step-1 node names

  • "Unknown" — emitted for any entryPoint when the session has no value for that dimension. It is a real bucket and counts toward the top-5 selection.

  • "Misc" — emitted only for source_site and source_channel. Those two dimensions get the top-5 rollup, which reserves "Other" as the catch-all, so a session whose own taxonomy value is literally Other is renamed to "Misc" to keep the two distinct. device_type and visitor_type have no rollup and therefore never produce "Misc".

  • "Other" — the top-5 rollup catch-all on source_site and source_channel only. Not a value any session carries.

These four mirror the Customer Journey chart's audience selector exactly. The shared AnalyticsAudienceType enum also has country_code and landing_page_full_path values, but the funnel intentionally excludes those — they're not surfaced in the dashboard's funnel view, so the external API and MCP do not expose them either.

Fallback on unrecognized values

If entryPoint is set to any string outside the four supported values (e.g., "country_code", "channel", "new_vs_returning", a typo), the request does not 400 — the value silently falls back to "device_type" and a warning is logged server-side. This is deliberate so that LLM-driven callers that guess slightly-wrong dimension names still get a sensible funnel back instead of an opaque validation error.

When entryPoint is omitted entirely, the funnel uses its built-in default step-1 split (the same default the dashboard's Customer Journey chart starts on).

Renamed from audience

This parameter was named audience in earlier v25-10-beta builds. It was renamed to entryPoint to disambiguate it from the audience segmentation parameter on the /analytics/sitewide/snapshot and /analytics/sitewide/timeseries endpoints — on the funnel it pivots step-1 entry-point nodes, it does not segment KPIs. A legacy audience key sent to this endpoint is now ignored (the funnel falls back to its default step-1 split rather than erroring), so update existing integrations to send entryPoint.

Response

Abbreviated example (one path through all six steps). Note every node referenced by a link appears in nodes, and step numbers are contiguous — a real response has more nodes/links per step:

Every node a link references is present in nodes, steps run 1→6 with no gaps, and each link.step equals its source node's step. pct values are all fractions of the step-1 total (10,000 here).

  • nodes — one entry per labeled state at each step. Ordered by (step ascending, value descending).

    • name — node label (e.g. "Mobile", "Landing: PDP", "Bounced", "Added to Cart").

    • step — 1-indexed step position in the funnel.

    • value — visitor count at this node.

    • pct — share of step-1 visitors that reached this node, as a fraction in [0, 1] (not a percent).

  • links — one entry per transition between adjacent step nodes. Ordered by (step ascending, value descending).

    • source / target — node names on either end of the transition.

    • step — step of the source node.

    • value — visitor count traversing this link.

Server-side bucketing

At each step the server keeps the top 5 entries by traffic and rolls everything else into "Other". Two special node names are reserved:

  • "Bounced" — sessions that ended before reaching a second page.

  • "Landing: Other" / "2nd Page: Other" — catch-all buckets for low-volume landing or second-page types.

This is the same shape the Intelligems dashboard renders; there is no "unbucketed" mode.

Rate limits

Same rate limit as the other /analytics/sitewide/* endpoints. Aggregated, cacheable data — see the Rate Limiting Reference.

Body
startstring · date-timeOptional

Start of analysis period as an ISO 8601 datetime string (e.g. '2025-01-01T00:00:00.000-05:00'). Defaults to the start of the day 30 days ago, in the store's timezone. Note the default differs per sitewide endpoint, so pass an explicit start if you need a specific window.

Pattern: ^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z|([+-](?:[01]\d|2[0-3]):[0-5]\d)))$
endstring · date-timeOptional

End of analysis period as an ISO 8601 datetime string. Defaults to now.

Pattern: ^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z|([+-](?:[01]\d|2[0-3]):[0-5]\d)))$
entryPointstring · enumOptional

Optional dimension that pivots the funnel's step-1 entry-point nodes. This does NOT filter the dataset — it only changes which buckets are rendered at step 1 (Mobile vs. Desktop, New vs. Returning, channel breakdown, source-site breakdown). To narrow the dataset to a single segment, use the filters object instead. Supported values: 'device_type' (Mobile vs Desktop), 'visitor_type' (New vs Returning), 'source_channel' (Paid Social, Paid Search, Direct, ...), 'source_site' (referrer host buckets). Any other value (typo, unsupported dimension, wrong type) silently falls back to 'device_type'. Mirrors the Customer Journey chart's audience selector in the Intelligems dashboard. NOTE: this parameter was named audience in earlier v25-10-beta builds (renamed to disambiguate it from the audience segmentation param on the snapshot/timeseries endpoints). A legacy audience key sent to this endpoint is now ignored — update integrations to entryPoint.

Default: device_typePossible values:
Responses
200

OK

application/json
post/v25-10-beta/analytics/sitewide/conversion-funnel
200

OK

post

Retrieve order value distribution data and unit mix breakdowns for a time window.

The response returns orderValueDistribution.kernel_density_estimate and orderValueDistribution.cumulative_distribution_function, plus orderBreakdown.

Body
startstring · date-timeOptional

Start of analysis period as an ISO 8601 datetime string (e.g. '2025-01-01T00:00:00.000-05:00'). Defaults to the start of the week containing the date 12 weeks ago, in the store's timezone (weeks start Monday), so the default start is week-aligned rather than exactly 84 days back. Note the default differs per sitewide endpoint, so pass an explicit start if you need a specific window.

Pattern: ^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z|([+-](?:[01]\d|2[0-3]):[0-5]\d)))$
endstring · date-timeOptional

End of analysis period as an ISO 8601 datetime string. Defaults to now.

Pattern: ^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z|([+-](?:[01]\d|2[0-3]):[0-5]\d)))$
Responses
200

OK

application/json
post/v25-10-beta/analytics/sitewide/order-distribution
200

OK

post

Retrieve sitewide snapshot metrics for a time window.

The optional feature parameter is an object, not a string enum. It selects which metric set is returned.

These sets belong to this endpoint. They are not the same as the sets on POST /analytics/sitewide/timeseries — the two endpoints compute different metrics, so a set with the same name returns different fields on each.

feature

Fields returned

{ "name": "performance" }

gross_profit_per_visitor, net_revenue_per_visitor, conversion_rate, aov, gross_margin_pct, gross_profit, net_revenue, n_orders, n_visitors, average_discount, pct_revenue_with_cogs

{ "name": "order" }

aov, n_visitors, n_orders, median_order_value, average_units_per_order, pct_orders_with_free_shipping, net_shipping_revenue_per_order

{ "name": "conversion" }

viewed_collection_page_rate, viewed_product_page_rate, add_to_cart_rate, checkout_begin_rate, conversion_rate, bounce_rate, abandoned_cart_rate, abandoned_checkout_rate

{ "name": "audience", "audience": "device_type" }

The full sitewide metric set, broken out per segment

Omitting feature entirely returns the full sitewide metric set in a single "All" segment.

median_order_value and average_discount are available only on this endpoint. Conversely, the timeseries endpoint returns per-session rates (sessions_per_visitor, conversion_rate_per_session, net_revenue_per_session, gross_profit_per_session) and cost_of_revenue, none of which are computed here.

Response Structure

The response is a JSON object keyed by segment name, not a flat object with top-level metric fields.

When no audience feature is specified (or feature.name is "performance", "order", or "conversion"), the response contains a single "All" key:

{
  "All": {
    "currency": "USD",
    "n_visitors": { "value": 52763, "pct_change": 0.12 },
    "conversion_rate": { "value": 0.034, "pct_change": -0.05 },
    ...
  }
}

When feature.name is "audience", the response contains one key per audience segment plus a "__total" key:

A window with no data returns an empty object {} — not { "All": {} } and not a segment map with zeroed metrics. This applies to every feature, including audience (no "__total" key either). Check that the segment you want is present before reading metrics off it; response.All.n_visitors.value will throw on an empty window.

Each segment object contains currency (string), the COGS metadata fields cogs_configured (boolean) and cogs_coverage_pct (number), and metric fields. The two cogs_* fields are present for the performance, order, and audience features but omitted for conversion. Each metric field is an object with value (number) and pct_change (number) representing the percent change versus the comparison period. In audience view, per-segment metrics also include pct_impact_to_total_change (number).

impact_from_visitor_mix_shift appears on __total for ratio metrics only — within the audience field set that means conversion_rate, aov, net_revenue_per_visitor, and pct_revenue_with_cogs. (gross_margin_pct is a ratio but is not part of the audience field set, so it never carries this field.) Additive metrics (n_visitors, n_orders, net_revenue, gross_profit, and the rest of the counts and totals) never carry it, so expect it on a minority of the fields in a __total object rather than on all of them. It is the residual of the total percent change that is not attributable to any individual segment — the part explained by the mix of visitors shifting between segments — which is only meaningful for a weighted average, not for a sum.

Alongside currency, every segment also includes two scalar COGS-status fields (not { value, pct_change } objects): cogs_configured (boolean — whether cost-of-goods data is configured for the store) and cogs_coverage_pct (number, a fraction in [0, 1] for the share of revenue with COGS data).

COGS-dependent profit metrics are returned as a bare null (not a { value, pct_change } object) when cogs_configured is false. On this endpoint that is four fields:

  • gross_profit

  • gross_profit_per_visitor

  • gross_margin_pct

  • oli_net_product_revenue_with_cogs

Clients must null-check all four before reading .value / .pct_change. The suppression is applied to any profit metric, so the same rule holds for other profit fields (for example gross_profit_per_order, product_profit, subscription_gross_profit) on the endpoints that return them.

Metric Availability by Feature

  • performance returns this KPI subset: n_visitors, conversion_rate, n_orders, aov, net_revenue, gross_profit, gross_profit_per_visitor, net_revenue_per_visitor, gross_margin_pct, average_discount, pct_revenue_with_cogs.

  • order returns this subset: aov, n_visitors, n_orders, median_order_value, average_units_per_order, pct_orders_with_free_shipping, net_shipping_revenue_per_order.

  • conversion returns this subset: viewed_collection_page_rate, viewed_product_page_rate, add_to_cart_rate, checkout_begin_rate, conversion_rate, bounce_rate, abandoned_cart_rate, abandoned_checkout_rate.

  • audience returns per-segment metrics plus a __total key: n_sessions, n_visitors, n_orders, gross_revenue, net_revenue, order_cogs, conversion_rate, aov, net_revenue_per_visitor, shipping_cost, transaction_fees, tax, gross_profit, gross_profit_per_visitor, oli_net_product_revenue_with_cogs, oli_net_product_revenue, pct_revenue_with_cogs.

Body
startstring · date-timeOptional

Start of analysis period as an ISO 8601 datetime string (e.g. '2025-01-01T00:00:00.000-05:00'). Defaults to the start of the week containing the date one week ago, in the store's timezone (weeks start Monday) — so the default window spans 7 to 13 days depending on the current weekday, not exactly 7. Note the default differs per sitewide endpoint, so pass an explicit start if you need a specific window.

Pattern: ^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z|([+-](?:[01]\d|2[0-3]):[0-5]\d)))$
endstring · date-timeOptional

End of analysis period as an ISO 8601 datetime string. Defaults to now.

Pattern: ^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z|([+-](?:[01]\d|2[0-3]):[0-5]\d)))$
featureone ofOptional

Optional feature selector object. Omit it or use { "name": "performance" } for sitewide KPI snapshots, { "name": "audience", "audience": "device_type" } for audience segment snapshots, { "name": "order" } for order-focused metrics, or { "name": "conversion" } for conversion funnel metrics.

or
or
or
Responses
200

OK

application/json
post/v25-10-beta/analytics/sitewide/snapshot
200

OK

post

Returns sitewide KPI time-series data with configurable granularity, a choice of metric set, and optional audience segmentation.

Parameters

  • granularity — optional time bucketing: day, week (default), or month

  • feature — optional metric-set selector object. These sets belong to this endpoint. They are not the same as the sets on POST /analytics/sitewide/snapshot — the two endpoints compute different metrics, so a set with the same name returns different fields on each. See "Metric sets" below.

Metric sets

Omit feature to receive every metric this endpoint produces. Pass one of the following to receive only that set:

feature

Segment keys

Fields returned (in addition to dt)

{ "name": "performance" }

"All"

n_visitors, n_orders, conversion_rate, aov, net_revenue, net_revenue_per_visitor, gross_profit, gross_profit_per_visitor, gross_margin_pct, pct_revenue_with_cogs

{ "name": "order" }

"All"

n_orders, aov, aov_pre_discount, units_per_order, net_revenue_per_unit, gross_revenue_per_unit, discount_per_unit, pct_orders_with_free_shipping, net_shipping_revenue_per_order

{ "name": "conversion" }

"All"

Funnel step rates — viewed_collection_page_rate, viewed_product_page_rate, add_to_cart_rate, checkout_begin_rate, conversion_rate, bounce_rate, abandoned_cart_rate, abandoned_checkout_rate — plus the four counts those rates are derived from: n_sessions, n_visitors, n_visitors_abandoned_cart, n_visitors_abandoned_checkout (12 fields in total)

{ "name": "audience", "audience": "device_type" }

one key per segment

The full per-segment metric set for the chosen dimension

The endpoint produces 37 metrics in total; performance and order between them cover 17. The remaining 20 are returned only when feature is omitted:

n_sessions, sessions_per_visitor, conversion_rate_per_session, net_revenue_per_session, gross_profit_per_session, gross_revenue, net_product_revenue, net_shipping_revenue, order_cogs, oli_net_product_revenue, oli_net_product_revenue_with_cogs, unit_quantity, lost_orders, lost_net_revenue, n_free_shipping_orders, discounts, shipping_cost, transaction_fees, tax, cost_of_revenue

Several of those — the per-session rates and cost_of_revenue — cannot be produced by the snapshot endpoint at all. Conversely, median_order_value and average_discount are available only on the snapshot endpoint and are never returned here.

conversion and audience are served by dedicated datasets, so their field sets are fixed by those datasets rather than filtered from the general metric set.

dt Field Format

dt is returned as a formatted date string (not Unix epoch). Format is "YYYY-MM-DDTHH:mm:ss" for all granularities (day, week, and month).

Response Notes

  • Each data point contains dt plus the numeric fields for the selected metric set.

  • Fields are null rather than 0 when a bucket has no data to compute them from (for example conversion_rate in a bucket with no visitors).

  • summary carries one fewer field than data: sessions_per_visitor appears on each data point but is not summarized. Do not assume the two key sets match.

summary is not a window total

Each segment can include a summary object alongside data, but it is not the sum over the requested window, and the two kinds of metric behave differently:

  • Additive metrics — n_sessions, n_orders, gross_revenue, net_product_revenue, net_shipping_revenue, n_free_shipping_orders, net_revenue, order_cogs, oli_net_product_revenue_with_cogs, oli_net_product_revenue, unit_quantity, lost_orders, lost_net_revenue, discounts, shipping_cost, transaction_fees, tax, cost_of_revenue, gross_profit — are the window sum rescaled to one granularity bucket, i.e. an average per bucket. The same window therefore returns different values at day, week, and month, and counts come back fractional. Summing the data array recovers the true window total for these.

  • Ratio metrics — conversion_rate, conversion_rate_per_session, aov, aov_pre_discount, net_revenue_per_visitor, net_revenue_per_session, gross_profit_per_visitor, gross_profit_per_session, units_per_order, gross_revenue_per_unit, net_revenue_per_unit, discount_per_unit, gross_margin_pct, pct_orders_with_free_shipping, net_shipping_revenue_per_order, pct_revenue_with_cogs — are computed from the window sums rather than from the rescaled per-bucket values. Ratios whose denominator is not visitor-based (aov, gross_margin_pct, pct_revenue_with_cogs, …) are exact window-wide figures and do not vary with granularity. Visitor-denominated ratios currently do vary — see the warning below.

  • n_visitors is not additive. It is a distinct-visitor count, so a visitor active on several days is counted once per bucket they appear in. Summing data[].n_visitors overcounts, and the overcount grows as buckets get smaller. summary.n_visitors is rescaled like the additive metrics, so it is not a window total either. For a true unique-visitor count over a window, use POST /analytics/sitewide/snapshot.

To get a window total for an additive metric, sum the data array yourself. This does not work for n_visitors.

Example — one request window (2026-06-01 → 2026-06-29) whose true totals are 727 orders and 138,938 unique visitors:

granularity

summary.n_orders

sum(data[].n_orders)

sum(data[].n_visitors)

summary.conversion_rate

day

25.96

727

158,528 (+14.1%)

0.0045859

week

181.75

727

146,665 (+5.6%)

0.0049569

month

791.91

727

138,938 (exact)

0.0052325

The additive scale factor is bucket_days / window_days (1, 7, and 30.5 respectively), which is why month on a 28-day window exceeds the true total.

Known issue — visitor-denominated summary ratios vary with granularity. summary.conversion_rate, summary.net_revenue_per_visitor, and summary.gross_profit_per_visitor are computed as numerator / sum(data[].n_visitors). Because that denominator double-counts returning visitors, these three are understated at day and week granularity and only correct when the window fits in a single bucket. In the example above the true conversion rate is 0.0052325 (confirmed against /analytics/sitewide/snapshot for the same window), but day reports 0.0045859 — a 12.3% understatement. Until this is fixed, read these three from POST /analytics/sitewide/snapshot, or compute them yourself from sum(data[].n_orders) and the snapshot's n_visitors. Ratios with non-visitor denominators are unaffected.

Body
startstring · date-timeOptional

Start of analysis period as an ISO 8601 datetime string (e.g. '2025-01-01T00:00:00.000-05:00'). Defaults to the start of the week containing the date 12 weeks ago, in the store's timezone (weeks start Monday), so the default start is week-aligned rather than exactly 84 days back. Note the default differs per sitewide endpoint, so pass an explicit start if you need a specific window.

Pattern: ^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z|([+-](?:[01]\d|2[0-3]):[0-5]\d)))$
endstring · date-timeOptional

End of analysis period as an ISO 8601 datetime string. Defaults to now.

Pattern: ^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z|([+-](?:[01]\d|2[0-3]):[0-5]\d)))$
featureone ofOptional

Optional metric-set selector. Object form, e.g. { "name": "performance" }. Values: 'performance' (headline KPI trend), 'order' (order composition and per-unit economics), 'conversion' (funnel step rates), or { name: 'audience', audience: '' } for a per-segment breakdown. Omit to receive every metric this endpoint produces. NOTE: the fields behind each set are specific to this endpoint and differ from the sitewide snapshot endpoint's set of the same name, because the two run different underlying datasets.

or
or
or
granularitystring · enumOptional

Time bucket granularity. Supported values: day, week, month. Defaults to week.

Default: weekPossible values:
Responses
200

OK

application/json
post/v25-10-beta/analytics/sitewide/timeseries
200

OK

Last updated

Was this helpful?