Un widget embebible es código que tus clientes pegan en sus propios sitios web: un snippet de analítica, una burbuja de chat, un formulario de reservas, un recolector de mediciones. Es la clase más difícil de ingeniería de frontend precisamente porque desaparece todo lo que un proyecto web normal da por sentado: no eliges el framework, ni la línea base de navegadores, ni los otros scripts de la página, ni cuándo actualizan tus usuarios. Tu código es un invitado en casa ajena, y tiene que comportarse a la perfección en todas las casas a la vez.

Es una disciplina de nicho, y tenemos una credencial real en ella: un recolector de señales que construimos corre incrustado en miles de sitios que no controlamos, alimentando una plataforma que puntúa decenas de miles de peticiones por minuto.

Los productos que construimos

  • Recolectores de medición y analítica: scripts que reúnen señales de una página y las envían a tu plataforma, como el que hay detrás de nuestro trabajo de detección de bots
  • Widgets funcionales: chat, reservas, formularios, calculadoras: una pieza de tu producto viviendo dentro de la página de tu cliente
  • Integraciones instaladas por snippet: el onboarding de «añade una etiqueta script» que pone tu producto delante de los visitantes de tu cliente
  • La ingesta detrás del script: el backend que recibe lo que envía el snippet, al volumen que sume el tráfico de tus clientes
  • El cuadro de mando desde el que tus clientes lo vigilan: las superficies de informes y configuración se cubren en paneles de administración y cuadros de mando

Quién construye tu script embebible

Construimos uno de estos de principio a fin, desde el snippet hasta la plataforma que hay detrás.

Un recolector en miles de páginas hostiles

Para una plataforma de detección de bots en tiempo real construimos el recolector del lado del navegador que reúne las pruebas a partir de las que se emite el veredicto de persona o bot. Es JavaScript plano —sin framework, sin runtime de compilación, sin dependencias— porque corre en miles de páginas junto a todo lo demás que esas páginas cargan, no puede dar por hecho un sistema de módulos ni un conjunto de polyfills y no debe chocar jamás con el sitio que lo rodea. Opera en un entorno activamente hostil: aquello que mide intenta derrotarlo. Y es pequeño, porque cada kilobyte se carga contra el presupuesto de rendimiento del propio cliente, en cada vista de página, para siempre.

Y la plataforma que recibe lo que envía

Un snippet es la décima parte visible del sistema. Detrás de ese recolector construimos los servicios de ingesta y scoring en Go y la plataforma de datos que hay debajo, porque un embed que tiene éxito multiplica su propio tráfico por cada cliente que lo instala, y el backend tiene que diseñarse para esa aritmética desde el primer día. La arquitectura completa está en el caso de estudio.

Qué exige realmente el código embebido

Cinco restricciones separan este trabajo de la ingeniería de frontend corriente.

Un presupuesto de tamaño medido en kilobytes

Tu script se envía a cada visitante de cada cliente. El runtime de un framework sería más grande que un recolector entero bien construido; por eso los embeds serios van sin dependencias por diseño, no por preferencia. Lo pequeño es una funcionalidad que las puntuaciones Lighthouse de tus clientes pueden ver.

Cero suposiciones sobre la página anfitriona

Ni sistema de módulos, ni línea base de navegadores modernos, ni garantía de que la página no esté ya cargando una librería en conflicto, un reset de CSS demasiado entusiasta o una segunda copia de tu propio script. Todo corre en su propio ámbito, toca el espacio de nombres global una vez como mucho y se degrada en silencio en lugar de romper el checkout de otro.

Defensivo por diseño

La página en la que corre tu código puede estar instrumentada, parcheada o emulada a su alrededor: en nuestro trabajo de detección de bots, derrotar la medición es el trabajo entero del adversario. Incluso en embeds más amistosos la lección se sostiene: leer las APIs del navegador directamente, verificar en lugar de confiar en el entorno y mantener todo juicio en el servidor, donde la lógica no es visible para la página.

Un versionado que no puedes forzar

Tus clientes pegan el snippet una vez y no lo vuelven a tocar. Esa única línea tiene que seguir siendo un loader estable mientras todo lo que hay detrás evoluciona: despliegues por etapas, un contrato irrompible entre loader y payload y compatibilidad mantenida durante años, porque «por favor, actualiza tu código de embed» es un correo que nadie responde.

El consentimiento y la privacidad como arquitectura

