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:

  • Call center agent profile is the Me profile.

  • Customer for whom the agent is managing the attributes is called the You profile.

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 Channel is the correct user profile attribute, it must not be spelled channel.

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 Org. and are based on the S_PARTY table or its extension tables and joins that point to an organization's attributes.

    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:

            Note: A similar process occurs when persistent user profile attributes are saved, for example when exiting the application.
            • 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 the Org.* 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.

                    Note: Do not name a dynamic profile attribute Id, as this system field generates a run time error.

                    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.

                        Note: The ActiveViewName profile attribute is set after the user has been navigated to the view.

                          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.

                                    Personalization Profile

                                    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: EXISTS ([Targeted State] = GetProfileAttrAsList("State"))

                                            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: EXISTS ([State] = GetProfileAttrAsList("State"))

                                            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: EXISTS ([Targeted State] = GetProfileAttr("State"))

                                            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: EXISTS ([Categories] = GetProfileAttrAsList( ))

                                              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: EXISTS ([Categories] = GetProfileAttrAsList("Interests"))

                                              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: [Product Id] = GetProfileAttrAsList ("Portfolio Product Id"))

                                              Note: The EXISTS clause is not required when searching for a business component’s single value field against a MVG profile attribute.