Data Types & Name Limits

Acceptable data types and limits for contact attributes and event properties

Summary

  • Contact & Event Property Data Types: Each property on a contact or event has an associated data type. Once a property is cast, the value type cannot be overwritten, and API calls/events attempting to set or update an existing property with a value that cannot be coerced into the appropriate type will fail in journey conditional nodes.
  • Event Property Names: Your Regal account can contain up to 8,000 unique event property names. If the same field name is used on various events, each with a different event name, it counts multiple times against this limit. Mapping events to a single event name, and using properties and categories to capture specific information, cuts down on the number of field names in use.

Contact & Event Property Data Types

Each property on a contact or event has an associated data type: string, boolean, double, long, date, object, or array. These data types are used in conditional node filtering when determining which contacts are eligible for certain steps in a journey.

⚠️

Datatypes cannot be updated

Once a property's datatype is cast, the value type cannot be overwritten. Thus, it is important to set the right data type when creating fields in Regal for the first time. API calls attempting to set or update an existing property with a value that cannot be coerced into the appropriate type will fail in journey conditional nodes.

Datetime

A date property (when contained in either traits or properties) is a specific type of string in Regal. Acceptable date formats include:

  • yyyy-MM-dd HH:mm:ss ZZ
    • 2000-01-01 00:00:00 -04:00
    • 2000-01-01 00:00:00 Z
  • yyyy-MM-dd HH:mm:ss
    • 2000-01-01 00:00:00
  • yyyy-MM-ddTHH:mm:ss.SSSZZ
    • 2000-01-01T00:00:00.000-04:00
    • 2000-01-01T00:00:00.000Z
  • yyyy-MM-dd
    • 2000-01-01
📘

Z literal shortcut

The Z literal can be used in any format that takes a timezone (ZZ) as a shortcut for UTC (+00:00)

⚠️

Local_time function in journey webhooks

When updating datetime contact attributes with unix/epoch timestamps using a Jourey Webhook node, a ast, the value function must be used to ensure the correct datetime format is passed to the contact. See this doc for example.


String

A string is most commonly used for text. When setting a string value, surround its value in quotes.

  • "firstName": "Rebecca"

Boolean

True or false. Acceptable boolean values include true and false.

  • "existing_customer": true

Long

Longs are numbers that do not have decimal points.

  • "age": 21

Double

Doubles are numbers that have decimal points.

  • "price": 124.14

Doubles and longs are both referred to as "Numbers" in Regal. Both are acceptable.

Objects

Objects are collections of related fields. For example, to represent the various attributes of a dog, use an object.

{"dog": 
  {"name": "Snickerdoodle",
  "color": "Brown",
  "age": 4,
   "favoriteToy": "Rubber bone"}
}

Arrays/Lists

Arrays are lists of items. For example, to represent a list of a dog's favorite foods, use an array. Arrays can contain objects, and arrays can belong to objects.

  • "favoriteFoods": ["Salmon","Chicken","Carrots"]

Event Property Names

Your Regal account can contain up to 8,000 unique event property names. If the same field name is used on various events, each with a different event name, it counts multiple times against this limit. Mapping events to a single event name, and using properties and categories to capture specific information, cuts down on the number of field names in use.

For example, if you send the following 3 events:

"name" : "Checkout - Georgia",
"properties" : {
  "price": 53.00
}


"name" : "Checkout - Florida",
"properties" : {
  "price": 124.00
}


"name" : "Checkout - California",
"properties" : {
  "price": 124.00
}

That counts as 3 unique event property names:

  • Checkout - Florida.properties.price
  • Checkout - Georgia.properties.price
  • Checkout - California.properties.price

However, if instead, you send the event as follows with state as a property of the event:

"name" : "Checkout",
"properties" : {
  "price": 124.00,
  "state": "Florida"
}

Then it only uses up 2 unique event property names:

  • checkout.properties.price
  • checkout.properties.state

If you consider all 50 states - approach 1 would utilize 50 unique property event names, whereas approach 2 would utilize only 2 unique property event names.