CONNECTIONS / Snowflake / Snowflake to Snap Offline CAPI
Snowflake's retail transactions, delivered to Snap on schedule.
Closed sales in a retail transaction table rarely happen on Snapchat itself. Signals reads the table your warehouse already populates and delivers it to Snap's Conversions API on the cadence that table refreshes.
- ● snowflake → snap.offline_capi :: live
- > sync table RETAIL_TRANSACTIONS rows=6,530
- hash sha256(email,phone)
- route snap.offline_capi batch=daily
- ✓ delivered · match 64%
WHAT THIS ENABLES
Snowflake to Snapchat Offline Conversions API
Snowflake to Snapchat Offline Conversions API reads a retail transaction table from your warehouse and delivers it to Snap's Conversions API on the schedule the underlying task runs, matched by hashed customer identifiers, so in-store and call-centre sales count toward Snap campaign optimization.
- Retail and call-centre sales already sitting in Snowflake counted inside Snap campaign optimization.
- A delivery cadence matched to however often the transaction table itself refreshes.
- One warehouse read reused across every offline destination, Snap included, instead of a bespoke build per platform.
The click, the conversion, and the credit.
The conversion happens off Snap, away from any pixel. Here is how Snowflake closes the loop.
Built for the teams that own the number.
Warehouse-first teams whose retail transaction table already decides which offline sales, Snap-attributed ones included, actually count.
From kickoff to verified events.
-
Connect
A read-only Snowflake role scoped to the retail transaction table.
-
Map
Transaction columns mapped to a Snap offline conversion event in the visual mapper.
-
Deliver
Each scheduled read posts to Snap's Conversions API as its own batch, deduped and tracked in the debugger.
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 /v2/conversion source=snowflake.RETAIL_TRANSACTIONS
- event_type "PURCHASE" · event_conversion_type "OFFLINE"
- hashed_email "5d8b22…" · hashed_phone_number "a179fe…"
- timestamp 1784278980 · price 14750 · currency AED
- ✓ accepted · match=true
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 Snap Offline CAPI
ActiveCampaign to Snapchat Offline CAPI: Signals reads your ActiveCampaign contacts and…
Learn moregeneric
Snap Offline CAPI
Deliver offline conversions to Snap on a schedule that fits your operations.
Learn moreAsked on almost every call.
How often should the retail transaction table sync to keep Snap's optimization sharp?
Fresher delivery generally helps Snap's optimization more, so daily is a common default where the transaction table refreshes at least that often. Weekly batches still work, since Snap accepts offline events within its attribution lookback window, and the right choice usually comes down to how often your warehouse task actually runs.
How does Snap match a Snowflake-sourced transaction back to the original ad?
Through hashed customer identifiers, most commonly the email and phone columns already present on the transaction table. Snap matches those hashes against its own ad-exposure record on its side, so nothing leaving the warehouse is ever readable outside your environment, and no raw contact field crosses into Snap's systems at any point in the delivery.
Does this need a dedicated table just for Snap, separate from other destinations?
No. The same retail transaction table can feed Snap alongside other ad platforms at once, each with its own mapping and delivery schedule drawn from that single source. The data team maintains one table rather than a separate copy per destination, and adding a new platform later means adding a mapping, not a new pipeline.
NEXT STEP