If the Deep Thinkers of marketing agree on anything today, it’s that the Internet is the key to the future, and personalization is the key to the Internet. So Web personalization software should receive more attention than any other type of marketing system, right?

Evidently not. Attend a marketing conference, read an industry magazine, or listen to marketers talk about their problems, and you’ll find most of the attention goes to CRM and campaign management systems. Even Internet specialists spend at least as much time considering Web-based customer service and email campaigns as personalization products. And if you distinguish personalization from collaborative filtering and interaction management, the mind-share occupied by personalization grows smaller still.

Why the disconnect? Is personalization really so much less important than the pundits would have us to believe? Or are most marketers still working on basic Web functions, and just not yet ready to add personalization?

Neither explanation seems very sound. Visit almost any major consumer Web site, and you will be offered some form of personalized interaction. So it seems that personalization is the Web’s clean little secret, something that everybody does but nobody talks about.

It would be fun to blame this mysterious silence on an extraterrestrial conspiracy or World Federalist plot or at least on Microsoft. But the real reason is much less exciting. People rarely talk about personalization systems because these no longer exist as stand-alone products. Instead, personalization has become embedded in basic tools used to build and run major Websites.

Since these tools are bought and operated by the site builders themselves–who once reported to marketing but now reside within IT or perhaps their own domain–marketers don’t concern themselves with these tools as much as they used to. And even the site builders consider personalization as just one of many capabilities to evaluate in a product.

But precisely because personalization can easily be taken for granted when evaluating a Web system, it’s important to examine what it takes to do it properly. There are some fairly specific issues to keep in mind. These relate to the three main components of a personalization system: content, profiles, and rules.

• – Content refers to the specific messages that will be sent to individuals. Of course, every page on a Web system is content, and extremely sophisticated systems have been developed for content creation, maintenance, distribution and access. But personalization adds its own demands to standard content management. One requirement might be called granularity: while static Web sites can be built and managed at the page level, personalized Web pages are typically assembled from many smaller components. This means the content must be stored at the component rather than page level.

It also means the system must include ways to categorize these components–often assigning multiple attributes to the same item. In part, this helps manage the much larger number of items that result from working at the component rather than page level. Perhaps more important, it also lets the system identify the components appropriate in a given situation without having the user explicitly specify them in advance. This opens the door to automated content selection mechanisms such as predictive models, which will ultimately be needed to replace hand-built rules.

Personalization also expands the types of content a system must present. Many personalization schemes rely on selecting information from a database, whether it’s leisure airfares to a favorite city or products most commonly purchased with each other. Other schemes involve geographic considerations, such as maps to the nearest drugstore. Personalization can also involve manipulating a graphical image, such as showing how a dress look in a particular color or pattern on the viewer’s body type. At a more basic but still challenging level, personalization can involve storing content and navigation messages in different languages.

The final impact that personalization has on content relates to system performance. Personalization greatly increases the number of content items that must be quickly accessible. This means that content must be stored in ways that allow high-speed retrieval. Thus, personalization implies a greater concern with in-memory caching, indexing, multi-threading, distributed servers, and other advanced technologies.

• – Profiles refer to information about individuals. The simplest profiles are limited to data that is gathered within the Web system itself. These can include information provided by customers through media such as registration forms and surveys, data inferred from click-stream and other behaviors, and transactions such as purchases and customer service requests. One key issue is how much and which kinds of this data a system can store. For example, marketers add new survey questions all the time–a system must be able to accommodate the new answers in its profile database, and ideally will be able to ask users for missing information without repeating questions they have already answered.

Most marketers want their profiles to include non-Web information. This might come from a data warehouse or legacy transaction processing system. The simpler method is to import selected values directly into the Web system’s profile database. But while this is technically straightforward, it can involve massive amounts of data–much of which will never be used if many customers never visit the Web site. The alternative is to query the external systems in real time as data on individual customers is needed. This of course assumes a common key, such as a standard customer ID, is available in both the Web and non-Web systems. Beyond that, it requires the system design and resources to provide adequate response times. If the warehouse or legacy system was not designed for this type of access, real-time queries may not be practical. A good Web personalization system should be able to handle either situation.

Most Web personalization systems store their profiles in a flat file or small number of relational tables, with standard indexes to provide high-speed access to individual records. Where very large volumes are involved–either in number of customers or data per customer–some form of compression or summarization may be needed to ensure performance and keep hardware costs within reason.

While personalization is the main reason profiles are gathered and made accessible on the Web, they can also be used to target Web ads and to target non-Web direct marketing campaigns. Personalization itself is rarely seen as a privacy issue, but the data in the underlying profiles is often considered quite sensitive. Systems need to protect this data through encryption and access limits. They may eventually need to comply with additional constraints on profile usage, such as restrictions on permissible applications, limits on data transfer, required expiration dates, and customer review and consent. Although today’s systems do not such functions, it would be a good idea to consider what it would take to add them to any system you are about to buy.

• – Rules represent the final component of a personalization solution. They determine which content is presented to which profiles. Rules can vary from a straightforward lookup of the customer’s preferred language, to simple if/then logic, to rankings based on automatically generated statistical models. Most of today’s Web personalization relies on manually-defined rules, sometimes drawn with a slick graphical flow chart but more often written in Java or another programming language. A few systems include data analysis capabilities that let them discover relationships and propose new rules on their own, although even in those cases it is (wisely) left to users to decide which new rules to implement. Most systems can nest rules within rules, allowing considerable complexity.

Like content, rules pose a significant administrative challenge: they have to be reviewed and authorized by the right people; they may need to start and expire on specified dates; they must fail gracefully if something unanticipated happens. In fact, rule and content administration must be closely coordinated, since rules often call on a specific piece of content that had better be available. The challenge in a large organization is that rules and content will often be created by different people. This means test and validation processes are needed to ensure a rule can be executed properly. One approach to mitigating this problem is to have a rule call for a class of content–for example, “find the best cross sell offer”–rather than a specific item. That makes it easier for the system to use whatever content is available, and to provide a default response if nothing better can be found. But this approach does require considerably more sophistication, and more real-time processing, than calling a specified piece of content.

The real challenge with rules is integrating them into the rest of the system. In early products, and still today in systems aimed at smaller installations, rules and content were intermingled: that is, a little snippet of logic would be embedded directly in an HTML page. While better than nothing, this has obvious problems, since any rule change requires changing the Web pages themselves. Today’s enterprise-level systems generally separate rules from content, so marketers can make changes without affecting the integrity of the site. For similar reasons, content itself is often separated into different classes–for example, there might be standard page templates constructed by the Web staff, with placeholders for content (or rules) that can be changed by other people. A similar division of labor may also apply where content interacts with profiles–allowing users to create survey questions, but giving administrators control over where the results are stored.

Not all Web personalization issues relate to content, profiles and rules. Architecture and scalability are critical concerns; so are integration with other systems’ data and processes. These are more related to the underlying Web site system than personalization itself. Personalization reporting also generally relies on the reporting functions of the parent Web site system, or on whatever third-party Web analysis tool a company has chosen. But personalization does add some specialized reporting requirements, such as the need to track the use and results of individual rules. So a few specialized reports are often built into the personalization process.

*                       *                        *  

Copyright 2000 Raab Associates. Contact: info@raabassociates.com

Back to Search