Skip to main content

User Identifiers

In Kevel Audience, each user has a 1st Party identifier generated by the CDP. 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 multiple channels and keep track of their multi-channel user journey.

Cross-platform IDs such as e-mail hashes or CRM IDs are typically used to perform onboarding operations before reaching out to the users through other mediums (Browser, App, etc.).

info

A User Profile is composed of:

Typical HTTP interactions with the CDP will use our 1st Party cookie to identify the user by default so no ID has to be passed explicitly. However, to support cross-channel user identification, additional user IDs must be previously matched via ID Matching by making use of the following ID types below.

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 reliable or not. Unreliable user IDs cannot be used to merge together multiple User profiles. Matching user profiles using unreliable User IDs will only append the unreliable User IDs to a list of unreliable user IDs on the user profile to which it is being matched against. This means that multiple distinct User profiles can have the same user ID. Unreliable IDs may still be used as an Activated ID Type in several Destinations but you cannot make an activation request using one.
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 per id type is customizable for your own private CDP environment. When a new id match is attempted for a user profile that has already reached the limit (e.g. a new CRM ID being added or matched to an existing profile that already has a CRM ID), the match will fail, and the user profile is not updated.

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