CONNECTIONS / Snowflake / Snowflake to Meta Offline CAPI
Snowflake offline sales, flowing to Meta CAPI.
Give Signals a read-only role on the sales table and Meta starts receiving hashed, consent-checked offline conversions on your schedule.
- ● snowflake → meta.offline_capi :: live
- > sync table SALES_LEDGER rows=7,206
- hash sha256(email,phone) consent=filtered
- route meta.offline_capi deliver
- ✓ delivered · 6,110 matched
WHAT THIS ENABLES
Snowflake to Meta Offline CAPI
Snowflake to Meta Offline CAPI points Signals at the Snowflake table where your offline sales already live, hashes and filters every row for consent, and delivers offline conversions to Meta on schedule so campaigns finally optimize on in-store and phone revenue.
- Offline transactions held in Snowflake joining Meta's optimization loop.
- Dealer, branch, and phone sales credited against the campaigns that drove them.
- Consent filtering enforced before any record leaves the pipeline.
The click, the conversion, and the credit.
The conversion happens off Meta, away from any pixel. Here is how Snowflake closes the loop.
Built for the teams that own the number.
Considered-purchase brands closing sales far from the browser.
Financial services teams with issuance tables to activate.
From kickoff to verified events.
-
Connect
A Snowflake role with SELECT on just the offline sales table.
-
Map
Your columns aligned to Meta's offline event fields, hashed as rows are read.
-
Deliver
Scheduled incremental delivery with match-rate visibility per batch in the Signals debugger and Meta Events Manager.
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 Offline CAPI 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 Offline CAPI actually receives.
- ● signals :: event payload
- > POST /offline_conversions source=snowflake.SALES_LEDGER
- event_name "Purchase" · event_time 2026-07-04T20:47:00
- value 189.00 · currency AED
- em sha256 "1fa603…" · ph sha256 "eb2201…" · external_id "txn-51092"
- ✓ accepted match=85%
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 morefrom Snowflake
Snowflake to Google Store Sales
Snowflake to Google Store Sales reads in-store transactions directly from your Snowflake…
Learn more
same use case
ActiveCampaign to Meta Offline CAPI
ActiveCampaign to Meta Offline CAPI: Signals reads your ActiveCampaign contacts and deal…
Learn moregeneric
Meta Offline CAPI
Datahash ingests offline transactions from your POS, CRM, or warehouse and routes them to…
Learn moreAsked on almost every call.
How fresh does the Snowflake sales table need to be for Meta CAPI?
Meta accepts offline events up to 62 days after they happened, so a daily incremental read is the common default and comfortably inside that window. Teams whose register or CRM replica updates more often can tighten the schedule to hourly without changing the mapping, since each run only picks up rows that changed since the last one.
What match rate should we expect from a Snowflake-sourced offline batch?
It depends on identifier coverage in the sales table itself. Rows carrying a clean, current email and phone typically land in the 40 to 70 percent range once hashed; rows missing both fields will not match no matter how the query is tuned. The first batch's feedback sets your baseline and the fix list for whichever columns need attention.
Can returns and refunds recorded in Snowflake be sent back to Meta?
Yes. Meta supports value adjustments on an already-matched offline event, so a refund row in the sales table can be mapped to reduce the original conversion value rather than being dropped from the sync entirely. The adjustment carries the same external ID as the original transaction so Meta ties the two together correctly.
NEXT STEP