TL;DR
The browser copies come with the extension's GTM container, and a container imported before v1.12.1 needs the re-import that release asks for [1]. On PRO, the server copies are two entries in the Measurement Protocol Track Events list. Your numbers depend on which Magento account flows produce them. Magento signs a new customer in as part of registration unless email confirmation is required, the account offer on the order success page creates a customer without signing anyone in, and a shopper recognized through Remember Me is never logged in. Choose browser or server delivery per event, walk five flows in DebugView, mark sign_up as a key event, and read logins with registrations taken out.
Key Takeaways
- Sign Up and Login moved into client-side tracking in v1.12.1; "previously, these events were only available in the PRO version via the Measurement Protocol functionality" [1].
- Track each event on one side only.
Automatically disable data layer for enabled measurement protocol eventsenforces that for every event you send by Measurement Protocol [1]. - A registration without email confirmation produces a sign_up and a login, because Magento logs the new customer in [7].
- An account created from the order success page produces a sign_up and no login, and where Persistent Shopping Cart is enabled, a Remember Me return produces neither event.
- The extension sends the same
methodvalue on every sign-up and login, so GA4's Method dimension [2] [3] can't split Google sign-ins from email sign-ups. - Marking sign_up as a key event counts from that day forward and "doesn't change historic data" [4].
Browser or server: which copy should each event use?
Version 1.12.1 (May 30, 2023) "Added Sign Up, Login and Search events to the extension's Client-Side tracking capabilities. Previously, these events were only available in the PRO version via the Measurement Protocol functionality" [1]. Track Sign-Ups and Track Logins are features of both editions, and Measurement Protocol Tracking for Sign Up and Login is PRO [1] [6]; our Standard vs PRO comparison covers the rest of that split. The product page describes the login as firing "either via the Create Account/Login Page or via the Checkout Page" [6]. The event definitions themselves are in our older article on which ecommerce events the extension tracks.
On PRO you add Sign Up and Login to the Measurement Protocol Track Events list, and the user guide's rule applies: "make sure that you only track events on one side or another" [1]. The Automatically disable data layer for enabled measurement protocol events option removes the guesswork, because with it on, "even existing GTM tags will not fire because the data layer is not sent" [1]. The full Measurement Protocol setup is in our server-side tracking guide.
The choice turns on how account actions work. A shopper submits a form, and Magento answers with a redirect. The browser copy of the event goes out only when the next page loads the GTM container. The server copy is sent by the store itself, with no page load involved. If sign_up has to be counted on every flow, including the success-page offer, send it by Measurement Protocol. If your other events run in the browser and these two are for context, the browser copies are fine.
Consent applies to each copy differently. The browser copies of sign_up and login run in the GTM container, so they follow its consent handling (on PRO, the Consent Management Method in the GA4 configuration; with Magento Cookie Restriction Mode, the default, the container loads only after the shopper accepts cookies); the PRO server copies are separate, and since v1.17.4 they wait for consent only when Require Visitor Consent for Server-Side Events is switched on [1]. Our guide to server-side events and consent has the detail. Signed-in shoppers are where PRO's Send User-ID comes in, which our article on the PII controls that actually exist covers.
Which account flows fire which event
The event names suggest one sign-up per new account and one login per returning visit. Magento's own account handling produces something else [7], and here's what DebugView shows:
| What the shopper does | sign_up | login | Why |
|---|---|---|---|
| Registers, no email confirmation required | Yes | Yes, right after | Magento signs the new customer in as part of registration |
| Registers, confirmation required | Yes | Later, on confirming or logging in | Magento holds the login until the account is confirmed |
| Creates an account from the order success page | Yes | No | Magento creates the account from the guest order without signing the shopper in |
| Logs in on the login page or during checkout | No | Yes | A standard login [6] |
| Comes back recognized by Remember Me (Persistent Shopping Cart enabled) | No | No | Magento's persistent cart recognizes the shopper without logging them in |
Two rows change how you read reports. The first means a registration is counted twice, once in each event. The last means returning shoppers who ticked Remember Me can browse and fill a cart without ever producing a login.
For the success-page row, look for the browser copy of that sign_up on the next page the shopper opens, not on the success page itself. PRO's server copy doesn't wait for a page load.
If a social-login module creates accounts on your store, add one of its sign-ups to the test below, because how it signs the shopper in is up to the module.
Does the GA4 login event's method tell you how they signed up?
Google's reference gives both events an optional method parameter, "The method used for sign up." on sign_up and "The method used to login." on login, with "Google" as the example value [2]. GA4's Method dimension is "The method used to sign up, login, or share (e.g., Google, Twitter, etc.)", populated by that parameter [3].
The extension sends one fixed method value for every sign-up and login, browser and server alike, and you can see it on any of the test events below. So the Method dimension will show a single row. It can't tell a Google sign-in from an email registration, whatever your login buttons say.
To split them, you need a different signal: the landing page or source of the session that ended in the sign_up, or the social-login module's own reporting.
Test five account flows in DebugView before you trust the numbers
Open DebugView as our verification guide describes, use a fresh email address, and run these in order:
- Register on the account page with email confirmation off. Expect a sign_up followed by a login.
- Log out, then log in from the login page. Expect one login and no sign_up.
- Place a guest order and create the account from the success page. Expect a sign_up with no login, arriving on the next page you open.
- Log in during checkout with an existing account. Expect one login.
- If Persistent Shopping Cart is enabled, log in with Remember Me ticked, let the session expire without logging out, then come back. Expect no login.
On PRO, read the server copies in var/log/ga4.log with Enable File Log switched on [1]. If any flow shows the same event twice, one copy comes from the browser and one from the server, which breaks the one-side rule above.
Mark sign_up as a key event, then read it against purchases
In GA4, go to Admin > Data display > Events and click the star next to sign_up [4]. Purchase is a key event by default; sign_up is not. The change can take up to 24 hours to show [4]. Leave the counting method on Once per event, which "counts a key event every time it's triggered" and is Google's recommended setting; Once per session counts "only once within a particular session" [5].
Then read the two account events against purchases in the same date range. sign_up against purchase is a rough guide to account creation around purchases, with one twist: success-page accounts are sign-ups that arrive after the purchase they belong to.
Take an illustrative peak weekend with 1,200 purchases, 300 sign_ups and 900 logins, on a store with email confirmation off. If all 300 sign-ups came through the registration page, each also produced a login, so 600 logins came from shoppers who already had an account. That 600 is closer to "returning customers who logged in" than the raw 900, and it still leaves out everyone Remember Me brought back.
FAQ
Do I need PRO to track sign-ups and logins?
No. Both editions send them from the browser [1]. PRO adds the option of sending them by Measurement Protocol instead.
Do sign-ups also reach Klaviyo or Reddit?
Not through these GA4 settings. Klaviyo's integration has its own Created Account event, covered in our Klaviyo server-side tracking guide. The Reddit pixel has a separate SignUp event in its own Track Events list, explained in our guide to setting up the ad pixels from one admin.
Will marking sign_up as a key event fill in last month's reports?
No. Google's wording is that marking an event "affects reports from time of creation. It doesn't change historic data" [4]. Mark it before the peak weeks you want to measure.
Send both events with the Magento 2 Google Analytics 4 extension, pick a side for each, and run the five flows once.
Sources
- WeltPixel Google Analytics 4 User Guide and Change Log (Features; Measurement Protocol settings; Consent Management Method; v1.12.1 and v1.17.4 entries), retrieved October 6, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
- Recommended events reference: login and sign_up, Google Analytics developer documentation, last updated September 16, 2026, retrieved October 6, 2026, https://developers.google.com/analytics/devguides/collection/ga4/reference/events?client_type=gtm#login
- GA4 dimensions and metrics (Method), Google Analytics Help, retrieved October 6, 2026, https://support.google.com/analytics/answer/9143382
- Mark events as key events, Google Analytics Help, retrieved October 6, 2026, https://support.google.com/analytics/answer/13128484
- Change the counting method of key events, Google Analytics Help, retrieved October 6, 2026, https://support.google.com/analytics/answer/13366706
- WeltPixel Magento 2 Google Analytics 4 extension product page, tracked events table, retrieved October 6, 2026, /products/magento-2-google-analytics-4-ga4-extension-with-gtm-server-side-tracking
- Magento Open Source, 2.4-develop branch, Customer, Checkout and Persistent modules, GitHub magento/magento2, retrieved October 6, 2026, https://github.com/magento/magento2/tree/2.4-develop/app/code/Magento