Tuesday Sep 27, 2011

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:


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


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 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.


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.

Monday Sep 26, 2011

Personalization fundamentals (part 2): Rules-based personalization

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


This part of the series focuses on what we call rules-based personalization.  Rules-based personalization is primarily used to establish rules that determine what customers will see on the site (personalizing the site).  These rules can be used in more ways than just content display.  Some examples include; determining who receives a marketing email, who receives a particular discount promotion, or which cross sell items should be shown for a particular product.

The goal of this post is to introduce you to the components of rules-based personalization, highlight some potential ways to use it, and describe some important things to think about during your implementation.

Components of rules-based personalization

  • Segments (Profile groups) – A segment is a rule that defines a subset of your customers.  You can define a segment based on any attribute you have on the ATG profile (see part 1 of this post for more details on the profile).  When you create a segment, it will show up dynamically as a property on the users profile as a boolean value (true means the customer belongs to the segment, false means they are not included in the segment).  *** Note: Profile Groups and segments are very similar, but Profile Groups are only managed in the ACC.  Profile Groups pre-date segments and will eventually be fully replaced by segments.
  • Content groups – Content groups are similar to Segments, but instead of operating on the customer, it’s operating on some type of content (such as your product catalog).  In other words, a content group is a rule that defines a subset of your content.  A simple example would be the following; you could create a content group that includes only products in your catalog that are on sale, are contained in the ‘shirts’ category, and are available in the color red.
  • Content Targeters – Content targeters are ‘show / hide’ rules that are used to display content to customers.  The rule consists of a few pieces: Show or hide, which content, to whom, at what time(s), and under what conditions.  There is a great deal of flexibility not only in how you define these rules, but also in how they can be used.  You can create multiple rule sets within a single content targeter in order to create if / else conditions.  Content targeters can leverage both segments (to whom) as well as content groups (what content).

What are the potential uses / benefits of rules-based personalization?

Content display – use rules to define what content is shown to which users.  Content Targeters were specifically designed for this purpose.  Content targeting rules can be simple or rather complex as the following examples show:

An example of a simple content targeter

A more complex content targeter

Re-use of rules - Provide a single place to define well-known rules so they can be leveraged (as opposed to redefined) across the entire application.  Reusing rules is much better than recreating the rules in a number of places for some obvious reasons:

  • There are less rules to manage
  • The results are more consistent
  • It’s easier to debug issues

Some examples of reusable rules (primarily segments and content groups):

  • If you define a segment called ‘recent visitors’ as customers who have visited the site within the last 7 days, your entire application can refer to the users ‘recent visitor’ property as simply true or false instead of redefining the rule over and over again.  You might want to use this rule in a number of places such as a promotional spot on your homepage and also as part of a qualification rule in a discount promotion.
  • If you define a content group called ‘products we want to move quickly’ as all products who’s ‘clearance’ flag is true, and who’s ‘scheduled to reorder’ is false, then you can refer to those products throughout the application (promotions, targeting rules, scenarios, etc) without redefining the rule in multiple places.
  • If you never want to feature clearance items to a certain segment of your customers, you could create a content targeter that is defined to hide clearance items from people in that group.  This one rule could be used in many areas of your site.
  • You could define a few segments based on how the customer came to your site.  Examples could include: Entry_Google, Entry_Email, or Entry_Direct.  Inclusion in these segments may drive what the customer would see on the homepage as well as what promotions are granted to them.

How to manage the rules

The intention of the Business Control Center (BCC) is to allow business users to manage as much of the site as possible.  Rules-based personalization items such as segments, content groups, and content targeters are all managed within the BCC.  A core aspect of managing these rules includes something called an ‘expression editor’ which allows for the rules to be simple to create and understand.  All rules are managed within a project in Content Administration (CA), so they will take advantage of the workflow and deployment features available with CA.  The screenshots below will give you an idea of what the BCC looks like when managing different rules.

Creating a segment

Creating a content group

Creating a content targeter

Implementation – things to think about

If you followed the advice from the first post, you should have a pretty easy time creating your segments, content groups, and content targeters.  This is because the first post focused on setting up your ATG profile, which is an important building block for establishing rules-based personalization.  For the most part, these rules will be what control much of the dynamic display on your site.  There are additional ways to deliver personalized content, but that is the topic of the third and final post in this series.

You should be managing all these rules by using the BCC (personalization menu).  Managing these rules via the BCC requires that you own licenses for Content Administration.  If you are running CA (and the BCC) already, but you do not see the Personalization menu, it is likely that some configuration steps were not followed during setup of the BCC. If you do not own licenses for CA, then you can also create and manage these rules using the ATG Control Center (ACC).

Note on managing rules in the BCC:  the rules will not be available to items outside of the current project until that project is checked in.

Make sure you test all the rules to ensure that they are behaving as expected.  The most reliable way to test rules is to deploy them to a staging environment, and then run through a series of use cases using a handful of test accounts.  Each test account should have different profile property values in order for them to fall into different segments.  Also, prior to testing, it is critical that you understand how the site is using these rules.  In other words, you can create any rules you like, but in order for those rules to have any meaning on the site, they will need to be explicitly used by a JSP page or some other component.  You will need to coordinate with the site developers in order to understand how the rules you have created are being used.

Note on testing: Future versions of ATG will provide enhanced means of testing rules by using a preview capability which will provide a faster way to test.


Rules-based personalization is really the most basic form of personalization.  It addresses the requirements related to:

  • Ability to define the different segments of your customer base
  • Ability to define the different groups of content available on your site
  • Ability to control what content to show to which customers, at what time

There may be other requirements which could call for more advanced (or at least a different form of) personalization.  An example of another (and very powerful) form of personalization is called event-based personalization.  Event-based personalization will enable you to react to changes in customer behavior over time.  Event-based personalization is the topic for the third and final part of this three-part post.

