CONNECTIONS / Snowflake / Snowflake to Google Store Sales
Snowflake POS data, delivered to Google Store Sales.
Point a read-only Snowflake role at your POS transactions and Signals handles hashing, Store Sales formatting, and the upload calendar.
- ● snowflake → google.store_sales :: live
- > sync table POS_TRANSACTIONS rows=11,504
- hash sha256(email,phone,address)
- route google.store_sales upload
- ✓ uploaded · 10,132 matched
WHAT THIS ENABLES
Snowflake to Google Store Sales
Snowflake to Google Store Sales reads in-store transactions directly from your Snowflake warehouse, hashes the identifiers Google's Store Sales spec requires, and uploads on a nightly or weekly cadence so Search and YouTube campaigns get credit for revenue that closed in a physical store.
- POS tables in Snowflake driving Google's offline sales measurement.
- Search and YouTube performance measured through to the register.
- Reject diagnostics per batch so data quality issues surface early.
The click, the conversion, and the credit.
The conversion happens off Google, away from any pixel. Here is how Snowflake closes the loop.
Built for the teams that own the number.
Marketing analytics teams closing the loop between spend and store revenue.
From kickoff to verified events.
-
Connect
A SELECT-only Snowflake role scoped to the POS transaction schema.
-
Map
Columns matched to Google's Store Sales fields with hashing applied in flight.
-
Deliver
Scheduled upload jobs with acceptance and rejection counts per run.
What changes when the CSV goes away.
| Capability | Manual CSV upload | Datahash |
|---|---|---|
| Reporting | Offline sales sit in a separate export, reconciled by hand. | Revenue counted in the same Store Sales reporting as web conversions. |
| Deduplication | A re-uploaded file risks counting the same conversion twice. | Deduped delivery, so a resent record never counts as a second conversion. |
| Match visibility | Match quality is a guess until the numbers look off. | Match rate reported per upload, tied to the source event set that produced it. |
| Effort and latency | An analyst exports and uploads on a manual cadence. | Server-side and automatic the moment Snowflake records the event. |
What Store Sales actually receives.
- ● signals :: store sales upload
- > POST /offline_user_data_jobs source=snowflake.POS_TRANSACTIONS
- transaction_time 2026-07-04T19:05:00 · transaction_amount_micros 189000000
- currency_code AED
- hashed_email sha256 "6d2e91…" · hashed_last_name sha256 "cc410a…"
- ✓ accepted match=88%
Adjacent moves on the same stack.
from Snowflake
Snowflake to Google OCI
Snowflake to Google Offline Conversion Import reads a warehouse table where GCLID capture…
Learn more
from Snowflake
Snowflake to Meta Offline CAPI
Snowflake to Meta Offline CAPI points Signals at the Snowflake table where your offline…
Learn more
same use case
ActiveCampaign to Google Store Sales
ActiveCampaign to Google Store Sales: Signals reads your ActiveCampaign contacts and deal…
Learn moregeneric
Google Store Sales
Datahash automates Store Sales Direct and Store Sales Customer Match uploads from your POS…
Learn moreAsked on almost every call.
How good is match rate likely to be on a Store Sales upload sourced from Snowflake?
It comes down to how complete the POS table is at checkout. Rows carrying a verified email or phone number alongside the transaction typically match well once hashed, while rows missing both fields will not match no matter how the query is tuned. The first upload sets a baseline match rate and a fix list for whichever columns are thin.
How fresh does the POS table in Snowflake need to be?
Nightly is the common cadence, though weekly works for chains whose warehouse task only rebuilds the transaction table on that schedule. Fresher reads feed Smart Bidding sooner, so teams running a POS table that updates hourly usually tighten the sync to match rather than waiting on a fixed nightly batch.
Does Datahash need its own copy of the POS table?
No. The read-only Snowflake role queries the table or view you nominate on each scheduled run and nothing is persisted on our side between syncs. A schema change on your end only costs an update to the mapper, after which the next run picks up the new columns on its own.
NEXT STEP