Overview

Cubed supports the ability to process Visits in real time and place them into Segments based on Rules.

Under the hood this is all supported by pre-defined Functions, with specific inputs and outputs, being used to create Conditions - with different values - that combine into a single Rule.

Each defined Function is given a Function Category (currently visit, or visitor) and when used in a Condition must provide a legal Function Operator. Function Operators can range from standard python startswith or simple math >=, all the way to Custom Operators (more on this later).

The concept of Segment Rules can now be used for Segmentation and Advanced Patterns.

Segmenter Tables Overview

Here is a list of all tables used, their design and purpose.

The table designs were structured to help support the frontend Rule Builder while also providing enough information for the DPS code to run.

Base Function Types

The below base function type tables sit in the clients database.

Table: attrib_function_data_type

This holds a name for data type that a function excepts to be. This includes everything from date, to time, datetime, and float. This also includes some custom concepts like money and could support Cubed specific referer.

Table: attrib_function_operator

This holds a simple name:symbol concept so we can display in the frontend Symbols for functions and their values, while using the opposite in the code behind. The name follows Django functional names (gte, lte etc..), while the symbol allow us to string replace for python code: 1 >= 0.

Table: attrib_function_data_type_operator

This holds a connection between data_types and their valid operators.

Everything here is primarily for the frontend to help build auto completing, validating, rules. For example, if I use a function with a data_type of Datetime, then it should bring up a Calendar Date Picker.
If I pick a function with a numerical data_type, then from the operators it should only bring through mathematical operators and no string based ones like "startswith" or "contains".

Table: segmenter_category

This holds a category type that a function excepts to be. We currently support two types of function categories - Visitor and Visit. Each function that is set-up will need to be linked to a category type in segmenter_function_category.

Segmenter Functions

The below segmenter function tables sit in the clients database.

Table: segmenter_function

A static table that is deployed to when ever we want to add a new function to the PyDPS/Segmenter project. All clients have all the same functions. A function has a display_name which is shown in the frontend, with a corresponding function_name which maps to a function in the Segmenter code base (see the Rule.py class).

This table has a couple of extra pieces of information to help build the frontend with correct validation. Each function is assigned a data_type (as seen above), but also can be assigned a specific table_name along with table_key_name and table_value_name. The idea here is if a user picks a Function that must use a Referer - then don't let them accidentally write in the wrong Referer name etc.. display a drop down that is populated with the key:value of id:name from attrib_referer (table_key_name, table_value_name, from table_name), these are NOT to be used in the actual code.

Table: segmenter_function_category

For each function that exists in segmenter_function, we should also have a row in segmenter_function_category which assigns a function to a category (segmenter_category).

Table: segmenter_conditions

Once we have picked a Function that we want to use, we will create a Condition from it. In the frontend that would be using a nice drop down etc.. and filling in "values" needed.

All Conditions need the same things: function, operator, value.

Here we have used the function visit_is_channel which we know is looking for the data_type Number in its Function table, so we use the operator eqls which translates into == in our python code. The value we are looking for is the referer Id 2. When creating this Condition in the frontend, while following the Function properties before, we would have picked an id from the table_name drop down of attrib_referer where table_value_key was id.

The next 2 functions are visit_has_discount_code which uses the data_type of String so we can use startswith and contains. Again via the frontend this can all be strictly defined via drop downs with an input text field at the end for value.

It is worth noting the has column. All Conditions by default will have this as True. The has is to flag a Condition that should return True when it is successful. Meaning if this is un-ticked then the Condition will reverse its returned result from True to False.

In Python this could then be written similar to:

if not function.has:

It will be rare to use this, but does mean that when all Functions are created as a Condition, they can be used in both their positive or negative states.

Now we have some Conditions we can make Rules.

Segmenter Rules

We currently support Visitor Segmentation and Advanced Patterns. Both take a roughly similar approach: build a rule of Conditions using Ids.

For example, here is a rule asking for condition 1 to return True and either 2 or 3 to also be True:

1 and (2 or 3)