Preparing your data for use in Simon's CDP might seem like a big task, but don’t worry—you're in great hands. This process is the key to unlocking powerful insights and delivering personalized experiences like never before. With our guidance, you’ll breeze through data preparation and set the stage for incredible success. Get ready to harness the full potential of Simon and watch your customer interactions soar to new heights!

---

Discovery

Where to start? It's very likely your marketing team has already begun defining priority use cases to launch in collaboration with their Simon Customer Success Manager. These initial use cases are a great way to begin scoping the data requirements. With each use case, ask yourselves:

• What data do you need to define your segment(s)?
• What data do you need to personalize messages for each customer?
• What data do you need to measure the success of the campaign?

The output of this exercise is a collection of tables or views that will be valuable to connect to Simon Data to power the use cases defined. Consult with your marketing team, and consider what data is relevant to them when they are creating segments as you choose tables to connect.

✅

At a minimum, we need the following data in order to use the platform:

• Identity Table (Required)
• Other Property or Event tables
  • These aren't required to set up Connected Deployment, but you'll want to grant us access to data you need to power any segmentation otherwise your segments will only be based on identifiers and nothing else.

---

Categorization

Next, it’s helpful to categorize the data into buckets: Identity, Properties, Events, Lookups. The category the data fits into will indicate the optimal table and/or view structure.

---

Customer Identity Table 🪪

Before you can begin using the Simon platform, you must share an Identity Table because it's the backbone of our CDP. If we don't know who your customers are, we can't send them anything!

This is a key part of the onboarding process, and we will work with you to create your Simon Identity Table. It must have:

1. A stable identifier.
2. Relevant channel identifiers.

If you don't have a stable identifier, your experience won't be optimal. Learn more here.

---

Stable Identifier

First and foremost, you must have a stable identifier in the identity table that you will connect to Simon Data. A stable identifier is a unique primary key for customer profiles. Whatever identifier you choose as your stable identifier will be the keystone of the segment builder.

✅

Stable identifier requirements

The identifier must be:

• A string, not an integer
• 1:1 per profile, meaning each profile can have 1, and only 1, stable identifier
• Readily available in your Snowflake instance

The identifier can't be shared across profiles, meaning the same stable identifier can't be associated with more than one customer profile.

---

Channel Identifiers

Customer attribute fields that identify a record for a specific integration (i.e. “channel identifiers,” such as email for Facebook or sfmc_id for Salesforce Marketing Cloud) must meet the following criteria in order for your outbound integrations to work:

• Each channel identifier must be included as a field on the identity table you provide to us
• Each channel identifier must be aliased into an appropriately named column on that table (see below for the appropriate column name for each channel identifier)

---

Customer Properties 🙋🏻

Properties are data points that have a one-to-one relationship with each customer such as:

• Personal information (e.g. name, address, birthday)
• Demographic information (e.g. gender, age, preferred language)
• Aggregated metrics (e.g. open rate, lifetime value, last order date)

Properties can be used to build segments, personalize content, gain insights about your segments, and gain insights about individual customers while using Simon's Customer360. When modeling property tables for use in Simon, keep in mind:

• Each table should contain an identifier that Simon can use to join to your Customer Identity Table
• Each table should contain only 1 record per unique identifier
• It's helpful to organize properties from the same data source with similar purpose (e.g. Engagement Metrics from your ESP, Summarized Order History from your POS system, Customer Details from your CRM)

---

Customer Events 🛍️

Events are data points with a one-to-many relationship with each customer such as orders, website_events, email_opens. While you may choose to aggregate some events into properties (e.g. last order date) for specific use cases and insights, events can be used to more flexibly build specific segments (e.g. customers who placed purchased a first-class flight on Travel Tuesday last year). Events are also used to create a timeline of interactions with each individual customer using Simon's Customer360. When modeling event tables for use in Simon, keep in mind:

• Each table should contain an identifier that Simon can use to join to your Customer Identity Table, though each unique identifier can appear on multiple records
• Each table must contain at least 1 timestamp field that tells us when the event took place, was created, or updated
• It is best practice to include a unique key for each event (e.g. event_id) for ease in investigation and to ensure there is only 1 row per event. For example, if you expect order_id to be unique but find there are multiple records for each order you may need to further model your data to consider updates such as returns.
• It's helpful to organize events so that each distinct event type is in it's own table, even if the source may combine several event types into one schema. For example, rather than modeling an Email Events table that can be further refined by event type in segmentation, it is more helpful to separate Email Sends, Email Opens, and Email Clicks into separate tables for faster, more intuitive segmentation.

---

Lookups 🏢

❗️

Coming soon

Please reach out to your account manager to be added to the waitlist!

When it comes to brand websites, 90% of your customers are browsing anonymously or via unrecognizable devices — making it impossible to capture first-party data to create highly targeted, personalized marketing experiences.

Lookups are data points that do not have any direct relationship with a customer, but instead contain attributes about some other unique object (e.g. a product catalog, a catalog of properties/hotels, etc.). Lookups are used only for personalization and cannot be used in segmentation. When modeling lookup tables for use in Simon, keep in mind:

• Each table must include a unique key (i.e. lookup key) for each record (e.g. product_id, store_id, property_id)
• The lookup key should be able to join to other property or event tables for use in content (e.g. the customer property preferred_store_id can join to store_id to personalize messages with more information about that store such as the customer service lead or store address)
• It's helpful to use lookup tables for objects that are repeatedly referenced across multiple property and/or event datasets

---

Prepare to connect to Snowflake

Once you've located your identity table and other event and customer property tables share the details with us then connect to Snowflake!

---