What are unique identifiers and how are they used?

One of the most fundamental and important decisions when creating your Acoustic Campaign database is how to configure unique identifiers.

Overview

The unique identifier is a column or field in your database.

Unique identifiers in a database are used to distinguish fields from each other. A unique identifier is used when information is called from the database and needs to be distinguished from other information in the database.

When you are thinking about creating your database you must ask yourself, 'What is the best unique information I have about contacts in my database? Is it email address, is it account ID?' In addition, ask yourself whether you may start using account ID instead of email address.

If the social email address is used as the unique identifier, you can map the social email address to the existing email address in your database.

Although email addresses are often used as the unique identifier, you can use any unique value.

After you implement your unique identifier decision, it cannot be modified. Additionally Acoustic Campaign enforces the integrity of unique indexes by rejecting record imports and updates that would violate uniqueness.

Unique identifiers in flexible and restricted databases

Database type Unique identifier Details
Flexible database No unique identifier Required for SMS, mobile app messages, CRM and strongly recommended for Acoustic Exchange customers. Select your database field(s) that you want to sync by when adding or updating contacts.
Restricted database

Unique identifier required.

Email is the default.

 Requires that you select a unique identifier(s) now. The field that you select as your unique identifier is required when adding or updating contacts. Typically the unique identifier is email, but can be other fields.

Flexible databases do not have a unique identifier (UID).

The default unique identifier (UID) for restricted databases is the email field. When email is the sole UID for the database, all contacts must have a unique value in the email field. Any attempt to add a contact with a duplicate email value (through Acoustic Campaign UI, API or web forms) is not allowed.

When a different field is set as the sole UID for the database, that field must also have a unique value. For example, if you create a custom numeric field labeled Account ID and assign it as the UID, then Account ID value in the database must be unique for each contact, such as 12345 for Contact A and 67891 for Contact B.

Multiple fields may be set as UIDs for a database (you can designate up to 10). This can also be performed via API when declaring a field in your mapping file through the <KEY_COLUMN> parameter set as 'true'. In all cases, the values in the string of fields must be unique. For example, if you created a database with three custom fields (Account ID, State, and Store ID) as UIDs, the string of field values would look similar to the following:

  • Contact A = '12345,GA,SMY'
  • Contact B = '6789,GA,SMY'

While no other record can have an exact match with any other record in the database, as long as one field value is unique in the UID set of fields, the record can exist in the database.

  • Acoustic Campaign's restricted databases UID default is email. But you may have a specific business reason for using another UID.
  • If you use SMS, mobile app messages, or CRM, do not use a unique identifier.
  • All Suppression Lists must have Email as the sole UID.
  • After creating the database, you cannot change unique identifiers.
  • Users of the CRM integration functionality will need to create a database with no UID present for syncing to CRM. For more information about CRM, go to the CRM Integrations page.
  • Composite unique identifier is a combination of up to six fields from a table or up to 10 fields from a database. For example, you can select multiple columns for relational table inclusion. Together these columns create a composite unique identifier.
  • Make sure to consider duplicate prevention and how sending works if choosing a flexible database or restricted database.