CONNECTIONS / Snowflake / Snowflake to Snap Custom Audience
Snowflake segments, refreshed automatically into Snap.
Once you point Signals at the segment table, it keeps the matching Snap audience current on its own, hashing every identifier before upload and shipping only the rows that changed since the last cycle.
- ● snowflake → snap.custom_audience :: live
- > sync table LOYALTY_SEGMENT rows=24,380
- hash sha256(email,phone)
- route snap.custom_audience upsert
- ✓ audience refreshed · 17,730 matched
WHAT THIS ENABLES
Snowflake to Snapchat Custom Audience
Snowflake to Snapchat Custom Audience keeps Snap's audience lists synced with a segment table your data team already maintains, refreshing adds and removals on the schedule the underlying warehouse task runs, so suppression and lookalike campaigns stay current.
- Segment tables in Snowflake mirrored into Snap Ads Manager without a manual export.
- A ready lookalike source: whichever cohort your dbt scoring already flags as top-tier, no separate export needed.
- Existing customers suppressed from Snap acquisition spend the moment the table refreshes.
WHAT FLOWS WHERE
Snowflake to Custom Audience, mapped.
A scheduled Snowflake read picks up changes to the segment table, Signals hashes each row, and updates the Snap Custom Audience with the corresponding adds and removals.
A scheduled Snowflake read picks up changes to the segment table, Signals hashes each row, and updates the Snap Custom Audience with the corresponding adds and removals.
Built for the teams that own the number.
Data teams still scripting a CSV pull from Snowflake every time Snap's audience needs a refresh.
From kickoff to verified events.
-
Connect
Signals is granted SELECT only on whichever table or view your data team already treats as the segment.
-
Segment
Membership stays defined entirely inside that object, Signals only reads it and hashes each identifier at the point of upload.
-
Sync
Each scheduled read pushes only the delta to Snap, refreshing the audience without a full re-upload.
What ships with this use case.
Suppression of existing warehouse-defined customers from Snap acquisition spend.
Lookalike seeds built from high-value cohorts your segment table already identifies.
One less recurring export for the data team to remember, since the table drives the audience directly.
What Custom Audience actually receives.
- ● signals :: audience upload
- > POST /audience_match source=snowflake.LOYALTY_SEGMENT
- schema ["EMAIL_SHA256","PHONE_SHA256"]
- external_audience_id "snow_loyalty_segment"
- id_list_size 24,380 · matched 17,730
- ✓ accepted match=73%
Adjacent moves on the same stack.
from Snowflake
Snowflake to Meta Custom Audience
Snowflake to Meta Custom Audience keeps Meta's Custom Audiences built from whichever table…
Learn more
from Snowflake
Snowflake to Google Customer Match
Snowflake to Google Customer Match reads customer segments straight from your Snowflake…
Learn more
same use case
ActiveCampaign to Snap Custom Audience
ActiveCampaign to Snapchat Custom Audience: Signals reads your ActiveCampaign contacts and…
Learn moregeneric
Snap Custom Audience
Build and refresh Snap audiences from your CRM, warehouse, or SingleView with hashed…
Learn moreAsked on almost every call.
Which columns does Snap use to match a row from our warehouse table?
Whatever identifier columns the table or view carries, most commonly email and phone, plus a mobile advertising ID where the schema has one. Every value is hashed inside Signals before it leaves your environment, and the sync uses whichever combination the source columns actually support.
Can one Snowflake table drive audiences on Snap and other channels together?
Yes. A single table or dbt model output can fan out to Snap, Meta, Google, and TikTok in parallel, each destination running its own hashed key handling and refresh schedule off the same underlying definition, so the data team is not maintaining a separate export per ad platform.
Does the segment need to be a physical table, or can it be a view?
Either. Signals reads whichever object your team already uses to define the segment, and a view built on top of a dbt model works the same as a materialized table as long as the read role has SELECT on it.
NEXT STEP