Import Data from Snowflake to Insider One

Snowflake integration, also known as syncing your Snowflake data warehouse data into Insider One, is the method for sharing user attribute and event data from your Snowflake account directly into Insider One.

It uses Snowflake's native data sharing capabilities to establish a secure pipeline between your warehouse and Insider One without requiring intermediate file exports or manual uploads.

Essentials before integration

Before you begin, ensure the following prerequisites are met to ensure a smooth, secure data import from Snowflake to Insider One.

• A Snowflake Enterprise or Business Critical account.

• Permission to create and manage shares in Snowflake. The user setting up the share must have ACCOUNTADMIN access.

• Access to the schema and tables that include user and event data.

Set up the Snowflake integration

If you want to integrate more than one Snowflake account into the same Insider One panel, please reach out to the Insider One team.

Follow the steps below to authenticate your Snowflake account and set up your data sync.

1. Navigate to InOne > Components > Integrations > External Integrations.

   

2. Click on the Snowflake integration.

   

3. Enter a name for your Snowflake source integration and click Save.

   

4. Enter your Snowflake Account Identifier and Warehouse Name.

   

1. To find your Snowflake Account Identifier, go to Snowflake > Account Details and copy the first part of the Account/Server URL.

2. To get your Warehouse name, go to Snowflake > Compute > Warehouses and enter the Warehouse name that you want Insider One to use.

   

The size of the warehouse determines throughput. For large, initial loads (where you have a high volume of data), we advise to scale up the warehouse to maximize parallel processing and achieve the fastest possible ingestion time

If your Snowflake account uses a network policy, add the IPs below to its allowed IP list. Without this, Insider One’s connection is blocked and authentication will not verify. If your account does not use a network policy, you can skip this step.

• 54.75.24.135

• 3.248.74.75

• 99.80.200.102

5. After you enter the Authentication inputs, scroll down to Script and Key Setup.

1. To create a Private Key and a Public Key, run the script below on your local machine terminal. Then, two files will be created.

   openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out rsa_key.p8 -nocrypt 
   
   openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub

2. Upload this file: rsa_key.p8

   

   If you create it with a different command in the terminal that creates a private key with a Passphrase, you can use the Enter Passphrase input field. If your file requires a passphrase, the input field will automatically open.

3. Run an SQL query in Snowflake. Make sure you replace the <DB>, <SCHEMA>, <STREAM> and <PUBLIC KEY> placeholders with your actual values.

   

Copy the SQL from the InOne panel; each SQL is prepared according to the panel.

Important:

• When replacing <RSA_PUBLIC_KEY>, use only the raw key value. Do not include the lines:

  -----BEGIN PUBLIC KEY-----

  -----END PUBLIC KEY-----

• You should paste only the actual key content, for example:

  ABCDE1235…

Important:

Please do not modify any values in the SQL query except those enclosed in < >. For example, the default user role should remain Insider_Role.

Important:

• The Stream you grant to Insider One must be dedicated exclusively to Insider One and must not be used by any other integration or system. If another system also uses this Stream, Insider One will not be able to retrieve the all changes from Snowflake.

• You should create the Stream in DEFAULT mode. Creating the stream as append_only risks silent data corruption, as append_only streams track only inserts.

• If you haven’t yet created a Stream for the table you are sharing with Insider One, refer to Snowflake documentation to create a dedicated Stream for Insider One.

• Insider One automatically selects the Stream associated with a table. Therefore, the table you want to sync should only have one Stream, and that Stream must be the one created specifically for Insider One.

Important:

• If you are using the same Snowflake account across multiple Insider One panels, ensure that the same table is not connected to more than one panel.

• It is recommended to use separate warehouses for different tables. If both panels must use the same warehouse, ensure that the warehouse has sufficient capacity to handle the workload.

• If you plan to use the same warehouse, as a best practice, schedule sync times at different times. This helps distribute the workload and prevents peak load caused by multiple integrations running simultaneously.

6. After you run all the SQL successfully on the Snowflake side, click the Verify Authentication button to verify your authentication.

   

7. After verification, select the database, schema, and table you want to sync. If you’ve made any changes in Snowflake, click Refresh to load the latest structure.

   

   Insider One identifies and unifies incoming user records according to the identifiers, priority order, and value limits configured in Identity Resolution Management. Review these settings before your first import to understand how imported records will be matched and unified.

8. After selecting the table, you will be able to match the columns with Insider One’s attributes, events, and event parameters.

1. First, select the identifiers you want to send to Insider One. Data will be imported using the identifiers you choose. You may select more than one identifier. For example, if some of your users have only a phone number and others have only an email address, it is recommended to select both so that Insider One can match as many users as possible. However, it is essential to note that if the email or phone number for the same user in Insider One does not match the values you send from Snowflake, an identifier conflict will result.

   

2. If you want to send attributes next to the identifier from Snowflake, you can open the Sync Attributes and map the columns in Snowflake to the Insider One Attributes.

   

