LIMIT 10 no la abarata: BigQuery factura los bytes que lee, no las filas que devuelve
Un SELECT * con LIMIT 10 devuelve diez filas y puede facturar la tabla entera. Cómo guarda y lee BigQuery los datos, y cómo hacer que cada consulta lea menos.
Find it. Understand it. Fix it.
¿Qué le pasa a mis datos? Vamos a verlo.
La mayoría de los informes que no cuadran no fallan por la herramienta, sino por pequeños errores de configuración que nadie detecta. Los encontramos, explicamos por qué ocurren y mostramos cómo corregirlos.
El síntoma: qué se ve en los informes y cómo detectarlo en tu propia cuenta.
La causa: dónde nace el error (la web, el gestor de etiquetas, la configuración de la propiedad) y por qué.
La solución, y cómo comprobar que funciona antes de volver a fiarte de los datos.
Cada vídeo corto que publicamos en Instagram, TikTok y YouTube tiene aquí su artículo. El artículo reproduce la misma animación en horizontal, paso a paso y sin sonido, y la explica por escrito con calma: el contexto, los casos límite y cómo verificar la solución.
Todo el stack de datos, error a error. Empezamos por Google Analytics 4, la API de conversiones de Meta y BigQuery.
Un SELECT * con LIMIT 10 devuelve diez filas y puede facturar la tabla entera. Cómo guarda y lee BigQuery los datos, y cómo hacer que cada consulta lea menos.
Sin filtro de _TABLE_SUFFIX, events_* lee todos los días exportados, y las tablas intradía si hay streaming. Facturas más altas y totales que no cuadran.
Desanidar event_params con un CROSS JOIN convierte cada evento en una fila por parámetro, y COUNT y SUM se multiplican. Cómo leer parámetros sin duplicar eventos.
ga_session_id solo identifica una sesión dentro de un usuario, así que COUNT(DISTINCT ga_session_id) junta sesiones de usuarios distintos. Cómo las cuenta Google.
Cuéntanos qué ves en tus informes. Escríbenos a hello@wrongwithdata.com