Most Sitecore users have a notion of how to represent their visitors with Sitecore pattern cards, the primary capability for visitor definition. But when they go through the process, they often find the flexibility of Sitecore personalization creates a lot of difficulty in Sitecore persona definition. How should I use Sitecore patterns to model my visitors? Can I use more than one classification system at a time? Can someone be in more than one persona? The challenge calls out for a methodology to structure Sitecore patterns that is well understood and repeatable.
If you are not familiar with the terminology Sitecore uses for its personalization mechanism, we recommend our Sitecore personalization basics post. And if you need a methodology for developing these Sitecore personas and profiles, we recommend our getting started with digital marketing post. Our methodology for defining Sitecore personas starts with understanding how you want to use them.
We have identified 8 different ways personas can be defined (so far).
Mutually exclusive and collectively exhaustive (MECE)
This is the most obvious approach, where Sitecore personas are used to classify visitors into groups that do not overlap and account for everyone. Most marketers can figure out how to use this pretty quickly, but soon realize the limitation – namely that visitors can have different roles at different times. Regardless, this approach is valuable in certain circumstances where roles or personas do not overlap, such as male/female, kids/no kids, working/retired/unemployed, geography, military branch, business relationship, or leisure traveler/business traveler/travel arranger.
Collectively exhaustive but not mutually exclusive
This is the most common approach for visitor personas, since it allows for more natural descriptions of visitor groups. When using this approach, we can relax mutual exclusivity and focus on natural breaks in visitor roles, such as prospect/customer/job seeker/investor/employee. It’s very important, however, to understand what this will mean in practice. Since pattern cards are mutually exclusive, visitors will eventually end up in one or another. If you want to track each persona separately (that is, you do not want to limit which personas a visitor can be represented by), you will need to set up each profile separately. That is, you would have a profile for prospect/not prospect, customer/not customer, and so forth (See #8 Mutliple Boolean). This will create a lot of complexity when you go to create personalization based on these profiles, since you may need to create a hierarchy of content rules that traverse the set of possible profiles. (For example, first check to see if the visitor is a prospect, then a customer, then an investor, then a job seeker, etc.)
Scalar attribute value within Sitecore
Here we move away from classification and try to understand the value of a visitor on a particular topic. This could be potential, interest, likelihood to buy or influence. Because of how Sitecore engagement values work, these scales should be set up on a range of 0 to 100. It’s very important to know that engagement values are additive, and not a true calculated value. (That is, if I hit two pages valued at 2 points each, I’ll accrue 4 points.) If you need calculated values you will need to use an external system to calculate on a per experience profile basis and update the Experience Profile with the value (very likely not real time unless you’ve invested in a separate solution that has some sort of streaming data analysis). We’ll cover this next. However Engagement Values can be used as a good approximation for these scalar values if used properly. (Developing the actual Engagement Values is beyond the scope of this post but a detailed discussion will be the topic of a future post.)
Scalar attribute value outside Sitecore
Similar to #3 but derived algorithmically, an external model is used to determine some attribute value. The most common one in marketing is customer lifetime value, typically a mix of forecasted spending and churn probability. The important limitation is the frequency of update – most solutions are not designed to calculate this on the fly and update relevant systems continuously. And it must be designed in from the beginning, since data flows between systems and the applications to do the calculations must be in place. If you can get to this, however, Sitecore becomes immensely powerful. Since power laws hold true in virtually every business (aka the 80/20 rule), having some idea that a high value customer is on your site right now and can get a personalized experience can be transformative to your marketing. In practice we find most Sitecore customers are still a ways away from this scenario, which is why #3 above is a more practical option.
Linear and fuzzy mutual exclusivity
This is where the customer journey falls. Visitors on a somewhat linear path to purchase or conversion can be classified roughly into the usual groups – research, interest, trial, purchase, loyal or research, suspect, prospect, customer. But where on this path a visitor lies is extremely difficult to define, so we don’t get too caught up in getting it perfect. Instead, we accept that the personas are overlapping but still show some progress towards a revenue or conversion goal. That is, we think of the specific group as having a high margin of error and the visitor could really be in the group on either side. So the content we show will work for any of the 3 groups, not the exact one they are in. One trick here will be to use multiple profiles. The purchase/conversion journey should coexist with typing classifications (#1 or #2 above) to allow for multiple personalization options. (That is, two personalized components could use different profiles, one focused on role and the other on journey.) The looseness of these fuzzy groups puts less pressure on the marketer to be exactly right, and focus more on “directionally correct”.
Specific actions taken by a visitor can radically change your understanding of their needs, potential and objective. In some cases, defining profiles around specific events can be very effective, especially if it is difficult to discern differences between personas. For example, an industrial products manufacturer with large amounts of product information may have a difficult time differentiating between a potential purchasing manager and an onsite construction worker trying to choose between two products in his toolbox. Looking for highly predictive events, or creating such events through marketing activities, can inform profile definition. To use the same example, research may show that construction workers only hit the site using mobile phones, so anyone researching from a desktop is by default not a construction worker. Or construction workers never hit the contact page, so anyone who hits that page is also by default not a construction worker. These events completely change your ability to make good decisions about personalization or engagement, so understanding them and how to build them into profiles can be very valuable.
This sits somewhere between classification and customer journey, in that there can be several simultaneous matches by visitor. Life stages are more about stable descriptions of a customer, versus a specific task or objective where a customer journey is more relevant. A life stage could be “new home owner” versus a customer journey to “select, purchase and install a new washer and dryer”. The key here, as with all of these profile options, is to use life stage only if it will change how you present information or make decisions around individual visitors. If you have a plan for changing content based on life stage, it might work better than anything else. Life stage can become extremely targeted by combining Sitecore with a CRM. Once a visitor identifies him/herself, match it with the contact record in CRM. Using this, a change in life stage can trigger a change in pattern cards or engagement plans. It’s an extremely powerful technique we see having tremendous impact.
If you paid attention in #1, many examples were Boolean (either or). Using multiple profiles of overlapping interests can be very productive since it sidesteps the mutual exclusivity of pattern cards. The easiest example is “interested in”. Different personas reflect categories or other interests, of which a visitor can be interested in multiple. A visitor can be “interested in” phones, TVs, laptops, and speakers at the same time. So instead of trying to make a single set of pattern cards cover this scenario, you would use 4 profiles with two pattern cards to accomplish the same thing.
When describing Sitecore personas, it’s easy to get locked in to the classic MECE structure. But with a little creativity, and an understanding of some of the alternate approaches above, you can drive even more results out of Sitecore’s powerful personalization features. A consultant or agency can help; if you feel stuck and need some help getting started with personalization, give us a shout and we can get you on the right path.