La calculadora de BigQuery dice una cosa en el mes uno. Tu factura dice otra en el mes tres. La diferencia no es un bug de facturación. Es que el modelo de pricing interactúa con los datos de marketing, desde exports de CRM de HubSpot hasta filas ad-level de Meta Ads hasta event streams de GA4, de formas que ninguna calculadora predice. Datos ad-level diarios, patrones de refresh de dashboards, decisiones de esquema tomadas el día uno y un par de hábitos SQL que nadie marcó en el onboarding se combinan en una factura que sorprende a marketing ops, y después sorprende a finanzas.

Esta guía desglosa lo que BigQuery realmente cuesta a los equipos de marketing en 2026, las siete trampas de coste ocultas que golpean entre el mes dos y el cuatro, y los patrones que reducen la factura un 40 a 60 por ciento sin sacrificar reporting. Las cifras se basan en el pricing publicado actual de Google Cloud y una carga de trabajo realista de equipo de marketing (cinco plataformas pagadas, diez cuentas, dashboards refrescados a diario).

Para la decisión más amplia sobre si un cloud warehouse como BigQuery es el encaje correcto para tu equipo frente a un warehouse marketing-native, ver nuestra Guía del Data Warehouse de Marketing 2026. Este post se sitúa dentro del Camino 1 de esa guía y cubre los costes que ese camino impone.

Cómo cobra BigQuery los datos de marketing en 2026

El pricing on-demand de BigQuery tiene cuatro partes móviles. Cada una interactúa con patrones específicos de marketing de forma diferente a las cargas de trabajo OLAP genéricas. Las tarifas oficiales están en la página de precios de BigQuery; las implicaciones específicas para marketing no.

• Coste de query on-demand: $6.25 por TiB de datos escaneados, después del primer 1 TiB gratis al mes. Lo que pilla a la gente: el coste se basa en bytes escaneados, no bytes devueltos. Una query que devuelve 100 filas puede escanear 10 GiB si la tabla no está particionada.
• Almacenamiento activo: $0.02 por GiB al mes después de los primeros 10 GiB gratis. Cuenta como "activo" mientras cualquier partición de la tabla haya sido modificada en los últimos 90 días.
• Almacenamiento long-term: $0.01 por GiB al mes, un 50 por ciento de descuento que solo entra cuando una partición lleva 90 días sin tocarse. Los datos de marketing se refrescan a diario en la mayoría de particiones, así que la mayor parte de los datos nunca califica.
• Streaming inserts (Storage Write API en modo legacy): $0.01 por 200 MB ($0.05 por GiB), con un mínimo de 1 KB por fila. Y aquí es donde la mayoría de equipos de marketing acaba pagando de más: si tu conector hace streaming en lugar de batch, pagas por fila incluso cuando las filas individuales son pequeñas.

Ninguna de esas tarifas asusta por sí sola. La factura se acumula porque los datos de marketing tienen ciertas formas: alta cardinalidad a nivel ad, granularidad diaria a través de muchas cuentas, dashboards que re-escanean tablas en cada refresco, y queries construidas por analistas que muchas veces se saltan los básicos de optimización. Cada uno de los siete costes de abajo viene de esa interacción.

Los 7 costes ocultos que golpean a los equipos de marketing en el mes 3

Están ordenados por frecuencia, no por severidad. La mayoría de equipos pega con al menos tres; algunos pegan con los siete.

Coste oculto #1: Tablas ad-level sin particionar escaneadas enteras

La fuente número uno de facturas inesperadas de BigQuery para equipos de marketing. Aquí va el cálculo, con tarifas reales de 2026.

Un analista de marketing carga datos diarios ad-level de Meta Ads a través de 10 cuentas. Aproximadamente 50 anuncios activos por cuenta, 365 días de historial a nivel fila: ~180.000 filas por cuenta, ~1,8 millones de filas en total. Cada fila ~2 KB (metadata de campaña, IDs de creatividad, spend, impresiones, clics, conversiones, ventanas de atribución). La tabla pesa unos 3,5 GiB.

El analista monta un dashboard en Looker Studio con el filtro "últimos 30 días". Si la tabla no está particionada por fecha, cada vista del dashboard escanea los 3,5 GiB completos, porque Looker Studio aplica los filtros después de que BigQuery devuelve los datos.

