Opti CMS Profile Visitor Groups

Opti CMS Add-On
C#
GitHub Repository

What It Is

Code to manage and query an instance-local data profile about the current site visitor

Status

Last Reviewed:

I don’t know if this was ever implemented. I wrote it for a POC, but no idea what happened to it after that.

Details

With Opti CMS, we’d often find that customers wanted to query other data sources to segregate visitors into Visitor Groups for personalization. THere are two problems with this:

  1. Latency. Visitor Group criteria evaluated on every request, and querying some external repo each time just wasn’t wise
  2. Criteria. A custom repository would require custom criteria, and that would often get unmanagable

So this system provide a framework to:

  1. Aggregate data from external repositories and “bring it local” to the Opti instance
  2. Provide a general set of Visitor Group criteria that let marketers dine their own groups

The system was really extensible – everything was a service. You provided one or more “data loaders” which were functions that would execute on session creation, retrieve the data from wherever, then store it local memory. The default structure was a key/value store, but it was extensible, and I think I have a JSON-based version demonstrated in their as well.

(The “or more” part was important. You could fire off a dozen data loaders against a dozen different systems, and then you could thread them together into a unified object. And you could execute them async – they would just update the profile when they returned.)

I was really proud of the Visitor Group criteria. There were five. For each, you specify a key (the actual key for the key/value store, or a JSON select string, or whatever), and then criteria to evaluate against:

  1. Text: compare if a text profile value equals, starts with, ends with, contains, (etc.) a provided number
  2. Number: compare if a numeric profile value equals, is greater than, is less than, (etc.) a provided number
  3. Date: compare if a dated numeric profile value equals, is greater than, is less than, (etc.) a provider date
  4. Relative Date: compare if a specified part of the timespan between a dated profile value and now equals, is greater than, is less than, (etc.) a provided number
  5. Exists: determine if a key does or does not exist (regardless of value)

Multiple keys could be comma-delitmed with would use the first key which returned a value.

It was a neat system that solved a lot of problems. There’s a lot of documentation at the repo URL.