Getting started

The business rules sandbox is a nifty tool designed to help you better understand how different sets of identity-related business rules are applied to and transform your customer data. The sandbox allows you to test identity rules to determine which are the best ones for your business.

If you’d like more details on Simon’s full Identity solution before you get started, please read this first.

Step 1: Customize a ruleset to test

Set profile rules

Stable identifier

A stable identifier is unique, persistent, and has a one-to-one relationship with each customer profile in your account.

• Each customer profile can only contain one stable identifier.
• The stable identifier can't be shared across multiple customer profiles.

User ID or customer ID make ideal stable identifiers because for most businesses, they never change and each customer only has one of them. However, if your organization doesn't have a customer ID, you can use email address instead.

Whichever identifier you choose as your stable identifier in the sandbox rules will automatically be moved to the bottom of the list, and rule configuration will be disabled. In the screenshot above, customer ID is the stable identifier.

Enabled

The other non-stable identifiers in the table may be configured to reflect the behavior you’d like to see in your account. You choose which identifier values to enable for messaging, merging, and updating profiles; either: all of the identifier values associated with the profile, only the first one that was added, or only the most recently updated. If only one of a given identifier type (e.g. the most recently updated phone number) on a customer profile is enabled, no other phone numbers associated with that profile will be visible in Simon or be used to send marketing messages.

Example: if your customers interact with your brand on their tablets and cell phones, you can allow all device IDs on a customer profile to be enabled so that you can send marketing messages to both.

Preferred

If you enabled all identifier values for a given identifier type, you’ll be required to choose which value you prefer to be used for messaging: the first one added to the profile or the most recently updated one. If only one value is enabled on a customer profile, by default that same value will be preferred.

Set sharing rules

By default, there are no shared identifiers in the sandbox. However, there are some identifiers that you may want to configure to be shared across profiles depending on how your customers interact with your brand. If you'd like to add sharing rules for an identifier, click Add Optional Identifier.

The most common example of a shared identifier is device ID. Allowing this identifier to be shared across profiles means that the same device ID can appear on multiple customer profiles. This is likely to occur if a family shares a desktop computer or tablet.

If an identifier can be shared across multiple profiles, you can choose which value is enabled. Like the profile rules you set above, this means that all, the first added, or most recently updated identifier on a customer profile will be used for messaging, merging, and updating profiles.

Once your business rules have been configured to your liking, scroll down to the sample customer profile section.

🚧

NOTE

The rules that you customize here will not affect your existing identity model. This set of rules is purely for testing purposes and will only be used in this sandbox environment.

If you’d like to see your organization’s existing business rules, navigate to Identity → Business Rules in the left-hand navigation bar. The sandbox’s default set of business rules matches your organization’s existing rules. If you need to go back to the default rules at any time, click Reset.

Step 2: Configure customer profiles

Once your test business rules are set, you can recreate a situation that happens often within your own business to test what would happen in Simon. If a customer changes their email address, for example, will they have two separate profiles or will those profiles merge? The profiles you configure here represent profiles that would exist in Simon; however, the identifier values are dummy data.

By default, one of each of the identifiers in your account will be populated. Click the "x" to remove an identifier from the profile. Click Add Optional Identifier to add a new identifier value. You may only add an additional identifier for those which you've configured all to be enabled in the business rules above.

You can also add an additional profile to test by clicking Add Optional Profile.

If you have sharing rules configured, this is where they'll come into play. An additional dropdown is available for configuration in the second profile; for identifier types that have sharing rules enabled, you can choose to either add a New identifier or to Match (1) the first card’s identifier. If the initial profile contains more than one of that identifier type, you can choose either the preferred or not preferred identifier that the second profile should match. The envelope icon indicates which value is preferred and would receive marketing messages.

Certain validations will prevent you from configuring a customer profile that would not be able to exist within Simon. Take the screenshot above, for example. If you were to remove the Customer ID and Device ID fields from the second profile, you would have a profile that would not exist on its own because the remaining phone number matches the initial profile. You can't have a profile that contains only one identifier value that already exists on another profile.

🚧

NOTE

The data populated for these customer profiles is dummy data and does not reflect the data in your account.

Step 3: Create a test event

Identity Events will always contain two identifiers; this is because identity events create associations between identifiers. An event triggered by a user creating an account on your website could contain an email address and a phone number, for example.

To start from scratch, click Reset Sandbox.

When events enter the Identity Service, Simon looks for any existing contact profiles that already contain either or both of the identifiers on the event. At least one of four things then happens. To view the results of the test, click Run.

Step 4: View the result

1. Two profiles merge into one

Let’s say an incoming event contains email and phone_number as identifiers, and there’s an existing profile that contains the email from the event and a different profile contains the phone_number from the event. Simon will then merge those two separate profiles into one; the resulting profile now contains both email and phone_number.

👍

Real-Life Example

An existing user with historical browse activity on your website downloads your app and browses some more without signing in. The user then signs into their account, which triggers a merge of the website profile & the app profile.

2. An existing profile is updated

The same event enters the Identity Service, containing email and phone_number as identifiers. This time, an existing profile contains a matching phone_number, but a different email. In this case, the existing profile is updated with the new email.

👍

Real-Life Example

An existing user logs into your app on a new device and their profile did not already contain a device_id. The device_id is now associated with that contact’s profile.

3. A new profile is created

The same event enters the Identity Service, containing email and phone_number as identifiers. There is no existing profile that contains either of the identifiers, so a new profile is created with email and phone_number.

👍

Real-Life Example

A new user visits your website for the first time and provides their email and phone_number during registration.

4. Nothing happens

The same event enters the Identity Service, containing email and _phone_number_as identifiers. An existing profile already contains both of those identifiers. In this case, nothing happens because we already know those identifiers belong to that contact.

👍

Real-Life Example