first_visit and session_start when sending events to GA4.

[emilianorios1]

Hi there, at my work we've been trying to use this Client to receive events in GTM SS and send events to GA4 through a Tag.

I've found that some of the reports end up broken because of a few parameters collected by the GA4 Client which are not calculated or shown in the Snowplow Client. Mainly the ones that makes metrics which regard the first session or the first visit of the user.

In a GA4 Client when a new session is set the "ss" is set to 1 which triggers a "session_start" event and when a new client_id is set then "fv" is set to 1 which triggers a "first_visit" event. Don't mind the "dbg" parameter which means debug.

"x-ga-system-properties" currently does not exist in events coming from a Snowplow Client, could it be added?

Thanks, looking forward to your reply. :)

[adatzer]

Hi @emilianorios1 and thank you for raising the issue! It sounds as something useful to implement!

Can you please help me fully understand what is required, possibly with an example of a simple Snowplow user journey and the desired outcome?

At this point the first thing that comes to mind is using the Snowplow client_session context entity. If this information is available/attached on the event then:

Example 1:

User A visits page A for the first time. This triggers a Snowplow page-view event. Then we can possibly map:

• ss to sessionIndex, which in this case will be 1
• fv to eventIndex (or sessionIndex), which will also be 1 in this case

Example 2:

User A visits page A for the second time on same session. This triggers a Snowplow page-view event. Then we can map:

• ss to sessionIndex, which will again be 1 ? or should it be something else denoting not-a-session-start?
• fv to eventIndex (which will be > 1)? or should it be 0 in this case, denoting not-a-first-visit ?

Example 3:

User A visits page A for the first time on next session. This triggers a Snowplow page-view event. Then we can map:

• ss to sessionIndex, which will be 2 - would this be fine?
• fv to ?? does this count as a first-visit?

You mentioned about fv:

when a new client_id is set

When this happens? How that works for GA? When is a new client_id being set?

---

Also, what about the session_start and first_visit events? From Snowplow side we are having a page-view event. Would it be enough to populate those parameters without actually triggering/firing those events? What do you have in mind?

[emilianorios1]

session_start and first_visit are events received by GA4 which populate the reports regarding a users first traffic channel or the landing page path in a session.

Every time a user triggers the first page view of a session a session_start will be sent which is triggered by having the ss="1". If that session happened to be the first then fv="1" will also be set.

Regarding your examples I'll answer:

Example 1:

• ss = 1
• fv = 1

Example 2:

• ss and fv will not be sent nor be in the parameters

Example 3:

• ss=1
• fv will not be sent nor be in the parameters

Regarding when client_id is set: Basically when a user clears the cookis or it expires, although I'm not sure if it expires like your cookie.

session_start and first_visit can only be triggered by populating these parameters in a page_view.

Me and my team we tried to find a way but weren't able to find a way to confirm if a page_view is a first_visist.

Also, something else we found was that events should have a c=1in x-ga-system_properties to actually trigger a conversion, which was also bugging us as to why they were not triggered.

Nonetheless, this leds me to think if this is really an issue in your client or if this is an issue in the GA4 Tag, because we were sold on GTM Server Side on the ability to use any Client to populate GA4 data but this has not been really possible because of all these limitations imposed by Google.

Anyways, sorry I wrote this in a rush let me know if you found this helpful or any other doubts and sorry for grammar errors.

Regards

[adatzer]

Hey @emilianorios1 ! Since resolving this issue is quite open-ended, it may be better to be handled either through GTM-SS transformations or through the new merging features we just added to the (just released) v0.6.0. Closing this for now, please feel free to reopen if needed!