Multiplica: 30 stakeholders abren el dashboard una media de 5 veces al día. Eso son 150 vistas, escaneando 3,5 GiB cada una = 525 GiB escaneados al día = ~15 TiB al mes. Coste: ~$87 al mes para un solo dashboard. Esto es la aritmética a partir de esos supuestos; los números reales varían según cómo Looker Studio cachea la fuente y según los filtros por defecto del dashboard.

Con particionado por fecha y clustering por ID de cuenta, esas mismas 150 vistas escanean ~50 MiB cada una (el corte de 30 días relevante). Escaneo mensual: ~225 GiB. Una vez que tus otras queries consumen el 1 TiB gratis del mes (la mayoría de equipos de marketing lo cruzan en la primera semana de cualquier mes), el coste marginal de esta carga es de aproximadamente $1,40 al mes. Una reducción del 98 por ciento sobre la misma carga.

Coste oculto #2: Tormentas de refresh de Looker Studio durante reuniones

El coste del dashboard arriba asume uso "normal". La realidad es más picuda. Las reviews de marketing tienden a agruparse: standups del lunes por la mañana, performance reviews de mitad de mes, QBRs de fin de mes. En esos días, el mismo dashboard puede acabar refrescándose 50 veces en una hora por 20 personas haciendo clic por sus pestañas.

El comportamiento por defecto de Looker Studio es re-consultar BigQuery en cada interacción a menos que el caching esté explícitamente habilitado. Sin caching, cada cambio de filtro, ajuste de rango de fechas o toggle de breakdown re-ejecuta la query. En un día de QBR un solo dashboard puede escanear 10x su volumen medio.

El arreglo no siempre es "añadir caching"; la ventana de freshness de Looker Studio puede interferir con la historia de refresh diario que esperan los marketers. El arreglo más duradero es materializar la query subyacente del dashboard como una vista scheduled que corre una vez al día y sirve los dashboards desde una tabla pre-agregada pequeña.

Coste oculto #3: Storage que compone con el histórico de campañas

Los datos de marketing componen en storage. Año uno: unos pocos GiB. Año dos: decenas de GiB. Año tres: cientos de GiB si incluyes datos a nivel creatividad, definiciones de audiencia e historial de bids.

La matemática a $0.02 por GiB al mes es modesta hasta que los volúmenes cruzan los 100 GiB. A 250 GiB cruzando todas las plataformas pagadas más el export de GA4 más sync de CRM, estás en $5 al mes de storage. A 1 TiB estás en $20. A 5 TiB (típico de agencias que llevan 30+ cuentas cliente, a menudo combinando LinkedIn Ads B2B con historial orgánico de Search Console), estás en $100 al mes.

El descuento de long-term storage (50 por ciento off después de 90 días sin tocar) suena como la respuesta, pero raramente aplica a tablas de marketing. La mayoría de equipos hacen append diario, lo que modifica la partición más reciente; si tu tooling re-inserta datos históricos en cambios de esquema o backfills, también modifica particiones más antiguas, devolviendo todo a tarifa activa. Usa INFORMATION_SCHEMA.PARTITIONS para comprobar qué particiones realmente han pasado a long-term.

Coste oculto #4: Streaming inserts cuando batch valdría

La Storage Write API y la legacy streaming API tienen un cargo por MB que las cargas batch ($0 por la carga en sí) no tienen. El streaming tiene sentido para casos de uso en tiempo real (tracking de eventos en vivo, detección de fraude). Raramente tiene sentido para datos de marketing que se actualizan en horarios de plataforma (Meta refresca ventanas de atribución cada pocas horas, no en tiempo real).

Muchos conectores de terceros vienen por defecto en streaming porque es marginalmente más fácil de implementar. A $0.05 por GiB streamed, con 5 GiB ingestados a diario a través de todas las plataformas (típico para una cuenta de tamaño medio), eso son $7,50 al mes. No suena mal. Pero el streaming también fuerza la partición destino a estado "activo" indefinidamente, bloqueando el descuento de long-term storage. El efecto combinado aterriza cerca de $15-25 al mes, escondido en dos líneas de coste.

Si tu conector te deja elegir, escoge batch load con un schedule diario u horario. El batch horario es lo bastante fresco para casi cualquier reporte de marketing que un equipo construye; los casos que genuinamente necesitan latencia sub-minuto son raros fuera del tracking de eventos en vivo.

Coste oculto #5: queries SELECT * en notebooks compartidos

