Skip to main content

User Identifiers

In Kevel Audience, each user has a 1st Party identifier generated by Kevel AUdience. They will also have multiple other identifiers from different channels and platforms. Collecting and resolving all of these IDs enables the identification of the user across channels and keep track of their multi-channel user journey.

info

A User Profile is composed of:

Typical HTTP interactions with Audience use a first-party cookie to identify users by default, so no ID needs to be passed explicitly. However, to support cross-channel user identification, additional user IDs must first be matched via ID Matching with the following ID types.

The IDs are classified as follows:

  • Platform: The platform where the ID is used. Common platforms are browser and mobile. Some IDs are not platform specific, such as the email address, and can be used in any platform.
  • Channel: The channel from where the ID was generated. For marketing platform IDs, this typically identifies if the ID is 1st or 3rd Party. Specific platform IDs can also exist, such as those from Email or CRM.
  • ID Type: The identifier to use in ID Matching.
  • Reliability: Signals whether the ID Type is considered reliable. Unreliable user IDs cannot be used to merge multiple User profiles. Instead, when matching profiles using unreliable IDs, these IDs are simply added to a list of unreliable IDs on the matched user profile. As a result, multiple distinct user profiles may share the same unreliable ID. Although unreliable IDs cannot be used to activate or initiate requests, they can still serve as Activated ID Types in certain Destinations.
Invalid User Identifier values

The list below outlines invalid user ID values to help avoid common errors in generating or matching user profiles. This results in more accurate attribute building and segmentation.

  • "" (empty value)
  • "null" (case insensitive)
  • "undefined" (case insensitive)
  • "none" (case insensitive)

Default ID Types​

Kevel Audience comes pre-configured to accept the following ID types:

ID Types
  • Platform: Browser
  • Channel: 1st Party
  • ID Type: 1pCookie
  • Reliability: reliable

This ID is automatically generated by Kevel Audience in Web interfaces and is sent via the adstax_uid cookie. It is the default ID type used to identify the user.

  • Platform: Browser
  • Channel: 3rd Party
  • ID Type: csi_* / csp_*
  • Reliability: unreliable

This ID is used by the CookieSync interactions.

Android Device Ad ID​

  • Platform: Mobile
  • Channel: 3rd Party
  • ID Type: gaid
  • Reliability: reliable

This ID identifies a user's Android device.

iOS Device Ad ID​

  • Platform: Mobile
  • Channel: 3rd Party
  • ID Type: idfa
  • Reliability: reliable

This ID identifier a user's iOS device.

CRM ID​

  • Platform: Any
  • Channel: CRM
  • ID Type: crm
  • Reliability: reliable

This ID corresponds to the CRM ID from a specific platform.

note

Only 1 CRM ID is allowed per user profile

The number of IDs allowed per ID type can be customized in your Kevel Audience environment. If a new ID match is attempted for a user profile that has already reached this limit (for example, adding a new CRM ID to a profile that already has one), the match will fail, and the user profile will remain unchanged. As a result, the two CRM IDs will be associated with separate user profiles.

Email SHA256​

  • Platform: Any
  • Channel: Email
  • ID Type: email_sha256
  • Reliability: reliable

This ID identifies the user via email. The email is hashed with SHA256 for privacy reasons.

Before hashing, the email address of the user should be in lowercase:

  • JohnDoe@domain.com => johndoe@domain.com

The hash should be sent as the hexadecimal representation in lower case of a generated SHA256 hash, e.g.:

  • sha256_fn(johndoe@domain.com) => d1df1acbdc99f3d0f80dc298471b0a2a01124e9371ea9e707805b19f4ffe8b6e

Email MD5​

  • Platform: Any
  • Channel: Email
  • ID Type: email_md5
  • Reliability: reliable

This ID identifies the user via email. The email is hashed with MD5 for privacy reasons.

Before hashing, the email address of the user should be in lowercase:

  • JohnDoe@domain.com => johndoe@domain.com

The hash should be sent as the hexadecimal representation in lower case of a generated MD5 hash, e.g.:

  • md5_fn(johndoe@domain.com) => 367f9b306cd4310c9fba3837574d6ced

Email SHA256 in Base64​

  • Platform: Any
  • Channel: Email
  • ID Type: email_sha256b64
  • Reliability: reliable

This ID identifies the user via email. The email is hashed with SHA256 and encoded in base64 for privacy reasons.

Before hashing, the email address of the user should be in lowercase:

  • JohnDoe@domain.com => johndoe@domain.com

The hash should be sent as the URL safe base64 representation of the generated SHA256 hash, e.g.:

  • sha256_base64_fn(johndoe@domain.com) => 0d8ay9yZ89D4DcKYRxsKKgESTpNx6p5weAWxn0_-i24

Email​

  • Platform: Any
  • Channel: Email
  • ID Type: email
  • Reliability: reliable

This ID identifies the user via their plaintext email.

Phone Number SHA256​

  • Platform: Any
  • Channel: Phone
  • ID Type: phone_sha256
  • Reliability: reliable

This ID identifies the user via phone number. The number is hashed with SHA256 for privacy reasons.

