[Quinn]

Switching from traditional Google Analytics to GA4 presents a unique set of challenges, especially with your complex setup where you look after numerous subdomains and apps. In GA4, the concept of views doesn’t exist anymore. However, you can use data streams within a single GA4 property to represent different apps or sites. For a big organization like yours, a good approach would be to create one GA4 property for each sub-brand, department, or functional unit that needs separate reporting and user access control. Then, for each property, create a data stream for every app or subdomain. This way, you can grant access at property level to mimic the access control you had with views, keeping the same granularity. Remember, a property in GA4 is not the same as in Universal Analytics, it’s rather a flexible container for data, which might represent a brand, a functional unit or any other form of logical separation. As for the user engagement, the switch to GA4 shouldn’t present significant changes unless they were extensively using some features no longer present in GA4.

[Quinn]

Based on your code, it seems you’ve done everything correctly. However, there is a chance you might be running into a race condition issue where the data is not fully registered before the page view event is sent.

In order to debug this, I would suggest checking how you are setting your custom dimensions. Make sure you are using the correct dimension names in your GA4 configuration. You could also verify whether you have correctly set up your GA4 Custom Dimensions config tag in GTM and that the triggering occurs at the right time.

Additionally, check if your dataLayer.push is executing before the GTM event trigger fires. If your dataLayer.push executes after the GTM event trigger, the data may not be included in the event.

Lastly, check your GTM to GA4 data mapping. Ensure that you are mapping from the correctly named variables, and that ‘article_id’, ‘type’, ‘category’, ‘subcat’, ‘pubdate’, match exactly to your custom dimensions in GA4.

Remember, the debugging process may take some time and require a lot of testing to make sure everything is set up correctly.

[Quinn]

Of course, there are practical solutions to avoid firing events to your GA from non-production environments – or when debugging. Indeed, you can also stop GA from recording those events. Let’s go through the process.

Generally, to start firing events to GA4 from GTM, you need a GA4 configuration tag, which requires a measurement ID. But hey, no one said you have to put just the measurement ID, right? You can set it to a CJS:

Just refer to it in your config tag, like this:

This way, whenever you’re working in your lower environment, your local host, or previewing the container on production, your tags and triggers will still fire, but these events will go to a different GA4 property.

And before you ask, it’s actually a good habit to collect your events from lower environments, too – just don’t mix them with your production data. There may come times when you’ll need to review some test data.

Moving on to the second part, GA4 does have data filters. While they’re not as robust as the old filtering system in GA UA, you’ll find the developer traffic filter useful. You’ll just need to add a custom parameter to every developer event that you want visible in the debug view, but not in the reports.

Given GA4’s current limitations and susceptibility to occasional hiccups, it’s generally better to resolve this on the GTM end and reserve GA’s filters for situations that GTM can’t handle.

Remember that GTM has built-in variables you can use, although most of them are turned off by default. When you type {{ and start typing the variable name in your CJS, this will come up:

Click on the option you want, and it’ll autofill for you. But do remember to interpret it as whatever the variable returns. They’re mostly strings, but you can also return a function and execute it like {{cjs that returns a function}}(param1, param2). Here’s an example:

Easy, right? The only thing is, debugging these built-in variables in the console can be a little tricky, so I usually just fetch the hostname from the global object, like this: window.location.hostname.

[Quinn]

It sounds like someone else might have access and is adding these events. Check who has permissions to your GTM and analytics. Once you’ve done that, you can simply remove or modify these events in your GTM – just look for triggers related to these events and remove or disable them.

[Quinn]

In layman’s terms, it sounds like you’re switching over to a new system, GA4, for tracking web traffic data. You’ve mapped some old terms to new ones and want to double-check if you’re on the right track – always a smart move! In addition, you’ve noticed some new terms in GA4 that seem similar to the old ones, and you’re keen to know the difference, which makes sense. Lastly, you’re trying to work with a new API for funnel reporting in GA4, and it looks a tad different from the old system so you want some pointers. I’d be happy to help once I have more specifics!