[Henry]

In Google Analytics, the “(not set)” entry is quite common and it occurs when Analytics hasn’t received any information for the dimension you’ve selected. For the case of ‘New vs Established’, it’s possible that for 0.5% of your sessions, Google Analytics was unable to determine whether the user was new or returning. There can be multiple reasons for this – it could be related to the users’ browser settings, such as blocking cookies or using incognito mode, which prevent Google Analytics from accurately tracking and categorizing the user. It might also be due to a small delay in data processing within Google Analytics itself. In all cases, it’s good to note that a small amount of ‘(not set)’ data is pretty normal and typically doesn’t impact your overall insights significantly.

[Henry]

In simple terms, these individuals are encountering some trouble when trying to send purchase events from their client’s server using a certain protocol. The issue is that a crucial ‘session_id’ parameter is missing, which causes other important information about source and medium to be lost. This has remained a problem even after trying to include the ‘session_id’ parameter in the request. They have shared the specific code they have been using
to try and resolve this problem. They are seeking advice on how to correctly include the ‘session_id’, or alternatively, how to ensure their events maintain all the necessary information. The solution involves adjusting the way they are sending the purchase event, being careful to include all necessary info and parameters, and doing away with some unnecessary ones.

[Henry]

Sounds like there could be an issue with the way your scripts are interacting with the browser’s history. This often happens when something interrupts the natural flow of the “back” function. Without seeing your scripts, it’s hard to be exact, but a common issue could be that your scripts might be adding entries to the history stack, which then misleads the “back” function.

[Henry]

It seems like you’re right about the user-attribution data (things like traffic name, source, and medium) not being included in the streaming export to BigQuery. From how I interpret Google’s statement, it looks like this data does take around 24 hours to fully process, so it won’t appear right away in your intraday tables. Rather, it would be included in the full daily export.

Because of this, for a complete data set, you might indeed need to run both streaming and daily exports simultaneously. However, whether the daily table can gather over a million events per day would largely depend on your specific setup and limitations on Google’s end. The technical specifics of these limitations would be best confirmed with Google’s support or their official documentation.

Remember, when dealing with such large amounts of data, it’s always a good idea to keep an eye on any potential costs or performance issues that could arise.

[Henry]

Sure, here’s the deal. You can adjust the trigger in Google Tag Manager to exclude the page view event for a specific page. Essentially, you’ll be setting up an exception to the rule.

Just like this: check out the image link for a visual idea!

[Click here](https://i.stack.imgur.com/qajWk.png)

So, it’s a bit tricky if you have a Single Page Application (SPA) page view. The current Google Analytics 4 page view tag only allows you to trigger on history changes instead of adding individual history change triggers.

In this case, you’ll have to stop it from firing page views on every history change and set it up again using normal triggers. Then, add your exception to these triggers.

I know it might be a little challenging, but once you set it up, you are good to go!