Using Sitecore Engagement Plans as an Audience Segmentation Tool

Engagement Plan as Audience Segmenter

I've been kicking around the idea of, instead of strictly mapping out a customer journey with Sitecore Engagement Plans, to instead use them as a visual audience segmentation tool.  With the great analytics that Sitecore is collecting, this seems like a natural extension to be able to divide the visitors within that analytics data into well-defined categories of patterns.  I'll end this post with an idea that could be added to the current Sitecore concept of Pattern Cards (with your great development addition, of course).

An example audience segmentation Engagement Plan

The idea is this: use the States and Conditions of Sitecore’s Engagement Plan to get a visual indication of the distribution of your audience based on any segmentation criteria.  Since the Rules Engine is so nicely involved in the Engagement Plan Condition checks, this to me is an incredibly natural use of this tool.

The Idea in Launch Sitecore

Here’s how it falls out for Launch Sitecore.  Our audience segments are clearly defined by the groups we envision might visit us at www.launchsitecore.net.  However, this definition is strictly based on content consumption—using Sitecore’s Pattern Card matching, we simply watch for the thresholds between these content consumption patterns.  If someone is reading a lot of articles around Sitecore’s Digital Marketing System, we might conclude he appears to be a marketer.  While this is really cool and easy to do, I have always thought that these patterns need to be a bit more descriptive, inclusive of content consumption patterns and potentially a lot more.  In addition, the definition of this pattern should be flexible and open to change on an ongoing basis—without development.

Talking to a lot of smart partners and clients lately has verified my assumptions.  As we get into the real-world use cases, we talk about all the attributes that should come together to fully define a marketing persona—everything from campaigns to keyword use in search to “known” profile attributes in CRMs to landing pages to referral sources.

Enter the Rules Engine

Enter the Sitecore Rules Engine and the perfect modeling environment for this situation.  Back to Launch Sitecore and our example.  As a simple start, all I want to do is segment my visitor traffic between two opposing possibilities—the visitor appears to be a Marketer or the visitor appears to be a Technologist.  We know that a couple of our Patterns nibble at this persona, and through content consumption our visitor might look like Mark the Marketer, or Devon the Developer.  But what we’re shooting for here is a much richer definition of the age-old split between marketer and technologist.  (By the way, if you consider yourself the perfect marriage of both, give me a shout).

First, we begin with a State that everyone is going to start their journey in:

The initial Engagement Plan state that all our visitors start in

We also get to decide which visitors we want in this plan.  For example, we might only want to evaluate visitors from a certain campaign.  Maybe I'm writing lots of articles on digital marketing subjects, and I want to test if the readers of those articles exhibit what I've defined to be "marketer" behavior on the site.

For the visitors we decide to track in this Engagement Plan, the first assumption is that we don’t yet have enough information to define them as Marketer or Technologist.  But we can immediately rectify that by invoking the Rules Engine in our first condition check.  We could check for either, but we chose to to first see if we should deem this visitor as technical.

A set of conditions we can check for to see if some one is "a technologist"

Our Condition invokes the Rules Engine where we can build a very sophisticated grouping of attributes that, for us at Launch Sitecore, peg someone with the Technical label.  We’re going to use the Pattern Card matches as a possibility (now grouping a couple of them together that represent our two technical Patterns), as well as including an additional possibility that someone got to Launch Sitecore using the word “development” in their search phrase (i.e., “Sitecore development”).

While this is a simple example, hopefully you’re seeing the possibilities here.  Never mind how rich the out of the box condition set is in Sitecore (geography, site, where you are in the content hierarchy itself, etc., etc.), we also know that this condition could be absolutely anything you dream up that returns a true/false.

If the condition returns true, we’re done and place the visitor in the Technical bucket:

A state for those we've deemed to be Technologists

If the overall condition returns false, we drop down to the check for the Marketer:

A set of conditions we can check for to see if some one is "a marketer"

As before, we are able to reuse our initial logic around Pattern Cards, with Connie and Mark combining forces as a possible reason to label a visitor as a Marketer.  In addition, we look for a search keyword containing DMS (Digital Marketing System) as well as a check for my MarchBlogBlitz campaign.  Since many of my articles in this time period are covering Analytics, I’m making the assumption that we have some Marketers on our hands.  Keep in mind the ability to replace the “or”s for “and”s, giving us possibly more granular condition definition.  As above for the Technical case, if this multi-clause condition returns true, we dump the visitor in the Marketing bucket.

