Personalization fundamentals (part 3): Event-based personalization

This is part three of a three part series. If you have not read the first two parts yet, you should go review them:

Overview

Let’s start by defining what ‘event-based personalization’ is… An ‘event’ on a web site includes just about any action the user takes. Examples include clicking a link, submitting a form, adding something to their cart, placing an order, visiting a page, logging in, etc… So, event-based personalization is the practice of personalizing the users experience based on events that happen on the site. This post is intended to provide the reader with a general understanding of what constitutes event-based personalization, some examples of what can be done with it, as well as some guidance on how to manage this.

A note on terminology: ATG’s event-based personalization is shipped as part of the Adaptive Scenario Engine (ASE). ASE is the foundation of all ATG products including ATG Commerce. More specifically, the primary module within ASE that contains all of this functionality is called Dynamo Scenario Server (DSS). Some people refer to ATG’s event-based personalization offering simply by calling it ‘Scenarios’.


Components of event-based personalization

There are a couple very important components of ATG’s event-based personalization offering as described below.

  • Slots – Think of a slot as a bucket of items. The items could be products, categories, images, blocks of HTML, or even just string values. The primary use of a slot is to show those items on a page; in other words, you would ‘render the contents of a slot on a page’. So how do you control what items go into a slot? The answer is to use a scenario (defined below). There are scenario actions that allow you to add items to a slot, remove items from a slot, and to filter items out of a slot by using a ‘collection filter’ (described below). When you add items to a slot, they can be assigned a relative priority compared to other items in the slot. The page developer (the one who controls how the slot is shown on a page template) has a lot of flexibility over how the slot is rendered on the page. For example, they can decide how many items to show at one time – if your slot contains 10 products, maybe they want to show 3 at once. They can also control whether the items should be shown in order based on priority or shown randomly. Finally, they can certainly control presentation of the items (i.e. a product could be rendered using it’s thumbnail image, name, and price).
  • Scenarios – I like to describe a scenario as a ‘workflow for the customer experience’. ATG provides a scenario editor as part of the ATG Control Center (ACC) that resembles something like Visio. It’s a graphical tool that allows you to chain together events, actions, and conditions (the building blocks of scenarios). There is also the ability to create forks for branching logic (similar to if / else logic). Let’s take a deeper look at events, actions, and conditions:
  • Events – As mentioned previously, an event is basically anything that happens on the site. Most scenarios start with some kind of event. This makes sense because most use cases sounds like this ‘when the customer does X (the event), and if they have Y properties (the condition), then I want to do Z (the action)’.
  • Actions – Actions represent something you want to do (usually in response to an event). Sometimes the user will recognize the action took place, and other times, they will have no idea that anything special just happened. If you use an action like sending them an email, showing them some content (by adding items to a slot), grant them a promotion, or redirect them to a new page, they will certainly know that this action took place. On the other hand, if you just updated their profile with the fact that they did something, or you logged the fact that they performed some action (for subsequent reporting), or if you set a scenario variable for later use, the user won’t know anything happened at all.
  • Conditions – Conditions are used to decide what direction the execution of the scenario should go. For example, if today is Tuesday, perform action A, but if it’s any other day of the week perform action B. Conditions can also be used to narrow down the users that will be affected by the scenario. For example, when someone adds a certain product to his or her cart (the event), and the user lives in Ohio (the condition), then add a special banner image to a slot (the action).
  • Collection Filters – A collection filter can be used to filter out items within a collection. Since a slot is a type of collection, you can filter a slot using a collection filter. Examples of collection filters that ship with ATG include:
  • Inventory filter – given a collection of products, it will filter out any products that are out of stock
  • StartEndDate filter – given any content item, it will filter out any item that is invalid based on comparing the current date-time to the items start and end date.
  • ExcludeItemsInCart filter – given a list of products, it will filter out any items that are already in the users cart

Note: It’s also possible to add your own custom collections filters (a developer task). An example could be that you want to filter out items that a customer is not ‘allowed’ to purchase for some reason