Los analistas heredan hábitos de otros contextos. SELECT * es universal en Postgres, MySQL y la mayoría de desarrollo local. En BigQuery, es una decisión financiera.

BigQuery es columnar. SELECT spend, impressions FROM meta_ads sobre una tabla de 50 columnas escanea aproximadamente el 4 por ciento de los datos que SELECT * FROM meta_ads. El ratio de coste coincide. Un solo notebook compartido con unas cuantas queries SELECT * corriendo en schedule (pipelines CI/CD de analistas, exports scheduled, dashboards exploratorios dejados corriendo) puede escanear varios TiB al mes sin que nadie se dé cuenta.

Hacer de la selección explícita de columnas parte de cada code review es la optimización más barata de la lista porque cuesta cero infraestructura y ahorra de inmediato. La guía oficial de best-practices de coste de Google abre con esta regla por algo.

Coste oculto #6: Movimiento de datos cross-region y replicación

El almacenamiento de BigQuery está fijado a una región. Si tu dataset vive en us-central1 pero tus reportes de Looker Studio consultan a través de una service account configurada para europe-west1, cada query incurre en network egress. Las tarifas son pequeñas por query (~$0.08 por GiB de egress) pero se acumulan en dashboards que refrescan cientos de veces al día.

Peor, los exports de GA4 van a una región atada al proyecto GCP que posee la propiedad de GA4. Si tu proyecto de marketing vive en una región diferente al proyecto de GA4, pagas egress en cada join cross-source. El check: SELECT location FROM INFORMATION_SCHEMA.SCHEMATA; para cada dataset que consultas.

Coste oculto #7: Reservas de capacidad dimensionadas para picos, pagadas 24/7

El modelo de pricing más nuevo de BigQuery (editions: Standard, Enterprise, Enterprise Plus) cobra por slot-hora para capacidad reservada. La edition Standard arranca alrededor de $0.04 por slot-hora. Un equipo de marketing típico que compra una reserva de 100 slots para manejar picos de QBR paga 100 slots × 24 horas × 30 días = 72.000 slot-horas = ~$2.880 al mes, aunque el uso pico sea solo 4 horas a la semana.

La trampa es dimensionar reservas para el pico en vez de para la media, y luego olvidarse del autoscaling. Las editions más nuevas soportan slots autoscalables; los flat-rate commitments más antiguos no. Si estás en un flat-rate commitment anterior a 2024, la matemática puede ahora favorecer cambiar a editions con autoscaling o de vuelta a on-demand.

Por qué la calculadora de pricing de GCP se equivoca con marketing

La calculadora oficial de pricing de BigQuery pide dos inputs: GiB almacenados y TiB consultados al mes. Ambos son estimaciones razonables si tienes una carga estable. Las cargas de marketing no son estables.

La calculadora no modela:

• Cómo afecta el particionado al volumen escaneado (asume que ya has optimizado)
• El conteo de vistas de dashboard, que es el mayor driver de volumen de query para equipos de marketing
• La interacción entre patrones de ingestión del conector (streaming vs batch) y elegibilidad de tier de storage
• Costes de evolución de esquema (re-cargar datos históricos en adiciones de columna devuelve long-term storage a activo)
• Egress cross-region en dashboards que cruzan setups multi-región

El resultado: los equipos de marketing meten "100 GiB almacenados, 5 TiB consultados" en la calculadora, ven $35 al mes y presupuestan en base a eso. La factura real del mes tres, con tablas sin particionar y dashboards de 30 stakeholders refrescando todo el día, aterriza 5-15x más alto.

Un método de forecast mejor: trackear INFORMATION_SCHEMA.JOBS_BY_PROJECT durante los primeros 30 días, calcular los bytes facturados reales por refresco de dashboard, multiplicar por tu conteo real de refrescos y extrapolar. Herramientas como Looker Studio también exponen el historial de queries por data source.

Patrones de optimización de coste de BigQuery que funcionan de verdad

Si has decidido quedarte con BigQuery, estos cinco patrones cubren la mayor parte de la factura. Cada uno está documentado oficialmente; la aplicación específica para equipos de marketing no siempre.

Patrón 1: Particionar por fecha, clusterizar por cuenta

