Welcome
Geek
VITES™ Rules Engine
This is the real heart of the system and the only bit that possesses any intelligence (rather than simply doing what it has been told). Both the Rules Engine and Response Engine run as daemonized processes using Net::Server::Fork.
The rules flow follows, at least in our usage, a clearly defined path as dictated by the "Rules File" (see below):
#====================================================================
# INITIALIZE RULE
#====================================================================
rule initialize on start
# Theory is to keep the initialize rule generic...
# ...any client specific initialization stuff can go in the call to
# do_initialize()
# set internal referrer
set data.vites_referrer = data.vites_content;
set data.vites_referrer.probability = 100;
# set data scoped content from request
set data.vites_content = request.vites_content;
# push any important ENV vars to data scope for posterity
set data.t_temp = env_to_data( "HTTP_USER_AGENT", \
"REMOTE_ADDR", \
"CGI_SESSION_ID" );
# client specific initialization
set data.t_temp = do_initialize();
end rule
#====================================================================
# FUNCTIONAL RULES
#====================================================================
# One rule to rule them all, one rule to find them, one rule to bring them all
# and in the darkness bind them...
rule r_do_functions on start
set data.t_temp = do_functions();
end rule
#====================================================================
# PROFILE RULE
#====================================================================
rule find_profile on profile
set data.profile = get_profile();
set data.profile.probability = 100;
end rule
#====================================================================
# RESPONSE RULE
#====================================================================
rule add_response on start
add response web data.vites_content;
end rule
As you can see, rules are written in a language of our own creation, something which may change in the future. This file forms the central control structure for the processing of the rules. The flow is fairly straight-forward and each stage contains a hook into the Perl code so you can pretty much do what you want:
-
Initialize
Set anything up that needs to be set up before we get to the meat of the functionality.
-
Functions
This is where everything except the profiling and addition of the response occurs. More on this stage later.
-
Profile
Calculate the VITES™ Profile of the visitor. This ultimately determines what the visitor is shown.
-
Response
...and add a response code in a format that ATC and the Response Engine can understand.
At this stage, some additional reading is probably required to better understand what is going on. If you don't want to know, don't care or have already guessed, skip straight to the Response Engine.
VITES™ Data
VITES™ stores "things we know or guess" about a visitor in a VITES™::Language::Variable object. The object has four critical attributes: a scope, a name, a value and a probability. The probability attribute indicates how certain we are about the value attribute on a scale of 0 to 100+.
The two scopes that you will (largely) be dealing with are "request" and "data". The request scope contains the parameters from the incoming (HTTP) request. Request scoped variables always have a probability of 100.
The data scope contains only that knowledge which we choose to add to this scope. The data scope is used to store variables that will be used later (either in the same or subsequent sessions). For example, a function to handle a simple web form may simply clean and move the incoming request scoped variables into the data scope for later use or reporting. For example:
Incoming variable:
{
scope: request
name: postcode
value: "hx35ax"
probability: 100
}
Cleaned and moved to data scope:
{
scope: data
name: postcode
value: "HX3 5AX"
probability: 95
}
Note that we have decremented the probability very slightly. Since we have performed an operation (cleaning) on the value we can no longer be 100% certain the value is what the visitor intended (although we're still pretty confident!).
Every variable in both the data and request scope is written to the VITES™ database on every request. This ensures we always have the current picture and a full transaction history, should we need to retrace the visitor's steps.
VITES™ Profiles
The VITES™ Profile is how we categorise the visitor and show them the appropriate "depth" of content. It is stored as a data scoped variable named "profile". You are not confined to specifying, creating, using or calculating profiles in the way shown below, though it serves as a good starting point.
The profiles exist as a matrix (sort of) or, if you prefer, a tree. Anyway, they are configured like this:
# profiles.conf
# Level One
male female
# Level Two
young old
The order of importance runs top to bottom and right to left (there is a good reason This allows you to write a "sales stage" layer as: stepA stepB stepC stepD. If these are all equally "true",
i.e. completed, you clearly need to be in the stepD rather than stepA profile path, but it is more natural to
write this as above than stepD... stepA!
<default>
male # parent profile is default
female
young # parent is default
old
male.young # NB: male is level 1 and young level 2, so not young.male
male.old # parent is male
female.young # parent is female
female.old
We use a period/full stop/dot (.) to concatenate profile blocks into a full profile (you can change this if you like).
Each profile has a parent (except "default", which is the base profile). The parent is typically the profile shown by everything up to the final dot, or "default" if there is no dot. This is not set in stone but it does help stop your brain going into meltdown once you get a few hundred profiles. The Response Engine finds the correct content to display by first searching for all the templates, includes and data capture includes in the visitor's profile, then the parent profile, then the parent's parent and so on all the way back up to the base profile "default".
Because of the cascading nature of the way the Response Engine hunts down the content to display to the visitor, you can very quickly build up a fairly complex profile tree with only the minimum required creation of new assets. Here is a very simple example from our internal idiot's guide.
As with most of the innards of the Rules Engine, you can perform the profile calculation in any way you like. However we include a standard module for doing this according to our top-to-bottom, right-to-left matrix. The "default" test for each level is to find the "truest" value or nothing if no values on the level are true, although this can easily be modified and extended _without_ having to write your own profiling module.
VITES™ Rule Functions
VITES™ Rule Functions, simply referred to as functions from here on, are essentially any code you add to the Rules Engine to extend the functionality of VITES™. A whole collection of standard functions are included "out of the box", though these can be changed, deleted or added to depending on taste and requirement.
Though there is no implementation distinction, we find it is helpful to think of the functions falling into two categories: "Learning" and "Doing".
"Learning" functions perform some manipulation of the data we hold linked to an individual. The most basic learning function (as illustrated in the VITES™ Data section) is simply to store what the visitor tells us (by moving the request scoped variables to the data scope). Most learning functions will create or adjust one or more data scoped variables based on a set of assumptions. By way of simple example, clicking on a link for "Menswear", which contains an appropriate request trigger, could increment the probability of the data.is_male=true variable by 20 points. A more involved example might be the adjustment of a whole raft of assumptions (data variables) based on demographic/socio-economic/behavioural data we already know (by being told or having learnt thanks to VITES™) about the "average" visitor on an inbound link from a particular external advertising source.
"Doing" functions, surprise surprise, do just that! They do stuff! VITES™ on its own doesn't do anything that isn't associated with calculating and serving a response to the browser. If you want something to happen when a visitor clicks a link or completes a form, this is where you implement it. There are quite a few "standard" doing functions already in VITES™ that handle the most common (and some uncommon) things you might want do with a click or form fill, but the system is designed to be flexible and extensible so you can pretty much run any code you like: talk to CRM systems, send emails, etc etc - the list is as long as you need...
A typical request may trigger many different learning and doing functions.
Contact
Page weight: 50KB