Sunday Jul 31, 2011

Personalization fundamentals (part 1): The ATG profile

Introduction to the series
This is the first post in a three part series that will provide some detail around the fundamentals of ATG personalization. The goal for these posts is to provide guidance on how to establish the foundation of your personalized site. The approach I’ll take is to describe the various functions as well as provide examples to provide context. The first post (the one you’re looking at now) will focus on the ATG profile. The next two posts will describe rules-based personalization and event-based personalization respectively.

What is the ATG profile?
The ATG profile is arguably the most important aspect of personalization because it represents everything you care to know about your customer. While it’s likely that there are multiple data sources around your organization which hold various ‘customer data', if it’s not mapped into the ATG profile, then you’ll have a hard time personalizing your site based on that data. At the same time, it certainly does not make sense to load up your ATG profile definition with absolutely everything you know about your customer… It only makes sense to store data that could be actionable in some way. In other words, while it may be possible to know that a customer exchanged a medium shirt for a large shirt back in 2003, is there really anything you would do with that information?

If you view a particular customers profile with one of the ATG UI’s, you can get a visual understanding of what the profile is, what attributes are available, and how it relates to other objects. Here’s a screenshot of a customers profile as viewed in the ATG Business Control Center (BCC):


Every ATG implementation will start with the default ATG profile and extend it to some degree. Extending the profile is a developer task, but defining what extensions need to be made is based on the application requirements (driven by the business). For the initial launch of your site, it’s unlikely that you can create a profile definition that will be sufficient for all time. Without a doubt, there will be things that you cannot predict that will end up requiring some modification to the profile you defined. We recommend that you consider what possible personalization use cases you might want to implement in the next year or so, and model your profile based on that. At the very least, you stand a good chance of having a sufficient profile to implement the use cases, and you can adjust the profile definition as part of future phases.

Defining your profile

ATG defines some common profile attributes for you. Depending on your specific needs, it’s likely that you will want to extend that definition by adding attributes where the data comes from either the online channel or from external sources.

ATG defined profile attributes
Note: Depending on which ATG products are running in your application, there will be more or less pre-defined profile attributes (each ATG product may define additional attributes). Here’s a sample of some of the pre-defined attributes:
  • email address, email status, email opt-in flag
  • first, middle, and last name
  • date of birth
  • gender
  • last activity date, registration date
  • multiple contact elements (address, phone numbers, etc)
  • login, password, auto login flag
  • member flag, security status
  • preferred locale
Online channel profile attributes
  • Interest level in a certain category (could also include search facets) - This gives you a rough idea of what the customer is looking for as this represents navigational behavior.
  • Search keywords - This is a clear indication of what the customer is looking for (they explicitly told you).
  • Products that have certain tags or attributes - What are the traits of the products the customer is looking at? Are they looking at relatively expensive items, clearance items, core vs. accessory products, etc.
  • Referring URL or some affiliate code on the initial request - This speaks to how they entered the site and can have a big influence on how you personalize the experience for the customer. 
  • Geo-location information - Knowing whether the customer is currently located in a particular geography may be useful when targeting content or offers. While this information may not be 100% reliable, it may play a role in your strategy. There are third party solutions available to help with providing this information. 
  • Past order history - This tells you what they have committed to purchasing in the past. It’s debatable whether this should be sourced from online purchases only, or whether it should include (if available) order data from offline channels. 
External source profile attributes
  • Membership or loyalty data - Having this data in the ATG Profile allows you present personalized content or offers to customers based on membership level. 
  • Offline-defined segmentation - If you have an offline segmentation application, it may be worthwhile to load some portion of that segment information into the ATG profile. 
  • Web analytics systems - Web analytics vendors can offer potentially useful data that can be fed back into the ATG Profile with the purpose of using that data for personalization. 
  • Service Information - Customer support applications could hold some interesting information about your customers’ service history that you might want to leverage in the online channel. 

Different modes of retrieving data from external sources

When sourcing data from an external system, a decision must be made about how that integration should be built. There are numerous ways to handle these types of integrations, but I’ll describe two common forms:
  • Push approach - Scheduled batch feeds that are loaded into the ATG profile repository – This is a very common approach because it’s straightforward from an implementation perspective, and it has the advantage of not relying on the external system to always be available. The downside is that the data could be up to one day old, so this approach might not be applicable in all circumstances. 
  • Pull approach - Instrument ATG to reach out for this data at certain times – The advantage with this approach is that the data you retrieve will be up to date. The downside is that there is a tight coupling between your site and the backend system; what if the system is unavailable at the time of the request? 

A note concerning usability

Something that unfortunately if often overlooked during an implementation is how easily the attributes that are added to the profile definition can be used in constructing personalization rules. Many times, the attributes you add can be defined in a couple different ways. Some of these approaches can lead to personalization rules that are simple to understand, while other approaches could make the rules very difficult to create. To provide some clarity, I’ll use a simple example… Your site may have a requirement to personalize based on the customers’ age. The ATG profile has a pre-defined attribute that represents the customers’ birthday (a java Date data type). You’ll find that it may be difficult to create ‘age-based’ rules when you’re only given a birthday. It would be much easier to create a rule if you had a field called ‘age’ (small piece of code that performs a date calculation based on the current date and the customers’ birthday). With the age attribute, you will know the customer is 37 instead of only knowing they were born in September 1970. It’s details like this can save business user hours of frustration! 


If you take the time to define a profile that encapsulates the information that describes your customer, you will be on your way to being able to provide those customers with the personalized experience they deserve. Stay tuned for the follow-up posts on this topic! 


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


« July 2016