Skip to main content
LayersQL provides seven datasets for building metrics. Each dataset exposes its own metrics, dimensions, and example queries.

​
Personalization dimensions (all datasets)

Every dataset exposes a shared set of session and customer dimensions you can use with GROUP BY, SEGMENT BY, and WHERE to segment metrics by shopper context:
  • shopping_channel — web or app.
  • locale — Storefront locale code (e.g., en, fr, pt-br).
  • currency — ISO 4217 currency code applied to the request (e.g., USD, EUR).
  • session_returning — Session type: new or returning.
  • customer_state — Whether the shopper is authenticated: signed_in or guest.
  • customer_returning — Customer type: new or returning, based on prior order count.
  • b2b_company — Shopify B2B company location identifier for the signed-in company account.
Layers reads these values from the request context payload. For currency and b2b_company, the server-resolved value takes precedence over any client-supplied value. When you use locale, currency, session_returning, customer_returning, or b2b_company with the Sales dataset, Layers joins them from the most recent session context. This lets you slice purchase metrics by these dimensions even though order data doesn’t store them directly.

​
Custom context dimensions

You can query the custom context parameters your storefront sends alongside the built-in dimensions. Once a parameter is discovered from live traffic, reference it in LayersQL as custom.<key>, mirroring the path under context.custom with the context. prefix dropped.
  • Where you can use them: WHERE, GROUP BY, and SEGMENT BY.
  • Where you can’t: bare SHOW. Custom dimensions aren’t metrics, so SHOW custom.storefront is rejected at validation.
  • Discovery: the parameter must already appear in the store’s contextual field inventory. Query the store-dimensions MCP tool or open the field picker in any contextual conditions form to see what’s available. See Custom context fields for discovery timing and requirements.
  • Namespaced keys: parameters sent one level deep (for example, context.custom.rivo.vipTier) use the same dotted path, so reference them as custom.rivo.vipTier.
Split product performance by a storefront-supplied audience flag:
Filter search analytics by a discovered loyalty tier:

​
Dataset compatibility

Custom context values are recorded on request and event traffic, so they resolve for metrics sourced from those tables. Every dataset supports custom context dimensions except Sales, whose metrics come from order data and carry no storefront context. On the Products dataset, purchase-sourced metrics such as total_sales, quantity_purchased, and purchase_sessions (and the ratios built on them) read from order data. LayersQL rejects any pairing of these metrics with a custom.* dimension at validation. For sales, use revenue instead: it measures the same purchases through the request tables and can be split by request context. The validation message for total_sales names both metrics so you can swap directly. The other purchase-sourced Products metrics have no request-backed equivalent. On Collections, Blocks, and the Search datasets, purchase-sourced metrics resolve custom context through the originating request, so LayersQL accepts them.
For order-level slicing you can’t get from revenue, use a dimension the Sales dataset exposes directly.

​
Dates (all datasets)

All datasets accept the same date expressions in the SINCE clause:
  • Relative offsets: -24h, -48h, -7d, -14d, -30d, -90d, -12m, -1y
  • Keywords: today, yesterday, this_week, last_week, this_month, last_month, this_quarter, last_quarter, this_year, last_year
  • Rolling windows: past_7_days, past_14_days, past_30_days, past_60_days, past_90_days, past_180_days, past_365_days
  • ISO timestamps: 2025-03-15 or 2025-03-15T10:30:00Z

​
Next steps