Resonate Enrichment On-Demand Snowflake Clean Room

Overview

The Resonate On-demand Clean Room is a Snowflake Native Application that enables secure, privacy-compliant data enrichment directly within your organization's own Snowflake environment. It allows agencies and brands to enrich first-party customer data with Resonate's proprietary behavioral, demographic, and psychographic attributes — without transferring files, waiting days for delivery, or exposing sensitive data to either party.

Resonate acts as the data provider. You, as the client, act as the consumer. The clean room architecture ensures:

• Your customer IDs and raw data are never seen by Resonate
• Resonate's full attribute dataset is never exposed to you
• Enrichment results are delivered directly into your Snowflake environment (no matter which environment you use) within hours

This guide covers everything your engineering team needs to get started: prerequisites, environment setup, job invocation, output schema, and error handling. If you are an existing Resonate Append customer, see Section 7 for a dedicated transition guide.

Note: This guide is written for engineering and implementation teams. For business context on use cases and value, see your Resonate Customer Success contact.

Why Use the On-demand Clean Room

The clean room solution is designed for agencies and brands that need a faster, more secure, and operationally simpler alternative to traditional file-based data append. Key advantages include:

Speed

• Enrichment jobs complete in hours, not days.
• On a large enough warehouse, such as a 4x-large, even an input size of nearly 100 million records completes in less than 30 minutes.

Privacy & Security

• Customer IDs remain in your Snowflake environment — Resonate never sees them
• Resonate's underlying dataset is never exposed to the consumer
• HEM, MAID, and IP are accepted as inputs (email addresses must be hashed)
• Sensitive attributes are automatically redacted as required by law

Operational Simplicity

• No file transfers, no SFTP setup, no manual handoffs
• Enrichment runs on-demand via SQL — on any cadence you choose
• Results are delivered as Snowflake tables inside your installed native app for immediate use
• Compatible with all Snowflake cloud provider/US region combinations

Common Use Cases

• Enrich a CRM or CDP customer list for audience segmentation
• Identify high-value targets for multi-channel campaign planning
• Blend enriched attributes with internal data sources for analytics
• Feed enriched segments into activation platforms (e.g., Ignite)

Prerequisites

Before getting started, confirm the following requirements are met on your Snowflake account:

Important: Unhashed or plaintext PII (e.g., raw email addresses, names) cannot be submitted as input. The input validation will fail if enough unhashed PII is detected such that the percentage of valid IDs falls below threshold. The append job will not match such identifiers.

Onboarding & Access

Access to the Resonate On-demand Clean Room is provisioned by Resonate — it is not self-serve through Snowflake Marketplace at this point in time.

Step 1: Receive Your Invite

Resonate will send a direct invite to your Snowflake account. Once you accept the invite, the Resonate enrichment application will become visible in your environment. You will receive confirmation instructions from your Resonate Customer Success contact.

Step 2: Validate Your Environment

Resonate will provide a QuickStart guide Resonate Snowflake Clean Room Enrichment Setup Guide containing SQL snippets to validate your environment. Run the provided SQL to confirm:

• Your account has the required roles and permissions
• Your compute warehouse is configured and active
• End-to-end connectivity to the enrichment service is working

If required roles or permissions are missing, Snowflake will return standard SQL error messages. Refer to the QuickStart documentation to resolve them.

Step 3: Role Provisioning

An administrator in your Snowflake account must ensure your user role has the following privileges that are required to use the enrichment application.

1. You must be able to grant the app read access to the database, schema, and table where your input data lives. To act on each of those three objects you must fulfill one of the following:
   • Be ACCOUNTADMIN
   • Have OWNERSHIP of the object
   • Have the same privilege you are trying to grant to the app (USAGE on database/schema, SELECT on table) and have been delegated authority "WITH GRANT OPTION" for the privilege
