Snowflake data sharing and Marketplace: a practical guide for marketing teams

Last updated: 15 September 2026.

What a Snowflake data share actually does

Secure Data Sharing lets a provider expose selected database objects to another Snowflake account. The consumer creates a read-only database from the share and queries it with its own access controls and compute. With a direct share in the same region, the shared data is not copied into the consumer's storage. Snowflake Secure Data Sharing

This is useful when an agency or partner needs recurring analytical access. You can publish a controlled reporting view and maintain its definition centrally. The partner queries the current result instead of asking someone to export another spreadsheet.

It does not solve the meaning of the data. If your team counts qualified leads differently from the agency, a faster delivery mechanism only distributes the disagreement sooner. Agree on grain, currency, dates and business definitions first.

Also distinguish query access from operational activation. Sharing a table with an agency's Snowflake account does not add people to a Google Ads audience or update a HubSpot property. Those actions require a supported delivery path, covered in the warehouse audience activation guide.

Choose the sharing mechanism for the relationship

Direct share: one defined reporting relationship

Use a direct share when the consumer has a Snowflake account in the same region and needs access to a controlled set of objects. It is a straightforward starting point for an agency reporting mart or a partner reconciliation dataset.

For other regions or clouds, use a listing with cross-cloud auto-fulfillment or a supported replication design. A listing can also add descriptions, usage examples and consumer usage information around the shared data. Snowflake sharing options

Choose based on the actual accounts and delivery requirements. Two companies both using AWS does not establish that their Snowflake accounts are in the same region.

Private listing: a managed data product for named consumers

A private listing fits when you want to package the dataset with documentation, support expectations and controlled distribution to particular accounts. This can help when the same product serves several partners or needs cross-region fulfillment.

For example, publish a partner revenue-reconciliation product with a stable schema, a sample query and an update commitment. The value is the maintained product contract, not merely making a share visible in a different menu.

Data Exchange: a private group that shares and discovers data

A Data Exchange is a hub for an invited group of members that can provide or consume listings. The exchange administrator manages membership and provider or consumer roles. Snowflake notes that enabling a Data Exchange may require contacting support. About Data Exchange

This fits an established partner ecosystem with repeated sharing needs. A small marketing team working with one agency usually has little reason to start by administering an entire exchange.

Marketplace: acquire someone else's data product

Marketplace is where you discover externally supplied data and other products. Start with the question you cannot answer using your own data, then inspect the listing's contents and commercial terms.

Examples include adding company attributes to an account list, introducing weather into a regional demand model or obtaining geographic context for expansion planning. Each needs a different coverage test. “Millions of records” says little about whether your five hundred target accounts are represented correctly.

Clean room: collaborate with restrictions on analysis

A clean room is relevant when the parties need joint analysis but should not receive unrestricted access to one another's underlying records. It requires agreement on identities, permitted queries, output controls and who may use the result. Treat that as a separate design exercise, described below.

Open full diagram

An agency share should expose a reporting contract

Suppose an agency manages selected campaigns and needs daily spend and qualified-lead totals. It does not need your customer emails, deal notes or every campaign another agency operates.

Create a reporting surface with one row per agreed date and channel for that partner. Specify whether the day follows UTC, the advertising account's timezone or your finance reporting timezone. Define how refunds, late conversions and reclassified leads change historical rows.

Prepare a short contract containing:

• The purpose and named recipient account.
• The row grain and the fields the recipient may query.
• The eligibility rule that selects the partner's records.
• Definitions and units for each measure.
• Source update frequency and a visible freshness indicator.
• The owner, schema-change process and end-of-access procedure.

These decisions should come from the marketing data warehouse model. Sharing a raw ingestion schema makes the partner responsible for reconstructing your business logic and following every connector schema change.

Snowflake recommends secure views or secure UDFs when sharing sensitive data instead of exposing the underlying tables directly. A secure view still needs the correct filter and projection; the word SECURE does not choose the permitted rows for you. Secure objects for shared access

A small SQL example for a single partner

The following illustrative provider-side example assumes the database, schemas and curated campaign table already exist. The source has one row per campaign per day, with qualified leads already allocated under an agreed rule so they are additive across campaigns. All spend is in USD. Replace the partner key and object names with your approved values.

