Snowflake: One Platform for First-Party and Partner Identity Resolution

Authors: Punit Shah, Luke Ambrosetti

The Consistent Data Pain in Marketing

Identity resolution is one of the most important data and infrastructure problems in marketing — and it has been for years. The market’s response has been to add more vendors. More point solutions. More data copies. More contracts.

Most brands maintain three or four different identity graphs without realizing it — one in their CDP, one in their clean room, one from their identity vendor, one built internally. Each resolves the same person differently. The customer count in the activation platform doesn’t match the measurement platform, which doesn’t match the data warehouse.

The deeper issue is structural: customer data lives in silos that were never designed to share a common identity. Loyalty systems, web analytics, point-of-sale, call centers — each holds a fragment of the customer, stored in different formats, governed by different teams, often in different platforms entirely. You can’t resolve identity across systems you can’t even see in one place.

The problem isn’t too many tools. It’s that there’s no shared foundation — no single catalog of customer touchpoints that all those tools can draw from and resolve against.

There’s a better way. It starts with understanding that identity resolution has two layers — and the order you tackle them in determines whether everything downstream works or falls apart.

Two Types of Identity Resolution, One Platform

First-party identity resolution (1PD): Resolving your customers across your systems into a single view. The output is a master_customer_id that you own — built on your data, governed by your team, running in your environment.

Third-party identity resolution and enrichment (3PD): Leveraging a provider’s graph to either resolve identifiers you can’t match on your own, enrich your resolved identities with ecosystem pseudo IDs (RampID, UID2), or both. The output connects you to publishers, DSPs, and measurement platforms.

You need both. They’re complementary, and the sequencing matters enormously.

If you skip first-party resolution and go straight to a provider, you’re sending fragmented, duplicated identities into their graph. That leads to worse match rates, inflated audience counts, and duplicated spend. The foundation is first-party resolution. Third-party enhancement should build on it — not replace it.

This is no longer just a best practice. As third-party cookies, mobile ad IDs, and platform signals become less reliable, durable identity has to come from the data brands already own: email, loyalty, authenticated sessions, commerce events, service interactions, and consented customer touchpoints.

Cleaner input creates better resolution. Consistently. And a strong first-party graph is the best hedge against a signal landscape that keeps shrinking.

Building First-Party identity resolution in Snowflake

First-party resolution works in layers. Each pass catches what the previous one missed — from high-confidence exact matches down to ambiguous cases that need AI judgment.

But before matching can begin, you need visibility into what data exists. Customer touchpoints are scattered across internal systems, cloud storage, and external sources — often inaccessible, undiscovered or undocumented. Horizon Catalog makes every data asset discoverable and governed in one place, whether it lives in Snowflake, an external object store, or a connected data lake. Additionally, Data Sharing helps to give permissioned access to data across different domains and business units within your organization. The identity resolution pipeline operates on the full picture, no longer on a subset of your data.

Below, six customer records arrive over time — some are obvious duplicates (shared email or phone), others have subtle variations (nicknames, typos, different email domains). The engine processes them through four matching passes, progressively resolving fragments into unified identities.

Records resolve incrementally through four matching layers as they arrive.

Deterministic Matching (DET)

Exact match on known identifiers — email, phone, loyalty ID, device ID. When two records share a verified key, they’re the same person. In Snowflake, this is a self-join on standardized identifiers: collect identity pairs from source tables, match on normalized keys, then traverse the resulting edges to find connected components using iterative label propagation. High confidence, low cost. This resolves the majority of your graph if you have decent key coverage across systems.

Fuzzy Matching (FUZZY)

Handles the noise that deterministic can’t — typos, formatting variations, inconsistent abbreviations, nicknames. Snowflake provides native functions like JAROWINKLER_SIMILARITY and EDITDISTANCE for scoring candidate pairs, combined with blocking keys (zip code + first name, or zip code + last name) to keep the comparison space manageable. A nickname lookup table maps “Bob” to “Robert,” “Dave” to “David,” “Liz” to “Elizabeth” — so a fuzzy pass recognizes that “Bob Smith” and “Robert Smith” at the same phone number aren’t two customers. A “Maria Rodriguez” and “Marila Rodriguez” at the same address shouldn’t stay split because of a single typo.

For large scale matching, you may use Batch Cortex Search as well, by embedding identity attributes into vectors and retrieving semantically similar records — catching nicknames, misspellings, typos, and abbreviations that blocking keys may miss.

Probabilistic/ML Matching (ML)

Some candidate pairs don’t share a strong identifier — no common email, no matching phone number, no loyalty ID overlap. But they share enough weak signals to warrant evaluation: similar names, overlapping address components, co-occurring device fingerprints, matching behavioral patterns. These are the pairs that deterministic and fuzzy passes can’t confidently resolve on their own.

A trained model scores these candidates on weighted features — name similarity, address overlap, shared partial identifiers, temporal co-occurrence, behavioral signals. Train and deploy using Snowpark ML and the Model Registry, then batch-score candidate pairs directly in-warehouse. Pairs above a threshold merge automatically. Pairs below get dropped. The middle band — too uncertain for automation, too plausible to discard — moves to LLM-based adjudication or human review.

LLM Adjudication (LLM)

For the grey zone — pairs that score between confident-match and confident-reject — Cortex AI evaluates the full context of both records and makes a judgment. Use Snowflake Cortex AI functions such as AI_COMPLETE with a structured prompt containing both records’ attributes, and it returns a confidence score with reasoning. Auto-approve above 0.95. Surface to a human review queue between 0.60–0.95. Reject below 0.60.

