Collect Stripe subscriptions in Google BigQuery
Load Stripe subscriptions, invoices and customers into your own BigQuery project with a custom OWOX connector: one table per endpoint, readable columns, a refresh on a schedule. Recurring revenue then joins to orders and ad spend.
Stripe Endpoints
14 Stripe endpoints you can import. Each lands in its own table in your data warehouse.
Balance transactions
Every movement of money through the Stripe balance: charges, refunds, disputes, fees, payouts, adjustments.
16 fieldsTime seriesCharges
One row per charge attempt: amount, outcome, card details, who paid and which invoice or payment intent it belongs to.
33 fieldsTime seriesCustomers
Every customer object: identity, billing country, delinquency and balance.
17 fieldsDisputes
One row per dispute (chargeback) with its status and evidence deadline.
14 fieldsTime seriesEvents
The audit trail: every change Stripe recorded (invoice.paid, customer.subscription.updated, charge.refunded, …) with the id of the object it concerns.
11 fieldsTime seriesInvoice line items
Every line on every invoice: what was billed, for which price and product, for which period.
19 fieldsInvoices
One row per invoice with amounts, status and period.
31 fieldsTime seriesPayment intents
One row per payment attempt lifecycle: how much was asked for, how much was received, and where it stands.
22 fieldsTime seriesPayouts
One row per transfer from the Stripe balance to the bank account: amount, arrival date, status.
18 fieldsTime seriesPrices
Every price (plan) of every product, active or not, with amount, currency and billing interval.
17 fieldsProducts
The catalogue: every product, active or not.
13 fieldsRefunds
One row per refund: how much was returned on which charge, why, and the balance transaction that reversed the money.
13 fieldsTime seriesSubscription items
The lines of every subscription: which price, how many units.
14 fieldsSubscriptions
One row per subscription in any status (status=all), full refresh every run so cancellations and past-due states are current.
23 fields
Why join Stripe subscriptions with sales and ad data
Stripe knows who subscribes and when they renew. It does not know which ad brought them or what they ordered first. To read recurring revenue against acquisition cost, all of it has to sit in one warehouse.
- Compute monthly recurring revenue from subscriptions and invoices
- Set acquisition spend beside new subscriptions
- See churn next to the open or uncollectible invoices before it
Step 1: Connect Stripe and pick the fields
Create a Data Mart, choose Stripe as the source and add a restricted API key with read access. Open an endpoint and tick only the fields you need.
- Subscriptions carries customer, status, period dates and cancellation fields
- A custom connector: the restricted API key is yours
Step 2: Load Stripe into Google BigQuery
Each endpoint becomes its own table, and refresh settings are set in the Data Mart. Run it and the first load lands as a table in a dataset of your own Google BigQuery project. The location is pre-filled from your storage, and you can change it.
- Each endpoint gets its own table, not one table for the account
- Every run is logged in Run History
Step 3: Get a business-friendly Stripe output schema
After the first run you get the output schema: every field with its type and a description. Timestamps arrive as Unix seconds, and the schema says so. Your quality checks can read it too.
- status lists trialing, active, past_due, unpaid, canceled and the incomplete states
- Unix seconds convert with one function in SQL
Step 4: Keep the Stripe tables linked
Customers, subscriptions and invoices stay separate tables, joined by ids. Together they become one Stripe model, ready to join to orders and ad spend.
- Subscriptions carry customer; invoices carry subscription
- Add orders and ad platforms to the same model
Step 5: Schedule the Stripe refresh and backfill history
Set it once. A daily scheduled refresh keeps the tables current, and a manual backfill reloads history, which refreshes fields that change after creation, such as status.
- Daily runs with no pipeline to maintain
- Backfill the subscription history the first time you connect
Step 6: Reuse the same Stripe table everywhere
One table feeds your model, , , assistants and scheduled insights in Slack or email.
- Define monthly recurring revenue once
- Every report reads the same table
- 0.41.0Rotating a warehouse key is one change: Storages share reusable Credentials
- 0.41.0Dates from Google Sheets arrive as dates, not text
- 0.41.0Shared SQL logic stays in one place: build a Data Mart on top of another
- 0.41.0Rotating a connector key is one change: Sources share reusable Credentials
- 0.40.0Connecting a plan from Google Sheets takes fewer guesses
Why OWOX for Stripe in Google BigQuery
Stripe dashboards, hand-built API scripts or a generic ETL tool each get subscriptions out. OWOX also keeps them yours, readable and ready to join to acquisition.
- You own the data. It lands in your own data warehouse, in tables you control.
- A custom connector, built to be extended. The Stripe connector is made in OWOX Data Marts, so an endpoint or field can be added when the account needs it.
- Ready for a data model. Separate tables per endpoint, joined by ids, built to connect to orders, ad spend and web analytics.
- One place to fix. When Stripe changes its API, you fix one connector, not a pile of scripts.
You are booked. The invitation is on its way to , with the calendar invite and the meeting link.