Nice little trick if both of these checks return false.  We simply put the visitor back into the Undecided state and let other things trigger another check (maybe the next check is done on a follow up Goal, Page Visit, Login Event or anything else we might wait for our visitor to accomplish).  We do this by one last Conditional check, which always returns True:

Send the visitor back until we're sure

Here’s another look at the overall plan:

The full audience segmentation Engagement Plan

Pretty simple, but sky’s the limit.  One really cool idea that fits nicely into this is a very simple geography breakdown.  I could have, for instance, three states representing West, Central, and Eastern United States and immediately drop visitors into those states as they enter the site based on our GEOIP resolution.  (Since I am in the world of ideas only here, be sure to appreciate performance implications of making such wholesale checks).

Manually test how a visitor maps to the plan

One last really cool thing.  Since I have lots of visitor information in our Launch Sitecore site, I can even run a visitor through my new Engagement Plan.  Using the Supervise features of Engagement Plans, I grabbed my user (the Visitor associated with my Facebook authentication).  I moved that User to my new plan and the Undecided State.  In Supervise, I can manually press the trigger:



Since my Conditions are checked at Session End (among other events), I chose to run the Session End Trigger.

Sitecore goes through the entire logic of my plan and determines that my user account should be placed in the Marketing bucket.

The results of manually sending someone through the plan

Way cool.

NOW GO DOWNLOAD LAUNCH SITECORE.  (Need to get that great data for my reporting experiment).  I’ll let you know how our audience trends between this new Marketing and Technologist segmentation.

Extra Credit

For the interested student and the great developer….

Where I think this would be even more interesting is to use this same logic in the Pattern Card feature of Sitecore.  My prototype took all of 2 seconds (since it doesn’t in any way work).  But for an enterprising developer that adds the Rules logic to the Pattern Card check, this seems like a killer feature:

This becomes especially interesting considering Pattern Cards are an automatic dimension of Sitecore’s Analytics reporting.

The Personas for Launch Sitecore

In showing Sitecore to prospect partner and clients, one of the things that inevitably starts some exciting discussions is Sitecore’s Customer Engagement Platform’s capabilities around customizing the Web experience based on marketing-defined Personas.  By the time we’re on the phone or sitting across the table, this is generally an exercise that has already been discussed.  Depending on the situation, you might be already incredibly deep into this process, with finely-tuned and clearly defined Personas, describing your target audiences in terms of all kinds of detailed attributes, demographics, buying patterns, etc.  In other situations, this might be exceptionally informal or barely defined at all.  You might have a general idea who hits your site, where they’re coming from, but you haven’t created these buckets of generalization to group those visitors into categories—categories that can drive experiential differences for them.

Sometimes this conversation can lead to, “why would I do that, and, more importantly, what happens if I do this WRONG?”.  Very fair question, and very smart to be cautious.  I think, generally, when this feature of the Customer Engagement Platform is first considered, creativity can get the best of us.  I hear this in meetings all the time, where the room starts to buzz with possibility—“what if we did that, or this, or moved this here because of that, or hid this because of that?”.  This is all good excitement and is the exact full-cycle brainstorming session that you should go through once the dust of initial giddiness has settled.  Even in a 1-2 hour first meeting around the Customer Engagement Platform, someone in the room with the right combination of fear, power and cynicism says, “STOP!”.

The air that left the room took with it a bit of excitement, but it also left room for a bit of rigor that any good human-based project needs.  We all tend to want to see and play with the IPhone 7 instead of enjoying the continual, measured improvement along the way.
So, with the giddiness out of the room, think.  Not about stage Z, but about stage B (you’re at A).  What are the simple, nuanced things that might change based on your having a general idea of who this visitor is?…not the logged in user who gave you his profile, but the visitor that came from a certain referrer, used a certain keyword, landed on a certain landing page, and is exhibiting a certain behavior?

The guy that said “STOP"!” is concerned that if you do this wrong, you’ll make sweeping generalizations and sweeping changes to the site based on incorrect assumptions.  Step back….too much for this stage.  Instead, based on an agreed upon confidence interval and threshold, you’ll change his experience through targeted marketing spots now shown, a multivariate test initiated (didn’t want to start the test for everyone), a navigation system that is just a little bit friendlier in its ordering, an image rotator that favors a particular image.  Or maybe NOTHING at all changes—you’re just gathering data for the good, old-fashioned analysis that will help you make better decisions in the future.

For Launch Sitecore, we decided on 4 buckets to put our potential visitors into:

