Product Analytics with BigQuery and Mitzu

Introduction

Product teams at BigQuery-first companies face a familiar paradox. Their cleanest event data is already in BigQuery, but many product analytics tools still require duplicating that data into proprietary event stores before teams can run funnels or retention. This introduces pipeline maintenance, freshness lag, and competing metric definitions across tools.

Mitzu removes that duplication by running analytics directly on BigQuery. Product managers get a self-serve interface for funnel, retention, segmentation, and journey analysis, while data teams keep SQL transparency and governance where it belongs: in the warehouse.

The result is a warehouse-native analytics workflow where non-technical teams can answer product questions quickly and technical teams can still validate every generated query. No reverse ETL. No event re-ingestion taxes. No second source of truth.

Why BigQuery for product event data?

BigQuery is often the canonical event store for modern product organizations because it scales well, executes SQL serverlessly, and integrates naturally with the rest of Google Cloud. GA4 exports, Segment pipelines, Fivetran loads, and backend event streams often land in BigQuery first.

• Cost-effective storage at very large event volumes
• Elastic SQL execution without cluster operations overhead
• Native fit with GCP identity, IAM, and audit logging
• Direct compatibility with marketing and product event exporters
• Strong ecosystem for joining events with business context tables

The cost of duplicating data into a SaaS analytics tool

Per-event pricing looks simple at small scale but becomes expensive quickly. At 100M events per month, annual SaaS analytics costs commonly land in the tens or hundreds of thousands of dollars depending on plan and retained history. In contrast, keeping events in BigQuery and querying selectively can be significantly cheaper for many teams.

Beyond budget, duplication creates privacy and compliance risk. Sending user-level behavioral data to third-party infrastructure adds policy overhead for GDPR, regional data residency, and deletion workflows. Warehouse-native analytics keeps the data in one governed environment while still supporting self-serve analysis.

A realistic comparison for many teams: SaaS ingestion might range from $50k-$200k/year at 100M monthly events, while storing equivalent raw data in BigQuery can be a small fraction of that. Your exact spend varies by retention policy and query profile, but the structural gap is usually meaningful.

How Mitzu connects to BigQuery?

Connection is done with a Google service account that has BigQuery Data Viewer and BigQuery Job User permissions on the relevant datasets. After authentication, Mitzu runs an event-catalog setup flow where you map event_name, user_id, and event_time fields, then choose properties to expose for filtering and breakdowns.

1. Create a service account for analytics querying.
2. Grant Data Viewer + Job User on the target project/datasets.
3. Connect credentials in Mitzu.
4. Select event tables in the event catalog wizard.
5. Map required fields and save.

No pipelines or sync jobs are required after setup. Mitzu runs SQL directly on BigQuery so teams can inspect query text and validate logic in their existing warehouse workflows.

Defining your event model

Mitzu's event model starts with required semantics: event_name, user_id, and event_time. You can model one wide events table or multiple event tables as long as key fields are consistently mapped. Optional fields like anonymous_id and property columns improve pre-login analysis and segmentation depth.

CREATE TABLE analytics.product_events (
  event_time TIMESTAMP,
  event_name STRING,
  user_id STRING,
  anonymous_id STRING,
  company_id STRING,
  plan_tier STRING,
  source_channel STRING,
  event_properties JSON
) PARTITION BY DATE(event_time)
CLUSTER BY user_id, event_name

Running key product analyses

After modeling, product teams can run core workflows quickly: funnel conversion, cohort retention, and segment comparisons. Mitzu builds these analyses through a visual interface and executes generated SQL in BigQuery, making logic transparent for data review.

Funnel example

