What is a Property?

Properties are used to add additional information to an event. For example, we can add item type price to an “item_added” event.
The number of properties for each event is only limited by the total number of available properties in the project.
You can send any properties with any event you send to CoolaData.
Each property is defined by the following meta data:

CoolaData provides two types of properties: standard and virtual properties (see below).

 

Defining a Property

When working in Lock mode, define your properties using the properties management interface.

  1. Open Project projecticonProperties  properties.
  2. Click on Add button in the top right of the window to add a new property.
    4-5
  3. Select Property. The following displays:
    4-6
  4. Fill in the window as follows and click the Save button.
    • Name: Describe the property of the event in lowercase without spaces. For example, button name, url, application_name, amount and so on. This is the name that appears in CoolaData in all visualizations and which you can query.
      • Property names must begin with a letter, and can contain letters, numbers, and underscores (space and dash are not supported).
      • Names cannot use any CQL functions, such as: Select, From, Where, As, NULL, And, Between, Join, Left, Outer, Inner, On.
      • Names cannot use a CoolaData reserved words – the following is a list of CoolaData reserved words:
        internal_user_id
        internal_session_id
        user_alias
        session_clean_path
        session_duration
        session_end_time_ts
        session_events_counter
        session_full_category_path
        session_full_clean_category_path
        session_full_clean_path
        session_full_path
        session_funnel_path
        session_serial_event_counter
        uid
        sid
      • Properties names are not case sensitive, so ‘User_Level’ and ‘user_level’ will be treated as the same property.
        Properties values are case sensitive, so the values ‘US’ and ‘us’ will be treated as two distinct values.
    • Source: Specify the name of this property as it appears in the JSON of the event that arrives at CoolaData. CoolaData uses the Name property (described above) like an alias. Use the Name property to query your data.
    • Data Type: Specify the data type: Integer, Float, String, or Timestamp.
      • In order to send a Boolean data type (such as Yes or No), either use string (TRUE/FALSE) OR integer (1/0).
      • In Self-Learning mode, CoolaData automatically interprets a timestamp property in an event as String data type regardless of whether it was sent in the JSON inside quotes or not. The best way to ensure that CoolaData handles a property as Timestamp data type is to define it as Timestamp in the Data Type field (described above) before the event is sent with this property. The event must also be sent according to the proper property data type syntax.
      • It is not possible to change a property’s data type once it is created. To do so, the property and all the data saved with it until that point will have to be deleted. It is recommended to create an new property instead in order to avoid data loss.
    • Scope: Select the scope of this property. We recommend that when you are first starting out with CoolaData, that you use EVENT scope. It is not possible to change a scope of a property once it is created. To do so, the property and all the data saved with it until that point will have to be deleted. It is recommended to create a new property instead in order to avoid data loss
      • Event: data applicable only to a specific event.
        Example: “price”:”52.50″ – the next event in the session will not have a value for the “price” property unless specifically sent with it.
      • Session: data applicable to the entire session, i.e. the specific visit to the site/app. Session scope data will be added to all events in the session following the event that included this property.
        Example: “device_type”:”iphone 6″ – all the following events in the session will include the this property’s value. If during the same session, a new event with a different value for this property is sent, it will take over for all consecutive events in the session. The final value received will be the one saved for the session, i.e. will be the value returned when querying only at the user/session scope. This property will not contain any value in the next sessions until updated per that session.
      • User: Applicable to a user’s lifetime. A user scope property will be added to all events of this user following the event that included this property, including in future sessions.
        Example: “user_email”:”sam@work.com” – assuming that the user property will continue to be true for all future actions, every event of the same user from that event on will include the user property “user_email” with the value “sam@work.com”. This will continue unless the value is overwritten by a new event with a different value for this property, which will take precedence from the new event forward.
      • Automatic Scope Mapping: When using the self-learned mapping, the scope is set automatically based on the metadata received. The default scope is event. To change the automatically assigned property scope, add a prefix to the property name. Once a property scope is saved the property scope prefix will be ignored, i.e. if the property scope prefix is changed or removed, it will not change the scope of the event. The prefixes are:
        • {s} for SESSION scope. Example: {s}referral_id
        • {u} for USER scope. Example: {u}source_campaign
      • Enriching events: Enriching events with user/session scope properties requires the value to first be saved – it will only take effect with the events received after it. Therefore, if multiple events are sent simultaneously, these events might not include the property value.
    • Lookup values refreshing: CoolaData manages lookup tables for up to 300 of the values received for each property. Select this option to specify that CoolaData keeps the 300 most recent values of this property versus the first 300 values received by CoolaData. By default, this option is not selected, meaning that the first 300 values are added to the lookup table and newer values are not added.
    • The following shows an example of where this lookup table appears in the user interface. This example shows a filter definition dropdown menu showing the values from a lookup table:
      4-9
      Examples of when to turn this on (refresh): when it represents recently published articles, popular songs and so on.
      Examples of when to turn this off: when it represents countries, statuses or device types, because there’s not more than 300 such values, and they don’t change very often.

 

