Website

S3 Sensitivity Science · Company dashboard

Landing pages and what they convert

Which pages carry sessions and which turn them into orders, for the chosen Window, read from the production dataset. Conversion rate is Shopify order rows over GA4 sessions taken off the same mart row, the landing page is first-click, and every row that is not a page a visitor can land on is named and counted above the table rather than quietly dropped.

Window
Landing-page data covers 27 May 2026 5 Aug 2026 across 128 pages

This page runs on analytics.channel_reporting, grouped by landing page — the same mart as /company/acquisition, so its coverage opens on 27 May 2026 , before the first order on 16 June 2026, and can end a day later than /company. Sessions and orders sit on the same mart row there, which is what makes a conversion rate on this page Shopify order rows over GA4 sessions rather than two numbers from two systems divided in hope.

Read the landing page as first-click

The caveat belongs above the table, not under it: it changes what the numbers mean, and a reader who meets it after the ranking has already drawn a conclusion from it.

The landing page is first-click, and only sessions and orders carry one.
First-click, deliberately. It stays consistent with the mart's primary attribution, which is what makes this table comparable with the channel table on /company/acquisition. A last-click landing page exists upstream and is not exposed, so nothing on this page mixes the two.
Only sessions and orders carry a real landing page. Ad spend and refund legs fall back to the Unknown sentinel, which is why Unknown is not a page anyone landed on and is not a row in the table below.
An order resolves to Unknown when no first-click landing exists — a discount- or journey-only order, an order with no GA4 match, or a Klaviyo-overridden order, whose landing page is reset alongside its source and medium.

Everything below reads that caveat as its ground rule. Unknown is not netted off or redistributed here — it is counted in the strip below with its real orders and Sales, and it is shown as a channel row in its own right on /company/acquisition, where a channel is the grain and Unknown is an answer.

What tripped on this page

The website flags, and only those: the same rule the panel on /company runs, filtered to the section this page shows. It is computed over the Window above from the very rowset the 'traffic that does not convert at all' table below prints, so the card and the table cannot disagree about which pages qualify.

No website rule tripped for this Window
The landing-page rule was evaluated over the days above and no page crossed its threshold. This is an empty result, not a panel that failed to load.

This is the website card from /company, computed here over this page's Window rather than that page's — the two controls do not carry the same bounds, because /company ends its ranges at the last order date and this page ends at the last day the marketing mart carries. Each panel states the window it ran over, which is what keeps two honest answers from reading as a disagreement.

The card names the pages, their sessions and the bar it crossed, and it does not say what to do about them — that is the line ADR 0007 draws between a computed flag and generated prose. The bar is written once, in the stalled fence that feeds the table below, and the card reads it back out rather than keeping a second copy of it.


Every session and order in the window, by kind of row

The table further down is filtered, so this is what it is filtered from. Each kind of row that is not a landing page is counted here with its own sessions, orders and Sales, and every kind adds back to the window total — an exclusion on this page is stated, never silent.

Window: Last 30 · 7 Jul 2026 → 5 Aug 2026 30 days, in which 77 landing pages carried at least one session.

Landing pages shown
51 orders
+
Checkout URLs
47 orders
+
Preview domains
0 orders
+
Unknown sentinel
38 orders
=
Orders in window
136
Sessions shown
3,996 of 4,136
Sales on shown pages
£1,077.30
Checkout-URL sessions
110
Checkout-URL Sales
£659.63
Preview-domain sessions
30
Unknown Sales
£448.96

Checkout URLs are excluded from the ranking, and this is the one exclusion worth arguing about. PRD044 records channel_reporting as free of the /checkouts/ pollution that disqualified ecommerce_funnel; re-measured against analytics, it is not — 115 checkout URLs carry 110 sessions and 47 orders in this window, a conversion rate of 42.7% against 1.28% on real pages.

A /checkouts/ URL is where an order finished, not where a visit began: the session that claimed it started on the checkout domain, so its first-click landing page is a page nobody can land on. Left in the ranking they would take the top conversion rates on the page and push every page a growth lead can actually change below them, which is exactly the failure ecommerce_funnel was rejected for — so switching marts would not have fixed it, and naming the rows does. Their orders and Sales are real and are counted above, and the orders mart on /company is where the business's order count lives.