A whole bunch of bullet-points about ATG event-based personalization

  • ATG ships many out of the box events, actions, and conditions, however, if you find that you need something that isn’t there, your developers can create custom ones.
  • When you follow best practices, event-based personalization performs very well… However, similar to any other site functionality, if you do not follow best practices, it could cause performance issues. Make sure you read through the ATG manuals on how to design efficient scenarios!
  • Any ATG commerce customer (running on version 5.0 or later) already owns all the software and has everything installed. In fact, your site may already be running some basic scenarios (check with your IT group).
  • Scenarios can perform many more functions than just what can be considered ‘personalization’. Some examples include basic logging of events, assigning a default catalog and pricelist, helping with integrations, etc.
  • Many, if not all, ATG applications make use of scenarios. For example, when you create a campaign using ATG Outreach, a scenario is created behind the scenes. The same goes for ATG’s Campaign Optimizer (AB split testing tool).
  • The same slot can appear on one or more pages.
  • You can show zero or more slots on a page. Although there is no strict limit on the number of slots you can render on a page, there is a point where you could have ‘too many’ slots being shown on a page. I don’t know of a customer that has more than 10 slots being shown on a page. It’s common to have somewhere between one and five slots on a page…
  • If you want to present the contents of a slot in random fashion, you could either configure the slot to randomize the contents, or the page developer could randomize the results using ATG’s tag library. You should avoid doing both (double-randomizing) simply because it doesn’t make sense.
  • You can design your slot to always show some default item (so something will always appear on the page), or you could elect to allow the slot to return nothing, and design the page to handle that appropriately (i.e. you don’t want to end up with a gaping whitespace on the page).
  • A key difference between rules-based and event-based personalization is that event-based personalization understands the notion of time (both absolute and relative). Rules-based allows you to define rules that get executed, return results, and it’s job is done. A scenario could start upon some event occurring, then pause for some amount of time (seconds, hours, days, etc) until the next event happens.
  • Scenarios can execute start to finish in one page request, or it could last across multiple sessions. Note: some configuration may be required to handle scenarios properly functioning across sessions; the key is to be able to identify the user when they return to the site.
  • Many ATG developers think of scenarios as a great way to avoid java coding (faster time to market).
  • Scenarios are easy to understand just by looking at them (good for us visual-thinkers)
  • Scenarios have a construct called a ‘randomizing fork’, which can be used to send a percentage of users down one path, and everyone else down another path.

Leveraging rules-based personalization

As we learned in the previous post in this series, there are a number of very useful components that are part of rules-based personalization including segments, content groups, and content targeters. All of these components can be leveraged by the components of event-based personalization. In other words, event-based personalization builds on top of rules-based personalization. For example, you can create a scenario (event-based personalization), which only impacts users from a particular segment (rules-based personalization).

Screenshot: 1 - Shows a segment (HighValuedCustomers) being used in a scenario

Another example is that you could create a scenario that populates a slot where the actual items put in the slot are based on executing a content targeter.

Screenshot: 2 - Shows a content targeter (PromotionUpsellProductTargeter) being used in a scenario


What are the some potential uses of event-based personalization?

Tracking - there are many reasons why you may want to track what users are doing on the site. The typical way to do this is to use a scenario to look for the event you’re interested in, and then use the ‘Change Persons’ scenario action to store that information in their profile. It makes a lot of sense to put tracking information in the users profile because now that information can be used in your personalization rules (i.e. may determine what segment a customer falls in to). Here’s a simple scenario that records the type of product they are looking at:

Screenshot: 3 - Record information in the customers profile

Show content - In the last post, we found that you can use content targeters to show personalized content to your users. A slot is another (more advanced) way to show content to a user. Slots provide additional controls over what to show, and it builds upon rules-based personalization in the sense that you could combine results from one or more content targeters into a single slot. You can then filter that slot in a number of ways. The scenario below shows how this can be done:

Screenshot: 4 - Adding items to a slot and then filtering the results

Granting promotions - There are a couple different aspects to managing promotions within ATG. The first step is to define the actual promotion itself (out of scope for this post). The next step is to handle how to provide users with that promotion. If the promotion should be global (given to everyone), then you just configure the promotion to be a global promotion and you’re done. However, if you have the need to only give the promotion to a subset of your users, you will want to use a scenario to grant the promotion. Here’s an example of how to do that (notice the date range that starts this scenario):

