Data offerings¶

Register a data offering¶

1. Create a data offering specification for your data. Specify the following details about your data offering:

   • The source object for each dataset in your data offering.

   • Which columns to include in each dataset.

   • The type (join or otherwise) of each column, which is used to populate the clean room policies. In some cases, you will also specify the format of individual columns.

   • Any Snowflake data protection policies to apply to columns in your data offering.

   • How users can access the data: by template only, or also by free-form SQL query.

2. Register the data offering by calling REGISTER_DATA_OFFERING, which returns a data offering ID.

   This step makes the data offering available to be linked into any collaboration by any role in your account that has read access to the registry. You can use the same data offering ID to share a data offering across multiple collaborations.

Link a data offering¶

The linking process depends on whether the collaboration has been created:

• If the collaboration hasn’t been created yet, the data provider can give the data offering ID to the collaboration owner to include in the collaboration specification. When a data offering is included in the collaboration specification, the data offering ID will be visible in the collaboration specification for review by the data provider before joining the collaboration.

• If the collaboration has been created, the data provider joins the collaboration and calls LINK_DATA_OFFERING with the data offering ID, the collaboration name, and who the data can be shared with. There might be a short delay after a data offering is linked before the data offering is available to use. Call VIEW_UPDATE_REQUESTS if you want to ensure that the link data offering request has completed successfully. After successful linking, the data offering will be visible and ready to use when calling VIEW_DATA_OFFERINGS.

When you link data, you specify which analysis runners can access the data.

A data provider can remove data offerings from a collaboration or specific collaborators by calling UNLINK_DATA_OFFERING.

To see registered data offerings in your account, call VIEW_REGISTERED_DATA_OFFERINGS.

See Run an analysis to learn how to run an analysis.

Source column renaming¶

Column names in a data offering can be renamed before exposing them to the analysis runner. Renaming depends on the category and column_type values that define the column in the data offering specification, as described in this table:

For example, if the column in the source table is named user_email_address, how this column is exposed to an analysis runner depends on how it’s defined in the data offering specification:

...
schema_and_template_policies:
  user_email_address:
    category: join_standard
    column_type: hashed_email_sha256

SELECT HASHED_EMAIL_SHA256
FROM source_table[0];

Applying data protection policies to data offerings¶

Data shared in a clean room is protected in several ways:

• Data registered with the clean room environment is created as a secure view that omits any columns not listed in the data offering specification.

• The secure view is shared only with the specific users and templates specified by the collaboration specification.

• You can add Snowflake policies to your data to further manage how it’s used.

• Data Clean Room template policies are also applied based on the data offering column classification.

There are two ways to apply a Snowflake data protection policy, such as a join or aggregation policy, to your shared data:

• Apply the policy to the source data. Any policies applied to the source data are enforced in the datasets exposed in a collaboration. Communicate your policy to your collaborators.

• Apply the policy to the data offering when used in free-form queries. If you allow free-form queries on your data offerings, you can specify policies to enforce on those queries in the data offering specification. These policies are applied on top of any existing Snowflake policies on your source tables.

CREATE OR REPLACE AGGREGATION POLICY my_db.public.my_agg_policy AS ()
  RETURNS AGGREGATION_CONSTRAINT ->
    AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 5);

# Tell data clean rooms to set your aggregation policy on the hashed_email column of
# the data offering
api_version: 2.0.0
spec_type: data_offering
version: 1
name: my_favorite_dataset
datasets:
  - alias: test_freeform_restricted_agg
    data_object_fqn: samooha_provider_sample_database.audience_overlap.customers
    allowed_analyses: template_and_freeform_sql
    object_class: custom
    freeform_sql_policies:
      aggregation_policy:
        name: my_db.public.my_agg_policy
        entity_keys:
          - hashed_email
...

SELECT *
FROM T1
JOIN T2
ON {{ t1_col | sqlsafe | join_policy }} = {{ t2_col | sqlsafe | join_policy }}

Organizing data offerings with naming paths¶

You can use naming paths to group data offerings conceptually. This is particularly effective because each data offering represents one or more tables or views. Individual tables are accessed using the syntax collaborator alias.data offering ID.dataset alias, where the data offering ID is a combination of the user-provided name and version values, and the alias is a single table in the offering.

Consider the name, version, and alias as a scoping system when registering your data offerings, which enables you to organize your data by offering and alias. For example, you might register the following data offering of sales data, where each table is specific to a US state:

api_version: 2.0.0
spec_type: data_offering
version: v0
name: examplecorp_sales_by_state
datasets:
 - alias: AL
   data_object_fqn: mydb.mysch.al_data
 - alias: NY
   data_object_fqn: mydb.mysch.ny_data
 - alias: CA
   data_object_fqn: mydb.mysch.ca_data

The analysis runner references these tables as user_alias.offering_id.AL, user_alias.offering_id.NY, and user_alias.offering_id.CA.