Full list of events bookingkit tracks

Who this is for: this is a technical reference sheet, mainly useful for a developer or agency setting up custom tracking. If you just followed the Easy path, you don’t need to read this — your setup already works. Come back here later if you (or your developer) want to build custom reports.

Every time a visitor does something meaningful in the booking process — views a ticket, adds it to their basket, enters payment info, completes a purchase — bookingkit quietly sends a little note to your website saying “this just happened, here are the details.” Google calls each of these notes an event. This page lists every event bookingkit sends, and exactly what details (“parameters”) come with each one.

When it fires: every time a visitor moves to a new screen — a widget page or a checkout step.

Widget screens (page_title values):

Checkout screens (page_title values):

When it fires: each time a ticket is selected or removed from the basket.

When it fires: when payment details are entered at checkout.

When it fires: the moment the confirmation/success page loads.

The newer floating widget (see Setting up your Revenue Boosting Webshop) sends events to the same window.dataLayer, but with its own naming convention — worth knowing if you’re building a trigger for it specifically.

Confirmed live on a production widget (July 2026):

The rest of the booking flow (add_to_cart, add_payment_info, purchase) runs through the same checkout as the standard widget, so those events and parameters match the tables above.

A note on the developer docs: bookingkit’s widget documentation describes an optional data-tracking="true" attribute for enabling tracking on this widget. In practice, tracking was already active on a live production site without that attribute set — so don’t worry if it’s missing from an embed snippet. There’s no extra setup step required on the vendor’s side.

This isn’t just a dataLayer-level check. Clicking through the floating widget on a connected test property and watching GA4’s Realtime report showed the full chain working end to end — bk_page_view, page_view, click, and view_item all appeared within moments of the click, with no extra GTM configuration beyond what’s already described in this article. The bk_page_view name is the same rename convention covered in the Google Tag Manager section below (see the naming tip), applied automatically to the floating widget’s events too.

If you’re using Google Tag Manager (see Using Google Tag Manager instead), Tag Manager doesn’t automatically know about these events — you need to add each one manually:

1. Create a trigger: Tag Manager → Triggers → New → trigger type Custom Event → event name = the exact event name (e.g. purchase).

2. Create a tag: Tag Manager → Tags → New → tag type Google Analytics: GA4 Event → set the Measurement ID to your Google Tag’s ID (or let it auto-detect, like in the screenshot below) → Event Name = same name → add any parameters you want to send through, each mapped to a matching Data Layer Variable (Tag Manager → Variables → New → Data Layer Variable, e.g. DLV - value, DLV - item_id) → set the Trigger to the one you created in step 1.

3. Click Submit, then Publish. Nothing goes live until you publish.

GTM Custom Event trigger configuration, named “bookingkit page_view” and listening for the page_view data layer event

GA4 Event tag configuration for page_view

Same tag, scrolled down to show parameters mapped to Data Layer Variables and the firing trigger

Naming tip: in the screenshots above, the outgoing GA4 event was renamed to bk_page_view instead of page_view. That’s because GA4 already automatically collects its own page_view event for standard page loads — sending bookingkit’s page_view through under the same name can cause double-counting. The trigger still listens for bookingkit’s real event name (page_view), but the tag sends it to GA4 under a distinct name. You don’t have to do this — it’s just a way to avoid confusing the two if you notice inflated page view numbers.

Some event names may need to be added manually so they show up when building reports:

1. In Google Analytics, click the gear icon (Admin) → Events.

2. Click Create event if a name you’re expecting isn’t listed once it’s started sending data.

GA4 Admin → Events screen

The event names on your screen will reflect your own account’s setup — this sandbox shows a mix of example events, not the bookingkit-specific ones. What matters is knowing where this screen lives: Admin → Events.

Use Tag Manager’s Preview mode (see Using Google Tag Manager instead) or Google Analytics’ DebugView while clicking through the booking widget live — each event should appear within a few seconds, along with its details.

The trigger for the order confirmation page won’t fire because the URL isn’t unique — why?

Don’t mix the two conversion-tracking options Google Ads offers: a URL-based trigger, and a GTM/event-based one. Since the confirmation page lives on bookingkit’s domain rather than yours, URL-based tracking won’t reliably match it. Use the purchase event from the bookingkit widget instead (see above), then send that conversion on to Google Ads through GTM.

What does “no payment options available” mean in an event’s data?

That value comes from bookingkit’s Express Checkout module, which checks whether it can offer PayPal Express or Apple Pay to a given visitor. If neither is available for that visitor’s device/browser — or if you as the vendor haven’t activated PayPal — it reports “no payment options available.” This is expected behavior, not an error, and it’s more likely to show up if PayPal isn’t turned on.

→ Frequently asked questions — cross-domain checkout can miscount some of these events; here’s the fix.