BigQuery

Fidero streams every enriched event into your own BigQuery through the Storage Write API, under a dataset and schema it provisions and maintains for you. The data lands in your Google Cloud project, not ours.

Channel	Server
Consent category	None – your warehouse receives every event that reaches Fidero, regardless of consent state. Consent & privacy covers why
Data residency	EU or US
Sync cadence	Real-time on Growth and Business, daily on Starter

What it delivers

• Every enriched event. Not just conversions – the complete, attributed record streams in, including events that never touched a browser, like a renewal or a webhook. How the pieces fit traces one event end to end
• The schema every destination reads. Each event lands with its name, type, identifiers and timestamps in typed columns, and its properties, context and traits in JSON columns. Data schema lists every field
• A latest-traits view. Fidero maintains a user_traits_view giving the most recent value of each trait per user, so you don’t write the window query yourself
• A deduplicated events view. Fidero maintains an events_deduped view returning one row per event, so a replayed or re-delivered event never double-counts. The events table covers the one case where you’d apply the dedup rule inline instead

What you provide

Item	Detail
Service-account key	A Google Cloud service-account key (JSON) for an account with permission to write to your project.
Dataset and region	Optional – the dataset name and whether it lives in the EU or US. Fidero creates it if it doesn’t exist.

That’s the whole connection. You enable the warehouse like any other destination – request it, and the same enrichment and delivery monitoring apply. What every destination receives covers the standard treatment.

What’s automatic

• Provisioning. Fidero creates the dataset, the events table, the user_traits_view and the events_deduped view on first delivery – nothing to set up by hand
• Day partitioning and clustering. The events table is partitioned by day on received_at, so date-scoped queries scan only the partitions they need, and clustered by project, event name and user, so filters on those columns read less data
• A schema that absorbs any event. Properties, context and traits land in JSON columns, so a new event shape never needs a table migration
• Erasure requests. A delete request for a user removes the rows recorded under their user ID, scoped to the project the request came from – events from before they identified, which carry only an anonymous ID, aren’t matched

The events table

The table holds one row per delivered track event – append-only, so a retry can land twice. Nested data lands as native JSON, so a new property is queryable immediately, without a schema change.

Column	Type	What it holds
fidero_project_id	STRING	The Fidero project the event belongs to
event_name	STRING	The event name, e.g. purchase_completed
event_type	STRING	The envelope type – track
channel	STRING	Where the event originated: web, mobile or server
event_id	STRING	The event’s unique ID – the deduplication key
received_at	TIMESTAMP	When the event reached Fidero – the partition column
timestamp	TIMESTAMP	When the event happened
user_id	STRING	The user’s ID, once identified
anonymous_id	STRING	The anonymous ID from before identification
properties	JSON	Event properties
context	JSON	Event context – page, device, library
user_traits	JSON	The user’s traits as of this event
attribution	JSON	Reserved for enriched attribution state – null today

events_deduped returns one row per event, but it always scans the whole table. On large date-bounded queries, filter events on received_at and keep the latest row per fidero_project_id and event_id, so BigQuery scans only the partitions in range.

The warehouse copy is yours to keep. Data ownership & portability covers what stays with you if you leave.