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!
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).
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:
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.
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.
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.