There’s no need to build Docker images, configure container registries, or manually provision infrastructure. Scaling to multiple nodes or GPUs is a parameter change, not an architecture rewrite. Submitting a new version of a job, updating requirements, or adding a pipeline step is a specification change. Once a template is approved, it is executed via a single SQL call from any orchestrator according to the schedule you set.
The development workflow is designed to avoid friction at clean room boundaries. You can use the same Python scripts and container runtime to build and test complete ML job workflows outside of the Snowflake Data Clean Room (DCR) within a standard Snowflake environment. Once built and tested, you can incorporate it into your collaboration using code specs with fixed image versions, locking down the versions of dependencies used for development and testing. This means that iterations occur in your regular development environment, and you can seamlessly deploy and operationalize workloads in DCR.
ML job workloads are designed to run as production pipelines rather than one-time experiments. Once a template is approved, you can schedule it at any frequency, trigger it from upstream data events, or adjust it from automation tools like Snowflake Tasks, Airflow, or any system that can run SQL calls.
Operationally, the activity history of all job executions can also be queried in Snowflake, providing an audit trail of analysis executions. Additionally, if something goes wrong, you can enable monitoring of your ML jobs to access standard container logs for debugging.
use case
Incremental measurement without data intermediary
To measure true sales growth from advertising, you need to combine ad exposure data with purchasing results between parties. Historically, this required a neutral third party to hold the combined data and critical custom infrastructure. This is a high-friction path that most advertisers skip.
With ML Jobs, brands and retailers execute improvement models within collaboration. Impression logs remain in the brand’s account, transaction data remains in the retailer’s account, and the model is trained on the join. Causal lift measurement, which previously required a dedicated data science project, is now a repeatable workflow for each campaign. Campaign teams get real signals about what’s working, not proxy metrics.
Retail media attribution at transaction scale
Retailer transaction data is one of the most valuable signals for attribution, but its competitive sensitivity has made it virtually inaccessible to media agencies and DSPs. ML jobs allow you to run attribution models where your data lives. Retailer records are never moved. Model outputs, including attribution weights and conversion lift estimates, are shared downstream.
ID crosswalk to improve match rate
The elimination of third-party cookies has significantly reduced the definitive match rate of many advertising programs. If the range of hashed email or device IDs is partial, a deterministic join will leave a large portion of the audience unmatched. To close this gap, first-party advertiser data, such as customer relationship management (CRM) records and conversion history, must be combined with graphs from third-party identity providers that map device IDs, hashed emails, and mobile advertising IDs across publishers.
Probabilistic identity resolution, a model trained to match records across identity space using behavioral and contextual signals, can recover meaningful match increases, but requires scale and dedicated computing. ML Jobs provides that in a clean room. The advertiser’s first-party CRM data and third-party identity provider graphs train the resolution model without either party’s records leaving the account. If deterministic combining leaves a large portion of the audience unmatched, a properly trained resolution model will fill the gap. Additionally, the model can be retrained as identity coverage changes, so the match rate does not simply drop over time, but instead remains degraded.
From similarity scoring to campaign optimization agents
Similarity modeling produces a ranked list of users similar to your seed audience, a static score at a point in time. Campaign optimization agents go further and, given a campaign overview, budget, and objectives, combine signals from multiple parties and make inferences to recommend which audience segments to target, in what context, and at what bid levels.
Differences in training data make this possible within a clean room. Similarity models train the publisher’s user characteristics on the advertiser’s seed audience. The Campaign Optimization Agent simultaneously trains publisher behavioral signals, advertiser conversion history across multiple campaigns and product categories, and data provider demographic enrichment. It learns not only which users are similar to past converters, but also which combinations of audience context, demographic profile, and campaign type drive conversions, and generalizes the learning to new campaigns that the model has never seen before.
A tripartite clean room provides a governance structure in which all three parties can actively contribute. Publisher behavioral data never leaves the account, advertiser conversion history and model logic stays within collaboration boundaries, and data provider demographic graphs are used only for approved training workloads. Two parties and a warehouse can build similar models. Campaign optimization agents require multiparty training data, GPU computing, and a trust model provided by clean room ML.
Comparison with other approaches
Certain clean room platforms design their ML APIs based on customized use cases, such as lookalike audience generation or specific custom model formats. Others rely on centralized, shared notebook environments that are well-suited for exploratory data science and manual collaborative reviews.
Snowflake Data Clean Rooms ML jobs extend these approaches by supporting standard end-to-end Python ML workloads optimized for automated production pipelines. Data remains within each party’s respective account and utilizes a hash-based authorization system that enables seamless and automated re-execution without requiring manual intervention for each execution. Additionally, when both parties enable cross-cloud automatic fulfillment, workloads run seamlessly across different clouds and regions. To scale efficiently to meet the needs of each project, analytics practitioners can choose compute pools that match their workloads directly within their account, from standard or high-memory CPUs for large feature sets to GPU instances for accelerated tasks like deep learning and LLM fine-tuning (in supported regions).
Let’s get started
Data Clean Rooms ML jobs are now available in all Snowflake accounts that have a Data Clean Rooms environment installed. No account-level activation is required.
For ML engineers and data scientists: We provide two end-to-end examples, each with a sample data generator, SQL worksheets for both, and ready-to-run Python training and scoring scripts.
For campaign managers and media buyers evaluating this for measurement and targeting workflows: The incrementality and similar examples above are the quickest way to understand what’s possible. Share them with your data science or measurement teams. This example includes everything you need to run end-to-end, and the workflow corresponds directly to the standard campaign and activation patterns you already use.
Complete reference documentation: Data Clean Room ML Jobs.
