All Collections
Analytics & Tracking
Google Analytics 4
Google Analytics 4: Events Deep Dive
Google Analytics 4: Events Deep Dive
Heyflow avatar
Written by Heyflow
Updated over a week ago

Tracking Version 1.0

This guide is only applicable to Tracking Version 1.0 and above. Make sure your heyflow is using Version 1.0 in your heyflow settings under Tracking:

Triggers and Event Names

By default (if you don't use your own Google Tag Manager), Google Analytics 4 (GA4) events are closely related to the Heyflow Events API and the DataLayer. Check out the respective guides to gain more in-depth knowledge.

Based on your heyflow's lifecycle, events are emitted and passed to Google Analytics 4:

GA4 Event Name










{{Custom Event Name*}}


{{Custom Event Name*}}

The Custom Event Name that is passed as the Event Name to GA4 when an input or button is clicked (heyflow-input-click, heyflow-button-click), is set in your heyflow:

If that's not available, the following applies: for heyflow-input-click, the Custom Event Name fallback is the sanitized* System Label, Label, or block ID. For heyflow-button-click, the Custom Event name fallback is the block ID.

*) sanitized here means that it's cleaned of special characters and whitespaces, e.g. My System [email protected] β†’ My_System_l_b_l. That's done for better compatibility with GA4 and other tools you might want to use.

Default Properties

By default, IP addresses are anonymized (anonymize_ip: true).

For all events, we define page_location, page_title, and page_referrer.

If you would like to change the schema, you can set up and link your own GTM container with custom properties. We supply a base configuration for you to start from.


For heyflow_start, the referrer is the HTTP referrer, e.g. For other events, including page_view, the referrer is the constructed URL of the last screen (explained below).


The page_title is the name of the screen.


Importantly, we re-construct the page_location – it is not the actual URL. That is beneficial because your heyflow is a so-called Single-Page Application for which page_view and their location are not ideally tracked automatically.

The page_location schema is the following:

{{Origin}}{{Page Path}}/{{Screen Name}}{{Search Query}}.

Origin is the first part of the URL, e.g. Page Path is only relevant when you have connected your own domain or when you have embedded your heyflow: for, the Page Path is /some/sub/page. Then, after a /, the screen name follows, e.g. start (the word behind the # in the URL, usually). You can define the screen names in your heyflow yourself. The Search Query is whatever follows the URL with a question mark, e.g. in Sometimes, it's also called Query String. That Search Query may contain URL parameters, e.g. utm_campaign or gclid.

A few examples for the page_location reconstruction:

Original URL


Did this answer your question?