WITH base AS (
  SELECT user_id, event_name, event_time, company_tier
  FROM analytics.product_events
  WHERE event_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
)
SELECT
  company_tier,
  COUNT(DISTINCT CASE WHEN event_name = 'sign_up' THEN user_id END) AS step1,
  COUNT(DISTINCT CASE WHEN event_name = 'onboarding_step_1' THEN user_id END) AS step2,
  COUNT(DISTINCT CASE WHEN event_name = 'onboarding_step_2' THEN user_id END) AS step3,
  COUNT(DISTINCT CASE WHEN event_name = 'first_value_moment' THEN user_id END) AS step4
FROM base
GROUP BY 1

Retention example

SELECT cohort_week, week_number, retention_rate_pct
FROM analytics.retention_cohorts
WHERE cohort_week BETWEEN DATE '2026-01-01' AND DATE '2026-03-31'
ORDER BY cohort_week, week_number

Joining BigQuery tables for richer context

The strongest warehouse-native benefit is joining product behavior with operational context. For example, enriching funnels with Salesforce ARR bands can show whether enterprise onboarding friction is hidden inside an aggregate conversion metric.

SELECT c.arr_segment, COUNT(DISTINCT e.user_id) AS converted_users
FROM analytics.product_events e
JOIN crm.companies c ON c.company_id = e.company_id
WHERE e.event_name = 'first_value_moment'
  AND e.event_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY 1
ORDER BY 2 DESC

Agentic analytics on BigQuery

Mitzu's agentic layer accepts natural-language questions and converts them into executable BigQuery SQL. Because the agent sees the event model and available dimensions, it can answer practical product questions quickly while still returning transparent SQL output for validation.

Example prompt: "Show activation funnel drop-off for users who signed up via the enterprise landing page last month." The generated query can join behavioral events with campaign and account attributes in one execution context, which is difficult in siloed event-store tools.

Performance and cost optimization

• Partition event tables by DATE(event_time).
• Cluster high-use tables by user_id and event_name.
• Set expiration policies for temporary staging tables.
• Filter by date early to minimize scanned bytes.
• Monitor query costs and optimize high-frequency workloads.

Mitzu helps control spend by generating date-constrained SQL patterns for common analyses. Teams keep full control over BigQuery billing while enabling non-technical exploration on governed datasets.

Getting started in 15 minutes

1. Create a Google service account for Mitzu.
2. Grant BigQuery Data Viewer + BigQuery Job User roles.
3. Connect credentials in Mitzu.
4. Map core event tables and required columns.
5. Run your first funnel and retention chart.

Conclusion

BigQuery is already where many teams keep their most trustworthy event data. Mitzu turns that same data into a practical product analytics system without duplication, vendor lock-in, or opaque logic. You get self-serve UX for product teams, SQL-level transparency for data teams, and agentic analytics built directly on warehouse truth.

FAQ

Does Mitzu support partitioned BigQuery tables?

Yes. Partitioned tables are a standard pattern for BigQuery event data and are fully compatible with Mitzu modeling. In many deployments this is the preferred setup because it improves query efficiency for date-scoped analyses like funnel windows and retention cohorts.

Can I use Looker Studio dashboards alongside Mitzu?

Yes. Many teams use Mitzu for product-specific workflows and self-serve discovery, then use Looker Studio for broader executive BI reporting. Both read from the same BigQuery source, which helps keep metrics consistent.

How does Mitzu handle BigQuery costs?

Mitzu executes SQL directly in your BigQuery project, so cost is still controlled by your warehouse settings and query patterns. Teams reduce spend by partitioning data, clustering key dimensions, and applying tight date filters. Query transparency makes optimization straightforward.

Can I connect Mitzu to GA4's BigQuery export?

Yes. GA4 export tables can be modeled in Mitzu and used for funnels, retention, and segmentation, especially when paired with flattened parameter views. This allows teams to move beyond GA4 UI limitations while keeping the same underlying event source.

What BigQuery permissions does Mitzu need?

A service account typically needs read access to modeled datasets and permission to run query jobs. Most setups use BigQuery Data Viewer and BigQuery Job User roles on scoped datasets/projects. Principle of least privilege should still be applied for production deployments.