> ## 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.
# Atribución de campañas
> Cómo se atribuye cada reserva a la campaña que trajo al cliente, con el widget alojado en Restoo o incrustado en tu web.
Cuando un anuncio trae a un cliente, su URL lleva **parámetros UTM** que dicen de dónde viene. Restoo los guarda en la reserva y los incluye en todos los eventos del widget, así que puedes medir qué campañas te traen reservas.
De dónde los lee depende de **dónde reserva tu cliente**.
Tus clientes reservan en la página alojada por Restoo. Los parámetros van en
el propio enlace y el widget los lee de su dirección.
El formulario de reservas aparece dentro de tu web. Restoo.js lee
los parámetros de la dirección de tu página y se los pasa al widget.
Restoo lee estos cinco parámetros:
* `utm_source`
* `utm_medium`
* `utm_campaign`
* `utm_term`
* `utm_content`
Para montar los enlaces sin equivocarte, usa el [Campaign URL Builder de
Google](https://ga-dev-tools.google/campaign-url-builder/): rellenas los campos
y te devuelve la URL con los parámetros ya puestos.
## Alojado en Restoo
Pon los parámetros UTM de la campaña en el enlace:
```
https://best-burger.myrestoo.net/?utm_source=instagram&utm_medium=social&utm_campaign=verano
```
El widget **es** la página, así que lee su propia dirección en cuanto carga. No hay nada que instalar ni que declarar.
Eso vale para la campaña cuyo enlace apunta directamente a tu página de Restoo, pero no para la que aterriza antes en **tu propia web**. Un visitante que llega a tu portada desde un anuncio y desde ahí pasa a tu página de Restoo deja la campaña atrás, en tu sitio, y el widget no encuentra nada que leer en su propia dirección.
[Restoo Attribution Transfer](/es/widget/attribution-transfer) es lo que cierra ese hueco. Instalado en tus propias páginas, escribe la campaña —y los identificadores de clic de las plataformas de anuncios— en el enlace cuando el visitante lo sigue, de modo que la reserva se atribuye igual, en Restoo y en la plataforma que trajo el clic.
## Incrustado en tu web
Restoo.js lee los parámetros UTM de la dirección de tu página y se los entrega al widget al arrancar. Un visitante que llega desde un anuncio a la página donde está el widget se atribuye sin que tengas que hacer nada.
Lo que no se resuelve solo es **conservar la campaña de una página a otra**: si el visitante aterriza en tu portada y navega desde ahí hasta la página de reservas, en la barra de direcciones ya no queda nada que leer. Para eso está [Restoo Attribution Transfer](/es/widget/attribution-transfer).
## Modelo de atribución
En los dos casos se conserva **la última campaña** que trajo al visitante, lo que en marketing se conoce como atribución *last-touch*. Una URL nueva que contenga al menos uno de los cinco parámetros sustituye el conjunto completo guardado antes.
| Lo que trae la visita | Lo que hay guardado | Atribución que usa el widget |
| --------------------- | ------------------------------- | ---------------------------------------------------- |
| Parámetros UTM | Cualquier valor | Los parámetros de esta visita |
| Ningún parámetro UTM | Valores guardados válidos | Los valores guardados |
| Ningún parámetro UTM | Sin valores o valores caducados | [La atribución por defecto](#atribución-por-defecto) |
Los valores guardados caducan **30 días** después de capturarse, y capturar un conjunto nuevo abre un nuevo periodo de 30 días.
## Atribución por defecto
Una reserva que llega a Restoo sin atribución no se guarda en blanco. Al crearla, Restoo rellena los dos campos principales con valores por defecto, de modo que toda reserva tiene un canal:
| Campo | Valor |
| ----------- | --------- |
| `utmSource` | `Directa` |
| `utmMedium` | `Online` |
`utmCampaign`, `utmTerm` y `utmContent` se quedan vacíos.
Los dos se registran en el idioma del país en el que está dado de alta tu negocio, así que un negocio en España ve `Directa` y uno en Italia, `Diretta`.
Dos detalles que conviene saber:
* **Los valores por defecto entran campo a campo.** Una reserva que trae `utm_source` pero no `utm_medium` recibe igualmente `Online` como medio: no es todo o nada.
* **Los escribe Restoo al guardar la reserva**, y solo al crearla, no cuando se modifica después. El [objeto `acquisition` de los eventos](#atribución-de-los-eventos) no se ve afectado: sigue informando `null` de lo que no se capturó.
## Consentimiento
Leer los parámetros de una URL no requiere ningún tipo de consentimiento. **Guardarlos en el navegador del visitante sí**: conservar la atribución es una finalidad de marketing, no una necesidad técnica, así que necesita su permiso para el almacenamiento publicitario —`ad_storage`, en términos del [Consent Mode de Google](https://support.google.com/tagmanager/answer/10718549)—.
Es igual en los dos casos:
| Operación | Necesita consentimiento |
| -------------------------------------------------------- | ----------------------- |
| Atribuir la visita en curso con los parámetros de la URL | No |
| Recordar la campaña durante 30 días | Sí |
| Volver a leer lo que guardó una visita anterior | Sí |
Lo que se lee de la dirección se queda en memoria, se guarda con la reserva y se incluye en los eventos de esa visita, así que ahí no hay nada que preguntar. Lo que necesita permiso es la **memoria**: conservar la campaña de una página a otra y recuperarla si el visitante vuelve más adelante. Esa decisión se la informas a Restoo [igual que para todo lo demás](/es/widget/consent).
Un visitante que acepta **después** de que el widget se haya cargado recupera igualmente lo que hubiera guardado: esos valores llegan al widget en cuanto se conoce la respuesta.
## La atribución de la ficha del cliente
La atribución no se queda solo en la reserva. **Cuando una reserva crea también la ficha del cliente** —es decir, la primera que hace contigo—, esa misma atribución queda guardada en su ficha.
Esa atribución es la del primer contacto y **no se reescribe nunca**. Si ese mismo cliente vuelve a reservar más adelante desde otra campaña, la reserva nueva lleva la atribución nueva, pero su ficha sigue mostrando la campaña que lo trajo la primera vez.
Son dos preguntas distintas y por eso se guardan por separado: qué campaña trae **cada reserva**, y qué campaña te consiguió **cada cliente**.
## Atribución de los eventos
Los valores capturados se incluyen en el [objeto `acquisition` de todos los eventos del widget](/es/widget/events#campos-comunes-a-todos-los-eventos):
```js theme={null}
{
acquisition: {
utm_source: "google",
utm_medium: "cpc",
utm_campaign: "summer",
utm_content: null,
utm_term: null
}
}
```
Cada campo vale `null` cuando su parámetro UTM correspondiente no se capturó.
## Fijar la atribución de una instalación
Hay páginas que **son** el canal, y ahí la URL del visitante no debería decidir nada: el caso habitual es un portal de reservas colaborador que incrusta el widget. Una instalación puede declarar su propia atribución fija, y esa manda sobre todo lo de esta página: consulta [Atribución forzada](/es/widget/advanced-installation#atribución-forzada).
Es una opción de tenerlo incrustado en tu web. Alojado en Restoo la configuración sale de tu cuenta, y ahí no se declara ninguna atribución fija.
## Siguientes pasos
Instala el script que conserva la atribución entre las páginas de tu web.
Qué desbloquea `ad_storage` y cómo informas la decisión del visitante.