3Managing User Profiles
Managing User Profiles
User profiles consist of attributes that you want to track for each user, so time invested in analyzing your audience is well spent.
As you determine your business requirements for personalization, review the standard user profile attributes available and decide if you need to create additional attributes.
This section includes the following topics:
About User Profile Attributes
User profile attributes can include personal information about the user, such as name, address, email address, and hobbies, or a variety of extended information, such as company, industry, position, responsibilities, items purchased, information requested, or service provided.
User profile attributes are configurable. Once modeled, they are available across all channels, whether the user contacts your organization through your Web site, your call center, or any other channel managed through your Siebel system.
About Managing User Profile Attributes
User profile attributes can be either dynamic or persistent, and can be managed in a variety of ways across many channels. The following table lists examples of managing user profile attributes.
Table Managing User Profile Attribute Examples
Channel | For example |
---|---|
Self–administration of a user’s own attributes |
Updating his or her mailing address. These attributes make up the Me user profile. |
A call center agent for customers or others contacting your organization by phone |
A service request. The profile of the:
The You profile is represented by the current contact in the customer dashboard. |
A field or sales representative administering customer or contact profile attributes remotely on a site visit |
Then synchronizing the changes with a corporate database. User profile attributes must be specified exactly as they appear in the business component, and are case sensitive. For example, if |
About Persistent User Profile Attributes
The persistent user profile consists of persistent user profile attributes, both individual and organizational. These attributes are stored in the Siebel database.
Persistent profile attributes exist in the base tables or extension tables of the S_PARTY table.
The persistent profile attributes can be:
Person-based or organization-based. They appear as fields in the Personalization Profile business component.
Present in any S_PARTY-based business component, but the Siebel Personalization Engine loads only those defined in the Personalization Profile business component. All organization-based attribute names start with an
Org.
prefix.
This section contains the following topics:
About Storing Persistent User Profile Attributes
All persistent user profile attributes are stored in the Personalization Profile business component, which has two sets of fields, as shown in the following table.
Table Persistent User Profile Attributes
Field | Description |
---|---|
Person-related |
All person-related fields are based on the S_PARTY table or its extension tables and joins that point to a person's attributes. Examples of such extension tables are S_CONTACT, S_CONTACT_X, and S_USER. The best way to define a new field is to find a similar one in the person-based business components, such as User and Employee, and use it as a prototype. |
Organization-related |
All organization-related fields start with Examples of such extension tables are S_ADDR_ORG, S_ORG_EXT, and S_POSTN. The best way to define a new field is to find a similar one in the organization-based business components, such as Account and Internal Division, and use it as an example. |
Attribute Components Obsolete in Version 7
In version 7 the following attribute components are obsolete:
Contact Profile Attributes business component
Account Profile Attributes business component
Employee Profile Attributes business component
Internal Division Profile Attributes business component
Personalization Profile Business Component Used in Version 7
In version 6, these business components are used to store persistent user profile attributes, but in version 7, the Personalization Profile business component is used instead. Any reference to the user profiles in those business components have to be modified.
Basic information such as name and email address should be stored as persistent attributes. Your business needs will determine what other attributes are important to store from one session to another. In general, the most frequently used attributes are made part of the persistent profile.
Adding New Persistent User Profile Attributes
You can add new persistent user profile attributes by adding columns to the S_PARTY table or one of its extension tables, and then exposing these columns as business component fields. New profile attributes are available after the repository file is recompiled.
Querying for Persistent User Profile Attributes
When you query for persistent user profile attributes in the Personalization Profile business component, it is important to use the Org.
prefix organization-related fields. The following process occurs:
Position the business component to the record corresponding to the person whose attributes are being read.
Read all person-related fields.
Use either the Primary Account Id Internal or Primary Division Id Internal field (whichever is not empty) as an Id field to query for the organization-related fields.
Note: If both the Primary Account Id Internal and Primary Division Id Internal fields are populated, then theOrg.*
fields are based on the Primary Account Id Internal.Because both person and organization records are stored in the S_PARTY table and its extensions, you can use the same business component to query for these fields.
Read all fields with names
Org.*
.
Saving Modified Persistent Attributes
The following table describes saving modified persistent attributes.
Table Saving Modified Persistent Attributes
If... | Then... |
---|---|
Persistent attributes are modified by a user and the session is updated, either directly or by the user’s actions while logged in. |
The modified values are not saved to the database until the session is terminated. This is because the profile attributes are cached. Caching profile attributes allows extremely fast access to them when building pages, while providing persistence between sessions. |
Persistent attributes are modified in an administration screen and saved, for example, by a call center agent using the Profile view under the User Profile Preferences screen. |
The changes are saved to the database at that time. |
GetProfileAttr and Personalization
GetProfileAttr only works for fields explicitly defined in the Personalization Profile business component. GetProfileAttr does not work with system fields, which are not explicitly defined in the business component; it returns a NULL value for them.
The Id system field is an exception. This particular system field was added in order to be available to GetProfileAttr, even though it is not in the Personalization Profile business component.
Retrieving Persistent Attributes
Values for persistent attributes are loaded in the session when a user logs in. Persistent attributes are retrieved using GetProfileAttr()
. For more information on GetProfileAttr()
, see Profile Functions.
About Dynamic User Profile Attributes
Dynamic attributes are created at run time and are not based on any business component fields. They are session specific.
Dynamic attributes are set and modified by actions the user takes while navigating the system, and are never written to the database. They allow real-time modification of the user experience. They are related to the state of the user, as determined when he or she entered the application.
This section contains the following topics:
Dynamic Attributes Set at Run Time
The login process can also automatically enter dynamic attributes. The following table lists the dynamic profile attributes that are set by the system at run time.
Table Dynamic Attributes Set at Run Time
Dynamic Profile Attribute | Possible Values |
---|---|
IsStandaloneWebClient |
TRUE or FALSE |
Is Anonymous |
TRUE or FALSE |
ApplicationName |
Name of the application |
ActiveViewName |
Name of the active view |
About Retrieving Dynamic Attributes
Dynamic attributes are retrieved the same way as persistent attributes, using GetProfileAttr()
. If the attribute is not set (or does not exist) for a given user, it will return nothing, but will not give an error message.
Dynamic profile attributes can be different for each user. When a dynamic profile attribute is set, it exists for that user only. This works because of how dynamic attributes are set and retrieved: no errors occur if an administrator references dynamic attributes that do not exist. If a dynamic profile attribute does not exist and the user sets it, a new one is created.
Dynamic Profile Attribute Examples
The following are examples of the usage of dynamic profile attributes:
GetProfileAttr(AttrDoesNotExist) returns NULL.
SetProfileAttr(NewAttribute,value) creates a new dynamic profile attribute.
About Second User Profiles
The second profile is used if a call center agent wants to personalize the content shown on the screen based upon the caller’s profile instead of the agent’s own profile.
In Web channel interactions, only one party is involved. However, in certain other channel interactions, for example, there are multiple parties involved, for example the call center and the customer agent. In this situation, it is necessary to load a second user profile.
This section contains the following topics:
About Loading a Second User Profile
The following table describes instances of loading a second user profile when the customer profile is open and when the customer is not using CTI.
Table Instances of Loading a Second User Profile
If... | Then... |
---|---|
The customer dashboard is open when the caller contacts the Call Center.
Note: The second profile is loaded if the Call Center agent executes a find for the customer contact and uses the Set Dashboard button to launch the dashboard.
|
The second profile is automatically loaded when the dashboard is set with the user’s credentials. |
Customer is not using CTI.
Note: LoadUserAttributes is exposed for the application object. This function takes only one argument: the row-id of the employee or contract.
|
The customer can write a script or business service to call the function LoadUserAttributes with the contact ID, and use this script to load the second user profile. |
Accessing the Second User Profile
You can access the second user profile with personalization rules by using a you.indentifier. The following table lists examples of accessing the second user profile.
Table Accessing the Second User Profile Examples
This user profile... | Returns... |
---|---|
GetProfileAttr (me.first name) |
The first name of the logged in user |
GetProfileAttr (you.firstname) |
The first name of the second user |
Using Load User Profile Example
The following VB example shows a method that loads a user profile into the session. The function is exposed on the Siebel Application Object.
Function LoadUserProfile As Integer sArgs = "0-10N07" TheApplication.InvokeMethod "LoadUserAttributes", sArgs End Function
This function has only one parameter: the row-id of the person whose profile needs to be loaded.
If this function is called with empty parameters, it unloads the loaded user profile. For example:
Function LoadUserProfile As Integer sArgs = "" TheApplication.InvokeMethod "LoadUserAttributes", sArgs End Function
Personalization Profile Business Component Restrictions
Personalization Profile business component:
All MVG- and join-based fields (except extension table–based fields) are read-only. Flag them accordingly in Siebel Tools.
If adding an MVG field, only its primary value is made visible to the end user.
Do not use any inner joins in the Personalization Profile business component, as it may prevent the business component from being queried correctly.
Do not modify the definitions of the following fields, because they are used to implement Siebel Personalization functionality:
Primary Account Id
Primary Account Id Internal
Primary Division Id
Primary Division Id Internal
Primary Position Id
Do not modify the definitions of the following joins, as they are used to implement Siebel Personalization functionality:
Primary Account
Primary Division
Primary Position
For performance reasons, flag fields in Siebel Tools as read-only whenever possible. This will avoid an attempt to save the record if the corresponding attribute is changed.
For information on working with business components and tables, see Using Siebel Tools.
Performance Considerations
The following figure shows that in Siebel Personalization, a profile attribute consists of a person component and an organization component.
When you implement action sets and events associated with the Personalization profile attributes, consider the following:
It takes two queries to load profile attributes and two queries to save them. One query is for the person, and the second query is for the organization. These attributes are loaded the first time Siebel Personalization accesses a persistent profile attribute.
If only a person's persistent attributes are set, the system will not load and save the organization component of the Personalization profile and vice versa.
Using only dynamic attributes will save two queries on startup and two on exiting, as the persistent profile would not be loaded or saved.
If the user does not modify a persistent profile attribute during a session, then two queries are saved, because nothing is saved to the database.
Working with Multiple Value Profile Attributes
Profile attributes with multiple values are stored as MVGs (Multiple Value Group). You configure them in Siebel Tools as ordinary MVG fields on the personalization profile business component. For more information, refer to Adding New Persistent User Profile Attributes.
This section contains the following topics:
Using MVG Profile Attributes to Improve Searches
Siebel Personalization provides a hook for entering dynamic search specifications on applets and business components. Administrators can use these dynamic search specifications to target the content to the user based on their profile information. Personalization supports MVG attributes in order to extend the profile, which you can use to track information on customers that cannot be captured in single value fields. These attributes could be hobbies, interests, and so on.
About the GetProfileAttrAsList Function
The GetProfileAttrAsList function returns the MVG value as a list. You can also use this function in the EXISTS operator to create the right expressions for matching the MVG profile attributes with content within Siebel applications.
Using GetProfileAttrAsList and the EXISTS Operator
The following table describes using the GetProfileAttrAsList outside and within the EXISTS operator.
Table Using GetProfileAttrAsList and the Exists Operator
If... | Then... |
---|---|
GetProfileAttrAsList is used outside the Exists operator. |
It returns a comma-separated list of the MVG values. For example, if you are using a MVG called State that has the values CA, MA, GA, and CA is primary, then GetProfileAttrAsList (State) would return CA, MA, GA. |
GetProfileAttrAsList is used within the EXISTS operator. |
The function returns the value of the profile attributes in the format expected by the operator. For example, a typical usage of the EXISTS operator in this scenario is EXISTS ([Targeted States] = GetProfileAttrAsList(“State”)). This does a many-to-many match of the MVG Business Component Field Targeted State against the MVG profile attribute State. |
GetProfileAttr and the MVG Profile Attributes
The following describes using the GetProfileAttr function and MVG profile attributes.
Modify the semantics of GetProfileAttr also for MVG profile attributes. So if the GetProfileAttr function is called for an MVG, it returns only the primary value of the MVG.
For example, for an MVG called State, with the values CA, MA, GA, where CA is primary, GetProfileAttr (State) would return CA.
Use the EXISTS operator for matching content with MVG profile attribute.
The following table lists the three potential cases when using EXISTS with a profile attribute.
Table Three Cases of Using EXISTS with a Profile Attribute
In this case... | Expression | Description |
---|---|---|
MVG profile attribute and MVG Business component field |
Expression: |
This expression tests whether any of the states in the MVG profile attribute, State, exist in the BC MVG field Targeted State. |
MVG profile attribute and single value business component field |
Expression: |
This expression tests whether any of the states in the MVG profile match states in the Targeted State single value BC field. |
Single value profile attribute and MVG Business component field |
Expression: |
This expression tests whether single value states in the user profile match states in the MVG Targeted State BC field. |
Exists Operator Usage Scenarios
The following table lists the usage scenarios using the EXISTS operator.
Table Usage Scenarios Using the EXISTS Operator
Usage Scenario | Example | Expression |
---|---|---|
Searching for an MVG field in a business component against an MVG profile attribute. |
A bookseller site wants to recommend books from all the categories that interest a user. A book can belong to multiple categories, that is, book ABC can belong to action, adventure, and history. Similarly, user XYZ is interested in multiple categories of books, that is, science fiction and action. The personalization engine matches user XYZ to all the books that belong to the categories that the user is interested in, including book ABC. This is done by matching the MVG profile field Interest with the MVG field Categories in the products business component. |
Expression: |
Searching for an MVG field in a business component against a single value profile attribute. |
A product is targeted to multiple states and the marketing manager wants to recommend the product to only the people who live in one of the targeted states. |
Expression: |
Searching for a single value field in a business component against an MVG profile attribute (for example, Portfolio Product Id). |
A product is targeted to multiple states and the marketing manager wants to recommend the product to only the people who live in one of the targeted states. |
Expression:
Note: The EXISTS clause is not required when searching for a business component’s single value field against a MVG profile attribute.
|