Screenshot: 5 - Granting a promotion to customers in a certain segment



Implementation – things to think about


General

The most important things to think about are how you plan to manage the scenarios (see the sections below for more on this topic), and what you plan to do with event-based personalization. We’ve seen some examples (in the section above) of what can be done, but you need to think about what makes sense for your business. For example, while it’s possible to offer different promotions to different user segments under a variety of conditions, it might not be something your business intends to do. Perhaps, your business policy is to offer all customers the exact same promotions. Spend some time thinking about how event-based personalization could be used for your site!


Managing slots

A slot is generally not something that a business user would manage. It’s something that a developer would setup based on requirements from the business. The developer would use the ACC to create the slot. Once it’s configured, the developer can just let the business users know that it is now available for use in scenarios. Once it’s configured it will also appear in all the ATG applications that can use slots (such as Outreach or Campaign Optimizer).

Screenshot: 6 - Configuring a slot component

The other person who needs to know about the slot is the page developer. A slot doesn’t have very much use unless it is being rendered on a page somewhere on the site (or within an email template). It’s a pretty straightforward task for a page developer to add a slot to a page. The page developer would use the ATG JSP tag library to add the slot to the page template (this is well documented in the ATG manuals and includes examples).


Managing scenarios

Scenarios are managed using the ACC. The ACC is generally considered a developer tool, but some ATG customers have decided to give this tool to their ‘more technical’ business users. Whether that makes sense for your organization or not really will depend on the skill set of your business users. Regardless of who is managing scenarios, they are assets, which have the potential to affect site performance, so we strongly recommend that they be tested in a staging environment prior to being pushed to production. In this sense, they can be treated similar to how code changes are treated. Here are a couple different approaches we’ve seen customers use:

Approach 1
Some ATG customers have scenarios managed exclusively by their development group. A new or modified scenario would be checked into their source code control system and would be tested in the staging environment, and then moved to production as part of a scheduled site build. This IT-centric approach boils down to scenarios being used to augment or replace the need for writing java code to meet particular business requirements.

Approach 2
This approach leverages the ATG Content Administration (CA) product. CA is used to manage ATG assets including content as well as personalization assets including scenarios. A business analyst could create a project in CA and then connect to the CA server using the ACC. When they navigate to the scenario editor, they will be prompted for a project to save their changes in (they can select the project they just created). Now they can create a new scenario(s) or modify existing ones, and those changes will be contained within the CA project. Next, they can select to advance their project through the defined workflow (i.e. author – review – deploy). When the project is deployed to a testing environment, the scenario can be tested to ensure it is functioning properly. Once the scenario has been tested and approved (it would be a good idea to have a developer approve it here), it can be deployed to production using the CA deployment functionality.

Approach 3
The third approach is similar to the second approach, but does not use CA. A business analyst could create / modify scenario(s) within a development / sandbox environment. When they feel it’s ready, they could ask a developer to move the scenario to staging so it can be tested. Upon successful testing, the developer could go about deploying the scenario to production.




Testing

Testing event-based personalization is very important! You will need to ensure that the slots, scenarios, filters, etc are all functionally meeting the defined requirements. You will also want to ensure that the scenarios are designed efficiently so there is no performance issues once they go live. There are many tips in the ATG manuals that describe how to test and debug scenarios, so it’s important that your developers read that section carefully.


Summary

Event-based personalization, when used appropriately, can become an essential aspect of your site. You can use it to drive incremental revenue, provide a better (more intelligent) experience for your customers, and you can also use it to simplify your implementation (code replacement). This is one of the most obvious tools at your disposal to help you differentiate your site from your competitors.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

Welcome to the Oracle Commerce Product Strategy Community. We are dedicated to driving Best Business Practices across Oracle ATG products, Oracle ATG and Endeca Solutions and overall eCommerce Strategy. We welcome all collaborative discussions on blog posts. If you have a question for one of our experts, feel free to ask it here:
ATG Business Forum

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today