CONNECTIONS / Snowflake / Snowflake to TikTok Offline eAPI
Snowflake's in-store sales, reconciled inside TikTok's pipeline.
TikTok's pixel never sees a transaction rung up over the phone or at a till, only the ledger your warehouse already reconciles it into. Signals reads that table and reconciles it against TikTok's Offline Events API with hashed identifiers and a stable event ID.
- ● snowflake → tiktok.offline_eapi :: live
- > sync table INSTORE_SALES_LEDGER rows=5,380
- hash sha256(email,phone)
- route tiktok.offline_eapi dedupe=event_id
- ✓ delivered · match 62%
WHAT THIS ENABLES
Snowflake to TikTok Offline Events API
Snowflake to TikTok Offline Events API reads an in-store sales table already maintained in your warehouse and reconciles it against TikTok's Offline Events API, each row carrying a stable identifier so a re-synced record never double counts a sale that already reached TikTok.
- In-store sales already sitting in Snowflake feeding TikTok's own campaign optimization.
- One identifier per row that survives a retried or overlapping read without inflating the count.
- Offline delivery on a cadence that fits however often the sales table itself refreshes.
The click, the conversion, and the credit.
The conversion happens off TikTok, away from any pixel. Here is how Snowflake closes the loop.
Built for the teams that own the number.
Teams whose real revenue rings up over the phone or at the till, not through the app.
From kickoff to verified events.
-
Connect
A read-only Snowflake role scoped to the in-store sales table and its contact columns.
-
Reconcile
Sales rows matched against a stable event identifier derived from the table, per TikTok spec.
-
Deliver
Each batch lands at TikTok's Offline Events API on schedule, watched for duplicates the whole way through.
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 eAPI 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 eAPI actually receives.
- ● signals :: event payload
- > POST /event/track source=snowflake.INSTORE_SALES_LEDGER
- event "CompletePayment" · event_time 1784317860
- user.email sha256 "c02fa8…" · user.phone sha256 "6b91dd…"
- properties.value 19400 · properties.currency GBP
- ✓ accepted · dedupe=event_id
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 TikTok Offline eAPI
ActiveCampaign to TikTok Offline Events API: Signals reads your ActiveCampaign contacts and…
Learn moregeneric
TikTok Offline eAPI
Move your in-store and call-centre conversions to TikTok server-side, so TikTok can…
Learn moreAsked on almost every call.
How does TikTok avoid double-counting a row that syncs twice from Snowflake?
Every event keys off an identifier pulled from the sales row itself, not from whatever time the sync happened to run. A retried batch or an overlapping scheduled read that touches the same row again does not add a second sale, since TikTok checks that identifier before crediting anything.
What other tables besides in-store sales can reach TikTok's offline pipeline?
Any table your warehouse records as a distinct conversion can be mapped, though in-store sales is the one most retail teams start with because it is the outcome TikTok's bidding optimizes toward. A call-centre sales table can be added later without rebuilding the underlying read.
Does the sales table need to be purpose-built for this sync?
No. This table almost always already exists for finance or ops reporting, so Signals reads it in its current shape rather than requiring a purpose-built export. A later change to the underlying dbt model just means updating the mapper once before the next scheduled read picks up the new columns.
NEXT STEP