Skip to main content
The widget, Restoo Connect, and Restoo Attribution Transfer all read consent from one place, Google Consent Mode v2 signals, and all apply the same rule: nothing is stored, forwarded, or matched until the visitor’s decision is known. It depends on what you have installed on your own site: the widget, Restoo Attribution Transfer, or neither. 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 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. 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. 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:

Declare your consent platform

You use Cookiebot or a platform with Consent Mode v2: you declare which one and Restoo reads the decision, and its changes.

Call setConsent()

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.
Pass the 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: If your platform fits neither, use setConsent() instead.

​
Call setConsent() directly

Call 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.
​
object
One or more consent signals. Each value must be exactly "granted" or "denied".
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 on your own page: they are yours, and the consent for whatever you do with them is yours to apply.

​
What each signal unlocks

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

​
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. It is required whenever ga4 is enabled. 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 for their matching, and every other destination uses E.164. The two hashes will not match each other — that is expected, not a bug. See 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

Restoo Connect

What each analytics and advertising destination requires beyond consent.

Campaign attribution

Which attribution depends on ad_storage in each of the two versions.