Capability
Fast on screen. Unrestricted underneath.
Two stores, two access patterns, on purpose. Firestore answers 'this person's last twenty events' inside a page render. BigQuery answers 'how many opened campaign X, by segment' across millions of rows, in your own dataset, using your own tools.
Written synchronously, mirrored asynchronously.
An operational write goes to Firestore synchronously, so a recorded event appears on screen immediately. The BigQuery mirror is fed through Pub/Sub afterwards, with a dead-letter topic, so an analytics outage can never lose a write or block the person waiting for the page.
Firestore holds a hot window — the last twelve months or the last five hundred events per person, whichever is smaller. Everything is retained in BigQuery. Ageing out of the hot window is explicitly not deletion, and the interface says so rather than implying history stopped.
- Interactions cover email opens and clicks, calls, web visits, form submissions and bounces
- Occurred-at and recorded-at are tracked separately, so webhook lag and backfill do not distort a timeline
- Orders are held as a reference — number, date, status, total, currency, a deep link and an item count — not a copy
- Keeping your commerce system as the system of record for line items avoids a synchronisation problem with no correct answer
Signed, deduplicated and tenant-bound.
Webhooks
HMAC-signed with a per-tenant secret and compared in constant time, with the timestamp inside the signed material so a replay with a fresh timestamp fails. Deduplicated on the vendor's own event id and rate-limited per tenant.
Never across the boundary
A webhook can never create or attach an event to a person outside the calling tenancy, and one naming a person outside it is refused with the same shape as a validation failure — so it cannot be used to enumerate.
Web analytics
GA4 web-visit data is accepted through a signed, short-lived, tenant-scoped browser beacon token — never by reaching into your own analytics property.
A documented connection pattern, deliberately not a bundled dashboard.
The campaign reporting grain lands in your own BigQuery dataset: sends, opens, clicks and bounces by campaign, category and date, with the variant identifier included so you can run your own analysis beyond the numbers the platform computes by default.
There is a documented pattern for connecting Looker Studio rather than a dashboard we built and you cannot change. That is a deliberate choice: a bundled dashboard becomes the ceiling of what anybody asks, and reporting should stay in your hands.
- One BigQuery dataset per tenant
- Tenant reporting views defined so isolation holds in the analytics layer too
- Reporting by category available by identifier and by name, so a rename does not orphan a report
- Wide analytical queries go to BigQuery rather than to the interactive path
Questions about data
Is the analytics data mine?
It lands in your own dataset and you connect whatever tools you like to it. There is no gate between you and your own reporting.
How does erasure work in the analytics store?
Honestly: it is eventually consistent rather than instant. Row-level deletion against a partitioned table is slow and quota-limited, so erasure runs as a periodic rewrite driven by a tombstone table, plus a short additional lag for anything still in the streaming buffer at the moment of erasure. We state that rather than claiming immediate erasure across both stores, and you should state it in your privacy notice too.
What happens to campaign history when somebody is erased?
The rows stay with the person identifier set to null, so historical reporting counts do not silently change under your analysts. The event stays; the person does not.
Can I get operational data out through the API instead?
Yes, and it is tenant-scoped and audited like everything else — every read as well as every write records the calling key's tenancy, the person touched and a timestamp. That is a compliance feature rather than a surveillance one, but it does make bulk scraping through the API highly visible.
Related capabilities
It is the fastest way to find out whether the grain we keep is the grain you need.