Collect Open Holidays calendars in Google BigQuery
Load public holiday calendars by country from Open Holidays into your own BigQuery project with OWOX Data Marts, then join the dates to your orders and ad spend to tell a real drop in demand from a calendar effect. Read it from BigQuery.
Someone asks why Monday's orders dropped, and the answer is a public holiday that isn't in Google BigQuery.
Paste this into your AI assistant. It loads Open Holidays calendars by country into Google BigQuery as a Data Mart, so a join on date shows whether a dip fell on a holiday.
The prompt
Read https://www.owox.com/ai-agent-setup.md and follow it to set up OWOX Data Marts for me, starting from /connectors/open-holidays-connector-to-google-bigquery.md. The task: load the Open Holidays calendar for our countries into Google BigQuery and show which of last quarter's sales dips fell on a public holiday. Tag the links you give me with utm_campaign=ai-task and utm_term=data-foundation. Use what you know about my context and goals
Open Holidays Endpoints
1 Open Holidays endpoints you can import. Each lands in its own table in your data warehouse.
Why keep a holiday calendar next to your sales and ad spend
A dip in the week of a public holiday looks like lost demand until someone checks the calendar. With the dates in your warehouse, the check is a join, not a guess. The calendar sits in your own BigQuery project, beside your own tables.
- Flag every order and ad day that fell on a holiday
- Separate a national holiday from a regional one with one field
- Compare a dip with the calendar before anyone calls it a trend
Step 1: Connect Open Holidays and pick the fields
Create a Data Mart, choose Open Holidays as the source and tick the fields you need. The source needs no credentials, so there is no token or service account to set up.
- One endpoint, Public Holidays, with 7 fields to choose from
- A time series: every holiday row carries its date, ready to filter in BigQuery
Step 2: Load Open Holidays calendars into a BigQuery table
The dataset and table in your storage are pre-filled, and you can change them. Run it and the first load lands in your own BigQuery project.
- Each row is one holiday with its date, name, type and scope
Step 3: Read the output schema in plain words
After the first run you get the output schema: every field with a plain description. Your quality checks can read it too.
- name is the holiday's name in the language you requested
- nationwide is true or false, so a regional holiday cannot pass for a national one
Step 4: Link the calendar to your own tables
The calendar does not need other Open Holidays tables. It needs yours: describe each join once in your model and it holds in every BigQuery query.
- orders.order_date joins to the holiday date, for the country you loaded, as a plain JOIN in BigQuery SQL
- ad_spend.date joins the same way, so spend is read against the same calendar
Step 5: Schedule the refresh and backfill history
Set it once. A scheduled refresh keeps your BigQuery table current, and a manual backfill loads any past period.
- Backfill a custom start and end date to cover the periods you want to explain
- Run History shows every load into your BigQuery dataset
Step 6: Reuse the same calendar everywhere
One BigQuery table feeds your model, , , assistants like Claude and ChatGPT, and scheduled AI insights in Slack or email.
- Every report flags holidays the same way, so the totals agree
- Ask an AI assistant whether last week's dip fell on a holiday and get an answer from the table
- 0.43.0Parallel reads of a SQL Data Mart on Google BigQuery no longer fail with a rate limit error
- 0.41.0Rotating a warehouse key is one change: Storages share reusable Credentials
- 0.41.0Shared SQL logic stays in one place: build a Data Mart on top of another
- 0.39.0Reload a year of history in one backfill, not twelve
- 0.38.0Import from Google BigQuery blocks tables stored in another location
Why OWOX for Open Holidays in BigQuery
Someone checking each dip against a holiday list by hand gets an answer once. OWOX keeps the calendar in the table where your orders and ad spend already are, so every report can check it.
- In your own project. Your BigQuery project holds the table, so your existing access rules, billing and queries apply to it.
- Your SQL, your project. Analysts reach the table with the BigQuery SQL they already write, and the join lives in the Data Mart.
- Calendar by country. The holidays come from Open Holidays by country, with their regional and temporal scope.
- History you can use. Backfill past years, so last year's dip can be explained too.
- Ready for a data model. The date is what the join runs on, so linking holidays to orders and ad spend is one line in your model.
You are booked. The invitation is on its way to , with the calendar invite and the meeting link.