Connecting analytics

The analytics tab in Connected accounts is where you add your tracking, so you can measure how customers move through your booking journey and see what your advertising is actually producing.

Open your Profile at the bottom left, go to Settings, then Connected accounts, then the analytics tab.

Where your tracking runs

All three integrations run on your customer facing pages only. Your home page, your forms, your client portal, your contracts and your checkout.

Nothing tracks your own admin area. What you are measuring is customer behaviour, so the data you get back is about the people booking you rather than about your team using the system.

Google Tag Manager

Enter your GTM container ID and the container is initialised on your customer facing pages using a standard gtag.js snippet.

You do not need to add any code yourself. Once the ID is saved, the snippet is placed for you and your container is live.

Events pushed to the dataLayer

At key moments in the booking journey we push events for your container to pick up. You then wire those events to your own conversion actions inside GTM.

conversion

• Fires on successful payment at checkout

• Parameters: value (the payment amount), currency (your business currency code), transaction_id (the quote ID)

• This is the generic event, sent through gtag where it is available and pushed to the dataLayer where it is not

bb_payment

• Fires on successful payment at checkout

• Parameters: value, currency, transaction_id

bb_contract_signed

• Fires when a customer signs a contract

• Parameters: booking_id

bb_form_submitted

• Fires when a booking form is submitted

• Parameters: form_id, quote_total, currency

The values come from the real booking rather than being hardcoded, so the figures reaching your reporting match what the customer actually paid, in the currency they paid it in.

Events are deduplicated by key, so a retry or a page re-render will not fire the same event twice.

Payment fires two events

A successful payment fires both conversion and bb_payment.

Wire your Google Ads conversion action to one of them, not both. Setting up both is the quickest way to end up reporting twice the sales you actually made and optimising your campaigns against a number that is out by 100 percent.

Use bb_payment if you want the prefixed event set to be consistent across your triggers. Use conversion if you already have a container built around it.

Using the events

Inside GTM, create a trigger for each event you care about and wire it to the Google Ads conversion action you want it to fire.

Payment is the one to set up first. It carries the value and the transaction ID, which is what Google Ads needs in order to report return on ad spend rather than just conversion counts.

Use GTM's preview mode to confirm the events are arriving with the right values before you rely on the numbers.

Hotjar

Enter your Hotjar ID and Hotjar runs on your customer facing pages.

You get heat maps showing where customers click, how far they scroll and where they stall on the way through your booking journey.

This is the one that tends to change how people build their forms. Watching where customers actually stop is more useful than any amount of guessing about which field is putting them off, and the fix is usually deleting something rather than adding something.

Meta Pixel

Enter your Pixel ID from Meta Business and the pixel runs on your customer facing pages, so you can track and optimise your Facebook and Instagram advertising.

The pixel only loads once you have saved an ID. No ID means nothing is added to your pages.

Events sent to your pixel

These four are sent directly to your own connected Pixel ID, so they appear on your pixel and nowhere else.

AddToCart

• Fires when a customer adds a product or package to their booking basket

• Parameters: value, currency

InitiateCheckout

• Fires when a customer starts checkout

• Parameters: value, currency

AddPaymentInfo

• Fires when a customer submits their payment method, across all supported payment gateways

• Parameters: none

Purchase

• Fires on payment success at checkout

• Parameters: value, currency

Values and currency come from the actual booking, in the currency of your account, so your Meta reporting matches what your customers really spent.

Purchase is the event to optimise campaigns against, since it is the only one tied to money actually taken.

Event deduplication

Every Meta event carries an event ID so Meta can drop duplicates if the same event reaches it more than once.

The IDs are built from the record the event relates to, so a purchase uses the quote ID, a trial uses the user ID, and so on. You do not need to configure anything for this, but it is worth knowing the IDs exist if you ever add the Conversions API alongside the pixel, since that is what stops browser and server events being counted twice.

Set these up before you advertise

Tracking added later cannot tell you what happened before you added it.

If you are planning to advertise, get the tracking in first and let it run for a couple of weeks. Starting a campaign and then adding tracking means your first fortnight of spend produces numbers you can never go back and check.

Consent and privacy

You are responsible for the tracking you add and for whatever consent your customers need to give for it, which depends on where you and they are based.

If you operate anywhere with cookie consent requirements, your consent setup needs to account for the tracking you have enabled here. Worth a conversation with whoever handles that for you rather than an assumption.

If your events are not showing

Check the ID first. A container or pixel ID pasted with a stray space, or an ID from the wrong account, is the most common cause and the quickest to rule out.

Then check you are testing on a customer facing page. Events do not fire in your admin area, so walking through the system as yourself will not produce any.

Then use the platform's own preview tools, GTM preview mode or Meta Events Manager, since they show you whether the event arrived and what it contained. That distinguishes an event that is not firing from an event that is firing with the wrong values, which are different problems with different fixes.