Friday Jun 20, 2014

Building Infinite Scrolling in Oracle Commerce

I have to start by saying that the approach I've taken to implement infinite scrolling may not be considered best practice.  I simply found an approach that worked for my purposes and I thought I would share…

The application I'm working with is an internal Oracle application built on Oracle Commerce (version 10.1.2 / 3.1.2 at the time this was written).  It's not a commerce application, but it does use the ATG 'platform' (modules DSS and below), as well as Endeca.  I have a repository that I index in Endeca, and I leverage Endeca Experience Manager to render some of the key pages of the application.  So, as it relates to infinite scrolling, I was starting with an experience manager driven page which contained a ResultsList cartridge, not unlike what you may see in the Commerce Reference Store (CRS).

There is a generic approach to designing infinite scrolling.  At a high level, you remove any kind of paging logic, you use javascript to notice when the user scrolls to the bottom of the initial results, and when that happens, you make some kind of call to get more data, and you append that data to your results.  The affect is that it seems like as you scroll, the results just keep going.

As I got into it, I found that there's a bit more to consider…  How to make the scrolling seem smooth instead of feeling jerky.  How to work through all the javascript event logic so that there are no unnecessary calls being made.  How to keep track of what was handled by the paging logic (the last record received, how many to get next, etc).  I was happy to find that most of these were actually fairly easy to figure out.

The original ResultsList cartridge (mostly borrowed from CRS) had two JSP's; ResultsList.jsp, and paging.jsp.  Just about all the work was done in ResultsList.jsp and paging.jsp was called to provide the page links at the top of the results (so you could click page 1, 2, 3, 4, etc).

For infinite scrolling, I had to rearrange things.  First, I pulled out the results formatting logic from the ResultsList.jsp and put that in a new JSP called ResultsFormat.jsp.  ResultsFormat.jsp simply takes an array of records and formats them - into a table in my case.  What was left in ResultsList was the call to ResultsFormat as well as the new javascript logic that deals with handling scrolling.

The next JSP I created is called recordRequest.jsp and it was called (by ResultsList.jsp) whenever the user scrolled down and it was time to get more data.  Instead of cramming a bunch of Endeca java code into that JSP, I created a droplet (EndecaInfiniteScrollDroplet) which contained all the Endeca Presentation API work.  The droplet would query Endeca and return the results in an array.  The recordRequest JSP really did nothing but invoke that droplet and pass the results array to the RecordFormat.jsp.  

This is a good time to point out that using the ATG - Endeca integration and Experience Manager, when the page loads for the first time, you get a data element called contentItem.  The contentItem contains a number of things, one of which is the initial result set.  So, in my application, I configured the ResultsList cartridge to return 100 records at a time, so that initial page would have the first 100 records (available to me in the contentItem).  

I didn't want to change how that worked, I wanted to leave that part alone and only figure out how to get the subsequent records I need when the user scrolled down…  So, this left me in the situation where I'm getting Endeca records from two different places; the initial set from the contentItem, and the rest from calls using my droplet (called each time the user scrolled to the bottom of the page).  This is why I decided to create a single place to format the records - for reusability and consistency.  All I really had to do was to make sure that my droplet returned an array of records that was the same as what was available in contentItem.

So, there are a few more moving parts, but it's really not too bad.  To summarize, here's a list of the pieces:
  • ResultsList.jsp - the main JSP, contains the javascript to handle scrolling
  • ResultsFormat.jsp - takes an array of records and formats them appropriately
  • recordRequest.jsp - was called upon scroll, and it invoked a droplet to get more records
  • EndecaInfiniteScrollDroplet - encapsulates all the Endeca API code to get more records

Rather than try to paste sample code snippets into this post, I thought it would be easier if I just provided all the relevant code in case you want to browse through it (keep in mind, this is not at all supported - just sample code).  If you do try to implement this and have questions, please let me know and I'll do what I can to help.

Thursday Jun 27, 2013

Oracle Commerce Responsive Design white paper now available

There is a new white paper available here that covers how responsive design can be implemented on Oracle Commerce.  Have a look and let us know your thoughts!

-- Glen 

Monday Sep 24, 2012

Design for complex ATG applications


Needless to say, some ATG applications are more complex than others.  Some ATG applications support a single site, single language, single catalog, single currency, have a single development staff, single business team, and a relatively simple business model.  The real complex applications have to support multiple sites, multiple languages, multiple catalogs, multiple currencies, a couple different development teams, multiple business teams, and a highly complex business model (and processes to go along with it).  While it's still important to implement a proper design for simple applications, it's absolutely critical to do this for the complex applications.  Why?  It's all about time and money.  If you are unable to manage your complex applications in an efficient manner, the cost of managing it will increase dramatically as will the time to get things done (time to market).  On the positive side, your competition is most likely in the same situation, so you just need to be more efficient than they are.

This article is intended to discuss a number of key areas to think about when designing complex applications on ATG.  Some of this can get fairly technical, so it may help to get some background first.  You can get enough of the required background information from this post.  After reading that, come back here and follow along.

Application Design

Of all the various types of ATG applications out there, the most complex tend to be the ones in the telecommunications industry - especially the ones which operate in multiple countries.  To get started, let's assume that we are talking about an application like that.  One that has these properties:
  • Operates in multiple countries - must support multiple sites, catalogs, languages, and currencies
  • The organization is fairly loosely-coupled - single brand, but different businesses across different countries
  • There is some common functionality across all sites in all countries
  • There is some common functionality across different sites within the same country
  • Sites within a single country may have some unique functionality - relative to other sites in the same country
  • Complex product catalog (mostly in terms of bundles, eligibility, and compatibility)
At this point, I'll assume you have read through the required reading and have a decent understanding of how ATG modules work...

Code / configuration - assemble into modules

When it comes to defining your modules for a complex application, there are a number of goals:
  • Divide functionality between the modules in a way that maps to your business
  • Group common functionality 'further down in the stack of modules'
  • Provide a good balance between shared resources and autonomy for countries / sites
Now I'll describe a high level approach to how you could accomplish those goals...  Let's start from the bottom and work our way up.  At the very bottom, you have the modules that ship with ATG - the 'out of the box' stuff.  You want to make sure that you are leveraging all the modules that make sense in order to get the most value from ATG as possible - and less stuff you'll have to write yourself.  On top of the ATG modules, you should create what we'll refer to as the Corporate Foundation Module described as follows:

  • Sits directly on top of ATG modules
  • Used by all applications across all countries and sites - this is the foundation for everyone
  • Contains everything that is common across all countries / all sites
  • Once established and settled, will change less frequently than other 'higher' modules
  • Encapsulates as many enterprise-wide integrations as possible
  • Will provide means of code sharing therefore less development / testing - faster time to market
  • Contains a 'reference' web application (described below)
The next layer up could be multiple modules for each country (you could replace this with region if that makes more sense).  We'll define those modules as follows:

  • Sits on top of the corporate foundation module
  • Contains what is unique to all sites in a given country
  • Responsible for managing any resource bundles for this country (to handle multiple languages)
  • Overrides / replaces corporate integration points with any country-specific ones
