| Oracle® Real-Time Decisions Base Application Decision Management Applications User's Guide Release 3.1.1 Part Number E28942-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Real-Time Decisions Base Application Decision Management Applications User's Guide Release 3.1.1 Part Number E28942-01 |
|
|
PDF · Mobi · ePub |
This chapter contains the following topics:
Section 2.2, "Introduction to Oracle RTD for Marketing Optimization"
Section 2.4, "Allocating Product Features to Marketing Organization Job Roles"
Section 2.5, "Job Role Oriented Example of Oracle RTD for Marketing Optimization Tasks"
A Day in the Life of the Marketing/Business User
Oracle RTD Decision Manager (DM) provides a collaborative framework for marketers and business analysts to optimize customer experiences by managing the ongoing lifecycle of marketing campaigns, from Planning through Discovery as shown below. While Oracle RTD Decision Manager provides a generic decision management framework to satisfy many use cases, Oracle also provides an out-of-the-box application called RTD for Marketing Optimization. This application provides a quick-start for most marketing organizations.
Description of the illustration dgr_gen.gif
More and more marketers are realizing the value of providing the "right customer experience at the right time" instead of the "right product at the right time." The decision management framework of Oracle RTD Decision Manager supports customer experience optimization by:
Providing a single multi-channel decision framework that optimizes all customer interactions while incorporating corporate goals and KPI's.
Utilizing self-learning predictive models that adapt to changing market conditions. These models support customer interaction decisioning as well as learning, and provide valuable customer intelligence.
Enabling marketers and business analysts to control the campaign process while minimizing reliance on IT.
The rest of this section examines each of the above stages in a campaign's lifecycle in more detail.
Stage 1: Planning
In the Planning phase, marketers collaborate to determine which campaigns are to be created or modified, as well as which customer segments, offers, creative's, channels, slots, slot types and placements are to be used for each campaign.
Oracle RTD Decision Manager ships with a pre-built application that provides a very flexible and robust framework to support your campaign management initiatives. The application is called RTD for Marketing Optimization This application is built upon a Decision Graph paradigm that represents the building blocks, depicted below, that support extremely powerful and flexible marketing and modeling efforts. The Decision Graph is the key real-world component that drives the definition and usage of the Oracle RTD Decision Management application.
Description of the illustration dm003.png
Oracle RTD Decision Manager is unique in that, while the out-of-the-box Decision Graph is immediately useful for most organizations, others may want to modify it to suit their particular decisioning and optimization needs. Moreover, unlike many other decision management applications, Decision Graph objects and their inter-relationships are totally configurable. The Decision Graph is covered in more detail in the last section to this introduction, "The Decision Graph and Tags/Facets". Additional detail is also provided in Section 2.2, "Introduction to Oracle RTD for Marketing Optimization."
During the Planning stage, it is likely that different individuals will collaborate on elements of the campaign.
Description of the illustration dm005.png
Decision Manager's role-based application uses the paradigm of a project to support collaborative efforts associated with defining and managing campaigns. The collaborative nature of creating the campaign begins with the Definition stage.
Stage 2: Definition
In this stage, all of the Decision Graph objects are used in combination with decision and goal arbitration logic to complete the overall decision framework. Decision logic includes choice/offer eligibility and scoring rules as defined and input by the business user. Models and arbitration logic are defined in the Inline Service (ILS). For more information on the ILS, refer to the Oracle Real-Time Decisions Platform Developer's Guide.
As mentioned at the end of the previous section on Planning, Oracle RTD Decision Manager's role-based application uses the paradigm of a project to support collaborative efforts associated with defining and managing campaigns. Projects are used to create or modify campaigns in an offline mode. After changes to a campaign have been completed, a user with the appropriate role and privileges can review the details and commit the project. Committing the project puts the changes into production.
For example, a company may have a number of individuals and departments involved in defining and managing a campaign.
Description of the illustration dm007.png
Marketers will be involved in defining and creating the campaigns and each of their components. Marketers or line-of-business analysts may define and manage eligibility rules associated with choices and offers. Content Managers will define and maintain slots and relationships to content (creatives, images, scripts, and so on). Statisticians will define Tags that will enable broader and higher levels of learnings that can be used for decisioning. For example, learnings from Tags can be used not just to identify that a particular person would be interested in online bill payments, but that they are more likely to convert based on an interest in being productive as opposed to being environmentally aware. Productive and environmentally aware are two different themes that could be used to try to drive the same action. Finally, LOB managers and/or marketing management may have to review and approve changes before the campaign can go into production.
RTD for Marketing Optimization ships with standardized templates to capture metadata that supports most common marketing processes, for example, start and end dates, status (Active, Needs Approval), channel, and so on. If desired, these templates can also be configured to support your own specific needs.
Oracle RTD Decision Manager also supports team collaboration by way of perspectives. A perspective is a view into a subset of your marketing objects of interest, which may vary by role. Each perspective represents a portion of your data that is convenient to view and process as a unit. The previous diagram shows how different users can utilize various perspectives based on their role in the campaign process.
To support ongoing campaign management activities, Oracle RTD Decision Manager provides basic and advanced search capabilities (depicted below) so that users can quickly locate any campaign object they wish to work with. With all of the different campaigns, offers, creatives, treatments, slots, and channels that a marketing department might work with in a given quarter, this search capability dramatically increases user productivity and marketing velocity.
Description of the illustration image010.gif
As the design process continues, an audit capability captures all significant changes and can provide compliance reports which provide the "Who, what, where, and why?"
Oracle RTD Decision Manager also allows users to define and utilize any measurable corporate or LOB goals in the decisioning framework. For instance, as highlighted in the following graphic, marketers or LOB users may attribute marketing priorities to each choice or offer associated with a campaign. It may be determined that newer offers or choices should hold a higher priority over older, established offers to help gain traction in the marketplace.
Description of the illustration dm011.png
Stage 3: Execution
After the campaign is approved, individuals with the appropriate roles or privileges can deploy it into production. At this point, Oracle RTD Decision Manager is now acting as a single decision management framework across one or more channels, depending on your work in the earlier planning and definition stages.
Oracle RTD Decision Manager acts as a key enabler to marketing in that it replaces the old paradigm of sending requests and files to IT. Oracle RTD Decision Manager is integrated with your front and back-end systems and allows marketers and business analysts to collaborate and take control of all campaigns. For instance, if you see that an offer eligibility rule needs to be modified, you can make the required changes and put them into production immediately if you have the necessary privileges.
Stage 4: Optimization
Oracle RTD Decision Manager puts marketers and business analysts in control of the optimization process. Real-time reporting provides feedback that can be used to improve existing campaigns, or can be used during campaign creation. Some changes to optimization logic can be manual via Oracle RTD Decision Manager, while others are provided as out-of-the-box features of the Oracle RTD learning engine. Examples of manual changes include creating and modifying offer-based marketing priorities as well as eligibility and scoring rules.
To summarize, Oracle RTD Decision Manager optimizes your marketing efforts as follows:
Eligibility and scoring rules defined in the Definition phase.
Predictive models which are self learning and adapt to changes in the marketplace.
The incorporation of corporate goals/KPIs in the decisioning process
Real-time campaign and offer performance reports also guide the optimization process and are discussed in the following Discovery stage.
The first three components mentioned above are shown in the following diagram, with an example of an optimized KPI.
Description of the illustration dm015.gif
When a customer visits a web-page being supported by Oracle RTD Decision Manager, the decision logic begins by understanding which offers and choices the customer is eligible for from the universe of choices. These rules were configured in the Definition stage.
Next, predictive models can be used to score the likelihood that the customer will behave in a particular way, for example, click, convert or download. Arbitrating across multiple business goals or KPIs is a balancing act between presenting the most likely offer to be of interest to the customer and the one that has the highest strategic value to the enterprise. Likelihood is a computed score based on Oracle RTD Decision Manager's models, while KPI metrics are prescriptive and agreed upon within or between LOB's.
Rules and arbitration goals were described in the Definition stage. This section now focuses on Decision Manager's self-learning, predictive models. The related topic of Tags and Facets will be discussed in greater detail in the Discovery stage, below. Additional detail can also be found in Section 1.2.2, "Inter-Choice Relationships."
Predictive models are used to determine the likelihood of a particular outcome for each customer. For instance, for each website visitor we can ascribe a unique likelihood that they will click on a certain ad slot or convert. Oracle RTD Decision Manager provides models and associated analytics for every object in the Decision Graph shown below.
Description of the illustration dm003.png
Consequently, decisions can be rendered based on many of the objects shown above. For example, we can use Oracle RTD Decision Manager models to identify the offer, creative, and placement based on the interaction channel.
Many organizations have developed manual, off-line processes for modeling customer behavior. In such cases, it may take weeks to update models to reflect new information and market conditions. This lag can lead to a sub-optimal decision process. Oracle RTD Decision Manager supports optimized decision processes by providing models which are self-learning and require no manual updates. Oracle RTD Decision Manager provides numerous integration options in the event that you desire to use your organization's offline modeling efforts.
Stage 5: Discovery
Oracle RTD Decision Manager provides a wide assortment of real-time reports that help marketers monitor campaign and offer performance. These reports are generated by Oracle RTD Decision Manager's closed-loop adaptive learning capabilities and provide real-time insights that can be used to modify existing campaign tactics, or to develop even more effective new campaigns.
Example reports:
Offer Performance Report - Performance reports show how many times an offer or creative has been presented to a customer, and the current dispositions. In the example below, we can see that we have converted 15% of those customers presented with buying frequent flyer points, while 29% have a stated interest in knowing more." Based on this type of performance, we may decide to extend the end date of this offer until we see drops in acceptance. After we see response decay, we may decide to make the offer inactive.
Description of the illustration dm1.gif
Predictive Driver Report - This report provides actual profiles of customers based on marketing disposition, for example, purchased, abandoned cart, or not interested. We can see below that the previous webpage is an important predictor of a customer showing interest in our offer. Those customers that come from the Where we Fly and TrueBlue webpage are very likely to be interested in our offer.
Description of the illustration dm2.gif
The analytics above represent an automated approach to providing customer insights that can be used to create new and better campaigns as well as modify existing campaigns on the fly as needed. The next section will introduce a new analytical capability in Oracle RTD Decision Manager that allows marketers to take the customer experience to the next level.
The Decision Graph and Tags/Facets
Leading companies seeking a competitive advantage, want a granular understanding and control over the whole user experience so that the various elements composing a cross-channel dialog can be even more targeted and relevant than before. This fundamental shift in managing the customer experience requires a new approach to analytics, based on understanding how the various elements of the user interaction relate one to the other. This change of focus has a critical impact on your analytics requirements as a one dimensional targeting approach for matching customers with offers will not address the need to optimize multiple dimensions at once. To address this, Oracle RTD Decision Manager's analytical engine can record and identify the characteristics of the customer interactions that are associated with success (say click or offer acceptance) across all dimensions associated with the Decision Graph (shown below).
Description of the illustration dm003.png
(Remember, the standard Decision Graph shown below can be configured for your organization's specific requirements.)
A website visit example illustrates how Decision Manager using a Decision Graph can work in real life.
You login to your bank account and see a nice picture of bear cubs on a forest background with a punchy banner stating "Please give us back your share of the 20,000 tons of paper associated with your account statements." This represents a call to action to sign up for electronic bill payment on the "recommended for you" section of the login page. You decide to click on the "sign-up" link.
Oracle RTD Decision Manager's Decision Graph has recorded the fact that your customer profile is positively associated with "positive responses" to marketing messages in the following context:
Channel (Web)
Offer / Product (Electronic Bill Payment)
Creative (The Bear Cub image)
Tags (Environmental, Wildlife, Donation, Provocative)
Slot Type (Image)
Slot (Recommended for you)
Placement (Login Page)
As predictive models are attached to the Decision Graph, this means that such a business event updates many predictive models that marketers can now use for reporting and to refine customer interaction processes.
You can now generalize the idea and imagine that this graph collects information about all marketing events across all channels. This provides everyone involved in the customer experience (marketing, content managers, LOB mangers, etc.) with an analytical system that has discovered the relationship between the different facets of user interactions. This understanding can then be used to drive strategic competitive advantage and enhance customer loyalty.
With the Decision Graph:
Marketing stakeholders will learn about customer segments that are receptive to eco-centric marketing messages and which customers in the right context will step out of their standard routine (why they came to web site in the first place) to positively respond to specific offers.
Web user experiences stakeholders will learn about which type of marketing messages are appropriate and for whom at the start / at the end or throughout a logged-in web session.
Content owners can focus their digital agencies on the most effective creative themes as they will be able to correlate response rates based on associated tags or facets.
The company as a whole will have learned who is receptive, in this example, to eco-centric marketing messages when displayed in a given context of a secured dialog; a dialog from which it will be in a position to dynamically tailor user experiences across channels based on such empirical evidence.
Models at the Tag/Facet level will often provide more mature and usable models before models at the product or offer level. This allows the interaction to go beyond rules and use models faster than interaction based on product-only outcomes, thus, providing increased relevance and a better customer experience.
The bottom line is that companies need analytical systems that operate at multiple levels of the Decision Graph if they want to delight their customers with relevant customer experiences.
This section contains the following topics:
In general, Oracle RTD can help improve the real-world business processes of any organization, particularly when the organization follows the stages of a decision management optimization program. Business users define a Decision Graph of their marketing objects of interest and the inter-relationships between the objects - see Figure 2-2 for the objects and relationships defined for the Oracle RTD Decision Management application.
The Decision Graph is the key real-world component that is defined in the Oracle RTD Decision Management application. The Decision Graph is defined in the Decision Management application, and describes the object types (for example, Campaign, Offer). Business users will then create and manage object occurrences (such as April Discount Campaign, Grand Opening Offer) when they use the running Decision Management application, as shown in Figure 2-1.
The rest of this section explores the objects and features of the Oracle RTD Decision Management application in more detail.
Figure 2-1 Application for Decision Management Projects
Decision Graph Choices and Relationships
In any marketing organization, there can be many requirements to take into consideration when determining what is "the best" offer to present to a given customer. Depending on the scope of the products and services that are being marketed, there could be a considerable number of types and categories of offers, as well as the actual products and services being offered, and in what campaigns. There could also be a number of different ways that these offers could be presented and displayed to customers on web pages, as part of the marketing campaigns.
The Oracle RTD Decision Management application RTD for Marketing Optimization uses the following Decision Graph objects of interest:
Figure 2-2 Marketing Objects of Interest and Inter-Relationships
The relationships are represented by the arrowed lines, according to the following conventions:
In lines with a single arrow, the direction of the arrow indicates a one-to-many relationship. Double arrow lines represent many-to-many relationships.
A solid line represents a mandatory relationship, and a broken line represents an optional relationship
So, for example (with the relationships described as generically as possible):
Each campaign consists of zero, one, or more offers
Each offer must belong to exactly one campaign
Each offer consists of zero, one, or more creatives
A creative can be thought of as specific content used to deliver an offer. For example, text content and image content could be two types of creative for the same offer.
Each creative can have zero, one or more tags, and each tag may be associated with zero, one or more creatives
Each channel may be related to zero, one, or more creatives
Each creative must belong to exactly one offer and must be associated with exactly one slot type
Each creative may be associated with one (and only one) channel, but does not have to be
In addition to the choices that are the key components of any Decision Management application, business users must also decide on which data the choices are to based, such as details of customers and their preferences, together with the rules and decision logic to determine the best choice recommendations in the business applications.
Defining the Decision Management Application Components and Interactions
The definition of all the Oracle RTD components to serve customer business applications is achieved through two components, the Oracle RTD Inline Service and the Oracle RTD Decision Management system.
The main Oracle RTD interactions are shown in Figure 2-3, and referenced in this and later sections.
Figure 2-3 Overview of Main Object interactions for Decision Management Applications
In step 1 in Figure 2-3, the data sources, the entities, the decision logic, choice groups, and prediction models are defined in an Oracle RTD Inline Service. For the Inline Service associated with RTD for Marketing Optimization, there is a choice group defined for each of the separate objects (Campaign, Tag, Channel, and so on) shown in Figure 2-2.
The Inline Service does not explicitly define the relationships between the choice groups, but it does include the logic that accomplishes the (subsequent) automatic updating of all models that are based on choices that are related.
The relationships between the choice groups are defined in a Oracle RTD Decision Manager application (see step 2 in Figure 2-3). The Oracle RTD Decision Manager application is always associated with the Inline Service that has been set up and deployed in step 1 in Figure 2-3. For the Inline Service associated with RTD for Marketing Optimization, the choice relationships are all the inter-object connections shown in Figure 2-2.
At this stage, designers also decide how to make the choices visible and available to different groups of users. This is achieved through perspectives and security permissions.
For more information about perspectives, see Section 2.2.2, "Oracle RTD for Marketing Optimization Perspectives." For more information about security permissions, see Section 2.4, "Allocating Product Features to Marketing Organization Job Roles."
After the Oracle RTD Decision Manager application is generated (step 3 in Figure 2-3), users can begin to enter their choices, choice rules, and choice relationships.
Creating Inter-Related Choices and Rules
In an Oracle RTD Decision Manager application, users create their choices, choice rules, and choice relationships in work units called projects (step 4 in Figure 2-3). Projects can also include modification and deletion of existing choice data and their rules and relationships.
After each project is committed (step 5 in Figure 2-3), all the changes made in that project (that is, all the new, modified, and deleted choices, choice eligibility rules, and choice relationships), are transferred on an automatic, periodic basis, to the Inline Service (step 6 in Figure 2-3).
The models defined in the Inline Service that are associated with each of the related choices are updated - in effect, the models become inter-related models.
Optimizing the Recommendations
The inter-related models can now optimize the recommendations for the applications that use the Inline Service (step 7 in Figure 2-3).
Through reports available in Decision Center and Decision Manager, business users can discover new insights that enable them to optimize their business processes. They may create new Decision Management projects, to continue the process of adding new choices, choice eligibility rules, and choice relationships, and modifying their existing choice data (step 8 in Figure 2-3).
A perspective is a subset of your marketing objects of interest, which also shows how they are inter-related. Each perspective represents a portion of your data that is convenient to view and process as a unit.
For each object, designers may decide whether all the objects of a particular type are to be available (for example, all campaigns) or a subset of a type (for example, only the campaigns whose approval status is Draft).
The perspectives defined in the RTD for Marketing Optimization application consist of four "general" subsets of data and three "filtered" subsets.
The four "general" views, with no qualifying conditions on any object, are as shown in the following diagram:
The following diagram shows examples of the four general perspectives, as displayed in Decision Manager:
Figure 2-4 Examples of General RTD for Marketing Optimization Perspectives
The following diagram shows the three "filtered" perspectives, each of which is similar to the Campaigns perspective, except that each filtered perspective only exposes the campaigns with a particular approval status:
Users can be granted permissions to work on different perspectives. In this way, perspectives can be designed and directed towards particular functional roles in your organization. For a possible function-to-job-role breakdown in a marketing organization, see Section 2.4, "Allocating Product Features to Marketing Organization Job Roles."
Terminology:
The general terms used throughout this section and other sections to cover all the marketing objects of interest are choices and choice groups.
So, campaigns, offers, channels are all different choice groups.
An individual Deep Discount campaign and an offer called Sixty-Percent-Off-Everything are examples of specific choices.
General Note:
This section contains a combination of general choice management options and examples oriented to the choices available in RTD for Marketing Optimization.
The convention used in this section is that the general descriptions appear in standard font, while the examples and descriptions oriented specifically to RTD for Marketing Optimization appear in italics.
More general information is also available in Appendix A, "Decision Manager User Interface Schematic."
For each of the operations listed in this section, it is assumed that you have been granted the correct permission or permissions by your Oracle RTD Decision Management administrator to perform that operation.
For general information about the layout of the user interface screens and screen areas, see Section A.1, "Decision Manager User Interface Schematic."
A Decision Management application can be set so that either multiple users can update a choice, or users can operate in a special "ownership=on" mode, which is basically a "single-user-update" mode.
In this mode, there is a provision for users who are granted the special "own" permission, such as system administrators or managers, to be able to override the single user mode and perform choice updates. In this "ownership=on" mode, the choices appear with an extra attribute Owner.
The following scenario includes the implicit provision that two different departments/users can edit the same choice. Decision Management application designers can set up applications either to allow multi-user updating of the same choice, or to enforce single-user update mode of a choice.
For more information on ownership, see the section "Config XML File" in Oracle Real-Time Decisions Base Application Decision Management Installation and Configuration Guide.
This section contains the following topics:
Section 2.3.4, "Viewing, Searching and Adding Audit Trail Information for Projects"
Section 2.3.5, "Viewing, Searching and Adding Main Repository Audit Trail Information"
Section 2.3.10, "Viewing, Searching and Adding to Choice Audit Trail Comments"
Note:
A project is a unit of work processing, that stores a set of pending changes to the Main Repository.
The Main Repository is the database containing the dynamic choices that may be accessed by and used for processing Oracle RTD decisions in customer applications. This set of choices is updated each time a project is committed.
You can create, edit, and delete choices in a project. While recorded as significant actions within the project, these pending changes will only take effect in the Main Repository when you commit the project. If you discard the project (also known as deleting the project), all the changes in that project are discarded.
[For general information about creating projects, see Section A.7, "Create Project."]
Your context can be either Main Repository or an active project.
Click New Project.
Note:
If you do not see the New Project icon, either expand your Decision Manager window, or click the chevron to the left of "Search" near the top of the screen, and select New Project from the dropdown list that appears.
In the Create Project window, enter the project Name and optionally Description and Audit Trail Comment.
Type is a required field. You can either leave the default value Incremental Changes or select another value.
Click OK.
After the project is created, the context is automatically switched to the new project, as displayed in the View box, and appears as an active project in the View Projects page.
[For general information about viewing projects, see Section A.9, "View Projects."]
The standard way to access and view projects and project details is through the View Projects.
Note:
If you do not see the View Projects icon, either expand your Decision Manager window, or click the chevron to the left of "Search" near the top of the screen, and select View Projects from the dropdown list that appears.
In both the Active Projects and Committed Projects areas, you can:
Customize project searches by clicking the appropriate View button, then selecting, suppressing or reordering the project search columns that appear.
Search for projects by entering search parameters in the empty boxes above the column names, then clicking the Execute button (green arrowhead) or Enter.
If the search boxes are not visible, click the Query By Example (wineglass) icon.
For search parameters, asterisk ("*") acts as a leading wild card, and there is no need to specify a trailing asterisk. So, for example:
The two character search string *c searches for values that contain the letter "c"
The search string *c*es searches for values that contain "c" and later "es"
You can also click on the Audit Trail icon for any active or committed project, to view and search the audit trail comments for that project.
To edit a project, select an active project in the View box of the Main Repository/Project context area, then click the Details button in the same area. The details screen for the project will include an Edit button.
In the Project Details area, you can edit the project attributes and add an audit trail comment.
There are two ways to access audit trail information for projects:
Click the Audit Trail icon for either an active or a committed project in the View Projects page.
With an active project selected in the View box in the Main Repository/Project context area, click the Audit Trail button in that area.
In both cases, this displays the Project Audit Trail area. In case 1, a blue back-arrow icon appears among the icon options, to enable returning to the View Projects page.
In the Project Audit Trail area, you can:
Customize searches by clicking the View button, then selecting, suppressing or reordering the project audit trail search columns that appear
Search the audit trail by entering search parameters in the empty boxes above the column names, then clicking the Search (green arrowhead) icon.
If the search boxes are not visible, click the Query By Example (wineglass) icon.
Note:
You can search for audit trail comments on particular choices and choice groups by entering search parameters for Choice Id and Choice Group Id respectively.
For search parameters, asterisk ("*") acts as a leading wild card, and there is no need to specify a trailing asterisk. So, for example:
The two character search string *c searches for values that contain the letter "c"
The search string *c*es searches for values that contain "c" and later "es"
You can also add an audit trail comment by clicking the green Plus icon and entering your comment. This comment will be associated with the current project.
If you reached the Project Audit Trail area from the View Projects page, you can return to the View Projects page by clicking the blue back-arrow icon.
You can access Main Repository audit trail information for all choices in previously-committed projects by clicking the Audit Trail button in the Main Repository/Project context area, when the View box contains the option Main Repository.
In the Project Audit Trail area, you can perform and customize searches as described in Section 2.3.4, "Viewing, Searching and Adding Audit Trail Information for Projects."
You can also add an audit trail comment by clicking the green Plus icon and entering your comment. This comment will be associated with the Main Repository.
If you have the necessary permission, you can commit a project. Committing a project will transfer all the pending choice changes in that project to the Main Repository.
To commit a project, select the project from the dropdown View list in the Main Repository/Project context area, then click the Commit button, and confirm that you want to commit the project. You may optionally enter an audit trail comment in the confirmation box.
After the project is committed, the context is automatically switched to the Main Repository, as displayed in the View box.
If you click View Projects, the newly-committed project appears in the Committed Projects area. You can click the Audit Trail icon for the project to see a list of all the operations that occurred when the project was active, and the users that performed those operations.
If you have the necessary permission, you can discard a project, which discards all changes in the project.
To discard a project, select the project from the dropdown View list in the previously-committed projects by clicking the Audit Trail button in the Main Repository/Project context area, then click the Discard button, and confirm that you want to discard the project. You may optionally enter an audit trail comment in the confirmation box.
After the project is discarded, the context is automatically switched to the Main Repository, as displayed in the View box.
[For general information about creating choices, see Section A.10, "Create Choice."]
Note:
When you create a choice in a project, the choice does not get added to the Main Repository until you commit the project. You can undo the choice creation in the project before you commit the project by discarding the newly-created choice, as described in Section 2.3.8.1, "Discarding Choice Additions in a Project."
Click the Create icon (in the header of the current perspective panel), and select one of the options from the dropdown list.
Note:
If you do not see the Create icon, either expand the Decision Manager window or the Perspective Panel area.
In the Overview dialog, enter the Name, and optionally a Description.
The following shows a Create Campaign example:
In addition to the name, you may have to select attribute values for choices related to the current choice. Mandatory values are marked with an asterisk.
If your choice group is in a many-to-many relationship, you may select one or more choices from an Available list into a Selected list.
For example, Creatives must belong to exactly one Offer, must have a Slot Type, may be associated with a Channel, and may also be associated with one or more Tags.
During the creation of a Creative choice you must select values for Offer and Slot Type (the fields for this are marked with an asterisk). You may select a Channel and one or more Tags at this point, or you can add Channel and Tag values in later edit sessions.
The following shows an example of creating a Creative by adding it to an Offer and a Slot Type :
Click Next to proceed to the Attributes dialog.
Default values may appear in some of the fields in the Attributes dialog.
In the Attributes dialog, enter or select values for all mandatory fields (marked with an asterisk), and as many of the optional fields as you require.
Click Next to proceed to the Rules dialog.
In the Rules dialog, optionally enter the rules for your choice in the Rule Editor frame that appears.
For detailed information about entering rules, see Section 12.10, "Using Rule Editors" in Oracle Real-Time Decisions Platform Developer's Guide.
The following shows an example of a rule added to a Campaign, specifying that the Code must not be equal to XXX:
If you want to create choices that are related to your newly created choice, you can perform the following operations, either in the same session or in later sessions:
Repeat the complete process described in this section, selecting the new choice to create when you click the Create icon described in step 1.
Click the special "Add ..." buttons that appear in the details screen for your newly created choice, then perform steps 2 to 7 as described in this section. Specifically, the first step to perform is one of the following:
In the Campaign details screen, click Add Offer
In the Offer details screen, click Add Creative
In the Tag details screen, click Add Creative
In the Channel details screen, click Add Creative or Add Placement
In the Placement details screen, click Add Slot
In the Slot Type details screen, click Add Creative or Add Slot
The following shows an example of the Choice details area after the successful creation of a Slot Type:
When you are working in a project, you can discard the choice that you created in the project, before the project has been committed to the Main Repository - in effect, this "deletes" the choice from the project. This option is known as Discard Addition.
To discard a choice that was added in a project, first access the choice as described in Section 2.3.9, "Viewing and Searching for Choices." The details screen for the choice will include a Discard Addition button.
The following shows a details screen example for a campaign HM Campaign:
Click the Discard Addition button, then confirm that you want to discard the choice addition from the project. You may optionally enter an audit trail comment in the confirmation box.
You cannot discard an addition if it is linked to other choices in a required relationship.
For example:
If a campaign has been created, and an offer added to the campaign, you cannot discard the addition of the campaign first. You can discard the offer addition first, then the campaign addition.
The relationship between tags and creatives is not mandatory - a tag does not have to be linked to a creative, nor does a creative have to be linked to a tag. So, if you have created a tag addition and related it to a creative, you may discard the addition of the tag.
Note:
After a choice addition is discarded in a project, you can still view audit trail information about the choice through the project audit trail. For details, see Section 2.3.3, "Editing Projects."
The standard ways to access and view choices and choice details are either through perspectives or by searching for choices.
Note:
You must have the necessary permissions to view and search for choices. For more information of how these are configured, see the section "Security XML Files" in Oracle Real-Time Decisions Base Application Decision Management Installation and Configuration Guide.
Using perspectives, you can expand choice hierarchies in the Perspectives panel tree, or select other perspectives and explore their choice tree structure in the Perspectives panel. When you click a choice in the Perspectives panel, and then the Definition tab, this will display the choice details in the main body of the Decision Manager window.
You can search for your choice or choices using one or more of the Search options described in Section A.5, "Search Options Area." If your application is in the special mode "ownership=off", then a basic search searches on name and description. In "ownership=on" mode, the basic search is on name, description, and owner.
The search takes place in the context of either the Main Repository or an active project, as appears in the View box near the top left of the screen:
A search in an active project context will search in both that project and the Main Repository
A search in the Main Repository context will search in only the Main Repository
After a successful search, the resulting choices appear in the Search Results panel. You can click any choice there to display the details in the main body of the Decision Manager window.
The following shows an example of the search results for the word "Image" in Creative names and descriptions, in the context of the active project DD Prospect:
The second result contains "Image" directly in the Creative name. The first result has "Image" only in the Creative description, which appears if you mouse-hover over the Creative name.
As both search results appear in standard font, this indicates that they were found in the Main Repository (any objects found in the project DD Prospect would have appeared in red italics).
You can also view audit trail information for choices - see Section 2.3.10, "Viewing, Searching and Adding to Choice Audit Trail Comments."
You can view audit trail information for choices in two ways:
You can view audit trail information for choices directly from the choice details screen, by clicking the Audit Trail tab for the choice.
The following shows an example of the Audit Trail tab just after the creation of a campaign HM Campaign, showing all the audit trail columns:
The audit trail search options are similar to those described in Section 2.3.4, "Viewing, Searching and Adding Audit Trail Information for Projects."
If you add an audit trail comment from the choice Audit Trail tab, it is automatically associated with the current choice in the choice details area.
You can view audit trail information for choices indirectly, by viewing project audit trail information, then using choice information as a search parameter in the Project Audit Trail tab. For more details, see Section 2.3.4, "Viewing, Searching and Adding Audit Trail Information for Projects."
Note:
When you edit a choice in a project, either a newly created choice or a choice that exists in the Main Repository, all the changes you make are within the project only - they do not reach the Main Repository until you commit the project.
To change a newly created choice, you simply edit the choice. This you can do many times before project committal. If you want to prevent the new choice from going to the Main Repository, you discard the choice addition, as described in Section 2.3.8.1, "Discarding Choice Additions in a Project."
You can also edit a Main Repository choice many times before project committal. If you want to undo all the changes made to that choice in the project, you discard the choice changes, as described in Section 2.3.11.1, "Discarding Changes to a Main Repository Choice."
To edit a choice, access the choice as described in Section 2.3.9, "Viewing and Searching for Choices." The details screen for the choice will include an Edit button.
Click the Edit button.
The following shows an example of the Overview tab for a campaign HM Campaign, ready for editing:
The following shows the Attributes tab for the HM campaign, ready for editing:
You can edit the choice name and attributes in the Overview and Attributes tabs respectively, and the rules for the choice in the Rules tab.
For detailed information about editing rules, see Section 12.10, "Using Rule Editors" in Oracle Real-Time Decisions Platform Developer's Guide.
When you have finished, click OK.
When you are working in a project, you can edit Main Repository choices. Before you commit these changes to the Main Repository, you may decide to undo the changes you made in that project - this will revert the choice back to its original Main Repository version. This option is known as Discard Changes.
To discard a change to a Main Repository object, first access the choice as described in Section 2.3.9, "Viewing and Searching for Choices." The details screen for the choice will include a Discard Changes button.
The following shows an example of the details screen for a Customer Acquisition Campaign, that exists in the Main Repository, but has just been edited in the project DD Project:
Click the Discard Changes button, then confirm that you want to discard the changes made in the project. You may optionally enter an audit trail comment in the confirmation box.
To delete a choice from the Main Repository, you must first be working in an active project. You may have edited the choice in that project or not.
In the project, you effectively prepare to delete a choice. As with all changes in a project, the actual choice deletion does not occur in the Main Repository until you commit the project. For example, you may decide to undo your choice deletion before you commit the project (see Section 2.3.12.1, "Discarding Deletions").
To start the process of deleting the choice from the Main Repository, first access the choice as described in Section 2.3.9, "Viewing and Searching for Choices." The details screen for the choice will include a Delete button.
The following shows an example of the details screen for a Customer Cross Sell Campaign, that has not yet been edited in the project DD project:
The following shows an example of the details screen for a Customer Acquisition Campaign, after it has been edited in the project DD project:
Click the Delete button, then confirm that you want to delete the choice from the Main Repository. You may optionally enter an audit trail comment in the confirmation box.
The choice deletion does not occur in the Main Repository until the project is committed. The final net effect of an undiscarded delete after the project is committed depends on the configuration of the relationships with other choices:
For relationships that are "orphan delete", related choices are not deleted, and only the selected choice is deleted
For relationships that are "cascade delete," then an attempt will be made to delete the choice and all lower-level related choices (as, for example, deleting a campaign will attempt to delete all of its offers, and all creatives under those offers). If any of the choices in the cascade delete hierarchy is locked in another project, the delete will fail. If any of the choices in the cascade delete hierarchy is owned by any other user and you do not have "own" permission on that choice, the delete will fail.
For more information on delete options, see the section "Choice Groups and Relationship Types XML Files" in Oracle Real-Time Decisions Base Application Decision Management Installation and Configuration Guide.
If you have signalled your intention to delete one or more choices from the Main Repository, as described in Section 2.3.12, "Deleting Choices from the Main Repository," you can undelete or discard pending choice deletions through the Project Changes panel.
Click the Project Changes bar, to expose the changes you made in the project. The choice deletions appear as red, crossed-out choice names.
To discard a deletion, click the crossed-out choice that you want to undelete. The details window that appears has a Discard Deletion button.
The following shows an example of the Project Changes panel for the project RN12, where two choices, P1 Camp and VX Campaign have been marked for deletion, and the VX Campaign has been selected for undeletion.
Click the Discard Deletion button.
The choice disappears from the Project Changes panel, and is available once again as a standard unedited choice in all appropriate perspectives.
Note:
If you deleted many choices at once as part of a cascade delete, you have to discard the choice deletions one by one, starting with the highest-level choices. For instance, if you deleted a campaign and it deleted offers and creatives under it, first discard the campaign deletions, then the offer deletions, then the creative deletions.
While each marketing organization has its own unique departmental structure, this section illustrates one possible way by which you can allocate the tasks available for RTD for Marketing Optimization users to job roles in a marketing organization.
The basic principle is that individual users are allocated specific permissions, at several levels: perspective, project, choice group, and choice view page. Without the right permissions, you will not be able to perform particular tasks on particular objects in the application.
The details of setting up permissions are not described in this manual, but the basic principles indicate how these permissions could be used in the process of allocating tasks to job roles (for more information about how permissions are configured, see the section "Security XML Files" in Oracle Real-Time Decisions Base Application Decision Management Installation and Configuration Guide).
The basic types of permission are as follows:
Perspective level
You must have View permission on a perspective to see the perspective. You will need further permissions if you want to create, update, or delete choices in a perspective.
Choice group level
For any choice group, you need individual Read, Create, Update, and Delete permissions to perform the associated view, create, update, and delete tasks on a choice of that particular choice group.
Project level
The individual permissions at the project level are Create Project, Update Project, Discard Project (this allows you to delete a project, and all the changes in that project), Commit Project (this allows you to commit the project changes to the database).
Choice view page level
There are page permissions for each of the pages for a choice group for each of the options view, edit, and create, therefore each of the pages available when creating, viewing, and editing choices requires a page permission. You must also have the choice group level permissions to see these pages.For instance, to see an "Attributes" create page, you must have both create permission on the choice group and create permission on the "Attributes" page.
Assume that there are four departments concerned with the overall process of creating and committing projects to add choices to your database:
Administration
Responsible for setting up and managing RTD for Marketing Optimization projects
Marketing
Responsible for setting up and managing choice content for the RTD for Marketing Optimization projects
Display Control
Responsible for setting up and managing the layout of the external sites that display choice information
Approvals
Responsible for changing the approval statuses of choices
An example of the breakdown of the permissions for particular organization roles could be as follows:
Note:
The following scenario includes the implicit provision that two different departments/users can edit the same choice. Decision Management application designers can set up applications either to allow multi-user updating of the same choice, or to enforce single-user update mode of a choice. For more details, see the "ownership" option in the section "Config XML File" in Oracle Real-Time Decisions Base Application Decision Management Installation and Configuration Guide.
The example here assumes that different users (in effect, different departments) can edit the same choice.
The Administration department users will have the following permissions:
Create Project, Update Project, Discard Project, Commit Project
Read, Create, Update, and Delete permissions on all the choice groups
Permissions to perform all actions on all choice view pages
The Marketing department users will have the following permissions:
View permissions on all the perspectives
Read, Create, Update, and Delete permissions on the choice groups Campaign, Offer, Creative, and Tag
Permissions to perform all actions on all Campaign, Offer, Creative, and Tag choice view pages
The Display Control department users will have the following permissions:
View permissions on the perspectives Channels, Slots by Slot Type, and Creatives by Slot Type
Read, Create, Update, and Delete permissions on the choice groups Slot, Slot Type, Channel, and Placement
Update permission on the Creative choice group
Permissions to perform all actions on Slot, Slot Type, Channel, and Placement choice view pages
View and update permissions on the Creative choice view pages
The Approvals department users will have the following permissions:
View permissions on the perspectives Draft Campaigns, Pending Approval Campaigns, and Approved Campaigns
Read and Update permissions on the choice groups Campaign, Offer, and Creative
View and update permissions on the Campaign, Offer, and Creative choice view pages
This section illustrates the use of some RTD for Marketing Optimization tasks, following the example of job roles and permissions described in Section 2.4, "Allocating Product Features to Marketing Organization Job Roles."
As an example, assume that the ZaxisZen Corporation wants to expand its core business of marketing large-site properties by running a test Showcase Properties campaign on the West Coast.
The ZaxisZen application design team has allocated the permissions to their specific ZXS department users as outlined in general in Section 2.4, "Allocating Product Features to Marketing Organization Job Roles," and has created the following outline specifications for how the project and choice tasks are to be performed using RTD for Marketing Optimization:
ZXS_Administration department (Login user clmadmin)
Create the Web Offers Rollout (WORP) project
ZXS_Marketing department (Login user clmadmin2)
Create Campaign Showcase Properties, with a rule that the end date is to be no later than June 28, 2013
Create Offer Regional Offers
Create Creative West Coast Properties, with slot type 200x400.
Set the approval status of all three choices to Draft
ZXS_Display_Control department (Login user clmauthor)
Create Slot Type 300x600
Update Creative West Coast Properties, setting slot type to 300x600
ZXS_Approvals department (Login user clmauthor2)
View the Draft campaigns perspective, and update the campaign Showcase Properties, changing the approval status to Approved
ZXS_Administration department (Login user clmadmin)
Commit the Web Offers Rollout (WORP) project changes
(Optionally, view audit trail information for Web Offers Rollout Project)
The rest of this section contains the following topics:
To set up the project, a ZXS_Administration department user (for example, clmadmin) logs into RTD for Marketing Optimization, and then performs the following steps:
Click New Project.
Enter the Name and optionally a Description for the project.
Click OK.
The View box shows the new active project, which also appears in the View Projects page.
To create the Showcase Properties campaign, a ZXS_Marketing department user (for example, clmadmin2) logs into RTD for Marketing Optimization, and then performs the following steps:
For the View, select the project Web Offers Rollout Project.
Click the Create icon, and select Campaign.
Stage 1: Overview
In the Overview screen of the Create Campaign page, enter the Name for the Showcase Properties campaign.
Click Next.
Stage 2: Attributes
In the Attributes screen of the Create Campaign page, enter the campaign details for the Showcase Properties campaign, selecting Draft for the Approval Status.
Click Next.
Stage 3: Rules
The Rules screen appears, displaying the Rule Editor.
In this screen, set up the rule that the campaign End Date is to be less than or equal to June 28, 2013, as follows:
Click the Add Rule (leftmost) icon in the Rules Editor toolbar.
Click the ... button in the first box, then select Attribute, End Date, and click OK.
Click the "=" operator and change it to "<=".
Click the ... button in the second box.
Select Constant, then Data Type = Date.
Select June 28, 2013 in the Date window.
For Display As, select Date only.
Click OK.
The full condition appears in the Rule Editor.
Click Next.
Stage 4: Confirm
The Confirm screen appears.
Click OK.
The newly-created campaign Showcase Properties appears in the left-hand perspective panel, in red italics. The main body of the screen shows the campaign Overview page.
To create the offer Regional Offers, the ZXS_Marketing department user continues by performing the following steps:
Click Add Offer.
Enter the Name Regional Offers.
Click Next.
Enter details for the Offer Regional Offers, setting the Approval Status to Draft.
Click Next twice, then OK, to complete creating the Offer Regional Offers.
To create the West Coast Properties creative, the ZXS_Marketing department user continues by performing the following steps:
Click Add Creative.
Enter the Name West Coast Properties, select 200x400 for the SlotType and Services for the Tag.
Click Next.
Enter details for the Creative West Coast Properties, setting the Approval Status to Draft.
Click Next twice, then OK, to complete creating the Creative West Coast Properties.
To create a new slot type and update the West Coast Properties creative, a ZXS_Display_Control department user (for example, clmauthor) logs into RTD for Marketing Optimization, and then performs the following steps:
For the View, select the project Web Offers Rollout Project.
Create Slot Type 300x600
Click the Create icon, and select SlotType.
Enter 300x600 for the Slot Type Name.
Click Next twice, then OK, to complete creating the Slot Type 300x600.
Change Slot Type of West Coast Properties to 300x600
To change the slot type of the West Coast Properties choice, first click the West Coast Properties choice in the left-hand perspective panel.
Click Edit, then select 300x600 for the SlotType.
Click OK.
To approve the Showcase Properties campaign, a ZXS_Approvals department user (for example, clmauthor2) logs into RTD for Marketing Optimization, and then performs the following steps:
For the View, select the project Web Offers Rollout Project.
For the perspective, select Draft Campaigns, then Showcase Properties.
Click Edit, select the Attributes tab, then change the Approval Status to Approved.
Click OK.
The Showcase Properties choice now does not appear in the Draft Campaigns perspective panel.
To check that it does appear in the Approved Campaigns perspective panel, select the Perspectives icon, then Approved Campaigns.
The Showcase Properties choice now appears in the Approved Campaigns perspective panel, with the choice details confirming that the Approval Status is Approved.
To commit the project, a ZXS_Administration department user (for example, clmadmin) logs into RTD for Marketing Optimization, and then performs the following steps:
For the View, select the project Web Offers Rollout Project, then click Commit.
After you confirm the Commit, the project is committed to the Main Repository, the View changes to Main Repository, and the newly-committed project appears in the Committed Projects area of the View Projects page.
To see a history of all the operations performed in Web Offers Rollout Project, click the Audit Trail icon for the project.
The Audit Trail for the project displays which operations were performed on which choice, and by which user.
|
 Copyright © 2011, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