CREATE SECURE VIEW MARKETING.PARTNER_EXPORT.AGENCY_ALPHA_DAILY AS
SELECT
  report_date,
  channel,
  SUM(spend_usd) AS spend_usd,
  SUM(qualified_leads) AS qualified_leads
FROM MARKETING.CURATED.CAMPAIGN_DAY
WHERE agency_key = 'agency_alpha'
GROUP BY report_date, channel;

CREATE SHARE AGENCY_ALPHA_REPORTING;

GRANT USAGE ON DATABASE MARKETING
  TO SHARE AGENCY_ALPHA_REPORTING;
GRANT USAGE ON SCHEMA MARKETING.PARTNER_EXPORT
  TO SHARE AGENCY_ALPHA_REPORTING;
GRANT SELECT ON VIEW MARKETING.PARTNER_EXPORT.AGENCY_ALPHA_DAILY
  TO SHARE AGENCY_ALPHA_REPORTING;

SHOW GRANTS TO SHARE AGENCY_ALPHA_REPORTING;

This creates the view and grants its containing database and schema access to the share. It does not grant access to the curated source table. The objects here sit in one database; cross-database views require additional design and privileges. Snowflake's provider guide documents the share and object-grant sequence. Create and configure shares

Review the grants and query result before adding the recipient. Do not add a second partner to this share if that partner should see different records.

ALTER SHARE AGENCY_ALPHA_REPORTING
  ADD ACCOUNTS = PARTNER_ORG.AGENCY_ACCOUNT;

SHOW SHARES;

PARTNER_ORG.AGENCY_ACCOUNT is an example identifier, not a real recipient. Confirm the exact organisation/account identifier and same-region compatibility with the partner.

Have an administrator prepare a role with the required view, share-creation and object-grant privileges. The current ALTER SHARE reference additionally requires ownership of the share and MANAGE SHARE TARGET on the account to add or remove recipients; CREATE SHARE alone does not provide that ability. ALTER SHARE reference

This example does not create roles, change production grants or demonstrate a working partner connection. Validate it in your own test accounts. Parser checks and local calculations cannot prove Snowflake privilege enforcement.

Verify what the partner can and cannot see

Use at least two agencies in the test data. Confirm that the intended recipient gets only its rows and that unshared source objects remain inaccessible. Include a campaign with a missing agency key, a reassigned campaign and a day with zero leads.

In an illustrative fixture, agency Alpha has two paid-search campaigns on one day: $40 and $60 spend, with one and two qualified leads. The shared result should show $100 and three leads. Agency Beta's $900 and twenty leads must contribute nothing. If the query returns $1,000, the filter is wrong even if all grants look correct.

Decide how reassignment should affect history. A campaign's current owner may differ from the agency responsible when spend occurred. Store the historical responsibility at the reporting grain when that is what the agreement requires.

Check the consumer experience using its intended role and warehouse. Confirm the expected objects, query results and freshness information, then test access removal as part of the handover plan. Keep expected totals from an independent fixture rather than copying the result you are trying to validate.

Aggregation also needs review. A daily total describing one identifiable customer may reveal more than the parties intend. Choose a suitable reporting grain and output policy for the use case; adding GROUP BY is not proof of privacy.

“No copy” does not mean “no cost” or “no export”

For the direct-sharing pattern, the provider maintains the source storage and the consumer pays for its query compute. A consumer that creates its own derived tables can introduce its own storage and transformation costs.

Cross-cloud auto-fulfillment adds a different cost path. Snowflake copies and maintains data in regional secure share areas, incurring compute, storage and transfer usage. Refresh frequency, changed data and destination regions affect that cost. Auto-fulfillment costs

Estimate the actual refresh needs. A daily agency report may not need frequent cross-region refreshes. Include licensing for acquired datasets, model preparation and the team's support effort. The Snowflake pricing guide explains the wider bill.

Revoking a share removes access through that share. It does not reach into a partner's previously downloaded report and erase it. Snowflake even documents an export path for reader accounts using COPY INTO with connection credentials, despite their restrictions on loading and modifying data. Reader account capabilities

Define permitted downstream use, retention and offboarding with the recipient. Use the platform's controls for what they enforce, and do not describe ordinary query access as a guarantee that results can never leave the account.

If the agency does not have Snowflake

A reader account lets a provider supply access without requiring the recipient to become a separately licensed Snowflake customer. The provider owns and manages it, pays its warehouse credits and supports its users. It can consume data only from the provider that created it. Managing reader accounts

