Google Analytics 4
ga4Google Tag Manager
gtmGoogle Ads
googleAdsMeta Pixel
metaPixelTikTok Pixel
tiktokPixelOpenAI Pixel
openaiPixelCuando un visitante modifica una reserva que ya existe, Restoo Connect suprime
los eventos de embudo y de conversión. Sí sigue reenviando
action_taken,
customer_identified y customer_signed_out a todas las plataformas, y
booking_updated solo a GA4 y a Google Tag Manager. Una modificación no es una
conversión nueva, así que nunca llega a Google Ads, Meta, TikTok ni ChatGPT Ads.Modelo de captación
Restoo mide las reservas como captación de leads, no como ecommerce. Una reserva no se trata como una compra, sino como la captación y la cualificación de un cliente potencial. Cada reserva creada dispara una sola conversión, elegida por el estado con el que nace:
Las dos son excluyentes. Una reserva confirmada dispara la de reserva confirmada y no la de lead; una pendiente dispara la de lead y no la de reserva confirmada. Sumadas equivalen al total de reservas creadas, así que ninguna reserva se cuenta dos veces.
Con una política de cancelación, la reserva no existe hasta que el cliente la
firma, así que la conversión se emite entonces y no al enviar el formulario. Si
abandona la página de firma, no se cuenta ninguna conversión. El estado con el
que nace la reserva decide igualmente cuál de las dos se dispara: una reserva con
política de cancelación también puede quedar pendiente de confirmación o en
lista de espera.
- No contamina tus ingresos. Las reservas nunca se cuentan como ventas, así que no distorsionan los informes de ingresos ni se mezclan con las ventas reales de productos, como las tarjetas regalo.
- Refleja el negocio real. Una reserva es una intención de visita, no una transacción cerrada, y el modelo de lead lo representa con fidelidad.
- Las campañas optimizan bien. Cada plataforma optimiza para captar reservas, sin sesgo hacia las reservas que casualmente llevan un anticipo.
El resto de esta página documenta todos los eventos que recibe cada plataforma, incluidos los de comportamiento, y los datos exactos que se envían con cada uno.
Qué omite Restoo deliberadamente
Hay campos que quizá esperes encontrar y que no están en ninguno de los payloads documentados aquí. Es a propósito, así que conviene saberlo antes de ponerse a buscarlos. Los nombres del catálogo. Las experiencias, los complementos y los elementos de un listado se identifican por ID —best_burger:experience:7—, nunca por su nombre.
El nombre de una experiencia es texto libre que escribe el negocio, y de ahí pueden inferirse datos de categorías especiales: un menú sin gluten apunta a la salud, una cena halal a las creencias religiosas, una experiencia temática puede apuntar a la orientación sexual. Bajo el RGPD eso exige un consentimiento explícito y aparte que este flujo no recoge, y las condiciones de Meta y de Google prohíben recibirlo: enviarlo pondría en riesgo la cuenta de publicidad.
Si tus informes necesitan etiquetas legibles, mantén tu propia tabla de equivalencias entre ID y nombre.
Los campos del cliente que ningún destino lee. El payload de identidad lleva solo el correo y el teléfono hasheados, porque son los dos únicos campos que consume algún destino. Antes se enviaban también un nombre, un código postal y un país, y se quitaron: el hasheo es pseudonimización, no anonimización, así que un campo que nadie lee es un dato personal expuesto sin ninguna finalidad.
El dinero en las conversiones. Las conversiones no llevan value ni currency: consulta Modelo de captación.
Estos campos se eliminan en el origen, no destino a destino. Todos los eventos
del widget se emiten a la página que lo incrusta, así que cualquier script de
terceros que se ejecute ahí puede leerlos. Filtrar dentro de un destino
protegería a Meta y a TikTok dejando ese canal completamente abierto.
Google Analytics 4
Conga4 activado, Restoo Connect llama a gtag("event", eventName, data). Se usan los nombres de evento estándar de GA4 cuando hay un equivalente adecuado. Los eventos propios de Restoo usan el prefijo restoo_.
Todas las llamadas llevan send_to con el measurement ID de la propiedad configurada en tu cuenta, así que los eventos llegan a esa propiedad y a ningún otro destino configurado en la página. En los ejemplos de abajo se omite, porque es el mismo en todos.
Eventos estándar
Estos eventos usan nombres definidos por GA4. La tabla enlaza al payload exacto que se envía en cada correspondencia, incluidos los parámetros adicionales de Restoo.
Para el significado de estos parámetros de evento y de elemento, consulta la referencia de eventos recomendados y la documentación de ecommerce de Google.
Eventos personalizados de Restoo
Estos eventos no tienen un equivalente directo en GA4. Sus nombres usan el prefijorestoo_ para que se puedan identificar como eventos personalizados.
Los campos
booking_*, action_* y availability_outcome son también parámetros personalizados. Consulta los parámetros de eventos personalizados de GA4 para saber cómo exponerlos en los informes.
generate_lead y qualify_lead no incluyen value ni currency: una reserva se modela como un lead, no como una compra de ecommerce.
Datos GA4 del inicio de reserva
Cuando se muestra la página de inicio de reserva, Restoo Connect envía el evento personalizado sin parámetros:search, con un término de búsqueda sintético:
pax_{guests}_day_{weekday}_shift_{shift}; los niños se cuentan dentro del número de comensales.
Datos GA4 del listado de elementos
select_item envía la misma estructura más la cantidad que eligió el cliente: quantity lleva el número de tickets de la experiencia, o las unidades del complemento. Un listado que se muestra todavía no tiene cantidad, así que view_item_list nunca la incluye. Los ID de listado están acotados a la cuenta y al tipo de listado.
Los precios se convierten de la unidad más pequeña de la divisa a unidades decimales.
Datos GA4 del detalle de un elemento
item_category es floor_plan_area.
Datos GA4 del formulario de datos y de la reserva
Los tres eventos del formulario de datos del cliente —restoo_booking_details_form_viewed cuando se muestra, form_start cuando el cliente empieza a rellenarlo y form_submit cuando lo envía— incluyen los mismos identificadores fijos de formulario y el contexto actual de la reserva:
generate_lead, qualify_lead y el resto de eventos de reserva propios de Restoo reciben los mismos campos de reserva, sin form_id ni form_name. Los campos cuyo valor de origen es null o undefined se omiten.
Consulta BookingFunnel para los campos de reserva de origen, y BookingStatus, ShiftType y CancellationPolicyType para las definiciones de los enumerados.
Datos GA4 de falta de disponibilidad
Datos GA4 de las acciones
action_taken emite siempre el evento propio de Restoo:
select_content cuando se trata de un canal de contacto concreto:
content_type es availability_fallback y content_id es la opción seleccionada. Abrir el menú de contacto (option: "open") o usar una acción genérica de un solo paso (option: "click") no emite el select_content de contacto.
Datos GA4 del cliente
Antes de enviar los eventos de identificación, Restoo Connect define el correo y el teléfono hasheados disponibles comouser_data global:
restoo_customer_identified se envía solo cuando hay un correo o un teléfono hasheados disponibles; login se envía siempre. Cuando el cliente identificado no tiene ninguno de los dos, user_data se define como {} para no dejar atrás la identidad de un visitante anterior. Al cerrar sesión, Restoo Connect limpia siempre user_data —esa eliminación no necesita consentimiento— y, cuando se cumple el requisito de consentimiento de esta propiedad, envía además restoo_customer_signed_out:
user_data global no son datos de evento. GA4 solo los ingiere cuando la propiedad tiene activada la recogida de datos proporcionados por el usuario.
Google Tag Manager
Congtm activado, Restoo Connect envía objetos a window.dataLayer. Los nombres de los eventos son los mismos que en el destino directo de GA4, pero los datos de la reserva se anidan bajo restoo y los de los elementos, bajo ecommerce.
Eventos estándar
Estos eventos deldataLayer reflejan la correspondencia estándar de GA4. Se pueden usar como triggers de evento personalizado para GA4 o para otras etiquetas de GTM.
Eventos personalizados de Restoo
Estos eventos no tienen un equivalente estándar directo. Sus nombres usan el prefijorestoo_. Los eventos con datos adicionales los guardan bajo la clave restoo.
Consulta la documentación del data layer de Google para saber cómo procesa GTM el campo
event y el resto de variables de cada envío. Los objetos restoo anidados son variables propias de Restoo que puedes exponer con definiciones de variable de capa de datos en GTM.
Envíos GTM del inicio de reserva
Envíos GTM de elementos
select_item usa el mismo objeto ecommerce. view_item usa los datos GA4 del detalle de un elemento bajo ecommerce.
Envíos GTM del formulario de datos y de la reserva
restoo_booking_details_form_viewed y form_start usan la primera estructura, cambiando solo el event. qualify_lead usa la segunda con event: "qualify_lead" y booking_status: "CONFIRMED". El conjunto completo de campos de reserva está en Datos GA4 del formulario de datos y de la reserva.
Envíos GTM de reserva específicos de Restoo
Los eventos propios de Restoo incluyen un contexto de reserva más completo. El nombre del evento cambia según la tabla de correspondencias; la estructurarestoo es siempre la misma.
null, salvo booking_add_ons, que es un array vacío cuando no se ha añadido nada. Los campos monetarios usan unidades decimales de la divisa. Consulta CancellationPolicyAmountType para los tipos de importe posibles.
restoo_booking_no_availability_viewed añade availability_outcome a ese mismo objeto restoo.
Envíos GTM de las acciones
Envíos GTM del cliente
window.dataLayer.push({ user_data: {} }); login se emite igualmente.
Al cerrar sesión son dos envíos separados, y no uno con las dos claves. La limpieza de user_data va sin event y ocurre siempre, porque retirar un dato no necesita permiso; el evento va aparte y solo cuando se cumple el requisito de consentimiento propio de GTM:
user_data en el evento de cierre no encuentra la clave en ese envío, porque llegó en el anterior.
Antes de cada envío de evento, Restoo Connect limpia primero los campos
transitorios
restoo, ecommerce, de formulario, de búsqueda, de contenido y
method, para que no se reutilicen valores de un evento anterior. user_data
persiste hasta que se sustituye o se limpia.Google Ads
CongoogleAds activado, Restoo Connect envía las conversiones mediante gtag("event", "conversion", data) y gestiona los datos hasheados del cliente mediante gtag("set", "user_data", data).
Conversiones estándar
Todos los eventos de conversión usan el nombre de evento estándarconversion de Google Ads. booking_lead, booking_confirmed y contact identifican la acción de conversión configurada, no son nombres de eventos personalizados enviados a Google Ads.
Actualizaciones de datos del cliente
Estas llamadas actualizan los datos de cruce globales; no son eventos ni conversiones.
Consulta la guía de configuración de conversiones de Google para saber cómo interpreta Google Ads las acciones de conversión, y la documentación de conversiones mejoradas para los datos de cruce del cliente.
Restoo Connect no envía eventos personalizados de Restoo a Google Ads.
Datos de conversión de Google Ads
Cada conversión envía únicamente su destino configurado:value, ni currency, ni transaction_id. La referencia de la propia reserva sería el ID de transacción natural, pero esa referencia es también la llave a los datos personales del cliente, así que nunca sale del widget.
Datos del cliente en Google Ads
gtag("set", "user_data", {}). Los datos del cliente enriquecen una conversión cuando están disponibles, pero no son imprescindibles para que se dispare.
Configurar los destinos de conversión
1
Crea las acciones de conversión
En Google Ads, ve a Objetivos → Conversiones → Nueva acción de conversión →
Sitio web. Crea las acciones
booking_lead, booking_confirmed y contact
que quieras medir y elige la configuración manual con la etiqueta de Google.
Usa esto como descripción de cada acción de conversión:Cada reserva dispara una sola de las dos primeras. Configura las dos aunque
tu local confirme al instante: un horario que se cubra pasa a solicitud o a
lista de espera, y sin
booking_lead esas reservas no se medirían.2
Copia el ID de conversión y cada etiqueta
Abre la configuración de la etiqueta de la acción de conversión y copia su
ID de conversión y su etiqueta. Consulta cómo encontrar el ID y la
etiqueta. El ID de
conversión es de la cuenta y es el mismo para las tres acciones; la etiqueta
es distinta en cada una.
3
Asígnalos en tu cuenta de Restoo
Pega el ID de conversión una vez, y cada etiqueta en la acción a la que
corresponde, en la configuración de tu integración de Google
Ads.Solo se emiten las acciones que tienen su etiqueta configurada, y una página no
puede redirigirlas a otro sitio:
connect solo admite false, para
desactivar un destino
entero.Meta Pixel
ConmetaPixel activado, Restoo Connect envía los eventos mediante fbq("trackSingle", pixelId, eventName, data) —y fbq("trackSingleCustom", …) para los personalizados— y gestiona el Advanced Matching reinicializando tu pixel mediante fbq("init", pixelId, userData). El ID del pixel se declara en tu cuenta de Restoo y es obligatorio para poder activar este destino.
Eventos estándar
Todos los eventos de medición que se envían a Meta usan nombres de evento estándar del Meta Pixel.Eventos personalizados de Restoo
Las etapas del embudo van como eventos personalizados y no como eventos estándar: los eventos estándar de Meta son optimizables, y ninguna de estas etapas es una conversión. Meta no las cuenta como conversión salvo que crees una conversión personalizada sobre ellas (consulta eventos estándar y personalizados). Todas se envían confbq("trackSingleCustom", pixelId, …).
Actualizaciones de datos del cliente
Las dos llamadas necesitan el ID del pixel configurado en tu cuenta. Actualizan los datos de Advanced Matching de Meta; no son eventos del pixel.
Consulta la referencia de eventos del pixel de Meta para el significado y los parámetros esperados de sus eventos estándar.
De
action_taken solo viaja el contacto por un canal concreto. El resto de acciones —añadir al calendario, invitar, cómo llegar, recomendar, compartir, modificar, cancelar— ocurren cuando la reserva ya está hecha, así que no alimentan ninguna audiencia ni cuentan como conversión: se quedan en GA4 y en GTM.
Datos de búsqueda y de contenido de Meta
Cuando se muestra la página de inicio de reserva, Restoo Connect envía el evento personalizado sin parámetros:Search, con un término de búsqueda sintético; el detalle de una experiencia manda un ViewContent:
ViewContent, con el contenido de la reserva:
content_ids de la reserva contiene el ID de la cuenta seguido de los ID de la experiencia y de los complementos seleccionados.
Datos de listado de Meta
RestooBookingItemSelected envía la misma estructura con los elementos que eligió el cliente. Ninguno de los dos lleva content_name ni cantidades: los ID de los elementos son lo único que necesitan la atribución y las audiencias.
Datos de falta de disponibilidad de Meta
content_ids puede contener solo el ID de la cuenta. Consulta AvailabilityOutcome para los valores posibles y su significado.
Datos de Lead y Schedule de Meta
Schedule y los eventos personalizados del formulario de datos, de las condiciones y de la política de cancelación reciben el mismo contenido.
Los eventos de Meta no llevan precios, ni value, ni currency, ni ID de evento. Como no hay ID de evento, Meta no puede cruzar estos eventos con una integración de servidor de la Conversions API, así que no reportes las mismas reservas por las dos vías: consulta Evitar conversiones duplicadas.
Datos de contacto y de cliente de Meta
em y ph contienen hashes SHA-256 normalizados. La llamada de identificación solo se hace cuando hay al menos un valor hasheado disponible. Al cerrar sesión, Restoo Connect envía fbq("init", pixelId, {}).
TikTok Pixel
ContiktokPixel activado, Restoo Connect envía los eventos mediante ttq.instance(pixelId).track(eventName, data) y gestiona los datos de cruce del cliente mediante ttq.instance(pixelId).identify(data). Las dos van acotadas al pixel configurado en tu cuenta, así que una página con más de un pixel instalado solo los recibe en ese.
Eventos estándar
Todos los eventos de medición que se envían a TikTok usan nombres de evento estándar del TikTok Pixel.TikTok renombró
SubmitForm como Lead y mantiene el nombre antiguo
operativo, convirtiéndolo en su backend. Restoo envía SubmitForm, que es el
que sigue en la referencia de eventos estándar, y en tus informes y en tu
optimización lo verás como Lead. Consulta los eventos estándar
actualizados.Eventos personalizados de Restoo
Las etapas del embudo van como eventos personalizados y no como eventos estándar: ninguna de ellas es una conversión. TikTok usa los eventos personalizados para informes y audiencias, pero no se pueden elegir como objetivo de optimización de campaña (consulta eventos personalizados).Actualizaciones de datos del cliente
Estas llamadas actualizan los datos de cruce de TikTok; no son eventos del pixel.
Consulta la referencia de eventos estándar y la referencia de parámetros de TikTok para el significado y el formato esperado de sus campos estándar.
De
action_taken solo viaja el contacto por un canal concreto. El resto de acciones —añadir al calendario, invitar, cómo llegar, recomendar, compartir, modificar, cancelar— ocurren cuando la reserva ya está hecha, así que no alimentan ninguna audiencia ni cuentan como conversión: se quedan en GA4 y en GTM.
Datos de búsqueda y de contenido de TikTok
Cuando se muestra la página de inicio de reserva, Restoo Connect envía el evento personalizado sin parámetros:Search, con un término de búsqueda sintético; el detalle de una experiencia manda un ViewContent:
ViewContent, con el contenido de la reserva:
Datos de listado de TikTok
RestooBookingItemSelected envía la misma estructura con los elementos que eligió el cliente. Ninguno de los dos lleva content_name ni cantidades: los ID de los elementos son lo único que necesitan la atribución y las audiencias.
Datos de falta de disponibilidad de TikTok
content_ids puede contener solo el ID de la cuenta. Consulta AvailabilityOutcome para los valores posibles y su significado.
Datos de SubmitForm y Schedule de TikTok
Schedule y los eventos personalizados del formulario de datos, de las condiciones y de la política de cancelación reciben el mismo contenido.
Los eventos de TikTok no llevan precios, ni value, ni currency, ni ID de evento. Igual que con Meta, eso significa que estos eventos no se pueden cruzar con una integración de servidor de la Events API: consulta Evitar conversiones duplicadas.
Datos de contacto y de cliente de TikTok
email y phone_number contienen hashes SHA-256 normalizados. La identificación solo se envía cuando hay al menos un valor disponible. Al cerrar sesión, Restoo Connect envía ttq.instance(pixelId).identify({}).
OpenAI Pixel
ConopenaiPixel activado, Restoo Connect envía los eventos al pixel de ChatGPT Ads mediante oaiq("measureSingle", pixelId, eventName, data, options) y fija los datos de cruce del cliente mediante oaiq("init", { pixelId, user }). Las dos van acotadas al pixel configurado en tu cuenta, así que una página con más de un pixel inicializado solo los recibe en ese: measure, la llamada que reparte a todos, no se usa.
En este destino el nombre del evento y la forma de sus datos van por separado: cada evento estándar exige un data.type concreto, y el SDK descarta el evento entero si data lleva un campo que no documenta para ese tipo. Los datos de las tablas de abajo son exactamente los que caben.
Eventos estándar
ChatGPT Ads no tiene un evento estándar de búsqueda ni uno de formulario, así
que la búsqueda de disponibilidad y el formulario de datos, que en Meta y TikTok
son
Search y ViewContent, aquí van como eventos personalizados.Eventos personalizados de Restoo
Las etapas del embudo van como eventos personalizados —el eventocustom, con el nombre en custom_event_name— y no como eventos estándar: ninguna de ellas es una conversión. ChatGPT Ads los admite para medición, pero no como objetivo de optimización de una campaña. El contacto también va personalizado, porque ningún evento estándar lo describe. Llevan el prefijo restoo_ porque comparten pixel con los eventos personalizados que envíe tu propio sitio.
Actualizaciones de datos del cliente
Estas llamadas fijan los datos de cruce del pixel; no son eventos.
Consulta los eventos admitidos y la referencia del pixel de OpenAI para el significado y el formato esperado de sus campos.
De
action_taken solo viaja el contacto por un canal concreto. El resto de acciones —añadir al calendario, invitar, cómo llegar, recomendar, compartir, modificar, cancelar— ocurren cuando la reserva ya está hecha, así que no alimentan ninguna audiencia ni cuentan como conversión: se quedan en GA4 y en GTM.
Datos de reserva del OpenAI Pixel
Cuando se muestra la página de inicio de reserva, Restoo Connect envía el evento personalizado sin contenido:name; los demás elementos se identifican por su ID, por lo que se explica en qué omite Restoo deliberadamente. Ningún elemento lleva amount ni currency.
Dos datos que Meta y TikTok sí reciben no viajan a este destino: el término de búsqueda sintético de Search y el availability_outcome de la falta de disponibilidad. No son campos que el SDK documente, y llevarlos descartaría el evento entero.
Datos de listado del OpenAI Pixel
items_added envía la misma estructura con los elementos que eligió el cliente, y el detalle de un elemento envía contents_viewed con ese único elemento. Ninguno lleva name ni cantidades: los ID de los elementos son lo único que necesitan la atribución y las audiencias.
Datos de conversión del OpenAI Pixel
lead_created envía exactamente lo mismo. El tipo customer_action, que es el que exigen estos dos eventos, no admite contents, así que la conversión no lleva los ID de la reserva: van en las etapas del embudo que la preceden.
Los eventos del OpenAI Pixel no llevan precios, ni amount, ni currency, ni ID de evento. Igual que con Meta y TikTok, eso significa que no se pueden cruzar con una integración de servidor de la Conversions API de OpenAI: consulta Evitar conversiones duplicadas.
Datos de contacto y de cliente del OpenAI Pixel
custom no admite campos propios en el pixel. email_sha256 y phone_number_sha256 contienen hashes SHA-256 normalizados; el del teléfono es el del formato MSISDN, el mismo que recibe Meta (consulta Identidad del cliente). La identificación solo se envía cuando hay al menos un valor disponible. Al cerrar sesión, Restoo Connect envía oaiq("init", { pixelId, user: {} }), que retira la identidad del pixel.
Siguientes pasos
Pujas y optimización
Elige hacia qué eventos optimizar las campañas en cada plataforma.
Consentimiento
Qué necesita cada destino para recibir un evento, señal a señal.