Finally, we will define what should be a fairly 'thin' (in terms of functionality) set of modules for each site as follows:

  • Sits on top of the country it resides in module
  • Contains what is unique for a given site within a given country
  • Will mostly contain configuration, but could also define some unique functionality as well
  • Contains one or more web applications

The graphic below should help to indicate how these modules fit together:

Web applications

As described in the previous section, there are many opportunities for sharing (minimizing costs) as it relates to the code and configuration aspects of ATG modules.  Web applications are also contained within ATG modules, however, sharing web applications can be a bit more difficult because this is what the end customer actually sees, and since each site may have some degree of unique look & feel, sharing becomes more challenging.  One approach that can help is to define a 'reference' web application at the corporate foundation layer to act as a solid starting point for each site.  Here's a description of the 'reference' web application:

  • Contains minimal / sample reference styling as this will mostly be addressed at the site level web app
  • Focus on functionality - ensure that core functionality is revealed via this web application
  • Each individual site can use this as a starting point
  • There may be multiple types of web apps (i.e. B2C, B2B, etc)
There are some techniques to share web application assets - i.e. multiple web applications, defined in the web.xml, and it's worth investigating, but is out of scope here.

Reference infrastructure

In this complex environment, it is assumed that there is not a single infrastructure for all countries and all sites.  It's more likely that different countries (or regions) could have their own solution for infrastructure.  In this case, it will be advantageous to define a reference infrastructure which contains all the hardware and software that make up the core environment.  Specifications and diagrams should be created to outline what this reference infrastructure looks like, as well as it's baseline cost and the incremental cost to scale up with volume.  Having some consistency in terms of infrastructure will save time and money as new countries / sites come online.  Here are some properties of the reference infrastructure:

  • Standardized approach to setup of hardware
    • Type and number of servers
    • Defines application server, operating system, database, etc... - including vendor and specific versions
  • Consistent naming conventions
    • Provides a consistent base of terminology and understanding across environments
  • Defines which ATG services run on which servers
    • Production
    • Staging
    • BCC / Preview
  • Each site can change as required to meet scale requirements

Governance / organization

It should be no surprise that the complex application we're talking about is backed by an equally complex organization.  One of the more challenging aspects of efficiently managing a series of complex applications is to ensure the proper level of governance and organization.  Here are some ideas and goals to work towards:

  • Establish a committee to make enterprise-wide decisions that affect all sites
    • Representation should be evenly distributed
    • Should have a clear communication procedure
    • Focus on high level business goals
    • Evaluation of feature / function gaps and how that relates to ATG release schedule / roadmap
    • Determine when to upgrade & ensure value will be realized
  • Determine how to manage various levels of modules
    • Who is responsible for maintaining corporate / country / site layers
    • Determine a procedure for controlling what goes in the corporate foundation module
  • Standardize on source code control, database, hardware, OS versions, J2EE app servers, development procedures, etc
    • only use tested / proven versions - this is something that should be centralized so that every country / site does not have to worry about compatibility between versions
  • Create a innovation team
    • Quickly develop new features, perform proof of concepts
    • All teams can benefit from their findings


At this point, it should be clear why the topics above (design, governance, organization, etc) are critical to being able to efficiently manage a complex application.  To summarize, it's all about competitive advantage...  You will need to reduce costs and improve time to market with the goal of providing a better experience for your end customers.  You can reduce cost by reducing development time, time allocated to testing (don't have to test the corporate foundation module over and over again - do it once), and optimizing operations.  With an efficient design, you can improve your time to market and your business will be more flexible  and agile.  Over time, you'll find that you're becoming more focused on offering functionality that is new to the market (creativity) and this will be rewarded - you're now a leader.

In addition to the above, you'll realize soft benefits as well.  Your staff will be operating in a culture based on sharing.  You'll want to reward efforts to improve and enhance the foundation as this will benefit everyone.  This culture will inspire innovation, which can only lend itself to your competitive advantage.

Key ATG architecture principles


The purpose of this article is to describe some of the important foundational concepts of ATG.  This is not intended to cover all areas of the ATG platform, just the most important subset - the ones that allow ATG to be extremely flexible, configurable, high performance, etc.  For more information on these topics, please see the online product manuals.

The first concept is called the 'ATG Module'.  Simply put, you can think of modules as the building blocks for ATG applications.  The ATG development team builds the out of the box product using modules (these are the 'out of the box' modules).  Then, when a customer is implementing their site, they build their own modules that sit 'on top' of the out of the box ATG modules.  Modules can be very simple - containing minimal definition, and perhaps a small amount of configuration.  Alternatively, a module can be rather complex - containing custom logic, database schema definitions, configuration, one or more web applications, etc.  Modules generally will have dependencies on other modules (the modules beneath it).  For example, the Commerce Reference Store module (CRS) requires the DCS (out of the box commerce) module.

Modules have a ton of value because they provide a way to decouple a customers implementation from the out of the box ATG modules.  This allows for a much easier job when it comes time to upgrade the ATG platform.  Modules are also a very useful way to group functionality into a single package which can be leveraged across multiple ATG applications.

One very important thing to understand about modules, or more accurately, ATG as a whole, is that when you start ATG, you tell it what module(s) you want to start.  One of the first things ATG does is to look through all the modules you specified, and for each one, determine a list of modules that are also required to start (based on each modules dependencies).  Once this final, ordered list is determined, ATG continues to boot up.  One of the outputs from the ordered list of modules is that each module can contain it's own classes and configuration.  During boot, the ordered list of modules drives the unified classpath and configpath.  This is what determines which classes override others, and which configuration overrides other configuration.  Think of it as a layered approach.

The structure of a module is well defined.  It simply looks like a folder in a filesystem that has certain other folders and files within it.  Here is a list of items that can appear in a module:

  • META-INF - this is required, along with a file called MANIFEST.MF which describes certain properties of the module.  One important property is what other modules this module depends on.
  • config - this is typically present in most modules.  It defines a tree structure (folders containing properties files, XML, etc) that maps to ATG components (these are described below).
  • lib - this contains the classes (typically in jarred format) for any code defined in this module
  • j2ee - this is where any web-apps would be stored.
  • src - in case you want to include the source code for this module, it's standard practice to put it here
  • sql - if your module requires any additions to the database schema, you should place that schema here

Here's a screenshots of a module:

Modules can also contain sub-modules.  A dot-notation is used when referring to these sub-modules (i.e. MyModule.Versioned, where Versioned is a sub-module of MyModule).

Finally, it is important to completely understand how modules work if you are going to be able to leverage them effectively.  There are many different ways to design modules you want to create, some approaches are better than others, especially if you plan to share functionality between multiple different ATG applications.


