Google Tag Manager

Install call tracking in your container, review it, and publish it when you want.

Google Tag Manager is the middleman that decides which scripts run on your site and with what data. This is where the piece that carries the call identifier into your booking event gets installed.

Why it’s needed if you already have Analytics

The call identifier travels in the address of the link your assistant sends, but only on the first page. Your guest browses, picks, pays, and the booking is confirmed several pages later, by which point the data is no longer in the address.

What gets installed solves exactly that: it picks the identifier up on arrival, keeps it for the length of the visit, and attaches it to your booking event when it happens.

What gets installed

Five changes in your container. Three are new items and one is a line added to something you already have:


New · three variables	Read the identifier from the address or from the cookie.
New · one tag	Stores the identifier in a cookie as soon as it appears, so it survives to the confirmation page.
Modified · your booking tag	One parameter is added. Everything it already carried stays untouched: booking number, amount, currency, items, attribution.

What is not touched: anything else. Your Google Ads conversions, your social pixels, your session recording or chat tools and the rest of the container stay exactly as they are. The only change to something existing is that added parameter.

About the cookie: it belongs to your own domain, lasts 30 days and holds nothing but a technical identifier for the call. No personal data — no name, no phone, no email.

How it’s done

In the client portal, go to Integrations → Google Tag Manager.

1. Connect. Same as Analytics: sign in with your Google account, authorise, and pick your container from your own. Save.

2. Choose the events. The Events card is where you tick which events should carry the identifier. The confirmed booking one is usually enough. If you tick an event that no tag in your container sends, we’ll tell you: that one cannot carry the identifier, because it is sent from somewhere else.

3. Install. The Installation card writes the five changes. By default it does so in a workspace of its own called Bookline tracking, separate from where your team or agency works, so the changes are reviewed on their own and don’t go live mixed with someone else’s.

At this point your site behaves exactly as before. Tag Manager keeps the changes as a draft.

4. Review in Preview. Recommended before publishing: in Tag Manager, with the Bookline tracking workspace selected, open Preview, make a test booking and check that the booking event carries the bookline_session_id parameter. Especially advisable if you use a server-side container.

5. Publish. This is the step that takes the changes live. You can do it from the Publish button in the portal or from Tag Manager itself. From then on, bookings start arriving with the identifier.

If something doesn’t add up, rolling back means restoring the previous version from Tag Manager’s version history. None of this is one-way.

Permissions

This is where most people get stuck, because there are two separate levels.

When you connect, you authorise Bookline to work with your containers. On top of that sits what your own user is allowed to do in that container, which is set in Tag Manager and has four levels: Read, Edit, Approve and Publish.

With Edit, the changes can be installed in the workspace. Installation works.
Publish is a separate permission. Without it, the publish button will fail even though the install went fine.

If that happens, there are two ways out: whoever administers the container raises you to publish permission, or they publish the Bookline tracking workspace themselves — it is already prepared and reviewable change by change.