3. To map the Events and Event parameters from Snowflake, you can open Sync Events.

   

Refer to Default Attribute, Event & Parameter Data Mapping Table for required event parameters.

If you send events with the same name and timestamp, Insider One treats them as duplicates and ignores them. Therefore, avoid sending different events with identical names and timestamps.

Event names must follow the same naming convention as the Upsert User Data API. Event names that do not match this format will not be processed. Refer to Create a Custom Event for further information.

9. After completing the matching step, proceed to the Launch step. Choose how often you want the data to sync—every 15 minutes or up to once daily. Set the activation status to Active and click Save as Active.

   

Data Type Mapping

Ensure that the Insider One and Snowflake data types match. You can refer to the table below for data type matching:

For example,  a contact in Istanbul (UTC+3) was last seen at 14:30 local time, which corresponds to 11:30 UTC. Depending on the column type you map, Insider One stores:

Both columns read 14:30 in Snowflake, but only TIMESTAMP_TZ records the moment the customer actually intended. For a "last seen 14:30" value powering a send-time or time-window segment, the TIMESTAMP_NTZ version treats that contact as three hours later than reality.

Unsupported column types

The following Snowflake types cannot be mapped to an Insider One attribute, event, or event parameter. Columns with these types do not appear as mapping options in the Match step.

If you need to use this data in Insider One, first cast or flatten it into a supported type in Snowflake. For example, you can expose a GEOGRAPHY column as two FLOAT columns for latitude and longitude, or serialize a structured column to VARCHAR.

VARIANT is supported and maps to String. The JSON content is stored as a serialized string. Untyped ARRAY maps to Array Strings or Array Numbers.

Precision and special values

• High-precision numbers: NUMBER values beyond roughly 17 significant digits lose precision when ingested. For example, a 38-digit NUMBER is stored in Insider One in floating-point form. Avoid mapping columns when preserving the full precision is important, such as large identifiers or exact financial ledgers. If you need to preserve the exact value, map the column as VARCHAR instead.

• inf / NaN floats: These values cannot be represented as an Insider One Number. The affected cell is dropped, while the rest of the row is still ingested.

Default Attribute, Event & Parameter Data Mapping Table

Purchase Event

If you have purchase event in your Snowflake table, please make sure to;

• If in a basket, there are more than single item, make sure to add those as seperated rows into your Snowflake table.

• Include e_guid(event_group_id) parameter for each purchase event. This is needed to connect different products to single cart.

Refer to Events & Attributes for all default events and attributes.

If your data type in Snowflake is a TIMESTAMP format, the specific date format is not critical. Insider One automatically converts any datetime format that is accepted by Snowflake.

Limitations

Supported source table types

Insider One reads changes from your table through a DEFAULT-mode Stream. Only tables that support this Stream type can be used as a source. The table selection step lists only eligible tables.

Already using one of the unsupported types? Integrations created before this restriction, or created through the API, can still point to an external or externally managed Iceberg table. If your integration uses one of these table types, move the source to a standard table. Data added to the stage after the last successful metadata refresh was not ingested.

If your data originates in a type that is not selectable, materialize it into a standard table that Insider One can read. For example, have your pipeline write the data to a dedicated standard table, then create the Insider One Stream on that table.

Column and row-level security policies

Insider One reads your table through the Insider_Role created by the setup SQL. Any Snowflake policy that changes what a role can see also changes what Insider One ingests.

Some policies cause an error and stop the integration. Others do not cause an error, so the sync can complete successfully even when the ingested data differs from what you see in your own Snowflake session.

Before mapping a column, check whether any of the following policies apply to it for Insider_Role:

The first four policies are the ones to watch. Masking and row access policies do not produce an error. The integration remains Active, the sync reports success, and nothing on the Monitoring screen indicates that the ingested data is incomplete. Projection and aggregation policies produce an error and notify you.

Recommendation: If a column is protected by a masking or row access policy and you want Insider One to receive the original values, grant Insider_Role an exemption from that policy. If you do not want Insider One to receive the data, do not map the column. Relying on the policy to filter mapped data can cause the data in Insider One to differ from the data in Snowflake. To verify what Insider One can access, run your query while impersonating Insider_Role.

Warehouse requirements

The warehouse you grant to Insider One must be able to run a query when a sync starts. If it cannot, the sync does not ingest any data and the integration moves to Action Required so that you are notified.

• AUTO_RESUME must be enabled. If the warehouse is suspended and AUTO_RESUME = FALSE, every sync fails to start. Keep the USAGE grant for Insider_Role on the warehouse as well. If this grant is revoked, the sync stops in the same way.

• STATEMENT_TIMEOUT_IN_SECONDS must be long enough for your data volume. Exporting a large table can take several minutes. If the statement timeout configured for the warehouse or account is shorter than the export requires, Snowflake cancels the sync while it is running. As a reference point, exporting roughly 3 million rows takes several seconds of warehouse time, so a timeout of only a few seconds can cancel the sync.