A component in ATG can be thought of as a single item that performs a certain set of related tasks.  An example could be a ProductViews component - used to store information about what products the current customer has viewed.  Components have properties (also called attributes).  The ProductViews component could have properties like lastProductViewed (stores the ID of the last product viewed) or productViewList (stores the ID's of products viewed in order of their being viewed).  The previous examples of component properties would typically also offer get and set methods used to retrieve and store the property values.  Components typically will also offer other types of useful methods aside from get and set.  In the ProductViewed component, we might want to offer a hasViewed method which will tell you if the customer has viewed a certain product or not.

Components are organized in a tree like hierarchy called 'nucleus'.  Nucleus is used to locate and instantiate ATG Components.  So, when you create a new ATG component, it will be able to be found 'within' nucleus.  Nucleus allows ATG components to reference one another - this is how components are strung together to perform meaningful work.  It's also a mechanism to prevent redundant configuration - define it once and refer to it from everywhere.

Here is a screenshot of a component in nucleus: 

Components can be extremely simple (i.e. a single property with a get method), or can be rather complex offering many properties and methods.  To be an ATG component, a few things are required:

  • a class - you can reference an existing out of the box class or you could write your own
  • a properties file - this is used to define your component
  • the above items must be located 'within' nucleus by placing them in the correct spot in your module's config folder
Within the properties file, you will need to point to the class you want to use:


You may also want to define the scope of the class (request, session, or global):


In summary, ATG Components live in nucleus, generally have links to other components, and provide some meaningful type of work.  You can configure components as well as extend their functionality by writing code.


Repositories (a.k.a. Data Anywhere Architecture) is the mechanism that ATG uses to access data primarily stored in relational databases, but also LDAP or other backend systems.  ATG applications are required to be very high performance, and data access is critical in that if not handled properly, it could create a bottleneck.  ATG's repository functionality has been around for a long time - it's proven to be extremely scalable.  Developers new to ATG need to understand how repositories work as this is a critical aspect of the ATG architecture.  

Repositories essentially map relational tables to objects in ATG, as well as handle caching.  ATG defines many repositories out of the box (i.e. user profile, catalog, orders, etc), and this is comprised of both the underlying database schema along with the associated repository definition files (XML).  It is fully expected that implementations will extend / change the out of the box repository definitions, so there is a prescribed approach to doing this.  The first thing to be sure of is to encapsulate your repository definition additions / changes within your own module (as described above).  The other important best practice is to never modify the out of the box schema - in other words, don't add columns to existing ATG tables, just create your own new tables.  These will help ensure you can easily upgrade your application at a later date.


As mentioned earlier, when you start ATG, the order of the modules will determine the final configpath.  Files within this configpath are 'layered' such that modules on top can override configuration of modules below it.  This is the same concept for repository definition files.  If you want to add a few properties to the out of the box user profile, you simply need to create an XML file containing only your additions, and place it in the correct location in your module.  At boot time, your definition will be combined (hence the term xml-combination) with the lower, out of the box modules, with the result being a user profile that contains everything (out of the box, plus your additions).  Aside from just adding properties, there are also ways to remove and change properties.

types of properties

Aside from the normal 'database backed' properties, there are a few other interesting types:
  • transient properties - these are properties that are in memory, but not backed by any database column.  These are useful for temporary storage.
  • java-backed properties - by nature, these are transient, but in addition, when you access this property (by called the get method) instead of looking up a piece of data, it performs some logic and returns the results.  'Age' is a good example - if you're storing a birth date on the profile, but your business rules are defined in terms of someones age, you could create a simple java-backed property to look at the birth date and compare it to the current date, and return the persons age.
  • derived properties - this is what allows for inheritance within the repository structure.  You could define a property at the category level, and have the product inherit it's value as well as override it.  This is useful for setting defaults, with the ability to override.

There are a number of different caching modes which are useful at different times depending on the nature of the data being cached.  For example, the simple cache mode is useful for things like user profiles.  This is because the user profile will typically only be used on a single instance of ATG at one time.  Simple cache mode is also useful for read-only types of data such as the product catalog.  Locked cache mode is useful when you need to ensure that only one ATG instance writes to a particular item at a time - an example would be a customers order.  There are many options in terms of configuring caching which are outside the scope of this article - please refer to the product manuals for more details.

Other important concepts - out of scope for this article

There are a whole host of concepts that are very important pieces to the ATG platform, but are out of scope for this article.  Here's a brief description of some of them:

  • formhandlers - these are ATG components that handle form submissions by users.
  • pipelines - these are configurable chains of logic that are used for things like handling a request (request pipeline) or checking out an order.
  • special kinds of repositories (versioned, files, secure, ...) - there are a couple different types of repositories that are used in various situations.  See the manuals for more information.
  • web development - JSP/ DSP tag library - ATG provides a traditional approach to developing web applications by providing a tag library called the DSP library.  This library is used throughout your JSP pages to interact with all the ATG components.
  • messaging - a message sub-system used as another way for components to interact.
  • personalization - ability for business users to define a personalized user experience for customers.  See the other blog posts related to personalization.

Tuesday May 22, 2012

My Oracle Support (MOS) Communities

The My Oracle Support Communities are vibrant forums for Oracle
customers, partners and employees to share knowledge, discover best practices
and ask questions. We encourage you to use these communities as well as to refer back to this blog for new posts on Oracle Commerce best practices.

For access to MOS, you will need to register on My Oracle Support:

When registering, you will be asked for a Customer Support Identifier (CSI).  If you are a partner, please use your partner SI. If you are a customer, you can use your ATG or Endeca SI number. If you are an authorized user of MetaLink 3 ( or Classic MetaLink/My
Oracle Support (, your CSI number will be contained in your
User Profile. If you have difficulty locating your CSI number, then you may
contact your company’s Customer User Administrator or the Oracle Support Sales
Representative assigned to your company. To locate your Support Sales
Representative, dial the Support Sales phone number listed by region on

There is an overall Oracle Commerce Category that both ATG and Endeca belong. 
We have individual communities for each product set.  The Communities can
be accessed via a tab in MOS, and you can set up subscriptions to follow them
as desired.

New Oracle Commerce and Oracle Knowledge communities are open, active, and
dedicated and fully integrated with MOS Service Requests and Knowledgebase.

  • Oracle
    ATG Web Commerce products, formerly known as the ATG Commerce Suite

  • Oracle
    Endeca products, formerly known as Endeca IAP and Endeca Latitude

  • Oracle
    Knowledge products, formerly known as InQuira

Tuesday Apr 17, 2012

What's New 10.1

ATG 10.1 (Dupont) was released April 2012. This note includes the All Products Chart for that version.

All Products Chart

What's New in 10.1


Merchant Empowerment: Merchants are continuously under pressure to innovate and be efficient. They need to do more with less time and resources. These merchants need flexibility to innovate in their sales and marketing, with creative approaches to attract, convert and retain customers. In order to be efficient and flexible, users need to be able to implement their plans without relying on technical support personnel.
ATG 10.1 adds a number of new capabilities to allow merchants to work faster, smarter and with more options to execute business plans on their site. These features address not only the costs of maintaining a site by allowing merchants to accomplish their tasks with fewer steps, but also new ways to view and edit data on the site that bring together the data-driven science as well as the visual art of merchandising. Likewise, new promotion capabilities, including pre-packaged templates for common promotion types, allow them to more easily and quickly create promotions according to their business objectives.

Mobile & Cross Channel: Customer usage of mobile devices is growing at an unprecedented pace, and merchants are racing to engage with their customers in a consistent manner across all channels and devices. Merchants are using all channels, especially mobile, to increase customer engagement and satisfaction with their brands. Cross channel commerce presents new opportunities with unique capabilities and there is growing market need for merchants to provide a seamless experience across all touch points – web, mobile, social, kiosks, contact center etc.
To enable merchants to provide an integrated and orchestrated cross channel experience, ATG is now providing a framework/SDK to ease and accelerate the development of mobile commerce solutions on the ATG platform. Release 10.1 provides mobile-optimized web and IOS versions of the Commerce Reference Store (CRS) that showcase key ATG features and value propositions and serve as a framework to help developers build mobile sites and applications more quickly. Improvements to the REST framework enable other applications to integrate and consume ATG commerce functions in a simpler and more efficient way. ATG's call center application, CSC, has been enhanced with a redesigned user interface to allow greater efficiency for call center agents.

Faster Commerce on a Global Scale: Merchants, like all business units, are driven to grow their business. They look to innovate and expand in a number of ways and to optimize their business across many areas. These factors have driven many companies to expand internationally, to extend product offerings, and to offer optimized shopping experiences to all segments of their customers.
The 10.1 release adds key capabilities to allow merchants to expand internationally, as well as enable merchants who are based internationally to use the ATG Commerce business user tools in their native language and cultural format. New capabilities, such as the integration with Coherence, allow merchants to scale to very large catalogs with high performance. The merging of ATG B2B and B2C modules enables B2C retailers to offer optimized shopping solutions to both their B2B and B2C customers and allows B2B companies to offer many of the same features to guide the shopper experience as their B2C counterparts. In summary, the new features of 10.1 allow companies to address broader markets, in different regions and with greater scale.

Monday Apr 16, 2012

What's New 9.1

[Read More]

What's New 10.0

ATG 10.0  (Cascade) was released December 2010.  This note includes the
What's New Document and the All Products Chart for that version.

What's New 10.0

No All Products Chart was released for this version


Reap the Rewards of a Commerce Anywhere World: The term Commerce Anywhere represents ATG’s view of how to effectively serve the “anytime, anywhere” customer and unify commerce initiatives across channels and devices. With ATG Commerce 10, companies can move from a model of independent, siloed, multi-channel sales processes to a unified cross-channel sales model that creates a highly coordinated customer experience and increases sales. ATG 10 enables you to deliver consistent customer profiles, product content, promotions, and order information in all touch points.

  • Improve the customer experience by empowering customers to shop the way they want, with the help of other consumers, seamlessly across channels, using their favorite devices

  • Increase agility and empower marketers and merchants with the tools to manage the customer experience, promotions, and content, and leverage customer-generated ratings and reviews across multiple sites

  • Implement a future-proof commerce enterprise by arming IT with the software and tools to rapidly build and implement a unified commerce infrastructure and systems

Gain Control, Efficiency, and Speed: Whether your customers are businesses or individuals, ATG 10 gives you the flexibility to adapt to changing customer behaviors to take full advantage of a dynamic and global marketplace. With ATG 10, you can:

  • Merchandise quickly, easily, and effectively to drive profitability

  • Rapidly launch sites for new brands, markets, and even single-purpose campaigns

  • Orchestrate seamless cross-channel buying experiences to improve customer loyalty

  • Use mobile devices and social media to drive sales

  • Expand internationally and target new countries and segments more effectively

Implement and Manage Your Sites with Ease:
New features and powerful tools in ATG 10 will speed implementations and reduce operational costs.

  • Simplify the management of commerce software and applications

  • Improve administrative and operational efficiency
    Increase technical flexibility and agility

Wednesday Feb 22, 2012

Defining content and the tools to manage it

A big part of managing an eCommerce site is to be able to manage the various forms of content on the site.  Content is a relatively vague term, so we need to provide some additional definition.

Defining 'content'

Development assets - This includes things like java code, configuration files, and JSP pages (templates).  These assets are typically maintained in source code control systems.  There are usually 'build scripts' that will compile the source code, and package the whole application into a form that can be deployed to the application server.  Deployments (moving the code into staging or production environments) is something that takes careful planning and organization within the development / operations group.

Oracle ATG-specific assets - These assets include content groups, segments, content targeters, promotions, scenarios, etc.  There are a few different approaches to managing these assets, but in general, they are best managed using Oracle ATG tools such as the BCC and Merchandising.

For the most part, what's we're left with can be considered some form of content.  We can break down what's left into two categories:

Static content - examples include style sheets (CSS), small navigational images, static html files, etc.  These assets are authored by designers who usually have their own process of managing these assets (i.e. they might leverage the source code control system that the developers use, or there could be other tools they prefer).

Dynamic content - this can be considered any content stored in an Oracle ATG repository such as products, categories, skus, media items, etc.  This content is typically managed using Oracle ATG tools such as the BCC or Merchandising.  When this type of content changes, it's expected that the changes will go through some kind of approval or review process.  At the very least, the changes need to be 'previewed' in order to see what what it will look like before being deployed to production.

What about other content items that are not listed above?  Perhaps your site has other kinds of content such as articles, tips / advice, detailed product sheets, etc.  Do you consider that content to be static or dynamic based on the definitions above?   You may already be managing that content in another content management system (CMS).  Should all of that content remain in the existing CMS, or should some or all of that content be migrated into Oracle ATG to be managed there?

Which tools to manage your content

There are a number of factors to consider when making that decision:

Factor 1: Investment in existing CMS

  • Sunk cost of the software
  • Sunk cost of any customizations done to the CMS
  • Training investment for the people who use the system

The existing investment might be too much to walk away from, especially if the system is functioning well.  If that's the case, then you're likely to end up with a 'combined' way to manage the assets of your site (see description of this below).

Factor 2: Enhancing your content management capabilities

What are the advantages of managing the content in Oracle ATG?  Some possibilities could include:

  • A single UI for managing content along with the rest of the sites assets
  • A single mechanism to deploy assets to the site (one approach for content along with all the other assets managed in the BCC)
  • Narrow down to a single vendors solution (reduced support cost, operational efficiencies, etc)
  • Potentially easier to cross reference content with catalog assets (perhaps you want to create a relationship between a product and articles related to that product.  Having them in one system may make that easier)
  • Do you plan to 'target' this content to customers in personalization rules?  In order to specify content to be targeted to customers, Oracle ATG needs to be aware of the content (at least the ID and meta-data).

Factor 3: Existing system effectiveness

If it's not broke...

  • Is the existing system performing well?
  • Are users able to manage the content effectively?
  • Are there any unique features in the existing system that users simply can't live without?

Different approaches

That's alot to think about.  The good news is that you can make it work either way.  First, let's take a look at how it would work if you decide to migrate all the content into Oracle ATG; we'll refer to this as the single system approach:


  • Analyze the existing content
  • Define the Oracle ATG content repositories to store that content
  • Consider functional requirements (preview, security, workflow, etc).
  • Migrate content into Oracle ATG
  • Instrument your pages to render the content accordingly

Below is a simple diagram that represents what the single system approach might look like.


Next, we'll have a look at what happens if you decided to continue managing content in the existing CMS; we'll refer to this as the combined system approach.  This approach allows you to leverage your investment in your existing CMS, but rather than have the content being published to your production servers, it publishes to a place where Oracle ATG CA can 'pick up' that content and store it in the same system you use to manage other assets.  There are a few benefits to this approach when you need to combine Oracle ATG with an existing CMS:

  • Single deployment mechanism to production (can take advantage of Oracle ATG switching data sources, cache invalidation, etc).  This will provide a higher level of reliability in terms of knowing what the site will look like when the deployment has completed.
  • Easier to preview site as all content is available within a single system
  • Ability to ‘relate’ an item managed in CA to an item which is authored in the CMS (but fed into CA)


  • Analyze the existing content
  • Define Oracle ATG content repositories to store content
  • Consider functional requirements (preview, security, workflow, etc).
  • Create the process of importing the content into the Oracle ATG repositories in an automated fashion (Oracle ATG provides a framework for this).  This content should not be modified by hand in Oracle ATG; you should only change it in the existing CMS in order to keep everything in sync.
  • Instrument your pages to render the content accordingly

Below is a simple diagram that represents what the combined system approach might look like.


Final thoughts

There are a number of different content management systems on the market which are all built differently.  These differences can have a dramatic affect on the 'best' way to integrate with Oracle ATG.  For example, some CMS's can act as a runtime engine which means they are capable of serving content / pages to the customer.  This capability (if used) will potentially complicate an integration, but at the very least, it could easily lead to a fragmented customer experience as multiple different systems will be delivering content.  This is a prime example of a time where it will be essential to work with Oracle ATG Professional Services to ensure that your environment is designed in a way that makes sense for your business.

Thursday Feb 09, 2012

ATG in the Telecommunications Industry

The purpose of this post is to describe how ATG can help organizations in the Telecommunications industry achieve their online goals.  ATG has established a leadership role in the overall practice of online commerce and service.  Many of the top retailers around the world use ATG to drive their online business, and in many ways, retailers’ requirements for a commerce platform are similar to that of a Telco.   Common needs between the two industries include performance, scalability, advanced personalization capabilities, optimized business tools to control the site(s), and the need for a commerce platform that provides a careful balance between offering a rich feature set along with the ability to extend / customize the platform to meet the organizations needs.

ATG has proven success with some of the leading telco providers in the world.  We have worked closely with these organizations both to ensure their success as well as understand the value ATG delivers to them.  We have found that there are numerous requirements that are unique to the Telecommunication industry, some of which are discussed below.  When possible, we will also use this document to describe best practices for particular use cases.

Product availability / compatibility

The following examples are primarily geared towards the wireless product line, but the general concepts can be applied to other types of products as well.

Mapping between services and geography

It’s quite obvious that not all service plans are available in all geographic regions.  During the shopping process, it’s necessary for the customer to identify their geographic region (typically by entering their zipcode) in order for the site to only show service plans that are available in their area.  Measures should be taken to ensure that the customer does not have to enter this geographic information more than one time (preferably, across sessions).  ATG provides this capability as an out of the box feature (called Persistent Anonymous Profiles).  For more information on ATG Profiles, see this post.

Mapping between devices and services

Not all wireless service plans are available for all devices.  There needs to be a mapping between device and service plan to ensure that the customer selects a valid combination.  It’s common to represent this as a many to many relationship.  ATG’s Data Anywhere Architecture makes it possible to define these kinds of complex relationships. 

Mapping between accessories and devices

Not all wireless accessories will work with every device.  For example, an iPhone case will certainly not fit a Blackberry phone.  When a customer has selected a device, they should only be presented with accessories that will be compatible with that device.  Ignoring this need will certainly result in unhappy customers and a high return rate for accessories that are incompatible with the selected device.

How to present these complexities to the customer in a way that is intuitive within the shopping process

While it’s essential that the relationships above are enforced to avoid allowing the customer to purchase incompatible products, the work doesn’t stop there.  There are many ways to represent these relationships in the shopping process, but many of them may seem confusing to the customer.  Great care needs to be taken to ensure that the customer has an easy time understanding how to navigate these choices.  There are different approaches to this, some which are rigid and drive the customer down a particular path (see diagram below).  Others are more flexible, allowing the customer more freedom in their shopping process.  For example, perhaps the customer wants to select the device prior to selecting which service plan they want.  Which approach (or the degree of freedom your site employs) and it’s effectiveness will depend on your target audience.  ATG cannot make this decision for you, but there are tools in the platform that will help you to try different approaches, and measure the effectiveness of each with the goal of helping you to find the right mix for your customers. 

Technical side-note

The task of modeling the ATG catalog structure to accommodate the mapping described above should not be taken lightly.  Theoretically, there are many ways to do this, but there are two very important things to keep in mind:

  1. Depending on how the catalog is modeled, performance could be anywhere from very good to unacceptable given the complexity of the relationships between the items (compatibility).  Steps need to be taken to ensure that performance is acceptable during the customer experience.
  2. Regardless of the size of the catalog (number of items) or the complexity of the relationships between items, the catalog must be designed so that it's easy to manage.  Many times, data feeds will populate a significant portion of the online catalog, but the rest is usually managed using ATG's Business User tools (such as ATG Merchandising).  Take time to ensure that the design of the catalog can easily be managed by business users.


What are common personalization goals for telcos?

The term Personalization means different things to different people, but within the context of the organizations online business, it generally boils down a few things; learning more about customer behavior, adapting the site to be more relevant to the customer, and helping guide the customer through various complex transactions (checkout, service, etc). A simple example of a common personalization use case would be the following:

  • A customer comes to the site, and enters their zipcode
  • Next, they spend some time browsing the Blackberry phones section of the site
  • You now know the geographic location of the customer, and the type of device they are likely to be interested in.  It would make perfect sense to adapt the site so that the 'featured devices' change from whatever the generic featured device set was for anonymous customers to something that would highlight the devices that seem most relevant to the customer.  Perhaps you could also offer a 'Which Blackberry is right for you' graphic that takes the customer to content that helps them to decide which Blackberry device is the best fit for their needs.  All the while, you could highlight some service plans that are available in their area as well as compatible with Blackberry devices.

To ATG, Personalization is part technology, but to a larger degree, it’s a strategy that our customer must define.  Our goals are to ensure that our tools enable our customers to fully implement their Personalization strategy as well as to provide best practices around personalization.  Click here for more information about ATG Personalization.

Product Bundling

Pre-defined by business

Bundling products and services together into logical sets of offerings has numerous advantages; provides the customer with an easier way to purchase the set of products / services, allows the organization to have more flexibility with respect to pricing, and it increases the adoption rate of less popular products by bundling them with the more popular items at a perceived low cost.  The task of determining the bundle mix is almost always done at a high level within the Marketing department, and then implemented across all the channels in a consistent manner.  The online channel needs to be flexible enough to handle any bundle mix the Marketing department defines.


Although the business will likely define the basic structure of the bundles, there is usually some degree of flexibility offered to the customer within the bundle structure.  For example, a particular bundle may require that the customer select from a certain class of broadband, select various options for their home phone service, and select certain options for their TV service.  The choices they make within the three products (internet, phone, and cable) will affect the overall package price.  The bundle now has a well-defined set of products included, but with some degree of configurability within each product.

Reverse engineering into a ‘better package’

Another concept that some organizations strive for is to recognize which products a customer already owns (or has in their cart), and try to upsell them into a ‘better package’.  The better package would likely be a bundle that includes all the products they currently have as well as one that they customer does not have.  The advantage to the customer is that they can get an additional product for a small cost (due to how the bundle is priced).  The advantage to the organization is that they increase their adoption rate for the added product.

Custom storefronts  (B2B)

While the B2C site will typically drive the most traffic, the B2B sites may actually be driving the most revenue.  The B2B site will be the destination for your business clients to manage their services, order additional devices, etc.  Each of these sites will typically have a common set of capabilities, but will differ to some extent in terms of products available, pricing, and will generally have a co-branded look and feel.  For the sake of simplifying the terminology, let's call each business clients site a microsite.  Most of the requirements for the B2C site will also be required for the B2B site.  In addition, the B2B site will likely have some additional requirements as follows:

  • Catalog - Each microsite will need to show only the products that are allowed based on the contract between the tow companies.  ATG provides this capability in the form of ATG Custom Catalogs.
  • Pricing - Each microsite will need to apply specific (negotiated) pricing based on the contract as well.  ATG provides this capability via ATG Price Lists.
  • Organizations / roles / approval workflow - The business clients will need some security in place to ensure that people are creating orders that are appropriate for their business.  This means that the ability for them to 'self-administer' the site becomes critical.  These include functions like being able to define a multi-level organization, ability to assign meaningful roles to people, and defining an approval workflow for orders placed (including limits on order values).  ATG provides all of these capabilities.
  • Presentation / UI - Each business client may prefer some kind of unique style for their microsite.  There are plenty of different ways to accomplish this in ATG, and the best approach will depend on how you envision these creative aspects being managed.

Merchandising / Content Management

Managing a commerce site depends on a variety of people with a range of different skill sets and responsibilities.  One of the more important aspects to managing a commerce site is how to manage the catalog as well as the content.  ATG provides  a number of tools that allow business users the ability to make the necessary changes to both the catalog and content.  The primary tool for this purpose is ATG Merchandising.

Regardless of the types of products contained in the catalog (wireless devices, service plans, media downloads, etc), there will almost always be attributes that need to be added to the definition of the category, product, and SKU.  ATG's catalog is extremely flexible, and is designed to be extended in this way.  For example, the out of the box SKU definition does not have a property called 'GPS Enabled' with a true or false value.  This may be something you will need to add to the definition of the SKU in order to properly present the details about the product (or to use this attribute in rules where you filter out any SKUs that have that property set to false).  The point is that every ATG implementation will require some degree of extending the catalog definition, and the ATG business user tools will automatically interpret those extensions and present the UI appropriately with no additional coding.

Promotions / Discounts

Many retailers tend to make great use of discounts in order to entice customers to place orders.  Telecommunications organizations have the opportunity as well, but probably not with the same degree of flexibility.  Promotions / discounts for telecommunications sites tend to be used more as an instrument to affect pricing overall.  The most obvious way to affect pricing is by altering the actual price of a product in the price list.  It's also common to set the price of a bundle to a particular base price, and then the price will adjust up based on the options the customer selects.  If there is a desire to move more customers into a more expensive option, discounts could be used to give the impression to the customer that they are getting a good deal.  ATG provides for the ability to offer percent off, amount off, or fixed price on items, orders, or shipping.

Multi-language / multi-currency

Many sites will have a requirement where they need to present the catalog / content in multiple languages, as well as present pricing in multiple currencies.  This is especially true in Europe.  ATG's commerce platform fully supports multiple languages and multiple currencies.  Some ATG customers decide to create a single site supporting multiple languages and currencies (a centralized approach), while other customers will instead create a different site for each country that will only support a single language and currency (distributed approach).  Which approach you choose is up to you, but it's important to note that either is possible.

Self service / My Account

Online service is an essential aspect to overall customer satisfaction and retention.  Online service can involve a number of areas including finding the answer to a technical question, viewing statements, paying your bill, changing service plan, etc.  Some of these functions are best handled by exposing functionality from the backend systems as opposed to building this functionality in ATG.  A good example is viewing past statement.  There is no real benefit to re-creating this functionality within ATG as there is not likely to be any personalization or selling opportunity within that context.  Rather, it's probably better to simply get the customer the information they are looking for as quickly as possible.

Alternatively, ATG does offer a series to applications that can certainly help customers find answers to commonly asked questions.  This would be an example of functionality that is most likely best delivered by ATG.  In fact, if the customer has authenticated (we know some information about them) then there may be the opportunity to enhance their self service experience by guiding them to the most appropriate information based on what we know about them (products owned, etc).

This is an area where it's common to have some overlap between ATG and other applicaitons, so it's important to have a clear understanding of the capabilites of each applicaiton, as well as a clear understanding of what you're trying to achieve in this area.


Without a doubt, the backend systems within the typical telecommunications organization are highly complex.  There are usually many systems which provide various functions, and each one tends to have it's own lifespan (recently added, mid-life, being phased out), which means there may be a situation where there is an 'old' customer master, and a 'new' customer master in production at the same time.  There is usually a mix of enterprise applications which have been customized to some degree, along with applications built internally by the IT group.   It's common for the IT group to split their time between supporting the enterprise applications and creating the integration infrastructure between them.

Virtually all ATG implementations require integrating to a number of third party applications, and it's no surprise that this tends to be a very important aspect of building out the site.  Some common integration points include things like sending the order to an order management system, receiving catalog feeds, pricing feeds, inventory feeds, tax calculation services, payment processing services, cross channel customer lookups / matching, fraud detection services, etc.  There are things for the IT group to consider when designing an integration:

  • Should the integration be real-time or batch?
  • Should it be synchronous or asynchronous?
  • What transport should we use?
  • How should we handle error conditions?

The ATG platform contains a variety of tools / API's that will help the IT group to simplify / standardize these integrations.  The Data Anywhere Architecture, Web Services, and Integration Framework should be considered when designing integrations to these backend applications.

Business concepts

Think like a retailer

This just make sense...  If you want to be effective at selling online, then you should think and act like a retailer.  In other words, you need to:

  • Merchandise the site in a simple and coherent manner.  The goal is to help customers navigate to the products / services they want as quickly as possible.
  • Provide an intuitive shopping process and avoid exposing all the complexities normally encountered when purchasing complex items.  Remember, the primary goal is to complete the sale, so creating unnecessary obstructions to checkout will make only push you further away from your goal.
  • Ensure that the site performs well.  Nobody likes to shop on a slow site.
  • Don't feel compelled to offer every product possible online as some of them just don't fit very well.  Use the 80/20 rule here and sacrifice complex situations to retain the simplicity of the customer experience.

Be open to re-org (combine business & IT into a closely knit group)

Consider creating a new online commerce group that is comprised of everyone who will actively maintain or support the site including both business and technical people.  This concept has had proven success in the past for a number of reasons:

  • Faster time to market - By bringing the technical and business people together, changes to the site tend to happen in much less time because the walls between the groups have come down.
  • Common goals - Everyone in this group should be measured by the performance of the site.  In this kind of environment, people tend to become much more cooperative in order to meet their common goals.
  • Single focus - People in this group should have a very sharp focus on the online business, and their level of channel expertise will increase over time.

Ensure the business is actively driving requirements (beware of making false assumptions)

Telecommunications organizations are commonly IT driven companies.  Creating an effective online commerce application absolutely requires the synchronized efforts of both the IT group as well as the business side.  


In order to compete in the extremely competitive online commerce space, Telecommunications organizations will need to find ways to differentiate themselves in the eyes of their customers and business clients.  ATG's commerce platform provides an an excellent foundation to build your customer facing sites on.  Many leading Telecommunications organizations around the world have already experienced success online with ATG.  Hopefully, this post has provided some insight into how ATG can help these organizations meet their online goals.

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.

Critical tasks for ATG Merchandising implementation

Of all the things that you should consider when planning an implementation of ATG Merchandising, there are a few critical tasks that rise to the top.  I've broken them down into three categories; implementation, technical, and process / organization / usability.


The items below represent the most important things to consider when planning for your implementation:

  • Engage with ATG PS - This is by far, the most important item of all.  ATG Professional Services can provide the expert skills and advice that will help to ensure that your implementation is a success.
  • Leverage ATG training (business and technical) - ATG offers education for both business and technical people for both Merchandising and Content Administration (the important underlying framework of Merchandising).  In order to gain a comprehensive understanding of these products, education is essential.
  • Plan on this being a ‘real’ project - Do not underestimate the complexity and importance of this implementation.  While implementing Merchandising is not something your customers will see, it will have an impact on your e-commerce operations.
  • Engage business users very early (requirements, most common use cases, testing, etc) - This is not just a new tool, but most likely, a new process for managing the site(s) as well.  The business users who will use this system every day must be involved from the beginning and should receive guidance on how to present their most important needs (see other posts in the Requirements category).


The items below represent the most important technical recommendations (from ATG) with respect to running Merchandising:

  • Read the CA best practices guide - ATG has created a CA (Content Administration) best practices guide, which contains essential advice on implementing CA.  It's important to note that best practices evolve over time so make sure you're looking at the latest version (available here).  The bullets below are discussed in this best practices guide, but they are worth mentioning again.
  • Use the latest version, patches, and hotfixes - There is no reason to run into the same issues that other customers have run into (which have been fixed in the form of a patch or hotifx).  Make sure you have all of those fixes in place so you don't waste valuable time debugging known and resolved issues.
  • Use the late staged workflow - This is the workflow recommended for all implementations of CA.  ATG offers other workflows out of the box, but best practices suggest that late staged is very likely the best one to use.
  • Use switching data sources in your production environment - This is something all ATG customers should do regardless of whether they are using Merchandising or not, but it becomes especially important when you are using Merchandising.  The idea here is that using switching datasources allows CA to update the catalog / content of your site without having an impact on your customers in the unlikely case that a deployment should fail.  In short, it's the safest approach.
  • Establish application security - Security is something that needs to be designed from the beginning, not something to add on later.  You should map your organization and roles to the appropriate application permissions.

Process / Organization / Usability

The items below represent the most important things to consider in order for the business users to successfully use Merchandising most efficiently:

  • Users work in different projects - We have found that when users create and work in their own project (as opposed to multiple users working in a single project), there is much better visibility into who changed what (less confusion).
  • Users should log in using their own login - We highly recommend that business users do not share a single / common login (such as the default 'publishing' login).  This will always lead to confusion over who changed what, it's much better for users have (and use) their own logins.
  • Avoid working in same category at the same time as other users - The ATG catalog structure is highly flexible in that it allows you to link the same product to multiple categories, link the same sub-category to multiple categories, etc.  With this flexibility comes some complexity in how to manage that structure.  The 'linking' capabilities can make things confusing when two business users are making changes in the same category, so we suggest that users avoid doing that.
  • Leverage the multi-edit capabilities as much as possible - Multi-edit is a excellent way to reduce the redundant 'clicks' to get a set of work done.  In an effort to optimize the business users use cases, it's important to understand and leverage Multi-edit as much as possible.
  • Create a map for business user (when I change XYZ, it has this affect on the site) - We've heard many business users say something like '... I have no idea what happens when I change the XYZ attribute of the product...'.  We recommend that a document be created that clearly shows what happens to the site when the business user changes a field in Merchandising.  This should be a large part of a custom training manual for business users.
  • Document the roles and responsibilities in your organization - Business users will need to understand who is responsible for what tasks in order to function properly.  This will separate tasks such as authoring and reviewing (so the business users will understand which task they are supposed to complete).  It will also help to get new hires up to speed faster.

Monday Aug 01, 2011

Thoughts on organizational structure to support an ATG commerce implementation

 While interviewing organizations that have implemented ATG, it is apparent that there is not a significant change in staff and that typically, just a re-training of staff occurs.  This varies with different scenarios such as those organizations that are new to online commerce or are moving from a fully hosted solution to one that they must be responsible for.  As organizations expand to greater international markets, thought should be given to current centralized strategies of site design and local campaigns.  It will be critical to empower those local offices to respond quickly to their markets.  This type of approach may increase expected headcount.  This post details an example of typical staffing requirements and FTE estimates based on a medium sized eCommerce organization which would have the following attributes:

  • Catalog: approximately 10,000 products with 18,000 SKUs
  • Site Traffic: 1.5 million page views
  • Unique Visitors: approximately 250,000/day
  • Annual Growth: 20

Business Groups

Merchandisers: ⁞ This group will be utilizing Oracle ATG Web Commerce Merchandising.  Most people re-train their existing content management team on ATG Merchandising through Oracle education (  It has been noted that ATG automates a majority of tasks that the merchant performed with old system(s) manually.  This automation has allowed merchants to focus more time on strategic campaigns and less time on daily maintenance tasks.  Headcount: 2 to 5 people per brand or unique catalog.  At least 2 people should be trained to cover for holidays, vacation and sick time.  The number depends on the size of the catalog and the number of changes made to the catalog per day.

Marketers: There are many personalization aspects of ATG that a marketer may want to drive including creating segments, content groups, content targeters and promotional campaigns to target those specific segments.  Headcount: 1 to 2 per brand or unique catalog.

eCommerce Service Agents: This group would be utilizing Oracle ATG Web Commerce Service Center. The staff in the contact center will also not change.  Again, the automation of the tasks in the call center that were previously manual or involved access to multiple systems greatly reduces call handle times.  Headcount should remain the same if a call center is in place.

Business Analyst: This role liaises between IT and the Business.  They may sit on the business or IT side and help to translate the business functionality use cases and needs to the technical development team.   In an ATG environment,, they are also typically assisting the business with merchandising and promotional tasks, including scenario design and maintenance.  This role can also act as the overall liaison across all ATG products implemented to assure streamlined work flow and processes cross product and business lines.  We find this role is most often overlooked but the role is critical to the success of post launch business process.  This person would be utilizing Oracle ATG Web Commerce Merchandising, Search Merchandising, Personalization, and ATG Control Center.  Headcount: typically 1

IT Groups

These support number should also remain the same, if a full service IT group was in place.  Oracle provides ATG Administrative courses at various levels across the platform to provide a foundation of understanding.  An ATG recommendation would be to take a channel approach if focused B2C and B2B while having an Operations Team manage the ATG infrastructure.  We have found that a 2 to 1 technician to manager ratio is ideal.  This allows for proper focus on the strategic issues of utilization and resources (server/memory) planning, but the Operations Team can also be used for spear heading business requirement specifications.The Operations Team can also help drive the technical review and requirements for PCI compliance.

Note on scaling the IT organization: While it might seem logical that the supporting IT organization of an eCommerce business has to scale in direct proportion to the growth of the business (as measured in revenue), that is not always the case across the organization.  The number of Development FTEs is greatly dependent on the volume of functionality change and maintenance and is not tied to the volume of transactions.  The exception to this rule might be in Deployment and QA, as the supporting infrastructure will certainly scale with revenue and could require more resources to efficiently support that task.  The key factor that drives scale in most eCommerce businesses is supporting multi-site and/or multi-brand implementations within the same organization.

IT management staff should be a team of developers, testers and a project manger/technical lead.  At  minimum, there is 1 person running applications, 1 person running infrastructure, but other layers will be needed if in a larger organization: Application Operations (monitoring, troubleshooting, ops), System Management, Security, Database Management, Network, Backup.  Headcount 4 to 8 depending on level of development and management.

VP/Director Level: This is typically a director level position which is aligned with peer-level IT management functions (project office, infrastructure, systems, etc) outside of the eCommerce business unit, although, larger organizations may find that the level of responsibility is such that it requires a VP-level position.  This position has overall responsibility for all IT functions related to the Commerce business, including development, QA, data migration and deployment.  Infrastructure and DBA may be an area of responsibility but could also be assumed by other internal organizations.

Development Management: This will most likely be a manager position, although the size of the organization could dictate it as a director-level position if reporting through a VP.  The responsibilities for this position would include managing the development staff and all relevant development projects, including code maintenance.

eCommerce Development (Senior): This developers have object-oriented programming background and at least 5+ years of Java, with preferably 2+ years of prior ATG experience and/or some other commerce framework. These developers do the majority of the heavy lifting on new functionality and site enhancements.  The actual number of development FTEs will greatly depend on the volume of new site functionality being developed, but a typical organization will have anywhere from 3-5 minimum.  This team may also be responsible for third party integrations to outlying systems (data feeds to fulfillment PkMS, payment processing, corporate legacy systems and reporting data warehouse).

eCommerce Development (Junior): These developers will primarily be working on the presentation layer of the eCommerce site and will not necessarily have a Java background or experience with ATG.  The web developers will have exposure to JavaScript and other scripting languages such as CSS and HTML.  The web developers are also responsible for JSP development and have a solid understanding of ATG so they can work on form handlers to the back end where necessary.  There should also be multi-media developers that have experience with flash, AJAX, video and interactive media.  They are most likely working on modifications to the user experience, content refreshes, product catalog updates, marketing updates to the site, seasonal content refreshes, promotions) and tying front end code to the lower level code that the senior developers are working on.  Exposure to development at this level makes for an ideal transition to Java development and a succession path to a senior development role.  As with the senior role, the FTE level depends on project volume but a typical organization would have 2-3 junior developers.

Deployment Specialist: This role will be responsible for the migration of the data and deployment of code releases tot eh ATG infrastructure and should not have any direct development responsibilities.  The need for an FTE in this role is predicated on the assumption that catalog repositories and search indexes are being refreshed on a daily basis and that there is at least one code release each week.

IT development staff - The variance here depends on where or not the organization is in active development state or not.  If the organization generally runs in maintenance mode, bringing in more bodies periodically, the organic number will be lower.  Another variable to answer is "who is providing operational support?".  Some organizations outsource some or all of these tasks to a systems integrator. Headcount: 2 to 8 range.

eCommerce Development (Senior): This developers have object-oriented programming background and at least 5+ years of Java, with preferably 2+ years of prior ATG experience and/or some other commerce framework. These developers do the majority of the heavy lifting on new functionality and site enhancements.  The actual number of development FTEs will greatly depend on the volume of new site functionality being developed, but a typical organization will have anywhere from 3-5 minimum.  This team may also be responsible for third party integrations to outlying systems (data feeds to fulfillment PkMS, payment processing, corporate legacy systems and reporting data warehouse).

eCommerce Development (Junior): These developers will primarily be working on the presentation layer of the eCommerce site and will not necessarily have a Java background or experience with ATG.  The web developers will have exposure to JavaScript and other scripting languages such as CSS and HTML, Flash, etc. They are most likely working on modifications to the user experience, content refreshes, product catalog updates, marketing updates to the site, seasonal content refreshes, promotions) and tying front end code to the lower level code that the senior developers are working on.  Exposure to development at this level makes for an ideal transition to Java development and a succession path to a senior development role.  As with the senior role, the FTE level depends on project volume but a typical organization would have 2-3 junior developers.

Architect(s): This team is responsible for setting and executing platform and data architecture strategy and road map which would include version control.  Team should include an architect with strong database design skills and a DBA administrator.

Note on the Development Team: The division of Junior/Senior developers and the inclusion of dedicated Deployment and QA specialist are based on what a relatively mature eCommerce IT organization would look like.  Some organizations at post launch may tend to learn towards a pool of development resources, where there is no clear division of specialty, and developers rotate on deployment and QA duties.  As an organization grows and becomes more mature, this separation of responsibilities results in greater efficiencies.

IT QA Staff is usually comprised of one functional tester, one load tester, one swing person who does documentation as well.  Headcount is 1 to 3 depending on IT requirements.  In our larger customers where there is a lot of policy sign off, there will be 3 people consistently.  Most disciplined organizations have QA processes inclusive of performance, load analysis as well as functional analysis.  Smaller organizations will have 1 person or leverage other team members.

QA Specialist:  This role is responsible for the QA cycles on all code releases with the exception of catalog updates.  They would be responsible for testing new functionality against the project charter and scope and regression testing existing functionality as needed.  This role should not report through Development Management as a best practice.

Other Cross Functional Groups

 Business Intelligence Staff: The Business Intelligence team produces and manages web analytics, A/B Testing, customer communications (email/text/twitter) and sets the direction for data management and strategy.  Headcount: 1 to 2.

Project Management Office: In addition tot eh business and IT teams, a program manager should be instituted to manage large strategic projects )like site build outs) and handle executive level project status communication.  Additional project leads could be added who would manage smaller projects.  The Business Analyst could report in through this group as well.  Headcount: 1 to 2.

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