En este paso instalas el SDK web (y móvil si aplica), configuras los eventos que alimentan el perfil 360 y subes el catálogo de productos. El criterio de salida es uno solo: cada evento crítico validado contra la realidad — una compra de prueba que aparece en el panel con el monto, los ítems y la identidad correctos. Sin ese QA, todo lo que actives después estará construido sobre arena.
El snippet web: dónde y cómo
El SDK web de Insider es un snippet JavaScript que va en el head de todas las páginas. Dos decisiones prácticas:
- ¿Google Tag Manager o hardcodeado? GTM te da agilidad (marketing puede actualizar sin release) pero agrega un intermediario que a veces carga tarde. Para personalización on-site el timing importa: un banner que aparece 2 segundos tarde parpadea y molesta. Nuestra práctica: hardcodear el snippet base en el template y dejar en GTM solo lo accesorio.
- Performance. El SDK carga asíncrono y pesa poco, pero mide igual: corre una comparación antes/después en tus métricas de velocidad. Si tu sitio ya está pesado, este es el empujón para limpiarlo — la personalización amplifica lo que hay, incluida la lentitud.
Si tienes app, el SDK móvil (iOS/Android) se instala en paralelo con el equipo de desarrollo: habilita push, in-app y el tracking de comportamiento dentro de la app. Coordinalo con el ciclo de releases — en LATAM, donde muchos equipos publican app cada 4-6 semanas, este suele ser el camino crítico del cronograma.
Eventos: estándar primero, custom después
Insider trae eventos estándar para ecommerce: vista de página, vista de producto, agregar al carrito, inicio de checkout, compra. Implementalos todos y con el payload completo (ID de producto, precio, moneda, cantidad). Después, y solo si un caso de uso lo pide, agrega eventos custom: "usó el buscador", "vio sucursales", "simuló crédito" — este último es oro en banca digital.
La trampa habitual: los eventos estándar mal poblados. Una "compra" sin ítems sirve para contar, no para recomendar. El plan de datos del paso 2 define qué debe llevar cada evento; acá se implementa tal cual, sin atajos.
Campañas brillantes sobre eventos rotos producen basura personalizada. El QA de datos no es burocracia: es el producto.
El catálogo: el insumo de las recomendaciones
El motor de recomendaciones del paso 4 es tan bueno como tu feed. Requisitos mínimos por producto: ID único (el mismo que reportan los eventos — si difieren, nada matchea), nombre, precio actual y de lista, stock, categoría jerárquica, URL e imagen. Súmale los atributos que tu negocio usa para filtrar: talla, marca, color.
Tres cuidados típicos de la región:
- Moneda y formato. Si vendes en varios países (pesos, colones, reales), define moneda por feed o campo de moneda explícito. Un precio "1.500" ambiguo rompe la confianza del que recibe la recomendación.
- Stock fresco. Actualiza el feed al menos cada pocas horas. Recomendar agotados es la forma más rápida de entrenar a tus usuarios a ignorar las recomendaciones.
- Imágenes reales. Un feed con 30% de imágenes placeholder produce widgets feos. Auditalo antes de subirlo, no después de la primera campaña.
Consentimiento y QA final
Conecta el SDK con tu gestor de consentimiento: el tracking se activa según la preferencia del usuario, y el opt-out se respeta en todos los canales. Con eso resuelto, corre el QA completo con una matriz simple: cada evento crítico × cada plataforma (desktop, móvil web, app) × un usuario identificado y uno anónimo. Documenta el resultado. Una tarde de pruebas ahora ahorra semanas de "¿por qué este journey no dispara?" después.
Errores comunes en este paso
- IDs de producto inconsistentes. El evento reporta "SKU-123" y el catálogo dice "123". Nada matchea y las recomendaciones salen genéricas. Es el bug número uno que encontramos en rescates.
- Instalar solo en el home y las PDP. El SDK va en TODAS las páginas: el comportamiento en checkout, búsqueda y contenido también alimenta el perfil.
- Saltarse el QA de la compra. Es el evento más importante y el que más se rompe (pasarelas, redirecciones, páginas de gracias). Probalo con una compra real de punta a punta.
- Feed de catálogo "para salir del paso". Sin stock ni categorías, el motor recomienda a ciegas. El feed pobre no se nota en la instalación: se nota en los resultados del paso 4.
Checklist antes de pasar al siguiente
- Snippet activo en todas las plantillas del sitio (y SDK en app, si aplica).
- Eventos estándar completos, validados con compra de prueba real.
- IDs de producto idénticos entre eventos y catálogo.
- Feed de catálogo con precio, stock, categoría e imagen, actualizándose solo.
- Consentimiento integrado y opt-out verificado.
- Matriz de QA documentada y firmada por el dueño del proyecto.
Con el dato fluyendo limpio, llega lo divertido: Paso 4 · Personalización on-site y recomendaciones con IA. ¿Perdiste el hilo? Vuelve a la guía completa.