Google Analytics 4

The problem

A Magento store without real GA4 event tracking is flying blind on the parts of the funnel that matter most: how many people add to cart versus how many actually complete checkout, which products get viewed but never purchased, where shoppers drop off between shipping and payment. Wiring this up by hand means writing theme-specific JavaScript for every checkout step and hoping it survives the next theme update.

How it works

This module renders the events tied to a single page load (view_item_list, search, view_item, view_cart, begin_checkout, purchase) directly from data already available on the server at render time. The rest are real client-side actions, but each one is tied to a Magento signal that holds true on any theme rather than a theme-specific click handler:

• add_to_cart / remove_from_cart come from diffing the shared "cart" customer-data section before and after each change, since every cart mutation on any theme refreshes it
• select_item comes from matching a clicked link's href against the product URLs the listing page's own view_item_list render already seeded
• add_shipping_info / add_payment_info come from watching for a successful call to Magento's own checkout REST endpoints, since every Magento checkout has to call these same core Web API endpoints to progress

Consent and tracking mode

Google Consent Mode v2 defaults go out before the tracking loader runs, so a store can add a cookie banner tool later that simply calls gtag('consent', 'update', ...) on top of this baseline rather than building consent handling from scratch. Tracking mode itself is a single admin setting: GA4 loads gtag.js directly against a Measurement ID, or Google Tag Manager loads your container and pushes events to its own dataLayer.

What you see in GA4

With Debug Mode on, every event this module sends shows up in GA4's DebugView in real time, plus a console log of the same pushes, so you can confirm the funnel is wired correctly before trusting the numbers in reporting.