Before hashing, the phone numbers should follow the E.123 notation stripped of the leading + sign and any spaces. That means that symbols, letters, spaces, country exit codes and any leading zeroes should be removed from the number, and a country code prefix should be always present. E.g.:

  • 202-555-0110 => 12025550110
  • +1-202-555-0110 => 12025550110
  • 001-202-555-0110 => 12025550110
  • 01632 960298 => 441632960298
  • 011 01632 960298 => 441632960298

The hash should be sent as the hexadecimal representation in lower case of a generated SHA256 hash, e.g.:

  • sha256_fn(12025550110) => 24852c56a20cfb294a79ccbb21cfcf1887fd28a6e9c3f4f52acb837a36ede077

Phone Number​

  • Platform: Any
  • Channel: Phone
  • ID Type: phone
  • Reliability: reliable

This ID identifies the user via their phone number.

Phone numbers should follow the E.123 notation stripped of the leading + sign and any spaces. That means that symbols, letters, spaces, country exit codes and any leading zeroes should be removed from the number, and a country code prefix should be always present. E.g.:

  • 202-555-0110 => 12025550110
  • +1-202-555-0110 => 12025550110
  • 001-202-555-0110 => 12025550110
  • 01632 960298 => 441632960298
  • 011 01632 960298 => 441632960298

Unreliable Email SHA256​

  • Platform: Any
  • Channel: Email
  • ID Type: email_sha256_unreliable
  • Reliability: unreliable

This ID identifies the user via email. The email is hashed with SHA256 for privacy reasons.

Before hashing, the email address of the user should be in lowercase:

  • JohnDoe@domain.com => johndoe@domain.com

The hash should be sent as the hexadecimal representation in lower case of a generated SHA256 hash, e.g.:

  • sha256_fn(johndoe@domain.com) => d1df1acbdc99f3d0f80dc298471b0a2a01124e9371ea9e707805b19f4ffe8b6e

Unreliable Email MD5​

  • Platform: Any
  • Channel: Email
  • ID Type: email_md5_unreliable
  • Reliability: unreliable

This ID identifies the user via email. The email is hashed with MD5 for privacy reasons.

Before hashing, the email address of the user should be in lowercase:

  • JohnDoe@domain.com => johndoe@domain.com

The hash should be sent as the hexadecimal representation in lower case of a generated MD5 hash, e.g.:

  • md5_fn(johndoe@domain.com) => 367f9b306cd4310c9fba3837574d6ced

Unreliable Email SHA256 in Base64​

  • Platform: Any
  • Channel: Email
  • ID Type: email_sha256b64_unreliable
  • Reliability: unreliable

This ID identifies the user via email. The email is hashed with SHA256 and encoded in base64 for privacy reasons.

Before hashing, the email address of the user should be in lowercase:

  • JohnDoe@domain.com => johndoe@domain.com

The hash should be sent as the URL safe base64 representation of the generated SHA256 hash, e.g.:

  • sha256_base64_fn(johndoe@domain.com) => 0d8ay9yZ89D4DcKYRxsKKgESTpNx6p5weAWxn0_-i24

Unreliable Phone Number SHA256​

  • Platform: Any
  • Channel: Phone
  • ID Type: phone_sha256_unreliable
  • Reliability: unreliable

This ID identifies the user via phone number. The number is hashed with SHA256 for privacy reasons.

Before hashing, the phone numbers should follow the E.123 notation stripped of the leading + sign and any spaces. That means that symbols, letters, spaces, country exit codes and any leading zeroes should be removed from the number, and a country code prefix should be always present. E.g.:

  • 202-555-0110 => 12025550110
  • +1-202-555-0110 => 12025550110
  • 001-202-555-0110 => 12025550110
  • 01632 960298 => 441632960298
  • 011 01632 960298 => 441632960298

The hash should be sent as the hexadecimal representation in lower case of a generated SHA256 hash, e.g.:

  • sha256_fn(12025550110) => 24852c56a20cfb294a79ccbb21cfcf1887fd28a6e9c3f4f52acb837a36ede077

Unreliable Phone Number​

  • Platform: Any
  • Channel: Phone
  • ID Type: phone_unreliable
  • Reliability: unreliable

This ID identifies the user via their phone number.

Phone numbers should follow the E.123 notation stripped of the leading + sign and any spaces. That means that symbols, letters, spaces, country exit codes and any leading zeroes should be removed from the number, and a country code prefix should be always present. E.g.:

  • 202-555-0110 => 12025550110
  • +1-202-555-0110 => 12025550110
  • 001-202-555-0110 => 12025550110
  • 01632 960298 => 441632960298
  • 011 01632 960298 => 441632960298

Facebook Browser ID​

  • Platform: Any
  • Channel: 3rd Party
  • ID Type: fbp
  • Reliability: unreliable

This ID identifies the user via the Facebook Browser ID, commonly known as fbp. The ID should follow the format described in: https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/fbp-and-fbc/#fbp

Facebook Click ID​

  • Platform: Any
  • Channel: 3rd Party
  • ID Type: fbc
  • Reliability: unreliable

This ID identifies the user via the Facebook Click ID, commonly known as fbc. The ID should follow the format described in: https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/fbp-and-fbc/#fbc

Last updated on