Preview domains are excluded too, and for a duller reason: *.shopifypreview.com is a theme preview opened by staff and agency, not customer traffic. They carry 30 sessions and no orders at all, which would sit them mid-table as a landing page with a zero conversion rate and, before long, trip the over-a-hundred-sessions-and-no-orders rule below on traffic that was never customers'.

And rows with no sessions are excluded, which is what keeps the Unknown sentinel out of a table of landing pages: spend and refund legs carry no session at all. The filter runs after the window sum, so it only ever drops a page that had no session across the whole window — 0 real pages in this one, carrying 0 orders.


By landing page

Ordered by sessions, most first. Every ratio is summed then divided over the Window above, a ratio with no usable denominator prints an em rule with its reason on the same row, and a page resting on fewer than thirty sessions is marked and still shown.

No Results

fewer than 30 sessions in the window, so the conversion rate on the row rests on that denominator. The row is still shown in full, in its natural position — a thin figure is marked, never hidden. 67 of 77 rows on this table carry it.

Conversion rate is Shopify order rows over GA4 sessions, both taken off the same mart row, which is the honest construction and the reason this page reads channel_reporting. GA4's own purchase event is never used as an order count anywhere on this page: it double-fires from 3 July 2026 and reads roughly twice the true rate, and the funnel mart that carries it also carries the /checkouts/ landing pages described above.

Reading the em rules. A is a rate whose denominator is zero, and the Basis column on the same row names which denominator went missing. It is never £0.00, never 0% and never . AOV is the live case: a page with sessions and no orders has nothing to divide Sales by, and printing £0.00 there would say those sessions bought something worth nothing rather than that they bought nothing. Conversion rate never takes an em rule on this table, because the rowset is filtered to pages with at least one session — the denominator cannot go missing by construction.

new_customer_conversion_rate divides by total sessions, not new sessions. A GA4 first-visit session and a customer's first order are different populations — a first-time buyer often converts on a returning session — so dividing new orders by new sessions divides two unrelated populations. The registry says so explicitly, and the mart's new_sessions column is deliberately not carried onto this page rather than left available to be picked up by mistake.

Small-n marking, on the denominator this page actually divides. /company/acquisition marks rows under five orders, because its ratios divide orders and spend. Every rate here divides sessions, so the bar that applies is the sessions one — thirty, the same bar CONTEXT.md sets for a hollow chart point. A marked page is shown in full, in its natural position: a thin figure is marked, never hidden.


Traffic that does not convert at all

Pages carrying real traffic in this window and not one attributed order. This is the shape the website flag rule picks up in a later slice; here it is just made findable, so the flag and the table cannot disagree.

No landing page in this window carries a hundred sessions with zero orders. The rule still runs; nothing trips it over these days, which is a statement about the window and not about the pages — a page that took a month to reach a hundred sessions cannot reach it in a narrower one.

Across all trading to date, whatever the Window above is set to, the same rule catches 4 pages:

  • https://s3sensitivity.com/pages/b001-launch-a — 192 sessions, zero attributed orders
  • https://s3sensitivity.com/pages/b001-launch-a-v3 — 156 sessions, zero attributed orders
  • https://s3sensitivity.com/pages/b001-launch-a-v2 — 106 sessions, zero attributed orders
  • https://s3sensitivity.com/pages/b001-launch-b — 104 sessions, zero attributed orders

Every one of them sits beside a sibling on the same launch template that does convert, and the ranking above on the All time Window puts the two side by side. Same traffic, same days, different outcome, which is what makes the comparison worth a growth lead's morning — and why the default Last 30 Window, which shows those pages with the traffic they took in the last thirty days rather than all of it, is not the Window to judge a launch test on.

Nothing on this page is suppressed. Thin pages are marked and kept, a rate with no denominator prints an em rule with its reason, and every row the table filters out is counted above with its sessions, orders and Sales. Suppression is reserved for figures that would be actively misleading (CONTEXT.md, Small-n marking) — a page resting on eleven sessions is thin, not misleading, and hiding it would remove the only evidence that the page has traffic at all.

Data baked at

The deployed site is static with no runtime connection to BigQuery, so this rebuild is the data refresh, and the stamp above is the only on-page evidence that the numbers moved.