CONNECTIONS / Snowflake / Snowflake to Google EC for Leads
Snowflake stage history, feeding Google EC for Leads.
Most teams already land GCLID and CRM stage data in the same warehouse table through a nightly load or a dbt model. Signals reads that table on a schedule and returns hashed stage conversions to Google Ads as the join updates.
- ● snowflake → google.ec_leads :: live
- > sync table LEAD_STAGE_HISTORY rows=8,410
- hash sha256(email,phone) gclid=carried
- route google.ec_leads conversion_action="sql_reached"
- ✓ delivered · bid signal live
WHAT THIS ENABLES
Snowflake to Google EC for Leads
Snowflake to Google Enhanced Conversions for Leads reads a warehouse table that already joins captured GCLIDs with lead and opportunity stage history, then delivers hashed stage conversions to Google Ads so lead campaigns bid toward revenue instead of raw form-fill counts.
- A single warehouse table driving conversion actions for every stage your funnel tracks.
- Bidding weighted toward the rows your dbt models already mark as qualified.
- Attribution that survives a lost GCLID, since hashed identifiers carry the match forward.
WHAT FLOWS WHERE
Snowflake to EC for Leads, mapped.
A scheduled Snowflake read picks up new and changed rows from the stage history table, Signals hashes the identifiers on each, and Google's Enhanced Conversions API registers the result as a stage conversion.
A scheduled Snowflake read picks up new and changed rows from the stage history table, Signals hashes the identifiers on each, and Google's Enhanced Conversions API registers the result as a stage conversion.
Built for the teams that own the number.
Analytics engineers who would rather point Google at a table than build a bespoke API integration.
From kickoff to verified events.
-
Connect
A read-only Snowflake role scoped to the table or view joining GCLID capture with stage history.
-
Map
Stage columns tied to individual Google Ads conversion actions in the visual mapper.
-
Deliver
Scheduled delta reads deliver to the Enhanced Conversions API, with hashed identifiers as the fallback match key.
What ships with this use case.
Google campaigns judged on qualified pipeline drawn straight from your warehouse.
A feed that runs on the same schedule as the dbt job producing the table.
Identifier handling that satisfies Google's consent requirements without a manual export step.
What EC for Leads actually receives.
- ● signals :: event payload
- > POST /conversion_action source=snowflake.LEAD_STAGE_HISTORY
- gclid "Cj0KCQjw…" · conversion_action "sql_reached"
- conversion_value 1 · currency AED
- hashed_email sha256 "9c41af…"
- ✓ accepted match=gclid+hashed_email
Adjacent moves on the same stack.
from Snowflake
Snowflake to Meta Conversion Leads
Snowflake to Meta CAPI for CRM reads a funnel-stage table already maintained in your…
Learn more
from Snowflake
Snowflake to TikTok CRM
Snowflake to TikTok CRM Integration reads a pipeline-stage table already maintained in your…
Learn more
same use case
ActiveCampaign to Google EC for Leads
ActiveCampaign to Google EC for Leads: Signals reads your ActiveCampaign contacts and deal…
Learn moregeneric
Google Enhanced Conversions for Leads
Datahash pushes hashed user data from your CRM back to Google Ads so lead-based campaigns…
Learn moreAsked on almost every call.
Does every row in the Snowflake table need a captured GCLID?
No. Enhanced Conversions for Leads matches primarily on hashed email and phone, so a row that reaches the warehouse without a GCLID still counts through that path. Where a landing page captures the click ID and a nightly load writes it into the same table, attribution precision improves, and Datahash sets that join up during the build.
Which columns in our stage table should map to Google Ads conversion actions?
Whichever stages your warehouse already tracks as predictive of revenue, most commonly a qualified stage, an opportunity stage, and a closed-won flag, each becoming its own conversion action. Custom stage names from your CRM replica are mapped during the working session and the set can change later without touching the underlying read.
How is this different from running Offline Conversion Import out of Snowflake?
OCI matches purely on the GCLID stored in the table, so a row that never captured one is invisible to it. Enhanced Conversions for Leads adds hashed identifiers as a second match path, which keeps working even when a click ID goes missing somewhere in the load. Many teams run both off the same warehouse table at once.
NEXT STEP