> ## Documentation Index
> Fetch the complete documentation index at: https://restoo.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Campaign attribution

> How every booking is credited to the campaign that brought the guest, with the widget hosted on Restoo or embedded in your site.

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**.

<CardGroup cols={2}>
  <Card title="Hosted on Restoo" icon="link" href="#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.
  </Card>

  <Card title="Embedded in your site" icon="code" href="#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.
  </Card>
</CardGroup>

Restoo reads these five parameters:

* `utm_source`
* `utm_medium`
* `utm_campaign`
* `utm_term`
* `utm_content`

<Tip>
  To build the links without slips, use [Google's Campaign URL
  Builder](https://ga-dev-tools.google/campaign-url-builder/): fill in the fields
  and it gives you back the URL with the parameters already in place.
</Tip>

## Hosted on Restoo

Put the campaign's UTM parameters in the link:

```
https://best-burger.myrestoo.net/?utm_source=instagram&utm_medium=social&utm_campaign=summer
```

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](/widget/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](/widget/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.

| What the visit carries | What is stored              | Attribution used by the widget                  |
| ---------------------- | --------------------------- | ----------------------------------------------- |
| UTM parameters         | Any value                   | The parameters from this visit                  |
| No UTM parameters      | Valid stored values         | The stored values                               |
| No UTM parameters      | No values or expired values | [The default attribution](#default-attribution) |

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:

| Field       | Value    |
| ----------- | -------- |
| `utmSource` | `Direct` |
| `utmMedium` | `Online` |

`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](#event-attribution) is not affected: it still reports `null` for whatever was not captured.

## Consent

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](https://support.google.com/tagmanager/answer/10718549) terms.

It is the same in both cases:

| Operation                                             | Needs consent |
| ----------------------------------------------------- | ------------- |
| Attributing the current visit from the URL parameters | No            |
| Remembering the campaign for 30 days                  | Yes           |
| Reading back what an earlier visit stored             | Yes           |

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](/widget/consent).

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](/widget/events#fields-common-to-every-event):

```js theme={null}
{
  acquisition: {
    utm_source: "google",
    utm_medium: "cpc",
    utm_campaign: "summer",
    utm_content: null,
    utm_term: null
  }
}
```

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](/widget/advanced-installation#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

<CardGroup cols={2}>
  <Card title="Restoo Attribution Transfer" icon="link" href="/widget/attribution-transfer">
    Install the script that preserves attribution across the pages of your site.
  </Card>

  <Card title="Consent" icon="shield-check" href="/widget/consent">
    What `ad_storage` unlocks and how you report the visitor's decision.
  </Card>
</CardGroup>