Examples

After you define a property’s data type or after CoolaData has learned its data type (when in Self-Learning mode), then any event that arrives afterwards with a different data type (as determined by the syntax below) is sent to the CoolaData Invalid Events list.

  • Integer Property: Must be a plain integer number. For example, “depositamount”:100.
  • Float Property: Must be a float number. For example, “depositamount”:100.3.
  • String Property: Must be encased in double quotes. For example, “event_name”:”deposit_server”.
  • Custom Timestamp Property: This type of property is added to an event by you. It must be encased in double quotes and using timestamp format. For example, “metadata_command_create”: “2015-10-21T18:02:13.627382+00:00”.
  • Common Event Timestamp Property: This type of property is automatically added by CoolaData to an event. It must be encased in double quotes and using Epoch timestamp format. For example, “event_timestamp_epoch”: “1461263697530”.
  • User Identifier: The user_id specifies the identifier of the end user who performed the event. The user ID can be assigned by you or by a CoolaData Tracker. To specify your own identifier for each user, simple include the user_id property in the event’s JSON encased in double quotes. CoolaData will not overwrite it. For example, “user_id”: “1”.
  • Session IP: The session_ip specifies the IP address of the user’s session in which the event occurred. The session IP may be assigned by you or by a CoolaData Tracker. To specify your own session IP, simple include the session_ip property in the event’s JSON encased in double quotes. CoolaData will not overwrite it. For example, “session_ip”:”192.168.255.255″.

An example of an event with a lot of properties:

 

Virtual Properties

You can define that a Virtual Property is automatically added to an event. The value of this Virtual Property is based on a JSON or an expression that you define in the CoolaData Administration console, as described below. Typically, the value of the Virtual Property is dependent upon the value of another property in that same event.

For example, a Virtual Property whose value is defined by a CQL function that extracts the domain name of an Email property in the same event.

Another example is a Virtual Property whose value is determined by an expression that groups events based on the value of another property. An example of this is a Group property whose value is based on the value of a Money property. The Low Group could be all events whose Money property has the value 0 – 500, The High Group could be all events whose Money property has the value 501 – 1000 and so on.

A Virtual Property can then be used throughout CoolaData in the same way as a regular property. For example, in KPI, Cohort and Funnel reports.

There are two kinds of Virtual Properties:

  • Virtual Dimension: A Virtual Dimension property enables you to replace the value of the property sent in the event with a specific set of strings according to the logic that you define. This is typically done in order to categorize events (meaning to divide them into groups) according to the value of the property sent in the event. After the event is stored in CoolaData, you can query this property in the same way that you would any other property.
    Example: A Virtual Property named Region can represent geographical regions that contain various countries. The value of the Region property can be automatically changed to according to the definitions specified in the CoolaData Administration console (as described below). For example, if the Region property is sent to CoolaData containing any of the following values – France, England or Spain, then this property is changed to the value Western Europe.
  • Virtual Measure: A Virtual Measure property enables you to replace the value of a property sent in an event using a CQL function that you define in the CoolaData Administrator console (as described below). After the event is stored in CoolaData, you can query this property in the same way that you would any other property.
    Example: Multiplying a monetary property value, concatenating a string to the value or stripping out the domain name from a URL address.

 

Creating a Virtual Property:

  1. Open your workspace in the CoolaData Administrator console and select Project  → Properties  properties.
  2. Click on Add  button in the top right of the window to add a new property.

9-2

  1. Select Virtual Dimension or Virtual Measure. Click the relevant option to see how to define it.
  2. Click the Save button.

 

Automatically Enriched Properties

Each CoolaData tracker automatically enriches the events that you send by adding more properties (these are also called common properties).

For a full list of common properties see Common Properties.

 

Handling Personally Identifiable Information (PII)

CoolaData accepts any event properties that you send without filtering them.

CoolaData takes the utmost precautions to ensure the security of your data in the cloud and continually upgrades with the latest security options.

However, even so, we advise you not to send sensitive personal information (such as credit card numbers) that may help a malicious entity identify someone.

Tip – Here are a few tips for protecting personal information –

  • Conceal personally identifiable information. For example, by scrambling, cloaking, encrypting, faking or hashing it.
  • Send a person’s location, instead of their IP address.
  • Send only partial information, such as a person’s country instead of their IP address.
  • Do not send combinations of information that may help someone piece together who the person is, such as session IP, address, gender and age.
Print Friendly