CONNECTIONS / File drops / Files to Google Store Sales
POS exports to Google Store Sales, hands-free.
Land the nightly export on SFTP, S3, or GCS and Signals takes it from there: validation, hashing, Store Sales formatting, and the upload itself.
- ● files → google.store_sales :: live
- > ingest File drop pos_sales_2026-07-04.csv
- hash sha256(email,phone,address) rejects=quarantined
- route google.store_sales upload
- ✓ uploaded · 8,143 matched
WHAT THIS ENABLES
POS / SFTP files to Google Store Sales
POS and SFTP files to Google Store Sales validates and hashes each nightly export the moment it lands on SFTP, S3, or GCS, then uploads it to Google's Store Sales spec on schedule, so in-store revenue reaches Search and YouTube campaigns without a manual upload.
- The export your POS already produces becoming the whole integration.
- Store revenue attributed to Google campaigns without touching an API.
- Row-level quarantine so one malformed line never sinks a batch.
The click, the conversion, and the credit.
The conversion happens off Google, away from any pixel. Here is how File drops closes the loop.
Built for the teams that own the number.
Retail groups whose legacy POS can export but cannot integrate.
From kickoff to verified events.
-
Connect
A watched drop folder on SFTP, S3, or GCS, wherever exports land today.
-
Map
File columns validated and bound to the Store Sales spec, keys hashed per row.
-
Deliver
Uploads on the drop schedule with match and reject counts reported back.
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 File drops records the event. |
What Store Sales actually receives.
- ● signals :: store sales upload
- > POST /offline_user_data_jobs source=files.pos_sales_2026-07-04.csv
- transaction_time 2026-07-04T22:00:00 · transaction_amount_micros 156000000
- currency_code AED
- hashed_email sha256 "88ac3f…" · hashed_street_address sha256 "12de90…"
- ✓ accepted match=87%
Adjacent moves on the same stack.
from File drops
File drops to Google OCI
File drops to Google Offline Conversions: your file drops, hashed and consent-checked, feed…
Learn more
from File drops
Files to Meta Offline CAPI
POS and SFTP files to Meta Offline CAPI validates and hashes each export the moment it…
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.
What happens to rows that fail validation?
Each file is checked as it arrives, and any row that fails a rule is quarantined with a reason rather than failing the batch, so one bad export never stops the store-sales feed to Google. Corrected rows reprocess on the next drop, and the clean records that already matched stay delivered, so a partial file still moves the transactions it can.
Can it handle multi-country chains?
Yes. Signals reads per-market files with their own currencies and maps each store's sales to the right Google Store Sales feed, so a chain operating across countries runs one pipeline rather than many. Currency and market columns come straight from the file, identifiers are hashed and matched per region, and the debugger breaks match rates out by market.
NEXT STEP