Send Event Hits Before Pageview Hits in Google Analytics

One of the myths surrounding Google Analytics is that the first hit of a session should always be a pageview. It makes sense - sessions are initialized with a landing page, and thus need a page view to have one.

However, in this article I want to show you empirically how this myth is just that - a myth.

There is little discernible impact if the first hit of a session is an event, and GA is more than capable of stitching the first event together with the subsequent pageview into a session entity.

The three repercussions I could find were:

1. Entrances and Sessions not matching up with the Page dimension. See here for some details, too.

2. Behavior Flow report attributes the event page as the “Landing Page” and the page sent with the pageview as the “Starting Page”.

3. Goal Completion Location for an event goal set for the event in question shows (entrance) if the event was the first hit of the session.

I’ll explore these later on in the article.

Test setup

Here’s how I tested this. I created four test cases. Each pair of event-pageview hits was contained in its own session (using the sessionControl parameter).

All events were sent from page /, where as the pageview hits always had a different page parameter. This was mainly to see the impact of the event’s page parameter on the Goal Completion Location (there was none).

I also created an Event goal which matched all the events sent with this test.

Here are the test cases:

1. Non-interactive event as the 1st hit, pageview on /test-event-1 as the 2nd hit.

2. Interactive event as the 1st hit, pageview on /test-event-3 as the 2nd hit.

3. Pageview on /test-event-5 as the 1st hit, non-interactive event as the 2nd hit.

4. Pageview on /test-event-7 as the 1st hit, interactive event as the 2nd hit.

Here’s what a sample command looked like. This is for the first test case:

ga('create', 'UA-XXXXXX', {name: 'test'});
ga('test.send', 'event', 'eventFirstHit', 'nonInteractive', 'noPath', {nonInteraction: true, sessionControl: 'start', campaignSource: 'test_event_1', campaignMedium: 'test_event_1'});
ga('test.send', 'pageview', {page: '/test-event-1'});

The first line creates the tracker.

The second line dispatches the event. You can ignore the noPath label and the campaignSource/Medium parameters - they were just used to control the test analysis in GA.

This is what the fourth test case code looked like:

ga('create', 'UA-XXXXXX', {name: 'test'});
ga('test.send', 'pageview', {sessionControl: 'start', page: '/test-event-7', campaignSource: 'test_event_7', campaignMedium: 'test_event_7'});
ga('test.send', 'event', 'eventNotFirstHit', 'Interactive', 'noPath');

Results

Here are the results of the test.

The first thing to note is that not one of the test cases produced a session with Landing Page (not set). That’s a red herring I’ll discuss this briefly in the next chapter.

Test case 1

Test case 2

Test case 3

Test case 4

Results overview

As you can see, even if the event was sent as the first hit of a session, it didn’t cause the cosmos to implode. Google Analytics is able to build the session nevertheless, treating the event as the first hit of the session, and adding subsequent hits (other events, pageview) to the session normally.

The main impacts of sending an event as the first hit of a session are:

1. The Landing Page is associated with the first pageview of the session. The page sent with the event hit cannot be the Landing Page.

2. When querying against the Page dimension, the Entrance is always incremented for the page sent with the pageview, but the Sessions metric is incremented for the first hit - non-interactive or interactive.

3. Goal Completion Location will always be the URI of the most recent page view sent before the event goal was completed. If the event is the first hit of the session, there is no preceding pageview, so the goal completion happens at (entrance).

Landing page (not set)

One red herring surrounding events and pageviews is that sending an event as the first hit of a session results in the Landing Page dimension showing (not set). This is something that Google Tag Assistant warns about.

Landing Page will be (not set) only if the session didn’t have ANY page views. Since the Landing Page is always the URI of the first pageview sent in the session, a session with no pageviews will have no Landing Page.

Sending an event as the first hit of a session does not automatically imply that the session will have no pageviews. Claiming otherwise is a non sequitur.

Note that if you have any events firing on your page, you will always risk having sessions with only events. All it takes is for the user to take a break of 30 minutes after the pageview was dispatched, and then scroll down the page, firing a scroll event you’ve configured.

This will start its own session (since the previous one expired after the 30 minute timeout was reached). If this scroll event isn’t followed by a pageview within the session timeout period, the event will be contained in its own session with landing page (not set).

But, if the event is followed by a pageview before the session timeout expires, the landing page will be the path of the pageview. Remember that.

Session with only non-interactive events

Similarly, a session with only non-interactive events will have a Landing Page of (not set).

However, unlike sessions with just interactive events (or a mix of interactive and non-interactive), sessions with just non-interactive events will not increment the Sessions metric, as that requires an interactive hit. They do increment the Users metric, which is why you’ll sometimes see more Users than Sessions.

But still, this is unrelated to having events fire before the pageview when a session starts.

Summary

As my tests above show, it’s OK to have an event precede the pageview hit when a session starts. You don’t have to rush to tag sequencing in Google Tag Manager to fix this “problem” - the implications are not severe at all.

So why is this still being warned about? Well, apart from misunderstanding how sessions work, there is a seed of truth in being cautious if you have events that can fire before the pageview on any given page. It’s potentially hazardous if you set campaign parameters with the pageview hit that are missing from the event hit.

Since the pageview is the nexus of Google Analytics’ session, it follows that most care is put into making sure the pageview hit has all the necessary session, campaign, and cookie modifications. This lopsided focus can be problematic in Google Tag Manager, where each hit has its own unique tracker object, and thus the hits don’t inherit anything from a common tracker, as with analytics.js and gtag.js.

In other words, you might modify your pageview hit to include campaign-defining fields such as campaignSource and campaignMedium, or you might modify its Document Location field to have UTM parameters manually appended to the URL string. Or, you might even rewrite the clientId field in the pageview hit alone.

The key thing here is consistency. Any modifications to campaign- or session-parameters in individual hits or tags should be applied to all hits or tags that can fire on the same page.

Since an event hit is capable of creating and populating a session on its own, it’s vital to have that event hit mirror the campaign settings of the pageview hit, and vice versa.

If you do that, you’ll avoid having rogue sessions starting simply because an event hit had totally different campaign settings from the pageview hit. In Google Tag Manager, the best way to mitigate this is to use the Google Analytics Settings variable.

Do you think I missed something crucial in this test? Please let me know in the comments.