The output of all four passes is a unified identity graph — connected components where every linked record resolves to a single master_customer_id. The graph updates incrementally: new records resolve within minutes via Streams and Tasks, without full rebuilds or nightly batch jobs. Dynamic Tables propagate resolved identities into golden-record profiles automatically.

This is your foundation. A clean, deduplicated, continuously-updating first-party graph — ready to activate, measure against, or extend into the broader ecosystem.

Building Third-Party resolution and enrichment in Snowflake

Once your first-party graph is clean, providers can do two things for you: resolve identities you can’t match on your own (using their broader data), and enrich your resolved identifiers with pseudo IDs that connect you to the advertising ecosystem.

Snowflake Data Sharing helps access data from thousands of Snowflake partners and customers without data movement accelerating your time to value. Many leading identity and enrichment providers — including Audience Acuity, Experian, LiveRamp, Merkle, TransUnion, and others — have deployed a Snowflake Native App on Snowflake Marketplace. Instead of sending your data to a provider, the provider’s graph comes to you. The mechanics are straightforward:

• Your PII (email, phone, MAID) and data stays in your account
• The provider’s Native App runs inside your Snowflake account
• Your identifiers go in — resolved clusters come back, ecosystem pseudo IDs come back, or both

Those pseudo IDs (e.g. RampID, UID2, Real ID) connect you to publishers, DSPs, and measurement platforms — activate audiences, measure conversions, suppress existing customers — all without exposing raw PII.

No data leaves Snowflake. For supported resolution or enrichment workflows, install the app, grant scoped access, and share the required table. For scenarios requiring bilateral governance (overlapping audiences, joint measurement, cross-brand collaboration), Data Clean Rooms provide the governance layer on the same platform.

With Native Apps, trust is enforced by the platform: apps run with explicitly granted privileges, and Snowflake provides isolation, access controls, and governed external-access mechanisms.

Other platforms require you to either (a) export data to the provider’s environment, (b) set up a separate API integration, or (c) maintain a data pipeline to keep identifiers in sync. Snowflake’s Native App model collapses all of that: the graph comes to you.

The compounding benefit: if you’ve already resolved your first-party graph, the identifiers you send to the Native App are cleaner and deduplicated. Better input → better match rates. The two layers reinforce each other.

What Identity Resolution Unlocks

Identity resolution isn’t the end goal — it’s the prerequisite for everything else working correctly. Bad identity → bad audiences → bad measurement → bad decisions.

• Activation: Deduplicated audiences for paid and owned channels. Accurate suppression so you’re not paying to target existing customers. Frequency capping that works across publishers. Cleaner conversion signals back to platforms (Meta CAPI, Google, TikTok) because you know who converted.
• Measurement: Attribution that correctly connects touchpoints to the same person across channels. Incrementality testing with clean holdout groups. Cross-channel journey analysis that isn’t stitched together from inconsistent identity across five systems.
• Operational efficiency: One identity pipeline replacing multiple vendor contracts and eliminating sync jobs between systems. Every redundant copy of customer data you eliminate is a compliance liability removed and a reconciliation problem solved.

All three get materially better when identity is resolved.

Getting Started: Build Your Foundation with CoCo

Building an identity resolution pipeline used to require deep data engineering expertise — graph theory, probabilistic matching, maintaining a complex DAG of incremental transformations. Most brands didn’t have that capability. So they bought a CDP or an identity vendor. Totally rational.

What’s changed: **Snowflake CoCo** is Snowflake’s AI-powered development environment. It understands Snowflake natively — SQL, Dynamic Tables, Cortex AI, Streams, Tasks — and can help generate, review, and iterate the logic needed for an IDR pipeline that teams can test, govern, and promote into production. You describe your source systems, and the engine generates a pipeline tailored to your schema: standardization rules mapped to your column semantics, matching rules with configurable weights and thresholds, iterative graph resolution, source-priority survivorship for golden records, and review queues for ambiguous matches.

The pipeline is config-driven — match rules, fuzzy thresholds, source priorities, and AI adjudication settings are all stored as data. Tune your identity graph without rewriting SQL.

For organizations seeking to layer partner-driven capabilities atop their foundation, a new generation of CDPs and identity specialists — such as Amperity, GrowthLoop, Hightouch, and Simon Data, along with providers like Zingg and Truelty — are now built natively on Snowflake. This architectural shift means that even when you choose to leverage external expertise, your data remains in place. There is no need for fragile exports, redundant copies, or the maintenance of complex synchronization workflows.

Now, it necessarily isn’t a build or buy decision. You can start your foundation using CoCo, then layer partner capabilities where you need them. The foundation is yours. The enhancements are optional and interchangeable.

Conclusion

One platform. One governance model. One set of roles and permissions covering PII from ingestion through resolution. No data copies, no sync jobs, no “which system has the truth?” conversations.

Three concrete next steps:

• Map your current identity architecture — How many copies of PII exist? How many integrations maintain your current identity graph? Where are the gaps?
• Zero ETL access of data from any source — Use Snowflake Data Sharing to de-silo data across hundreds of applications, system of records, and business units within a few clicks.
• Try building with CoCo — open CoCo and experiment. Describe your source systems, and see what pipeline it generates against your actual data. We have a full solution accelerator that provides some opinionated ways to help you get started. Alternatively, here is a CoCo skill to help with building something yourself.
• Explore identity provider Native Apps on Snowflake Marketplace — LiveRamp, TransUnion, Audience Acuity, and others are all there. Install one, run a test resolution against a sample, compare match rates to your current approach. Work with your Snowflake Account team to help you get started here.