# LinkedIn Server-side Tracking: cómo configurar la LinkedIn Conversions API Configura la LinkedIn Conversions API junto al Insight Tag: deduplicación, el ID de clic li_fat_id, tu tasa de coincidencia y la ruta de servidor adecuada. Source: https://taggrs.io/es/linkedin-server-side-tracking/ Author: Małgorzata Poddębniak, Especialista en marketing de contenidos · [LinkedIn](https://www.linkedin.com/in/malgorzatapoddebniak/) Updated: 2026-11-13 --- El LinkedIn Server-side Tracking envía tus eventos de conversión a LinkedIn desde un servidor que tú controlas, a través de la LinkedIn Conversions API, en lugar de depender solo del Insight Tag en el navegador del visitante. LinkedIn recomienda usar ambos: el Insight Tag sigue informando desde el navegador, tu servidor envía la misma conversión y un ID de evento compartido le indica a LinkedIn que la cuente una sola vez. La mayoría de las configuraciones de LinkedIn fallan en dos puntos. El ID de clic que vincula una conversión con un anuncio se pierde antes de que un lead B2B convierta. Y las copias del navegador y del servidor de una conversión no se deduplican, así que las cifras de Campaign Manager dejan de coincidir con tu CRM. Esta guía explica cómo configurar ambas fuentes, cómo funciona la deduplicación en LinkedIn, qué identificadores determinan tu tasa de coincidencia (match rate) y qué ruta de servidor hacia LinkedIn encaja con tu configuración. ## ¿Qué es el LinkedIn Server-side Tracking? La Conversions API es la conexión de servidor a servidor de LinkedIn para eventos de conversión. Tu sitio web o tu CRM envía primero cada conversión a tu propio servidor, y este la reenvía a LinkedIn con identificadores como un email cifrado con hash y el ID de clic de LinkedIn. LinkedIn vincula el evento con un miembro y lo atribuye a la campaña que lo generó. Como la copia del servidor no depende de cookies ni de scripts en el navegador, los bloqueadores de anuncios y los ajustes de privacidad del navegador le afectan menos. También llega a conversiones que nunca ocurren en un navegador, como un lead que tu equipo de ventas marca como cualificado semanas después. Para profundizar en la parte B2B, lee [LinkedIn Conversions API for B2B](/linkedin-conversions-api-for-b2b/) (en inglés). ## Principales beneficios ### Conversiones de tu CRM Los leads cualificados, las reuniones reservadas y los acuerdos cerrados ocurren en tu CRM, cuando la sesión en el sitio web ya ha terminado. La Conversions API es la vía para que lleguen a LinkedIn. Con el objetivo de optimización de leads cualificados, LinkedIn puede usar estas conversiones para orientar la entrega hacia leads que cumplen tus criterios, siempre que las compartas en un plazo de 30 días. ### Una coincidencia que aguanta un ciclo de venta largo El Insight Tag vincula una conversión con un anuncio mediante una cookie en el navegador. En el servidor, envías con la conversión un email cifrado con hash y el ID de clic guardado, así que LinkedIn puede vincular incluso un lead que convierte semanas después del primer clic. ### Control sobre lo que recibe LinkedIn Los eventos pasan por un contenedor de servidor que tú controlas, así que decides qué campos se reenvían, cuáles se cifran con hash y cuáles se retienen. ### Mejores audiencias y optimización LinkedIn optimiza e informa según las conversiones que puede vincular. Los eventos de la Conversions API vinculados con un miembro también pueden formar una audiencia de retargeting, que se puede usar cuando alcanza 300 miembros, y servir como fuente de una audiencia predictiva. Cuantas más conversiones vinculadas, más datos tiene LinkedIn para aprender. El Server-side Tracking no puede recuperar una interacción que tu sitio nunca registró, pero evita que sea el navegador quien decida si una conversión cuenta. Descubre [cómo el Server-side Tracking mejora Smart Bidding y el rendimiento de las campañas automatizadas](/improve-smart-bidding-with-server-side-tracking/). **Seguimiento solo en navegador y server-side para LinkedIn** | | Solo navegador | Server-side con TAGGRS | | ------------------------------------------------------ | ------------------------------------- | ---------------------------------------- | | Leads cualificados y acuerdos cerrados | ✗ Sin seguimiento | ✓ Se envían desde tu CRM | | Coincidencia en un ciclo de ventas largo | ✗ Depende de una cookie del navegador | ✓ Email con hash e ID de clic guardado | | Restricciones del navegador y bloqueadores de anuncios | ✗ Solo lo que deja pasar el navegador | ✓ Menos afectado | | Conversiones tardías | ✗ Sin seguimiento | ✓ Hasta 90 días después | | Control sobre lo que recibe LinkedIn | ✗ Limitado | ✓ Filtrar, aplicar hash o retener campos | > «Con soluciones client-side, un día puedes medir el 90 % y al siguiente solo el 20 %. Así no se pueden enviar buenos datos y tampoco entrenar una máquina.» > > Teun van Kleef, Lead Advertising & Data, Social Brothers ## ¿Insight Tag, Conversions API o ambos? Usar la Conversions API no significa quitar el Insight Tag. LinkedIn recomienda enviar las conversiones por las dos vías para tener una visión más completa del recorrido del cliente. Las dos fuentes ven cosas distintas. | Lo que ve el Insight Tag | Lo que ve la Conversions API | | ------------------------------------------------- | ----------------------------------------------------------- | | Las páginas vistas y las conversiones en tu sitio | Los leads cualificados y los acuerdos registrados en tu CRM | | La cookie li\_fat\_id y el contexto del navegador | El email cifrado con hash del formulario o del CRM | | Los visitantes del sitio para retargeting | Las conversiones tras el fin de la sesión | | Solo lo que el navegador deja pasar | Conversiones hasta 90 días después de que ocurrieran | Una configuración solo de servidor funciona, por ejemplo si solo quieres enviar etapas del CRM, pero renuncia al contexto del navegador y a las audiencias del sitio que aporta el Insight Tag. Para la mayoría de los anunciantes, la respuesta es usar ambas fuentes, deduplicadas. El paso 4 explica cómo. Elige LinkedIn en el comprobador de abajo para ver en qué contenedor va y cómo configurarlo. **¿En qué contenedor va tu plataforma?** Elige una plataforma para ver en qué contenedor va, por qué y cómo configurarla correctamente. **Google Analytics 4**: Ambos contenedores. Contenedor web + contenedor de servidor. Por qué: GA4 es la base de cualquier configuración server-side. El tag GA4 Config se ejecuta en el contenedor web y envía los datos al contenedor de servidor, que alimenta a todos los tags posteriores, incluido Google Ads. Sin GA4 en server-side, ninguna otra plataforma del contenedor de servidor recibe los datos correctamente. Pasos de configuración: 1. **Añade el tag GA4 Config**: En tu **contenedor web**, añade un tag de configuración de GA4. Introduce el Measurement ID y haz que la URL del contenedor de servidor apunte a tu subdominio de tagging first-party (p. ej. `sst.tudominio.es`). 2. **Conecta el contenedor de servidor a TAGGRS**: Conecta tu contenedor de servidor de GTM a TAGGRS. Tu subdominio de tagging debe ser un subdominio first-party del dominio que mides. 3. **Añade el tag de servidor de GA4**: En tu **contenedor de servidor**, añade el tag de GA4. Recibe automáticamente los eventos que reenvía el tag GA4 Config del contenedor web. 4. **Comprueba el flujo de datos**: Usa el modo Vista previa de GTM y GA4 DebugView para confirmar que los eventos llegan al contenedor de servidor antes de publicar. [Pasar al server-side (Google Analytics 4)](https://taggrs.io/docs/server-side-tracking/ga4/setup-in-gtm) **Google Ads**: Solo contenedor de servidor. Todos los datos salen del servidor. Sin tag de navegador. Por qué: La medición server-side de Google Ads depende por completo de que GA4 esté configurado primero en ambos contenedores. Una vez configurado GA4, todos los tags de Google Ads (Conversion Tracking y Remarketing) se ejecutan solo en el contenedor de servidor. Pasos de configuración: 1. **Configura primero GA4 en ambos contenedores**: Google Ads depende directamente de GA4. Completa la configuración server-side de GA4 antes de añadir cualquier tag de Google Ads. 2. **Añade el tag Conversion Linker**: En tu **contenedor de servidor**, añade el tag Conversion Linker. Vincula los datos de clic con los eventos de conversión. Es el paso que más se olvida, y sin él la atribución deja de funcionar. 3. **Añade el tag Google Ads Conversion Tracking**: En tu **contenedor de servidor**, añade el tag Google Ads Conversion Tracking. Introduce el ID y la etiqueta de conversión de tu cuenta de Google Ads. 4. **Añade el tag Google Ads Remarketing (opcional)**: Si haces campañas de remarketing, añade el tag Google Ads Remarketing al **contenedor de servidor**. Tiene la misma cadena de dependencias que Conversion Tracking. 5. **Prueba con Tag Assistant**: Comprueba toda la cadena: GA4 Config (web) → tag de servidor de GA4 → Conversion Linker → tag de Google Ads. Confirma que las conversiones aparecen en Google Ads → Medición → Conversiones. [Pasar al server-side (Google Ads)](https://taggrs.io/docs/server-side-tracking/google-ads/conversion-linker) **Meta / Facebook**: Ambos contenedores. Contenedor web + contenedor de servidor. Por qué: Meta recomienda ejecutar a la vez el píxel del navegador y la CAPI de servidor para maximizar las tasas de coincidencia y la cobertura de eventos. Con ambos aumenta la probabilidad de que cada conversión se atribuya bien, incluso cuando la señal del navegador está bloqueada o degradada. Deduplicación necesaria. Cuando el píxel del navegador y la CAPI de servidor se activan para el mismo evento, Meta lo recibe dos veces. Envía el mismo `event_id` en el evento del navegador y en el del servidor. Meta usa ese ID para deduplicar y cuenta la conversión una sola vez. Pasos de configuración: 1. **Mantén el Meta Pixel en el contenedor web**: Tu tag de Meta Pixel actual se queda en el **contenedor web**. No lo elimines: la señal del navegador mejora las tasas de coincidencia. 2. **Añade el tag Meta CAPI en el contenedor de servidor**: En tu **contenedor de servidor**, añade el tag Meta Conversions API. Introduce tu ID de píxel y tu token de acceso de Meta. 3. **Configura la deduplicación con event\_id**: Genera un `event_id` único para cada evento (p. ej. un UUID o una cadena basada en una marca de tiempo). Envía el mismo `event_id` en el evento del píxel del navegador y en el evento CAPI del servidor. Meta los empareja y cuenta una sola vez. 4. **Prueba en Meta Events Manager**: Ve a Meta Events Manager → Test Events. Confirma que llegan eventos del navegador y del servidor, y que los duplicados se deduplican correctamente. [Pasar al server-side (Meta / Facebook)](https://taggrs.io/docs/server-side-tracking/facebook/meta-pixel) **TikTok**: Ambos contenedores. Contenedor web + contenedor de servidor. Por qué: TikTok recomienda ejecutar el Pixel y la Events API juntos, con deduplicación de eventos, para maximizar el rendimiento. El Pixel solo puede perder conversiones por diferencias entre navegadores y problemas de conexión. La Events API recupera esos huecos. Ejecuta ambos en paralelo y envía el mismo `event_id` para que TikTok fusione los duplicados. Deduplicación necesaria. Cuando el Pixel y la Events API se activan para el mismo evento, TikTok lo recibe dos veces. Envía el mismo `event_id` en el evento del navegador y en el del servidor. TikTok usa ese ID para fusionar los duplicados y cuenta la conversión una sola vez. Pasos de configuración: 1. **Mantén el TikTok Pixel en el contenedor web**: Tu tag de TikTok Pixel actual se queda en el **contenedor web**. No lo elimines: TikTok recomienda usar el Pixel y la Events API juntos. 2. **Añade el tag TikTok Events API en el contenedor de servidor**: En tu **contenedor de servidor**, añade el tag TikTok Events API. Introduce tu ID de píxel y tu token de acceso de TikTok. 3. **Configura la deduplicación con event\_id**: Genera un `event_id` único para cada evento (p. ej. un UUID o una cadena basada en una marca de tiempo). Envía el mismo `event_id` en el evento del Pixel del navegador y en el evento de la Events API del servidor. TikTok los empareja y cuenta una sola vez. 4. **Confirma el hash de los datos de usuario**: El tag de servidor pasa automáticamente los datos de usuario (email, teléfono) a minúsculas y les aplica un hash SHA256 antes de enviarlos a TikTok. Comprueba que esté activado en la configuración del tag. 5. **Comprueba en TikTok Events Manager**: Ve a TikTok Ads Manager → Assets → Events → Web Events (o Test Events). Confirma que llegan eventos del navegador y del servidor, y que los eventos coincidentes se deduplican. [Pasar al server-side (TikTok)](https://taggrs.io/docs/server-side-tracking/tiktok/pixel) **Pinterest**: Ambos contenedores. Contenedor web + contenedor de servidor. Por qué: Pinterest sigue la misma lógica de doble señal que Meta: el tag del navegador y la Conversions API se ejecutan en paralelo. Juntos dan a Pinterest la visión más fiel de tus conversiones, lo que mejora la atribución y la optimización de campañas. Deduplicación necesaria. Con el tag del navegador y la Conversions API activos, Pinterest recibe cada evento de dos fuentes. Envía la misma clave de deduplicación en el evento del navegador y en el del servidor para que Pinterest cuente cada conversión una sola vez. Pasos de configuración: 1. **Mantén el Pinterest Tag en el contenedor web**: Tu Pinterest Tag actual se queda en el **contenedor web**. Sigue activándose con los eventos del navegador. 2. **Añade el tag Pinterest Conversions API en el contenedor de servidor**: En tu **contenedor de servidor**, añade el tag Pinterest Conversions API. Configura tu Tag ID y el token de acceso que generas en Ads Manager. 3. **Configura la deduplicación de eventos**: Envía la misma clave de deduplicación en el evento del navegador y en el del servidor. Pinterest la usa para emparejar y deduplicar los eventos de conversión. 4. **Prueba con Pinterest Tag Helper**: Usa la extensión de Chrome Pinterest Tag Helper y Pinterest Events Manager para confirmar que los eventos llegan por los dos canales y se deduplican correctamente. [Pasar al server-side (Pinterest)](https://taggrs.io/docs/server-side-tracking/pinterest/tag) **LinkedIn**: Ambos contenedores. Contenedor web + contenedor de servidor. Por qué: El LinkedIn Insight Tag se ejecuta en el lado del cliente, en el contenedor web, para crear audiencias y medir páginas vistas. Los eventos de conversión también se envían desde el servidor mediante LinkedIn CAPI. LinkedIn lo llama una configuración redundante: cuando ambos coinciden, LinkedIn conserva el evento del Insight Tag y descarta la copia de CAPI. Aun así, la vía del servidor cubre los casos en que el tag del navegador nunca se activa. Deduplicación necesaria. LinkedIn usa un `eventId` para emparejar los eventos de conversión del navegador y del servidor. Envía el mismo `eventId` en ambos. Cuando coinciden, LinkedIn conserva el evento del Insight Tag y descarta la copia de la Conversions API. Pasos de configuración: 1. **Mantén el LinkedIn Insight Tag en el contenedor web**: El Insight Tag se queda en el **contenedor web** para crear audiencias y medir páginas vistas. 2. **Añade el tag LinkedIn CAPI en el contenedor de servidor**: En tu **contenedor de servidor**, añade el tag LinkedIn Conversions API. Introduce tu LinkedIn Ad Account ID y tu token de acceso. 3. **Configura la deduplicación con eventId**: Envía el mismo `eventId` en el Insight Tag del navegador y en el evento CAPI del servidor. LinkedIn lo usa para deduplicar. Nota: `conversion_id` identifica la regla de conversión, no es la clave de deduplicación. 4. **Comprueba en LinkedIn Campaign Manager**: Ve a LinkedIn Campaign Manager → Analyze → Conversion Tracking. Confirma que aparecen los eventos del Insight Tag y de CAPI, y que las coincidencias redundantes se restan del recuento de CAPI. [Pasar al server-side (LinkedIn)](https://taggrs.io/docs/server-side-tracking/linkedin/insights-tag) **Snapchat**: Ambos contenedores. Contenedor web + contenedor de servidor. Por qué: Snap Pixel se ejecuta en el contenedor web y Snap Conversions API en el contenedor de servidor. Los dos canales funcionan en paralelo. El tag de servidor normaliza los parámetros de usuario y les aplica un hash automáticamente, como el email, el identificador móvil, la dirección IP y el número de teléfono, antes de enviarlos a Snap. Deduplicación necesaria. Envía el mismo ID en ambos lados: `client_dedup_id` en el Snap Pixel del navegador y `event_id` en los eventos de la Conversions API del servidor. Snapchat lo usa para deduplicar y cuenta cada conversión una sola vez. Pasos de configuración: 1. **Mantén el Snap Pixel en el contenedor web**: Tu tag de Snap Pixel actual se queda en el **contenedor web**. Sigue enviando los eventos del navegador. 2. **Añade el tag Snapchat Conversions API en el contenedor de servidor**: En tu **contenedor de servidor**, añade el tag Snapchat CAPI. Introduce tu ID de Snap Pixel y tu token de acceso. 3. **Confirma la normalización de los datos de usuario**: El tag normaliza automáticamente el email, el teléfono, la dirección IP y el identificador móvil y les aplica un hash SHA256. Comprueba que esté activado en la configuración del tag. 4. **Configura la deduplicación**: Envía un solo ID como `client_dedup_id` en el Snap Pixel y como `event_id` en la Conversions API para que Snapchat deduplique correctamente. 5. **Prueba en Snap Events Manager**: Ve a Snap Ads Manager → Events Manager. Confirma que los eventos llegan por los dos canales y se deduplican. [Pasar al server-side (Snapchat)](https://taggrs.io/docs/server-side-tracking/snapchat/snap-pixel) **Klaviyo**: Solo contenedor de servidor. Todos los datos salen del servidor. Sin tag de navegador. Por qué: Klaviyo no admite la deduplicación de eventos. Si ejecutas a la vez el seguimiento del navegador y el del servidor, cada evento llega dos veces. Configúralo solo en server-side. El tag se comunica directamente con la API de Klaviyo y permite añadir contactos, medir la actividad en el sitio y enviar parámetros de evento. Pasos de configuración: 1. **Elimina el tag de navegador de Klaviyo que tengas**: Si tienes un snippet de JavaScript de Klaviyo en tu contenedor web o en el código de tu sitio, desactívalo antes de añadir el tag server-side. Con ambos se generan eventos duplicados. 2. **Añade el tag de Klaviyo en el contenedor de servidor**: En tu **contenedor de servidor**, añade el tag de Klaviyo. Introduce tu Klaviyo Public API Key y tu Private API Key. 3. **Configura las acciones disponibles**: El tag admite tres tipos de acción: **medir eventos**, **crear o actualizar un contacto** y **crear o actualizar un contacto y medir un evento a la vez**. Configura el tipo de acción para cada trigger. 4. **Prueba con el feed de actividad de Klaviyo**: En tu cuenta de Klaviyo, ve a Profiles. Lanza un evento de prueba y confirma que aparece sin duplicados en el feed de actividad del perfil. [Pasar al server-side (Klaviyo)](https://taggrs.io/docs/server-side-tracking/config/klaviyo) **ActiveCampaign**: Solo contenedor de servidor. Todos los datos salen del servidor. Sin tag de navegador. Por qué: ActiveCampaign se conecta mediante la API desde el contenedor de servidor. El tag mide eventos, crea o actualiza contactos y puede combinar ambas acciones en una sola llamada. Configúralo solo en server-side para que lleguen a tu CRM datos limpios y sin duplicados. Pasos de configuración: 1. **Consigue tus credenciales de la API de ActiveCampaign**: En tu cuenta de ActiveCampaign, ve a Settings → Developer para encontrar tu API URL y tu API Key. 2. **Añade el tag de ActiveCampaign en el contenedor de servidor**: En tu **contenedor de servidor**, añade el tag de ActiveCampaign. Introduce tu API URL y tu API Key en la configuración del tag. 3. **Elige el tipo de acción**: Elige entre tres tipos de acción: **Track event**, **Create or update contact** o **Create or update contact + track event**. Configura el trigger adecuado para cada acción. 4. **Asigna los parámetros de evento y de contacto**: Define qué variables del data layer corresponden a los nombres de evento de ActiveCampaign, al email del contacto y a los campos personalizados que quieras rellenar. 5. **Prueba en ActiveCampaign**: Lanza un evento de prueba y confirma que aparece en ActiveCampaign en Contacts → Activity o Reports → Event Tracking. [Pasar al server-side (ActiveCampaign)](https://taggrs.io/docs/server-side-tracking/config/activecampaign) **Hotjar**: Solo contenedor web. No hace falta configuración server-side. Por qué: Hotjar graba sesiones, genera heatmaps y registra el comportamiento de los usuarios directamente en el navegador. Funciona observando las interacciones con el DOM (movimientos del ratón, profundidad de scroll y clics), que solo existen en el navegador. No tiene equivalente server-side y no lo necesita: Hotjar no envía señales de conversión a plataformas publicitarias, así que aquí no hay pérdida de señal que resolver. Déjalo en tu contenedor web y no toques tu contenedor de servidor. Pasos de configuración: 1. **Mantén Hotjar en el contenedor web**: Añade el código de seguimiento de Hotjar mediante un tag de HTML personalizado en tu **contenedor web**, o instálalo directamente en el `` de tu sitio. Las dos opciones son correctas. 2. **No hace falta cambiar el contenedor de servidor**: No añadas Hotjar a tu contenedor de servidor. No tiene equivalente en API, y enviarlo por el servidor haría que dejara de funcionar por completo. **Microsoft Clarity**: Solo contenedor web. No hace falta configuración server-side. Por qué: Microsoft Clarity funciona igual que Hotjar: grabaciones de sesiones y heatmaps capturados directamente en el navegador. Observa interacciones reales con el DOM y no puede funcionar fuera del navegador. Es gratis, se integra de forma nativa con GA4 y se usa mucho junto a configuraciones server-side, aunque no forma parte de ellas. Pasos de configuración: 1. **Añade Clarity mediante el contenedor web de GTM**: En tu **contenedor web**, añade un tag de HTML personalizado con el script de Microsoft Clarity. Haz que se active en todas las páginas. 2. **Conecta con GA4 (opcional)**: En el panel de Clarity, vincula tu propiedad de GA4 para ver las grabaciones de sesiones junto a los segmentos de GA4. Esta conexión se hace dentro de Clarity, sin cambios en GTM. 3. **No hace falta cambiar el contenedor de servidor**: Clarity no tiene API server-side. Mantenlo solo en el lado del cliente. **LiveChat**: Solo contenedor web. No hace falta configuración server-side. Por qué: LiveChat inserta un widget de chat en el DOM del navegador y detecta la actividad en la página, el tiempo de inactividad y el scroll para iniciar conversaciones en el momento justo. Todo eso requiere acceso directo al navegador. El widget no se puede cargar ni gestionar desde un contenedor de servidor. Pasos de configuración: 1. **Añade LiveChat mediante el contenedor web de GTM**: En tu **contenedor web**, añade un tag de HTML personalizado con el snippet de seguimiento de LiveChat. Haz que se active en todas las páginas. 2. **No hace falta cambiar el contenedor de servidor**: LiveChat no tiene API server-side para servir el widget. Es una herramienta pensada solo para el navegador. **Zendesk Chat**: Solo contenedor web. No hace falta configuración server-side. Por qué: Zendesk Chat (Web Widget) muestra una interfaz de chat en directo en el navegador. Usa JavaScript del lado del cliente para mostrar el widget, detectar el comportamiento de los visitantes y gestionar conversaciones en tiempo real. Como todos los widgets de chat de este tipo, depende por completo del navegador y no puede pasar por un contenedor de servidor. Pasos de configuración: 1. **Añade el Zendesk Web Widget mediante el contenedor web de GTM**: En tu **contenedor web**, añade un tag de HTML personalizado con el snippet del Web Widget de tu cuenta de Zendesk (Admin Center → Channels → Messaging). Haz que se active en todas las páginas. 2. **No hace falta cambiar el contenedor de servidor**: El Zendesk Web Widget funciona solo en el navegador. La configuración server-side no es necesaria ni posible. **Typeform**: Solo contenedor web. No hace falta configuración server-side. Por qué: Los formularios incrustados y los pop-ups de Typeform funcionan por completo en el navegador. Usan JavaScript del lado del cliente para mostrar el formulario, responder a lo que escribe el usuario y activar la lógica de visualización (por scroll, por tiempo o por exit intent). Typeform ofrece una Responses API para obtener las respuestas de servidor a servidor, pero el embed en sí solo funciona en el navegador y va en el contenedor web. Pasos de configuración: 1. **Incrusta Typeform mediante el contenedor web de GTM**: En tu **contenedor web**, añade un tag de HTML personalizado con el snippet de embed de Typeform, o usa el método de embed estándar con `