Todo lo que construimos realmente cuando una empresa dice que quiere usar Google correctamente: la arquitectura de datos GCP completa, recolección limpia de GA4, pipelines de BigQuery, Looker y Looker Studio para el reporting, administración de Workspace, automatizaciones de Apps Script, topología de Pub/Sub, identidad y seguridad, y cómo todo se conecta al resto del stack. Sin generalidades, sin pitch comercial. Solo la mecánica y el orden en que trabajamos.
Esta guía es larga porque el tema es amplio. Google Cloud por sí solo abarca docenas de servicios, y Google Workspace es una plataforma completa de productividad e identidad encima de eso. La mayoría de los equipos usa una fracción de lo que tienen disponible, a menudo de forma deficiente. Lo que sigue es un relato preciso de cómo pensamos en el stack, a qué partes acudir primero y cómo cada capa se conecta con la siguiente. Léela de principio a fin y entenderás cómo abordamos un trabajo antes de que hablemos.
Google Cloud Platform no es un producto único. Tiene unos doscientos servicios, la mayoría de los cuales nunca necesitarás. Los cuatro que más importan a una empresa en crecimiento son BigQuery (tu data warehouse), Cloud Run (cargas de trabajo en contenedores sin gestión de servidores), Cloud Functions (código pequeño activado por eventos) y Pub/Sub (la capa de mensajería que une todo). El resto o se construye sobre estos o es una necesidad especializada que sabrás que tienes cuando llegues a ella.
Google Workspace está aparte pero se conecta. Es tu email, calendario, documentos y proveedor de identidad, y para muchos equipos es el lugar donde realmente ocurren las decisiones, incluso cuando esas decisiones están técnicamente impulsadas por datos que se encuentran en otros sistemas. La oportunidad de integración no es solo conectar Workspace a Cloud; es hacer inteligentes las herramientas que la gente ya usa.
El problema más común que vemos en el momento de la auditoría no es que se eligieron las herramientas equivocadas. Es que las herramientas correctas se adoptaron una a una, sin un modelo de datos que las conecte, de modo que la empresa tiene GA4, BigQuery, un CRM, una plataforma publicitaria y una base de datos de producto que nunca han hablado entre sí. La auditoría existe para encontrar esas brechas antes de que empiece el build.
El modelo mental correcto para un stack de datos GCP es un embudo: los datos en bruto de muchas fuentes llegan a un único warehouse, las transformaciones se ejecutan dentro del warehouse y las herramientas de reporting leen de él. BigQuery es el warehouse. Maneja petabytes, ejecuta SQL en segundos y tiene conectores nativos con todos los demás servicios de GCP. Elegirlo como capa central es la decisión que permite que todo lo demás se componga de forma limpia.
La decisión más importante en la arquitectura de datos es el schema. BigQuery es barato de almacenar y rápido de consultar, pero si el schema es un volcado directo de las tablas de aplicación se vuelve imposible de consultar para alguien que no lo construyó. Diseñamos los schemas en torno a las preguntas que el negocio realmente hace: ingresos por canal por día, conversión del funnel por cohorte, churn por tier de producto. Las tablas son intencionalmente amplias y las transformaciones están escritas en SQL estándar que tu equipo puede leer y verificar.
ELT significa extract, load, transform. Los datos llegan en bruto a BigQuery primero, luego las transformaciones se ejecutan dentro del warehouse usando SQL o una herramienta como dbt. Es lo contrario del patrón ETL más antiguo donde se transformaba antes de cargar, y es mejor por dos razones: los datos en bruto siempre están ahí si necesitas reprocesarlos, y BigQuery es más rápido y barato ejecutando transformaciones que cualquier servicio externo.
El trabajo práctico de construir un pipeline ELT tiene cuatro fases. Primero, inventariar las fuentes: qué datos existen, dónde viven, cómo se accede a ellos (API, webhook, exportación de archivo, réplica de base de datos) y con qué latencia los necesitas. Segundo, diseñar el schema en bruto para preservar fielmente la estructura fuente, incluyendo campos que actualmente no usas. Tercero, construir la capa de extracción gestionando correctamente autenticación, paginación y rate limiting. Cuarto, escribir las transformaciones que producen las tablas orientadas al negocio.
Los pipelines que construimos con más frecuencia conectan Salesforce o HubSpot (via API REST con cargas incrementales), Google Ads y Meta Ads (via sus respectivas API), Stripe (via webhooks en Pub/Sub) y la base de datos de producto (via réplica de lectura o un conector Fivetran o Airbyte si ya está en uso). Cada uno se ejecuta de forma independiente, así que un fallo en una fuente no rompe las demás, y cada uno está monitorizado con alertas sobre el timestamp de última actualización de la tabla en bruto.
GA4 es la plataforma de analítica adecuada para la mayoría de las empresas en crecimiento, pero la configuración client-side predeterminada tiene un problema estructural: el código de medición se ejecuta en el navegador del usuario, lo que significa que los bloqueadores de anuncios, el Intelligent Tracking Prevention de iOS y los banners de consentimiento de cookies erosionan tus datos antes de que lleguen a Google. Los estudios en propiedades típicas de e-commerce y SaaS muestran constantemente que el 20-40 por ciento de las sesiones no se rastrea con una configuración solo del lado del cliente.
El etiquetado server-side lo soluciona moviendo el endpoint de recolección a un contenedor que tú controlas, ejecutándose en Cloud Run. El navegador envía eventos a tu propio dominio, no directamente a Google. Tu contenedor server-side los reenvía a GA4 y cualquier otro destino (Google Ads, Meta, webhooks de CRM). Los beneficios son concretos: mejor completitud de datos, cookies de primera parte que sobreviven a ITP y ningún dato personal que salga de tu infraestructura antes de que hayas tenido oportunidad de anonimizarlo o eliminarlo.
La configuración tiene tres partes: un web container de Google Tag Manager que dispara a tu endpoint sGTM en lugar de directamente a GA4, un contenedor GTM server-side alojado en Cloud Run con auto-scaling configurado y las etiquetas de GA4 y publicidad reconstruidas en el lado del servidor con el mapeo de variables correcto. La configuración de Cloud Run necesita un subdominio personalizado que apunte a él para que las cookies que establece sean de primera parte; sin eso, el beneficio ITP desaparece.
También conectamos la exportación BigQuery de GA4. Cada evento que GA4 registra se transmite diariamente (o en tiempo real en el tier 360) a un dataset de BigQuery. Esa tabla de eventos en bruto es la base del trabajo de analítica: puedes consultarla con SQL, unirla a tu base de datos de producto y construir embudos personalizados que la propia interfaz de GA4 no soporta. Es una de las pocas integraciones gratuitas en el stack de Google que reporta beneficios de inmediato.
Looker Studio (antes Data Studio) es la herramienta adecuada para la mayoría de las necesidades de reporting. Se conecta directamente a BigQuery, se actualiza según un schedule y produce paneles que los equipos no técnicos pueden leer y compartir sin tocar SQL. La clave para una configuración de Looker Studio que realmente se use es conectarla a tablas de BigQuery limpias y bien nombradas en lugar de datos fuente en bruto, de modo que las métricas sean consistentes en todos los informes.
Looker (el producto enterprise completo, ahora parte de Google Cloud) añade una capa semántica: un conjunto de definiciones de métricas que se sitúa entre los datos y las herramientas de reporting, asegurando que “ingresos” signifique lo mismo tanto si lo consultas en Looker, desde un notebook de Python o via API REST. Para equipos donde las definiciones de métricas consistentes a través de varias herramientas es un problema real, la capa semántica vale la inversión. Para equipos en una etapa anterior, Looker Studio directamente sobre BigQuery es más rápido de desplegar y más barato de operar.
Los paneles que construimos siguen un patrón consistente: una vista ejecutiva única que cubre los cuatro o cinco números que realmente impulsan las decisiones (ingresos, pipeline, activación, churn, eficiencia del gasto) y un panel operativo por equipo (embudo de marketing por canal, activación de producto por cohorte, salud del cliente por tier). Cada gráfico tiene una consulta SQL que puedes leer y cada métrica tiene una definición escrita que aparece al pasar el ratón. El objetivo es que cualquiera que mire el panel pueda entender lo que está viendo sin preguntar al analista que lo construyó.
Pub/Sub es el backbone de mensajería que hace a GCP composable. En lugar de que los servicios se llamen directamente entre sí, un productor publica un evento en un topic y cualquier número de suscriptores actúa sobre él de forma independiente. Un nuevo cliente se registra en tu producto: un suscriptor carga el evento a BigQuery, otro dispara una secuencia de bienvenida en tu CRM, un tercero actualiza un contador en un panel de Sheets. Ninguno sabe de los demás, y si uno falla, reintenta sin afectar a los otros.
Usamos Pub/Sub para tres categorías de eventos. La primera son los disparadores para pipelines de datos: un webhook de Stripe o un evento de producto genera un mensaje Pub/Sub que activa la Cloud Function que lo carga a BigQuery. La segunda son las sincronizaciones entre sistemas: un deal cerrado en el CRM publica un evento que activa una tarea de Customer Success, una actualización de Looker Studio y un borrador de factura, todo a la vez, ninguno bloqueando a los demás. La tercera son el monitoreo y las alertas: una consulta programada de BigQuery publica en un topic cuando una métrica clave cruza un umbral y un suscriptor enruta la alerta a Slack o email.
Workspace suele ser lo último en lo que piensa una empresa en crecimiento hasta que se convierte en un problema: una cuenta de usuario que no se desactivó cuando alguien se fue, una unidad compartida sin propietario con tres mil archivos que nadie puede encontrar, una alerta de seguridad que saltó hace meses y que nadie vio. Una buena administración de Workspace no es glamorosa, pero es la base sobre la que se asienta todo lo demás del stack de Google, porque Workspace es el proveedor de identidad.
El trabajo de administración que realizamos cubre cinco áreas. Gestión del ciclo de vida de usuarios: aprovisionamiento de nuevas cuentas con los grupos y permisos correctos desde el primer día, y desaprovisionamiento completo de quienes se van incluyendo la revocación de tokens OAuth de terceros. Gobierno de unidades compartidas: auditar quién posee qué, aplicar políticas de retención y eliminación y mover contenido huérfano a ubicaciones gestionadas. Línea base de seguridad: aplicar la autenticación de dos factores en toda la organización, revisar el inventario de cuentas de administrador y configurar el Security Investigation Tool para detectar actividad inusual. Gestión de licencias: ajustar los niveles de licencia al uso real para no pagar por funcionalidades que nadie usa. Configuración de cumplimiento: establecer regiones de datos, configurar Vault para retención legal si hace falta y revisar los permisos de aplicaciones de terceros.
La auditoría pone de manifiesto todo esto. La mayoría de las organizaciones con las que trabajamos tiene al menos dos o tres cuentas que deberían haberse desactivado pero no se hicieron, al menos una cuenta de administrador que no tiene autenticación de dos factores y al menos una docena de autorizaciones de aplicaciones de terceros que nadie recuerda haber aprobado.
Apps Script es la capa de automatización integrada de Google para Workspace. Ejecuta JavaScript en la infraestructura de Google, tiene acceso directo a Sheets, Docs, Drive, Gmail, Calendar y Forms sin sobrecarga de autenticación y puede llamar a API externas. No es un entorno de programación de propósito general, pero para la categoría específica de automatizar flujos de Workspace es más rápido y más barato de construir que cualquier herramienta externa.
Las automatizaciones que más frecuentemente construimos con Apps Script caen en cuatro grupos. Procesamiento de formularios: un Google Form recoge datos, el script los valida, escribe una fila en una Sheet, envía emails de confirmación, crea invitaciones de Calendar y opcionalmente publica en Slack o un CRM. Generación de documentos: un script lee datos de una Sheet o BigQuery, rellena una plantilla de Docs y guarda el output en una carpeta de Drive con nombre, reemplazando un proceso que antes le llevaba una tarde a alguien. Flujos de aprobación: un script enruta una fila de Sheet a través de una cadena de aprobación por email, actualizando el estado a medida que cada aprobador actúa. Sincronizaciones de datos: scripts programados ligeros que envían datos de Sheets a una API externa o los traen de vuelta, para sistemas donde un pipeline completo sería excesivo.
La identidad es el único área donde un error es difícil de recuperar. Un rol IAM mal configurado que concede a una cuenta de servicio acceso de project-owner, una cuenta de administrador de Workspace sin autenticación de dos factores o un token OAuth dejado en la cuenta de un empleado que se fue son todas superficies de ataque que se agravan con el tiempo. Tratamos la identidad y el IAM como un entregable de primera clase, no como un afterthought.
En el lado de GCP, el principio de mínimo privilegio es la regla. Cada cuenta de servicio obtiene exactamente los permisos que necesita para los recursos específicos que toca, escritos como un rol IAM personalizado, no un rol predefinido a nivel de proyecto. Las claves de cuenta de servicio no se usan donde Workload Identity Federation o el servicio de metadatos pueden proporcionar credenciales en su lugar; las claves que no pueden evitarse se rotan según un schedule. El acceso a los datasets de BigQuery se controla a nivel de dataset y tabla, no a nivel de proyecto, de modo que un desarrollador puede consultar las tablas limpias sin tocar datos en bruto ni los datasets de otros equipos.
En el lado de Workspace, las recomendaciones de seguridad de la consola de administración son un suelo, no un techo. Más allá de aplicar la autenticación de dos factores y revisar las cuentas de administrador, configuramos políticas de acceso context-aware para cualquier aplicación de Workspace que maneja datos sensibles, revisamos y recortamos las autorizaciones OAuth de aplicaciones de terceros que se acumulan silenciosamente a lo largo de los años, y configuramos el Security Investigation Tool para alertar sobre actividad de inicio de sesión sospechosa, descargas masivas de Drive y compartición externa de documentos sensibles.
Google Cloud se conecta a sistemas externos a través de dos patrones. El primero es el pull: una Cloud Function o consulta programada llama a una API externa según un schedule, obtiene datos y los carga a BigQuery. Esto cubre la mayoría de los casos de uso de reporting: tu CRM, tus plataformas de publicidad, tu sistema de facturación. El segundo es el push: un sistema externo llama a un endpoint de Cloud (normalmente una Cloud Function detrás de una configuración de Cloud Endpoints o API Gateway, o una suscripción push de Pub/Sub) cuando algo cambia. Esto cubre los disparadores en tiempo real: un pago completado, un usuario que se activa, un deal cerrado.
Las integraciones que construimos con más frecuencia son la sincronización de CRM (Salesforce y HubSpot tienen ambos API REST bien documentadas con soporte de carga incremental), las plataformas de publicidad (Google Ads, Meta, LinkedIn tienen todas API que devuelven datos de campaña y conversión con un retraso de dos días), los procesadores de pagos (el sistema de webhooks de Stripe es fiable y su modelo de eventos se mapea limpiamente a Pub/Sub) y las bases de datos de producto (típicamente via réplica de lectura o un conector Fivetran o Airbyte si ya está en uso). Documentamos cada integración en un formato estándar: el endpoint de la API, el método de autenticación, los campos extraídos, el schedule y el comportamiento en caso de error.
Cada trabajo comienza con la auditoría gratuita, que produce una lista priorizada de qué construir y en qué orden. El build en sí es un proyecto de alcance fijo, estructurado en dos o tres fases según la complejidad del stack.
La fase uno es siempre la base: etiquetado server-side de GA4, BigQuery conectado a la exportación de GA4, línea base IAM en GCP, hardening de seguridad de Workspace. Este es el trabajo que hace que todo lo demás sea fiable. La fase dos es la capa de datos: pipelines ELT para los dos o tres sistemas fuente que más importan, el schema de BigQuery que los une y los primeros paneles de Looker Studio. La fase tres, donde hace falta, cubre la automatización: topología Pub/Sub para las integraciones event-driven, automatizaciones de Apps Script para los flujos manuales de mayor valor y administración de Workspace para equipos con necesidades significativas de gestión del ciclo de vida.
Todo lo que construimos está documentado a un nivel que permite a tu equipo ser dueño de ello tras la entrega. Cada pipeline tiene un runbook que describe qué hace, cómo se monitoriza y cómo reiniciarlo si falla. Cada panel tiene un diccionario de datos que define cada métrica. Cada automatización de Apps Script tiene comentarios inline y una Sheet de prueba que te permite activarla manualmente. El objetivo es que seis meses después de la entrega tu equipo pueda mantener y ampliar el trabajo sin volver a nosotros.
Un único punto de contacto. Tendrás una persona que es dueña del trabajo, el calendario de entrega y cualquier escalada. Las especificaciones llegan en un formato estándar con criterios de aceptación que tu equipo puede verificar. Los datasets e informes iniciales son tuyos y el código se despliega en tu propio proyecto GCP, no en el nuestro.
Esa es la arquitectura completa. Cuando quieras aplicarla a tu stack, el siguiente paso es una auditoría gratuita: una revisión real de tu entorno GCP y Workspace, los hallazgos en una semana, sin obligaciones.
Una auditoría gratuita de tu stack de Google real, los hallazgos cuantificados y un alcance fijo para construir lo que falta. Hallazgos en una semana.
Solicita una auditoría Google gratuita