2. You must be able to call the procedures provided by the application, which are exposed to the consumer through the application role "app_user". This requires you to fulfill all of the following:
   • Have OWNERSHIP or USAGE on the application (automatic if you are the one who installed the application)
   • app_user has been granted to you (automatic if you are the one who installed the application)
   • Have USAGE on the warehouse you wish to use

Input Requirements

Enrichment is invoked by calling a stored procedure or SQL command against an input table in your Snowflake environment. Your input table must conform to the following requirements.

Supported Identifier Types

The enrichment service accepts the following identifier types. At least one must be present in your input table:

Example File Formatting for Snowflake Input Column Headers:

Waterfall Matching Logic

When multiple identifier types are present in your input table, the enrichment service applies waterfall matching in the following priority order:

1. HEM (highest priority)
2. MAID
3. IP address (lowest priority / fallback)

If a record matches on HEM, Resonate will not attempt MAID or IP matching for that record. If HEM does not yield a match, the service falls back to MAID, then IP. The MATCHED_ID_TYPE field in your output will indicate which identifier was used for each customer record.

Running an Enrichment Job

All tables created by the application go into the schema INST.

All procedures defined by the application live in the schema CORE.

Here is an example of how to use the application. At the top right the selected database is the name you gave to the clean room application at the time of installation.

1. Before you call any procedures, grant the application access to your input table, which requires USAGE on the database and schema and SELECT on the table.
2. If this is your first time using the application, call core.health_check to see if the application can reach the necessary tables at Resonate. If the status says healthy, then you are good to proceed. Otherwise, take note of which tables are reported as not accessible, and inform your contact at Resonate.
3. Call core.run_validation(your input table) to determine if it is healthy enough for enrichment. This run will produce a row_level_validation table for your input, which assesses each of your rows for validity, and add one row to the validation_summary table, which assigns a pass/fail status to your input and provides the metrics that explain the decision. If passed, proceed to run the enrichment. Otherwise, try to fix the problems highlighted by the metrics, and contact Resonate if you need assistance or if you believe your input is actually valid and was incorrectly flagged as failed.
4. Call core.run_append(your input table) to perform the enrichment. This in turn internally calls core.enrich_ids(your input table), core.generate_key_definitions(enriched output table), and core.generate_summary(enriched output table) to produce the three deliverable tables described within this document: enriched_ids, key_definitions, and summary. These are suffixed with both your input table name and the current timestamp, so that rerunning the same input will produce a new set of tables. You could call any of those three procedures independently, such as after a transient resource failure where the enrichment already succeeded but the supplementary tables had not been created yet, but in general you only need to call run_append.
5. If you wish to drop any tables from the application, you can call drop_table for a single table, drop_prefix/drop_suffix for all tables with a given prefix/suffix, or drop_all_output for a complete wipeout. Ignore the procedure _override_dataset_view, as that is internally used by Resonate during tests.

Job Status & Visibility

There is no separate job status UI in Phase 1. Use Snowflake's built-in tools to monitor enrichment jobs:

• Snowflake Query History — view whether your job is running, complete, or errored
• Snowflake Task Logs — review execution details
• If a job fails, error details will appear in the SQL error output

Output Schema

When enrichment completes, three tables are placed directly into your Snowflake environment within the application:

• Append Output Table — enriched results for matched records
• Key Definitions File — maps survey_value_keys to human-readable attribute names and descriptions
• Summary Table — fill rate, sensitive attribute flag

Append Output Table Schema

The output uses a rectangular (narrow and tall) format optimized for Snowflake. Each row represents one customer-attribute combination.

Sample Output Data

Key Observations About the Output Format

• Each row represents a single customer-attribute combination — an unrestricted customer with 500 attributes will have 500 rows
• MATCHED_ID_TYPE shows which identifier was used for the waterfall match — useful for understanding match quality
• NULL in PREDICTION indicates a sensitive attribute that was legally redacted for a restricted customer — it does not mean no data was found
• For a restricted customer, every sensitive attribute that you purchased will appear in the output with a NULL prediction, while nonsensitive attributes appear if TRUE as usual
• CUSTOMER_ID enables you to join enrichment results back to your source data
• SURVEY_VALUE_KEY joins to the KEY_DEFINITIONS table to retrieve attribute names and descriptions

