Overview
Redpoint Identity Studio (RIS) runs natively inside your Snowflake environment on Snowpark Container Services as a “data-in-place” application; your data is persisted only within your Snowflake environment. You configure and review every merge decision as you tune to your own data and risk tolerance. This page walks through some example use cases for how teams use RIS in their data readiness workflows.
CRM deduplication before a CDP migration
When migrating CRM (Customer Relationship Management) data into a new CDP (Customer Data Platform), duplicate and conflicting records become a structural problem. Whatever issues exist in the source system get carried into the new platform, at scale, and it's much harder to untangle once campaigns, segments, and reporting are built on top of it.
RIS gives data teams a way to dial in match precision before that happens. The Overall Matching Tightness slider runs from -100 (looser) to +100 (tighter), adjusting how conservative or aggressive the matching logic is, relative to your current production settings, without anyone writing custom rules. If you need finer control than one slider, Detailed Tightness breaks that same adjustment out by field, Name, Date of Birth, Address, Phone, Email, Social, Account, and Other, so you can tighten matching on, say, email while leaving address matching untouched. Because getting this wrong before a migration is expensive to undo, RIS's A/B experiment framework runs a full copy of your proposed configuration against the same production data and lets you compare its match results side by side with your current settings before you commit.
Fixing the issues in your source system before your migration sets you up for the best possible results in your new CDP.
Household matching for direct mail
Direct mail costs money per piece, and every duplicate mailing to the same household is money spent twice for the same impression. RIS identifies which individual records belong to the same household by combining deterministic signals, like a shared last name and address, with probabilistic matching that catches the more complex cases: nicknames; maiden, hyphenated, or different last names; minor address variants; and similar near-matches.
Household matching runs as its own step in the Production job, after individual-level matching: RIS segments records into candidate households, then matches within those segments to confirm which records actually belong together. Once that's done, you can de-duplicate at the household level instead of the individual level, so a campaign sends one mailing per household rather than one per person. The match review workspace lets you inspect why any given household grouping was made before it goes to production, so marketing teams aren't taking the matching logic on faith. The result is a smaller, cleaner mail file and a direct reduction in printing and postage spend, with no loss of reach to the household itself.
Cross-channel identity resolution
Most enterprises hold pieces of the same customer's identity in different systems: web behavior in one platform, purchase history in another, call center notes in a third. None of those systems knows they're describing the same person unless something ties the records together.
RIS's INPUT table takes up to 14 categories of PII: name (with parsed first, middle, last, and generation), date of birth, gender, address, phone, email, social, account, and a custom "other" field, several of which support multiple alternates (three phone numbers, three emails, three social handles, and so on) so no channel's version of the data gets left out. Every record that comes in returns a GROUP_ID, a stable identifier for the person or household it belongs to. Because every source system's records resolve to the same GROUP_ID, downstream systems, including a data warehouse, a CDP, or a reporting layer, can use it as a universal customer key without needing their own matching logic. You get one consistent way to say "this record and that record are the same person," no matter which channel each one came from.
Post-merger customer record unification
A merger or acquisition means two (or more) organizations' customer files need to become one, and the records rarely line up cleanly. Formats differ, fields differ, and the same customer may exist in both companies' systems with slightly different variations.
Once the combined data lands in a shared INPUT table and you run a full production match, every record in the merged table gets evaluated from scratch, rather than treating the second company's records as an incremental add-on to the first's existing groups. Because merging multiple companies' matching logic is a one-time, high-stakes decision, the A/B experiment framework lets data stewards test candidate merge settings against the full combined dataset first, see how the two organizations' records would actually group together, and adjust before anyone commits to a production run.
Single customer view and unified customer profile
"Single customer view" is a goal that many organizations state but few actually achieve, mostly because the PII describing one customer is distributed across multiple systems that don’t interface with one other.
RIS makes that goal achievable in practice. You bring PII from across the enterprise, CRM, e-commerce, support, loyalty, etc., into RIS's INPUT table, and it resolves those disparate records to a single GROUP_ID per person or household. That GROUP_ID becomes the connective thread: the same identifier a marketing team uses to build a Customer 360 view is the one an analytics team uses to join records for reporting. Everyone works from the same resolved identity instead of rebuilding their own matching logic on top of the same fragmented sources.
Prospects vs. customers
Two related questions frequently arise in acquisition marketing: how many of the prospects we targeted actually converted to customers, and how many of the "new" leads coming in are actually existing prospects or customers we already know?
Both questions are identity resolution problems. When prospect records run through RIS alongside your existing customer file, records that resolve to the same GROUP_ID as an existing customer tell you that a prospect converted, giving you an accurate assessment of acquisition campaign performance instead of an estimate. The same matching logic works in the other direction on inbound leads: if a "new" lead's GROUP_ID already matches a customer or prospect record, you know immediately that lead isn't new, and sales and marketing can treat it accordingly instead of working it as a cold contact.
Suppression, consent, and preference reconciliation
Opt-outs, do-not-contact requests, and consent preferences are only enforced consistently if every duplicate record for that person carries the same flag. When a customer opts out on one record but three other duplicate records for that same person don't reflect it, your data quality issue becomes a compliance gap.
RIS resolves duplicate records to a single GROUP_ID per person, household, or family, so a consent or suppression flag attached to one record can be reconciled across every record that resolves to that same identity. Instead of enforcing preferences per record and hoping the duplicates were caught, you enforce them per resolved identity, which is what regulators and customers expect.
Marketing measurement
Reach, frequency, and attribution numbers are as accurate as your count of unique individuals, and duplicate customer records inflate that count. If the same person exists as three records in your data, your measurement treats them as three people, and your downstream metrics (e.g., spend efficiency, exposure, and attributed lift) inherit that inflation.
RIS collapses duplicate records to their GROUP_ID before measurement runs, giving you an accurate unique-person count as the foundation for reach and frequency calculations. Attribution and spend-efficiency numbers built on top of that resolved count are accurate and reliable.
Duplicate-account and synthetic-identity detection
The same PII, plus the INPUT table's ACCOUNT field, can surface a person operating behind multiple accounts, which is the pattern behind a lot of fraud, abuse, and loyalty-program gaming. If two accounts resolve to the same GROUP_ID, it’s worth taking a closer look.
Today, that signal surfaces during match review, not through automated fraud scoring. An analyst working through grouped records can see when the same identity shows up under multiple accounts, and RIS's manual overrides give them a mechanism to correct this: they can force-match records together or force-break them apart. A manual override decision takes precedence over the automated matching logic on every production run after that, making it a one-time fix. It's currently an analyst-driven capability, not an automated alert or a fraud score. Teams evaluating RIS for this use case should plan for match review as the starting point, with room to build more automated alerting or scoring on top of it as the need grows.