Analytics and consent

The widget reports what customers do (viewing products, starting a booking, paying) as events in your page's dataLayer, in Google Analytics 4 e-commerce format. Your own Google Tag Manager container picks them up and sends them on. The widget itself loads no analytics or tracking scripts.

Events need window.dataLayer

The widget pushes events only if the host page defines window.dataLayer. Without it, no events are pushed. The widget never creates dataLayer itself.

• Tag Manager snippets create window.dataLayer, so events flow as soon as your container is on the page.
• WordPress plugin: events flow if your site has a Tag Manager container or another script that defines dataLayer.
• Astro package: the integration's boot script always creates window.dataLayer before the widget loads. Events are therefore always pushed; they reach an analytics tool only if you add one.
• Plain JavaScript: define window.dataLayer = window.dataLayer || []; before the widget script, or load your Tag Manager container first.

What happens with the events after that — which tags fire, and whether consent allows them — is decided by your Tag Manager setup.

Events

GA4 e-commerce events

Each of these is pushed as two entries: { ecommerce: null } to clear the previous values, then { event, ecommerce: {...} }. Prices are in major currency units (euros, not cents), and currency is an upper-case code such as EUR.

Event	When it is pushed
view_item_list	A product grid, the product step of the location-first flow, a course grid or a course's term list is shown; the checkout offers step is shown (list checkout_offers).
select_item	The customer picks a product from a grid, the location-first flow or a course list.
view_item	The booking flow opens for a product, or a single course is shown.
add_to_cart	The customer's time is reserved (a hold is created), or the customer accepts a checkout offer.
begin_checkout	The customer reaches the payment step.
add_payment_info	The customer chooses a payment method. payment_type is Card, Paytrail or Pay on arrival.
purchase	The booking is confirmed. transaction_id is the booking ID, and coupon is the discount code the customer entered, if any. A paid campaign door sale is also a purchase (see Campaign events).

List IDs used in item_list_id: product_grid (product grid), booking_products (location-first flow, or your data-item-list-id), course_catalog (course grid), course_cohorts_<productId> (one course product's terms) and checkout_offers.

begin_checkout and purchase are pushed at most once per booking per page load, even if the customer goes back and forth between steps.

Diagnostic events

These are not e-commerce events, so their parameters sit directly on the dataLayer entry.

Event	When it is pushed	Parameters
widget_loaded	The single-product booking flow loads. Once per product per page.	widget_id, widget_version, page_path, load_time_ms
availability_check	The availability calendar (sessiq-calendar-widget) loads availability.	requested_date_range_start, requested_date_range_end, available_count, time_to_response_ms

Sessiq events

These run alongside the GA4 events, for sites that built tags on them earlier.

Event	When it is pushed	Parameters
sessiq_slot_selected	The customer picks a time.	product_id, product_name, slot_date, slot_time (formatted in the browser's locale), party_size
sessiq_booking_started	A hold is created.	booking_id, product_id, product_name, value, currency
sessiq_booking_confirmed	The booking is confirmed.	booking_id, product_id, product_name, value, currency, payment_method
sessiq_course_enrollment_started	A course enrolment hold is created.	booking_id, course_id, product_id, product_name, value, currency
sessiq_course_enrollment_confirmed	A course enrolment is confirmed.	booking_id, course_id, product_id, product_name, value, currency, payment_method

Campaign events

The campaign calendar (sessiq-campaign) pushes these with their parameters directly on the dataLayer entry. They are pushed only when analytics consent is granted (or no consent signal is found, as for the other events). They describe the calendar funnel; don't count them as conversions.

All of them carry campaign_id, campaign_slug and day_index.

Event	When it is pushed	Other parameters
select_promotion	The customer opens a door.	promotion_name, item_id (the door's product, when it has one)
campaign_claim	A code is claimed.	reward_type, already_claimed, item_id, marketing_opt_in (true/false, never the email)
campaign_purchase_start	The customer starts paying for a prepaid voucher or gift card door.	door_mode (prepaid or gift_card), value, currency, item_id
campaign_purchase_complete	The door purchase is paid. Once per purchase, also after a redirect payment.	door_mode, value, currency, item_id
campaign_book_now	The customer clicks Book now.	item_id (the product), target_site_origin (the site the link goes to)

Door sales are purchases

When a prepaid voucher, gift card or pass bought from a door is paid, the calendar also pushes a GA4 purchase, once, right after campaign_purchase_complete:

• ecommerce.transaction_id is the purchase ID, value what the buyer paid (a gift card door's bonus isn't included) and one item whose item_category is prepaid_voucher, gift_card or visit_pass.
• Next to ecommerce it carries purchase_type: "campaign_door", campaign_id, campaign_slug and day_index. Booking purchases have no purchase_type.

Sessiq also sends the same purchase from its server, with the same transaction_id, so GA4 counts it once. Refunding a door purchase sends a refund. To report door sales separately from bookings, use purchase_type (register it as an event-scoped custom dimension) or item_category.

Venue parameters

Most e-commerce events, and the sessiq_booking_* and sessiq_course_enrollment_* events, also carry the venue next to event (outside the ecommerce object):

• location_id — the Sessiq site ID
• venue — the site name
• city — the site's city, when set

Use them in Tag Manager to report per location.

No personal data in events

Events never carry the customer's name, email address or phone number.

• GA4 events are checked against a fixed schema before they are pushed. An event that fails the check is dropped and an error is logged in the browser console. The booking itself continues normally.
• Sessiq events are checked for keys that look like personal data: any key containing email or phone, and the keys name, first_name, last_name, full_name, fullname, given_name, family_name and customer_name. Such keys are removed before the event is pushed, and an error is logged. Keys like product_name are allowed.

Consent Mode v2

The widget does not show a consent banner and does not hold back events by itself. Use a consent management platform (CMP) that supports Google Consent Mode v2, and let Tag Manager decide which tags may fire.

When the customer's time is reserved, the widget reads the consent state your CMP has written to dataLayer (the consent default and update commands) and sends it to Sessiq with the booking. Later updates override earlier ones.

Consent Mode signal	Stored on the booking as
analytics_storage	analytics
ad_user_data	marketing
functionality_storage	functional
personalization_storage	preferences

A category counts as given only when its signal is exactly granted. If the page has no consent commands at all, no consent state is sent, and the booking records consent as unknown rather than refused.

Google Analytics cookies

When the customer's time is reserved, the widget also reads two Google Analytics cookies from your page and sends their IDs with the booking:

• _ga → the GA client ID
• _ga_<measurement ID> → the GA session ID

If a cookie is missing or has an unexpected format, the value is sent as empty; the widget never makes one up. Sessiq uses these IDs, together with the stored consent, to link its own server-side measurement of the purchase to the customer's browser session.

These cookies exist only if Google Analytics runs on your page and the customer's consent allows it.