Joining to Key Definitions

To get human-readable attribute names alongside your enriched data, join the output table to the KEY_DEFINITIONS table:

SELECT o.CUSTOMER_ID, o.MATCHED_ID_TYPE, o.PREDICTION,
    k.ATTRIBUTE_NAME, k.ATTRIBUTE_VALUE_NAME
FROM YOUR_OUTPUT_TABLE o
JOIN KEY_DEFINITIONS k
    ON o.SURVEY_VALUE_KEY = k.SURVEY_VALUE_KEY;

Summary Table

Alongside the append output, every job produces a summary table containing for every attribute:

• The number of customers that have the attribute
• The above count as a percentage of matched customers
• Whether or not the attribute is sensitive data

Error Handling

Every consumer-facing procedure (core.run_validation, core.run_append) returns a structured JSON response — not a raw Snowflake error. Always inspect the response's status, message, and hint fields to understand what happened and what to do next.

Response Shape

On success, run_append returns:

{
  "status": "OK",
  "enriched_table":        "resonate_cleanroom_enrichment_app.inst.enriched_ids_abc123",
  "key_definitions_table": "resonate_cleanroom_enrichment_app.inst.key_definitions_abc123",
  "summary_table":         "resonate_cleanroom_enrichment_app.inst.summary_abc123"
}

On failure, run_append returns:

{
  "status": "ERROR",
  "message": "Enrichment failed: Input table row count (250000000) exceeded the maximum allowed (200,000,000).",
  "enriched_table":        null,
  "key_definitions_table": null,
  "summary_table":         null,
  "errors": {
    "enrichment":      "Input table row count (250000000) exceeded the maximum allowed (200,000,000).",
    "key_definitions": null,
    "summary":         null
  },
  "hint": "Reduce the input table to 200,000,000 rows or fewer and retry."
}

run_validation returns the same basic shape (status, message, hint) plus row_level_validation_table on success.

If you're calling from a SnowSQL or Snowsight worksheet, the full JSON appears as a single cell in the results grid — click into the cell to expand it, or use TRY_PARSE_JSON(result):status::STRING to extract individual fields.

How to Read a Failure

1. status — "OK" means the job completed fully. "ERROR" means at least one step failed. For run_append, the three *_table fields indicate which outputs were still produced before the failure; any non-null value is a real table you can still query.
2. message — a human-readable summary. For validation-time failures the message is specific. For failures deep inside the pipeline, the message is intentionally generic to avoid exposing internal implementation details. The detailed Snowflake error is captured in Resonate's event table for support.
3. hint — suggested next step. Depending on the failure it may contain ready-to-paste SQL or an invocation_id / job_id. When contacting Resonate support about a failure, always include the ID from the hint.
4. errors (present on run_append failures only) — breaks out per-step error text. Useful for distinguishing between a full failure and a partial failure where enrichment succeeded but the key-definitions or summary table could not be produced.

Common Error Conditions

Where Error Detail Is Recorded

• Structured JSON response (primary surface) — returned by every procedure call.
• App event table (secondary surface, for Resonate support) — every call emits telemetry keyed by invocation_id or job_id. Support uses this to diagnose failures where the consumer-facing message is intentionally generic.
• Snowflake Query History — useful for confirming the CALL executed, how long it took, and which warehouse ran it. It does not contain the procedure's structured JSON response body.

Contacting Support

If the hint doesn't resolve the issue, email customersupport@resonate.com with:

• Your client ID
• The procedure you called and the input table you passed
• The full JSON response returned by the procedure — in particular the status, message, hint, and any invocation_id or job_id
• The approximate time you ran the call

The invocation_id / job_id is the single most useful piece of information — it lets support locate the raw error log for your specific run instantly.

Privacy & Compliance

The On-demand Clean Room is architected to enforce privacy for both Resonate and the client:

