Analítica y rendimiento

La primera pregunta que me hice al dar forma a la superficie de analítica: qué cambia cuando los datos de visitantes y los datos de conversión viven en la misma base de datos, detrás del mismo muro de autenticación. La respuesta resulta ser el tipo de pregunta que el comprador puede hacer. Con el stack estándar, un comprador puede preguntar 'cuál fue mi tasa de rebote la semana pasada'. Eso es lo que las plataformas de analítica de terceros hacen bien, y es lo que venden. Lo que un comprador no puede preguntar es 'de los prospectos que se convirtieron en negocios el trimestre pasado, de qué fuente de marketing vinieron, y cuál fue la mediana de tiempo entre la primera visita y el cierre'. Esa segunda pregunta exige unir dos sistemas que el contrato de SaaS no le permite unir, y la reconciliación de exportaciones que pretende resolverlo nunca termina de cuadrar entre herramientas. La tasa de rebote es un indicador; la unión entre fuente y negocio es una pregunta sobre si el marketing realmente funcionó. El comprador que intenta decidir dónde gastar su siguiente dólar necesita la segunda respuesta, y el stack estándar no puede dársela. Consideré el stack estándar: un SDK de analítica de terceros en el front end, el CRM accedido por su API pública, un puente de webhooks entre los dos, una herramienta de atribución encima del puente para hacer las uniones entre fuente y negocio, y un tablero encima de la herramienta de atribución para dibujar esas uniones. Cinco productos en el camino, cuatro contratos que el comprador paga, tres integraciones que tienen que mantenerse sincronizadas. Rechacé ese stack por la misma razón por la que rechazo casi todas las soluciones de múltiples proveedores: cada capa le renta al comprador el acceso a sus propios datos, y el puente es lo primero que se rompe. Cuando un proveedor cambia su API, cuando se retira un plan de precios, cuando compran un producto y la integración deja de mantenerse, el puente se rompe y la vista que el comprador tiene de su propio embudo se apaga hasta que alguien la reconstruya. El costo se acumula entre proveedores. Los datos se fragmentan entre centros de datos. Los números de una herramienta no coinciden con los de la otra. El camino de Canopy es estructuralmente más simple y más invasivo que el stack estándar. Tanto la captura de visitantes como la captura de conversiones comparten el mismo destino: una tabla dentro de la base de datos del propio comprador, escrita por rutas dentro del despliegue del propio comprador. Cada evento vive ahí: la primera llegada del visitante, las páginas que vio, los clics que cruzaron el límite de conversión, los envíos de formulario, los reportes de escaneo, los negocios creados a partir de esos registros, todo en la misma base de datos. No hay un SDK cargado desde una CDN ajena; el script de captura se sirve desde el dominio del propio comprador. No hay cookie de rastreo de terceros; el identificador es una cookie propia, limitada al sitio del comprador. No hay envío de eventos a un centro de datos externo; los eventos van por POST a una ruta dentro del despliegue del comprador que los escribe directo en su base de datos. La presión de bots se separa de los visitantes reales en la capa de ingesta. Esta es la parte que la mayoría de los tableros de analítica o sobrecuentan, inflando números de vanidad que hacen sentir bien al comprador y empeoran sus decisiones, o subcuentan, escondiendo una señal real sobre atención de scrapers o sobre el costo que esos scrapers generan. Canopy clasifica el tráfico en el momento de la captura, combinando coincidencia de user-agent, huella de comportamiento y una lista de infraestructura de automatización conocida. La clasificación se escribe en la misma fila que el evento, así que los números principales del tablero reflejan clientes potenciales reales mientras la presión de bots queda visible en los datos de abajo cuando el comprador quiera mirarla. Ambos números son honestos; simplemente aparecen en lugares distintos. El comprador que intenta tomar una decisión de marketing ve los números de tráfico humano; el que está depurando un pico de costo inusual o una tasa de rebote extraña puede bajar a la vista de bots en el mismo tablero. Los Web Vitals de usuarios reales se capturan desde el propio sitio del comprador y se envían a la misma base de datos. Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, Time to First Byte, First Contentful Paint, todos medidos en cada sesión real y guardados como filas de eventos. El tablero dibuja las distribuciones por percentil, el desglose por página y la línea de tiempo de regresiones frente a los despliegues. Cuando aparece una regresión después de un despliegue, el comprador puede responder 'esto es real o es solo presión de bots' contra la misma base de datos que guarda el pipeline. También puede responder 'esta regresión está dañando la conversión' en el mismo tablero, con los mismos números y detrás del mismo muro de autenticación. Sin cambiar de pestaña. Sin una junta trimestral para decidir de quién son los números correctos. La información de búsqueda entra a la misma base de datos por una ingesta diaria desde la propiedad de Search Console del comprador. Impresiones, clics, posición promedio y las consultas por las que aparece el sitio, todo atribuido a las páginas donde aterrizó la gente. Los datos de consultas se unen a los de visitantes por la página de aterrizaje, y los de aterrizaje se unen a los de negocios por la atribución normal del embudo. El comprador puede preguntar 'qué consultas produjeron visitantes que terminaron en negocios' en una sola pregunta de SQL, porque todas las filas viven en la misma base de datos. La respuesta está al mismo nivel de confianza que el resto de la analítica, es decir, el comprador puede auditarla, consultarla, modificarla y replicarla. La exclusión honesta: Canopy no está hecho para sistemas con miles de millones de eventos al día. La arquitectura asume que el comprador maneja de miles a decenas de miles de eventos diarios, donde la propiedad arquitectónica importa más que la escala horizontal. En el extremo alto de volumen, la respuesta correcta es un pipeline de eventos dedicado, una capa de agregación en streaming, una base de datos analítica optimizada para consultas OLAP y un equipo aparte para operarla; eso es otro producto y otro precio. El intercambio que Canopy acepta es el que le sirve a un negocio pequeño con ingresos, datos de conversión y ganas de hacer preguntas precisas sobre qué está produciendo esos ingresos. No es el intercambio correcto para un SaaS de consumo de alto volumen. Una segunda exclusión honesta: la postura de privacidad es de datos propios y nada más, por diseño. No hay cookie de rastreo de terceros, no hay identificador entre sitios, no hay grafo de identidad compartido con otras instalaciones de Canopy ni con el estudio. Los datos de visitantes de cada instalación se quedan en la base de datos de esa instalación. Las direcciones IP en crudo no se guardan; sí se guarda la geolocalización derivada de la IP en el momento de la captura, pero la IP se descarta después de esa derivación. Esta postura es en parte por defensibilidad frente a la regulación de privacidad, en parte por no sorprender al comprador cuando revise qué hay en su base de datos, y en parte porque no necesito identidad entre sitios para responder las preguntas que Canopy existe para responder. El tablero lee de vistas ya agregadas y no de las tablas de eventos en crudo en cada render. Las agregaciones se refrescan en un calendario que corresponde a qué tan fresca necesita ser cada tipo de pregunta: conteos de visitantes cada pocos minutos, percentiles de Web Vitals cada hora, uniones de fuente a negocio durante la noche. El tablero sigue siendo rápido conforme crecen los datos de abajo, porque las vistas agregadas crecen mucho más despacio que las tablas de eventos. La base de datos del comprador no tiene que ser infinitamente rápida en consultas OLAP; los caminos de lectura del tablero están diseñados asumiendo que la base de datos es normal y buena, no de grado analítico, que es la suposición correcta para este nivel de precio. La consecuencia operativa es la que la arquitectura persigue: cuando aparece una regresión después de un despliegue, el comprador puede responder 'esto es real o es solo presión de bots' contra la misma base de datos que guarda el pipeline, en el mismo tablero donde revisa sus negocios y detrás del mismo muro de autenticación. La pregunta de marketing, la de rendimiento y la de conversión se responden con los mismos números en el mismo lugar. No hay una conversación trimestral sobre cuál tasa de rebote es la buena, porque solo hay una herramienta. No hay integración que se rompa, porque no hay integración. Los datos son del comprador, y las preguntas que esos datos pueden responder solo están limitadas por el SQL que el comprador esté dispuesto a escribir.