Defining a Property

Here’s how to define the properties that are accepted by CoolaData.

Note – Self-learning mode is the default CoolaData operation mode. In Self-learning mode, there is no need to define properties. Therefore, you can skip this section, if CoolaData is configured to Self-learning mode (not Lock mode).

Each property that you define can belong to any event sent to CoolaData.

To define a property:

      1. Open your workspace in the CoolaData Administrator console and select Project projecticonProperties  properties.

4-5

      1. Click on Add button in the top right of the window to add a new property.
      2. Select Property. The following displays:

4-6

      1. 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.
        • 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, such as Integer, String, Timestamp and so on.

GSSC 1Check this out to see the syntax for sending properties with various data types.

        • Scope – Select the scope of this property. We recommend that when you are first starting out with CoolaData, that you use EVENT scope.
          • EVENT (default) The value of this property only applies to the event in which it appears. For example, deposit_amount or page_viewed.
          • USER – The latest value of this property affects all future events of the same user. For example, user_status or user_address.
          • SESSION – The latest value of this property affects all events of the same user in the same session (from the session’s start until its end). For example, user_location or user_app_version.
        • Classification – Selecting this option determines how CoolaData handles this property in the user interface.

Generally, CoolaData uses a property’s Data Type field (described above) to determine how to handle that property in the CoolaData Admin Console and database. However, in some cases, you may want the property to be handled differently than its data type indicates. For example, when a property is defined with the data type String, but that property contains a numeric value.

          • DIMENSION – Typically, this property is a string that describes something. The following is an example of filter operators that are offered by CoolaData for a DIMENSION property. These operators are all suited for strings –

4-7

          • MEASURE – Typically, this property is a numeric value. For example, enabling aggregation and averaging, as well as slicing by comparative operators, such as less than (<) or greater than (>). The following is an example of filter operators that are offered by CoolaData for a MEASURE property. These operators all suited for numeric values –

4-8

        • 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

Tip – Here are a few examples of when it is a good idea to turn this option on (refresh) – when it represents recently published articles, popular songs and so on. Here are a few examples of when it is a good idea to turn this property 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.

Tip – In order to send a Boolean data type (such as Yes or No), use string data type and enter the values Yes and NO. Another option is to specify an Integer data type and to enter the values 1 and 0.

Tip – 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.

Event Property Data Type Syntax

Here’s the syntax for sending properties with various data types.

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.

JSON Structure Example

{“event_name”:”deposit_server”,”transaction_id”:”683219″,”session_os”:”PC”,”depositamount”:100,”pearlsamount”:”0″,”blackpearlsamount”:”0″}

      • 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″.

Virtual Property

Introduction

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.

GSSC 1To see how to create a Virtual Property.

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.

GSSC 1To see how to create a Virtual Property.

Creating a Virtual Property

To create 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.

Call me if you need anything.

  1. Click the Save button.

Properties Automatically Enriched by CoolaData

Each CoolaData tracker automatically enriches the events that you send by adding more properties (these are also called common properties). The following are a few examples:

GSSC 1For more information about properties that are automatically enriched in each event by CoolaData.

  • event_timestamp_epoch/event_time_ts – Specifies the time the event actually occurred – EPOCH time format (also called UNIX time). To specify your own timestamp for each event, simple include the event_timestamp_epoch property in the event’s JSON. CoolaData will not overwrite it. Add link to timestamp topic

GSSC 1For more information about timestamps.

  • user_id – Specifies the identifier of the end user who performed the event. These user IDs may be assigned by you or by a CoolaData Tracker. Add link to user_id topic

    • Assigned Automatically by CoolaData – CoolaData automatically assigns a unique identifier to each end user.
    • Assigned by You – To specify your own identifier for each user, simple include the user_id property in the event’s JSON. CoolaData will not overwrite it.

GSSC 1For more information about Sending User IDs.

  • session_dua – Device User Agent (DUA) describes the device (model, version, screen dimensions and so on) from which the event was sent, and may include the browser and more. CoolaData uses DeviceAtlas to convert the session DUA into more clear and detailed information, such as the following property list:

4-10

  • tracker_type – Specifies the type of CoolaData tracker used to send the event, such as JavaScript.

Note – In addition to the properties that are automatically added, you can add a variety of additional properties for any purpose that you see fit. For example, you can add account_id, game_id, deposit_amount, score, a/b_testing_property_1.

 

 

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