Skip to main content

​
Overview

The Members Portal can send page views and user events directly to your Google Analytics 4 (GA4) property or your Google Tag Manager (GTM) container. This lets you measure how customers interact with your portal — from first visit through to signup, bookings, and purchases — using the same analytics tools you already know.
You can use either GA4 or GTM, but not both at the same time. If you enable GA4 while GTM is active, GTM will be automatically disabled.

​
Setup

  1. Open the Nexudus admin panel and go to Settings > Integrations > Google Analytics.
  2. Enter your Measurement ID (starts with G-) for GA4, or your Container ID (starts with GTM-) for Google Tag Manager.
  3. Save your changes.
The tracking code is injected automatically on every page of your Members Portal — no additional setup is required.

​
What is tracked

​
Page views

Every page your customers visit is automatically recorded as a page_view event in your GA4 property or GTM dataLayer. This happens on every navigation within the portal, including single-page transitions.

​
GA4 event name mapping

Some portal events are mapped to GA4 recommended event names. The table below shows which portal events are renamed before being sent to GA4 / GTM. All other events are sent with their original name.

​
Event reference

​
Signup funnel

When fired: Customer lands on the signup/checkout page.
When fired: The signup form step loads for the first time.No payload.
When fired: Customer submits the main signup form with their personal details.No payload.
When fired: Customer submits the additional information form during signup (when extra fields are configured).No payload.
When fired: Customer completes the e-invoicing settings step during signup.No payload.
When fired: Customer selects a membership plan from the plan list.
When fired: The add-on products step loads during signup.No payload.
When fired: Customer increases the quantity of an add-on product.
When fired: Customer accepts the proposal/terms and confirms.No payload.
When fired: Customer completes the e-signature for the proposal document.No payload.
When fired: The payment step loads during signup.
When fired: Customer reaches the signup confirmation page after completing all steps.

​
Checkout — starting a purchase

When fired: Customer opens the booking checkout page and the resource details load.
When fired: Customer opens the product checkout page and the product details load.
When fired: Customer opens the event ticket checkout page and the event details load.
When fired: Customer opens the course checkout page and the course details load.

​
Checkout — payment and completion

When fired: Customer submits a payment form. Fired for each payment method (invoice, Stripe, Spreedly, PayPal).
When fired: Payment is processed and the confirmation page loads. Fired once per checkout regardless of items.
When fired: A booking purchase completes successfully. Fired once per booking in the invoice. Can occur via checkout (payment required) or directly (no payment due).
When fired: An event ticket purchase completes successfully. Fired once per attendee in the invoice. Can occur via checkout or directly.
When fired: A plan purchase completes successfully. Fired once per contract in the invoice. Can occur via checkout or directly.
When fired: A product purchase completes successfully. Fired once per product in the invoice. Can occur via checkout or directly.

​
Guest checkout

When fired: Customer clicks “Continue as guest” to proceed without signing in.
When fired: Guest customer creates a permanent account after completing their purchase.No payload.
When fired: Guest customer’s checkout is confirmed and payment succeeds.

​
Bookings

When fired: Customer creates a new booking (before payment, if any is required).
When fired: Customer modifies an existing booking (e.g. changes dates or times).
When fired: Customer clicks the book button on a resource to start an instant booking.
When fired: Customer confirms the instant booking in the confirmation dialog.
When fired: Customer dismisses the instant booking confirmation dialog without confirming.
When fired: Customer successfully cancels an existing booking.
When fired: Customer clicks to confirm a system-suggested booking from their dashboard.
When fired: Customer confirms a system-suggested booking in the confirmation dialog.
When fired: Customer dismisses the suggested booking confirmation dialog without confirming.

​
Events and courses

When fired: Customer registers for an event (before payment, if any is required).
When fired: Customer cancels their registration for an event.
When fired: Customer enrols in a course (before payment, if any is required).
When fired: Customer finishes a lesson and marks it as complete.
When fired: Customer finishes all lessons and reaches the course completion page.

​
Cart and basket

