Skip to main content
When an ad brings a guest to you, their URL carries UTM parameters saying where they came from. Restoo stores them on the booking and includes them on every widget event, so you can measure which campaigns bring you bookings. Where it reads them from depends on where your guests book.

Hosted on Restoo

Your guests book on the page Restoo hosts for you. The parameters travel in the link itself and the widget reads them from its own address.

Embedded in your site

The booking form appears inside your own website. Restoo.js reads the parameters from your page’s address and hands them to the widget.
Restoo reads these five parameters:
  • utm_source
  • utm_medium
  • utm_campaign
  • utm_term
  • utm_content
To build the links without slips, use Google’s Campaign URL Builder: fill in the fields and it gives you back the URL with the parameters already in place.

Hosted on Restoo

Put the campaign’s UTM parameters in the link:
The widget is the page, so it reads its own address as soon as it loads. Nothing to install and nothing to declare. That holds for a campaign whose link points straight at your Restoo page. It does not hold for one that lands on your own website first. A visitor who arrives at your homepage from an ad and then clicks through to your Restoo page leaves the campaign behind on your site, and the widget finds nothing in its own address to read. Restoo Attribution Transfer is what closes that gap. Installed on your own pages, it writes the campaign — and the ad platforms’ click identifiers — into the link as the visitor follows it, so the booking is credited all the same, in Restoo and in the platform that brought the click.

Embedded in your site

Restoo.js reads the UTM parameters from your page’s address and hands them to the widget as it starts. A guest who arrives from an ad on the page that holds the widget is attributed without you doing anything. What is not solved on its own is keeping the campaign from one page to the next: if the visitor lands on your homepage and browses from there to your reservations page, there is nothing left in the address bar to read. That is what Restoo Attribution Transfer is for.

Attribution model

In both cases the last campaign that brought the visitor is the one kept — last-touch attribution, in marketing terms. A new URL containing at least one of the five parameters replaces the complete set stored before. Stored values expire 30 days after they are captured, and capturing a new set starts a new 30-day period.

Default attribution

A booking that reaches Restoo with no attribution is not stored blank. As it is created, Restoo fills the two main fields with defaults, so every booking has a channel: utmCampaign, utmTerm and utmContent stay empty. Both values are recorded in the language of the country your business is registered in, so a business in Spain sees Directa and one in Italy Diretta. Two details worth knowing:
  • The defaults fill in field by field. A booking that carries utm_source but no utm_medium still gets Online as its medium — it is not all or nothing.
  • They are written by Restoo when it stores the booking, and only when the booking is created, not when it is later modified. The acquisition object on the events is not affected: it still reports null for whatever was not captured.
Reading the parameters from a URL needs no consent of any kind. Storing them in the visitor’s browser does: keeping attribution is a marketing purpose rather than a technical necessity, so it needs their permission for advertising storage — ad_storage in Google Consent Mode terms. It is the same in both cases: What is read from the address stays in memory, is stored with the booking, and is included in that visit’s events, so there is nothing to ask about. What needs permission is the memory: keeping the campaign from one page to the next, and recovering it if the visitor comes back later. You report that decision to Restoo the same way as for everything else. A visitor who accepts after the widget has loaded still recovers whatever was stored: those values reach the widget as soon as the answer is known.

Attribution on the customer record

Attribution does not stop at the booking. When a booking also creates the customer record — the first one they make with you — that same attribution is stored on their record. It is the attribution of the first contact and it is never rewritten. If that same guest books again later from a different campaign, the new booking carries the new attribution, but their record still shows the campaign that brought them the first time. They are two different questions, which is why they are stored separately: which campaign brings each booking, and which campaign won you each customer.

Event attribution

The captured values are included in the acquisition object on every widget event:
Each field is null when its corresponding UTM parameter was not captured.

Fixing the attribution of one installation

Some pages are the channel, and there the visitor’s URL should decide nothing: the usual case is a partner booking portal that embeds the widget. An installation can declare its own fixed attribution, and that takes precedence over everything on this page — see Forced attribution. It is an option of having it embedded in your site. Hosted on Restoo the configuration comes from your account, and no fixed attribution is declared there.

Next steps

Restoo Attribution Transfer

Install the script that preserves attribution across the pages of your site.

Consent

What ad_storage unlocks and how you report the visitor’s decision.