Magnite Data Onboarding: Snowflake Marketplace User Guide

The Magnite Data Onboarding listing in the Snowflake Marketplace allows you to onboard your first-party or third-party data for activation within Magnite SSPs via Snowflake Views. The following provides a step-by-step approach for Clients and Data Partners to onboard their data into Magnite. This listing currently supports onboarding data for activation on Magnite Streaming.

Getting Started

To get started, locate the Magnite Data Onboarding listing and click the request button to email the Magnite Snowflake admin team with more information on the data you want to onboard. Please include:

  • Your company name

  • A point of contact and email address

  • The type of data (first-party/3rd party) you want to onboard

  • The data size

  • The number of user profiles

  • The average number of segments per profile

  • Expected frequency of updates.

  • Expected size of updates.

  • The region where the data is located. Note: Magnite requires data to be stored in US-east-1.

A member of our admin team will review the request. Once the request is approved, Magnite will share our target Snowflake account name so you can begin sharing data views with Magnite.

Segment Membership and Taxonomy Table Requirements

Magnite requires a segment membership and taxonomy table for data onboarding. The following outlines the requirements for each table.

NOTE: Please use the UpdatedTimestamp in both Views when your row gets updated/ added.  This helps Magnite troubleshoot/ monitor/ backfill if any issues arise when onboarding your data.

Segment Membership Table Requirements

Field

Data type

Required/
Optional Values

Definition

StorageId

VARCHAR(4000)

Required

First-party ID,  Device ID,  IP, Khaos,  EID + EID Source (When Applicable)

IdType

VARCHAR(36)

Required

First Party ID, IDFA, RIDA, TIFA, AAID / GAID, IP, EID, KHAOS, EXTERNAL.  A cookie sync is required for khaos usage.

SegmentId

VARCHAR(36)

Required

Required even if you plan to maintain one master list. Please include one segment per row.

Active

BOOLEAN

Required

TRUE, FALSE. A user is opted out when set to False.

UpdateTimestamp 

TIMESTAMP

Required

Timestamp of the update to Magnite.

Taxonomy Table Requirements

Field

Data type

Required/
Optional Values

Definition

ClientName

VARCHAR(255)

Required

Data Provider, Publisher or Advertiser Name 

AccountId

VARCHAR(36)

Required

Magnite Account ID associated with the client. (This is where the segment needs to go within Magnite.)

DataShareSettings

VARCHAR(36)

Required

Values are Public or Private.

SegmentId

VARCHAR(36)

Required

Segment ID(s) that are provided in the segment membership table.

SegmentName

VARCHAR(255)

Required

Name of the segment. 

SegmentDescription

VARCHAR(255)

Optional

Notes/metadata on the segment. 

SegmentCPM

DOUBLE

Optional

Cost of the segment.

Platform

VARCHAR(255)

Required

Magnite, Magnite Streaming, DV+, SpringServe.

Active

BOOLEAN

Required

- True
- False

Related to segment status for future system support.

UpdateTimestamp

TIMESTAMP

Required

Timestamp of the update to Magnite

Example Table Creation

The following shows how to create a membership table and share (the table name used here is simply for the example).  Please reach out to Magnite if you have any questions. 

-- Create a membership table
CREATE TABLE SF_MAGNITE_MEMBERSHIP (
  storageid varchar (4000) not null,
  idtype varchar (36) not null DEFAULT 'unclassified',
  segmentid varchar (36) not null,
  ACTIVE boolean not null,
  UPDATETIMESTAMP timestamp not null
);

-- Create Share views, append _SHARE To name
CREATE SECURE VIEW IF NOT EXISTS SF_MAGNITE_MEMBERSHIP_SECURE_VIEW WITH CHANGE_TRACKING = TRUE AS SELECT * FROM SF_MAGNITE_MEMBERSHIP;

-- Insert data to membership table
INSERT INTO SF_MAGNITE_MEMBERSHIP(storageid, segmentid, ACTIVE, UPDATETIMESTAMP) VALUES ('device_id_1_null_seg_1','seg_1_device_1_idfa',true, CURRENT_TIMESTAMP);

Sharing Table Views

Once the data tables are prepared, you can share views of your data with Magnite in three steps. 

Step One: Check the Data Format

Before sharing data with Magnite, you must run the script in the Magnite Listing to ensure the data is in the correct format and meets the segment membership and taxonomy table requirements. 

You can also find a link to the script here: Validating Your Views to Share to Magnite

Step Two: Enable Streams 

A stream (change tracking) on the view must be enabled to understand table updates and inform data ingestion. For more information, see Snowflake’s Managing Streams documentation or contact your Magnite representative.

Step Three: Make the View Accessible to Magnite

To make the view accessible to Magnite, please create a share of each table and grant privileges to the shared objects using Magnite’s target Snowflake account name.

Magnite Data Ingestion

Data share updates are checked hourly and ingested into Magnite daily. 

Refreshing Your Data

When you add, update, or delete a row in your shared Views, Magnite detects the change using Snowflake Streams and processes updates hourly. If data has not been changed in 28 days, it will expire in Magnite systems.

Deleting Segment Memberships or Segments

Magnite supports two methods for removing data:

  1. Boolean Deactivation (Active = FALSE)
    You may deactivate a segment membership or taxonomy entry by setting the Active field to FALSE.

  • Membership table:
     Setting Active = FALSE removes the user from the specified segment.

  • Taxonomy table:
     Setting Active = FALSE deactivates the segment from activation within Magnite.

This method preserves the row while signaling that the membership or segment should no longer be active.

  1. Row Deletion
    Alternatively, you may remove a membership or taxonomy by deleting the row entirely from the underlying table.

Because Streams are enabled on the Secure View, Snowflake will detect the row deletion and Magnite will process it as a removal.

Both approaches are fully supported. Clients may choose the method that best aligns with their internal data governance and lifecycle policies.

TTL Refreshes

If you want your data’s TTL refreshed without changing the main row’s data, you can use the `UpdateTimestamp` column to trigger a refresh.  The Snowflake Stream will detect this as an update to the row and send it to us for processing.

You can use the WHERE clause to help split the data refresh (instead of sending all the data at once).  This will help with processing times and stagger processing across multiple hours rather than a single, long processing hour.

-- WHERE clause is optional
UPDATE SF_MAGNITE_MEMBERSHIP_SECURE_VIEW
SET UPDATETIMESTAMP CURRENT_TIMESTAMP()
WHERE SEGMENTID = '123';
UPDATE SF_MAGNITE_TAXONOMY_SECURE_VIEW
SET UPDATETIMESTAMP CURRENT_TIMESTAMP()
WHERE SEGMENTID = '123';

Questions

If you’d like more information or need help with the onboarding process, please contact snowflake@magnite.com.