Skip to main content
The fields (attributes) listed here are created by default for every contact type in Voyado Customer Engagement.

​
Contact standard fields

These contact attributes exist by default when setting up a new Customer Engagement tenant and every contact created will have them.
When creating a contact, the recommended approach is to ONLY specify countryCode in the payload. The value for country will be automatically populated based on what you specify for countryCode (assuming you have sent a valid value). So do not include country in the payload.

​
More about Birthday

Customer Engagement automatically calculates if the current day is the contact’s birthday, based on the standard contact attribute Birthday. This is the only way it is done. If birthday or age is added as an extra field, they will be ignored. The Birthday calculations that activate the trigger are made every morning at a random time between 6:00 and 8:00.
Birthday must have the format YYYY-MM-DD with dashes as shown. Using an incorrect date format when creating a contact will not stop the contact from being created, but it will cause their Birthday to be null.

​
Contact custom attributes

As well as the standard contact attributes listed above, there is also the option to extend the data model by adding custom contact attributes, based on the client’s needs. Custom attributes can be used to store data about contacts in order to create useful segments or to personalize content in send-outs. Both standard and custom contact attributes use the field types listed in the section below.

​
Contact field types

Below are the field types supported in Customer Engagement and their constraints:
  • Text - Standard string field
  • Long text - Extended text field
  • Number - Decimal field
  • Checkbox - One checkbox
  • Checkbox (multiple) - Several checkboxes
  • Dropdown menu - A dropdown menu
  • Social security number - The attribute socialSecurityNumber is a default attribute of this type. It is possible to add another social security number field as long as both fields don’t set birthday and gender. 
  • Store (current) - The store (current store) field will be automatically added when activating the “Stores” module in “Enable/disable modules”. Adding another attribute of this type is not recommended, and if you do then both fields will be mirrored, meaning that changing one will automatically change the other.
  • Store (created in) - See “Store (current)Company (only with Company-module) - DEPRECATED
  • Birth date This is type BirthDate and always given as YYYY/MM/DD, for example 1971/05/26
  • Date and time - For other dates and times we use ISO 8601 
  • E-mail - We validate email according to: RFC 5322, adr-spec
  • Formula - (Used in special cases)
  • Gender - The gender attribute is a default attribute of this type, and it can be calculated by either socialSecurityNumber (default), setting on the socialSecurityNumber attribute.
  • Integer - Maximum length of this field is 12 digits.
  • Sequence - Serial number, for instance memberNumber. When manually importing contacts the sequence attribute (memberNumber for instance) needs to be present but empty for Customer Engagement to set a sequence number.
  • List of children - It’s possible to add multiple children with their age set by their birth date.
  • Country This is of type countryCode - ISO 3166, Alpha-2 (two digits).
  • Consent - The consent attribute includes title, linked text and the actual terms text (HTML).
  • Age (Integer) - Is set by socialSecurityNumber by default.
When using the type Sequence as a custom attribute, it should never be used as a key since this will impact performance severely.
You will never need to manually create any fields of the following types, since one of each is created by default whenever a contact is created, and duplicates are not allowed:
  • Store (current)
  • Store (created in)
  • Birth date
  • Gender
  • Age (integer)

​
More about standard fields

​
Mobile Phone (mobilePhone)

Each contact can only have one phone number connected to them, and the number should always be formatted as MSISDN (Mobile Station International Subscriber Directory Number), as a ”+” prefix followed by [countrycode][phonenumber]. For example: +46707104603. Voyado Customer Engagement uses libphonenumber. a Google open source library, to validate phone numbers internationally. For a deep dive into the area of phone number validation and all the issues that can occur, you can read this page. The library libphonenumber works by setting a “default” country code, from which all numbers are validated. A number is considered valid if you, by calling that exact number from a phone in the “default” country, could succeed in placing a call. However, this can quickly become complex, making it important to follow the standard. Consider these cases: Case 1: If the default country is SE, the following numbers are valid: 0707104603, +46707104603, 0046707104603. This is because “00” is the international calling code from Sweden. Case 2: If the default country is US, the same number, 0046707104603, would now not be valid, since “00” is not an international calling prefix in the US. So, although it will sometimes work, you should never send phone numbers using only the country code (without prefixing ”+”). There are many ambiguities where it is impossible to distinguish a country code from a regional code. For example, 468211415 will be validated as a number with regional code 046 (Lund) instead of a Swedish number (46) if called from regional code 08 (Stockholm). Thereby it will be stored in the database as 46468211415. Similar things can happen with Norwegian numbers that have country code 47, but local numbers may themselves also start with “47”.
A phone number should always be made of a ”+” prefix followed by [countrycode][phonenumber].
Using “local” phone numbers based on the default country code should only be done when manually entering phone numbers in Customer Engagement, i.e. when searching, or using the LoyaltyBar, or on registration forms.

​
Email (email)

All emails in Customer Engagement are validated according to RFC 5322, addr-spec. Read the details of RFC 5322 here. Read a general explanation of email standards here.

​
Country code (countryCode)

Country codes follow the ISO 3166, alpha-2 naming standard. Some useful examples are:
  • SE = Sweden
  • NO = Norway
  • GB = Great Britain (and Northern Ireland)
  • NL = Netherlands
  • IE = Ireland

​
Language (lang)

Some markets / countries use multiple languages, for example Belgium, where Dutch and French are both used. Here, the countryCode contact attribute isn’t enough to identify the end-user’s language. In cases like this, the lang (language) standard contact attribute can be used. The lang contact attribute is of type Language, and follows the ISO 639-1 standard. Examples:
  • en = English
  • sv = Swedish
  • nb = Norwegian (bokmål)
  • de = German
Since the list of languages is very long and can be troublesome to navigate when manually setting a contact’s language, a custom-made shorter version of the list can be configured for your tenant, showing only the languages you intend to use for your contacts. Contact your Voyado team to do this.

​
Preferences and accept flags

A contact also has several optional preference fields defining how they wish to be contacted, known as accept flags.
If these accept flags are used, they must be set to either true or false, and never to null.