Skippr Docs

Appearance

How to Explain BigQuery Tables to Analysts ​

July 2026

Analysts should treat Skippr BigQuery tables as current-state raw tables in a dataset, not as an append-only mutation archive.

Short Answer ​

Explain BigQuery tables as current-state raw tables that live in the configured dataset and show the latest row per business key after each completed load. For CDC-managed tables, Skippr applies BigQuery MERGE statements with order-token guards, so analysts should think of raw_data.customers as the current customer row set, not as a log of every insert and update that ever happened.

That framing helps immediately with freshness and interpretation. If a subscription changed plans three times today, the ordinary raw table should show the latest subscription row once the load finishes. The _skippr_order_token column exists to protect write ordering, and tombstone tables protect deletes, but neither one is the main analytical interface for everyday reporting.

Why Teams Struggle with This ​

Analysts get lost when engineering teams explain warehouse plumbing instead of table meaning. BigQuery jobs, service accounts, and dataset creation matter operationally, but the first question analysts need answered is what one row in the table represents right now.

  • A CDC-managed BigQuery table is usually a current-state table, not a history table of every mutation.
  • The _skippr_order_token column is a system field for replay safety, not a business timestamp or sequence to model on casually.
  • Companion tombstone tables exist for delete protection and usually should not be part of standard analyst-facing models.
  • Freshness follows completed BigQuery loading and MERGE work, so analysts should ask when the last successful run landed, not assume the table is a live replication feed.

How Skippr Handles It ​

Skippr makes the BigQuery story easier to teach because the destination surface is simple: project, dataset, and optional location. Analysts can be told where the raw tables live without having to understand the service account file or the load mechanics behind them.

The CDC contract is also clean. BigQuery MERGE is atomic, and Skippr automatically manages the order-token and tombstone pieces, so the everyday query model can stay focused on current rows instead of replay logic.

  • Targets a named BigQuery dataset inside one project.
  • Uses exactly-once final-state MERGE semantics for CDC-managed tables.
  • Adds _skippr_order_token columns automatically for stale-write protection.
  • Creates tombstone tables automatically so deletes are not accidentally reversed later.

What the First Useful Version Looks Like ​

The first useful explanation is one table such as raw_data.orders: one row is the current order record, key business columns are the fields analysts model from, and _skippr_order_token is an internal guardrail. That is usually enough to stop most confusion.

If a team also needs history, say that explicitly and build it somewhere else. The raw BigQuery table is strongest when analysts understand it as the trustworthy current-state starting point.