Cada tabla de marketing debería estar particionada por fecha (PARTITION BY DATE(event_date) o PARTITION BY DATE(_PARTITIONTIME) para tiempo de ingestión) y clusterizada por la columna de filtro con mayor cardinalidad, normalmente account ID o campaign ID. Los docs de particionado cubren la sintaxis; para marketing, la regla general es particionar por la columna de fecha por la que filtras en el 90 por ciento de tus queries.

Las tablas existentes sin particionar se pueden migrar con un swap CREATE TABLE ... PARTITION BY ... AS SELECT * FROM .... La migración escanea la tabla completa una vez (coste equivalente a una query contra ella), y luego cada query futura contra la versión particionada cuesta una fracción.

Patrón 2: Vistas materializadas para queries de dashboard repetidas

Si tres dashboards agregan el mismo spend de Meta Ads por campaña × día × geo, esa agregación se computa tres veces en cada refresco. Una vista materializada la computa una vez y sirve los tres dashboards desde el resultado pre-computado. BigQuery refresca vistas materializadas automáticamente cuando las tablas base cambian.

Para marketing, las vistas materializadas que pagan más rápido son: spend por canal × día × geo (base para la mayoría de dashboards), conversiones por source × campaña (joins de atribución) y snapshots de funnel de contacto a deal (si HubSpot o Salesforce están en BigQuery).

Patrón 3: Reservas de capacidad dimensionadas para la media, no el pico

Si estás en pricing de editions, dimensiona tu reserva para la carga steady-state y deja que el autoscaling absorba los picos. El autoscaling de la edition Standard significa que solo pagas por los slots adicionales durante la hora de QBR, no 24/7. Para la mayoría de equipos de marketing, la base es 25-50 slots y los picos llegan a 100-200. Right-sizing típicamente recorta la factura de la reserva un 40 por ciento.

Patrón 4: Quotas de query custom por usuario o service account

BigQuery soporta quotas custom que limitan cuánto puede escanear cada usuario (o service account) al día. Pon una quota en la service account del analista que alimenta Looker Studio. Si el dashboard accidentalmente arranca una tormenta de refresh, el cap salta antes de que lo haga la factura. El setup está en los docs de quotas custom.

Patrón 5: Queries con aprobación requerida para análisis ad-hoc

Para queries ad-hoc fuera del pipeline diario, exige un dry run que estime los bytes facturados antes de la ejecución. La UI de BigQuery muestra esta estimación arriba a la derecha. Los equipos que hacen del hábito "revisar la estimación antes de pulsar Run" prácticamente eliminan los escaneos no intencionados de 1+ TiB que generan la mayoría de las facturas sorpresa.

Cuándo dejar de optimizar BigQuery y cambiar de camino

La optimización tiene un techo. Después de particionar, clusterizar, vistas materializadas, right-sizing de reservas y controles de quota, la factura de BigQuery de un equipo de marketing típico aterriza en $200-800 al mes, más el coste de ingeniería para mantener esas optimizaciones.

Para equipos de marketing sin un data engineer dedicado, el coste de ingeniería a menudo pesa más que el coste de storage. Cada una de estas optimizaciones es una cosa pequeña aislada. Combinadas, consumen horas de ingeniería todos los meses: monitorizar INFORMATION_SCHEMA, auditar patrones de query, ajustar reservas, debuggear por qué una partición no pasó a long-term.

La pregunta honesta es si la inversión de ingeniería compensa frente a pasar a un warehouse gestionado que maneja todo esto internamente. La Guía del Data Warehouse de Marketing 2026 cubre cuándo encaja cada camino. Para cargas marketing-only por debajo de escala enterprise, la matemática a menudo favorece un warehouse marketing-native gestionado con tarifas predecibles por tier.

Lo contrario también puede ser cierto. Si tu infraestructura de datos se extiende más allá de marketing (product analytics, finanzas, ML), y tienes capacidad de ingeniería, la flexibilidad de BigQuery justifica el trabajo de optimización.

Un ejemplo de coste a 90 días

Para hacerlo concreto: un equipo de marketing corriendo paid media en Google Ads, Meta, LinkedIn, TikTok y Pinterest, con 10 cuentas cliente (setup de agencia), export de GA4 habilitado y HubSpot sincronizando a diario. Tres dashboards en Looker Studio. Ocho stakeholders viéndolos a diario. Cinco analistas corriendo queries ad-hoc.

