Conversions by page in GA4: why the thank-you page gets all the credit

You want to know which pages on your site sell. GA4's Pages and screens report has a Key events column, so you sort by it, and for most shops the answer is the order confirmation page: nearly every sale on the one page nobody reaches until they have already paid.

So you try the other obvious thing: give a sale to every page the buyer looked at. Now the product page, the basket and the blog post all get credit, and the column adds up to several times the sales you actually made. Neither answer is what you were asking. Here is why, and which question GA4 can answer fairly.

An example

An invented furniture shop, one month, 100 orders. The purchase is the key event, and it fires on /order-confirmed. The orders came in three routes:

• 50 visits started on the home page, then went to the oak table, the basket, checkout and the confirmation page.
• 30 started on the oak table's own page and went straight through.
• 20 started on a blog guide, Choosing a table, then followed the same route.

Three ways to put those 100 orders against pages:

The first column is what the Pages and screens report shows. It adds up, but it only says where the tag fired. The second credits every page in the visit and totals 470 orders, 4.7 times the real 100, with nothing on the page saying so. The third adds up and answers a real question: which pages start the visits that end in a sale.

Why it happens

A purchase is one event, sent from one page. On a website, GA4 collects the page's address with every event, including custom events (the page_location parameter). The Key events metric is "the number of times users triggered a key event", so in a report split by page path, each one lands on the page it was sent from. For most shops that is the confirmation page.

The visit is a different thing. Google defines the landing page as "the page path associated with the first page view in a session". A session has exactly one first page, so each order sits on exactly one landing page and the column adds up. Google's session key event rate is defined on the same unit: "number of sessions in which a key event happened / total number of sessions".

The pages in the middle of the visit have no such rule. The oak table was seen in all 100 visits that bought, but so were the basket and checkout. Giving each of them the full sale counts the same order four or five times.

A sale belongs to one visit. Put it against one page per visit, and the column adds up; put it against every page, and it stops meaning anything.

Where it bites

• Content decisions. In the Pages and screens report the blog guide shows no key events at all, so it looks like it sells nothing. By where visits started, it brought in 20 of the 100 orders.
• Reports with a total row. A "conversions by page" table built by crediting every page cannot be totalled. Here it would claim 470 orders.
• Mixing a page with a visit in one table. When we built Glancely's landing page table, it was split by page title as well. A page title belongs to each page viewed, not to the visit, so each landing page broke into one row per page title in the visit, and its sales went to the row titled with the checkout page. The other rows for the same landing page read zero.

How to get the right number

• For "which pages start visits that sell", open Reports > Engagement > Landing page in GA4. Read Key events beside Sessions. If the report is missing, Google says an editor can add it back to the left navigation.
• Compare by rate, not by count. Divide orders by the sessions that started on the page. In the example the home page started 2,500 visits and 50 orders (2.0%), the oak table 1,200 and 30 (2.5%), and the blog guide 400 and 20 (5.0%). The guide is the smallest page by orders and the best by rate.
• Use Pages and screens' Key events as a tracking check, not a verdict on content. Each key event should be on the page where you expect it to fire. A purchase showing on the basket page means the tag is firing in the wrong place.
• If you count "visits that saw this page and bought", in an exploration, BigQuery or a spreadsheet, read each row on its own and never total the column. It shows that a page is on the way to a sale, not that it caused one: the basket scores 100 here and persuaded nobody.
• Do not add a page dimension to a landing page table. Page title and page path describe each page viewed, so the visit's sale lands on one of its rows and the rest read zero.

How Glancely handles it

On Glancely's Analytics page, the "What do they do?" section has two tabs. Landing pages shows sessions, conversion rate and revenue for each page a visit started on, one row per landing page. Top content shows views, users and engagement for every page read, with no conversion column, and a line under the table saying that conversions are counted per visit, so they are shown against landing pages instead. The order people view pages in is on the Behaviour page's Journeys tab, for properties with GA4's BigQuery export connected.