• Size the warehouse for the initial load. The first sync creates a full snapshot of the table. Temporarily scaling the warehouse up for this run and scaling it back down afterward can help the initial sync complete faster.

Changing the table after activation

Some schema changes on an active integration are detected and move the integration to Action Required. Other changes are not detected and can silently change the data Insider One receives.

Recommendation: Treat the source table as a contract. If you need to rename, change the data type of, or remove a mapped column, update the mapping in the integration's Match step within the same change window.

Avoid using CREATE OR REPLACE TABLE on the source table. This operation drops the change-tracking history and causes the Stream to become stale.

• Each table must include an identifier.

  Identifier columns must use a String type. Only VARCHAR or TEXT columns can be mapped to an identifier such as email, phone number, or UUID.

  If your identifier is stored as a number or another data type, cast it to a String in Snowflake before mapping it. For example, if a phone number is stored as NUMBER, expose it as VARCHAR in E.164 format.

• Custom attributes or event parameters must be predefined in Insider One (see the Events & Attributes page).

• For purchase events:

  • Add one row per product in a basket.

  • Include e_guid (event_group_id) to link multiple rows to a single cart.

• Each row (user) must be under 350KB; rows exceeding this size will not be upserted.

A single sync can process at most 1 billion rows. This limit applies to every sync; both the initial full sync and subsequent incremental syncs. If a sync exceeds 1 billion rows, the integration is moved to Archived and that sync is not processed. If you expect any sync to exceed this, contact your Insider representative before launching.

Data Import Logic

During the Snowflake → Insider synchronization:

• If any identifier coming from Snowflake is invalid, the entire record is not sent.

• If an attribute coming from Snowflake is invalid, only that specific attribute is skipped.

• If an event parameter coming from Snowflake is invalid, the entire event is excluded from processing.

• The first synchronization performs a full table sync and doesn’t trigger any webhooks, campaigns, or journeys.

• If a single incremental sync exceeds the row limit configured for your account, Insider One still ingests all rows. However, those rows do not trigger webhooks, campaigns, or Architect journeys.

Important: Event Deduplication & Re-Ingestion Behavior

• Duplicate Detection Rule: Insider One treats events with the same event name and timestamp as duplicates.
  If multiple events with identical names and timestamps are sent within the same sync, only one will be processed and the others will be ignored.

• Avoid Updating Previously Synced Events: Do not update rows that were already consumed by Insider One in a previous sync.

  Updating these rows triggers re-ingestion, which may create duplicate events in Insider.

Recommendation: Ensure each event has a unique timestamp and avoid modifying rows which include historical event records after they have been successfully synced.

Local Region Support

• If your UCD uses a local region other than the default Ireland region, the integration will automatically use that region.

• To change it later, contact the Insider One team.

FAQ

Q: Do I need to be on a specific Snowflake plan?
A: Yes, either Enterprise or Business Critical.

Q: What permissions are required in Snowflake?
A: You must have ACCOUNTADMIN privileges and access to relevant schemas and tables.

Q: Can Insider One access data in a different region?
A: Yes, but you need to enable cross-region replication.

Q: Can I share multiple tables with Insider One?
A: Yes, you can share multiple tables with Insider One.

Q: What happens if I include custom attributes or events?
A: They must be created first in Insider One’s Events & Attributes page and mapped in the Match page.

Q: Can I send purchase events with multiple products?
A: Yes. Add each product as a separate row and use the event_group_id (e_guid) to link them to the same cart.

Q: How should I format dates (like a_birthday and e_timestamp)?
A: The datetime format itself is not critical. Insider One converts any datetime format that Snowflake accepts. The time zone is what matters.

Use TIMESTAMP_TZ where possible because it preserves the offset and the exact instant. If you use TIMESTAMP_NTZ, Insider One interprets the value as UTC, so store UTC values in that column rather than local time.

See the Data Type Mapping table above for the behavior of each timestamp type.

Q: How can I delete a user attribute or an entire user profile?
A: The Snowflake integration performs data synchronization based on updates and additions. It does not support explicit "delete" operations for user attributes or entire user profiles within Insider One. If a record is deleted in your Snowflake table, it will not automatically trigger the removal of that data from Insider One during the next sync. To delete user data in Insider One, you can use Insider One's dedicated user deletion features or contact the Insider One team.

Q: Under what conditions does a Snowflake stream become “stale”?
A: A stream becomes stale when its “offset” falls outside the data-retention period of its source table (or underlying tables for a view). At that point, historical data, including any unconsumed change records, is no longer accessible, and you must recreate the stream to resume change capture. Refer to Snowflake’s documentation for more information.

Q: Can I use the same Snowflake warehouse across multiple Insider One panels?
A: Yes, you can use the same Snowflake account and warehouse across multiple Insider One panels. However, ensure the same table is not connected to more than one panel. While we recommend using separate warehouses for different tables, if you choose to use the same warehouse, make sure it has sufficient capacity.
As a best practice, schedule sync times at different times to avoid peak load caused by multiple integrations running simultaneously.