La inversión típica de optimización aterriza en 20-30 horas de ingeniería a lo largo de dos semanas. A una tarifa blended de $100-150 por hora, eso son aproximadamente $2.000-4.500 one-time, a menudo pagándose dentro del primer ciclo de facturación. El mantenimiento continuo son 2-4 horas al mes (monitoring, ajustes de quotas, auditorías de particiones).

Para algunos equipos, esa matemática funciona. Para otros, apunta a una alternativa gestionada.

FAQ

¿Cuánto cuesta BigQuery al mes para un equipo de marketing típico?
Sin optimización, un setup típico de marketing de 5 plataformas y 10 cuentas con 3 dashboards en Looker Studio refrescados a diario aterriza en $400-600 al mes en el mes tres. Con particionado, clustering, vistas materializadas e higiene de conectores, la misma carga se sitúa en $30-80 al mes. El ejemplo a 90 días arriba muestra el desglose completo.

¿Cuál es la mayor trampa de coste de BigQuery para equipos de marketing?
Tablas ad-level sin particionar consultadas por dashboards de Looker Studio. Una sola tabla de 3,5 GiB sin particionar vista 150 veces al día escanea 15 TiB al mes, costando aproximadamente $87 mensual. Particionada correctamente, la misma carga escanea 225 GiB con un coste de alrededor de $1,40 al mes, una reducción del 98 por ciento.

¿Vale la pena la optimización de coste de BigQuery por el tiempo de ingeniería?
Para equipos que escanean más de 5 TiB al mes, sí. Las cinco optimizaciones core (partición, cluster, vistas materializadas, quotas de query, hábitos de dry-run) típicamente pagan la inversión de ingeniería en 30-60 días y ahorran un 80-95 por ciento de forma continua. Para equipos de volumen menor, la complejidad de la optimización puede pesar más que el ahorro, y un warehouse gestionado con pricing empaquetado se vuelve más coste-efectivo.

¿Aplica el descuento de long-term storage a los datos de marketing?
Solo parcialmente. El 50 por ciento de descuento entra para particiones no tocadas en 90 días. Los datos de marketing añadidos a diario solo afectan a la partición más reciente, así que las particiones más antiguas normalmente sí califican. Pero los cambios de esquema o backfills históricos modifican particiones antiguas y resetean el timer. Revisa INFORMATION_SCHEMA.PARTITIONS para ver cuáles de tus particiones son realmente long-term.

¿Debería usar BigQuery streaming o batch load para datos de marketing?
Batch load en casi todos los casos. Los datos de marketing se actualizan en horarios de plataforma (Meta refresca ventanas de atribución cada pocas horas, no en tiempo real), así que el beneficio near-real-time del streaming no importa. El streaming cuesta $0,05 por GiB ingestado más el coste indirecto de bloquear el descuento de long-term storage en las particiones afectadas. Usa streaming solo cuando la freshness sub-minuto genuinamente importe.

¿Cuál es la diferencia entre on-demand y editions pricing para marketing?
On-demand factura por TiB escaneado, sin compromiso mínimo. Editions (Standard, Enterprise, Enterprise Plus) facturan por slot-hora y requieren una reserva de capacidad. Para cargas mensuales predecibles por encima de 50 TiB escaneados, editions con autoscaling puede ser más barato. Para cargas variables o equipos escaneando menos de 20 TiB al mes, on-demand es normalmente más simple y competitivo.

Conclusión

Las tarifas publicadas de BigQuery son honestas. Los costes ocultos vienen de cómo interactúan los datos de marketing con el modelo de pricing: tablas sin particionar escaneadas enteras, dashboards refrescando todo el día, streaming inserts cuando batch valdría, evolución de esquema arrastrando particiones fuera de long-term storage. Cada uno es arreglable. Juntos, explican por qué la factura del mes tres raramente coincide con la estimación de la calculadora del mes uno.

Para equipos comprometidos con el camino de cloud warehouse, los cinco patrones arriba cubren la mayor parte de la factura. Para equipos cuyas cargas se extienden más allá de marketing hacia product analytics, finanzas o ML, la flexibilidad de BigQuery y su economía per-byte genuinamente superan a una alternativa marketing-native; la inversión en ingeniería paga a través de consolidación cross-team, no solo reporting de marketing. Para equipos marketing-only sin ingeniería de datos dedicada, la complejidad de optimización puede justificar un camino diferente. De cualquier manera, conocer los drivers reales de coste, no solo las tarifas publicadas, es el primer paso hacia una infraestructura de datos de marketing que no sorprenda a finanzas.