BigQuery es el almacén de datos de Google, y a una pyme le sirve por tres razones: una sola fuente de verdad para todas las cifras, el histórico de GA4 guardado sin depender de su retención y el cruce de las visitas con la tienda y el CRM. Se paga por lo que guardas y por lo que consultas.
Este artículo es para quien tiene GA4, una tienda o un CRM y cada mes junta las cifras a mano, y para quien ha oído hablar de BigQuery y cree que es cosa de empresas grandes. Vas a encontrar qué es, por qué compensa, cómo se activa la exportación de GA4, cómo se factura y qué no hacer.
Es la base de los paneles de Power BI y BigQuery para marketing que montamos, y la parte que nadie ve. El panel es lo visible; las definiciones, el histórico y los cruces viven debajo.
¿Qué es BigQuery, explicado sin jerga?
BigQuery es una base de datos de Google Cloud pensada para analizar: cargas tablas, las consultas con SQL y no administras ningún servidor. Los datos se organizan en proyectos, conjuntos de datos y tablas, y se guardan por columnas, de modo que una consulta solo lee las columnas que nombra. Esa forma de guardar explica también cómo se factura.
La diferencia con una hoja de cálculo es de escala y de disciplina. Una hoja sirve mientras los datos caben en una pestaña y los toca una persona. BigQuery sirve cuando hay varias fuentes que se cargan solas cada día y varias personas que tienen que ver la misma cifra.
No sustituye a la base de datos de tu tienda ni a tu ERP, que guardan operaciones una a una: lee de ellas y agrega.
La duda de una pyme suele ser otra: si tiene sentido un almacén de datos para treinta pedidos al mes. El tamaño de la empresa importa menos que el número de fuentes que hay que cruzar para responder a una pregunta.
¿Por qué unir los datos en BigQuery aunque seas pequeño?
Porque los problemas que resuelve no dependen del tamaño. Con dos personas en marketing ya hay dos cifras distintas de ventas del mes, GA4 ya borra detalle cuando vence su plazo de retención y saber qué canal trae clientes que repiten ya exige la tienda y el CRM a la vez. BigQuery responde a las tres desde un mismo sitio.
La primera razón es la fuente de verdad. Qué es un cliente, cuándo cuenta un pedido, qué lead es cualificado: se escribe una vez en una vista de SQL, y el panel y el informe mensual leen de esa vista. Cuando alguien pregunta por qué no cuadran dos cifras, la respuesta está en una consulta, no en una discusión.
La segunda es el histórico. GA4 aplica a las exploraciones un plazo de retención de datos de usuario y de evento, y lo que vence no vuelve. Con la exportación a BigQuery, los eventos en bruto quedan en un conjunto de datos tuyo, y Google lo dice sin rodeos: cuando exportas a BigQuery, esos datos son tuyos y decides cuánto tiempo se quedan.
La tercera es el cruce. GA4 sabe de dónde llegó la visita, pero no si ese cliente repite; la tienda sabe los pedidos, pero no el origen; el CRM sabe qué presupuesto se cerró. Se unen por una clave común: el transaction_id del evento de compra de GA4 con el número de pedido de la tienda, o el identificador de campaña guardado en un campo oculto del formulario con la ficha del CRM.
En nuestra tienda Shopify de dropshipping, que vende en cinco países sin stock propio, la pregunta útil es qué país deja margen después de envíos y anuncios. Esa cifra no está en Shopify ni en Google Ads por separado. Cómo se enseña en una pantalla está en dashboard para ecommerce.
| Razón | Sin BigQuery | Con BigQuery |
|---|---|---|
| Una fuente de verdad | Cada herramienta cuenta a su manera y cada persona exporta la suya | Una vista con las definiciones acordadas, de la que leen todos |
| Histórico de GA4 | Las exploraciones pierden lo que vence la retención | Los eventos en bruto se quedan el tiempo que tú decidas |
| Cruce con CRM y tienda | Hojas de cálculo que se rehacen a mano cada mes | Uniones por pedido o por lead que se actualizan solas |
| Margen | Imposible de ver en una sola herramienta | Pedido, coste de producto, envío y gasto en anuncios en una tabla |
¿Cómo se exporta GA4 a BigQuery?
Con un vínculo nativo y sin programar: creas un proyecto en Google Cloud, habilitas la API de BigQuery, vinculas la propiedad desde Administrar, eliges ubicación y frecuencia, y los datos empiezan a llegar en menos de 24 horas, según la guía para configurarla. La exportación diaria no se cobra aparte: se paga lo que guardas y consultas en BigQuery.
Los pasos, en orden:
- En la consola de Google Cloud, crea un proyecto o elige uno, y en la biblioteca de APIs habilita BigQuery API. Hace falta ser editor o superior en el proyecto.
- En GA4, entra en Administrar, busca la vinculación de BigQuery dentro de los vínculos de productos, pulsa Vincular y elige el proyecto.
- Elige la ubicación de los datos. Para una empresa española, una ubicación en la Unión Europea; si el proyecto ya tiene un conjunto de datos de esa propiedad, no se puede cambiar.
- Elige qué flujos de datos exportar y qué eventos excluir.
- Elige la frecuencia: diaria, en streaming o las dos.
- Revisa la configuración y envíala.
La diaria exporta una vez al día los datos del día anterior, sin muestreo, a una tabla events_AAAAMMDD. El streaming los envía en minutos a una tabla events_intraday_AAAAMMDD, sin garantía de que estén completos, y cuesta 0,05 USD por GB, unos 600.000 eventos, según la página de la exportación a BigQuery. La misma página fija el límite de la diaria en un millón de eventos al día en propiedades estándar. Para un panel que se mira los lunes, la diaria basta.
Dos avisos de la guía de configuración. Se puede empezar en el sandbox, la versión gratuita de BigQuery, pero Google califica de pequeña su cuota de 10 GB. Y fuera del sandbox hace falta un método de pago válido: si la exportación se corta porque la tarjeta caduca, esos días no se pueden volver a exportar.
Si además activas la exportación diaria de datos de usuario, GA4 crea dos tablas más: una por identificador seudónimo y otra por ID de usuario, con campos como la fecha de la primera compra, el valor acumulado del usuario y sus audiencias. El esquema (en inglés) detalla cada campo y aclara que los usuarios sin consentimiento no entran en la tabla de identificadores seudónimos.
Hay una segunda vía documentada por Google Cloud: las transferencias (en inglés) programadas de GA4 con el servicio de transferencia de datos de BigQuery. Es un mecanismo distinto, que se configura en la consola de Google Cloud. Para un panel de pyme empiezo siempre por la exportación de eventos.
¿Cuánto cuesta BigQuery y cómo se factura?
BigQuery factura dos cosas por separado: el almacenamiento, por el volumen que guardas cada mes, y el procesamiento de consultas, por los datos que lee cada consulta en el modelo bajo demanda. La exportación a BigQuery avisa de que cada exportación genera costes de almacenamiento y de procesamiento. En una pyme, lo que más mueve la factura es cómo se consulta.
El almacenamiento se paga por volumen y mes, y las tablas que llevan tiempo sin modificarse pasan a una tarifa de largo plazo, más barata. Las tablas diarias de GA4 no se tocan una vez escritas, así que el histórico se abarata solo.
La consulta se paga por los datos que lee, no por las filas que devuelve. Como BigQuery guarda por columnas, pedir todas las columnas lee todas, y añadir LIMIT 10 no reduce lo leído. La consola enseña antes de ejecutar cuántos datos va a procesar la consulta: es el número que hay que mirar siempre.
No doy precios de almacenamiento ni de consulta porque Google los publica por región y los cambia, y hay una franja gratuita mensual que cubre parte del uso de una cuenta pequeña.
| Concepto | Qué se cobra | Qué lo dispara | Cómo se controla |
|---|---|---|---|
| Almacenamiento activo | Volumen guardado al mes | Tablas nuevas o modificadas | Borrar tablas de prueba y poner caducidad a las temporales |
| Almacenamiento a largo plazo | Volumen sin modificar desde hace tiempo, a tarifa menor | El histórico | Nada: se abarata solo |
| Consultas bajo demanda | Datos leídos por cada consulta | Todas las columnas, fechas sin acotar, paneles que releen el bruto | Columnas concretas, filtro de fechas, tablas resumen |
| Exportación en streaming | GB recibidos | Activar el streaming | Quedarte con la diaria si no miras el día en curso |
¿Qué no hay que hacer en BigQuery?
No hay que lanzar consultas sin límite de bytes ni dejar tablas sin particionar: son las dos formas de que una factura pequeña deje de serlo. Tampoco conviene conectar el panel a las tablas en bruto de GA4, dar acceso al conjunto de datos a todo el equipo ni cargar datos personales que ninguna pregunta necesita.
Una consulta sin límite es un SELECT sobre events_: todas las columnas de todos los días desde que activaste la exportación. Se evita de dos formas. En la consulta, acotando las fechas con _TABLE_SUFFIX y nombrando solo las columnas que hacen falta. En la configuración, fijando un máximo de bytes facturados por consulta y cuotas diarias por usuario o por proyecto, para que un error cueste un aviso y no una factura.
Las tablas de GA4 ya vienen separadas por día, y por eso filtrar por fecha funciona. Las tuyas no: pedidos, fichas del CRM o gasto diario de Ads se cargan en una tabla única que crece cada día. Particionarla por fecha y agruparla por canal o campaña hace que una consulta de la última semana lea la última semana. Se puede exigir además que toda consulta filtre por la partición.
Un panel conectado al bruto lanza una consulta cada vez que alguien lo abre o cambia un filtro. Lo correcto es una consulta programada que cada noche escribe una tabla resumen de la que lee el panel. Cómo encaja eso en cada herramienta está en Power BI o Looker Studio (desde abril de 2026 ha vuelto a llamarse Data Studio).
| Error | Qué pasa | Cómo se evita |
|---|---|---|
SELECT * sobre todas las tablas de eventos | Lee todas las columnas de todo el histórico en cada ejecución | Columnas concretas y _TABLE_SUFFIX acotado |
Confiar en LIMIT para ahorrar | Se lee lo mismo; solo se devuelven menos filas | Mirar la estimación de datos procesados antes de ejecutar |
| Tablas propias sin particionar | Cada consulta recorre la tabla entera | Partición por fecha, agrupación por canal y filtro de partición obligatorio |
| Panel leyendo el bruto de GA4 | Una consulta por cada apertura y cada filtro | Tabla resumen diaria con una consulta programada |
| Acceso abierto y datos personales de más | Riesgo legal sin ninguna pregunta que lo justifique | Permisos por persona y solo los campos que usa el panel |
¿Cuándo no necesita BigQuery una pyme?
Cuando solo hay una o dos fuentes y una pregunta. Una web de servicios con un formulario, GA4 y Search Console se mira bien con los informes de GA4 o con Looker Studio conectado directamente. BigQuery empieza a compensar con la tercera fuente, cuando la pregunta es de margen o cuando quieres guardar el histórico de GA4 por tu cuenta.
Aun así, activaría la exportación de GA4 el primer día. Unas tablas que nadie consulta apenas generan coste de procesamiento, y la exportación no trae los días anteriores a activarla. Si dentro de un año quieres comparar, ese año tiene que estar ya guardado.
Y el recorrido completo, de la medición al panel, en la guía de datos y dashboards para marketing.
Nuestro proyecto con BigQuery como fuente única, atribución acordada y margen por producto parte de 2.900 €. Si antes quieres saber si tu medición sirve, la auditoría parte de 490 €.
Hay más sobre esto en la sección de datos para decidir del blog.
Preguntas frecuentes
¿BigQuery es gratis para una pyme?
En parte. Hay un sandbox gratuito con límites y una franja gratuita mensual de almacenamiento y de consulta; por encima, se paga por volumen guardado y por datos consultados. La exportación diaria de GA4 no se cobra aparte; la de streaming, sí.
¿Hace falta saber SQL para usar BigQuery?
Para montar y mantener las tablas, sí, o alguien que lo sepa. Para mirar el panel, no: Power BI y Looker Studio leen las tablas ya preparadas.
¿Puedo cargar en BigQuery los datos de GA4 de antes de activar la exportación?
No con la exportación nativa: se llena desde el día en que vinculas la propiedad. Por eso conviene activarla cuanto antes, aunque todavía no vayas a usar los datos.
¿Dónde se guardan los datos y qué pasa con el RGPD?
En la ubicación que elijas al vincular, que no se puede cambiar después para ese conjunto de datos. Para una empresa española, lo coherente es una ubicación en la Unión Europea, con acceso limitado a quien lo necesita y sin cargar datos personales que ninguna pregunta use.
—
Juan Martínez es el fundador de We Love SEO, en Zaragoza, ingeniero y data scientist. Monta paneles de datos para marketing con GA4, BigQuery, Power BI y Data Studio (antes Looker Studio). Más en el equipo.
