Identifiers & Business Rules

Simon ID

Each contact that exists within Simon is assigned a unique identifier called simon_id. This is a unique, but not persistent identifer that’s managed by Simon; as more and more identifiers for a contact become known over time, they're associated with the contact’s simon_id.

---

Native Identifiers

Native identifiers are channel agonstic identifiers (e.g. email_address & phone_number) and client-generated identifiers (e.g. user_id & customer_id). By way of an Identity-Providing Dataset, Simon ingests your native identifiers into the platform and creates associations between them in order to create a single view of your customer.

For example, let’s say:

1. Your data warehouse contains customer_id and email identifiers.
2. You have a separate Shopify table that contains email and phone_number.

In this case, the "common denominator" identifier is email, which is used essentially as a join key to associate the customer_id from your data warehouse to the phone_number in your Shopify table. The identifiers from these separate data sources are stitched together to create a single view of the customer that contains all four identifiers as they become known.

The following identifiers are currently supported within Simon. If you use an identifier that isn't listed, you may alias it as one of our existing identifiers in your Identity-Providing Datasets in order to bring it into Simon.

One example is custom_id = customer_id.

---

Stable Identifier

A stable identifier is what Simon uses as the source of truth for a given contact. It’s a unique identifier, meaning that each contact may only have one associated with their profile, and it may not be shared across multiple profiles.

You can customize the stable identifier to meet your business needs. Do you use email_address to identify your customers? Or do you generate a customer_id for them? Whatever you choose as your stable identifier will be the keystone of Simon’s identity rules engine.

---

Shared Identifiers

You can enable shared identifiers for multiple contacts, meaning multiple profiles may share the same value for a given identifier.

An example of this is a customer calling customer support to change their email address from their work email to their personal email. This sometimes results in duplicate contact profiles (i.e. different email addresses that belong to the same person but look like different contacts). To solve this in Simon, set the email address field as a shared identifier, allowing contacts to have more than one email address associated with their profile.

This means that the next time a customer changes their email address, it will simply be added to their existing profile rather than creating a new one as long as the stable identifier remains the same.

---

Business Rules

Business rules govern whether a new identifier-associated event can be successfully connected to an existing profile as part of an update or merge. If no association is made, meaning we’ve never seen that identifier before and it can’t be connected to an existing profile, a new contact is created within Simon.

---

Primary

Each identifier type can have only one primary identifier value. If we see more than one identifier for the same identifier type for any given contact (i.e. a contact has 2 or more email addresses), the primary identifier by default is the most recently updated identifier, unless otherwise specified. We recommend the most recently updated identifier is primary, otherwise you risk using outdated information to contact your customers.

---

Enabled

Enablement rules work in conjunction with primary rules. A primary identifier should always be enabled. If an identifier is primary and becomes disabled, the next enabled identifier of the same type becomes primary. By default, you can enable shared identifiers for multiple profiles.

If an identifier may not be shared, enablement indicates a change in that identifier’s association. This means that the enabled identifier is the one that was most recently associated with that contact and all other identifiers of that type are disabled across other profiles.

Example Business Rules

Below is an example of a set of business rules for a company that often has customers changing their email address. During onboarding, we'll work with you to determine the right set of business rules for your data.

---

Editing Your Business Rules

There are a few reasons why you might want to edit your existing business rules:

1. You need to connect a new data source to Simon.
2. You need to bring a new identifier into Simon, either from an existing data source or a new one.
3. You discover that the current ruleset no longer works for your organization, for whatever reason (i.e. you want to change your stable identifier or you want to change the primary identifier if more than one is present on a profile).

🚧

Editing an existing business ruleset is not self-service and can sometimes have unintended consequences. Speak to your account manager for more details.