1. Marketers (probably really interested in the Customer Engagement Platform)
2. Content Managers (usability and feature set of the CMS)
3. Developers (how do I get this installed and start playing with it?)
4. IT Professionals (what are the infrastructure and environment specs?)

Don’t go crazy with this yet.  I’ve seen troublesome attempts at creating 30 different buckets on Day 1.  Think to yourself—am I going to really be able to, as an author of content, discern between 30 different audiences when I write my content?  And, as a Web Experience Strategist, are you going to do anything different based on 30 possibilities?  Do you have targeted content written to support this?

In our case, 4 is our good starting point and it is clear in our heads when we’re writing a new article.  If I’m putting together an article with infrastructure diagrams, I know which bucket of visitors I’m targeting.  If I’m diving into CEP Analytics--while it could be less black-and-white—I can picture my visitor type that will be interested.
This won’t be an exhaustive discussion of Sitecore’s Profiles, Profile Cards and Pattern Cards, but let’s take a look at the Launch Sitecore content tree in this area:

Going down the tree:

1. The overall Profiles section in the Sitecore content tree (part of the CEP installation by default).
2. Our Launch Sitecore Profile, called Job Function (the main driver behind our 4 buckets)
3. Individual, specific job functions (Analytics, Copywriting…).  These are called Profile Keys in Sitecore .
4. The Profile Cards folder.  These are in the Sitecore content tree by default, under any specific Profiles you create.  The individual Profile Cards described below are then a possible mixture of any Profile Keys you defined in this Profile.
5. Individual Profile Cards (Connie the Content Manager, Devon the Developer…).  Now we risk tripping over terminology a bit.  Don’t these seem like Personas?  Well, in fact they really are.  The Data Template these Cards are built from is called Profile Card – Persona.  The fields that make up these items will ring true to anyone that has gone through a persona definition marketing exercise to date:

 

In addition to the persona definition fields, description, a handy image to help communicate and visualize what this persona is all about, there is a field in these items that allows you to specify the right mix of specific job function attributes Connie is concerned with / interested in:

Connie is most concerned with Copywriting, but don’t necessarily leave her out of Personalization and Testing conversations.

So, with our Profile Cards / Personas defined, we have a concrete, visual representation of the 4 buckets we started with.  Now our Launch Sitecore article writers can consistently “tag” their work with an appropriate audience.

On a fundamental concept article called the Launch Sitecore Site, we are able to choose Connie’s Profile Card (and see the specific job function attribute mix that will apply to our content item).

If you actually go to this page on Launch Sitecore and hover over the “peelback” on the top left corner, you can see that you’re already trending towards Connie.  Click around to different articles and see if you hit a threshold where you’re trending like one of the other Personas.
Sky’s the limit now!  When someone visits Launch Sitecore and they start to exhibit behaviors like Connie (by reading some targeted content authoring articles), we sound mp3 file horns, we put up huge banners screaming “Hey Content Author!” and we remove all navigation to any articles not targeted towards content authors.  OK, no, we don’t do that.
What we can do is limitless, but let’s just cover 2 quick options.

1. Do absolutely nothing.  Maybe we’re just starting out with this Launch Sitecore thing (we are) and we’re not quite sure our Personas are just right for us.  We’re not sure the campaigns we set up and the MV tests we run will reconcile with the content tagging we have in place with these Profile Cards.  Maybe we just want to look at Sitecore Analytics for a while and see how our traffic is being distributed between these 4 buckets.  More importantly, let’s start to see how much Engagement Value visitors that trend towards these personas are providing for us on our site.  Much more on this later.
2. Apply a Rule to a control that changes content if someone starts to exhibit the traits of one of our Personas.  I won’t go into too many details on this as I and many others have written  plenty of articles covering this topic--but to finish our specific Launch Sitecore example, I might want to show a marketing spot on the home page that specifically talks about CMS as opposed to DMS/CEP if a visitor looks like Connie:

 

And here’s the specific default (out of the box) rule condition that will do this:

We have a targeted marketing spot focused on the CMS (as you can see, this has been selected in the Personalize Content field.  Sitecore will continue to watch for a change…if the threshold is hit where this visitor looks more like Devon the Developer, we might choose to personalize the content with something more developer-centric.

Lots more to come as we enjoy watching the Engagement Plan and Analytics on our Launch Sitecore site:  www.launchsitecore.net.

Previous Post:  The Goal Discussion for Launch Sitecore  |  Next Post:  The Engagement Plan for Launch Sitecore