> ## 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. # Consentimiento > Cómo lee Restoo el consentimiento del visitante y qué desbloquea cada señal del Consent Mode v2 de Google. El widget, [Restoo Connect](/es/widget/connect) y [Restoo Attribution Transfer](/es/widget/attribution-transfer) leen el consentimiento de un solo sitio, las señales del [Consent Mode v2 de Google](https://support.google.com/tagmanager/answer/10718549), y aplican todos la misma regla: **hasta conocer la decisión del visitante no se almacena nada, no sale nada hacia ninguna plataforma y no se cruza ningún dato del cliente.** ## Quién recoge el consentimiento Depende de qué tengas instalado en tu propia web: el widget, [Restoo Attribution Transfer](/es/widget/attribution-transfer), o ninguno de los dos. | | Quién pregunta al visitante | Qué te toca a ti | | --------------------------------------------------------------------------------- | --------------------------- | ----------------------------- | | **Alojado en Restoo** — tus clientes reservan en la página que Restoo te aloja | Restoo | Nada | | **Incrustado en tu web** — el formulario aparece dentro de tu propia web | Tú | Pasarle la decisión al widget | | **Restoo Attribution Transfer** — corre en tu web, también si lo alojas en Restoo | Tú | Pasarle la decisión al script | Alojado en Restoo el widget **es** la página: el aviso de cookies lo pone Restoo, y aplica esa decisión a todo lo que envía. Incrustado en tu web el formulario está en tu dominio, así que preguntas tú. [Restoo Attribution Transfer](/es/widget/attribution-transfer#qué-necesita-consentimiento) va aparte, porque se ejecuta en tu sitio web y no en el widget: ahí preguntas tú **también si tus clientes reservan en la página alojada por Restoo**. ## Qué es una plataforma de gestión de consentimiento Una plataforma de gestión de consentimiento (en inglés, Consent Management Platform o **CMP**) es el software que muestra el aviso de cookies de tu web, guarda lo que responde cada visitante y comunica esa decisión a las herramientas que la necesitan. En la documentación técnica casi siempre la verás por su acrónimo, CMP. **Si tu web ya muestra un aviso de cookies, ya tienes una.** Puede ser una herramienta dedicada —Cookiebot, OneTrust, Didomi o iubenda están entre las más extendidas—, un plugin de WordPress como Complianz o Borlabs, o el aviso que ya viene incluido en Wix, Squarespace o Shopify. Si no sabes cuál usas, lo sabrá quien te lleve la web. Incrustado en tu web, Restoo no sustituye a la tuya: solo lee su decisión, y para eso necesita que le digas cuál es. ## Cómo llega el consentimiento a Restoo **Cuando la pregunta la haces tú**, Restoo necesita que le pases la decisión del visitante. Hay dos formas, según cómo lo recoja ya tu web: Usas Cookiebot o una plataforma con Consent Mode v2: declaras cuál y Restoo lee la decisión, y sus cambios. Tu aviso de cookies lo has montado tú, o tu plataforma no está admitida: lo llamas cada vez que el visitante acepta, rechaza o cambia de opinión. ### Declarar tu plataforma de consentimiento Pásale el parámetro [`cmp`](/es/widget/advanced-installation#param-cmp) a `.create()`, la llamada que configura el widget, y Restoo tomará de esa plataforma la decisión del visitante y sus cambios posteriores. Puede leer de dos sitios: | Valor | De dónde lo lee | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | `COOKIEBOT` | El objeto `Cookiebot` de la página. Sus categorías se traducen a señales del Consent Mode igual que en la integración de Cookiebot con Google. | | `GOOGLE_CONSENT_MODE` | Las llamadas `gtag("consent", "update", …)` de `window.dataLayer`. Funciona con cualquier plataforma que envíe Consent Mode v2, que son casi todas. | Si tu plataforma no encaja en ninguna de las dos, usa [`setConsent()`](#llamar-a-setconsent-directamente) en su lugar. ### Llamar a `setConsent()` directamente Llama a [`setConsent(signals)`](/es/widget/advanced-installation#setconsent-signals) desde tu propio aviso de cookies cada vez que el visitante acepte, rechace o cambie su decisión. Si has declarado tu plataforma de consentimiento, Restoo ya la lee y no necesitas llamarlo. **Parámetros** Una o varias señales de consentimiento. Cada valor tiene que ser exactamente `"granted"` o `"denied"`. Almacenamiento con fines publicitarios. Envío de datos del usuario a plataformas de publicidad. Publicidad personalizada, como las audiencias de remarketing. Almacenamiento con fines analíticos. Almacenamiento que da soporte a la funcionalidad de la web, como las preferencias de idioma. Almacenamiento para personalización, como las recomendaciones. Almacenamiento relacionado con la seguridad, como la autenticación y la prevención del fraude. Las señales se acumulan entre llamadas, así que puedes informarlas de una en una o todas a la vez. Se aplican a toda la página, así que una sola llamada llega a todos los widgets, incluido uno que se monte **más tarde**, como un modal que se abre al hacer clic. ## Qué significa «desconocido» Todo lo que no hayas informado se queda como **desconocido**, y desconocido no autoriza nada: una señal cuenta como permiso solo cuando está explícitamente en `"granted"`. Hasta que se conoce la decisión del visitante, Restoo Connect no envía a ningún destino, Restoo Attribution Transfer no guarda las etiquetas de campaña ni los click ids, y el widget no difunde la identidad del cliente. Y lo que ocurre antes de ese momento **se descarta, no se encola**: entregarlo más tarde sería actuar sobre datos recogidos sin permiso. Lo que sí llega siempre son los [eventos del widget](/es/widget/events) en tu propia página: son tuyos, y el consentimiento de lo que hagas con ellos lo aplicas tú. ## Qué desbloquea cada señal | Señal | Desbloquea | | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | `analytics_storage` | La medición: consulta [los requisitos de cada destino](#requisitos-de-cada-destino) | | `ad_storage` | El almacenamiento publicitario y [recordar la atribución de campaña](/es/widget/attribution#consentimiento) entre páginas y entre visitas | | `ad_user_data`, `ad_personalization` | El envío de la identidad del visitante a tus plataformas de publicidad: consulta [Identidad del cliente](#identidad-del-cliente) | | `functionality_storage`, `personalization_storage` | [Reconocer a un cliente que vuelve](#recordar-a-un-cliente-que-vuelve) | | `security_storage` | El almacenamiento de la pasarela de pago —autenticar la operación y prevenir el fraude— y el resto de almacenamiento de seguridad | ### Recordar a un cliente que vuelve Con `functionality_storage` y `personalization_storage` concedidas, el widget recuerda al cliente y sus datos ya aparecen en su siguiente visita. Informa cualquiera de las dos como `"denied"` y **lo que se hubiera guardado se elimina**: retirar el permiso es tan sencillo como concederlo. Mientras la respuesta sigue siendo desconocida, el widget no guarda ni borra nada, y la reserva funciona igual en cualquiera de los casos. ## Requisitos de cada destino Cada destino **se decide por separado**: en un mismo evento uno puede recibirlo y otro no. Lo que exige depende de lo que **puede hacer** con el evento, no de cómo lo hayas configurado. | Destino | Señales necesarias | | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | `googleAds`, `metaPixel`, `tiktokPixel`, `openaiPixel` | Las tres de publicidad: `ad_storage`, `ad_user_data` y `ad_personalization` | | `ga4` | `analytics_storage`, salvo [con una propiedad que alimenta publicidad](#ga4-con-una-propiedad-que-alimenta-publicidad) | | `gtm` | Ninguna en concreto, pero sí que el consentimiento esté informado: [lo aplican tus etiquetas](#gtm-y-el-consentimiento-de-tus-etiquetas) | ### `ga4` con una propiedad que alimenta publicidad `ga4` cuenta como analítica **solo mientras tu propiedad de GA4 sea solo analítica**. Si también alimenta publicidad, los eventos que Restoo le envía alimentan la personalización publicitaria y `analytics_storage` por sí sola ya no es el permiso adecuado: entonces exige **además** las tres señales de publicidad, sumadas a la de analítica y no en su lugar, porque la propiedad sigue escribiendo su cookie `_ga`. Restoo no puede ver la configuración de tu propiedad, así que [se declara en tu cuenta](/es/widget/integrations#google-analytics-4). Es obligatorio siempre que `ga4` esté activado. ### `gtm` y el consentimiento de tus etiquetas `gtm` no exige ninguna señal concreta porque las etiquetas de tu contenedor traen la suya. Restoo empuja el evento en cuanto el consentimiento está informado, **aunque todas las señales estén denegadas**. De ahí en adelante manda el Consent Mode de tu GTM, y configurarlo bien te toca a ti. ## Identidad del cliente El correo y el teléfono del visitante se convierten en un **hash SHA-256** antes de salir del navegador, de modo que no viajan en claro y el destino solo puede cotejarlos con los que ya tenga de ese cliente. Eso es **pseudonimización, no anonimización**: el dato sigue siendo personal. Difundirlo exige `ad_user_data` y `ad_personalization` por encima de lo que ya pida cada destino. Para los cuatro destinos de publicidad eso no añade nada, porque ya exigen ambas señales para cualquier evento. Donde sí exige más es en `gtm` —que por lo demás solo pide que el consentimiento esté informado— y en un `ga4` declarado como solo analítica, que solo pide `analytics_storage`. El teléfono se hashea **dos veces, en dos formatos distintos**: Meta y el OpenAI Pixel necesitan [MSISDN](https://en.wikipedia.org/wiki/MSISDN) para su cruce de datos, y el resto de destinos usan [E.164](https://en.wikipedia.org/wiki/E.164). Los dos hashes no coinciden entre sí; eso es lo esperado, no un fallo. En [CustomerIdentified](/es/widget/events#customeridentified) tienes el payload exacto. **Revocar una señal concedida antes retira la identidad, no solo los eventos futuros.** Todo lo que ya se hubiera comunicado a un destino —el Advanced Matching de Meta, las conversiones mejoradas de Google, el `ttq.identify()` de TikTok, el `user` del OpenAI Pixel— se elimina de él en cuanto desaparece el permiso, sin dejarlo caducar por su cuenta. La eliminación es lo único incondicional. El **evento** `customer_signed_out` en sí sigue la misma regla de consentimiento que cualquier otro evento hacia GA4 y GTM. El OpenAI Pixel trae activado su *advanced matching* automático: además de lo que le envía Restoo Connect, el propio SDK detecta datos de contacto en los formularios de la página donde está instalado, los hashea en el navegador y los adjunta a sus eventos. Es una función del pixel, no de Restoo, y queda bajo el mismo permiso publicitario con el que se carga. ## Siguientes pasos Qué necesita cada destino de analítica y publicidad más allá del consentimiento. Qué atribución depende de `ad_storage` en cada uno de los dos casos.