A shop that only sends the purchase event to GA4 has a revenue figure and nothing else. No abandonment rate per step, no products viewed but never added, no analysis of list performance. The value of GA4 on a shop comes from the complete chain, not from the last link.
Seven events are enough to rebuild it.
The seven events
- view_item_list: display of a product list, category, search results, recommendation block. It lets you compare the performance of placements against each other.
- select_item: click on a product from a list. Combined with the previous one, it gives the click-through rate per list.
- view_item: viewing a product page. The basis of everything else.
- add_to_cart: adding to the cart. Relative to view_item, it gives the add-to-cart rate, the most useful indicator at product level.
- begin_checkout: entering the funnel. This is the boundary that separates browsing from buying.
- add_payment_info: choosing the payment method. The last measuring point before validation, and the one that isolates payment-related abandonment.
- purchase: order confirmed, with the item detail.
An eighth is worth adding when it is easy to wire: remove_from_cart, which flags products removed when shipping costs are discovered.
The item structure
All these events share the same item description structure, and the consistency between them is what makes the difference between usable data and an unreadable report.
Five parameters matter per item: the identifier, the name, the category, the unit price and the quantity. Two more are useful: the brand and the variant.
The identifier is the critical point. It must be strictly the same across all events, and above all identical to the one used in your product feed to Google. A shop that sends the reference in one event and the internal ID in another gets two distinct product entries in its reports, for the same item.
The variant must be handled explicitly. Decide whether the identifier refers to the product or the variant, and hold that rule everywhere. Both choices are defensible, mixing them is not.
Google Tag Pro — Plug & Play PrestaShopE-commerce tracking that no longer loses conversions.€190.00
Prices excluding or including tax
A question with no universal answer, and one to settle before wiring.
The most common convention in Europe is to send prices including tax, because it is what the customer pays and what appears on the order. The alternative, excluding tax, makes reconciliation with accounting easier.
What matters more than the choice: that the order value be calculated the same way, and that you know which one you picked when you compare GA4 to your back office six months later.
Two elements to exclude from the transaction value: shipping costs and taxes are declared in dedicated parameters, not in the total amount. Including them artificially inflates product revenue.
The classic mistakes
The purchase counted twice. The confirmation page reloaded or restored from cache resends the event. It is by far the most frequent anomaly, and it skews revenue upwards. The protection consists of marking the order as already sent, server side or in local storage, and never firing the event twice for the same transaction ID.
A missing or non-unique transaction ID. Without it, GA4 cannot deduplicate. Use the order reference, never a timestamp.
Shipping costs in the value. See above.
The purchase event fired before payment validation. On a redirected payment, the order can fail after the event has been sent. The trigger must happen on the real confirmation page, after the provider’s return.
Unnamed lists. If all your lists carry the same name, you will never know whether your recommendation blocks work.
Consent
Without consent, none of these events should leave with identifiers. Consent mode allows an aggregated measurement to be kept in the absence of consent, provided it is wired correctly and the signals are transmitted before the tags load.
A practical point often discovered too late: if your banner blocks scripts until consent, the events fired during that window are lost. Plan a queue that replays them after acceptance, rather than dropping them.
Verifying
Three levels of control, in this order.
The data layer. In the browser console, inspect its content at each step and check the presence and shape of the parameters. That is where inconsistent identifiers and badly formatted prices show up.
GA4’s debug mode. It displays events in real time with their parameters, and flags the ones that are rejected. Place a full order while watching this screen.
The numerical reconciliation. After two weeks, compare GA4’s order count and revenue with your back office.
The normal gap with the back office
Do not look for perfect equality, it does not exist. A gap of 5 to 15% lower in GA4 is expected, and it has explanations: consent refusals, ad blockers, private browsing, phone orders, and customers leaving the page before the event is sent.
What should alert you is a gap above 25%, or a positive gap, GA4 counting more orders than your back office. The second almost always signals double counting.
The Google Tag Pro module for PrestaShop wires this chain on PrestaShop 8 and 9: the e-commerce events with a consistent item structure, protection against double sending of the purchase, and the articulation with consent.