How do I set up GA4 for ecommerce?

The most common setup problem is not a missing tag, it is two of them. A store connects the platform's built in integration, then someone adds the tag through a tag manager as well, and every event fires twice. Sessions inflate, revenue doubles and nobody trusts the reports again.

So decide on one installation route before you touch anything. Either the native connection your ecommerce platform provides, or your own tag through a tag manager. Not both.

Create the property and a single web data stream for your storefront domain. Note the measurement id. If your checkout runs on the same domain as the store, which it does for most Shopify setups, you do not need cross domain configuration. If any part of the journey sits on a different domain, configure that before you look at any numbers, otherwise every checkout will start a new session and appear to come from a referral.

Then verify with the real time report and the debug view. Place a test order, watch the events arrive, and confirm each one appears once. Ten minutes here saves weeks of doubting the data later.

Everything else is diagnostic. The purchase event is what your revenue reporting and your channel comparisons rest on, so check it field by field.

It needs a transaction id that is unique per order, so a refresh of the thank you page does not create a second sale. It needs a value, and you have to decide once whether that value includes tax and shipping, then apply the same rule everywhere so comparisons hold. It needs a currency code, and if you sell in several currencies each event must carry the right one or the totals will be nonsense. And it needs an items array carrying item id, item name, price and quantity, because without it none of the product reports work.

The item id should match the identifier you use in your product feed and in your other systems. When the same product has three different identifiers across analytics, the feed and the ad platforms, joining the data becomes a manual job forever.

Test with a real order rather than a simulator. Then test a refund, and decide how refunds are recorded, because a channel that drives returnable orders looks better than it is until refunds are subtracted.

You need enough events to see where people drop and no more. The recommended ecommerce set covers it: view_item_list and select_item for browsing, view_item on the product page, add_to_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info and purchase.

That sequence gives you a funnel you can read: how many people saw a product, how many added, how many started the checkout, and where between shipping and payment they stopped. Most stores never need anything beyond it.

What you should resist is instrumenting every click on the site. Custom events multiply quickly, they arrive with inconsistent naming, and within a year nobody can remember what half of them mean. If an event will not change a decision, do not send it.

Make sure the events carry the same item parameters as the purchase event, so you can follow a specific product from view to sale. An add_to_cart with no item details tells you a number and nothing else.

If your platform has its own customer events or pixel system, use it to send these rather than trying to attach listeners to theme elements, which break the next time the theme is updated.

Four settings decide whether the property is useful in a year.

Data retention. The default retention for user and event level data is short. If you want to look back further in the exploration reports, raise it to the longer option immediately, because the setting is not retrospective and the months you lose are gone.

Internal traffic. Filter your own office, your warehouse and your developers by IP, and exclude any staging domain. Otherwise your own team's browsing shows up as engaged traffic on your best pages.

Key events. Mark purchase as a key event, and usually begin_checkout as well. This is what feeds your reporting and any linked ad accounts.

Unwanted referrals. Payment providers that take the shopper off site and return them will otherwise appear as a referral source that receives credit for the sale. Add them to the list so the session keeps its original source.

Also link the property to your ad accounts and to Search Console. The links are quick and they make several reports work that are otherwise empty. And set the reporting time zone and currency to match your business before data accumulates.

Before you use any of it, compare a full month against your store admin. Orders, revenue and average order value. Analytics will report slightly fewer orders and slightly less revenue because of consent choices, ad blockers and in-app browsers. A small stable gap is normal and workable. A large or changing gap means something is broken and needs fixing before the reports are used to spend money.

Then build four things and no more.

Acquisition by channel with orders and revenue, so you can see which sources pay. Landing page performance with conversion rate, so you know which pages carry the traffic. A funnel exploration from view_item to purchase, split by device, which is where mobile problems become obvious. And product performance, so you know which items get viewed but not added.

Check those four weekly and note what changed on the site each week alongside them. The notes matter as much as the numbers, because six months later they explain the movements.

Everything else in the tool can wait until you have a specific question it needs to answer.