That can work for a partner who only needs to query your reporting data. It is a poor substitute for a full analytical workspace when the partner must load and combine its own datasets.

Assign small, appropriate warehouses, suspend idle compute and configure resource monitors. Review actual usage rather than assuming “reader” means free. A dashboard refresh loop can consume compute even when nobody is learning anything new.

Also consider the partner's skills. If they only need a few charts, an appropriately scoped reporting interface may be more useful than giving them SQL access they will not use. Choose the smallest supported delivery method that completes the job.

Evaluate Marketplace data on usable coverage

Before shopping, define a decision and a unit of analysis. For account prioritisation, the unit may be a legal entity or product account. For retail demand, it may be a store-day. For geographic expansion, it may be a region and a specified population measure.

Four categories can be worth testing when they fill a demonstrated gap:

• Firmographic data: test company identity, geography, parent/subsidiary treatment and attribute update dates.
• Technographic data: inspect how a technology signal was observed and whether it describes the relevant company, site or historical period.
• Weather and local-event data: test location alignment, timezone and whether you need observations or forecasts available at the decision time.
• Geographic and demographic data: inspect the geographic unit, vintage and measurement uncertainty; an area-level attribute is not a fact about an individual customer.

These are evaluation directions, not claims that a particular listing improves revenue. Compare a paid product with the data you already own or can obtain through an appropriate public source.

Snowflake provides listing data dictionaries and optional previews to inspect available objects. Trials may offer limited data or limited time. Current listing configuration documentation says trials are optional for paid public and private listings, so check the offer rather than assuming every product has a free trial. Explore listings, Listing configuration and trials

Run a join-quality test before a purchase decision

Use a representative target list that includes difficult cases: small companies, subsidiaries, missing domains and your actual operating countries. Preserve the unmatched records in the test output.

Suppose a trial contains 500 target accounts. Three hundred obtain a unique provider match, giving 60% apparent coverage. Further checks reject forty stale records, thirty matches at the wrong entity level and twenty lacking a required field. Assume these rejection groups are disjoint.

That leaves 210 usable matches, or 42% of the original 500. Those are illustrative audit results, not a vendor benchmark. Counting only returned rows would hide the gap between a technical join and useful enrichment.

Check for duplicate provider keys before joining. One account matching three historical snapshots can inflate pipeline totals without adding any new customers. Specify an as-of date and the provider's intended snapshot rule, then reconcile account count and revenue before and after the join.

If the purpose is predictive scoring, use only attributes that would have been available when the score was made. Current company size attached to a two-year-old opportunity can leak future information into a retrospective test.

Finally, ask what decision changes because of the added information. A dataset that increases filled fields but never changes account selection, qualification or analysis may not justify its licensing and maintenance cost.

When a marketing clean room earns its complexity

A clean room can support a defined collaboration such as audience overlap or campaign measurement while restricting the data and outputs available to participants. Snowflake's current Collaboration Data Clean Rooms model supports multiple collaborators with separate ownership, data-provider and analysis-runner roles. About Snowflake Data Clean Rooms

Start with a precise question: “How many customers in this eligible audience also appear in the partner's eligible audience during this period?” Define the matching keys, population, time window and permitted output before loading data.

An overlap result is not proof of incremental advertising impact. People appearing in both datasets may have purchased without the campaign. If the decision concerns causal lift, design the experiment separately using the attribution and incrementality guide.

Do not assume every clean room only allows one fixed template or that the product name supplies all privacy controls. Current Snowflake data offerings can allow template-only access or configured free-form SQL, with policies controlling uses such as joins, projection and aggregation. Review the actual offering and collaboration configuration. Data offering policies

Edition and account requirements also matter. Snowflake currently requires Enterprise Edition for data providers and for activating results to another account; owners and analysis runners can use Standard within its stated limits. Trial accounts do not support Data Clean Rooms. Current clean room requirements

For a small team, proceed when the partner, usable matching data and an actionable analysis are already identified. Budget for policy design, identity preparation and interpreting the result. If all you need is approved aggregate campaign reporting, a controlled share may complete the job with less operational work.

Keep the first release small. One maintained reporting product is useful; a catalogue of undocumented tables is another integration problem. Our data warehouse and CDP service can help define the reporting model, access boundary and validation needed for a partner handover.