Un script de terceros es un tercero: el se aplica en cada sitio que lo instala. Qué recoge el script, cuándo puede ejecutarse respecto al estado de consentimiento de la página anfitriona y qué cruza el cable son decisiones de diseño que hacemos explícitas desde el principio, para que tu embed sea algo que las propias revisiones de cumplimiento de tus clientes puedan aprobar en vez de señalar.

Cómo trabajamos

Proyecto de alcance cerrado. Snippet, loader, ingesta y el pipeline de despliegue que los versiona con seguridad, acotados y entregados como un solo sistema.

Ampliación de equipo. Nuestros ingenieros se suman al equipo dueño de tu plataforma: mira ampliación de equipo.

En cualquiera de los dos casos, enviamos un presupuesto detallado en un plazo de dos días laborables desde que entendemos los requisitos.

Cuánto cuesta un widget embebible

El snippet es pequeño; el sistema, no. Un embed se presupuesta desde los mismos niveles publicados que la página de desarrollo web: el recolector o widget junto con su loader y una ingesta esbelta entra en el nivel de aplicación web, en 12.000-32.000 €; cuando la plataforma que hay detrás soporta escala real —scoring, analítica, cuadros de mando para clientes—, el sistema se presupuesta como trabajo de nivel SaaS a partir de desde 40.000 €.

Son las mismas claves que renderizan la tabla de precios del pilar, así que las dos no pueden divergir. Lo que mueve la cifra: lo hostiles que sean los entornos a los que tu script debe sobrevivir, cuánto tráfico sumen las páginas de tus clientes y cuánta plataforma receptora existe ya.

Preguntas frecuentes

Dudas habituales de los equipos que envían código a páginas de otros.

Porque el runtime del framework sería más grande que el widget entero, y porque la página anfitriona puede estar ya ejecutando otra versión del mismo framework, o un entorno global que pelea con el tuyo. Un embed que se envía a cada visitante de cada cliente se mide contra el presupuesto de rendimiento de cada cliente, así que los scripts embebidos serios son JavaScript puro sin dependencias por diseño. El sitio propio de tu producto puede cargar tantos frameworks como quiera: el código que viaja debe ser autocontenido.
No asumiendo nada y no tocando nada. Todo corre dentro de su propio ámbito, el espacio de nombres global se toca una vez como mucho, los estilos van aislados para que el CSS de la página anfitriona no pueda filtrarse hacia dentro ni hacia fuera y cada ruta de fallo se degrada en silencio: un widget roto no debe tumbar jamás el checkout de un cliente. Construimos contra condiciones de página hostil desde el principio, porque el recolector que operamos corre junto a lo que sea que carguen miles de sitios sin relación entre sí.
La línea pegada nunca es el producto: es un loader diminuto y estable que descarga el payload vigente. El contrato entre loader y payload es la única interfaz que no puede romperse jamás, y todo lo demás puede entonces evolucionar: despliegues por etapas primero a una fracción del tráfico, payloads versionados y una vuelta atrás instantánea cuando una release de navegador te sorprende. Diseñar bien esa costura el primer día es lo que convierte «por favor, actualiza tu código de embed» en un correo que nunca tienes que enviar.
Un script de terceros es un tercero a efectos del RGPD en cada sitio que lo instala, así que diseñamos para el consentimiento desde el principio. Hacemos explícito qué recoge el script, si algo de ello identifica a una persona y cómo se comporta respecto al estado de consentimiento de la página anfitriona, incluido un modo sin consentimiento cuando es lo que exige el cumplimiento. El objetivo es un embed que las propias revisiones de privacidad de tus clientes puedan aprobar sin una reunión.
Sí, y preferimos construir ambos lados antes que cualquiera de los dos por separado. Un embed con éxito multiplica su tráfico por cada cliente que lo instala, así que la ingesta tiene que diseñarse para el volumen agregado desde el principio: la plataforma detrás de nuestro recolector puntúa decenas de miles de peticiones por minuto en tiempo real, sobre servicios en Go que construimos de principio a fin. El snippet y su backend son un solo sistema, y los modos de fallo viven en su costura.
Un widget o recolector con su loader y una ingesta esbelta suele costar entre 15.000 y 40.000 dólares en un plazo de uno a tres meses, el nivel publicado de aplicación web de nuestra página de desarrollo web. Cuando la plataforma receptora es el producto de verdad —scoring en tiempo real, analítica, cuadros de mando de cara al cliente—, el sistema se presupuesta como trabajo de nivel SaaS a partir de 50.000. El snippet en sí rara vez es la parte cara; lo es el volumen que genera.

Lee cómo encaja el recolector en el sistema completo en el caso de estudio de detección de bots, mira los servicios en Go que hay detrás o empieza por el pilar de desarrollo web.