[Daniel]

Firstly, using gtag.js that you’ve implemented is a good way to track load times as Google recommends it and most developers find it efficient and easy to use. You don’t necessarily need to look for alternative methods, unless you’re experiencing problems or limitations.

Secondly, GA4 does not provide an out-of-the-box feature to get averaged load times. However, GA4 is designed to allow for custom data analysis and reporting. You can build this average yourself by creating a calculated field in a GA4 report to compute an average of your page load time metrics. This allows you to view the averaged data in comparison to other metrics you’re interested in, without having to extract and calculate the average by hand.

Remember that while the above is possible, the exact process and steps may vary and might require some knowledge in manipulating GA4’s interface to create reports, calculated fields and other explorations. If you’re finding it complicated, you might find it helpful to look at some tutorials or ask community help for more step-by-step guidance.

[Daniel]

Yes, ideally the GA4’s screen numbers and the BigQuery data would be closely aligned. However, discrepancies can occur due to several reasons like data processing differences, internal filters applied in GA, or event-based or cookie-based session tracking differences. Introducing new events to your site could also potentially affect session tracking and cause discrepancies. In order to align the numbers more closely, you may need to investigate how each platform is calculating and filtering session data. Sometimes it might be an error in the query or the data collection method itself, so make sure to verify that your BigQuery formula is accurately reflecting the session calculations and try to account for any filtering or processing differences within GA4. It’s also important to note that GA4 and BigQuery use different methods to count sessions, handle cookies and manage user identification, which could explain why the numbers don’t match. You’re on the right track, and with some data investigation, you should be able to understand and resolve these discrepancies.

[Daniel]

Google Analytics 4 Measurement Protocol doesn’t automatically extract data fields like Device Category, Operating System, or Platform for you. If you want to track these dimensions, you’ll need to manually set them as custom dimensions and include these custom parameters in each HTTP request. For the ‘ua’ query param, GA4 Measurement Protocol does not parse it, so unfortunately, it won’t help to populate the Users by OS table.

[Daniel]

It seems like you’re right, their docs don’t list currency as a dimension in GA4’s API. Weird, because it’s available in the UI. Maybe you’ll have to assume the currency from elsewhere like your product data? As for APIs, Google didn’t mention them specifically, but since they’re ending UA, I’d assume the APIs will stop working too. You’ll likely need to switch over to the GA4 APIs.

[Daniel]

The issue you’re encountering seems to originate from the event scope of your dimension. When mapping certain types of data in GA4, specifically involving metrics and dimensions, it’s crucial to understand their scopes. User (or broader) scoped variables can encompass the data from event scoped ones but not vice versa. Therefore, when you pull in data from the API, concepts like ‘totalUsers’, ‘newUsers’, etc., which are user-scoped, can’t be correctly captured under an event-scoped dimension such as your ‘exp_bucket’. Your concept of using ‘ab_test_lane_[1|2|3|4|5]’ as a user dimension might help you bypass this scope conflict. However, you’d indeed need to manage the complexity of mapping live experiments to these lanes carefully to avoid inconsistencies in the data.

[Daniel]

Considering your situation, there may be a few possible issues that you might want to check. You should firstly ensure to have Google Analytics 4 properly configured in your Firebase project. You also need to link your Firebase project to your Google Analytics 4 property. Another crucial thing is you must have the latest version of the Firebase/Google Analytics SDK for your iOS app. You can refer to Firebase’s documentation for installing and configuring the SDK. After you’re set with the SDK, it remains necessary to verify whether you’re accurately logging events in your app, detailed instructions can be found again in Firebase’s documentation. I hope this guidance has been useful to get you back on track.

[Daniel]

Sure thing, you can just specify the name of the tracker you want to send the event to. When you create the tracker, assign it a name. Then, when sending the event ‘timeToLoad’, simply add the tracker name before sending the event like this: ga('trackerName.send', 'event', 'timeToLoad'). This tells GA to send the event to ‘G-0000001’ only.

[Daniel]

You can send a specific event to one particular tracker by referencing the tracker name directly when you send the event. For your case, you can first give your trackers names when you create them. For example, ‘tracker1’ to the ‘G-0000001’ and ‘tracker2’ to the ‘G-0000002’. Then, in the command to send the event ‘timeToLoad’, reference it to ‘tracker1’ will send this event exclusively to the first tracker with the ID ‘G-0000001’. An example code might look like this: ga(‘tracker1.send’, ‘event’, { eventCategory: ‘category’, eventAction: ‘timeToLoad’}).

[Daniel]

The problem here is that Google Analytics 4 (GA4) is dropping any rows where dimensions, including custom ones, are null. The posted code is an illustration of this problem. The programmer tried to solve it by flagging GA4 to keep rows even when they’re empty (keep_empty_rows = True) and ignore fields it doesn’t recognize (ignore_unknown_fields = True).

[Daniel]

There really isn’t any particular advantage to using the “Live” GTM snippet. When you access this, you would get the environment parameters filled in just like for any other environment.

Meanwhile, if you select “Install GTM”, the environment-specific parameters are omitted. This is because when these parameters aren’t specified, GTM will default to the live environment.

Identifying the live environment via the snippet doesn’t provide any unique benefits, mainly because it’s not possible to alter which environment is seen as live. As per my knowledge, env-2 is always deemed live. It’s interesting because you might think that env-1 would be preserved for the primary live environment, but this isn’t the case.