When fired: Customer views the cart page with items in it.
When fired: Customer views an empty cart page.No payload.
When fired: An item is added to the cart.
When fired: An item is removed from the cart.
When fired: The quantity of a product in the cart is changed.
When fired: Customer clicks “Proceed to checkout” from the cart page.
When fired: Customer views the cart checkout confirmation page.
When fired: Cart checkout completes successfully (for purchases with payment due).
When fired: Customer clicks “Continue shopping” from the cart page (potential cart abandonment).
When fired: Customer enters or applies a discount code in the cart or checkout.
When fired: Customer clicks “Continue to payment” to scroll to the payment section.

​
Products

When fired: Customer adds a product to their basket (from the store or quick-buy flow).

​
Authentication

When fired: Customer signs in successfully with valid credentials.No payload.
When fired: Customer attempts to sign in with invalid credentials.No payload.
When fired: Customer clicks a single sign-on (SSO) button on the sign-in page.
When fired: Customer signs out of their account.No payload.
When fired: Customer submits the forgot-password form to request a password reset email.No payload.

​
Profile and account

When fired: Customer saves changes to their personal information.No payload.
When fired: Customer saves changes to their billing information.No payload.
When fired: Customer subscribes to the newsletter from the articles page.No payload.

​
Help desk

When fired: Customer clicks the “Contact us” button to reach the help desk.No payload.
When fired: Customer creates a new support ticket.No payload.
When fired: Customer replies to an existing support ticket.No payload.
When fired: Customer closes an open support ticket.No payload.

​
Forms

When fired: Customer submits a custom form page.

​
Session and navigation

When fired: The Members Portal application loads for the first time.No payload.
When fired: A signed-in customer’s session begins (after authentication is confirmed).
When fired: An anonymous visitor’s session begins (not signed in).No payload.
When fired: Customer navigates to a public-facing page (landing, resource list, events, etc.).No payload.
When fired: Customer navigates to the sign-in or authentication pages.No payload.
When fired: Customer navigates to their personal dashboard.No payload.
When fired: Customer navigates to a location-specific page.No payload.
When fired: Customer navigates to a course page.No payload.
When fired: An admin user navigates to the admin section of the portal.No payload.

​
UTM attribution

The Members Portal automatically captures UTM parameters (utm_source, utm_medium, utm_campaign, utm_term, utm_content) from the landing URL. These are included as properties on conversion events such as signup_completed, checkout_completed, booking_purchase_completed, plan_purchase_completed, event_purchase_completed, product_purchase_completed, and guest_checkout_completed. This means you can track which marketing campaigns are driving signups and purchases without any additional configuration.

​
Analytics in embedded widgets

When you embed the Members Portal into your marketing website using widget embedding, Google Analytics continues to work automatically — no extra configuration is needed. However, there are some differences in how data is collected compared to the standalone portal.

​
How it works

Modern browsers restrict third-party cookies when content is loaded inside a cross-origin iframe (which is the case when your portal is embedded on a different domain). Since GA4 normally relies on cookies to identify returning visitors, the portal automatically switches to a cookieless tracking mode when embedded. In this mode:
  • All events and page views are still sent to your GA4 property or GTM container
  • A temporary session identifier is generated for each visit, so events within a single session are grouped correctly
  • Cross-session visitor recognition (e.g. “returning user”) is not available because the browser blocks the persistent cookies GA4 uses for this

​
Automatic upgrade on interaction

After a customer interacts with the embedded portal (e.g. clicks a booking button), the portal automatically requests cookie access from the browser using the Storage Access API. If the browser grants access, GA4 upgrades to full cookie-based tracking for the remainder of the session, restoring returning-visitor recognition. This happens silently and requires no action from you or your customers.

​
What this means for your reports

If you need full returning-visitor recognition from the first page load, direct customers to your standalone portal domain instead of using the embedded widget for those flows.

​
GA4 vs GTM — which should I use?

If you only need Google Analytics, use the GA4 Measurement ID. If you need to manage multiple marketing tags or apply custom triggers, use Google Tag Manager.