> ## 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.
# Consent
> How Restoo reads the visitor's consent, and what each Google Consent Mode v2 signal unlocks.
The widget, [Restoo Connect](/widget/connect), and [Restoo Attribution Transfer](/widget/attribution-transfer) all read consent from one place, [Google Consent Mode v2](https://support.google.com/tagmanager/answer/10718549) signals, and all apply the same rule: **nothing is stored, forwarded, or matched until the visitor's decision is known.**
## Who collects consent
It depends on what you have installed on your own site: the widget, [Restoo Attribution Transfer](/widget/attribution-transfer), or neither.
| | Who asks the visitor | Your job |
| ---------------------------------------------------------------------------------- | -------------------- | ------------------------------- |
| **Hosted on Restoo** — your guests book on the page Restoo hosts for you | Restoo | Nothing |
| **Embedded in your site** — the booking form appears inside your own site | You | Pass the decision to the widget |
| **Restoo Attribution Transfer** — runs on your own site, hosted on Restoo included | You | Pass the decision to the script |
Hosted on Restoo the widget *is* the page: Restoo puts up the cookie notice, and applies that decision to everything it sends. Embedded in your site the booking form is on your domain, so the asking is yours.
[Restoo Attribution Transfer](/widget/attribution-transfer#what-needs-consent) is separate, because it runs on your website and not in the widget: there the asking is yours **even when your guests book on the page Restoo hosts for you**.
## What a consent management platform is
A consent management platform (CMP for short) is the software that shows the cookie notice on your site, stores what each visitor answers, and passes that decision to the tools that need it. In technical documentation you will almost always see the acronym, CMP.
**If your site already shows a cookie notice, you already have one.** It can be a dedicated tool — Cookiebot, OneTrust, Didomi, and iubenda are among the most widespread — a WordPress plugin such as Complianz or Borlabs, or the notice that already comes with Wix, Squarespace, or Shopify. If you don't know which one you use, whoever runs your site will.
Embedded in your site, Restoo does not replace yours: it only reads its decision, and for that it needs you to say which one it is.
## How consent reaches Restoo
**When the asking is yours**, Restoo needs you to pass the visitor's decision along. There are two ways, depending on how your site already collects it:
You use Cookiebot or a platform with Consent Mode v2: you declare which one
and Restoo reads the decision, and its changes.
Your cookie notice is your own, or your platform is not supported: you call
it every time the visitor accepts, rejects, or changes their mind.
### Declare your consent platform
Pass the [`cmp`](/widget/advanced-installation#param-cmp) parameter to `.create()`, the call that configures the widget, and Restoo will take the visitor's decision, and any later changes, from that platform. It can read from two places:
| Value | Reads from |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| `COOKIEBOT` | The `Cookiebot` object on the page. Its categories translate into Consent Mode signals the same way they do in Cookiebot's own Google integration. |
| `GOOGLE_CONSENT_MODE` | The `gtag("consent", "update", …)` calls in `window.dataLayer`. Works with any platform that pushes Consent Mode v2, which is most of them. |
If your platform fits neither, use [`setConsent()`](#call-setconsent-directly) instead.
### Call `setConsent()` directly
Call [`setConsent(signals)`](/widget/advanced-installation#setconsent-signals) from your own cookie notice whenever the visitor accepts, rejects, or changes their decision. If you declared your consent platform, Restoo already reads it and you do not need to call this.
One or more consent signals. Each value must be exactly `"granted"` or
`"denied"`.
Storage for advertising purposes.
Sending user data to advertising platforms.
Personalized advertising, such as remarketing audiences.
Storage for analytics purposes.
Storage that supports site functionality, such as language preferences.
Storage for personalization, such as recommendations.
Storage related to security, such as authentication and fraud prevention.
Signals accumulate across calls, so you can inform them one at a time or all at once. They also apply to the whole page, so one call reaches every widget — including one that mounts **later**, such as an overlay that opens on click.
## What "unknown" means
Anything you have not informed stays **unknown**, and unknown grants nothing: a signal counts as permission only when it is explicitly `"granted"`.
Until the visitor's decision is known, Restoo Connect sends to no destination, Restoo Attribution Transfer keeps no campaign tags or click IDs, and the widget broadcasts no customer identity. And what happens before that moment is **discarded, not queued**: delivering it later would mean acting on data gathered without permission.
What does always arrive are the [widget events](/widget/events) on your own page: they are yours, and the consent for whatever you do with them is yours to apply.
## What each signal unlocks
| Signal | Unlocks |
| -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `analytics_storage` | Measurement — see [what each destination requires](#what-each-destination-requires) |
| `ad_storage` | Advertising storage, and [remembering campaign attribution](/widget/attribution#consent) across pages and visits |
| `ad_user_data`, `ad_personalization` | Sending the visitor's identity to your ad platforms — see [Customer identity](#customer-identity) |
| `functionality_storage`, `personalization_storage` | [Recognizing a returning guest](#remembering-a-returning-guest) |
| `security_storage` | The payment gateway's storage — authenticating the transaction and preventing fraud — and other security storage |
### Remembering a returning guest
With both `functionality_storage` and `personalization_storage` granted, the widget remembers the guest, and their details are already there on their next visit. Report either as `"denied"` and **what was stored is deleted** — withdrawing is as easy as granting. While the answer is still unknown the widget neither stores nor deletes anything, and booking works the same either way.
## What each destination requires
Each destination is **decided separately**: in the same event one can receive it while another does not. What it requires depends on what it **can do** with the event, not on how you have configured it.
| Destination | Signals required |
| ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- |
| `googleAds`, `metaPixel`, `tiktokPixel`, `openaiPixel` | All three advertising ones: `ad_storage`, `ad_user_data`, and `ad_personalization` |
| `ga4` | `analytics_storage`, except [with a property that feeds advertising](#ga4-with-a-property-that-feeds-advertising) |
| `gtm` | None in particular, but consent must have been informed: [your tags apply their own](#gtm-and-the-consent-your-tags-apply) |
### `ga4` with a property that feeds advertising
`ga4` counts as analytics **only while your GA4 property is analytics only**. If it also feeds advertising, the events Restoo sends it feed advertising personalization and `analytics_storage` alone is no longer the right permission: it then requires the three advertising signals **as well**, added to the analytics one rather than replacing it, because the property still writes its `_ga` cookie.
Restoo cannot see your property's configuration, so [it is declared in your account](/widget/integrations#google-analytics-4). It is required whenever `ga4` is enabled.
### `gtm` and the consent your tags apply
`gtm` requires no specific signal because the tags in your container bring their own. Restoo pushes the event as soon as consent has been informed, **even if every signal is denied**. From there on your GTM's Consent Mode governs, and configuring it correctly is your job.
## Customer identity
The visitor's email and phone are turned into a **SHA-256 hash** before they leave the browser, so they never travel in the clear and a destination can only match them against the ones it already holds for that customer.
That is **pseudonymization, not anonymization**: the data is still personal. Disclosing it requires `ad_user_data` and `ad_personalization` on top of whatever a destination already asks for.
For the four advertising destinations that adds nothing, since they already require both signals for every event. Where it does ask for more is `gtm` — which otherwise only asks that consent be informed — and a `ga4` declared as analytics only, which only asks for `analytics_storage`.
The phone number is hashed **twice, in two different formats**: Meta and the OpenAI Pixel require [MSISDN](https://en.wikipedia.org/wiki/MSISDN) for their matching, and every other destination uses [E.164](https://en.wikipedia.org/wiki/E.164). The two hashes will not match each other — that is expected, not a bug. See [CustomerIdentified](/widget/events#customeridentified) for the exact payload.
**Revoking a signal that was previously granted retracts the identity, not just future events.** Whatever was already disclosed to a destination — Meta's Advanced Matching, Google's Enhanced Conversions, TikTok's `ttq.identify()`, the OpenAI Pixel's `user` — is removed from it as soon as the permission is gone, rather than being left to expire on its own.
The removal is the only unconditional part. The `customer_signed_out` **event** itself still follows the same consent rule as any other event towards GA4 and GTM.
The OpenAI Pixel ships with its automatic advanced matching enabled: besides
what Restoo Connect sends it, the SDK itself detects contact details in the
forms of the page it is installed on, hashes them in the browser and attaches
them to its events. That is a feature of the pixel, not of Restoo, and it sits
under the same advertising permission the pixel loads with.
## Next steps
What each analytics and advertising destination requires beyond consent.
Which attribution depends on `ad_storage` in each of the two versions.