• Only hashed email addresses are accepted as input — unhashed PII will not pass validation
• Resonate never sees your CUSTOMER_IDs or the contents of your input table
• You never see Resonate's full underlying dataset — only attributes for records that matched your inputs
• Sensitive attributes are automatically redacted and appear as NULL in outputs

Compute Costs

Enrichment jobs run on your Snowflake compute warehouse and are billed by Snowflake directly — not by Resonate. These are standard Snowflake virtual warehouse credits billed per second of usage.

For example, an enrichment job on 16K records using a 3x-large warehouse ran for about 3 minutes and consumed 3.09 credits, which costs $6.18 for a standard account. If your organization has pre-purchased Snowflake capacity, these jobs draw from your existing committed spend, which may effectively reduce marginal cost to near zero.

For questions about Snowflake billing, work with your Snowflake account team to understand current credit burn and available capacity.

Guide for Existing Resonate Append Customers

If you are currently using Resonate's file-based Data Append service, this section explains your options, what changes between the two products, and what — if anything — you need to do.

Key Point: No action is required if you want to continue using your current Resonate Append setup. The clean room is a separate, opt-in offering. Your existing file-based Append workflow will not be affected.

Option A: Adopt the Clean Room Instead of File-Based Append

You may choose to migrate fully from file-based Append to clean room delivery. This means Resonate will no longer deliver enrichment files to your Box, SFTP, or AWS location — instead, results will be written directly into your Snowflake environment.

Benefits of migrating:

• Results in hours instead of weeks
• No file transfer or ingestion pipeline to maintain
• Run enrichment on any cadence — not limited to monthly batches
• Simpler data governance with no files leaving Snowflake

To migrate, work with your Resonate Customer Success contact to initiate onboarding and confirm your Snowflake environment prerequisites (see Section 3).

Option B: Add the Clean Room Alongside File-Based Append

You may also choose to use both delivery methods. For example, you might continue receiving monthly file-based Append for archival purposes while also using the clean room for on-demand, real-time enrichment runs during campaign planning.

Contact your Resonate Customer Success contact to discuss how to configure this arrangement.

What Changes If You Use the Clean Room

The following is a summary of the key differences between file-based Append and the clean room offering that your engineering team should be aware of:

Output Schema Changes

The most significant technical change for existing Append customers is the output format. The clean room uses a rectangular (narrow and tall) schema rather than the pivoted (wide) format used in file-based Append.

Why the new format:

• The pivoted format used by file-based Append is not Snowflake-friendly for large attribute sets
• The rectangular format is optimized for Snowflake querying and scales efficiently regardless of attribute count
• Joining to the KEY_DEFINITIONS table is simpler — join on SURVEY_VALUE_KEY rather than unpivoting column names
• CUSTOMER_ID in every row makes it straightforward to join back to your source data

If you have downstream pipelines or reporting built on the Append output schema, those will need to be updated to consume the new rectangular format before switching to clean room delivery. The Key Definitions Table remains unchanged, while the Summary Table provides the information described in the "Summary Table" section.

The Clean Room Output Format:

Standard Output File Format for Append File Transfer:

Pivoted Output File Format:

Address Match Limitation

