Overview

Simon’s composable application operates on a database within your Snowflake instance. Our application creates various schemas within this database to organize the objects it produces. The schemas that are created and the data within them will vary depending on the parts of the application you use.

SD_ACTIVATION

When you sync a flow, we automatically save a view in your Snowflake instance that combines segment membership with personalization fields (aka Content). There is one view per flow, and it follows this naming convention: SD_FLOW_<FLOW_ID>_<FLOW_NAME>

SD_DATA_ROUTING

The data routing product is used to route event data from Simon into your Snowflake instance. There is one “pipe” per data source (i.e. Simon Signal and Data Feeds).

During general Simon onboarding, we create one file format: NLJSON (new line delimited JSON).

When onboarding each data source, we create the following:

• One pipe per source: _DATA_ROUTING_<INTEGRATION>_EVENTS_PIPE
• One stage per source: _DATA_ROUTING_<INTEGRATION>_EVENTS_STAGE
• One table per source: _DATA_ROUTING_<INTEGRATION>_EVENTS

For each event type in the data that gets routed to Snowflake, we create one view that’s filtered to the specific event type: _DATA_ROUTING_VIEW_<INTEGRATION>_<EVENT_TYPE>_EVENTS

SD_IDENTITY

Your Identity Model is the foundation of your Simon instance. You may have one live identity model and one draft identity model at a time, but you will be able to see historical versions both in the Simon platform and in your Snowflake under the SD_IDENTITY schema.

For each draft identity model, we create one view: SD_IDENTITY_MODEL_<DRAFT_ID>_<DRAFT_NAME>

For each promoted identity model, we create one view: SD_IDENTITY_MODEL_<MODEL_ID>_<MODEL_VERSION>_<MODEL_NAME>

📘

Some things to keep in mind:

• The version that’s live in your account will be named default.
• If the name of your identity table exceeds 255 characters, it will be truncated.

In order to add SIMON_ID to each of your contacts, we create a view on top of your live identity model called CONTACT_TABLE_IDENTIFIED. This view is what is connected to the Simon platform in the Schema Builder.

SD_IDENTITY_NATIVE_KEYS_VIEW is the object representation of your live identity model, which is used to power your flows.

SD_SEGMENTATION

When you save a segment, we automatically create one view per segment in your Snowflake instance with the logic defined by that segment. Find this view at SD_SEGMENT_<SEGMENT_ID>_<SEGMENT_NAME>

• Because the segment is stored as a view, it recalculates whenever you query it. There's no need to refresh the data manually when you query the view because it will contain the most current data.
• The view has one column that contains all of the SIMON_IDs for the contacts that fall into that segment.

SD_TRANSFORMATION

When you commit a new dataset from the Simon platform, one view per dataset is automatically created in your Snowflake instance with the logic defined by that dataset's query. Find this view within the TRANSFORMATION schema at SD_QUERY_\<DATASET_ID>_\<DATASET_NAME>.

When you upload a CSV via the Simon platform, a table is automatically created in your Snowflake instance that contains the contents of the CSV. You can find this table within the TRANSFORMATION schema as well at SD_UPLOAD_<UPLOAD_ID>_<CSV_NAME>.

QUERY_TAG

This tag is for Simon internal use. It contains the application within Simon that generated our query. It's not backward compatible and subject to change without notice.