Overview

Properties are used to add additional information to an event. For example, we can add the “item_type” to an “item_added” event.
You can send any properties with any event you send to Cooladata.
The number of properties for each event is only limited by the total number of available properties in the project.

From the Properties page you can manage all the properties in project. Here you can:

  • Create new properties
  • Update existing properties (including changing property scope – see below)
  • Delete properties

Cooladata provides two types of properties:

  • Standard properties: values you send as parameters with your events, as described below
  • Virtual properties: calculation on your data, carried out on demand, when queried – see more here

As long as you project is set to “Self learned”, properties are created automatically as you send them, and added to the Properties list (see Data Schema Configuration for information on the mode properties are created in). If you do not use the “Self learned” schema, you will have to manually add properties to your project. This is also useful when you want to manually specify the property settings.

 

Creating a new property

  1. From the project menu (cogwheel icon on the top right) select Properties.
  2. To add a new property click the + button at the top right, and select Property.
  3. Enter the property settings, as below.
  4. Click Save.

The property will be added to the properties list and schema, and will be stored according to the settings you defined when next received.

 

Property Settings

Name

The name of the property that will be used in queries and property lists.

Property names:

  1. Must begin with a letter
  2. Cannot contain spaces or special characters
  3. Are not case sensitive: querying a property can be done using in any capitalization. Note that properties values are case sensitive, so ‘US’ and ‘us’ will be treated as two distinct values.
  4. Cannot be an SQL functions (such as: Select, From, Where, As, NULL, And, Between, Join, Left, Outer, Inner, On).
  5. Cannot use a reserved word:
    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

Source

The name of the parameter sent with the event that represents this property. Can be different from the property name.

Data Type

Cooladata supports the following data types:

  • Integer
  • Float
  • String
  • Timestamp

Boolean values can be saved using integer (1/0), or string (TRUE/FALSE).

It is not possible to change a property’s data type after it has been saved. We recommend replacing this property’s Source with an unused expression and creating a new property instead, to avoid data loss (the old property can be deleted later in any case).

Scope

The property scope determines for which events the data received is saved.
Cooladata managed 3 scopes of properties:

  • Event: data is saved only with the specific event.
  • Session: data is saved for the entire session (visit). Session data is added to all the events in the session following the event that this property was sent with. 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 and will be the value returned when querying only at the user/session scope. Events in the following sessions will not include this property.
  • User: data is saved for the entire user’s lifetime. A user scope property will be added to all events of this user following the event that this property was sent with, including future sessions. 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.

Examples:

  • “price”:15.49 – is only relevant to the “purchase” event. It should be set to “Event” scope, which will only be saved with this event.
  • “device_type”:”iphone 6″ – as the device does not change during the session, it should be set to “Session”, which will be saved with all following events in the session.
  • “user_email”:”john@work.com” – assuming that this is the email that belongs to the user for all his future events, it should be set to “User” scope, which will be saved with all future events in the user’s lifetime. If the email changes, it can be sent again and update for all following events.

User and Session scope properties requires the value to first be stored in Cooladata in order to effect following events. Therefore, they will not be applied to other events sent simultaneously with the event that included them.

Automatic Scope Mapping using Scope Prefixes:

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.
The prefixes are:

  • {s} for SESSION scope. Example: {s}referral_id
  • {u} for USER scope. Example: {u}source_campaign

Once a property is saved, the scope is set and the property scope prefix will be ignored, i.e. it is not possible to change a property scope using prefixes. If the property scope prefix is changed or removed for future events, it will not change the scope of the event.

Lookup values refreshing

Cooladata manages up to 300 lookup values for each property.
Lookups are used to select values from lists, in condition with “is in list” or “is not in list”. The following shows an example of where this lookup table appears in the filter:

4-9

By default, the first 300 values are added to the lookup list (and newer values are ignored).
Select this option to keep the 300 most recent values of this property instead.

First Value

When on, Cooladata will save the first value received for each session after the property was created. Example: use to store the referring URL.

 

Examples

After you define a property’s data type or after Cooladata has learned its data type (when in Self-Learning mode), 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, “avg_deposit”: 76.32.
  • 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 custom properties:

 

Print Friendly, PDF & Email