The current clean room offering does not support name/address-based matching. If your Append use cases depend on address match (using Resonate's Smarty-driven matching), file-based Append remains the appropriate solution for those records. You can continue using file-based Append for address-matched records while using the clean room for HEM, MAID, and IP matching.

Prerequisites for Existing Append Customers

If you are an existing Append customer adopting the clean room, confirm:

• You have an active Snowflake account (any cloud provider/US region combination is supported)
• You have permissions to accept a Snowflake invite and run enrichment jobs
• You have reviewed and updated any downstream pipelines that consume the Append output to support the new rectangular schema

Input Table Formatting Guidelines

Before invoking an enrichment job, your input data must be loaded into a Snowflake table in your own environment. This section describes the required table structure, column specifications, data formatting rules, and validation checks your engineering team should perform before submitting a job.

Note: Resonate never sees your raw input table; only the installed application reads it. Formatting your table correctly is required for the enrichment procedure to execute successfully.

Required Input Table Structure

Your input table must contain a CUSTOMER_ID column and at least one supported identifier column. Additional identifier columns are optional but recommended to maximize match rates through waterfall matching.

*At least one identifier column (HEM, MAID, or IP_ADDRESS) is required. Including multiple identifier types is strongly recommended to maximize match coverage through waterfall matching.

Column Formatting Rules by Identifier Type

HEM (Hashed Email Address)

• Accepted hash algorithms: SHA-256, SHA-1, MD5
• Hash values must be lowercase hexadecimal strings
• SHA-256 produces 64-character strings; SHA-1 produces 40-character strings; MD5 produces 32-character strings
• Email addresses must be normalized before hashing: lowercase, trimmed of whitespace
• NULL values in the HEM column are permitted — the waterfall will fall through to the next identifier

Example valid HEM values (MD5):

d8578edf8458ce06fbc5bb76a58c5ca4
5d41402abc4b2a76b9719d911017c592

MAID (Mobile Advertising ID)

• Accepted formats: IDFA (Apple iOS) and GAID (Google Android)
• Must be formatted as a standard UUID string: 8-4-4-4-12 character groups separated by hyphens
• Values should be lowercase
• Do not include braces, spaces, or other non-standard characters
• NULL values are permitted — the waterfall will fall through to the next identifier

Example valid MAID value:

3b4c1a2d-5e6f-7890-abcd-ef1234567890

IP_ADDRESS (IPv4)

• Standard dotted-decimal IPv4 notation only (e.g., 203.0.113.45)
• IPv6 addresses are not accepted and will not match anything
• Only residential IPs will return enrichment results — commercial and non-residential IPs will not match
• IPs originating outside the US will not return results
• Must be a valid public IP address — private/internal IP ranges (e.g., 192.168.x.x, 10.x.x.x) will not match
• NULL values are permitted — records with no matching IP will simply not match on this fallback

Example valid IPv4 values:

203.0.113.45
198.51.100.22

General Table Requirements

• All columns must be VARCHAR / STRING type — do not use integer, float, or other data types for identifier columns
• One row per customer — CUSTOMER_ID must be unique within the input table
• Empty string values ('') should be converted to NULL before submitting — empty strings may cause unexpected behavior
• Column names must match exactly as specified above — the enrichment procedure references columns by name
• Column names are case-insensitive in Snowflake, but using the exact casing shown is recommended for clarity
• There is no maximum column count — additional columns beyond the required set will be ignored by the enrichment procedure

Null Handling & Partial Records

Records with NULLs in one or more identifier columns are fully supported. The waterfall matching logic will attempt each non-NULL identifier in priority order:

• A record with only a MAID (no HEM) will skip HEM matching and proceed directly to MAID matching
• A record with only an IP address will skip HEM, MAID matching and attempt IP matching only
• A record with no valid identifiers in any column will not match and will not appear in the output

There is no penalty for NULL identifiers — they simply reduce the available fallback options for that record.

Pre-Submission Validation Checklist

Before invoking an enrichment job, run these checks against your input table:

Support

For implementation assistance, onboarding questions, or attribute mapping help, contact Resonate support:

Email: customersupport@resonate.com

When contacting support, include: your client ID (provided by Resonate), a description of the issue, and any relevant Snowflake error codes or job IDs.

Appendix: Quick Reference

Supported ID Types at a Glance

Output PREDICTION Field Values

Onboarding Checklist

1. Confirm you have an active Snowflake account
2. Confirm you have permissions to accept invites and install apps
3. Confirm you have an active compute warehouse
4. Prepare your input table with at least one supported ID type
5. Accept the Snowflake invite from Resonate
6. Run the health check and input table validation to confirm readiness
7. Invoke your first enrichment job
8. Validate output by joining to KEY_DEFINITIONS