Configuring Google Analytics 4 events for post-NCR store tracking

The discontinuation of NCR Retail Online has pushed many Australian merchants toward Magento and WooCommerce, but the move brings fresh questions about how customer behaviour should be measured. Google Analytics 4 is now the default standard, and its event-driven model behaves very differently from the Universal Analytics version that most NCR users relied on. Getting event configuration right from the start prevents data gaps, attribution errors and reporting headaches down the track.

Whether the new storefront runs on Magento Open Source or a WooCommerce build through a Counterpoint partner, the underlying analytics plumbing remains the same. Merchants in Sydney, Melbourne and Brisbane who previously watched pageviews and sessions now need to think in terms of triggered events, parameters and conversion paths. That shift is not just technical; it changes how marketing teams interpret campaign performance across the country.

Understanding the GA4 event model for migrated stores

GA4 treats every interaction as an event, from a product page view to a scroll depth milestone or a checkout step. Unlike the older hit-based approach, events flow into a single data stream and are then evaluated against conversion markers. For a store that previously exported NCR Retail Online transaction data into a separate reporting tab, this consolidation feels liberating but requires careful event naming.

It helps to map out the customer journey before writing any code. Tracking a drinkware range through the new analytics layer might involve view_item, add_to_cart, begin_checkout and purchase events in a single session. Each of those needs a consistent name and a defined set of parameters so the data can be sliced by city, device or campaign later.

Setting up data streams and the GA4 property

The first technical step is creating a GA4 property in the Google Analytics admin panel and configuring a web data stream for the new Magento or WooCommerce domain. Australian businesses should pay attention to the timezone setting, selecting Australia/Sydney or Australia/Melbourne to align with local trading hours and AEST/AEDT transitions. An incorrect timezone will throw off time-of-day reports, which are particularly useful for shops targeting the lucrative evening arvo browsing crowd.

Enhanced measurement should be enabled but treated as a starting point, not a finished solution. The built-in scroll, outbound click and site search events give a useful baseline, but most retailers will need to disable a few or rename them to match internal reporting standards. A Melbourne-based apparel brand, for example, might rename view_search_results to something more intuitive for its team before rolling the configuration out to other regions.

Configuring custom events for Magento and WooCommerce

Magento and WooCommerce handle event firing differently, so the configuration process diverges once the data stream is live. On Magento, the recommended path is to use the Google Tag Manager container combined with a data layer push from the checkout modules. WooCommerce users can rely on plugins such as GTM4WP, which injects the necessary JavaScript hooks into product, cart and order pages automatically.

Custom events should be reserved for interactions that the built-in enhanced measurement cannot capture. Wishlist additions, store locator searches, click-and-collect reservations and afterpay payment selections are common examples in the Australian market. When a Brisbane customer selects Afterpay at checkout, a custom event called select_afterpay with a payment_type parameter of "afterpay" provides far better insight than the generic add_payment_info event alone.

Tracking conversions and enhanced ecommerce in GA4

Once events are firing reliably, the next task is marking the commercial ones as conversions. In GA4, this happens through the admin interface by toggling the conversion flag on specific events. Purchase, add_to_cart and begin_checkout are the usual suspects, but sign_up for loyalty programs and generate_lead for contact form submissions are equally valuable for retail businesses operating across multiple states.

Enhanced ecommerce reporting in GA4 also requires the collection of item-level data. For every purchase event, the transaction_id, value, currency, and an items array containing item_id, item_name, item_category and price should accompany the event. A Sydney-based homewares store migrating its product feed needs to ensure that item_category values align with the existing taxonomy, otherwise funnel reports will fragment and become difficult to trust during EOFY reporting. For stores running campaign-specific landing page hosting without a full website, the GA4 measurement ID must be added manually to each standalone page, and UTM parameters verified to maintain attribution accuracy.

Mapping old NCR event data to GA4 parameters

One of the trickier parts of the migration is reconciling the event names and parameter structures that were used in NCR Retail Online with the GA4 schema. Old custom dimensions such as store_id, till_id or staff_member do not transfer automatically. These need to be either remapped to GA4 user properties or sent as custom dimensions, depending on how broadly they apply across sessions.

A practical approach is to maintain a mapping document during the transition. List every legacy event, its purpose, the GA4 equivalent and any gaps that need a custom implementation. Australian retailers with multiple physical stores often find that store_id is a critical dimension, because marketing spend is frequently allocated by region. Sending it as a custom dimension with a scope of user ensures the data is available in every report that includes that identifier.

Validating events with DebugView and real-time reports

Before trusting the data, every event configuration needs to be validated. GA4's DebugView provides a real-time stream of events from a single device, making it easy to confirm that parameters are firing as expected. Tag Assistant in Google Chrome can also verify that the Google tags are loading correctly on each page template, from the homepage to the order confirmation screen.

Real-time reports offer a broader view, showing which events are being collected across all active users in the last 30 minutes. During a migration, it is worth scheduling validation windows during peak traffic periods, such as a Thursday evening Melbourne flash sale or a Brisbane lunchtime promotion. If event volumes look healthy in those windows, the configuration is likely sound enough to proceed with the public launch.

Maintaining compliance and data quality post-migration

Analytics configuration is not a set-and-forget task, particularly when handling payment data. GA4 itself does not process card details, but the event parameters it collects can include order values, transaction IDs and sometimes customer identifiers. Reviewing the PCI compliance guide alongside the analytics setup helps ensure that nothing sensitive slips through the data layer.

Data quality should be reviewed on a regular cadence, ideally monthly, to catch any drift caused by theme updates, plugin changes or new product launches. A regional campaign targeting Adelaide and Perth shoppers through a standalone Black Friday landing page will only report correctly if every event on that page carries the proper tracking parameters and the measurement ID remains consistent across the site.

The most practical starting point is to install the GA4 property, enable DebugView and fire a single test purchase event from a staging environment before migrating the rest of the catalogue. Once that test event arrives in GA4 with the correct transaction_id, value and items array, the foundation is solid enough to begin rolling events across the live site.