CONNECTIONS / Snowflake / Snowflake to Google Customer Match
From Snowflake tables to Customer Match lists.
Grant Signals a read-only role, choose the table, and your Snowflake segments show up in Google Ads as Customer Match audiences that stay in step.
- ● snowflake → google.customer_match :: live
- > sync table REPEAT_BUYERS rows=53,660
- hash sha256(email,phone)
- route google.customer_match upsert
- ✓ list refreshed · 48,177 matched
WHAT THIS ENABLES
Snowflake to Google Customer Match
Snowflake to Google Customer Match reads customer segments straight from your Snowflake tables and keeps Google Customer Match lists in sync with hashed adds and removals on the schedule you choose, so Smart Bidding and lookalike audiences always reflect your actual best customers.
- Snowflake segment tables projected into Google Ads without an ETL detour.
- Audiences refreshed whenever your warehouse tasks rebuild the underlying table.
- Customer suppression governed by the same data your BI already trusts.
WHAT FLOWS WHERE
Snowflake to Customer Match, mapped.
Each scheduled Snowflake sync moves segment rows into Signals, where they are hashed before Google's Customer Match API applies the adds and removals.
Each scheduled Snowflake sync moves segment rows into Signals, where they are hashed before Google's Customer Match API applies the adds and removals.
Built for the teams that own the number.
Growth teams who want Google audiences fed straight from dbt output.
From kickoff to verified events.
-
Connect
A dedicated Snowflake role with SELECT on the schema you nominate.
-
Map
Identifier fields aligned to Google's spec and hashed during each read.
-
Deliver
Delta syncs on your schedule with per-list matched-size visibility.
What ships with this use case.
Warehouse-defined cohorts targetable across Google's ad surfaces.
Removals honored on every sync, so lapsed members stop being targeted.
Delta reads that scan only the rows changed since the last sync, so cost stays predictable against the warehouse size you assign.
What Customer Match actually receives.
- ● signals :: audience upload
- > POST /user_list_operations source=snowflake.REPEAT_BUYERS
- operation ADD · user_list "repeat_buyers"
- hashed_email sha256 "b02cf1…" · hashed_phone sha256 "3ad990…"
- members_uploaded 53,660 · members_matched 48,177
- ✓ accepted match=90%
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 TikTok Custom Audience
Snowflake to TikTok Custom Audience keeps TikTok's Custom Audiences synced with a segment…
Learn more
same use case
ActiveCampaign to Google Customer Match
ActiveCampaign to Google Customer Match: Signals reads your ActiveCampaign contacts and…
Learn moregeneric
Google Customer Match
Datahash builds and refreshes Google Customer Match audiences from your CRM, warehouse, or…
Learn moreAsked on almost every call.
How often does the Customer Match list refresh from Snowflake?
Daily is the common default, though the underlying warehouse task can run anywhere from every fifteen minutes to weekly depending on how often the segment table actually changes. Each run sends only the rows added or dropped since the previous sync rather than the full table, so a tighter schedule does not add meaningful load to your Snowflake compute.
What happens if a Snowflake-sourced list drops under Google's serving threshold?
Google will not serve a Customer Match list on most surfaces once its matched, active membership falls under a minimum size. Datahash checks that count after every sync and flags any table producing a list near or under the line, so a narrowing segment shows up as an alert rather than a silent drop in reach.
Does a wider Snowflake warehouse size make the sync faster?
A larger warehouse can shorten the time a scheduled read takes, but the sync itself is delta based, so it already scans only the rows changed since the last run regardless of warehouse size. Most teams run the read role on a small or medium warehouse and reserve larger sizes for the BI workloads that actually need them.
NEXT STEP