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