Part II of IV: Birth of the Personalization Program

The Missing Central Tool for Operationalizing Experience Personalization

February 27, 2015 | John Berndt

bento boxThis blog post is excerpted from a longer chapter in my new full-length book "Personalization Mechanics: Targeted Content for Web Teams of All Sizes," which is now available.

As far as I can tell, when it comes out, it will be the only book on Web personalization written from the perspective of people who actually work on websites (the strategists and teams that build and maintain them), so it’s a much needed resource. I’m excited to be excerpting four sections leading up to the book’s release, to get the conversation started and give a sneak peek into the book’s content. This piece below adapts from the chapter “Personalization—A New Dimension For Web Development.” The chapter concerns how personalization efforts can be conceived and organized within a standard Web team, and provides some basic frameworks to understand the standard work streams that are involved.

Introducing Personalization Programs

Before you dive into Web personalization, I’d like you to consider one thing: your commitment to it from an operational perspective. Here’s why:

If you don’t take personalization seriously, it will wither and die on the vine in your Web team at best or, at worst, create a mess that will dissatisfy your users and management.

You can give yourself a head start by institutionalizing an approach to planning it, discussing it, tracking its effectiveness, and preventing unintended collisions between different personalized elements. In other words, personalization has to become “a thing” within your Web team.

The term personalization program1 is a new term of art that I’m proposing for the industry that fills a significant conceptual gap. When used in the context of a website, a “personalization program” implies certain beneficial characteristics:

  • It can be multi-part and group multiple elements.
  • It is potentially temporary or reusable.
  • It relates to a specific goal(s).
  • It implies a clear process to achieve results.
  • It integrates with tracking tools.
  • It is relatively vendor neutral.

Personalization programs can be simple (that element on the homepage looks that different if you’ve visited the site before) or quite complex (a variety of coordinated, multi-stage navigation and call-to-action components render differently based on which audience group most closely matches your behavior, and positioning statements render differently based on who you are, all of which also updates your CRM record). The unit of the personalization program allows you to imagine, discuss, and track these efforts as a meaningful effort.

This is the organizing principle that you need to succeed with personalization, but it is also currently missing from (or remedial in) more than 90%+ of the CMS and HTC Optimization platforms, almost none of which provide ways of grouping program pieces together and in one place to enable programmatic oversight. The platforms today are extremely tactical and feature-based; they are generally designed as if they are only going to be used occasionally, and not as if they are going to be a core element at the heart of fast-paced Web operations.

The majority of platforms instead enable personalization rules on portlets at a tactical (page components, chunks of page layout) or on specific pages—or allow you to map audience-based campaigns to particular triggers—but in the end do little to help you group and manage those administratively.2

Therefore, the standard unit of focus is usually the element that changes on a page when a rule is triggered. For example, a portlet changes when a visitor from Texas comes to the page or when someone who previously bought over $80 of leaf bags visits the site. Platforms that offer such limited management functionality are fine if you are executing a handful of simple, evergreen personalization rules, but they are grossly insufficient when trying to build and incorporate personalization as a meaningful, frequently used tool in your Web practice.

Now this is the important part. Here’s why you should care about implementing a personalization program (hint: it goes hand-in-hand with overall content personalization).

  1. First, you need a way to talk about, evaluate, and strategize the use of content personalization that transcends the individual, technical piece of the page.

  2. Second, you need to define and organize your content personalization so that it’s easier to remember and track what your site is supposed to change and when. You all need a shorthand name to be able to easily refer to it (not just arbitrary names like portlet X on page Y under conditions Q, R, and Z).

  3. Third, for personalization to drive a larger portion of the Web experience and be taken seriously, you need to better characterize and group activities coherently. Doing this right encourages people to engage in secondary activities like collision detection and program tuning.

If the discussion remains at the level of “I made this portlet do this or that on a page,” then the operational integration of personalization will never really get started, nor can it be successful.

sushi

Organizing Activity in Personalization Programs

The multi-part personalization program provides an organizational framework for Web teams to tackle small-to-large personalization opportunities. A personalization program serves as both an administrative aid and a way of focusing ongoing critical review.

I’ll leave you with this list of core elements when laying the groundwork for your personalization program:

Documented Overview

This should include elements such as the program name, a series of goals for the program, the metrics used to track the success of the program, and the revision history of the program.

Details of Program Components

These should include the name and location (URLs, though in some cases, it may not make sense to list them all if generalizations can be made) of all personalized elements, associated definitions of their rules, and, to make it more complex, the currently mapped content or experiences delivered when those rules are executed.

It also helps dramatically if everything on a specific webpage is accompanied by a live link to that page. This makes it easier to move back and forth between tracking and the page. The fact that all of these details today need to be tracked outside of most systems to be useful is a major hurdle to the efficiency of Web personalization today. Some systems get parts of it right (integrating management) but in general, it is a gap in the platform market, which hasn’t thought through the complexities of managing multiple, complex programs in context.

Program Status History

Personalization programs tend to be turned on, off, and then on again in a cycle that occurs multiple times. Particularly as it relates to timing issues around tracking and analytics, a program’s status history is important to take note.

QA History

Each time a personalization program is updated, some (a lot, in many cases) QA is needed to assess how the content is working, to provide collision detection, and to otherwise avoid problems. Tracking the QA work makes it much more likely that it will actually happen.

Iteration History

As programs change, it is important to track how they are modified and tuned. In some cases, a brief may suffice; in others, an audit trail of actual changes may be needed. This also has a great impact on understanding tracking and analytics over time.

There is a cool diagram of all this, and a lot more about Personalization Programs in my book, Personalization Mechanics: Targeted Content for Web Teams of All Sizes, which if this interests you, you should check out!

To sum things up, content and experience personalization needs lucid administrative and planning structures to be effective. Although they all have their place, the focus of our attention should not start at the personalized page component, the audience, or even the specific creative campaign (with multiple applications). That’s what the platforms provide, but if you have an active practice, it will quickly get unmanageable with a long list of related elements spread across interfaces you can never review at the same time—and as a result, conflicts and confusion will abound.

Rather, Web teams need something like a well-organized box we can put all of the pieces in (the Personalization Program)—so that we can point to that box out of a stack of many and say “hey, I’d like that one over there,” and then be able pull the box out and digest all of the pieces at a single sitting. It takes some extra effort outside of the platform interfaces, but I think you’ll be glad you did.

Enough food metaphors! Lunch, anyone?

Excerpted and adapted from Personalization Mechanics: Targeted Content for Web Teams of All Sizes © 2015 John Berndt.


1“Personalization Program” as a term also has the benefit of being relatively vendor independent and also being usefully expansive in definition.

2Or in some systems, it works another way, but is equally limiting for management considerations. Here the audience segment is the primary unit, and each segment can trigger multiple personalized components. Either way, you never really get to see the entire process documented in one place for quick reference.

About the Author

John Berndt

I'm CEO of TBG and I've been thinking about the Web in creative ways since the year it began.

Leave A Reply

comments powered by Disqus