[Sophia]

In Google Analytics 4, ‘Engagement Rate’ is calculated as the total number of ‘Engagement Events’ divided by the total number of ‘Users’, (Engagement Events / Users)*100. In BigQuery, the calculation involves a similar approach. First, you will need to count the engagement events from the ‘events’ table, and then divide it by the total number of users from the ‘user_pseudo_id’ field. The ‘events’ table contains the details of each interaction or engagement event made by users, like first_open, app_remove, etc. The ‘user_pseudo_id’ is an identifier for each user that gets mapped to it across devices and platforms. You can use these to match your BigQuery analytics with GA4 UI for calculating the engagement rate. However, it’s pertinent to remember that applying filters and segments can lead to the discrepancy in the data points from the UI and BQ. Try to ensure that both data sets are identical before comparison.

[Sophia]

Unfortunately, you cannot directly pass the Universal Analytics (UA) custom dimensions to Google Analytics 4 (GA4) without making changes to your JavaScript code. This is because UA and GA4 handle custom dimensions differently. UA uses a flat structure with custom dimensions & metrics being numbers (like dimension1, dimension2), but GA4 utilizes an event-based model and its custom parameters are named.

It means you’ll have to modify the JavaScript code to handle GA4 custom dimensions (user properties). You’d need to, for example, use gtag('event', 'some_event', {'dimension_name': 'value'}); for GA4.

You also can’t use the same custom dimension tag to send data to both your UA and GA4 properties because of their different implementations. They would need separate tags.

Remember to set up the new custom dimensions in GA4, then in GTM ensure your tags reflect the different custom dimension structure of GA4 compared to UA. Finally, thoroughly test everything before fully migrating.

Keep in mind that enabling GA4 does not mean you have to immediately stop using UA. Both can and should run simultaneously during your transition.

[Sophia]

Yes, you’ve got the gist of it. Essentially, what’s happening is that a user is trying to track website traffic using Google Tag Manager (GTM) and Google Analytics 4 (GA4). Because of people working from home, the typical IP address filtering isn’t going to work. So, the user is looking to filter data by individual user IDs, which are already being tracked.

The user has set things up so that they are in debug mode, meaning they have extra visibility of what’s happening. They’re confident their user ID system is working, but they are seeing something unexpected. Even though they haven’t put GTM in “Preview” mode (a specific debug mode for GTM), they’re still seeing data in the GA4’s Debug View. They’re also seeing this data on the real-time dashboard. The question seems to be about why this is happening and possibly how to stop or fine-tune it.

[Sophia]

It sounds like you’ve run into a situation where elements that are created and added to the DOM (Document Object Model) via Google Tag Manager (GTM) are not being removed, leading to a buildup of these elements each time a page view event occurs. This might cause a memory leak situation, as you’ve observed in Chrome DevTools. This is not typical behavior for GTM, there may be something in your specific setup or custom script/iframe elements causing this action.

It’s a good idea to consider a cleanup routine. This can be a GTM tag that triggers when all elements are in the DOM, then cleans up these extra elements. Alternatively, it can be a routine within your app itself that tracks and removes these extra elements. It’s likely worthwhile to test these options out to see whether they mitigate the memory leak issue you’re encountering. Keep in mind that this is a deeper technical issue that may require more specific technical advice or direction.

[Sophia]

Here’s the deal – if you want to create a copy of your GA4 property, the easiest way would be to just create a new property with a different measurement ID. This would be like creating a new destination for your data.

But here’s my honest take – while this approach could work, it may not be the best solution for what you’re trying to do. Instead, why not just give your team access to the main property but only with read-only permission? This way, they can get a feel for things without risking any accidental changes.

There’s also another, more complex, way to duplicate a property which involves exporting the data from the original property and re-inserting it into the new one with a measurement protocol. But if I’m being real with you, this seems a bit extreme for your situation and probably not worth the trouble.

[Sophia]

Unfortunately, no, Google Analytics API doesn’t support getting data for multiple URLs in a single API call. You would have to call the API separately for each URL. However, you could potentially write a loop in your backend to automate these calls.

[Sophia]

Sure, I’ll be glad to help you. You may want to verify if you have the most recent version of the Google Tag Manager extension and update it if necessary. Also, ensure you’ve refreshed your page after enabling the debug mode in Google Tag Manager. You might want to clear your cache as this sometimes helps. Another option might be to check if your tag triggers are configured correctly and the event you are trying to track is happening as expected. If your tag is related to link clicks, you should check that the links aren’t redirecting too fast for the tag to fire. Finally, consider checking whether any other extensions or internal settings are potentially blocking your tags. If none of the above works, you might consider reaching out to Google Support for assistance.