Unique Identifiers & Allowed Operations

In APSIS One every Profile must have at least one unique identifier, also called a Profile Key. A Profile can have many Keys, but always has at least one. When we import data to, or fetch data from, any given Profile, we must always use a Key to specify which Profile we are working with.

APSIS One supports several types of Keys. Today, APSIS One works out of the box with email addresses, phone numbers, and web browser cookie IDs as Keys. Down the road, support will be added to let you define your own custom types of Keys, such as you might have in a CRM system or other external system; and as APSIS introduces more tools and channels to One, e.g. Social Networks or Mobile/Apps channels, additional types of Profile Keys will be added for those.

Each type of Profile data (meaning each specific Attribute, Event, or Tag that you have in your account) can be configured to be allowed or not for each specific type of Key.

For example, when creating a Custom Attribute, you can configure which types of keys (web, email, mobile) should allow reading, writing or both read and write of this custom Attribute. This is managed in the Allowed Operations UI.

Example: lets imagine that we want to set up an integration (using the OneAPI) that needs to be able to read this custom Attribute. If this integration is using the email address to look up Profiles, you have to configure the custom Attribute to have read operation allowed using email Keys. If you also want the integration to be able to update the value of this custom Attribute using the same email address Keys, you also need to configure the Attribute to allow write operations using the email Keys.


Using a CRM ID as a Unique Identifier

Profiles imported with an APSIS One CRM integration will now have their CRM ID Attribute as their Profile Key, or Unique Identifier.

Previously, Profiles imported from a CRM would have their Email or Mobile Attribute as their Profile Key. This meant that in order to be identified, Profiles were limited to only one email address or phone number.

A Profile with a CRM ID as their Profile Key can contain a shared email address or phone number. Whereas Profiles using the same email address or phone number would usually be merged, these Profiles imported from the CRM would contain both email addresses or phone numbers, allowing Profiles to receive personalized communications via a shared address.

Additionally, any CTAs or links that the email recipient clicks in a shared device will register in their individual Profile only, and will not be shared across other Profiles with the same email address or phone number.

How Does This Work?

Let's imagine that two of your subscribers, a happily married couple, share the same email address.


Using this email address to consent to your communications and sign-up to your mailing list, they both create Profiles in your CRM.

Now there are two Profiles in your CRM and APSIS One Audience that share the same email address.

In your next email marketing campaign, create a personalized email with Data Tags to display the recipients name, or add Row Segmentation.
Both Profiles will receive a personalized email addressed to them, containing content they consented to receive.

One email address, two recipients, two different emails!

A Note on CRM IDs...

Unique identifiers like Email address and phone number can no longer be used to search for Profiles that have been imported from a CRM integration.

To search for Profiles imported from the CRM integration, use the CRM ID belonging to the Profile you wish to search for. For example, in Microsoft Dynamics 365, this is know as the Contact ID, and in Lime, it is known as the Person ID.


A Note on Data Security and Profile Keys

For more advanced readers.

APSIS One does not allow configuring read and write operations for the web keys today. This is because some mechanisms in One, such as the auto collect web tracking, must allow some unauthenticated access to Profiles using the web keys. This is necessary to be able to collect anonymous browsing data, but also means that we need to be careful about what those keys look like, and what they can be used for.

To manage this, One makes sure that the web keys are only usable for writing data, not reading. Furthermore, only the specific anonymous behavior is allowed to be written using web keys. Finally, the web keys are randomly generated. That means that unlike globally unique clear-text identifiers like email addresses, web keys are almost impossible to guess.

Did this answer your question?