Next-Best-Action Marketing

Next-Best-Action Marketing 7.12 USER GUIDE

Copyright 2014 Pegasystems Inc., Cambridge, MA All rights reserved. This document describes products and services of Pegasystems Inc. It may contain trade secrets and proprietary information. The document and product are protected by copyright and distributed under licenses restricting their use, copying, distribution, or transmittal in any form without prior written authorization of Pegasystems Inc. This document is current as of the date of publication only. Changes in the document may be made from time to time at the discretion of Pegasystems. This document remains the property of Pegasystems and must be returned to it upon request. This document does not imply any commitment to offer or deliver the products or services provided. This document may include references to Pegasystems product features that have not been licensed by your company. If you have questions about whether a particular capability is included in your installation, please consult your Pegasystems service consultant. PegaRULES, Process Commander, SmartBPM and the Pegasystems logo are trademarks or registered trademarks of Pegasystems Inc. All other product names, logos and symbols may be registered trademarks of their respective owners. Although Pegasystems Inc. strives for accuracy in its publications, any publication may contain inaccuracies or typographical errors. This document or Help System could contain technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Pegasystems Inc. may make improvements and/or changes in the information described herein at any time. This document is the property of: Pegasystems Inc. One Rogers Street Cambridge, MA 02142 Phone: (617) 374-9600 Fax: (617) 374-9620 www.pega.com Document: Software Version: 7.12 Updated: December 2014

CONTENTS Preface..i Intended Audience...ii Guide Organization...ii Chapter 1: Next-Best-Action Marketing Overview... 1-1 Features... 1-2 Logging In... 1-3 Next-Best-Action Studio... 1-3 Marketing Explorers... 1-4 Home Tab... 1-6 Pega Button... 1-9 Header Bar... 1-11 Footer Bar... 1-12 Chapter 2: Programs... 2-1 Program Display... 2-2 Program Header... 2-3 Message Panel... 2-3 Program Configuration Panel... 2-4 Program Information Tabs... 2-4 Links Panel... 2-7 Run Summary Panel... 2-8 Checklists Panel... 2-9 Pega Pulse and Attachments Panels... 2-9 Program Lifecycle... 2-11 Stages in the Program Lifecycle... 2-11 Actions Available on a Program... 2-15 Program Execution Options... 2-30 Enabling Program Schedule... 2-31 Enabling Events... 2-33 Enabling Real-Time Containers... 2-35 Program Run Display... 2-36 Program Run Header... 2-37 Message Panel... 2-37 Progress Run Progress Panel... 2-38 Metrics & Reports... 2-38 Links Panel... 2-39

Pega Pulse and Attachments panels... 2-40 Program Run Lifecycle... 2-40 Stages in the Program Run Lifecycle... 2-41 Actions Available on a Program Run... 2-42 Test Program Runs... 2-45 Program Distribution Test Display... 2-45 Program Run Test Display... 2-46 Delete Test Results... 2-47 Chapter 3: Campaigns... 3-1 Campaign Lifecycle... 3-2 Creating a Campaign... 3-3 Configuring a Campaign... 3-4 Specifying Campaign Details... 3-4 Selecting the Campaign Audience... 3-4 Selecting the Campaign Offer... 3-7 Selecting the Campaign Flow... 3-11 Specifying Campaign Goals... 3-13 Validating a Campaign... 3-15 Running a Campaign... 3-16 Monitoring Campaign Goals... 3-17 Wrapping up a Campaign... 3-18 Other Campaign Actions... 3-18 Rescheduling a Campaign... 3-19 Suspending a Campaign... 3-19 Withdrawing a Campaign... 3-19 Archiving a Completed Campaign... 3-20 Restoring an Archived Campaign... 3-20 Reopening a Completed Campaign... 3-20 Chapter 4: Segments... 4-1 Designing a Segment... 4-3 Segment Header Panel... 4-4 Creating Visually Composed Segments... 4-4 Creating Non-Visual Segments... 4-27 Saving and Running a Segment... 4-28 Configuring and Scheduling a Segment... 4-30 Scheduled Segment Execution... 4-31 Segment History... 4-33 Intelligent Segmentation... 4-34 Configuring Samples... 4-34 Configuring Analysis Projects... 4-38

Chapter 5: Control Groups... 5-1 Creating a Control Group... 5-1 Populating a Control Group... 5-2 Determining Control Group Membership... 5-2 Chapter 6: Strategies... 6-1 Using Segments within Strategies... 6-1 Using Contact Policies within Strategies... 6-3 Requirements for Contact Policies to be applicable... 6-4 Using Geofences within Strategies... 6-6 Selecting Geofences... 6-6 Configuring Filter Options... 6-8 Using a Strategy to Stop In-Flight Offers... 6-9 Chapter 7: Contact Policies... 7-1 Contact Policy Management... 7-2 Creating a new Contact Policy... 7-2 Deleting a Contact Policy... 7-4 Chapter 8: Volume Constraints... 8-1 Configuring Constraint Reset Options... 8-3 Specifying Offer Constraints... 8-5 Specifying Channel Constraints... 8-5 Selecting the Optimization Mode... 8-7 Chapter 9: Offers... 9-1 Creating the Offer Flow... 9-2 Adding Flow Shapes... 9-2 Connecting Two Shapes... 9-27 Offer Flow Validation... 9-31 Adding Inbound Channel Support... 9-32 Sample Offer Flow... 9-34 Specifying Offer Details... 9-34 Basic Offer Attributes... 9-35 Bundle Attributes... 9-35 Field Marketing Details... 9-36 Custom Attributes... 9-36 Creating a New Attribute... 9-37 Testing the Offer Flow... 9-38

Chapter 10: Treatments... 10-1 Email Treatments... 10-1 Configuring the Email Treatment... 10-2 Testing the Email Treatment... 10-6 Passbook Treatments... 10-9 Configuring Pass Elements... 10-11 Configuring Pass Fields... 10-15 Configuring Advanced Passbook Options... 10-16 Testing the Passbook Treatment... 10-16 Sections... 10-21 SMS Treatments... 10-22 Using the SMS Treatment Editor... 10-22 Testing the SMS Treatment... 10-24 Chapter 11: Templates... 11-1 File Template... 11-2 Database Template... 11-2 Configuring Output Destination... 11-2 Configuring Output Content... 11-4 Specifying Header/Footer Information... 11-4 Specifying Output Fields... 11-4 Configuring File/Table Finalization... 11-5 File/Table Landing Page Actions... 11-7 Chapter 12: Offer Bundles... 12-1 Offer Bundling Basics... 12-1 Offer Roles... 12-1 Offer Bundle Types... 12-1 Specifying Offer Bundle Settings... 12-3 1. Using the Details Tab on the Offer Rule Form... 12-3 2. Specifying Bundle Characteristics in the Strategy... 12-3 Designing Offer Flows for Bundles... 12-4 Designing the Parent Offer... 12-4 Designing Member Offers... 12-5 Designing Email Treatments for Bundles... 12-6 Offer Bundle Counts in Program Displays... 12-7 Chapter 13: Microsites... 13-1 Creating a Microsite... 13-1 Managing Microsite Stages... 13-4 Adding a new Stage... 13-4 Deleting a Stage... 13-4

Reordering Stages... 13-5 Configuring a Stage... 13-5 Launching another Microsite... 13-7 Defining and Using Custom Fields... 13-8 Embedding a Microsite Link in an Email Treatment... 13-9 Launching and Testing Microsites... 13-10 Example Microsite Configurations... 13-10 1. Microsite using Custom Site Data... 13-10 2. Microsite using Customer and Offer Data... 13-12 Note on Deleting Microsites... 13-15 Manage Subscription Preferences Microsite... 13-16 Embedding Subscription Microsite Link... 13-16 Subscription Microsite Functionality... 13-17 Viewing Unsubscribe Data... 13-18 Subscription Microsite Configuration... 13-20 Subscription Preference Data Class... 13-21 Chapter 14: Geofences... 14-1 Geofence Management... 14-1 Creating a new Geofence... 14-1 Viewing Associated Events... 14-6 Importing Geofences... 14-6 Geofence Services... 14-10 Preferred Geofences Lookup... 14-10 Detect/Trigger Geofences... 14-11 Chapter 15: Real-Time Events... 15-1 Event Management... 15-1 Creating a new Event... 15-1 Viewing Associated Programs... 15-4 Triggering an Event... 15-4 Chapter 16: Real-Time Containers... 16-1 Container Management... 16-2 Creating a new Container... 16-2 Viewing Associated Programs... 16-3 Real-Time Container APIs... 16-4 ExecuteWebContainer... 16-4 CaptureWebImpression... 16-6 CaptureWebClickThrough... 16-6

Chapter 17: Prospects... 17-1 Configuring the Prospect Class... 17-1 Importing Prospect Lists... 17-2 Prospect Segments... 17-4 Targeting Prospects in Programs... 17-6 Chapter 18: Seed Lists... 18-1 Seed List Management... 18-2 Creating a new Seed List... 18-2 Modifying Seeds in a Seed List... 18-2 Deleting a Seed List... 18-3 Updating Seed List Columns... 18-3 Chapter 19: Checklists... 19-1 Checklist Display... 19-2 Checklist Header... 19-3 Checklist Details Panel... 19-3 Tasks Panel... 19-4 Links Panel... 19-4 Pega Pulse and Attachments panels... 19-5 Actions Available on a Checklist... 19-5 Start Checklist... 19-5 Add Tasks... 19-5 Update Checklist Info... 19-6 Complete Checklist... 19-6 Withdraw Checklist... 19-7 Reopen Checklist... 19-7 Task Display... 19-8 Task Header... 19-9 Task Details Panel... 19-9 Links Panel... 19-10 Pega Pulse and Attachments panels... 19-11 Actions Available on a Task... 19-11 Start Task... 19-11 Update Task... 19-11 Complete Task... 19-12 Withdraw Task... 19-12 Reopen Task... 19-12 Chapter 20: Email and SMS Account Configuration... 20-1 Configuring an Outbound Email Account... 20-1 Configuring an Outbound SMS Account... 20-2 Specifying Delivery Time Frames... 20-4

Configuring an Inbound SMS Account... 20-5 Connection Setup... 20-5 Response Behaviors... 20-6 Chapter 21: Push Notifications... 21-1 Registering Apps for Push Notification... 21-2 Configuring a New App... 21-2 Adding a Variant to an Existing App... 21-4 Setting the Default App... 21-5 Testing an App Variant... 21-5 Deleting an App Variant... 21-6 Using Push Notification with Passbook... 21-7 Configuring Push Notifications in Offers... 21-7 General Configuration... 21-7 Application Configuration... 21-8 Wait After Sending... 21-8 Send Additional Values... 21-9 Set Badge... 21-9 Push Notification User Registration Services... 21-10 Registration Service... 21-10 Un-registration Service... 21-11 Chapter 22: Marketing Profile... 22-1 Profile Elements... 22-2 Customer Details... 22-2 Customer Dimensions... 22-3 Customer Demographics... 22-3 Propensity Scores... 22-4 Engagement History... 22-4 Marketing Profile Customization Guidelines... 22-6 Displaying Next Best Action... 22-6 Displaying Top Offers... 22-6 Displaying Segments... 22-7 Displaying Customer Dimensions... 22-7 Appendix A: User Preferences... A-1 Appendix B: Administrative Settings... B-1 Configuration Settings... B-1 Artifact Settings... B-3 Inbound SMS Settings... B-3 Manage Data Relationships... B-4 Associating Entities with the Customer class... B-4 Building an Application on Pega Next-Best-Action Marketing... B-7

Using a custom Artifacts ruleset... B-7 Appendix C: Passbook Settings... C-1 Uploading the Apple Certificate... C-1 Uploading the Organizational Certificate... C-1 Appendix D: System Health... D-1 Errors and Warnings Cards... D-2 Errors and Warnings Grids... D-3 Agent Errors/Warnings... D-3 Channel Errors/Warnings... D-4 Configuration Errors/Warnings... D-5 Runtime Errors/Warnings... D-7

Preface This guide is designed to provide you with an overview of Next-Best-Action Marketing (NBAM) and its various components. NBAM is a comprehensive marketing automation solution that delivers inbound offer management and outbound marketing campaigns on a single platform. NBAM uses a unique combination of predictive and adaptive analytics, real time decisioning, and business process management to dynamically manage cross-channel conversations (from offer design to fulfillment), drive revenue, and expand customer lifetime value. This guide explains how to: Use Next-Best-Action Studio Create Programs and Strategies to deliver Offers to customers Leverage Segment visualization to hone in on the ideal set of customers Configure constraints to optimize throughput Create complex cross-channel Offers and group Offers into bundles Design and create compelling Treatments Design, deliver, and update (Apple) Passbook passes Deliver push notifications to configured apps on Android and ios devices Configure, trigger, and respond to real-time Events and Geofences Use stage-based case management to define dynamic Microsites Create Seed Lists and utilize them for testing Offers and Programs Import Prospect lists and target prospects via Programs Define and populate Control Groups and utilize them in Strategies Create Checklists and Tasks Utilize the Marketing Profile to view customer details Assess the health of your NBAM application Utilize other common Marketing functions i

Intended Audience This guide is intended for Marketing analysts and managers with PegaRULES Process Commander and Decision Strategy Manager (DSM) experience. Guide Organization This guide contains the following chapters: Chapter 1: Next-Best-Action Marketing Overview Chapter 2: Programs Chapter 3: Campaigns Chapter 4: Segments Chapter 5: Control Groups Chapter 6: Strategies Chapter 7: Contact Policies Chapter 8: Volume Constraints Chapter 9: Offers Chapter 10: Treatments Chapter 11: Templates Chapter 12: Offer Bundles Chapter 13: Microsites Chapter 14: Geofences Chapter 15: Real-Time Events Provides a business overview of NBAM and explains the basics of Next-Best-Action Studio. Provides an in-depth look into the Program work object. Topics covered include Program (and Program Run) display and life cycle, Program execution options, and testing Program execution. Provides a detailed look into Campaigns. Topics covered include Campaign lifecycle, configuration, and available actions. Provides an in-depth look into Segments, Samples, and Analysis Projects. Topics covered include designing Segments, running Segments, scheduling Segments, and Intelligent Segmentation. Provides information on creating and populating Control Groups; and determining Control Group memberships via Strategies. Provides an overview of Strategies and their usage. Provides information on managing Contact Policies, which provide a mechanism for controlling and restricting how many times a customer is contacted in accordance with corporate and/or regulatory guidelines. Provides information on creating Offer and Operational Volume Constraints; and configuring constraint reset options. Provides insights into various aspects of the Offer, such as creating and testing Offer flows, and specifying Offer details. Provides information on how to create and test Email, Passbook, and SMS Treatments. Explains how Templates can be utilized to write content to output files and database tables. Provides information on creating Offer bundles and designing bundle Offer flows and Email Treatments. Provides information on various aspects of creating Microsites using stage-based case management. Provides details on creating and importing Geofences; and invoking Geofence-related services. Provides information on configuring and triggering Events. ii

Chapter 16: Real-Time Containers Chapter 17: Prospects Chapter 18: Seed Lists Chapter 19: Checklists Chapter 20: Email and SMS Account Configuration Chapter 21: Push Notifications Chapter 22: Marketing Profile Appendix A: User Preferences Appendix B: Administrative Settings Appendix C: Passbook Settings Appendix D: System Health Provides information on configuring Real-Time Containers and the APIs available for supporting their execution. Provides information on importing Prospect lists and using Prospect-based Segments to target prospects via Programs. Provides information on configuring and managing Seed Lists. Provides an overview of the various aspects of Checklists and Tasks. Provides information on configuring Inbound/Outbound SMS accounts and Outbound Email accounts. Provides information on configuring apps for push notifications, using Offers to push notifications to customers, and invoking push notification services. Provides details on the various elements of the Marketing Profile and guidelines on using it in custom applications. Provides an overview of individual user preferences. Provides information for configuring various administrative facets of the Application. Provides details on uploading certificates for using the Passbook functionality. Provides an overview of the System Health functionality. iii

Chapter 1: Next-Best-Action Marketing Overview Marketing organizations, looking to make a significant impact on the customer experience and drive effective return on marketing investment, are turning to a Next- Best-Action approach to marketing. Pega s approach to Next-Best-Action marketing uses decision management and analytics to determine what the right action is for every customer; and provides them with the right message, at the right time, in the right channel. Built for marketers (herein referred to as the user) responsible for managing inbound and outbound customer communications and experiences, the Pega Next-Best-Action Marketing solution (herein referred to as the System or the Application) delivers on this vision through a unique combination of real-time inbound and outbound marketing, campaign management, and marketing operations capabilities that leverage predictive and adaptive analytics, real-time decisioning, and business process management. Pega s marketing solution dynamically manages multi-channel conversations through the entire customer lifecycle, from offer design to offer fulfillment. The solution embraces customer centricity by providing measureable business benefits to marketing organizations by: Creating relevant experiences for every customer Turn every interaction into a guided, relevant conversation by executing the Next-Best-Action at the moment of truth. This solution continuously learns and adapts to every customer in real time, across all channels, including social media and mobile. Giving marketers more control Design, change, measure, and control multichannel customer strategies with a single marketing portal that doesn t require IT involvement. Pega is the only solution to support marketing operations with a robust business process management platform that seamlessly connects sales with customer fulfillment processes. Optimizing customer lifetime value - Maximize revenue with proactive crosssell, up-sell, and retention opportunities for customers and coordinate the experience across inbound and outbound channels. The solution provides the optimum balance between various customer needs and the specific needs of the business. 1-1

Features Next-Best-Action Marketing features the following high level capabilities: Next-Best-Action Marketing Customer-centric approach to marketing that leverages predictive and adaptive analytics to provide real-time and batch marketing offers and treatments to drive customer lifetime value. Capabilities to allow Marketers to create cross-channel engagement strategies that continuously look at customer history and many different customizable attributes to determine the top offer, best time, specific treatment, and best channel to interact with customers and prospects. Shared Marketing components Next-Best-Action Marketing includes a core set of out-of-the-box marketing capabilities leveraged by every module of the solution that allows marketers to design, execute, deliver, and adapt to marketing strategies. Pega s shared components include a single marketer s portal that has a marketing calendar, collaboration environment, offer and campaign design, treatment design, channel configuration, constraints optimization, response management, and reporting dashboards. Analytics-Based Campaigns Pega s marketing campaign capabilities deliver multi-step, multi-channel marketing communications to very targeted and segmented audiences that help increase return on investment in every marketing initiative. Analytics-based campaign capabilities include intelligent segmentation that leverages predictive analytics and easy to use visual segments to pick the best customers for your marketing initiative. Marketing Operations Pega s Marketing Operations capabilities include dynamic case management that can orchestrate multiple processes, systems, and people. This allows marketing to adapt to complex business needs. Pega s Operations module includes checklists for marketers to monitor and control work, as well as a number of approval templates that can be quickly leveraged in the marketing organization to support financial business objectives. 1-2

Logging In The following accounts are provided as out-of-the-box samples. Your administrator should provide you with the specific account(s) with which to login to the System. Role Login Password Default Portal Other Portals Analyst Manager MarketingAnalyst @PegaNBAM MarketingManager @PegaNBAM Administrator MarketingAdminist rator@peganbam install install install Next-Best- Action Studio Next-Best- Action Studio Designer Studio (none) Case Manager Next-Best- Action Studio, Case Manager Next-Best-Action Studio Next-Best-Action Studio is the default portal for both marketing users and managers. This portal is specially built for the marketing user. It provides the user with quick and convenient access to a wide variety of resources. 1-3

Next-Best-Action Studio comprises the following pieces: Marketing Explorers Home Tab Pega Button Header Bar Footer Bar Marketing Explorers Next-Best-Action Studio provides various explorers, thereby enabling users to quickly browse to the desired marketing artifact. This includes the following explorers: Icon Explorer Name Explorer Purpose Recent Items Business Decisions Offer Assets Programs Checked Out Records Favorites Contains a searchable list of recently accessed artifacts, such as rules, work objects, and landing pages Contains decision centric rules. This includes Segments, Strategies, Volume Constraints, Decision Trees/Tables, Predictive/Adaptive Models, Scorecards, and When rules). Contains Offer-related assets. This includes Offer rules, treatment rules (Email, Passbook, Section, and SMS), and Microsites. Contains Program, Campaign, and Checklist work objects. Contains a searchable list of the user s checked out records. Contains a searchable list of the user s favorites. Issue/Group Classification Pattern Most marketing artifacts are classified using the Issue and Group constructs. The only exceptions to this are the OOTB Decision rule types (such as Decision Trees, Decision Tables, etc.) which are displayed without any further classification. Within the current classification pattern, there are three levels at which an artifact can be created: Top Level These artifacts are created without the context of an Issue or a Group. Top level artifacts can be used by artifacts at any of the three levels. However, they can only use artifacts which are also defined at the top level. 1-4

Issue Level These artifacts are created within the context of only an Issue (no Group). Issue level artifacts can be used by artifacts that are in the same Issue or one of its Groups. Issue level artifacts can use top level artifacts and other artifacts belonging to the same Issue. Group Level These artifacts are created within the context of both an Issue and a Group. Group level artifacts can be used only by other artifacts that belong to the same Group. Group level artifacts can use top level artifacts, artifacts belonging to the parent Issue, and artifacts belonging to the same Group. Note: Issues and Groups are Decisioning constructs and are used extensively throughout this Application. Issues and Groups can be created from the Proposition Hierarchy landing page: -> Decisioning -> Decisions -> Proposition Management -> Hierarchy Each artifact type that uses the Issue/Group classification has nested nodes for the various Issues and Groups that are defined in the System. In addition, most artifact types (with the exception of Offers) also have a Top Level node. Expanding either the Top Level node or the Issue/Group nodes displays all artifacts of that type at that particular level. Creating New Artifacts Marketing artifacts can be created from marketing explorers in the following two ways: Right-click context menu Artifacts can be created at any level (Top/Issue/Group) by simply right-clicking the node entry for the appropriate level and selecting New. For most applicable marketing rules (with the exception of Strategies), the System automatically sets the Issue and Group for the new artifact based on the node that was used to create the new artifact. It is still possible to change the Issue/Group in the new rule form before creating the artifact. 1-5

Top-level explorer menu Artifacts can also be created via the Create action of the appropriate explorer s top-level menu, which is shown to the right of the explorer title. Artifacts created via this mode start out as top-level artifacts. The user can specify Issue/Group classification in the new rule form, if desired. Additionally, marketing artifacts can also be created via the Create button in the portal header. Refreshing the Explorer Each marketing explorer can be refreshed via the Refresh action in the explorer s top-level menu. Home Tab The Home tab is the chief starting point for every user. It provides the user with a quick snapshot of everything that is relevant to them. It contains the following sections: Beginner Shortcuts My Work List What s Happening Beginner Shortcuts This section provides easy access to various Marketing actions that can be performed. Each action is displayed with a description, thereby making it easier for new users to select the right action that serves their purpose. These actions are grouped into Design, Execute, and Track categories to further help the user in determining which actions are applicable at a particular phase. 1-6

The following shortcuts are provided: Design Create a New Marketing Program Create a New Offer Create a New Email Treatment Define Your Segments Execute Create a Marketing Program Define Your Segments View Your Calendar Monitor a Program Or Offer Track View Your Calendar Monitor a Program Or Offer Run a Report Hiding Beginner Shortcuts Once users have become familiar with the intricacies of the marketing portal, they may wish to hide the Beginner Shortcuts section. This can be done in the following two ways: If the Beginner Shortcuts section needs to be hidden only for the current session, simply click the Close link at the bottom right corner of this section. 1-7

This will close the Beginner Shortcuts section for the current session. To disable Beginner Shortcuts across sessions, update the Next-Best-Action Studio preference for Show Beginner Shortcuts to no longer be enabled. Refer to the User Preferences appendix for more details. My Work List The My Work List area displays all items that have been assigned to the current user. It provides the user with an easy means to work on items that require their attention. Items can directly be opened from the work list by clicking the link on the item name. The status of each item is also displayed to aid the user in prioritizing which items should be addressed first. By default, the work list displays 10 items. If there are more than 10 items in the work list, these can be accessed via the View all My Work link. The number of items to display in the work list can be updated (from 10) by updating the appropriate Next- Best-Action Studio preference. Refer to the User Preferences appendix for more details. What s Happening The What s Happening area provides a quick snapshot of the various changes that are happening across the System. It serves as a means of collaboration among various users. It displays event feeds detailing the work being performed, provides quick links to the actual artifacts that have been updated, and allows users to respond to posts and add additional comments as necessary. 1-8

The What s Happening feed also enables the user to filter the set of events that are displayed. This can be done by enabling the Show Filters checkbox and selecting the required event types. Pega Button The Pega/Next-Best-Action Studio button provides access to various landing pages and utilities. The set of items available is specific to the role of the user. At a high level, the following items are available under this button: Application Overview Provides links to application information, attachments, etc. Usage History Provides links to rule usage history (such as checkins). Available to the Administrator and Manager roles. Import & Export Provides ability to package/import/export relevant artifacts. Available to the Administrator role only. Settings Provides ability to configure various settings for the Application. Available to the Administrator role only. Refer to the Administrative Settings appendix for more details. System Health Launches the System Health landing page. Available to Administrator role only. Refer to the System Health appendix for more details. Home Provides links to the Calendar, My Work List, and the Home tab. 1-9

Track and Monitor Dashboard Launches the Marketing Reports tab. Report Browser Provides access to the Report Browser. Consult the help on the landing page for more details. Report Settings Provides ability to configure various Report settings. Tools Provides links to add reports to the Report Browser, and to view various monitoring reports. Visual Business Director Launches Visual Business Director. Decisioning Decisions Provides links to the Proposition Management and Data Flows landing pages. Predictive Analytics Provides links to manage adaptive models and to launch the Import PMML wizard. Monitoring Provides ability to monitor various decisioning facets, such as Interaction History, Visual Business Director, and Adaptive Models. Infrastructure - Provides links for configuring decisioning services, batch topology, and node topology. Available to the Administrator role only. Migration Launches the Adaptive Model Schema Migration wizard. Channels SMS Provides links to manage Inbound and Outbound SMS accounts. Email Provides links to manage Outbound Email accounts and handle Email delivery errors. File Provides link to manage Outbound File templates. Database Provides link to manage Outbound Database templates. Contact Policies Launches the Contact Policies landing page. 1-10

Passbook Settings Launches the Passbook Settings configuration landing page. Push Notification Launches the Push Notification configuration landing page. Available to the Administrator role only. Image Library Launches the Image Library, where images in the System can be searched. Segmentation Segmentation Support Provides links to manage Sample Populations and Analysis Projects, which are used for intelligent segmentation. Seed Lists Launches the Seed Lists landing page. Prospect Lists Launches the Prospect Lists landing page. Marketing Profile Launches the Marketing Profile window. Real-Time Artifacts Real-Time Events Provides links to the Events and Geofences landing pages. Containers Launches the Real-Time Containers landing page. Header Bar The Header bar provides icons for easy access to various tools and menus. The following icons are included: Icon Purpose Contains menu items with links to landing pages and utilities Launches a secondary portal (Administrator/Manager roles only) Contains menu items to create marketing artifacts Displays checked out rules Contains menu items with links to help resources Contains menu items with link to operator resources (such as preferences) 1-11

Footer Bar The Footer bar provides icons for easy access to various tools. The set of items available in the footer bar is specific to the role of the user. The following icons are included: Icon Purpose Launches the Marketing Calendar. Launches Visual Business Director. Users can select the desired view from the menu items. Launches the Marketing Dashboard Charts tab. Launches the Tracer. Administrator and Manager roles only. Launches the Clipboard Viewer. Administrator and Manager roles only. Toggles Live UI on or off. Live UI allows inspection of UI elements. Administrator and Manager roles only. Launches PAL. Administrator role only. Displays alerts. Administrator role only. Opens Pega Developer Network (PDN) in a new window. Administrator role only. 1-12

Marketing Calendar The Marketing Calendar presents a view of Programs across a certain time period. Various time range options (Daily, Weekly, and Monthly) aid in providing both shortterm focus and long-term vision into planned marketing activities. Features of the Marketing Calendar include: Ability to switch between different calendar views daily, weekly, and monthly Ability to jump to current date (Today) in any calendar view Status-centric demarcation of Programs (with appropriate Status Key) Ability to filter the Calendar both by Status and by User 1-13

Ability to view Program details (along with Program Run summary) upon hovering over a Calendar entry Note: If there are more than 10 entries for a single day on the calendar, these can be seen by clicking the ellipsis ( ) at the bottom of the list of Program entries for that day. 1-14

Visual Business Director Visual Business Director (VBD) allows the user to visually analyze business performance by performing historical analysis. Users can analyze results along different views (such as Issues, Groups, Offers/Propositions, Channels, etc.). Users can directly launch VBD for pre-defined views by selecting the appropriate view using the arrow in the footer, as shown below: Users can detach the VBD display via the detach arrow, located to the right of the Close button in the VBD display header. Users can manage views from the Views tab, which is accessible via: -> Decisioning -> Monitoring -> Visual Business Director -> Views Note: For more information on VBD and how to use it, refer to the PRPC Help documentation. 1-15

Marketing Reports The Marketing Reports tab enables the user to view reports that track the progress of their Marketing initiatives. This includes the following reports: Program Budgets by Business Issue Recently Processed Offers Forecasts and Actuals by Type Program Count by Type Each report can be rendered in 2D or 3D mode. Users can also maximize an individual report or view the data associated with the report. In addition to these standard out-of-the-box reports, users can also create their own reports via the Report Browser, which is accessible from the Pega Button. 1-16

Chapter 2: Programs A Program is the culmination of various Marketing artifacts. Programs have a lifecycle of their own and go through various stages, such as Design, Approval, Execution, etc. These stages are fully explained in the Program Lifecycle section. A Program can have multiple executions (based on a schedule) each of these executions is represented by a Program Run. Thus, a Program has one or more Program Runs. Programs are listed in the Programs & Checklists explorer in Next-Best-Action Studio. Programs can be stored at the top level or can be categorized under Issues and Groups. A new Program starts out with input fields where basic information about the Program can be entered, as shown below: Note: The Program name must be unique across the system. Unlike some of the other rules (such as Offer), the same Program name can t be used at different hierarchical levels (Top/Issue/Group). The Program name must also begin with a letter and shouldn t contain any special characters (except spaces and underscores). 2-1

Program Display Clicking Create, after entering the information above, creates the Program work object and switches to the Program work object display, as shown below: The Program Display can be split into the following pieces: Program Header Message Panel Program Configuration Panel Program Information Tabs Links Panel Run Summary Panel Checklists Panel Pega Pulse and Attachments Panels 2-2

Program Header The Program header displays the following information about the Program: Name Work ID Status Button Strip Contains buttons for the actions that can be performed on the Program, including: Save As Create a copy of this Program. Other actions - View a list of available actions that can be taken on the Program at the current point of time. Close Close the Program display. Save Save current changes and continue performing the action. Message Panel The Message panel is used to display messages to the user after an action is performed on the Program. This includes confirmation messages, error messages, and any other messages relevant to the performed action and its outcome. 2-3

Program Configuration Panel The Program Configuration panel is used to display and specify the building blocks of the Program. This includes the following: Starting Population The Starting Population specifies the potential set of customers, with whom to communicate. The constituents of the Starting Population can be defined by creating a Segment rule within the System and pointing to the appropriate Segment rule in the Starting Population field. Refer to the Segments chapter for more details. Marketing Strategy The Marketing Strategy determines how customers and Offers are matched to one another. After selecting a Marketing Strategy for the Program, the appropriate Public Component to be used within the Strategy must also be selected. Refer to the Strategies chapter for more details. Constraint Optimization Constraint Optimization enables the limiting of Offers based on Product/Channel constraints. Refer to the Volume Constraints chapter for more details. In display mode, the Program Configuration panel also provides links to the artifacts mentioned above (if they are set on the Program). Clicking one of these links opens the relevant artifact in its own tab. If the Starting Population Segment rule has been previously executed, the latest number of customers in the Starting Population is displayed next to the name of the Segment rule. Program Information Tabs The Program information tabs enable the display and specification of various Program details. These tabs are displayed in a group under the Program Configuration panel and include the following: Details This tab contains general details of the Program along with the Key Code and 2-4

the Approval Status. The Summary expand pane at the bottom contains read-only information about the Program s creation and categorization. Financials This tab contains details pertaining to the financial aspect of the Program, such as Budget, Forecast Expenses, etc. Target Population This tab contains information about the target population for the Program, including the Expected Audience Size and the Expected Response Rate. 2-5

Offers This tab contains information about the Offers associated with this Program. It is divided into two parts: Planned Offers - This section contains a free-form list of Offers that are planned to be included in this Program. This list does not have to correlate to real Offer rules in the System, and is meant as a planning tool when the Program is in its inception/design phase. Available Offers in Strategy This section lists the actual Offers that are part of the specified Marketing Strategy (and any of its substrategies) for this Program. This list is auto-populated by the System based on the specified Strategy and can t be modified. To update the list of Offers that appears in this list, update the associated Marketing Strategy rule. Run Options This tab contains the various scheduling options for the Program. Refer to Program Execution Options for more details. 2-6

Links Panel The Links panel contains various useful links, including the following: Help View the help topic for Programs. History - View a historical record of the various actions that have been performed on this Program. Follow (For managers) Mark this Program as an item to follow. Followed items are displayed in the Following list in the Case Manager portal. Unfollow (For managers) Remove this Program from the list of followed items. Tags Manage the tags associated with this Program. Managers can directly search for work objects by tags in the Case Manager portal by selecting the Matching Tags link in the search results pane. 2-7

Archive Archive a completed Program. Restore Restore a previously archived Program. Reopen Reopen a wrapped-up or restored Program. Run Summary Panel The Run Summary panel presents a summarized view of the Program execution. It consists of the following sections: Program Summary Details This section presents total and average metrics for the Offers being processed as part of this Program. This includes information such as the number of offers initiated, number active, and the number completed. Run Schedule This section displays the run schedule for the Program, which contains the list of completed, current, and upcoming Program Runs. Offer metrics and an Actions menu (containing applicable actions) are displayed for current and completed Program Runs. Upcoming Program Runs are displayed with their scheduled execution time in the Upcoming Run Dates section. 2-8

Test Runs This section displays current and completed Test Program Runs. This includes both Program Distribution Test runs and Program Run Test runs. Offer metrics and an Actions menu (containing applicable actions) are displayed for each test run. Checklists Panel The Checklists panel displays any Checklists that have been associated with this Program, along with their due dates. The user can open the referenced checklist by clicking on the link in the name column. Refer to the Checklists chapter for more information. Pega Pulse and Attachments Panels The Pega Pulse panel provides a mechanism for users to collaborate while they work on the Program. Users can share messages, files, and links with each other. Users can also apply various filters to only view the desired posts. While adding a new post, users can control whether the post should be Private or Public. For files and links, users can also choose to attach the file/link to the work object. 2-9

The Attachments panel lists the documents that have been attached to the Program. It also provides a means for adding new attachments to this Program. Users can attach files and links via the Add menu in the panel. To attach other types of attachments (such as notes, screenshots) or to scan and attach a document, users can use the Advanced link. This opens a separate window where attachments can be managed. 2-10

Program Lifecycle Each Program has a lifecycle and goes through various stages along this lifecycle. At each of these stages, appropriate actions can be performed on the Program either via the Other Actions menu or via links in the Links panel. Performing one of these steps might progress the Program to a different stage in the lifecycle or leave it at the current stage. Note: Some of the lifecycle stages (such as the ones pertaining to the Program Approval process) can be customized by the administrator of your Application. This section describes the out-of-the-box set of stages and their applicable actions. Stages in the Program Lifecycle The following is an overview of the various stages in the Program Lifecycle. The actions available at each stage are listed with the stage. These actions are further explained in subsequent sections. New Program This is the initial stage of the Program when it is first initiated. The following actions can be performed at this stage: Create Program - Enter the necessary Program details and click the Create button. Discard Program Close the Program without clicking the Create button. Program Created/Updated Once the Program has been created (or, in latter iterations, updated), the Program Display is shown. The actions available at this stage are: Submit Program For Approval This action is only available for those Programs that require approval and haven t been either approved or rejected. Completing this action moves the Program to the Program Pending Approval stage. Submit Program For Execution This action is only available for Programs that have been approved (or don t require approval) and have all pertinent details (necessary for execution) specified. Completing this action moves the Program to the Program Ready for Execution stage. In the rare case that an error occurs while creating the Program schedule or other necessary artifacts, the Program transitions to the Program Failed stage. 2-11

Update Program Update the various details of the Program. Completing this action can enable the Submit Program For Execution action if all details (necessary for execution) have been provided and the Program doesn t require approval. Cancel Program Completing this action moves the Program to the Program Cancelled stage. Program Distribution Testing This action is available for Programs that have all pertinent details (necessary for execution) specified. Taking this action initiates a Program Distribution Test. Refer to the Program Distribution Testing action for more details. Program Run Testing This action is available for Programs that have all pertinent details (necessary for execution) specified. Taking this action initiates a Program Run Test. Refer to the Program Run Testing action for more details. Validate Program This action can be used to validate the Program configuration. Completing this action does not move the Program to a different stage. Program Pending Approval Once a Program has been submitted for approval, the actions available on the Program differ based on the user s role. For regular users, the only action available is: Recall Program The user can recall their Program from the manager. Taking this step moves the Program back to the Program Created/Updated stage. For the manager, the available actions are: Approve Program Completing this action moves the Program to the Program Approved stage. Reject Program Completing this action moves the Program to the Program Rejected stage. Program Approved Once a Program is approved by the manager, it goes back to the Program Created/Updated stage with the approval status set to Approved. 2-12

Program Rejected If a Program is rejected by the manager, it goes back to the Program Created/Updated stage with the approval status set to Rejected. Program Ready for Execution Once a Program is submitted for execution, it transitions into this stage while waiting for the first/next Program Run to start. At that point, it automatically transitions to the Program Run Running stage. The actions available at this stage are: Reschedule Program Completing this action applies the new execution schedule for the Program and leaves it in this (ready for execution) stage. Suspend Program Completing this action places the Program in the Program Suspended stage. Stop All Program Runs Completing this action stops any active Program Runs on the Program. Program Run Running The Program automatically transitions into this stage when the start time for one of its Program Runs is reached. The actions available at this stage are: Reschedule Program Completing this action places the Program back in the Program Ready for Execution stage. Suspend Program Completing this action places the Program in the Program Suspended stage. Stop All Program Runs Completing this action stops any active Program Runs on the Program. After the Program Run has completed, the Program automatically transitions to either the Program Ready for Execution stage (if there are more Program Runs pending) or to the Program Execution Complete stage (if this was the last Program Run). Program Suspended When a Program is suspended, the following actions are available: Update Program - Completing this action moves the Program to the Program Created/Updated stage. Resume Program Completing this action moves the Program to the Program Ready for Execution stage. 2-13

Cancel Program - Completing this action moves the Program to the Program Cancelled stage. Program Execution Complete Once all Program Runs for a Program have completed, the Program enters this stage. The following actions are available: Update Program This action is provided to enable the user to update any necessary information (such as actual metrics) at the completion of the Program. Completing this action leaves the Program in its current stage. Wrap-Up Program Completing this action moves the Program to the Program Wrap-Up Complete stage. Archive This action is available in the Links panel. Taking this action moves the Program to the Program Archived stage. Program Wrap-Up Complete After wrap-up has been completed for the Program, the following actions are available: Archive This action is available in the Links panel. Taking this action moves the Program to the Program Archived stage. Reopen This action is available in the Links panel. Taking this action moves the Program to the Program Execution Complete stage. Program Archived Once a Program is archived, the only available action is: Restore This action is available in the Links panel. Taking this action moves the Program to the Program Wrap-Up Complete stage. Program Cancelled Once a Program is cancelled, no further actions are available for the Program. This Program can still be copied by using the Save As button. Program Failed If a failure occurs in generating the Program schedule, the Program enters this stage. No further actions are available for the Program. This Program can still be copied by using the Save As button. 2-14

Actions Available on a Program The following is an overview of the various actions that are applicable on a Program, during the course of its lifecycle. While performing any of these actions, it is possible to switch to a different action (if it s currently available) by using the Other Actions menu. Update Program This action enables the user to update various Program details. This includes the information that is found in the Program Information tabs and the Program Configuration panel. After performing this action, the Program must once again go through the approval process (if approval is needed). Certain details about the Program must be provided before a Program can be submitted for execution. This is true even if the Program has been approved by the Manager. In such cases (where the Program has been approved), the status of the Program will change to Pending-Details to indicate that certain key information (required for Program execution) is missing. After providing this information, the Program might still have to be re-approved before it can be submitted for execution. The specific set of details that are required can be customized by the administrator of your Application. The OOTB list includes the following items: Program Name Starting Population Marketing Strategy & Public Component Program Schedule (one-time or recurring) 2-15

Submit Program For Approval This action enables the user to submit their Programs for approval. Most Programs require approval before they can be executed. Users can enter a note along with their approval request and can also decide whether this note should be displayed in the Pega Pulse panel in the Program display. The System automatically routes approval requests to the manager of the user s organizational unit. In addition to adding the Program to the manager s Work List, the System also notifies the manager about the approval request via email. 2-16

Recall Program After a Program has been submitted for approval, no further changes are allowed to the Program. If a user wishes to make further updates to the Program, they must first recall the Program from the manager. Users can enter a note (explaining the reason for recalling the Program from the manager) and can also decide whether this note should be displayed in the Pega Pulse panel in the Program display. As before, the manager is notified via email when a Program is recalled from their Work List. Once a Program has been successfully recalled, it can be updated and re-submitted for approval when ready. Approve Program This action is available only to the manager. The manager can open the Program work object either directly from their email (by clicking the Program link) or from the My Work List section of their home page; and can then select the Approve Program action from the actions menu. 2-17

The manager can also enter an approval note and decide whether this note should be displayed in the Pega Pulse panel in the Program display. After entering the note, click the Submit button at the bottom of the screen (after the Program details sections). When a Program is approved, the user that submitted this Program for approval is notified via email so that they can start working on it again. The approval message is also displayed in the Messages Panel on the Program Display. Reject Program This action is also available only to the manager. The manager can open the Program work object either directly from their email (by clicking the Program link) or from the 2-18

My Work List section of their home page; and can then select the Reject Program action from the actions menu. The manager can also enter a rejection note and decide whether this note should be displayed in the Pega Pulse panel in the Program display. After entering the note, click the Submit button at the bottom of the screen (after the Program details sections). When a Program is rejected, the user that submitted this Program for approval is notified via email so that they can make necessary changes to the Program. The rejection message is also displayed in the Messages Panel on the Program Display. 2-19

Validate Program The Validate Program action enables the user to validate the various configurations that they provided for the Program. Any violations are categorized into errors and warnings. Errors denote violations that will prevent the Program from being submitted for execution. Warnings represent best practice violations and other scenarios which may potentially impact Program execution. The user can use the update link to make any necessary updates to the Program. The same validation routine used by the Validate Program action is also invoked by the System when the Submit Program for Execution, Program Run Testing, and Program Distribution Testing actions are taken. If the validation returns any errors, they must be corrected before the user is allowed to perform the desired action. Warnings do not prevent these actions from being taken but should still be individually heeded and addressed, where necessary. Program Distribution Testing The Program Distribution Testing action enables the user to configure and initiate a distribution test. This is done to test the execution of a Program in terms of assessing the Offers made and the Customers targeted. This information is made available to the user in the various program reports. No offers are actually made to customers in this form of Program testing. The following configuration options are available for this action: 2-20

Refresh the starting population This setting determines whether the Program s starting population (referenced Segment rule) should be refreshed before running the distribution test. Use Volume Constraints This setting determines whether the Volume Constraint rule referenced in the Program configuration should be applied as part of executing the distribution test. Upon clicking Submit, a test run instance is initiated and the Program distribution test is executed. Refer to the Test Program Runs section for details on the display and actions for this object. Program Run Testing The Program Run Testing action enables the user to configure and initiate a simulation of the Program Run. This test is run against customers specified in a Seed List. The test will execute the referenced Strategy to determine the Offers that should be made to the customers (seeds) and then make these Offers. Customers will also be able to respond to these Offers. These responses, however, will not be captured in History. To perform a Program Run Test, a Seed List (to represent the starting population for the Program) must be selected. Refer to the Seed Lists chapter for information on creating and configuring Seed Lists. 2-21

Upon clicking Submit, a test run instance is initiated and the Program Run test is executed. Refer to the Test Program Runs section for details on the display and actions for this object. Submit Program For Execution After a Program has been approved and has the key fields (necessary for execution) specified, it can be submitted for execution. Before this action can be performed, the System runs the Validate Program action on the Program. Any validation errors and warnings are presented to the user. 2-22

All validation errors must be addressed before the Program can be submitted for execution. Once this is done, the user can choose to make any updates to their previously set Program run options. These options are explained in detail in the Program Execution Options section. Once a Program is submitted for execution, the System generates the execution schedule for the Program if Program scheduling was enabled. The generated schedule can be seen in the Run Summary panel in the Program display. The System also creates other artifacts necessary for Program Run execution. The System then waits for the execution time of the first Program Run and/or for an event to trigger its execution. Note: After submitting a Program for execution (and while it is still active), its referenced components (such as Segments, Strategies, and Volume Constraints) should not be deleted. In addition, certain structural changes should only be made after suspending the Program. Examples of these changes include modifying the Strategy s Public Component, and adding/removing Segment usage within Strategies. After making the desired structural change, the Program must be updated and resubmitted for execution. 2-23

Reschedule Program After the Program has been submitted for execution, it can be re-scheduled. The new schedule applies only to the upcoming Program Runs and does not impact any Program Runs that have already completed or are currently running. Any upcoming Program Run for the Program is suspended while this action is in progress. Once this action is submitted, the previous set of upcoming Program Runs for the Program is removed and a new set of upcoming Program Runs is calculated based on the newly specified schedule. The System also notifies the user (who submitted this program for execution) that this Program has been rescheduled and informs them of the next Program Run time. 2-24

Suspend Program This action enables the user to suspend a running Program. Suspending a Program prevents any upcoming Program Runs from executing. The user can choose to enter a note when they select this action, and can also choose whether this note should be shown in the Pega Pulse panel in the Program display. The System also notifies the user (who submitted this program for execution) that this Program has been suspended. Resume Program This action is available when a Program has been suspended and enables the user to resume Program execution. Furthermore, it provides the user with various options to deal with Program Runs that were skipped (not executed) while the Program was suspended. These options include: 2-25

Resume all unexecuted program runs In this option, all Program Runs that were not executed will be resumed. This will also include all runs that are now in the past. Program execution will start with the earliest unexecuted Program Run and continue until it has caught up with the current time. This implies that if there are multiple runs in the past that were not executed, they will execute one after the other. Remove all past unexecuted program runs In this option, any Program Run that is unexecuted but in the past will be removed. This option basically provides a mechanism for ignoring (skipping over) Program Runs that are in the past and resuming Program execution with the current Program Run (scheduled to execute on or after today). Remove all past unexecuted program runs except the last In this option, all past unexecuted Program Runs will be removed with the exception of the last one. This option will execute the last Program Run immediately on submission and then follow the rest of the upcoming Program schedule. Regardless of the option selected above, the System displays the list of Program Runs that will be resumed so that the user can see the impact the various resumption options will have on Program execution. As before, users can choose to enter a note when they resume the Program, and can also choose whether this note should be shown in the Pega Pulse panel in the Program display. 2-26

The System also notifies the user (who submitted this program for execution) that this Program has been resumed. Stop All Program Runs This action enables the user to stop any active Program Runs on the Program. A list of the Program Runs that will be stopped is presented to the user. The user can also enter a note detailing why the stop action was selected, and choose whether this note should be shown in the Pega Pulse panel in the Program display. Once this action is completed, stop requests are issued for all applicable Program Runs. The System will halt Program Run processing (if possible) at the earliest possible instance. Once the System successfully stops a Program Run, an email is sent to the user. 2-27

Any Program Run that is stopped by this action can then be individually restarted or skipped by performing the appropriate action from the Run Summary panel in the Program display or from the Other Actions menu in the Program Run display. Cancel Program This action enables the user to cancel a Program. Programs that are in approval or execution stages can t be cancelled directly. They must first be recalled or suspended (as appropriate) before they can be cancelled. Cancelling a Program moves the Program from its current node to the Withdrawn node (under Programs) in the Programs & Checklists explorer. 2-28

Wrap-Up Program The Wrap-Up Program action becomes available when all scheduled runs for a Program have completed. This action allows the user to complete the Program. The user can enter any additional remarks on the Program in the Wrap-Up Notes field. The user can also classify the Program based on its outcome into one of four categories: Successful, Not Successful, Neutral, or Not Specified. Archive The Archive action is available in the Links panel in the Program display. It allows the user to archive completed Programs. Archiving a Program moves it from its current node and places it under the Archived node (under Programs) in the Programs & Checklists explorer. Restore The Restore action is available in the Links panel in the Program display. It allows the user to restore an archived Program. The restored Program will be moved from the Archived node to its previous node (based on Issue and Group) under Programs in the Programs & Checklists explorer. Reopen The Reopen action is available in the Links panel in the Program display. It allows the user to reopen a completed (wrapped-up or restored) Program. Re-opening the Program places the Program back to its pending wrap-up state. 2-29

Program Execution Options A wide variety of options are available for configuring the desired mode of Program execution. These options are presented on the Run Options tab in the Program display and include the following: Refresh Starting Population This setting allows the user to configure whether the starting population (Segment rule) should be refreshed before the Program s execution. The user can further opt between refreshing the population for each Program Run or just for the first Program Run. Enable Run Reporting This setting allows the user to configure whether various distribution reports should be generated for each Program Run. If this option is selected, these reports (once generated) are listed in the Distribution Reports tab of the Program Run Display. Enable Program Schedule This setting determines whether the Program should be executed based on a configured schedule. See Enabling Program Schedule for various options and scheduling modes. Enable Events This setting determines whether the Program can be triggered by Events. See Enabling Events for configuration options. Enable Real-Time Containers This setting determines whether the Program can be used with Real-Time Containers. See Enabling Real-Time Containers for configuration options. 2-30

Enabling Program Schedule This group of settings provides a variety of options for configuring the execution schedule of a Program. The user has the option of selecting between a One-Time Only execution and a Recurring execution. The following additional configuration is available for the One-Time option: On Specify the start date/time for the Program execution. The following additional configurations are available for the Recurring option: Start Select the start date and time for the Program execution. End Select between the following three end options: No end date End after X occurrences End by specified date/time Frequency Select the recurrence frequency. Options available are: Minutes Specify the number of minutes in which to recur. Additionally, the user can also choose to specify the hours of operation which are applicable to this mode of recurrence. 2-31

Hourly - Specify the number of hours in which to recur. Additionally, the user can also choose to specify the hours of operation which are applicable to this mode of recurrence. Daily The user can choose between the following three options: - Recur every day - Recur every weekday - leave days box empty (shown below) - Recur every X days specify X in days box Weekly The following modes are supported: - Recur every X weeks based off a start date specify X in weeks box, do not select any week days - Recur every X weeks on selected days specify X in weeks box, select week days (as shown below) 2-32

Monthly Specify the day of the month and the number of months in which to recur. The following shows a quarterly configuration: Yearly Specify the day of the year and the number of years in which to recur. When a Program with an enabled schedule is submitted for execution, the System generates the upcoming Program Run schedule and waits for the completion of the scheduled items. As a Program Run completes, the next one is queued for execution according to its schedule. In the case of a Program where the end date is not specified, the System schedules a certain number of Program Runs (by default, 10) initially. It then schedules more Program Runs when the number of remaining Program Runs is below a threshold (by default, 5). For a schedule-only Program (no Events or Real-Time Containers), once all Program Runs are completed, the Program is automatically moved to the Execution Complete stage (ready for wrap-up). If Events and/or Containers are also configured, the Program is moved to this stage only after active windows for these have lapsed. Enabling Events This group of settings provides options for enabling Events for the Program. Refer to the Events chapter for details on creating and triggering Events. The following configuration options are available: Validate customer is in Starting Population If this is enabled, when a Program is triggered by an Event, the customer associated with the Event is validated against the starting population of the Program. Only if the customer is present in the starting population, Program execution is triggered. 2-33

Note: If the Program is referencing a Strategy rule that contains Segment references within the Strategy, the above setting is enforced even if it is not enabled. The customer must be in the starting population of the Program in this scenario. Listen for associated Events from/to Specify the Start and, if desired, End date/time values during which the Program will listen for the Events associated to it. Any Event that is received outside of the specified time frame will be ignored. Select Events Select the Events to which this Program should respond. At least one Event must be selected. Programs can be associated with multiple Events and the same Event can be listened for by multiple Programs. When a Program with Events enabled is submitted for execution, the System listens for the Event during the configured time frame. If an end time is configured for the window, the Program stops listening for the Event once the end time is reached. At this point, for Event-only Programs, the Program is automatically moved to the Execution Complete stage (ready for wrap-up). If other execution options (such as a schedule and/or Containers) are also configured, the Program is moved to this stage only after all corresponding execution cycles are complete. Note: Volume Constraints and any Contact Policy limitations specified in the Strategy are not applicable to Programs that are triggered by Events. See Configuring a Fallback Strategy for details on using a using a fallback Strategy with Events. 2-34

Enabling Real-Time Containers Real-Time Containers allow marketers to expose the results of a marketing Program to real-time channels such as web and mobile. This group of settings provides options for enabling Containers for the Program. Refer to the Real-Time Containers chapter for more details on creating and triggering Containers. The following configuration options are available: Listen for associated Container requests from/to Specify the Start and, if desired, End date/time values during which the Program will be valid for the specified Container. If a Container request is made outside of the specified timeframe, this Program will not be considered for execution. Multiple Programs can reference a single Container as long as the active listening dates do not overlap. Select Containers - Select Containers to associate with the Program. A Program can be associated to one or more Containers, but each Container can only have one active Program at any given point in time. A Program is deemed active if it is in a running state (i.e. status = Pending-Running). When the Program is validated (either directly or when submitting for execution), the System will flag any associated Containers that are currently active on a different Program. When a Program with Containers enabled is submitted for execution, the System responds to Container requests during the configured time frame. If an end time is configured, the Container will no longer consider this Program once the end time is reached. At this point, for Container-only Programs, the Program is automatically moved to the Execution Complete stage (ready for wrap-up). If other execution options (such as a schedule and/or Events) are also configured, the Program is moved to this stage only after all corresponding execution cycles are complete. 2-35

Configuring a Fallback Strategy For Real-Time Events and Containers, NBAM supports defining a fallback strategy which gets executed in case the Strategy defined on the Program fails. To utilize this functionality, users should save the strategy titled "FallbackStrategy" into their implementation layer and replace the placeholder Set Property components in this strategy with the Offers that need to be rendered in case of a failure. Program Run Display The Program Run display can typically be accessed in the following ways: By double-clicking a Start Date entry under Run Schedule in the Run Summary panel in the Program display. By opening Program Runs that are assigned to you from the My Work List section on your home page. The following shows a typical Program Run Display: 2-36

The Program Run Display can be split into the following pieces: Program Run Header Message Panel Program Run Progress Panel Metrics & Reports Links Panel Pega Pulse and Attachments Panels Program Run Header The Program Run header displays the following information about the Program Run: Name Work ID Parent Program name and work ID Contains link to parent Program Status Button Strip Contains buttons for the actions that can be performed on the Program Run, including: Other Actions Display a list of available actions that can be taken on the Program Run at the current point of time. Close Close the Program Run display. Save Save current changes and continue performing the action in edit mode. Message Panel The Message panel is used to display messages to the user after an action is performed on the Program Run. This includes confirmation messages, error messages, and any other messages relevant to the performed action and its outcome. 2-37

Progress Run Progress Panel The Program Run Progress panel is used to provide a visual overview into the Program Run s execution progress. As the Program Run executes, this panel is updated with appropriate metrics from the various execution stages. For example, after the starting population has been applied, its box in the Progress Panel is updated with the last refresh date of the population and the number of customers in the population. Completed stages are marked with a checkmark, while the currently executing stage is highlighted. A completed Program Run s progress panel is shown below: Metrics & Reports This panel is comprised of the following two tabs: Customers & Offers Distribution Reports Customers & Offers This tab presents various metrics relating the Program Run to the target customers and the output Offers. The response and accept rate for the Program Run is also presented. This tab also contains charts for the Offer counts against the Offer status, and against the response received. 2-38

Distribution Reports This tab is used to display various reports associated with the Program Run s execution. These reports are only displayed if Enable Run Reporting was selected when the parent Program was submitted for execution (or re-scheduled). Links Panel 2-39

The Links panel contains various useful links, including the following: Help View the help topic for Program Runs. History - View a historical record of the various actions that have been performed on this Program Run. Follow (For managers) Mark this Program Run as an item to follow. Followed items are displayed in the Following list in the Case Manager portal. Unfollow (For managers) Remove this Program Run from the list of followed items. Tags Manage the tags associated with this Program Run. Managers can directly search for work objects by tags in the Case Manager portal by selecting the Matching Tags link in the search results pane. Stop Program Run - Request the stopping of this Program Run. This link is shown when the Program Run is currently executing. Pega Pulse and Attachments panels The Program Run display also includes the Pega Pulse panel and the Attachments panel. The behavior of these panels is similar across various Marketing work types and has been outlined in the corresponding section of the Programs chapter. Program Run Lifecycle Just like the Program, a Program Run has its own lifecycle and goes through various stages along this lifecycle. The System handles most aspects of the Program Run lifecycle (such as creation, processing, and completion). However, certain actions are available to be performed by the user on the Program Run. Note: Each Program Run is closely tied to its parent Program. As a Program Run completes (or fails), it notifies its parent Program. Once all Program Runs are completed for a Program and there are no more scheduled runs (if configured) and the Events window (if configured) on the Program has lapsed, the Program is automatically moved to the Program Execution Complete stage by the System. 2-40

Stages in the Program Run Lifecycle The following is an overview of the stages in the Program Run Lifecycle. The available actions at each of these stages are also listed. These actions might be present directly as a link in the Links panels or as an item in the Other Actions menu. New Program Run This is the initial stage of the Program Run after it has been created but the System has not yet started processing this Program Run. The only action available at this point is Stop Program Run. Program Run Executing In this stage, the System is actively processing the Program Run. The only action available at this point is Stop Program Run. Program Run Waiting Once a Program Run has finished processing Offers, it waits in this stage until all Offers are completed. No further actions are available for this Program Run. Completed Program Run The Program Run enters this stage once all its Offers have completed. No further actions are available for this Program Run. Stopped Program Run In this stage, the System has successfully completed a Program Run stop request. Program Run execution has been halted. The actions available at this point are: Restart Program Run Taking this action withdraws the current Program Run; and creates a new Program Run for execution, starting it out from the New Program Run state. Skip Program Run Taking this action marks the Program Run as ignored (withdrawn). No further actions are available for this Program Run. Failed Program Run If something erroneous occurs during Program Run execution, the Program Run enters this stage. The actions available at this point are: Restart Program Run Taking this action withdraws the current Program Run; and creates a new Program Run for execution, starting it out from the New Program Run state. Skip Program Run Taking this action marks the Program Run as ignored (withdrawn). No further actions are available for this Program Run. 2-41

Actions Available on a Program Run The following is an overview of the user actions that are applicable on a Program Run, during the course of its lifecycle. These actions can be performed in the following two ways: Directly from the Program Run display using the actions either in the Other Actions menu or in the Links panel. While performing an action from the menu, it is possible to switch to a different action (if it s currently available). From the Actions menu adjacent to the Program Run entry in the Run Schedule in the Run Summary panel in the Program display. Stop Program Run This action enables the user to issue a stop request for an active Program Run. The user can also enter a note along with their stop request and select whether this note should be shown in the Pega Pulse panel in the Program Run display. Upon completing this action, the message panel in the Program Run display indicates that a stop has been requested. This message is displayed until the Program Run has been successfully stopped. The System will halt Program Run processing (if possible) at the earliest possible instance. Once the System successfully stops a Program Run, an email is sent to the 2-42

user. The System also assigns the stopped Program Run to the user (who submitted the Program for execution or rescheduled the Program) by placing it in their work list. Restart Program Run This action is available when a Program Run has either failed or has been stopped. In such instances, the user can correct any necessary items and restart the Program Run execution. As before, the user can enter a note along with the restart request and select whether this note should be displayed in the Pega Pulse panel in the Program Run display. When this action is submitted, the current Program Run is marked as ignored (withdrawn), a new Program Run is created, and the System starts processing this new Program Run. The System also notifies the user via email that the Program Run has been restarted. 2-43

Skip Program Run This action is available when a Program Run has either failed or has been stopped. This action enables the user to ignore this Program Run and let the Program continue with the rest of its schedule. This Program Run is marked as Withdrawn. The user can enter a note along with the skip request and select whether this note should be displayed in the Pega Pulse panel in the Program Run display. The System also notifies the user via email that this Program Run has been skipped. 2-44

Test Program Runs A Test Program Run represents the execution of a Program Distribution Test or a Program Run Test. The Test Program Run object is very similar to the Program Run object and as such, this section provides a quick overview of the Test Program Run object. Test Program Runs are listed under the Test Runs section in the Run Summary panel in the Program display, as shown below: To open the Test Program Run, double-click the Start Date entry for the desired run. Program Distribution Test Display A sample Program Distribution Test display is shown below: 2-45

Salient pieces of information that are displayed include: Associated Program name with a link to open the Program Number of Offers identified Status of the test Progress Run Progress Panel Distribution Reports Links Panel Pega Pulse and Attachments Panels Note: The Processed Offers box in the progress panel doesn t have a value for Total Offers because in the Program Distribution Test, actual Offers are not sent out to customers. Program Run Test Display A sample Program Run Test display is shown below: Salient pieces of information that are displayed include: Associated Program name with a link to open the Program Associated Seed List name with a link to open the Seed List Number of Offers identified Number of Offers processed Duration of the test Status of the test 2-46

Progress Run Progress Panel Distribution Reports Links Panel Pega Pulse and Attachments Panels Delete Test Results Once a Test Program Run has completed, the user has the option to delete the test results. This action can be performed from the Actions menu for a distribution or test run in the Test Runs section of the Run Summary panel in the Program display. The user also has the option to enter a note when performing this action. Performing this action marks the Test Program Run as Withdrawn and it is no longer listed under the Test Runs list on the Program. 2-47

Chapter 3: Campaigns NBAM 7.12 introduces an easier way to build simple outbound marketing campaigns. For advanced marketing campaigns, Programs allow the use of adaptive and predictive analytics with business rules to optimize across multiple offers, resulting in the selection of the best offer for each individual customer. However, marketers often need a simpler mechanism to promote a single offering and monitor its performance. The new Campaign construct provides just this functionality using a visual card paradigm that highlights all aspects of the campaign on a single canvas. This allows marketers to focus on key aspects of the Campaign, such as the Audience, the Offer, and the Flow. A Campaign can be considered to be a simplified version of a Program. High-level features of the Campaign functionality include the following: Simplified canvas, which includes all Campaign details in single view Visual card paradigm for easier Campaign building Three step approach to creating a multi-channel Campaign Traceable goals and the ability to monitor their performance Campaigns have a lifecycle of their own and go through various stages. These stages are outlined in the Campaign Lifecycle section. The remaining sections in this chapter outline the various Campaign interactions available to the user. These interactions include the following: Creating a Campaign Configuring a Campaign Validating a Campaign Running a Campaign Monitoring Campaign Goals Wrapping up a Campaign Other Campaign Actions Note: Campaigns are a part of the core NBAM solution and are covered in this user guide. NBAM s Field Marketing solution includes a different construct, called Field Marketing Campaign. Corporate marketers and field marketers looking for information on Field Marketing Campaigns should consult the Next- Best-Action Field Marketing User Guide. 3-1

Campaign Lifecycle Each Campaign has a lifecycle and goes through various stages along this lifecycle. The user can perform appropriate actions on the Campaign at some of these stages. Performing an action on the Campaign may move to it a different stage. The following graphic illustrates the stages in the Campaign lifecycle and the actions that can be performed by the user at each stage. The stages in the Campaign lifecycle are: New Initial stage, Campaign is yet to be saved In Design Campaign has been created and is in design Scheduled Campaign is pending the scheduled run time Running Campaign is currently running Awaiting Wrap-Up Campaign has completed running and is available for wrap-up Failed Campaign has failed. Actions in this stage are similar to those in the design stage. Completed Campaign has been wrapped-up Archived Campaign has been archived Withdrawn Campaign has been withdrawn 3-2

Creating a Campaign Campaigns are listed in the Programs explorer in Next-Best-Action Studio. Campaigns can be stored at the top level or can be categorized under Issues and Groups. Users can create new Campaigns from the following places: Create menu in the Programs explorer New Right click menu action from the top, Issue, or Group node in the Campaigns tree in Programs explorer Create menu in the Next-Best-Action Studio header Upon creation, a new Campaign resembles the following: 3-3

Configuring a Campaign Marketers can start configuring the Campaign right from the New screen. Once the Campaign has been created, they can use the Edit button to go into edit mode and make further updates to the Campaign s configurations. This section provides details on the various aspects of configuring the Campaign. This includes the following: Specifying Campaign Details Selecting the Campaign Audience Selecting the Campaign Offer Selecting the Campaign Flow Specifying Campaign Goals Specifying Campaign Details The Campaign details section contains various details about the Campaign, such as its name, issue/group information, objectives, planned start date, and basic financial information. The Campaign Name, Issue, and Group can t be modified after the Campaign has been created. Note: The Campaign s name must be unique across the system. The name must also begin with a letter and shouldn t contain any special characters (except spaces and underscores). In addition to basic information, marketers can also add tags to their Campaigns. Tagging is available once the Campaign has been created. Currently, tagging allows the marketer to further classify the Campaign as desired. In future iterations of the product, the tagging capabilities may be further enhanced to allow for tag-based searching. Selecting the Campaign Audience A key element of Campaigns is the audience, which is the set of individuals the user plans to target with their marketing message. Audience selection in Campaigns 3-4

utilizes the Segment rule, which can be used by the marketer to hone in on their desired audience. When configuring a Campaign, the marketer can review their existing Segments (along with pertinent details) right from the Campaign canvas. They can also create a new Segment and reference it in the Campaign. The Audience card in the Campaign canvas displays the currently selected Segment and its details. Initially, this card is empty. Marketers can click anywhere in the card to launch the Add Segment dialog. This dialog presents the twenty most recently updated Segments in the system. The View more results link at the bottom of the list enables users to load the next twenty Segments. Users can also utilize the search box to search for Segments by name or description. The Refresh link refreshes the list of Segments, retaining any search criteria that was previously entered. 3-5

Each Segment is represented by a card in the list. This card contains the following details about the Segment: 1. Segment name. Users can click the name to open the Segment rule. 2. Segment description 3. When the Segment s population was last refreshed 4. Number of customers in the Segment 5. Percentage of the total population represented by the Segment 6. When the Segment was last edited 7. Image associated with the Segment (if any) If the desired audience is not represented by an existing Segment, users can also choose to create a new Segment via the Create new link. After the Segment has been created, the user can use the Refresh link to reload the list of Segments. The user s new Segment should now show at the top of the list since it was most recently edited. Clicking a Segment card selects the Segment. The right pane in the Add Segment modal displays further details about the selected Segment. This includes the following information: 1. Segment name. Users can click the name to open the Segment rule. 3-6

2. Number of Segments that the selected Segment references 3. Number of Campaigns that are using this Segment as their audience 4. List of criteria utilized in the Segment. Review the Segment rule to see how the criteria is fused together to determine the Segment s population. To complete the selection process, click the Add button to denote the selected Segment as the Campaign s audience. The Audience card is updated to reflect the selected Segment. This card shows pertinent details about the Segment. This provides the user with a comprehensive summary of the selected Segment. The user can still open the referenced Segment by clicking the name link. The Delete link in the bottom right corner of the Audience card (in edit mode) allows the user to remove the selected Segment. They can then select a different Segment using the process outlined above. Selecting the Campaign Offer Next, the marketer can select the Offer they want to use in their Campaign. The Offer portion of the Campaign focuses on the promotional content that the marketer wishes to communicate and the channels they wish to utilize. The marketer can review their existing Offers (along with pertinent details) right from the Campaign canvas. They can also create a new Offer and reference it in the Campaign. The Offer card in the Campaign canvas displays the currently selected Offer and its details. Initially, this card is empty as shown below: 3-7

Marketers can click anywhere in the card to launch the Add Offer dialog. This dialog presents the twenty most recently updated Offers in the system. The View more results link at the bottom of the list enables users to load the next twenty Offers. Users can also utilize the search box to search for Offers by name or description. The Refresh link refreshes the list of Offers, retaining any search criteria that was previously entered. Each Offer is represented by a card in the list. 3-8

This card contains the following details about the Offer: 1. Offer name. Users can click the name to open the Offer rule. 2. Offer description 3. Conversion rate of the Offer 4. Impression rate of the Offer 5. Volume of the Offer number of times this Offer has been made 6. Channels utilized by this Offer. Each channel is represented by its icon. Supported channels include Email, SMS, Passbook, Push Notification, and File/Database. 7. Availability of the Offer duration when this Offer is available, if start and end dates are set on the Offer 8. Image associated with the Offer (if any) 9. Draft status of the Offer Draft icon appears if the Offer is in draft mode Clicking an Offer card selects the Offer. The right pane in the Add Offer modal displays further information about the engagement content that the Offer utilizes. This information is grouped by communication channel and includes every channel that that the Offer uses. In the example Offer above, all supported channels are being used. For each engagement, relevant information - such as the Email Treatment name or the Push Notification message - is displayed. To complete the selection process, click the Add button to denote the selected Offer as the Campaign Offer. The Offer card is updated to reflect the selected Offer. This card shows pertinent details about the Offer. This provides the user with a comprehensive summary of the selected Offer. The user can still open the referenced Offer by clicking the name link. 3-9

The Delete link in the bottom right corner of the Offer card (in edit mode) allows the user to remove the selected Offer. They can then select a different Offer using the process outlined above. Note: In the current release of NBAM, the Offer and Flow cards are interrelated as the metadata for both these cards uses the same Offer rule. As such, selecting one of these cards auto-selects the other card as well. Similarly, removing either the selected Offer or Flow also removes the other. In future releases, the cards will function independently of one another and will allow for the separation of the content from the flow. 3-10

Selecting the Campaign Flow Finally, the marketer can select the Flow they want to use in their Campaign. The Flow determines the means in which the Campaign content (i.e. Offer) will be sent to the customers. In the current release, the Flow is also represented by the Offer rule and is, therefore, coupled to the Offer card. However, the Flow card displays flowcentric information and provides a different view to the marketer. The Flow card in the Campaign canvas displays the currently selected Offer flow and its details. Initially, this card is empty as shown below: Marketers can click anywhere in the card to launch the Add Flow dialog. This dialog presents the twenty most recently updated Offers in the system. The View more results link at the bottom of the list enables users to load the next twenty Offers. Users can also utilize the search box to search for Offers by name or description. The Refresh link refreshes the list of Offers, retaining any search criteria that was previously entered. Each Offer flow is represented by a card in the list. 3-11

This card contains the following details about the Offer and its flow: 1. Offer name. Users can click the name to open the Offer rule. 2. Offer description 3. Channels utilized by this Offer. Each channel is represented by its icon. Supported channels include Email, SMS, Passbook, Push Notification, and File/Database. 4. When the offer was last updated 5. Offer flow 6. Draft status of the Offer Draft icon appears if the Offer is in draft mode Users can view the Offer flow in more detail by clicking on the flow. This opens the flow in a modal window (as shown below). Clicking anywhere outside the modal closes the flow view. Users can select a particular flow by clicking on the corresponding card. To complete the selection process, click the Add button to denote the selected Flow as the Campaign Flow. The Flow and Offer cards are updated to reflect the selected Offer. The Delete link in the bottom right corner of the Flow card (in edit mode) allows the user to remove the selected Offer/Flow. They can then select a different Offer/Flow using the process outlined above. 3-12

Specifying Campaign Goals The Goal performance section of the Campaign allows marketers to define goals for their Campaigns and to monitor the performance of these goals once the Campaign is running. When the Campaign is in edit mode, the Manage goals link is available in the Goals performance section. Clicking this link launches the Manage goals modal dialog. The marketer can use this dialog to specify various goals for their Campaign. Initially, this modal contains three rows, one for each of the supported goal types, as shown below: 3-13

The three supported goal metrics are: Conversion rate: Ratio of the number of conversions (accepts) for this Campaign to the total number of Campaign Offers made. Click rate: Ratio of the number of clicks recorded for this Campaign to the total number of Campaign Offers made. Impression rate: Ratio of the number of impressions recorded for this Campaign to the total number of Campaign Offers made. Users can choose to enter values for all metrics or remove the metrics they do not wish to use. After specifying the desired goals and their target values, use the Apply button to add these goals to the Campaign. The Goal performance section displays all goals that have been configured for the Campaign. Users can continue to make changes to these goals and their target values while the Campaign is in design mode. Once the Campaign is launched, these goals can no longer be edited. 3-14

Validating a Campaign The marketer can utilize the Validate action from the Actions menu to validate their Campaign. This action enables the user to validate the various configurations that they provided for the Campaign. Any violations are categorized into errors and warnings. Errors denote violations that will prevent the Campaign from being launched. Warnings represent best practice violations and other scenarios which may potentially impact Campaign execution. The user can use the edit link to make any necessary updates to the Campaign. 3-15

Running a Campaign Once the user is satisfied with their Campaign s configurations, they can launch the Campaign via the Run button or the Run action in the Actions menu. When this action is initiated, the System automatically performs Campaign validation and reports the validation results to the user. The user must address any validation errors before the Campaign can be launched. Warnings do not prevent the Campaign from being launched but should still be individually heeded and addressed, where necessary. After addressing validation errors and warnings, the user can launch this Campaign. The user can choose to run the Campaign right away or schedule it for a time in the future. If a Planned Start date is set on the Campaign, the System pre-populates the scheduled run time with this value. The user can also choose to refresh the audience for the Campaign before it is run. After the user completes this action, the Campaign status switches to either Running or Scheduled based on the run option that was selected. The Campaign Status card displays this information along with the Campaign run duration (if running) or the scheduled Campaign start time (if scheduled). 3-16

Monitoring Campaign Goals Once a Campaign enters the running stage, the System tracks the Campaign s performance and records clicks, impressions, and accepts in Interaction History (IH). If the user specified performance goals on the Campaign, they can monitor these goals as the Campaign progresses. The Goal performance section of the Campaign displays relevant metrics both for the Campaign as a whole and for each individual goal. First, the number of goals achieved and the total number of goals are displayed. Then, each goal is represented with pertinent metric data. The following information displays for each goal: 1. Goal name 2. Goal status indicator Up arrow when the goal has been achieved, down arrow otherwise 3. Current value for goal Green font when achieved, red font otherwise 4. Current volume for goal (e.g. number of conversions in the example above) 5. Target goal value Set by the user as part of designing the Campaign Goal metrics are fetched each time the Campaign is refreshed or re-opened. To get the latest metric values, the user can simply refresh the Campaign. 3-17

Wrapping up a Campaign Once a Campaign has finished running, it enters the Awaiting Wrap-Up stage. At this stage, the user can perform one of the following actions: Edit the Campaign This action allows the user to update Campaign details and enter actual values for data collected and other pertinent information about the Campaign and its outcome. Wrap-up the Campaign This action allows the user to complete the Campaign and is available in the Actions menu. The user must select a value for the Campaign s outcome and can enter an outcome note as well. Upon completion of this action, the Campaign moves to the Completed stage. Other Campaign Actions This section provides details on the following additional Campaign actions that a user can perform on their Campaign: Rescheduling a Campaign Suspending a Campaign Withdrawing a Campaign Archiving a Completed Campaign Restoring an Archived Campaign Reopening a Completed Campaign 3-18

Rescheduling a Campaign When the Campaign is in the scheduled stage, the user can update the Campaign s run time (if desired) by utilizing the Reschedule action from the Actions menu. The Campaign is once again validated and the user is presented with the same configuration options as the Run action. Upon completing this action, the Campaign moves to either the running or the scheduled stage based on the run option that was selected. Suspending a Campaign If the user desires to make changes to a scheduled Campaign, they can do so by first suspending the Campaign. To do so, the user can utilize the Suspend button or the Suspend action from the Actions menu. The user must also enter a note along with their suspension request. As part of suspending the Campaign, the System sends an email to the user that launched the Campaign notifying them of the Campaign s suspension. This email also includes the note that was entered. Suspending a Campaign returns it back to the In Design stage. The user can make further modifications to the Campaign before running it. Withdrawing a Campaign While the Campaign is in either the design or the failed stage, the user can also withdraw the Campaign if it is no longer needed. To do so, the user can utilize the Withdraw action from the Actions menu and enter a note for the withdrawal. 3-19

Withdrawing a Campaign moves it to the withdrawn stage. No further actions are available on this Campaign. The user can still utilize the Save As button to create a copy of this Campaign. Withdrawn Campaigns are listed under the Withdrawn node in the Campaigns tree. Archiving a Completed Campaign Once the Campaign has finished running, the user can utilize the Archive button to archive the Campaign. Archiving a Campaign moves it from its current node and places it under the Archived node in the Campaigns tree. Restoring an Archived Campaign To restore an archived Campaign, the user can utilize the Restore button. The restored Campaign will be moved from the Archived node to its previous node (based on Issue and Group) in the Campaigns tree. Reopening a Completed Campaign To reopen a completed - either wrapped-up or restored - Campaign, the user can utilize the Reopen button. Re-opening a Campaign places it back in the awaiting wrap-up stage. 3-20

Chapter 4: Segments Segments provide the capability to identify a specific group of customers that match some criteria and to use this group as the starting population for a program run. Segments can also be used within the marketing strategy to decide what offers are made to which customers based on the segments they are in. Historically, the assembly of criteria to describe a segment has been an area in which the marketer had to rely on intuition, prior complex analysis, or guess work. Pega Next-Best-Action Marketing solves this through the use of intelligent segmentation. The solution can leverage the power of decision management (in the area of segment criteria) through the use of statistical analysis to discover predictors within the customer data that contribute positively towards a targeted outcome (like the purchase of a product). The solution also uses sampling strategies to optimize the processing involved in discovering these predictors. High level steps to create a Segment: 1. Select the criteria from the available sources, making use of the recommended criteria assembled by the system. 2. Visually interact with these criteria and see the relationships of these criteria play out on the dynamic Venn diagram. 3. Select the areas of most interest by clicking on the Venn diagram. 4. Save the Segment and run it to populate it with the desired customers. In the background, the solution makes use of the following to produce meaningful results: Analysis Projects - To host the predictors associated with the customer data Samples - To minimize the amount of data consumed The assembly would look something like this: 4-1

Segments are not dependent on Analysis Projects but benefit significantly from the intelligence provided. Segments can be created without the use of Analysis Projects; the effect is to reduce the type of criteria available. Segments are listed in the Business Decisions explorer in Next-Best-Action Studio. Like most other Marketing rules, Segments can be specified at the top level or at the Issue/Group level. The Segment rule contains the following tabs: Tab Name Design Options and Schedule History Purpose Hosts the functionality which allows the user to identify the criteria required to target the customers of interest. In designing a segment, the marketer assembles a set of criteria that initially identifies interesting parts of the population. The marketer then combines these criteria in a variety of ways to specifically target the customers with whom they wish to communicate. Further details are provided in the Designing a Segment section. Hosts configurations for managing Segments, relationships with other Segments, and the scheduling options available for Segment execution. Further details are provided in the Configuring and Scheduling a Segment section. Gives the user a view on the execution activity for the Segment, illustrating when the Segment was refreshed, its row count, and execution times. Further details are provided in the Segment History section. 4-2

Designing a Segment The Design tab of the Segment rule is used to assemble a set of criteria that identifies a specific subset of the population. Upon initial creation, the Design tab looks like the following: This view is initially presented to help guide the user in terms of the main sequence of tasks associated with designing a segment. This form is replaced when the Add Criteria button is clicked for the first time. The first choice for the user is to decide if they want to build a visually composed Segment (using the Venn diagram metaphor) or use a more traditional rule form to describe the criteria. This is managed by toggling the visualization button at the top left corner of the rule form. Both these modes are described in the following sections. By default, a new segment is created with Venn diagram visualization enabled. 4-3

Segment Header Panel This panel is displayed at the top of the Design tab on the Segment rule form. It contains action buttons and displays pertinent information about the Segment. The following table describes the various items that are present in the header panel. Item Description Venn Diagram visualization button Toggle to switch between visual and non-visual modes of creating Segments. Run button Used to trigger manual Segment execution. Enabled when Segment rule is checked in. Load Visualization Estimates button Enabled/displayed upon disabling visualization estimates. Show Customers button Enabled once the Segment is saved and populated. Provides a preview of the customers in the Segment. Main Customer Count Displays the total number of customers in the data set. Refresh icon is enabled when the rule is checkedout and can be used to get the latest customer count. Sample Size Number of customers in the Sample associated to the referenced Analysis Project. In This Segment Number of customers in the Segment as determined by the latest Segment execution. Creating Visually Composed Segments If the user chooses to assemble the segment using a visual metaphor, the sequence to follow when designing the segment is described in the opening screen. This sequence is as follows: 1. Click the Add Criteria button at the bottom of the criteria section. 2. Select the criteria, making full use of the recommended predictors and then configure the query parameters associated with each criteria. 3. Watch what s going on in the interactive Venn diagram, as relationships between the nominated criteria are visualized. Select areas of the Venn diagram that are of interest. Multiple parts of the Venn can be selected to build up a comprehensive picture of the desired target population. 4. Save (and check-in, if applicable) the Segment. 5. Run the Segment to populate it with the target population. 4-4

Selecting a Criterion Clicking the Add Criteria button launches the criteria picker, as shown below: The Selection Criteria dialog presents a set of tabs which individually host a collection of criteria available to the user. The number and type of tabs displayed are dependent on the presence of an Analysis Project (associated with the Segment) and the type of analyzed data available in that project. To select a criterion, select the row for the criterion and press the OK button on the Selection Criteria dialog. Each of the tabs in the criteria dialog is explained below. Recommendations This tab (shown above) holds the top 3 modeled predictors available from the modeled data. These predictors should be the most powerful in identifying the criteria to be used in defining this Segment. The Performance column displays the effectiveness of the criterion in predicting the outcome. In essence, this represents the ability of the criterion to identify parts of the population who would be most likely to exhibit the behavior for which the model has been trained. Modeled Data This tab lists all the predictors available in the Analysis Project that have been assembled during the execution of the modeled analysis. The following pieces of information are listed for each predictor (criterion): Name Name of the predictor Type Type of the predictor: numeric or symbolic Performance Effectiveness in predicting the outcome Description Range of values (for numeric predictors) or the number of symbols (for symbolic predictors) present in the sample set The higher the performance figure, the more powerful the predictor. The columns can be sorted. By default, the criteria are sorted on the performance field. 4-5

Statics This tab lists the set of static attributes from the Analysis Project which have been processed as part of the static analysis execution. The columns describe the attribute s type and the distribution of data (or groupings of data) for each field. Although there s no real equivalent of performance for this type of analyzed data, the count of the number of items within each group can provide valuable insight into the group s relevance. Data Fields This tab enables the user to utilize any data field (associated with the customer entity) as a criterion. The user can search for a criterion by entering its name in the Search Criteria field. Criteria that match the entered value are displayed: 4-6

Alternately, the user can select the browse option to view a tree containing the available entities and a list of the criteria available for each entity. To view criteria on a different entity, simply select the desired entity in the tree. The name, type, and description are shown for each criterion. Communication History This tab provides the user with various pre-defined criteria that associate the customer with their communication history. A meaningful description is provided for each criterion. Some examples of the provided criteria include: Offers Received Offers Received per Channel per Time Period Offer Responses per Time Period Treatments Opened per Time Period 4-7

Defined Segments This tab lists the various Segments in the system. These Segments are organized according to their issue and group hierarchy. Selecting a specific issue or group within the segment tree displays the Segments present at that hierarchical level. Selecting the top level Segment node provides a list of all the Segments within the Application. Configuring a Criterion Selecting a criterion from the set causes that criterion to be placed in the criteria panel in the Design tab on the Segment rule form. The configuration options for a criterion depend upon the criteria type. The Application automatically presents the user with the most appropriate criteria editor based on the type of the selected criterion. This editor enables the user to configure the search parameters to be used in conjunction with the selected criterion. The following table lists the criteria editor types available and the criteria tab which generates criteria of that editor type. Criteria Editor Type Criteria Tab(s) Notes Histogram Modeled Data See Configuring Histograms Categorical Modeled Data, Statics See Configuring Categoricals Long Categorical Modeled Data, Statics See Configuring Long Categoricals String Matcher Data Fields See Configuring Strings Numerical Data Fields See Configuring Numbers Date and/or Time Data Fields See Configuring Dates and Times Segment Defined Segments See Configuring Segments History Communication History See Configuring History Criteria 4-8

Configuring Histograms Any numerical property which has produced meaningful analysis information during Analysis Project execution will be represented as a numerical histogram. An example histogram is shown below: Notes on salient parts of the histogram: The range value displayed under the name of the criterion represents the range of values observed during the analysis execution. The performance value represents the predictive power of this criterion, as determined by the analysis execution. Individual columns of the histogram represent the banding or grouping of the analyzed data. The ranges themselves are displayed as the x-axis labels. The height of each column equates to the percentage of the overall population within the group and is measured by the left y-axis. The red performance line, mapped to the right y-axis, represents the propensity of the individual groups. Propensity is the ratio of the number of positive responses to the total number of responses. The column with the highest propensity is selected by default. Selected columns are highlighted in the same color as the name of the criterion. Users can select (or de-select) groups by clicking on the columns. Multiple groups can be selected at the same time. The System will use the range values associated with each group to compose suitable queries against the customer source. The left edge of a range is treated as greater than or equal to and the right edge is treated as less than. As columns are selected (or de-selected), the number of matching customers found is determined and displayed on the left hand side. 4-9

Configuring Categoricals Symbolic information that is provided as inputs into the analysis execution for modeled or static properties is represented as a categorical bar chart. An example bar chart is shown below: Notes on salient parts of the categorical bar chart: The performance value (only presented for modeled criteria) represents the predictive power of this criterion, as determined by the analysis execution. The length of each bar is proportional to the percentage of the population in that group. Percentage values are mapped onto the bottom x-axis. Propensity information (only present for modeled criteria) is displayed as red dots and mapped onto the top x-axis. Each bar (including the Missing category) can be selected (or de-selected) by clicking on the bar. A tooltip is presented when the user hovers over a bar or the propensity red dot. The tooltips displays the symbols represented by the bar (Range), the percentage of the total population (People), and the propensity value (Performance). As bars are selected (or de-selected), the number of matching customers found is determined and displayed on the left hand side. Clicking on a bar will add the corresponding group to the query parameters for this criterion. In the case where there multiple symbols associated with a specific bar (e.g. the Residual (second) bar above), the System will query for all present symbols. The Missing bar will be translated into queries where the criterion value is null. 4-10

Configuring Long Categoricals If the number of elements for a categorical criterion is greater than 8, it becomes impractical to visualize this criterion as a bar chart. In this case, the System will switch to using the long categorical model which is illustrated below: Clicking the Select Items button presents a list of the individual values. The user can select one or more items from the list by clicking the checkbox next to the item. Upon pressing OK, the number of matching customers found is determined and displayed on the left hand side. 4-11

Configuring Strings When criteria with type Text are selected from the Data Fields tab, the stringbased criteria editor, illustrated below, is provided: Enter the search value for the criterion into the input field. After entering this value, tab out of the field or click the search icon. Doing so will trigger the System to compose the appropriate query to determine how many customers meet the specified criteria. The criteria editor supports the following search types: Contains Starts with Ends with Search Exact Is Null Additionally, the user can also select the following options: Negation negates the current condition Ignore Case performs case-insensitive search Include Null includes null values As a query is performed, the number of customers that meet this criterion are determined and displayed in the Criterion panel. Configuring Numbers When criteria with a numeric type (Integer, Double, etc.) are selected from the Data Fields tab, the numerical criteria editor, illustrated below, is provided: 4-12

This editor functions similarly to the string-based criteria editor, but provides additional query capabilities. This criteria editor can describe two types of search matching strategies: 1. A range based strategy which queries values between the lower and upper bounds 2. Numeric test operations using a comparison operator (such as greater than, equals, etc.) and a desired value. Additionally, the user can also select the following options: Negation Negates the current condition. This allows the user to express interest in customers where the criterion value is not null, for example. Include Missing Values Instructs the System to include searching for null values as part of the composed query. Configuring Dates and Times For configuring date and time based properties, the Date/Time criteria editor is provided. This enables users to configure criteria for a range of dates and times or perform standard comparison tests against date and time values. Select between the following options for querying the data: Date Specify date ranges/values Date & Time Specify date and time ranges/values Time Specify time ranges/values Is Null Search for entities where the criterion value is null 4-13

Relative Specify the relation operator to use (Last or Next) and the desired number of days (say x). This option uses the current time and returns results where the criterion value is within the last/next x days. For example, users can query for new customers by examining only those customers whose relationship start date is in the last week, as shown below: For the date and/or time options listed above, the next choice is the comparison function. The choices available are the same as those in the numeric editor (range based or comparative). Upon clicking in the input field(s) for date/time specification, a popup calendar or time picker is presented to aid in the specification of the date/time value. The calendar, shown below, is available for specifying dates. Click the desired date to select it as the input value. The time picker, shown below, is available for specifying times. Select values for hours, minutes, and AM/PM. These changes are displayed in the time in the header. Click Set to apply the selected time value to the input field. 4-14

When used by itself, the Time query will match the time across multiple date values. This enables the user to specify powerful queries, such as customers who visited the branch between a specified range of hours (e.g. 12pm - 2pm). Configuring Segments When Segments are used as criteria, the Segment criteria editor, illustrated below, is provided: The level of control for this criterion is limited to simply controlling the direction of the relationship. When including a Segment, the default behavior is to assume that we want to query customers who are also in the nominated Segment. Clicking the Negation checkbox reverses the query and returns customers who are not in the nominated Segment. Clicking the refresh icon will update the customer count and last updated date for the Segment with its most recent values. Clicking the Segment name will open the nominated Segment s rule form. Configuring History Criteria When one of the pre-defined Communication History criteria is selected, the history criteria editor, illustrated below, is presented: 4-15

The actual fields displayed in the editor are contingent upon the input requirements of the selected criterion. Most of the input fields provide either smart-prompts or value options to assist the user in specifying the criteria values. This is demonstrated with the Offer field below: The input fields displayed could include: Offer Name of the Offer. Offer name is displayed with its associated Issue and Group. Channel Channel of communication for the Offer/Treatment (e.g. Email, SMS). Direction Direction of communication: Outbound or Inbound. Response Behavior and Response value for a customer s response to an Offer. Treatment Name of the (Email/SMS/ ) Treatment. Time Period Applicable date/time value/range. Uses the Date/Time criteria editor. Organizing Criteria into Sets Each time a criterion is added to the canvas, a circle is added to the Venn diagram. This circle represents the size of the population identified by that criterion and its relationships to other criteria. To properly represent all possible relationships among criteria, only three criteria can be associated at one time with a Venn diagram. To add more criteria to the Segment, users can organize their criteria into sets. Each set has its own associated Venn diagram and can, thus, hold up to three criteria. The first (Set #1) set is automatically added when the user initially selects the Add Criteria button. Clicking the Add Criteria icon in a set that already contains three criteria will automatically generate the next set for storing the new criterion. When the new criterion is selected, it will get added to the newly generated set, as shown below: 4-16

When a new set (say Set #3) is created, the combination of criteria intersections selected for the immediately prior set (in this example, Set #2) serves as the starting population for the new set. This is true for every new set with the exception of the first set (Set #1) whose starting population is the customer base. Users can also choose to manually create new sets by clicking the add icon (shown below) which is located to the left of the first set. This further enables the user to combine criteria to form powerful queries to hone in on the desired set of customers. Users can also rename sets to better describe the criteria they contain/specify. To rename a set, double-click on the set name and enter the desired name. Click anywhere outside the set name to save the set name entered. Removing Criteria At any point, the user can remove a criterion from the selection by clicking the remove icon [x], located at the top right corner of the criterion entry. 4-17

A set of criteria can also be removed by selecting the desired set and clicking the remove set icon [x], as shown below: Selecting the Desired Population Having added a criterion to the canvas, the visualization will immediately render that population as a circle in the Venn diagram. The circle may be the first in the frame if it s the first criteria or it may be the second or third depending on how many criteria already exist. The visualization layer will size and position the newly created circle to best describe its relationships with the other parts of the Venn diagram and this positioning will change as criteria are added or removed. The user selects the parts of the overall Venn diagram that represent the desired target population. This is done by clicking the individual parts of the Venn diagram. In a fully populated diagram, there are eight areas that may be selected. The user can select one or more of these areas. The following graphic illustrates the eight possible areas in a Venn diagram: There is a base population (P) that represents the total customer population. Each circle represents a criterion and has a number of cells, some shared with other circles. All, any, or none of these individual cells can be selected (or de-selected) by clicking on the specific Venn cell. Additionally, the population that falls outside of the area defined by the set of criteria can also be selected (or de-selected). 4-18

During each interaction, the solution will give the user the current state of the selected intersections. This is displayed in the Selected Intersections grid, which is located to the right of the Venn diagram. This grid also includes the identified row count for the each selected intersection. The total count contained in all selected intersections will be shown at the bottom. This total is the population (or estimated population, depending on the estimation type used) when the segment is populated. The options involved in selecting the appropriate parts of a population are further explained with the use of an example scenario. In this example, a user wants to select all males in the most profitable age group who are not detractors (as determined by their net promoter score). The following represents a potential set of criteria to determine the desired starting population. 4-19

Specifying the criteria above might result in a Venn diagram representation that resembles the following: Criteria are created and visual feedback illustrates how these individual populations relate to each other. To enable the Segment to target males in the most profitable age group who are not detractors, the user simply selects that portion of the Venn diagram. The Venn diagram responds by painting the selected area in a more saturated color and the selected intersections table is updated with the selection choice, as illustrated below: 4-20

The criteria that are applied for the selected area are shown with checkmarks in the selected intersections table. The number of customers that belong in the selected intersection is also displayed. The user can select other areas that may also be of interest. As a region is selected, an entry (denoting the selected criteria) is added to the selected intersections table. This is shown below: The previous diagram shows that there are two other selected intersections, each contributing a set of customers to the overall total selected population that has now grown to 154 from the original 12. There may be situations where selecting one of the intersections may be difficult to do due to its size. In our example scenario, we would experience this situation if we wanted to select the intersection of our age, gender, and net promoter criteria. To overcome such situation, the Select from List link is provided along with the selected intersections grid. Clicking this link displays a dialog box with check boxes for all areas of possible intersection, thereby making it easier to select any part of the Venn diagram. Our desired intersection can be selected from this list, as displayed below: 4-21

The checkered pattern at the end of the list represents everyone outside the union of the nominated criteria, as illustrated below: This area is also selectable and can contribute its part to the overall population, as demonstrated above. At any point, the user can hover over areas of the Venn diagram, the criteria in the criteria panel, or the selected intersections to get further information on the area. Additionally, hovering over an area in the Venn diagram or a row in the selected intersection table will have the effect that both related areas will be (temporarily) colored differently to highlight their relationship. As mentioned in the prior section, criteria can be hosted in multiple sets. The customer source for the first set is the set of all customers. The customer source for any subsequent set is the union of all selected customers in the set immediately prior to it. As an example, let s consider our earlier Segment which contained all males in the most profitable age group who were not detractors. The selection for this customer base gave us 12 customers. Let s further impose the criteria that we are only interested in those customers who reside in the United States. Adding this criterion will automatically trigger the creation of a new set since we already had three criteria on the first set. Furthermore, the result counts returned for this set will be a subset of the 12 customers that were selected by the first set. 4-22

A new Venn diagram will be rendered for this set with a single circle representing the criterion shown above. As other criteria are added to this set, their appropriate circles will be rendered in the Venn. Inspecting the customer source for this set (displayed to the right of the Venn diagram) reveals that the source is Set #1 and the number of customers in the source is 12. Relationships between sets can be viewed by clicking the View Set Relationships icon ( ). Clicking this icon displays a visual representation of the customers determined by each set, along with their individual counts and the total customer count. 4-23

Hovering over a particular set displays the set name and the percentage of the total customer population that is contained in the set. Clicking on the set name in the legend separates the set from the other sets. Clicking on the cylindrical portion representing the set takes the user to the selected set. After the user has interacted with the visualization and selected the areas of the population that interest them the most, they can move into the next phase of Segment creation. This involves saving the Segment definition and executing the Segment to populate it with the customers who meet the specified criteria. Disabling Visualization Estimates The Segment rule provides significant power and utility to the user by displaying realtime visualizations of the user s criteria along with estimates for the number of customers in each selection. When the data source of customers is massive, it is possible for a visualization to take longer than desired. Each criteria insertion or modification requires a re-fetch of the customer counts in order to scale the Venn diagrams appropriately. In addition, counts are potentially needed for each of the eight possible areas of a fully drawn Venn diagram. Thus, there is a possibility of performance degradation for large customer data sets. In order to alleviate this problem, the user has the option of disabling visualization estimates while building the Segment s criteria. The current status of visualization estimates is displayed by the Active Visualization Estimates checkbox. By default, visualization estimates are disabled. To turn on visualization estimates, simply enable the checkbox. When visualization estimates are disabled, the following visual differences can be observed: Each circle in the Venn diagram is of the same size. All places where customer count estimates would be displayed will show the text Pending. This includes the following: Criterion field Venn diagram tooltips Selected Intersections grid Customer source counts for sets 4-24

The Load Visualization Estimates button is available to the right of the Run button. Apart from these differences, Segment visualization and its various controls will continue to function just as before. Users can continue to visualize criteria and select the appropriate areas of interest in the Venn diagram. The visualization representing our prior example - of all males in the most profitable age group who are not detractors - now resembles the following: Once the user has configured the criteria and desired selections in the Segment, they can choose to load the estimates for the visualization. This can be done via the Load Visualization Estimates button. Upon clicking this button, the Segment rule is saved and the user is presented with a dialog to confirm the load request. Select Cancel if more updates need to be made to the Segment. 4-25

After clicking Confirm, the Segment can no longer be modified until the System has loaded the visualization estimates for all areas of interest. A panel, indicating that the estimates are being loaded, is displayed to the user. Once the System has completed loading the estimates, the estimates are displayed in all appropriate areas replacing the prior Pending text. In addition, the Venn diagram rescales the criteria circles and intersections to accurately reflect their relative sizes. This is illustrated using our prior example: The above Venn is an identical version of our original Venn when visualization estimates were active (enabled). 4-26

Creating Non-Visual Segments The user can switch to the visualization disabled mode by toggling the Venn diagram visualization button (which is located to the left of the Run button). Doing so, switches the Design tab of the Segment rule to an approach that uses the Report Definition style of constructing criteria. In this approach the user provides a series of criteria in by identifying the appropriate column, the relationship type, and the value for which to search. Criteria are added by clicking the Add filter icon/link and adding additional rows. These criteria are then combined in the Filter conditions field to allow the user to describe the logic for applying the various criteria. The Column Source field is supported by a smart prompt which will helps the user to select the property they are interested in querying. The Relationship field lists appropriate operations. Use the Options icon case and Use NULL if empty. to add filter options, such as Ignore 4-27

Additionally, the user can include references to existing marketing Segments and also describe the desired relationship (in or not in) with the existing Segment. This is done within the Segments sub-section in the Design tab. To combine Segments in the right order, use the Filter Segments field within the Segments sub-section. Once the various fields are configured, the Segment can be saved and executed. This is explained in the following section. Saving and Running a Segment This part of the process is common for all Segments and independent of the mode in which they were composed. Once the Segment has been suitably designed, save the Segment rule. Once the Segment rule is saved (and checked-in, where applicable) the Run button is enabled. Click this button to trigger execution of the Segment. This will display the Run Segment Now? dialog, which presents an overview of the Segment, its current population, and the last time it was executed. 4-28

The warning at the bottom makes the user aware that modifying a segment will affect any existing programs or schedules that reference this segment. Upon clicking Confirm, the System will assemble the appropriate background assets (to support Segment execution) and then populate the Segment. While the System executes the Segment, a status bar is displayed with a Stop button in case the user wishes to stop the execution. Once Segment population is complete, the Segment header will be updated with the latest count of customers in the Segment. The Segment is now created and populated and will appear in the segment criteria picker for use by other Segments. The Segment is available for use by programs as the starting population. It can also be referenced on the strategy canvas to support marketers who want to use Segments in their strategy design. 4-29

Configuring and Scheduling a Segment The Options and Schedule tab of the Segment rule enables the user to configure various options on the Segment and to configure a schedule for the Segment s execution. Upon initial creation of the Segment, the Options and Schedule tab is as shown below: The user can utilize the Segment Image field to reference an image (uploaded in PRPC) which represents this Segment. This image is displayed in the Audience card and Segment selector in Campaigns. Refer to the Campaigns chapter for details. 4-30

From the Data Options panel, a Virtual Segment is one which accesses its customers in real time. The drawback is that it is more expensive to use as the criteria are evaluated every time they are referenced. A virtual Segment is useful if the Segment and the targeted customers need to always be up-to-date (live). The next two options control how a segment is refreshed and what level of control each segment can exert. A Refreshable Segment is one that can be refreshed if it used by another Segment. If a Segment refers to another Segment as part of its criteria, there is a dependency between the two. If a segment is marked as refreshable, then its contents will be refreshed when it is executed as part of a dependency chain. If the Refreshable Segment checkbox is not set, then its contents will remain untouched and used as is in the criteria evaluation of the parent. In this way, users have control over how Segments get refreshed. Normally, Segments should be marked as refreshable as this would ensure that any parent Segment is set up in the most accurate way. However, a specific Segment execution may be too expensive (in terms of time and processing resources) to perform every time a parent Segment is executed. In this case de-selecting the refreshable flag will prevent the child Segment from being refreshed when the parent is executed. Top level Segments in a dependency chain are always refreshed because it is the Segment that is being re-populated. This flag only comes into play for Segments which are in a lower part of the dependency chain. The effect of having a nonrefreshable Segment within the chain will be to prevent any further inspection of child Segments beneath the non-refreshable Segment. If the Refresh Child Segment option is selected, any Segments referenced by this Segment will be refreshed when it is refreshed (as long as their refreshable setting is enabled). This allows the user to control the cascading effect of Segments. It may be undesirable to cascade the refresh operation on certain Segments and this option provides that level of control. Note: Refer to the Control Groups chapter for information on the Select a portion and Mark segment results as control group options. Scheduled Segment Execution Segment execution provides support for handling the execution of various tasks in the background. The Enable Schedule checkbox enables a Segment to be executed once or as part of a recurring schedule. The scheduling panel provides a set of options for configuring the background execution of segments. 4-31

The Delivery Options panel enables the user to send email notifications when a scheduled Segment execution occurs and/or when the Segment is refreshed from a Program. The user can further customize the email using the provided fields. The intended recipient of the email must be an operator in the System. Note: The scheduling of background Segment execution and the removal of any prior schedule only takes place once the Segment rule has been checked in (where applicable). 4-32

Segment History The history tab on the segment rule provides: Details of previous segment execution runs Segment description Usage areas History trail for the segment The user can click the Refresh Activity History button to reload the latest Segment statistics. The following details are provided for each Segment execution entry: Last Run Date and time of the Segment population Reason Reason for the Segment population e.g. requested by user, triggered by schedule, etc. Execution Time Execution time (in ms) for the Segment population Row Count Number of customers in the Segment 4-33

Intelligent Segmentation Creating and managing Segments is a central theme within a marketing solution. The concept of identifying a group of customers, to form a Segment, and then using this Segment within the marketing mechanisms hides a degree of complexity which is often overlooked: How do you identify those customers? It is not enough to present the user with the ability to select various criteria and play with these until something starts to take shape. While this is a key aspect of the overall approach, the selection of criteria can become nothing more than guess work. This is where the support for intelligent segmentation comes into play. Recommended criteria have been assembled from statistical analysis of various input sources and are ranked according to their power to act as predictors against certain outcomes. This section describes how these criteria are created. At a high level, the solution provides support for a concept called Analysis Projects. This creates a set of predictors based on Samples of the main customer data. These Samples provide a sample of the overall population. An Analysis Project takes a sample and performs a range of statistical analysis activities to determine which data fields have predictive power or influence when measured against a nominated goal, such as the purchase of a product or service. Configuring Samples Samples are created and managed via the Sample Populations landing page, which is accessible via: Populations -> Segmentation -> Segmentation Support -> Sample From this landing page, users can create new and open existing Samples. To create a new Sample, select New from the landing page. Provide the following information in the New form: Unique name for the Sample Issue/Group classification Click Create to open the Sample rule form which allows the user to configure the specific details of the Sample. A new Sample resembles the following: 4-34

The following table describes the fields that are available in the About This Sample Population panel: Field Description Sample Source Denotes where the sample is going to be taken from, i.e. the main backing source for the Sample s data. Anticipated Sample Size Describes the desired size in terms of an absolute number (Fixed) or a percentage (e.g. 10%, as shown in our example). Sample Strategy Describes various sampling strategies. The options available are Random, Ascending, and Descending. If either of the last two is chosen, the user needs to identify the field in the data set on which to order. This is specified in the Ordered On field, which is displayed when either Ascending or Descending is selected. 4-35

The entries in the Sample Fields section (displayed below) represent the list of fields within the Sample and their corresponding column names, to which they map, in the backing table. The user can use this list to remove (de-select) fields that they know will not be useful in the downstream analysis. 4-36

In the example above, the Customer ID, full name, email address, mobile number, and partition key have been de-selected. These will not be valuable for further analysis. As a general rule, fields that are system related (e.g. partition key) or genuinely unique for individual customers (such as their customer id or their full name) are typically fields that have no value from an analysis perspective. After configuring the sampling settings and selecting the desired fields, save the Sample rule. This action creates the supporting rules for the Sample. Click the Save and Run button at the top of the rule form to populate the Sample. Clicking this button saves the Sample rule (if applicable) and launches the Run Sample dialog, as shown below: Upon clicking Confirm, the Sample is populated and the Sample size field is updated to reflect the number of rows in the Sample. In addition, an entry is added to the Sample Statistics panel (on the History tab) containing details of the Sample population. 4-37

The contents of the sample can be previewed via the Preview button. Clicking this button launches a report definition that presents the contents of the Sample along with their associated customer data. Like Segments, Samples can also be configured to execute in offline mode so as to defer any processing expenses (time and/or cost) to a more suitable time. This option can also be used to perform the population operation on a recurring schedule in order to prevent the Sample data from becoming stale. These configuration options are listed in the Schedule tab and are identical to those for scheduled Segment execution. The Sample is now configured and ready for use. It is listed on the Sample Populations landing page along with its pertinent information. Configuring Analysis Projects Analysis Projects analyze Sample data in order to assemble a set of predictors that have influence on the nominated outcome or to conduct distribution analysis against the data set. Analysts Projects are created and managed via the Analysis Projects landing page, which is accessible via: -> Segmentation -> Segmentation Support -> Analysis Projects From this landing page, users can create new and open existing Analysis Projects. To create a new Analysis Project, select New from the landing page. Provide the following information in the New form: Analysis Project name Sample Select an existing Sample from the drop-down list. A pre-existing Sample is required for creating an Analysis Project. Click Create to open the Analysis Project rule form. A new Analysis Project resembles the following: 4-38

The following table describes the tabs that are available in the Analysis Project rule form: Tab Static Analysis Modeled Analysis Schedule Results History Description Provides configuration for Static Analysis runs. Provides configuration for Modeled Analysis runs. Provides configuration for scheduled Analysis Project execution in offline mode. Provides support for reviewing the results of the analysis runs. Hosts analysis execution statistics and standard rule history fields (usage and description). The following two types of analysis are currently supported: Static Analysis provides support for Data Distribution analysis. This provides a convenient way to understand what the groups of data look like for a specific property and how many occurrences exist within each group. Modeled Analysis provides a statistical assessment of the significance of the individual properties and their influence or power in predicting the targeted outcome. Both analysis types help provide more color and useful configuration detail when assembling Segment criteria, thereby helping to reduce the guess work (or intuition) previously identified as the main issue with more traditional approaches to segment construction. 4-39

Static Analysis To configure the Analysis Project for static analysis, review the available properties (which have been retrieved from the supporting sample) and describe which grouping type is required for each property. Use the Refresh button to refresh the list of Sample fields if they have changed since this Analysis Project was created. Any property marked with the Distinct Count grouping type will be processed during the execution phase and a distinct count of the grouping will be performed. Any property with No Grouping set will be ignored. In this example, Age has been marked as being ignored for static analysis. However, it may still be used as part of the modeled analysis. It is likely to be a continuous value with a large number of groups and, therefore, will not be that useful from a grouping and distribution analysis perspective. On the other hand, NetPromoterScore has been marked for Distinct Count analysis. This property should have a range of values from 0 10 and knowing how many customers are in each group would be very valuable. Static Analysis Execution To manually execute the static analysis, go to the Results tab and click the Run button in the Static Results panel. The Analysis Project needs to be saved (and checked-out, where applicable) for the Run button to be enabled. Clicking this button instructs the system to perform static analysis against all nominated columns. This is illustrated below: 4-40

Each row in the Static Results grid correlates to one of the properties configured in the Static Analysis tab. For each property, we can see the number of groups that have been identified and the number of values present. In the above example, the Gender property has 3 distinct groups (including Missing ) and a total of 669 values, as shown below. We can see the distribution of data across the two main groups, M and F. We can also see that there are two rows with missing or null data. The description field offers users the ability to add more friendly text to describe the values represented by the category. This is very useful when the grouped data is based on non user-friendly properties, such as product codes or other cryptic classifications. These analysis results, along with their modeled variants, are stored within the rule and, as such, are only made permanent when the rule is saved. Modeled Analysis Distribution analysis is useful as a first pass to describe how the data in our data source is organized and may give some insight as to where to focus any criteria construction in Segments. The modeled analysis approach improves on this significantly through the use of statistical analysis. This helps identify properties that have a high influence on the targeted outcome, completely removing the need for guess work or intuition when assembling criteria in a Segment. 4-41

A key aspect of this analysis approach is the use of a closed loop feedback mechanism. Sample data is used to train or drive the creation of modeled analysis predictors. The sample data brings with it details of previous interactions and responses to offers made. While we are creating modeled analysis predictors that have predictive power over various outcomes, they are based on positive and negative responses to previous offers. Configuration for this form of analysis is provided in the Modeled Analysis tab. This includes the following configurations: Select Offer Select Interaction Details Select Predictors Define Behaviors Each of these configurations is explained below. Select Offer This panel enables the user to train the analysis on specific instances of responses to previously delivered offers. In this section, the user can specify the level of their interest (Issue, Group, or Offer). The user uses the drop-downs (displayed above) to select the Issue, Group, or Offer on which they want to focus. Leaving any of these values blank will bring through all entries for the parent category. In the example above, selecting the Sales Issue and the Handsets Group will force the analysis to consider responses to all offers that belong under Sales/Handsets. Analysis Projects can be created with predictors based on actual responses to previously offered products. Alternately, they can also be trained against similar (or group level) offers which can act as proxies for a new product offering. For example, consider the case where a user wants to create some predictors that will help identify successful sales opportunities for a product not yet released. There is no history (or previous transactions) that can be used to inform this choice. However, there might be similar products or product groups which could be used to help start the analysis process. By setting up the analysis to use these proxies, the user can start to assemble likely predictors that will help illustrate the type of customers who are likely to buy the new product. 4-42

Select Interaction Details In a similar way, the interaction details may also be a useful set of dimensions on which to train the analysis. In this section, the user can direct the analysis to focus on the interaction dimensions of Direction, Channel, and Treatment. The user can also restrict the analysis assessment to apply only to responses to those offers that were offered after a specified date and time. Smart prompts are provided for each of the input fields to assist the user in selecting the right values. Select Predictors This section hosts the set of predictors available for analysis. The user is able to remove (or even add) properties from the base Sample. There may be cases where it s obvious that a certain type of data may have no predictive value. It might be in the default list that is generated when the Analysis Project is first created. It may even be used by the static analysis (for distribution), but might have no predictive value in modeled analysis. In such cases, the predictor can simply be removed from this section. The predictor type is initialized to the default value for the property type of the predictor. If required, this can be changed to a different value using the provided drop-down. A sample set of predictors is illustrated below: 4-43

Define Behaviors This section allows the user to select positive and negative outcomes for the modeled analysis based on the set of responses received so far. The Available Behaviors section lists all distinct (non-neutral) responses received so far, within the constraints described by the selected offer and selected interaction dimensions. The user should review each available behavior and mark it as a positive, negative, or ignored behavior for the analysis. The list of available behaviors can be reloaded via the Refresh button. This is particularly useful if changes have been made to the nominated offer and/or interaction dimensions. By default, each response is marked as Ignore and will not be considered in the modeled analysis execution. Changing a response to be treated as Positive or Negative moves the response type into the appropriate response category ( Positive Behavior or Negative Behavior ). A sample configuration of behaviors is illustrated below: Modeled Analysis Execution Once the Modeled Analysis tab has been suitably configured, modeled analysis can be performed and previewed. To manually execute the modeled analysis, go to the Results tab and click the Run button in the Modeled Results panel. The Analysis Project needs to be saved (and checked-out, where applicable) for the Run button to be enabled. Clicking this button instructs the System to perform modeled analysis against all nominated configurations. The System will pump the Sample data through the Adaptive Decision Management engine and retrieve any predictors identified. An example illustration of executing modeled analysis is displayed below: 4-44

The data displayed above is in a preview form. The user can select to Cancel the results of this analysis or Accept them. If the results are accepted, they replace any existing modeled analysis results which may be present on the rule. Each predictor is shown with its performance rating, the groupings constructed by the analysis engine, the number of positive and negative responses, and the predictor type. As with the results of the static analysis, the details for each predictor can be exposed by clicking the arrow-head in the left hand column. In the example above, Age is seen as having a high performance rating among the available predictors. Expanding the Age predictor shows the following: Each row represents a grouping of age ranges. Each range is displayed with its propensity, number of responses (count), and its percentage of total responses. As a reminder, propensity represents the ratio of positive responses to total responses. Age is an example of a histogram (numeric) predictor. A categorical (symbolic) predictor such as pycountry looks like this: 4-45

In this example, the various symbols are shown instead of the ranges. The tooltip for a truncated symbol will show the other symbol values. For both static and modeled analysis, the last run date is presented alongside the Run button. Separate execution of static and modeled analysis is only present in manual (online) mode. When an Analysis Project is scheduled to execute (offline mode), both types of analysis will be executed at the same time Scheduled Analysis Project Execution The options available for scheduling offline execution of Analysis Projects are identical to those for scheduled Segment execution. This is illustrated below. The schedule is generated when the Analysis Project is checked in. Any prior schedule is deleted. Results of the analysis execution can be seen on the History tab. 4-46

Using Analysis Projects in Segments As mentioned earlier, the user can nominate an Analysis Project when a Segment is created. Associating a Segment with an Analysis Project will give the Segment the option to pull in static and modeled analysis predictors when assembling the Segment criteria. To associate an Analysis Project at Segment creation, ensure that the Segment Subject is Customer and select the desired Analysis Project, as shown below. This can also be done on the Segment rule form, in the About This Segment section (shown below), by selecting a different Analysis Project. Changing the analysis project for a segment can also be achieved on this form, but doing so will clear down any existing criteria that may be present on the rule form. The user is warned that this will happen and given the option to cancel the change. The last run date for the Analysis Project is also displayed. 4-47

Additionally, having an Analysis Project available enables Segment visualization to use different estimation strategies when calculating the population sizes. The following table describes each of the options for Visualization Estimates. Type Description Real The counts for the populations within the Venn diagram are calculated by querying the base customer data set. Benefits: Counts are accurate. Drawbacks: May be a slow or expensive process if there are many rows within the data set. Sampled The counts for the populations are queried against the population within the Sample. For example, if the sample described 10% of the population, the counts presented in the Venn diagram will be 10% of the true value. Benefits: Less expensive to perform counts against the smaller data size. Drawbacks: Counts are only an estimate based on the sample size. The smaller the sample is, the larger the estimation error will be. Extrapolated This approach uses the sampling approach but extrapolates the results based on the ratio between the sample size and the main data source it is working with. Changing the visualization estimation method will cause the Venn diagram to be refreshed and a new set of counts produced (if visualization of estimates is currently active). 4-48

Chapter 5: Control Groups In an experiment, a Control Group is a group, separated from the rest of the experiment, which is isolated from the variable being tested. In marketing, Control Groups can be used to assess the performance of marketing initiatives. Next-Best-Action Marketing provides support for defining and populating Control Groups. In addition, the Strategy rule also provides support for assessing whether a customer is in a Control Group. This allows the user to treat Control Group members differently. For example, Control Groups members might not receive a particular Offer. Note: Next-Best-Action Marketing uses Interaction History (IH) to maintain Control Group memberships. This allows Control Groups to be used in both batch and real-time strategies. Creating a Control Group In the marketing Application, Control Groups are specially configured Segment rules. To create a new Control Group, perform the following steps: 1. Create a new Segment rule. Alternately, an existing Segment rule can also be converted to a Control Group. 2. Configure the "Design" tab of the Segment rule as desired. Specify the criteria fields to use and select the intersections that represent the Control Group. 3. On the "Options and Schedule" tab, enable the Control Group checkbox and, optionally, specify a validity period for the Control Group. 4. Optionally, select whether the Control Group should be a random sampling of the selected Segment criteria results. To do so, enable the "Select a portion..." checkbox on the "Options and Schedule" tab. If selected, specify the maximum sample size or the percentage of the criteria results to be use for the Control Group. If this option is not selected, the entire set returned by the Segment criteria will be used as the Control Group. 5-1

Note: The Sample option can also be used independently on a Segment (without the Control Group option) to create a Segment with a random sampling of the selected criteria's results. 5. Save the Segment. Note: Control Group segments cannot be configured as virtual segments. Populating a Control Group Like normal Segments, Control Groups can be populated in the following ways: 1. Manually, via the Run button on the Segment rule form 2. Automatically, based on a schedule specified on the "Options and Schedule" tab Once the Control Group has been populated, the number of customers in the Control Group is shown in the Segment toolbar. The "Show Customers" button can be used to view the customers in the Control Group. Determining Control Group Membership The Strategy rule can be used to determine whether a particular customer is in a specified Control Group. A sample Strategy demonstrating this use is shown below. 5-2

At a high level, this Strategy pushes out a selected Offer to customers that are not in a selected Control Group. The salient shapes in this Strategy are explained below. 1. Interaction History shape The Interaction History shape is used to fetch the Control Group membership records for the customer. To do so, the following conditions are specified on the shape: MktType - This must be set to "ControlGroup" MktValue - This should be set to the name of the Control Group In addition, the last days value is cleared in order to include all IH records. To minimize the number of fields being retrieved, the "Manually select properties checkbox is enabled. 5-3

The following image shows the properties that should be selected: 2. Group By shape The IH shape fetches all records that meet the specified criteria ordered in reverse chronological order (latest entry first). The latest IH entry (if one exists) depicts the current membership status in the specified Control Group. To get at this entry, the Group By shape can be used to select the first entry. No additional grouping/aggregation criteria need to be specified. 3. Filter shape The Filter shape specifies the criteria to output the input Offer. The filter expression must inspect the status of the last membership record. This value is stored in the "pyoutcome" field of the record. There are three possible values for this field: Member - Customer is currently IN the specified Control Group NonMember - Customer is currently NOT IN the specified Control Group, but has previously been a member of this group. (Missing) - Customer is currently not and has never been in the specified Control Group. The filter expression must also account for Control Group validity dates, if they have been specified. The following represents a sample filter expression that takes the above factors into account: 5-4

!( @equals(latestcgstatus.pyoutcome,"member") && @if(@equals(latestcgstatus.controlgroupvaliditystart,""), true, @(Pega-RULES:DateTime).CompareDates(@(Pega- RULES:DateTime).CurrentDateTime(), LatestCGStatus.ControlGroupValidityStart)) && @if(@equals(latestcgstatus.controlgroupvalidityend,""), true, @(Pega- RULES:DateTime).CompareDates(LatestCGStatus.ControlGroupValidityEnd, @(Pega-RULES:DateTime).CurrentDateTime())) ) 5-5

Chapter 6: Strategies A Marketing Strategy enables the user to match the Offers that are available for a Program to the customers in the target population. Users can design Strategies to ensure that each customer is targeted with the Offer that is most suitable for them. The Strategy rule enables the user to apply various business goals and prioritization criteria to make this determination. A Marketing Strategy is associated to a Program via the Program s Configuration Panel. After selecting a Strategy, the Public Component (within the Strategy) should also be selected. Strategies are listed in the Business Decisions explorer in Next-Best-Action Studio. They can be stored at the top level or can be categorized into Issues and Groups. Note: Unlike other Marketing rules, the Issue/Group categorization is not automatically populated for new Strategies. Verify that the desired Issue and Group are selected before clicking the Create button on the Strategy new form. For information on creating a Strategy rule and configuring its various tabs, refer to the PRPC Help documentation. Using Segments within Strategies Strategies built within Pega Next-Best-Action Marketing can also use Segments to filter results directly in the Strategy itself. This is done by adding a Segment Filter shape to the Strategy canvas (accessible via Arbitration -> Segment Filter). 6-1

A Segment Filter shape can reference any Segment rule that has been created in the System. Refer to the Segments chapter for more information about creating Segment rules. The Segment Filter shape can be connected to other Decisioning shapes, as appropriate, to apply Segment-based filtering at appropriate levels in Strategy execution. A sample Strategy which uses the Segment Filter shape is shown below: 6-2

Using Contact Policies within Strategies Strategies built within Pega Next-Best-Action Marketing can also use Contact Policies to restrict the strategy output based on channel limitations specified in the Contact Policy rule. This is done by adding a Contact Policy shape to the Strategy canvas (accessible via Arbitration -> Contact Policy). The Contact Policy shape enables the user to reference a Contact Policy rule that has been created in the System. Refer to the Contact Policies chapter for more information about creating a Contact Policy rule. The Contact Policy shape can also be used to restrict the number of propositions (Offers) output from the shape. This is governed by the Output field. The two options available are: 6-3

First x Select this option to restrict the output of the Contact Policy shape. In this option, if multiple inputs to the shape satisfy the referenced Contact Policy rule, only the first x (where x is a positive integer) of these are output. The default value for x is 1. All Select this option to output all input propositions that satisfy the referenced Contact Policy rule. Note: Since the Contact Policy shape can (potentially) output a portion of the inputs, it is recommended that propositions are prioritized before being passed to the Contact Policy shape. Like other shapes on the Strategy canvas, multiple Contact Policy shapes can be chained together. This is particularly useful in enforcing multiple limits on the same channel of communication. For example, one Contact Policy rule could set daily limitations of the Email channel while another sets weekly limitations on the Email channel. By chaining two Contact Policy shapes (which reference the above two rules), the user can ensure that both daily and weekly channel limitations are being satisfied. If either of these limitations is violated, the Offer will not be output. This usage is illustrated below. Requirements for Contact Policies to be applicable In addition to adding a Contact Policy shape to the Strategy, the following conditions must be satisfied for the Contact Policy limitations to be applied: Presence of input Offers Since Contact Policies limit the Offers being output by the Strategy, a Contact Policy shape must have some Offers (propositions) as input to the shape. Outbound communication Contact Policies only apply to Offers (propositions) being communicated on an outbound channel. This is validated by inspecting the pydirection property on each proposition. For Contact Policies to be applicable, this value must be set to the literal string Outbound. Restricted channel Contact Policies only apply to Offers (propositions) being communicated on a channel that is restricted in the referenced Contact Policy rule. This is validated by inspecting the pychannel property on each 6-4

proposition. For the Contact Policy to be applicable, this value must be set to match (exactly) one of the channels in the referenced rule. Available Contact Policy Contact Policy limitations are only applied if the referenced Contact Policy rule is marked as being available. Applicable Contact Policy If date validity criteria are specified on the referenced Contact Policy rule, the Contact Policy limitations are only applied if the current date meets these criteria. In cases where the applicable start date is in the future or the applicable end date is in the past, the limitations specified in the policy rule are ignored. If the conditions specified above are satisfied, the limitations specified in the Contact Policy rule are applied. Otherwise, these limitations are ignored. The output specifications of the Contact Policy shape are honored regardless of whether the channel limitations were applied. 6-5

Using Geofences within Strategies Strategies built within Pega Next-Best-Action Marketing can also use Geofence rules to filter propositions. This is done by adding a Geofence Filter shape to the Strategy canvas (accessible via Arbitration -> Geofence Filter). The Geofence Filter shape enables the user to reference one or more Geofence rules that have been created in the System. Refer to the Geofences chapter for more information about creating a Geofence rule. Selecting Geofences Users can select one or more Geofence rules to use for filtering. At runtime, the System will evaluate each of the referenced Geofence rules (in order) until a Geofence is satisfied, i.e. the customer location is within the Geofence. The Geofences properties panel tab provides support for two modes for selecting Geofence rules: 6-6

Select Geofences one at a time Use this mode to add Geofence rules one at a time via the Add Item link. Use the Delete link to remove the selected Geofence. Select multiple Geofences Use this mode to select and add multiple Geofences using a list-to-list interaction. The left list contains the available Geofences while the right list contains the currently selected Geofences. Use the icons adjacent to the lists to manage Geofences between (and within) the lists. Icon Purpose Move all available Geofences to the applied list. Move the selected Geofence from the available to the applied list. Move the selected Geofence from the applied to the available list. Move all applied Geofences back to the available list. Sort the available or applied list in ascending order. 6-7

Icon Purpose Sort the available or applied list in descending order. Move the selected Geofence up in the applied list. Move the selected Geofence down in the applied list. Configuring Filter Options The Options properties panel tab provides various options for configuring the desired behavior of the Geofence Filter shape. Handling Missing Customer Location Data Select the desired behavior of the shape when customer location data is not available. The default option is to prevent the shape from returning source component results as outputs. However, if desired, users can choose to pass source component results through to the next shape. Selecting Customer Location Properties Users can configure the properties to use to determine the customer location. The Latitude and Longitude fields are initialized to the default properties but can be overridden by the user. Note: The default location properties are configured by the application administrator. Refer to the Administrative Settings appendix for more details. The following sources can be used for the latitude and longitude properties: Customer Prefix the property with Primary., e.g. Primary.Latitude Offer Data Prefix the property with a period, e.g..latitude Calculated fields Prefix the property with the strategy shape name Additionally, users can opt to use customer location from real-time Event data, if it is available. This option can be employed to use location data from a triggered Event. If 6-8

location data is not present on the Event, the customer location fields specified on the shape will be used. Refer to the Events chapter for details on including location data (latitude/longitude) as part of the Event s payload. Using a Strategy to Stop In-Flight Offers In certain cases, users might want to terminate Offers that are currently in-flight. An example usage might be if the wrong details were sent out with an Offer or if an Offer is no longer available. Stopping an Offer prevents the System from reacting to responses by customers. To stop an in-flight Offer: 1. Create a new Strategy to stop the Offer. In this Strategy, select the Offer that needs to be stopped. Specify the value of the Type property (via a Strategy Set) to be StopOffer and return this Offer. 2. Create a new Program. Target the Program to the appropriate set of Customers via a Segment rule, such as the one that was used to originally send out the Offer. Specify the newly created Strategy as the Marketing Strategy for the Program. 3. Submit the Program for a one-time execution. When this Program runs, the system will execute the Strategy to determine the list of in-flight Offers that need to be stopped. Each of these Offers will be marked as completed, thereby preventing any further actions from being taken on these Offers. 6-9

Chapter 7: Contact Policies Contact Policies provide a mechanism for controlling and restricting how many times a customer is contacted in accordance with corporate and/or regulatory guidelines. A single policy can contain the contact limits for multiple channels of communication. Each contact limit is applicable over a specified time period (e.g. weekly, yearly, etc.). Furthermore, the contact policy, as a whole, can be disabled, enabled only for a specified date range, or always enabled. Contact Policies are listed under the Contact Policies landing page, which is accessible via: -> Channels -> Contact Policies The Contact Policies landing page provides a quick overview of the various Contact Policies configured in the Application. The landing page displays the start and end date of each policy along with its availability. Details about the limits specified for a particular policy are visible by expanding the row for the individual policy (via the arrow on the left side), as shown below: 7-1

Contact Policy Management This section explains the various actions that can be performed on a Contact Policy. Creating a new Contact Policy To create a new Contact Policy, click the New button on the Contact Policies landing page. Enter a unique Contact Policy name in the Short Description field and click Create on the new form. A new Contact Policy rule resembles the following: The Contact Policy rule has the following tabs: Tab Name General History Purpose Configure the Contact Policy s availability and perchannel contact limits. Specify the Description and Usage information for this Event. 7-2

Specifying Contact Policy Availability The following configuration options are available: Policy Starts Specify the start date for the policy to be applicable. If this value is not specified, the policy is deemed to be always applicable. Policy Ends Specify the end date for the policy to be applicable. Using this value requires that a valid policy start date is also specified. Available Specify whether the policy is available. Contact Policy restrictions are only applied when the policy is marked as being available and any date restrictions (if specified) are currently applicable. In all other cases, the contact limits specified in the policy are ignored. Refer to the Using Contact Policies section in the Strategies chapter for details on how to use Contact Policies. Specifying Contact Policy Channel Limits Specify the per-channel limits for the Contact Policy in the channel restrictions grid. At least one channel limit must be specified in the Contact Policy. Additionally, each channel can only be specified once in a Contact Policy. For each row, the following options are available: Channel Select the channel (from the list of available channels) on which to restrict outbound communication. Contact(s) per customer Specify the maximum number of contacts allowed per customer. Duration Select the duration over which the channel restrictions are applicable. The following durations are supported: Daily Weekly New week starts on Sunday Semimonthly Semimonthly periods are: from the 1 st to the 15 th of a month; and from the 16 th to the end of the month Monthly Quarterly New quarters start on the first day of January, April, July, and October Yearly 7-3

Contact Policy restrictions only apply to communications with customers that are triggered by strategies during Program execution. Refer to the Using Contact Policies section in the Strategies chapter for details on how to reference Contact Policy rules in strategies and how the limits specified in a Contact Policy rule are applied. Deleting a Contact Policy Existing Contact Policies can be deleted directly from the Contact Policy rule form. 7-4

Chapter 8: Volume Constraints A Volume Constraint enables the user to limit the number of Offers that are delivered. The following two constraint types are supported: Offer Constraints Offer constraints allow the user to specify the maximum and/or minimum volume for a particular Offer. This is useful in situations where there is only a limited quantity available for a particular product. Channel Constraints Channel constraints allow the user to specify a maximum and/or minimum value for a particular delivery Channel (e.g. Email, SMS, etc.). This is useful in situations where there are limitations on the delivery mechanism, such as SMS/Email server throughput. To apply these constraints, the Volume Constraint rule should be specified in the Constraint Optimization configuration of a Program (in the Program Configuration Panel). When a Program Run occurs, it first executes the Strategy to determine the potential set of Offers that should be processed. Next, if a Volume Constraint has been associated with the Program, any enabled Offer and Channel Constraints are applied to the Offer set to determine the final list of Offers which needs to be processed. Note: If a Volume Constraint has been associated with a Program, it must have at least one constraint enabled. If no constraints are enabled on this Volume Constraint, the Program Run will not execute. At this point, the user can either enable a constraint and restart the Program Run; or update the Program to no longer use Volume Constraints and resubmit the Program for execution. Volume Constraints are listed in the Business Decisions explorer in Next-Best-Action Studio. They can be stored at the top level or can be categorized into Issues and Groups. A new Volume Constraint resembles the following: 8-1

The Volume Constraint rule has the following tabs: Tab Name General Advanced History Purpose Specify the offer and channel constraints to be applied. Also configure the constraint reset options. Select optimization mode. Specify the Description and Usage information for this Volume Constraint. Note: When using Volume Constraints, in most cases, each customer will receive a maximum of one Offer. If the marketing Strategy pushes out multiple Offers for a customer, these Offers should be prioritized in the Strategy since the highest priority Offer (based on the pxpriority field) will be made to the customer. 8-2

Configuring Constraint Reset Options Both offer and channel constraints tend to apply over a specific period of time (e.g. 100 instances of the Offer (product) are available every week, 50000 Offer emails can be delivered every day, etc.). As a constraint is applied, the actual count (of Offers sent) is updated to keep track against the constraint s limit. Once the constraint limit is reached, any Offer for which the constraint is applicable will not be made until the actual values are reset. This is done by configuring the reset options for the constraints in a Volume Constraint rule. The user must decide whether to specify the reset policy for each constraint in the Volume Constraint rule individually or globally (as shown below): The two options available are: Manage each constraint individually In this mode, the reset option is specified individually for each (offer and channel) constraint along with its limits. Reset all constraints at once In this mode, the reset option is specified globally for all (offer and channel) constraints. The global reset options are presented as a separate row when this option is selected. Whether constraint limits are reset globally or individually, the following reset frequency options are available: Manually: Select this option to manually reset constraint counts via the provided reset button(s). The Volume Constraint rule must be checked in (where applicable) for the reset button(s) to be enabled. 8-3

When limits are reset globally, use the Reset Now button: When limits are reset individually, use the Reset button(s) for the appropriate (offer or channel) constraint(s): Each time it is accessed: System will reset constraint limits each time the Volume Constraint rule is applied. This setting provides the option for constraining the output of an individual Program Run. Daily: System will reset the constraint limits the first time they are applied on a particular day. Weekly: System will reset constraint limits the first time they are applied in a particular week (first day of week = Sunday). Semi-Monthly: System will reset constraint limits the first time they are applied in a particular semi-monthly period (semi-monthly periods begin on the 1 st and 16 th days of each month). Monthly: System will reset constraint limits the first time they are applied in a particular month. Quarterly: System will reset constraint limits the first time they are applied in a particular quarter (quarters begin on the 1 st day of January, April, July, and October of each year). Yearly: System will reset constraint limits the first time they are applied in a particular year. 8-4

Specifying Offer Constraints For each Offer Constraint, the following must be specified: Enabled Whether this constraint should be enabled. This provides an easy mechanism to switch constraints on and off as product volumes fluctuate. Offer Name of the Offer to be constrained. The smart prompt presents a list of Offers categorized by their Issue and Group. Reset Interval Reset policy for this constraint. This option is available if constraint limits are managed individually. Select the appropriate reset option. For the constraint volumes, the user must specify at least one of the following and can specify both. Minimum Volume Desired minimum volume for this Offer. If a sufficient number of Offers is being propagated and the optimization engine selects this Offer, then the engine will satisfy this minimum volume requirement before selecting a different Offer. Maximum Volume Desired maximum volume for this Offer. In addition, the following are also displayed: Remaining Number of Offers remaining. The System displays Unlimited for this field in the following scenarios: If a maximum volume is not specified If the constraint is not enabled Reset button Reset the remaining count to the maximum volume. This option is available for the Manually reset interval when constraint limits are managed individually. Specifying Channel Constraints For each Channel Constraint, the following must be specified: Enabled Whether this constraint should be enabled/applied. Channel Delivery channel that is being constrained. 8-5

Reset Interval Reset policy for this constraint. This option is available if constraint limits are managed individually. Select the appropriate reset option. For the constraint volumes, the user must specify at least one of the following and can specify both. Minimum Volume Desired minimum volume for this channel. Maximum Volume Desired maximum volume for this channel. In addition, the following are also displayed: Remaining Number of Offers that can still be made on this channel. Reset button Reset the remaining count to the maximum volume. This option is available for the Manually reset interval when constraint limits are managed individually. In order for Channel Constraints to be properly applied, any Offer (Proposition) that is returned by the Strategy must set the following property: pychannel This needs to be set to the channel being constrained ( Email, SMS, etc.) This is demonstrated in the Strategy snippet below: 8-6

Selecting the Optimization Mode By default, Progressive constraint optimization is enabled on Volume Constraint rules. This is a robust mechanism for applying constraints and allows for the inclusion of both minimum and maximum constraints. This mode should only be disabled (in few advanced scenarios) upon the recommendation of the Pega support team. 8-7

Chapter 9: Offers An Offer is the Marketing manifestation of a Decisioning Proposition. The Proposition holds various details about a particular offering, such as Start Date, End Date, and Expected Revenue. In addition to the proposition data, the Offer rule enables the user to visually specify the flow of steps for a particular offering (Offer Flow). Note: Each Offer is backed by a Decisioning Proposition. The System automatically manages this relationship by creating/deploying/deleting the Proposition as needed. Since an Offer is closely tied to a Proposition, it must always be created in the context of an Issue and a Group. Offers are listed in the Offer Assets explorer in Next-Best-Action Studio. A newly created Offer starts out with the Start and End shapes, as shown below. The Offer rule contains the following tabs: Tab Name Diagram Purpose Create the Offer Flow. Refer to the Creating the Offer Flow section. 9-1

Tab Name Details Checklists Test Offer History Purpose Specify the details about the offering. Refer to the Specifying Offer Details section. View any checklists associated with this Offer. Refer to the Checklists chapter. Test the Offer Flow. Refer to the Testing the Offer Flow section. Specify the Description and Usage information for this Offer. Creating the Offer Flow The Offer Flow contains the exact sequence of actions to be performed in the lifecycle of a particular Offer. An Offer Flow consists of a variety of shapes and the connectors which connect these shapes. The Offer Flow editor provides the user with an intuitive drag-and-drop mechanism for designing their offerings. Users can configure the details of each step directly on the step s shape using the shape s Properties panel. Adding Flow Shapes The Shapes Palette lists all the shapes that can be added to an Offer Flow. It can be accessed via the Flow Shapes' button or via the right-click 'Add' sub-menu. 9-2

The following shapes are available in the Shapes Palette: Shape Name Icon Purpose Send Email Send SMS Send Generic Send Multiple Treatments Send Passbook Push Notification Inbound Call Center Wait Update Status Hand Off Decision Schedule Appointment Start End Configure and send an Email. Configure and send an SMS message. Configure and send a Generic treatment. Dynamically determine which channel (Email, SMS, or Passbook) to use for communication and send out the appropriate treatment on that channel. Configure and send a Passbook treatment. Configure and send a notification to an app running on a device. Refer to the Configuring Push Notifications in Offers section of the Push Notifications chapter. Specify the Inbound treatment to be returned for a request from an Inbound Call Center application. Specify a wait time in the flow execution. Update the Offer's status and record response information to History (Interaction Services). Spinoff a new work object/process (such as Offer Fulfillment). Use various PRPC decision structures to determine branch conditions in the flow. Schedule and configure an appointment for follow-up work to be performed. This shape is available in the Smart Shapes sub-menu. Denote the starting point of the flow. Denote the ending point of the flow. Each of these shapes is detailed in the subsequent sections. 9-3

Send Email The Send Email shape enables the user to configure an email message for delivery. The following General Configuration options are available for this shape: Name Treatment Name Key Code Purpose Name of the Email Treatment to send. In the case of Online Delivery, the Treatment Name specified must be backed by an existing Email Treatment rule since this is used as the content of the email to be sent. Marketing code used to identify the treatment. This value can be output in the sent email and/or the output file/db, and can be used to track the performance of different treatments. If a key code value is specified on the Email Treatment being referenced, it will be populated into this field upon selecting the treatment. Delivery Options Emails can be delivered in various ways - they can be sent by the System (Online mode) or they can be written to a data warehouse for processing by other systems (File and DB modes). Users can enable one or more of these modes at the same time. The following Delivery Configuration options are available for this shape: Name Deliver Online Purpose Determines whether an actual email should be sent using the content in the specified Treatment Name. 9-4

Name Use Subject From Treatment (Online mode) Specify Subject (Online mode) Email Subject (Online mode) Write To File Write To DB Select Template (File/DB modes) Purpose Denotes that this shape should directly use the Email subject specified in the referenced Email Treatment. This subject is shown as read-only in the Email Subject field. Denotes that this shape should use the specified Email Subject. Subject of the email to be sent. Determines whether a record should be written to an output file. Determines whether a record should be written to an output database table. File/DB Template rule which contains the specifics of what should be output to the file/table. This includes the file/table name, location, header information, and the specific data fields that need to be output. Refer to the Templates chapter for more information. Configuring Email Subject The Email Subject field supports the following three formats: 1. Plain text If the subject contains plain text (with no quoted words); simply enter the text in the input field. The System will wrap the entire text around quotes. 2. Quoted text If the subject needs to include text in double quotes (e.g. The brand new ProductName is here!), then the entire subject must be in quotes with the desired quotes being escaped with a backslash. The example above should be entered as: The brand new \ Product Name\ is here! 3. Property references If the subject needs to contain property references (such as the customer name), then the property reference needs to be concatenated to the remaining subject by the plus (+) symbol. Each block of text that is not a property reference should be wrapped in double quotes. This is exemplified below: Desired Subject: Hi <Customer s Name>, a new Product awaits you! Entered Subject: Hi +.Customer.pyFullName +, a new \ Product\ awaits you! If an email subject doesn t meet the supported formats, the following error is displayed to the user: Invalid value specified for Email Subject. Value doesn t adhere to the Validate: BalancedQuotationMarks. 9-5

Wait After Sending Users can determine whether they would like to wait after sending an email. It is typical to enable this wait when customer response is expected for an email (such as accepting or rejecting an Offer). In other cases, the user might simply want to send an email and move on to the next step in the Offer Flow. In such cases, waiting should be disabled on the Send Email shape. The wait options available are the same for all wait-based shapes and are described in the section on the Wait shape. Email Account Users also have the option to specify the Outbound Email account to use for sending the email message. These accounts are typically configured by the administrator. Refer to the Email and SMS Account Configuration chapter for more details. The following options are available in the Email Account sub-section under the Advanced section of the Send Email Properties modal: Name Use Default Email Account Specify Email Account Account From/Reply To: Use Email Account Settings From/Reply To: Use Operator Settings From/Reply To: Override Settings From Reply To Purpose Determines whether the Default Email account should be used for sending this email. Determines whether a user-specified Email account should be used for sending the email. Name of the Outbound Email account to use for sending the email. Denotes that the sender s name (from) and reply-to address in the email being sent should be taken from the values specified on the Email account. Denotes that the name and email address of the operator that initiates this email (e.g. by launching a Program that sends it) should be used for the sender s name and reply-to address. Denotes that user-specified values should be used for the sender s name (from) and reply-to address in the email being sent. Name that will be used as the sender s name in the email being sent. Email address that will be set as the reply-to address in the email being sent. Testing the Send Email shape The Send Email shape provides an easy mechanism to test its outcome. Users can employ this test mechanism to test the online delivery of the Email Treatment. This can be beneficial in verifying both the content of the email being delivered and any email configurations that were applied (such as the subject, sender s name, and replyto address). Finally, this also enables the user to verify any data references (both 9-6

Offer Data and Customer) in the Email Treatment that were used to personalize the email message. The Test Message section lists the options available for configuring the test email message. This includes the following: To Recipients of the test email. Select either Test Recipients or Seed List. Test Recipients Enter list of recipients. Each entry can either be the Operator ID of an existing user in the system or a valid email address. If the operator ID is entered, operator information such as the name and email is populated as the customer data and the test email is sent to the operator s email address. Seed List Select a pre-defined Seed List as the intended recipients of the test email. The data for each seed is populated as the customer data and is visible (if referenced) in the test email. In this case, the Email1 column in the Seed List (.pyemail1 property) specifies the email address to which the test email is sent. Refer to the Seed Lists chapter for information on configuring a Seed List. Subject Subject of the test email. This value is pre-populated with the subject specified in the Treatment tab. The user can choose to specify a different subject by selecting the Override subject option. Refer to the Configuring Email Subject section for options available for this field. After the test message has been configured, it can be sent via the Send Test Message button. Once configured, the test message can also be directly sent via the Test this Email right-click menu item on the Send Email shape. The status of the test is displayed. Any errors in the test delivery are displayed in case of a failure. These can be corrected and the test email can be resubmitted for delivery. 9-7

Send SMS The Send SMS shape enables the user to configure an SMS message for delivery. The following General Configuration options are available for this shape: Name Treatment Name Key Code Purpose Name of the SMS Treatment to be sent. Marketing code used to identify the treatment. This value can be output in the sent SMS message and/or the output file/db, and can be used to track the performance of different treatments. If a key code value is specified on the SMS Treatment being referenced, it will be populated into this field upon selecting the treatment. Delivery Options SMS treatments can be delivered in various ways - they can be sent by the System (Online mode) or they can be written to a data warehouse for processing by other systems (File and DB modes). Users can enable one or more of these modes at the same time. The following Delivery Configuration options are available for this shape: Name Deliver Online Use Existing SMS (Online mode) Purpose Determines whether an actual SMS message should be sent using the content in the specified Treatment Name. Determines whether an existing treatment, specified by the Treatment Name property, should be used to get the content of the SMS message. 9-8

Name Quick Create SMS (Online mode) Write Message (Online mode) Write To File Write To DB Select Template (File/DB modes) Purpose Determines whether to use the text specified in the Write Message box as the content of the SMS message. Content of the message to be sent in Quick Create SMS mode. Determines whether a record should be written to an output file. Determines whether a record should be written to an output database table. File/DB Template rule which contains the specifics of what should be output to the file/table. This includes the file/table name, location, header information, and the specific data fields that need to be output. Refer to the Templates chapter for more information. Wait After Sending Users can determine whether they would like to wait after sending an SMS message or proceed directly to the next step in the Offer Flow. The wait options available are the same for all wait-based shapes and are described in the section on the Wait shape. SMS Account Users also have the option to specify the SMS account to use for sending the SMS message. These accounts are typically configured by the system administrator. Refer to the Email and SMS Account Configuration chapter for more details. The following Account Configuration options are available in the SMS Account subsection under the Advanced section of the Send SMS Properties modal: Name Use Default SMS Account Specify SMS Account Account Purpose Determines whether the Default SMS account should be used for sending this SMS message. Determines whether a user-specified SMS account should be used for sending the SMS message. Name of the Outbound SMS account to use for sending the SMS message. Testing the Send SMS shape The Send SMS shape provides an easy mechanism to test its outcome. Users can employ this test mechanism to test the online delivery of the SMS Treatment. This can be beneficial in verifying the content of the SMS being delivered. This also enables the user to verify any data references (both Offer Data and Customer) in the SMS Treatment that were used to personalize the SMS message. The Test Message tab lists the options available for configuring the test SMS message. This includes the following: 9-9

To Recipients of the test message. Select Test Recipients or Seed List. Test Recipients Enter list of recipients. Each entry can either be the Operator ID of an existing user in the system or a valid mobile phone number. If the operator ID is entered, operator information such as the name and phone is populated as the customer data and the test SMS message is sent to the operator s phone number. Seed List Select a pre-defined Seed List as the intended recipients of the test SMS message. The data for each seed is populated as the customer data and is visible (if referenced) in the test message. In this case, the Mobile Phone column in the Seed List (.pymobilephone property) specifies the phone number to which the test SMS message is sent. Refer to the Seed Lists chapter for information on configuring a Seed List. Test SMS Account Options These settings specify the SMS account (Default or custom) used to send the test SMS message. After the test message has been configured, it can be sent via the Send Test Message button. Once configured, the test message can also be directly sent via the Test this SMS right-click menu item on the Send SMS shape. Upon sending a test message, the status of the test is displayed. Any errors in the test delivery are displayed in case of a failure. These can be corrected and the test SMS can be resubmitted for delivery. 9-10

Send Generic The Send Generic shape enables the user to configure and send a Generic treatment. This shape provides a hook for the user to process Offers via outbound delivery mechanisms, other than the ones currently provided by the System (Email/SMS). The user can use this shape to output relevant data to an output file or database table for processing by legacy systems. The following General Configuration options are available for this shape: Name Treatment Name Key Code Purpose Name of the treatment. This can be used to track/organize the output data. Marketing code used to identify the treatment. This value can be output in the output file/db and can be used to track the performance of different treatments. Delivery Options Generic treatments can be written to a data warehouse (File/DB) for processing by other systems. Users can enable one or more of these modes at the same time. The following Delivery Configuration options are available for this shape: Name Write To File Purpose Determines whether a record should be written to an output file. 9-11

Name Write To DB Select Template (File/DB modes) Purpose Determines whether a record should be written to an output database table. File/DB Template rule which contains the specifics of what should be output to the file/table. This includes the file/table name, location, header information, and the specific data fields that need to be output. Refer to the Templates chapter for more information. Wait After Sending Users can determine whether they would like to wait after sending a generic treatment or proceed directly to the next step in the Offer Flow. The wait options available are the same for all wait-based shapes and are described in the section on the Wait shape. Field Marketing Options This set of options is available when the Application includes Next-Best-Action Field Marketing. Corporate marketers can enable the checkbox to include this shape in the list of engagement steps that field marketers see in Field Marketing Campaigns. Additionally, they can also provide a meaningful description to aid the field marketer in understanding this shape s purpose. Content Details The Content Details section allows the user to upload related content for this shape. If this shape is configured to display in Field Marketing Campaigns, then field marketers will be able to view the uploaded content when they review this shape in their Campaigns. Both links and files can be uploaded using this section. The user can also enter a description for each item. Once the file/link is added, it displays in the content grid at the bottom of this section. 9-12

Send Multiple Treatments The Send Multiple Treatments shape enables the user to configure treatments to be delivered across different channels (currently Email, SMS, or Passbook). The user also specifies the logic which determines the channel to be used for delivery. When the Offer Flow executes, the correct delivery channel is determined and the treatment specified for this channel is delivered. Treatment Specification The following configurations options are available for specifying the treatments and channels for this shape: Treatment Origin This setting determines how the channel for delivery is determined. The two options are: Strategy/Offer In this scenario, the channel value determined by strategy execution as part of the Program Run is used as the delivery channel. The user can alternately set/reset the channel value (.OfferData.pyChannel property) directly in the Offer Flow prior to this shape. 9-13

Decision Rule In this scenario, the channel value is determined by executing a decision rule. The user must also specify the Decision Type (decision table or decision tree) and the name of the Decision Rule. Treatments This group of settings is used to specify the treatments for delivery. The user can select the channels available for delivery by enabling the Outbound Email, Outbound SMS, and Passbook checkboxes. The configuration options available for each channel are similar to those present on the channel-specific delivery shapes. Refer to the descriptions provided for each of these shapes for more details: Outbound Email Send Email shape Outbound SMS Send SMS shape Passbook Send Passbook shape Default Treatment This setting determines the default channel value to use in case the channel returned by the Treatment Origin setting is either undefined or not currently supported. The values available for this setting are predicated by the channels that are enabled in the Treatments group. Wait After Sending Users can determine whether they would like to wait after the processing of this shape or proceed directly to the next step in the Offer Flow. The wait options available are the same for all wait-based shapes and are described in the section on the Wait shape. Delivery Options Emails and SMS messages can be delivered in various ways - they can be sent by the system (Online mode) or they can be written to a data warehouse for processing by other systems (File and DB modes). Users can enable one or more of these modes at the same time. The configuration options available are similar to the ones available for the Send Email and Send SMS shapes. These options are situated in the following areas of the Send Multiple Treatments shape: Write to File/DB options In the Output section Email Account options In the Advanced section SMS Account options In the Advanced section 9-14

Send Passbook The Send Passbook shape enables the user to configure a Passbook Treatment for delivery. The following general configuration options are available for this shape: Name Passbook Style Passbook Treatment Key Code Email Treatment Purpose Style of the Passbook Treatment to send. Currently available options are Coupon and Generic. Name of the Passbook Treatment (pass) to send. Refer to the Passbook Treatments section in the Treatments chapter for details on creating and configuring Passbook Treatments. Marketing code used to identify the treatment. This value can be output in the sent email and/or the generated pass, and can be used to track the performance of different treatments. If a key code value is specified on the Passbook Treatment being referenced, it will be auto-populated into this field upon selecting the treatment. Name of the Email Treatment to use to deliver new passes and updates to existing passes. The pass is delivered as an attachment to the email message. Delivery Options New passes are delivered as attachments to emails. On ios devices, the customer can open the attached pass and can add it to their Passbook. The following delivery configuration options are available for this shape: 9-15

Name Email Subject Purpose Subject of the email containing the new/updated pass. Refer to Configuring Email Subject for more details. On Update Users have multiple options for updating passes that have previously been sent. When the same Passbook Treatment is used in multiple shapes in the same offer flow, the first delivery is treated as a new pass. Subsequent deliveries (shapes) are treated as updates to the existing pass. Furthermore, if the Passbook Treatment is configured as a global treatment ( Keep updating the pass option is enabled on the treatment s Advanced tab), even the first passbook shape will result in an update scenario if the pass has already been sent to the customer previously (via a different Offer or Program). The following configuration options are available for updating passes: Name Push Notification Email Notification Purpose Select this option to utilize the Apple Push Notification service (APNs) to signal the device that an update is available for the pass. The device will then make a web service call to get the latest pass. Select this option to send the updated pass as an attachment to the email (specified in the Email Treatment field). Note: If neither notification option (Push/Email) is enabled, the System will generate and store the updated pass internally. This updated pass will be available to pass holders (customers) if/when they attempt to manually update the pass. Wait After Sending Users can determine whether they would like to wait after sending a pass. The wait options available are the same for all wait-based shapes and are described in the section on the Wait shape. Email Account Users also have the option to specify the Outbound Email account to use for sending the message. These configuration options are available in the Advanced tab of the Send Passbook shape and are described in the Email Account sub-section of the Send Email shape. 9-16

Testing the Send Passbook shape The Send Passbook shape provides an easy mechanism to test its outcome. Users can employ this test mechanism to test the online delivery of the email with the pass attachment. Refer to Testing the Send Email shape for details on configuration options for the test message. The test email will be sent with the selected pass as an attachment. Refer to the Reviewing the Test Pass sub-section in the Treatments chapter for details on reviewing and adding the test pass. Inbound Call Center The Inbound Call Center shape provides a means to specify the content that should be returned when an inbound call center application, such as Next-Best-Action Advisor (NBAA), requests this Offer to display/use within their application. Name Section Channel Work Status (Status tab) Purpose Name of the Section rule to use. The content of this section is returned when an Inbound Call Center application (such as NBAA) requests Offer content from the System. Inbound Channel for the Treatment (Default value for this shape is CallCenter). Status of the Offer after executing this step in the Offer Flow. Note: There should be only one Inbound Call Center shape in an Offer Flow. Having multiple Inbound Call Center shapes in the same Offer Flow could cause non-deterministic behavior in resolving the content that should be returned to the Call Center application. 9-17

The Inbound Call Center shape, by itself, simply serves as a determining point for the content to be returned for external requests. However, this shape can be (and typically is) combined with the InboundTicket ticketing mechanism to provide a branch of Offer Flow execution for processing an Inbound request. Refer to Adding Inbound Channel Support for more details. Wait The Wait shape enables the user to pause the Offer Flow execution for a specified duration. This shape can be used when an unconditional wait is required in the Offer Flow. When the specified wait duration has lapsed, Offer Flow execution automatically resumes with the next shape in the flow. The following Configuration options are available for this shape: Name Days Business Days? Hours Minutes Seconds Purpose Number of days to wait Determines whether the wait duration should be in terms of business days or regular week days. Number of hours to wait Number of minutes to wait Number of seconds to wait Users can also enable a wait in Offer Flow execution via the Wait After Sending configuration options on wait-based delivery shapes. This includes the Send Email, Send SMS, Send Passbook, Send Generic, Send Multiple Treatments, and Push Notifications" shapes. To enable the wait and configure the wait options (listed above), enable the Wait checkbox on these shapes. 9-18

Update Status The Update Status shape is used to specify the status of the Offer as it works its way through various stages of the Offer Flow. This status can be used to group Offers for reporting and other aggregations. This status can also be used to determine the appropriate path to be taken down a subsequent branch in the Offer Flow execution. The Update Status shape also enables the user to record Behavior and Response information for the Offer into Interaction History. The following Configuration options are available for the Update Status shape: Name Work Status Behavior Purpose Status of the Offer. The OOTB values for the Offer status include: New OfferSent Resolved-OfferAccepted Resolved-OfferExpired Resolved-OfferRejected Denotes the behavior of the customer to the particular Offer. This information gets recorded in History. The OOTB values for Behavior include: Negative Neutral Positive Response Denotes the response of the customer to the particular Offer. This information gets recorded in History. The OOTB values for Response include: Accepted NoResponse Pending Rejected 9-19

Hand Off The Hand Off shape enables the user to launch other processes (in the background) from the Offer Flow. This serves as a launching point for external processes which can be triggered at the appropriate time in the Offer execution. An example use of this would be to initiate an Offer Fulfillment process when a customer accepts an Offer. Note: Initial processing of the handed-off work object is sequential with the Offer Flow execution until the new work object reaches a stopping point (such as an Assignment). At this point, Offer Flow execution resumes and the handed-off work object lives and executes separately on its own. The following Configuration options are available for the Hand Off shape: Name Work Class Name Work Flow Name Work Status (Status section) Purpose Name of the class which contains the process (Work Object flow) to be started. Name of the process (flow) to be started. Status of the Offer after the new process has been initiated. As part of the Hand Off shape, the entire contents of the Offer work object (including Offer details) are initially made available to the newly created work object. This information is stored in the top level OfferWorkPage clipboard page. This information is available whilst the new work object shares the execution with the Offer work object (see Note at the beginning of this section). If the new work object 9-20

requires any of this data for its processing, it is recommended to copy relevant data from the OfferWorkPage onto appropriate locations on the new work object. This could be done via the use of the default Data Transform rule (pydefault) or by other mechanisms in the work process flow before it enters a waiting point (such as an Assignment). In a similar vein, a reference to the newly handed-off work object is stored on the original Offer work object. This is made available under the pyreferencedinskeys construct. This information can be used to provide a reference code to the customer in an email or for any other cross-referencing purposes, as deemed fit by the user. Note: In order for the System to successfully create and launch the handedoff work object, all necessary rules (such as Flow, Data Transform, Work Parties, etc.) should be properly configured for the desired work object. Hand Off Example Some of the salient pieces involved in a handed-off work object are demonstrated in the following OfferFulfillment example: Data Transform: pydefault Properties: Channel CustomerID OfferName Flow: FulfillOffer Work Parties: Default Flow Action: Approve Section: FulfillOffer This work object involves a minimal process flow where the object is placed in a workbasket and is resolved upon approval. The FulfillOffer Flow rule is shown below: 9-21

The above flow is configured to create a new work object since we expect it to have its own lifecycle and want it to be actionable after it is stored in the workbasket. For simpler flows with straight through processing (no assignment shapes), the flow can be configured with the temporary object setting in the Process tab. As mentioned previously, both customer and offer data are available to this flow until it hits the first assignment. After this assignment, only data that has been saved onto the work object will be available. The following (pydefault) Data Transform demonstrates the copying of (both Offer and Customer) data from the Offer page onto the work object, upon its initial creation: 9-22

In the above Data Transform, the Customer object is added as the Customer work party on the new object. A sample Work Parties rule for this work object is shown below: The sample Flow Action and Section use basic PRPC concepts to display some of the copied over data and present an action to resolve the work object. This is demonstrated by the following instance of a handed-off Offer Fulfillment work object: Field Marketing Options This set of options is available when the Application includes Next-Best-Action Field Marketing. Corporate marketers can enable the checkbox to include this Hand Off shape in the list of engagement steps that field marketers see in Field Marketing Campaigns. Additionally, they can also provide a meaningful description to aid the field marketer in understanding this shape s purpose. 9-23

Decision The decision shape enables the user to execute a variety of different decision constructs (such as decision trees, decision tables, etc.) to provide a basis for branching in the execution of the Offer Flow. The following Decision types are currently supported: Boolean Expression Decision Table Decision Tree Fork Map Value Predictive Model Scorecard Model Note: More information on the various options for configuring each of the decision types (listed above) can be found in the PRPC Help documentation. 9-24

Schedule Appointment The Schedule Appointment smart shape enables the user to schedule and configure follow-up work to be performed at a particular point in the Offer flow lifecycle. The user can utilize the Instructions field to specify any instructions to aid in processing the scheduled appointment. Select Assignee The user can choose from the following options: Current Operator Routes the appointment to the operator that initiates this Offer (e.g. by using it in a Program and executing the Program). Specify Operator Routes the appointment to the operator specified in the Operator field. Workbasket Routes the appointment to the workbasket specified in the Workbasket field. Schedule Options The user can choose from the following options: Relative Date - Sets the appointment time relative to the time when this shape is processed in the Offer. The user must specify the relative number of days, the appointment time, and the time zone. The user can also enable the Business Days? checkbox to denote that the relative number of days should be applied using only business days. Specify Date Sets the appointment time to the specified date and time 9-25

Start The Start shape denotes the beginning of the Offer Flow. Each Offer Flow must have one and only one Start shape. End The End shape denotes the termination point of the Offer Flow execution. Each Offer Flow can have one or more End shapes. Note: More information on the options for configuring the Start and End shapes can be found in the PRPC Help documentation. 9-26

Connecting Two Shapes The various shapes outlined in the prior sections can all be connected to one another. Each connector connects one shape to another. A shape can have multiple connectors emanating from it and/or terminating at it. The various connectors represent possible paths of Offer Flow execution. Connectors can be categorized into the following types: Simple Connectors Decision Connectors Wait Connectors Response Received Connector Simple Connectors These connectors simply connect one shape to another. There is no logic/path determination behind these connectors. The following shapes have simple connectors emanating from them: Inbound Call Center Update Status Hand Off Start Decision Connectors These connectors emanate from the Decision shape. Decision connectors can be subcategorized based on the condition type Result, Always, When, and Else. Result Condition Type This condition type is used to represent the result of executing the Decision rule specified in the Decision shape. The system automatically analyzes the Decision rule and populates the Result drop-down with the possible set of outcomes from the decision. 9-27

Always Condition Type This condition type represents a connector that is always taken. When Condition Type This condition type represents a connector that is taken when the expression/condition specified in the When input box evaluates to true. Percentage Condition Type Use the Percentage condition type to specify the percentage (relative amount) of time that the Offer Flow should take this path during its execution. Else Condition Type The Else condition type serves as the catch-all connector and is taken when none of the other connectors originating from the Decision shape can be taken. It is a best practice to have an else path whenever the other execution paths aren t collectively exhaustive (e.g. with percentage and when condition types). Wait Connectors The wait connector emanates from shapes that have a waiting mechanism tied to them (wait-based shapes). This includes the following shapes: Send Email Send SMS Send Generic Send Passbook Send Multiple Treatments Push Notification Wait There are two types of the Wait connector Continue and Wait Expired. Only one Wait connector can originate from a wait-based shape. If waiting is enabled for the shape, the Wait Expired connector is used; otherwise, the Continue connector is used. The appropriate Wait connector (Continue vs. Wait Expired) is automatically generated when you connect a wait-based shape to another shape. 9-28

Note: Since the system manages the Wait connectors, these should not be changed manually. If you wish to update the type of Wait connector originating from a shape, toggle the Wait field on the shape. If you delete the Wait connector by accident, simply draw a new connector coming out of the shape and the appropriate Wait connector will be recreated for you. Response Received Connector The Response Received connector is used to denote the Offer Flow path that should be taken when a response is received for a particular Offer. This is typically used as a connector originating from the Send Email/SMS shape after an Offer email/sms is sent to a customer. This connector should be used in tandem with the Wait Expired connector, as shown below: In the Offer Flow depicted above, the System puts the Offer in a wait state for the duration specified (5 days). If no response is received within this wait duration, Offer Flow execution will resume along the Wait Expired path. However, if a response is received before the wait duration has expired; the Offer will instantly get out of the wait state and go down the Response Received path. Note: The ability of the System to go down the Response Received path is tied to the built-in response mechanism for Email and SMS treatments. Refer to Embedding a Response Link in the Treatments chapter for adding this mechanism to Email treatments. For SMS treatments, this mechanism is handled via the configuration of Inbound SMS accounts. For more details, refer to Configuring an Inbound SMS Account in the Email and SMS Accounts Configuration chapter. 9-29

To add a Response Received connector to an Email/SMS shape: 1. Enable Wait on the shape and configure the wait duration. Then, draw a connector from the shape to the backing shape for your Wait Expired action. The system will automatically create the Wait Expired connector for you. 2. Draw a second connector from the shape to the backing shape for the Response Received path. Open this connector s properties panel and select ResponseReceived as the value for the Flow Action smart prompt and provide a suitable Name for the connector (e.g. Response Received). 9-30

Offer Flow Validation When the Offer is saved, the system validates multiple aspects of the Offer and presents the user with any violations that are found. These violations are reported as warnings when the Offer Flow is in Draft mode and the Offer can still be saved. When Draft mode is disabled, these violations are reported as errors and must be corrected in order for the Offer to be successfully saved. These errors and warnings are displayed underneath the Offer header. If a shape has any errors associated to it, an error icon is also displayed on the shape. The tooltip on the error icon displays the associated error message. Some examples of these violations include the following: Missing required fields Invalid rule references e.g. Treatment, Template, Decision, Email/SMS accounts, etc. Missing key codes (warning only) Note: Being able to successfully save an Offer with Draft mode disabled is an excellent gauge for ensuring successful Offer flow execution. It is strongly recommended that any Offers that are live (can be potentially sent to customers) should be validated by saving them with Draft mode disabled. 9-31

Adding Inbound Channel Support The System enables the use of the same Offer rule for both inbound and outbound channels. This allows the user to build distinct paths of Offer Flow execution based on the channel. This functionality facilitates the use of the system by inbound applications (such as NBAA) to process their customer offerings. The system enables this inbound channel support functionality in the following two ways: 1. When an inbound request is received (for a specific Offer and Customer), the system first determines whether the specified Offer is already in flight for the specified Customer. If so, the particular Offer is loaded and Offer Flow execution is forced down the Inbound path. This is done by the use of the InboundTicket construct. The InboundTicket is a PRPC ticket that can be associated with most Offer Flow shapes (with the exception of the Start shape and the Wait shape). This ticket denotes the place in the Offer Flow where processing should jump/switch to when an inbound request is received for an in-flight Offer. As shown above, the InboundTicket is enabled by specifying it as the value for the Ticket Name in the Tickets tab of the appropriate Offer Flow shape. Note: To avoid ambiguity in Offer Flow execution, the InboundTicket should be specified on only one shape in an Offer Flow. 2. On the other hand, if the specified Offer is not currently in-flight for the specified Customer, the system creates a new Offer object and starts executing the Offer Flow on it, in the context of the Channel that was part of the inbound request. If there s a need to have separate processing paths for different channels (say Inbound vs. Outbound, or Call Center vs. ATM), this can be achieved by branching the Offer Flow on Channel at the appropriate place. 9-32

In the Offer Flow snippet above, the flow execution is initially branched based on the Channel. If the Channel on the input request is Call Center, the Offer flow goes down the Record Response route in this case, the customer is responding to the Offer in the Call Center, and there is no need to send them the Offer email. For all other channels, we send the Offer email and wait for either the customer to respond or the wait duration to expire. Both the scenarios, outlined above, should be handled in an Offer if it needs to support requests on an inbound channel. Thus, such an Offer should have both: A shape designated as the resumption point for inbound requests by having the InboundTicket set on it A branch in flow execution for Channel-specific paths (as needed) Note: When integrating with an Inbound Call Center application (such as NBAA), it is typical to use the Inbound Call Center shape to also hold the InboundTicket. 9-33

Sample Offer Flow The following sample Offer Flow assimilates the concepts that have been outlined in the previous sections: Significant points in this Offer Flow include: Initial branching on Channel Contact Center (CC) vs. Outbound Specifying the InboundTicket on the Contact Center shape Specifying the Inbound Treatment on the Contact Center shape Waiting for a response after sending out the Offer email Branching on the type of response received Accepted vs. Rejected Handing off to a Fulfillment mechanism upon Offer acceptance Marking Offer status as appropriate and recording this information to History Specifying Offer Details Various details about the Offer can be specified on the Details tab of the Offer rule. As mentioned previously, an Offer is backed by a Decisioning Proposition. It is this backing Proposition that serves as the container for all Offer details. Note: Each Offer detail is a Proposition attribute. 9-34

Offer details are classified into the following groups: Basic Offer Attributes Bundle Attributes Field Marketing Details Custom Attributes Basic Offer Attributes Basic Offer attributes are shown in the top part on the Details tab of every Offer and include the following: Key Code Start Date End Date Expected Revenue Budgeted Cost Expected Response Rate Click Through URL Typically, this is the link to web page or file that provides more details on this Offer. When this Offer is included in a Real-Time Container, clicking this Offer in the Container will re-direct to the URL specified in this field. Refer to the Real-Time Containers chapter for details. Image URL Link to the image to display for this Offer when it is rendered as part of a Real-Time Container. Refer to the Real-Time Containers chapter for details. Offer Image Image (uploaded in PRPC) representing this Offer. This image is displayed in the Offer card and Offer selector in Campaigns. Refer to the Campaigns chapter for details. Bundle Attributes Bundles attributes are used to specify the bundling settings for the Offer. Refer to the Offer Bundles chapter for more details. 9-35

Field Marketing Details This section is available when your Application includes Next-Best-Action Field Marketing. It contains configuration options for using this Offer as a template in Field Marketing Campaigns. Refer to the Next-Best-Action Field Marketing User Guide for details on Field Marketing Campaigns. The main checkbox in this section allows the user to enable the use of this Offer in Field Marketing Campaigns. Once this checkbox is enabled, the user can configure the following additional options: Whether Field Marketing Campaigns based on this Offer must be submitted for approval Start and end restrictions on the time period when this Offer can be used in Field Marketing Campaigns Additionally, the user can also specify a Segment in the Segment Rule field to filter the Field Marketer's contact list (for Field Marketing Campaigns that reference this Offer) to only those contacts that are present in the specified Segment. When a Segment is selected, the System displays the last run date and population count for the selected Segment. If the selected Segment is yet to be run, an informational message is displaying alerting the user that the field marketer will not have any contacts to target with their Field Marketing Campaign. The above configurations are shown in the example below: Custom Attributes These are displayed in the Custom Attributes section on the Details tab of an Offer. This list includes both top level and Issue/Group level attributes. Custom top level attributes are common across all Offers. The set of Custom Issue/Group level 9-36

attributes differs from Offer to Offer, based on which attributes have been specified for the particular Issue and Group, to which the Offer belongs. Creating a New Attribute In order to specify a new Offer detail, the backing Proposition attribute must first be created. To add a new custom attribute: 1. Access the Proposition Hierarchy landing page tab: -> Decisioning -> Decisions -> Proposition Management -> Hierarchy 2. Refer to the following table for your next action: To Create a top level attribute Create an Issue/Group level attribute Do Ensure Top Level is selected under the Business Issues and Groups tree. Click the New Property button to launch the New form. Select the appropriate Issue/Group in the Business issues & groups tree. Click the New Property button to launch the New form. 3. Specify the Name and Type of the new attribute in Create Property form and click the Create button. Also, validate that the Issue and Group fields have been correctly set. Once the Proposition attribute has been created, it will be available as a Custom Attribute on the Details tab of all Offers that share the scope of this attribute. 9-37

Testing the Offer Flow Once the Offer Flow has been created and configured, it can be tested against seed customers to ensure the various paths of Offer Flow execution are working as expected. The Test Offer tab lists the various configuration options for setting up the Offer test. This includes the following options: Select Recipients Select a Seed List for executing the Offer test. The Offer test will be executed for each seed in the Seed List. All the data associated with the seed will be available as customer data in the Offer test execution and will be used (if referenced) in the various Offer Flow shapes. Refer to the Seed Lists chapter for information on configuring a Seed List. Select Starting Point Select an Offer Flow shape from where the Offer test should begin. All shapes present in the Offer Flow (with the exception of the End shape) are listed in the Starting Point drop-down and can be selected as the starting shape. 9-38

Select Channel and Direction Specify the channel and direction of communication for the Offer test. These values are particularly useful in testing different branches of Offer Flow execution which are dependent on the channel or direction. Once the Offer test settings have been configured, the Offer can be tested via the Test Offer button. At this point, the Offer is first saved. If the offer can be successfully saved, the test is submitted for execution. If the test path includes correspondence, this will be sent to the entries in the specified Seed List. Any response links that are present in the communication will be active and visible to the recipients. Recipients can click these links to test the response handling paths of flow execution. Information will not be captured for these responses in History. Any errors in the test are reported at the top of the Test Offer tab. Once these are corrected, the test can be re-executed. A success status is displayed upon successful commencement of the Offer test. The Track Results section lists the progress of recently executed and currently running tests. After configuring the Test Offer tab, the test process can also be initiated directly from a shape in the Offer Flow by utilizing the Test Offer from Here right-click menu item. This will trigger the Offer test using the settings specified on the Test Offer tab, with the starting point set to the triggering shape. 9-39

9-40

Chapter 10: Treatments A Treatment is the definition of the content that is delivered to a Customer as part of an Offer over a specific communication Channel. The System provides support for four kinds of Treatments Email, Passbook, Section, and SMS. Each of these types is further explored in subsequent sections. Each of the four Treatment types has its own node in the Offer Assets marketing explorer. Treatments can be defined at the top level or can be categorized into Issues and Groups. Email Treatments A newly created Email Treatment starts out with input fields - for the Email subject and key code - and a blank canvas to compose the email content, as shown below. 10-1

The Email Treatment rule includes the following tabs: Tab Name Treatment Test Message History Purpose Create the contents of the Treatment. Refer to Configuring the Email Treatment. Test the content and format of this Treatment by sending it. Refer to Testing the Email Treatment. Specify the Description and Usage information for this Treatment. Configuring the Email Treatment The Subject field allows the user to specify the subject for the Email. The Email subject can be static text, a property reference, or an expression which combines both static text and property references. The user can also utilize the Key Code field to specify a code for the Email Treatment. This code can be used by downstream functionality, such as the Send Email shape in the Offer canvas. When the Track Email Open Rate checkbox is enabled, the System automatically captures Email opens (impressions) in Interaction History. This setting is enabled by default in a new Email Treatment. The Email Treatment Editor enables the user to design high quality treatments to send to customers. This editor supports two modes of editing: Design This is the default editing mode. In this mode, users can enter freeform content and use a wide array of editing tools to format this content. To apply formatting to content; select the content first and then, use the formatting icons to update the content s format. Source This mode is for advanced users and provides direct access to the source HTML for this treatment. In this mode, the formatting icons are disabled. Users can switch between the two modes above by toggling the Source button: The editor also includes an array of buttons to insert content (such as links, images, properties, etc.) into the Treatment: Two of the buttons in this array are essential in designing effective customer-focused treatments. These are further outlined below. 10-2

Embedding Relevant Data Relevant data can be embedded into the Treatment via the Insert Property button: Examples of this data include customer information, offer details, etc. Upon clicking the Add Property icon, the Add Property dialog can be configured to embed the necessary data field. In addition to specifying the name of the field to be embedded, users can also specify: Format Reference to a Format rule that determines how this field should be formatted. When Reference to a When rule that determines whether this field should be displayed or not. Embedding a Response Link Response links can be embedded into an Email Treatment via the Insert Button icon: Clicking the icon opens the Button Parameters dialog. This dialog presents the user with a variety of options for configuring the response mechanism for the Treatment. The type of response link is determined by the value selected in the Function dropdown. The following options are available: Accept Offer - This option embeds a link for the customer to accept the Offer. The user must select whether to direct the customer to a response screen or to an external URL. 10-3

Decline Offer - This option embeds a link for the customer to decline the Offer. The user must select whether to direct the customer to a response screen or to an external URL. Open Internal Page This option embeds a link to launch an internal page. The user must specify the name of the response screen (internal page). Open External URL This option embeds a link to launch an external URL. The user must specify the external URL to open. 10-4

Tracking Click Rate For each of the above functions, the user can enable the Track Click Rate option. The System automatically tracks clicks (in Interaction History) for any response links that are generated with this option enabled. This setting is enabled by default. Redirecting to a Response Screen This option is available for the Accept Offer, Decline Offer, and Open Internal Page links. The user can configure a response screen (internal PRPC page typically represented by a Section rule) to be displayed when the customer clicks on a response link in the Offer email. For Accept Offer and Decline Offer, the response screen value is defaulted to the value configured by the Application administrator. In these cases, a typical response screen should represent a confirmation for the action taken by the customer (accept or decline) and any other information that needs to be presented. For Open Internal Page, the response screen can be considered as a page to provide more information on the Offer. This page can contain appropriately configured action buttons (such as accept and decline) that the customer can use to respond to the Offer. If the value for the response screen is not set, the OOTB default response screen (DefaultEmailResponse) will be used. Both Customer and Offer Data are available to be referenced when building/configuring a custom response screen. Note: Response Screens must be created in the PegaMKT-Work-Offer class. Redirecting to an External URL This option is available for the Accept Offer, Decline Offer, and Open External URL links. The user can further choose whether relevant Offer Data should be included while re-directing to the external URL. If selected, these values are passed as URL parameters to the external URL being launched. The following parameters are furnished: C Customer ID R Customer response I Issue of the Offer G Group of the Offer O Name of the Offer T Name of the Email Treatment W ID of the Program Run that initiated the Offer RA Rank of the Offer in the Program Run (batch output) table OU Name of the Program Run (batch output) class containing the Offer instance 10-5

Adding Style Options The following style options can be specified for the response link: Button Text The text that is displayed to the user as the link Button Image Reference to an image that is displayed alongside the link Custom Style CSS formatting style that should be applied to the link Previewing Included Sections The Show the preview of included section checkbox (at the bottom of the Email Treatment editor) enables users to preview sections inline in the editor. Testing the Email Treatment The Test Message tab on the Email Treatment provides an easy way to test the look and feel of the Email Treatment when it is actually delivered. The following options are available for configuring the test message: To Recipients of the test email. Select either Test Recipients or Seed List. Test Recipients Enter list of recipients. Each entry can either be the Operator ID of an existing user in the system or a valid email address. If the operator ID is entered, operator information such as the name and email is populated as the customer data and the test email is sent to the operator s email address. 10-6

Seed List Select a pre-defined Seed List as the intended recipients of the test email. The data for each seed is populated as the customer data and is visible (if referenced) in the test email. In this case, the Email1 column in the Seed List (.pyemail1 property) specifies the email address to which the test email is sent. Refer to the Seed Lists chapter for information on configuring a Seed List. Email Subject Enter the subject for test email. Test Account Settings Specify Email Account settings for the test email. Use Default Email Account Select this option to use the Default outbound Email Account. Specify Email Account Select this option to specify the outbound Email Account to use for delivering the test email. Specify the account name in the Account field. From/Reply To: Use Email Account Settings - Select this option to use the sender s name (From) and reply-to address that is configured on the Email Account being used. 10-7

From/Reply To: Use Operator Settings - Select this option to use the name and email address of the current operator for these values. From/Reply To: Override Account Settings Select this option to specify the sender s name (From) and reply-to address for the test email. Specify these values in the From and Reply To fields. After the test message has been configured, it can be sent via the Send Test Message button. Upon clicking this button, the Email Treatment is saved and the test email is sent to the specified recipients. The status of the test is displayed. Any errors in the test delivery are displayed in case of a failure. These can be corrected and the test email can be resubmitted for delivery. 10-8

Passbook Treatments Passbook is an application available on ios devices (such as iphone or ipod touch) that can be used to store things (termed passes) such as boarding passes, tickets, and coupons. These passes can be used to perform appropriate tasks, such as checking in to a flight or redeeming a coupon. A Passbook Treatment enables marketing users to design the contents of a pass using interactive tools and a preview pane that displays a rendering of the pass based on the user s configurations. Users can configure each element of a pass, preview the impact of their changes, and test the generated pass by sending it as an email attachment. Each pass is associated with a pass style. This style determines the overall visual appearance of the pass and impacts the placement of different fields on the pass. Currently, the System supports the following Passbook Styles: Coupon Appropriate for coupons, discounts, and special offers Generic Appropriate for all other uses Users must select the Passbook Style for the pass as part of creating a new Passbook Treatment. Users can t change the style of a Passbook Treatment while copying. A newly created Generic Passbook Treatment starts out as shown below. 10-9

The Passbook Treatment rule includes the following tabs: Tab Name Passbook Details Advanced Test Message History Purpose Configure the contents of the pass and preview how the pass will be rendered. Refer to Configuring Pass Elements. Configure how pass updates should be handled. Refer to Configuring Advanced Passbook Options. Test the content and format of this Treatment by sending it. Refer to Testing the Passbook Treatment. Specify the Description and Usage information for this Treatment. Note: For more details on Passbook, refer to Apple s Passbook Programming Guide, available at: https://developer.apple.com/library/ios/documentation/userexperience/co nceptual/passkit_pg/chapters/introduction.html 10-10

Configuring Pass Elements The various mini-tabs in the Passbook Details tab allow users to configure and preview different elements of the pass. The System automatically updates the Preview pane as the configuration settings in the tabs are changed. General tab Use this tab to configure the following general settings for the pass: Category Name Purpose Key Code Key Code Marketing key code for the pass. This can be displayed on the pass and/or can be used internally for tracking purposes. Description Visual Elements Visual Elements Visual Elements Visual Elements Accessibility Description Pass icon High-res (or 2x) pass icon Strip image (Coupons only) Thumbnail image (Generic passes only) Description that the device will use for accessibility to differentiate this pass from other passes Icon that the Apple device shows with the pass on the lock screen and in ios apps (such as Mail) when representing this pass. A preview of the selected icon is shown next to the field. High-res version of the pass icon (used in Retina displays) Image that displays behind the Primary fields Image that displays to the right of the Primary fields Colors Large text elements Color used for the values of the fields shown on the front of the pass Colors Label text elements Color used for the labels of the fields shown on the front of the pass Colors Background of the passbook Color used for the background of the front and back of the pass For images, users can use the icon to launch the Image Catalog, which can be used to search and select the desired image. For specifying colors, users can either directly enter the hex code for the color or click the color square (next to the input box) to launch the Color Picker. The Standard tab provides commonly used standard colors while the Custom tab provides multiple ways to select/specify the desired color. 10-11

Pass Header tab Use this tab to configure the pass header. This tab is split into the following two sections: Header Visual Appearance Header Fields Header Visual Appearance Use the following settings to configure the header logo: Name Main logo High-res (or 2x) logo Logo text Purpose Logo image that displays at the top left corner of the pass High-res version of the logo icon (used in Retina displays) Optional text that displays next to the logo icon For images, users can use the icon to launch the Image Catalog, which can be used to search and select the desired image. Header Fields Use this section to add fields to be displayed in the pass header. Users can configure a maximum of three fields for the header. Header fields are the only fields that are visible when the pass is stacked with other passes in the Passbook app. They should be used sparingly to show only the most vital pass information. Refer to Configuring Pass Fields for details on configuration options for pass fields. 10-12

Primary tab Use this tab to configure the primary field for the pass. The primary field typically contains the most important pass information and is displayed prominently. Refer to Configuring Pass Fields for details on configuration options for pass fields. Secondary tab Use this tab to configure the secondary fields for the pass. Users can configure a maximum of four secondary fields. Secondary fields are less prominent than the primary field and are typically shown in a smaller font size. Users should specify secondary fields in the order of their importance. Refer to Configuring Pass Fields for details on configuration options for pass fields. Auxiliary tab Use this tab to configure additional fields to display on the pass. Users can configure a maximum of four auxiliary fields. If secondary fields are present, they will take precedence over auxiliary fields. Refer to Configuring Pass Fields for details on configuration options for pass fields. Note: In most cases, coupons and generic passes can have a maximum of four secondary and auxiliary fields, combined. Barcode tab Use this tab to specify the barcode configuration for the pass. Users can include a barcode in the pass and configure the data contained in the barcode. Users can also choose to display a text message beneath the barcode. The barcode inclusion in a pass is optional and users can choose to create a pass without a barcode. The System provides support for the following barcode formats: Aztec Quick Response (QR) code Portable Data file (PDF) 417 After selecting the barcode format, users need to select what should happen when the barcode is scanned. The System provides support for the following two options: Register a positive response when a barcode is scanned Select this option to have the System record a positive response for the Offer through which this pass is delivered. In this scenario, the System injects a callback link with pertinent details. When the pass s barcode is scanned, the 10-13

injected link invokes appropriate the service on the System and the positive response is captured. Customize the barcode data Select this option to specify the data to be stored in the barcode. The barcode format determines the amount of data that the barcode can contain. Refer to the official documentation for each of these formats for more details on their data limits. In this scenario, no response is captured as part of scanning the barcode. Response capture (if needed) must be handled in a different part of the process. Users can also choose to specify a text message that will display with the barcode. This field can be used to display human-readable information (such as coupon codes or membership numbers). This is particularly useful if the pass can be used at places where a barcode scanner might not be available. Finally, some barcode scanners require the data encapsulated in the barcode to be encoded. Users can specify the encoding to use or use the default encoding (ISO 8859-1). Relevance tab Use this tab to configure locations at which this pass will be relevant. Users can specify up to ten locations. When a holder of this pass is at (or within) one of the specified locations, the specified notification message is displayed on the holder s device. For each location, the user can specify: Location information - Users can either select a pre-configured Geofence rule or directly specify the latitude and longitude of the location. Refer to the Geofences chapter for more details on the Geofence rule. Notification message Users can specify the message to display on the pass holder s device when the holder is at/within the specified location. Back tab Use this tab to configure fields to display on the back of the pass. Users can specify up to twenty fields for the back of the pass. Users care use back fields to specify fields that are too long for the front of the pass (e.g. terms and conditions) or any other additional information that may be helpful for pass holders. If the contents of the back exceed what can be displayed on the screen at once, pass holders are able to scroll through the contents. Refer to Configuring Pass Fields for details on configuration options for pass fields. 10-14

Configuring Pass Fields Users can add and remove fields from the various tabs by using the appropriate buttons displayed over the grid, as shown below: For each field, users must specify the following: Type Type of the field. Choose from a wide variety of supported types, such as String, Number, Date, and Currency. For back fields, the type is String and can t be changed. For Date, DateTime, and Time, use the corresponding Dynamic option if the value is a property reference. Label Label of the field. In most cases, the field label is displayed above the field value. However, for coupons, the primary field s label is displayed below (and less prominently than) the field value. The label can be static, a property reference, or an expression. Users can use the icon to open a referenced property and the icon to launch the expression builder. Value Value of the field. The value can be static, a property reference, or an expression. Users can use the icon to open a referenced property and the icon to launch the expression builder. Format Format used to display the field. Users can specify formats for all field types with the exception of String. The list of available formats depends on the type of field. Since back fields are of type String, the Format option is not available for back fields. Alignment Alignment of the field text. Users can select the desired alignment for all fields with the exception of primary fields in coupons using one of the alignment buttons. 10-15

Note: For specific details on the various elements involved in pass creation (such as images, fields, and barcodes), refer to the Pass Design and Creation chapter of Apple s Passbook Programming Guide, available at: https://developer.apple.com/library/ios/documentation/userexperience/conce ptual/passkit_pg/chapters/creating.html Configuring Advanced Passbook Options The Advanced tab in the Passbook Treatment rule form enables the user to configure how updates to passes should be handled. The System provides support for two options when the same pass is sent multiple times to a customer (pass holder): Send a new pass every time a new offer or program uses this treatment In this option, the System will send out a new pass each time this Passbook Treatment is used in a new Offer or Program. Keep updating the pass even if different offers use this treatment In this option, the System will instead update the existing pass when this Passbook Treatment is used in a new Offer or Program. The pass update will be propagated to the customer s device using the update mechanism specified in the Send Passbook Treatment shape on the Offer canvas. A treatment with this option enabled is frequently referred as a global treatment. Testing the Passbook Treatment The Test Message tab on the Passbook Treatment provides an easy way to test the look and feel of the Passbook Treatment when it is actually delivered. Users can test the look and feel of the email containing the pass and the actual pass itself (by opening the attached pass). Configuring and Sending the Test Email The following options are available for configuring the test message: To Recipients of the test pass. Select either Test Recipients or Seed List. Test Recipients Enter list of recipients. Each entry can either be the Operator ID of an existing user in the system or a valid email address. If the operator ID is entered, operator information such as the name and email is populated as the customer data and the test email is sent to the operator s email address. 10-16

Seed List Select a pre-defined Seed List as the intended recipients of the test email. The data for each seed is populated as the customer data and is visible (if referenced) in the test email. In this case, the Email1 column in the Seed List (.pyemail1 property) specifies the email address to which the test email is sent. Refer to the Seed Lists chapter for information on configuring a Seed List. Test Email Subject Enter the subject for the test email. 10-17

Test Account Settings Specify Email Account settings for the test email. Use Default Email Account Select this option to use the Default outbound Email Account. Specify Email Account Select this option to specify the outbound Email Account to use for delivering the test email. Specify the account name in the Account field. From/Reply To: Use Email Account Settings - Select this option to use the sender s name (From) and reply-to address that is configured on the Email Account being used. From/Reply To: Use Operator Settings - Select this option to use the name and email address of the current operator for these values. From/Reply To: Override Account Settings Select this option to specify the sender s name (From) and reply-to address for the test email. Specify these values in the From and Reply To fields. 10-18

After the test message has been configured, it can be sent via the Send Test Message button. Upon clicking this button, the Passbook Treatment is saved and the test email (containing the attached pass) is sent to the specified recipients. The status of the test is displayed. Any errors in the test delivery are displayed in case of a failure. These can be corrected and the test can be resubmitted for delivery. Reviewing the Test Pass When the test email is opened on an ios device (such as an iphone or ipod touch), the attached pass is shown with the selected pass icon and the organization name. 10-19

Click the pass to open it the front of the pass is displayed. Click the icon to view the back of the pass. Use the Done button to return to the front of the pass. Use the Add button to add the pass to your passbook. Front of the test pass Back of the test pass 10-20

Sections A newly created Section starts out as shown below. For more information about creating Sections, refer to the PRPC Help documentation. Note: Unlike other Marketing artifacts, a Section rule does not show Issue/Group drop-downs in the New form. However, these are still correctly set based on the context of the tree node from which the Section is created. To ensure proper access to relevant resources, it is recommended that marketing-specific Sections should always be created from the appropriate Sections node in the Offer Assets explorer. 10-21

SMS Treatments A newly created SMS Treatment starts out with an input field for the key code and a blank canvas to compose the SMS message, as shown below. The SMS Treatment rule includes the following tabs: Tab Name Message Test Message History Purpose Create the contents of the Treatment. Refer to Using the SMS Treatment Editor. Test the content and format of this Treatment by sending it. Refer to Testing the SMS Treatment. Specify the Description and Usage information for this Treatment. Using the SMS Treatment Editor The SMS Treatment Editor enables the user to specify the contents of the SMS message. Users can simply type the content of the message into the editor. The SMS editor provides the following features: Character Count - As a user types the message content, the editor displays the number of characters in the message. Once the content goes past the length of one SMS message (160 characters), the editor also displays the message number along with an informational note to the user about SMS message lengths. 10-22

Spell Check Users can use perform a spell check via the Check Spelling icon: Spelling errors are underlined in red. Clicking an incorrectly spelled word provides a list of possible corrections. Selecting one of these corrections replaces the incorrect word with the selected suggestion. Embedding Relevant Data Relevant data (such as customer information, offer details, etc.) can be embedded into an SMS Treatment via the Insert Property icon: Upon clicking this icon, the Property Parameters dialog can be configured to embed the necessary data field. In addition to specifying the name of the field to be embedded, users can also specify: Format Reference to a Format rule that determines how this field should be formatted. When Reference to a When rule that determines whether this field should be displayed or not. 10-23

Note: When an SMS message contains embedded fields, the character count is an approximation of the message length. Each embedded field counts as 15 characters towards the character count for the message. Testing the SMS Treatment The Test Message tab on the SMS Treatment provides an easy way to test the content of the SMS Treatment when it is actually delivered. The following options are available for configuring the test message: To Recipients of the test message. Select either Test Recipients or Seed List. Test Recipients Enter list of recipients. Each entry can either be the Operator ID of an existing user in the system or a valid mobile phone number. If the operator ID is entered, operator information such as the name and phone number is populated as the customer data and the test message is sent to the operator s phone number. Seed List Select a pre-defined Seed List as the intended recipients of the test SMS message. The data for each seed is populated as the customer data and is visible (if referenced) in the message. In this case, the Mobile Phone column in the Seed List (.pymobilephone property) specifies the phone number to which the test SMS message is sent. Refer to the Seed Lists chapter for information on configuring a Seed List. 10-24

Test SMS Account Options Specify SMS Account settings for sending the test SMS message. Use Default SMS Account Select this option to use the Default outbound SMS Account. Specify SMS Account Select this option to specify the outbound SMS Account to use for delivering the test message. Specify the account name in the Test Account field. After the test message has been configured, it can be sent via the Send Test Message button. Upon clicking this button, the SMS Treatment is saved and the test SMS message is sent to the specified recipients. The status of the test is displayed. Any errors in the test delivery are displayed in case of a failure. These can be corrected and the test message resubmitted for delivery. 10-25

Chapter 11: Templates A Marketing Template is the definition of the content that should be written to an external source as part of making an Offer. The System provides support for writing to both a file and a database table. Any outbound shape in the Offer Flow can be configured to write to a File Template and/or a Database Template. This includes the following shapes: Send Email Send SMS Send Generic Sent Multiple Treatments Like most other Marketing artifacts, Templates can be created at the top level or can be categorized under Issues and Groups. The categorization level of the Template determines the attributes (Offer details) that are available for use within the Template. Both File and Database Template rules have the following tabs: Tab Name Definition Details Finalize History Purpose Configure the output location and the writing mode. See Configuring Output Destination. Specify the contents to be written to the output source. See Configuring Output Content. Configure schedule options, delivery options, and postprocessing activity. See Configuring File/Table Finalization. Specify the Description and Usage information for this Template. 11-1

File Template File Templates are listed on the File landing page, which is accessible via: -> Channels -> File -> Outbound File Database Template Database Templates are listed on the Database landing page, which is accessible via: -> Channels -> Database -> Outbound Table Configuring Output Destination The following output destination configurations are available (on the Definition tab). Some of this information can also be directly entered in the New or Save As dialog when creating or copying a Template. Name Mode Purpose File Path File Path on the System machine where the output file should be stored File Name File Name of the output file where the output content will be written 11-2

Name Mode Purpose Database Database Name of the Database rule to use to create the output table Table Database Name of the table where the output content will be written Overwrite existing data Append to existing data File, Database File, Database Whether existing output content should be over-written Whether new output content should be appended to existing content A sample File Template with its output destination configured is shown below: When the Template rule is saved, the System performs the following validations on the output destination: File Template: Specified file path must be a valid folder/directory Write access must be available for the specified file path Administrator Note: Output file paths must be accessible by all configured System nodes. Database Template: Should be able to connect to the specified database Should be able to create tables in the specified database 11-3

Configuring Output Content The actual content that needs to be written to the output destination is configured via the Details tab. This content can include both data attributes and static text. When writing to an output file, users can choose to also specify header and footer information. Specifying Header/Footer Information This option is only available in File Templates. The following information can be added as part of the file header or footer: Free form text Any text specified by the user File name Name of the output file Record Count Number of records at the time of finalization Column Heading Names This option is only available for the file header and when the write mode is Overwrite. If this option is selected, column headers will be written to the output file upon file finalization. Specifying Output Fields The following types of information can be added as part of the Fields list: Data Fields Any relevant data fields (such as customer information, Offer details, etc.) Text Free form text entered by the user The Name column in the grid denotes the name of the database column or file column header, while the Content column denotes the actual value for the individual records. For File Templates, the user can also specify a format for dates and numeric fields. When one of these fields is selected in the Content column, the Format column is loaded with the appropriate set of available formats. A sample File Template with its output content configured is shown below: 11-4

Configuring File/Table Finalization When the necessary output content has been written to an output file or database table, it can be finalized. Finalization results in any pending data to be written to the output file/table. For the overwrite existing data mode of writing, upon finalization, the staging.lock file or _LOCK table is converted to its proper version without the lock in the name. Finalization can be triggered in the following two ways: Manually by the user - Users can choose to finalize a file or table by selecting either the Finalize or Finalize and Download action on a particular entry from the Outbound File/Database Template landing page. Automatically by the System based on a schedule The Schedule for finalizing a file or table can be specified via the Schedule options on the Finalize tab. Enable the Enable Schedule checkbox and configure the desired schedule options. 11-5

Users can choose to send email notifications in either one or both of the finalization trigger scenarios. To enable notifications, enable the checkbox for the desired scenario(s) in the Delivery Options section. Configure the recipient(s), subject, and body of the notification email. For File Templates, users can also choose to attach the finalized file to the notification email. 11-6

Note: The recipient of the finalization email must be an operator in the System. The finalization email will be sent to the email address associated with the operator s record. Finalization also serves as a hook for a post-processing activity, if one is specified. An example usage of this could be to upload the finalized file via FTP to a processing system. The post-processing activity can be configured in the Advanced section of the Finalize tab, as shown below: File/Table Landing Page Actions The Outbound File and Outbound Table landing pages provide various actions (via the Action menu) that can be taken on a specific file/table. The set of available actions depends on the status of the output file/table. This includes the following actions: Download - (File only) Download the output file. Finalize Trigger finalization of the output file/table. Finalize and Download (File only) Trigger finalization of the output file, and then download the resulting file. Preview (Database only) Presents a CSV file containing a subset of the contents in the database table. The number of records returned in the preview file is configurable by the Application administrator. Retry In case of a failure, this option can be used to retry writing the records to the appropriate output file/table. 11-7

Chapter 12: Offer Bundles In typical marketing scenarios, it is often desirable to group offerings into bundles. There may be varied reasons for doing so, such as incentivizing, logistics, etc. To address this marketing need, the System provides support for grouping Offers into bundles. Offer Bundling Basics Offer Roles Offers in an Offer bundle can be categorized into the following two roles: Parent Offer - Each bundle must have one parent Offer. Typically, the Offer flow for the parent Offer will propagate the offering of its member Offers. For example, the parent Offer flow will send an email with details about its member Offers and action links to respond to the Offers. Member Offer - Each bundle can have multiple member Offers. Offer Bundle Types The System supports three modes of Offer bundling. These modes are henceforth referred to as bundle types. Fixed Bundle - This bundle type should be used when customers must purchase the bundle in its entirety (all members). In this mode, the parent Offer flow is the only flow that is processed. All interaction history (IH) records are recorded for the parent bundle and all of its members. Any response will progress the parent offer flow. Flexible Bundle - This bundle type should be used when customers can purchase the entire bundle or can pick individual members to purchase. In this mode, the parent Offer flow is used as a container for distributing communication about the collection of offerings. A response to an individual offering will only start that member's Offer flow. Any IH recording in the member Offer flow will record information for the member Offer and the parent Offer. Responding directly to the parent bundle Offer will trigger all member Offers that haven't been started. However, the parent Offer flow will not progress. Grouped Offers - This bundle type should be used when the user has a selection of Offers they wish to market together to the customer. The individual Offers themselves may not have any correlation to each other. In this mode, (similar to the flexible bundle mode) the parent Offer flow is used as 12-1

a container for distributing communication about the collection of offerings. A response to an individual offering will only start that member's Offer flow. However, unlike a flexible bundle, any IH recording in the member Offer flow will only record information for the member Offer. Responding directly to the parent bundle Offer will not start any of the member Offers, but will progress the parent Offer flow. The differences in the behaviors of the three bundle types are summarized in the table below: Scenario Fixed Bundle Flexible Bundle Grouped Offers Offer initiation - Start the parent Offer flow - Record initial IH entry for parent and all members - Start the parent Offer flow - Record initial IH entry for parent and all members - Start the parent Offer flow - Record initial IH entry for parent and all members Respond to Email link for bundle (all members) - Resume the parent Offer flow - Start all member Offer flows that haven t been started - Parent flow does not resume - Resume the parent Offer flow Respond to Email link for individual Offer - Resume the parent Offer flow - Start/resume the member Offer flow - Start/resume the member Offer flow Update Status shape in parent Offer - Record IH response for parent and all members - Record IH response for parent and member Offers that haven t been started - Record IH response for parent and member Offers that haven t been started Update Status shape in member Offer N/A (since member Offer is never started) - Record IH response for member and its parent - Record IH response for member only Parent Offer completion - Complete parent and all member Offers - Complete parent and member Offers that haven t been started - Complete parent and member Offers that haven t been started Member Offer completion N/A (since member Offer is never started) - Complete member Offer only - Complete member Offer only Note on Offer Bundles and Volume Constraints: Volume Constraints are currently only applied for fixed bundles. 12-2

Specifying Offer Bundle Settings There are two ways to specify the Offer bundle settings for an Offer. 1. Using the Details Tab on the Offer Rule Form The "Details" tab on the Offer rule form contains the "Bundle Attributes" section which can be used for specifying the following bundle settings. Bundle Name - Specify the name of the Offer bundle. This name should be the same for all Offers (both parent and members) in the bundle. Offer Role - Specify the role this Offer will play in the bundle. Select "Yes" if this Offer is a parent Offer, otherwise select "No". Also, select the bundle type for the parent Offer. 2. Specifying Bundle Characteristics in the Strategy Bundle characteristics for Offers can also be directly specified in Strategies. Strategies can also be used to override the bundle settings specified on the Offer. The settings on the Offer Details tab can be considered as defaults, which can be overridden in Strategies (if desired). The following example illustrates setting bundle characteristics using a Strategy rule. 12-3

For the parent Offer, the bundle type is specified ("FixedBundle", "FlexibleBundle", or "GroupedOffers") and the bundle parent flag is set to true. For all Offers (parent and two members), the bundle name is specified. In the above example, the parent Offer's name is used as the bundle name. Designing Offer Flows for Bundles When designing Offer flows for bundled items, the user must take into consideration the role of the Offer. For the parent Offer, the flow can also be tailored differently based on the bundle type. Designing the Parent Offer The parent Offer flow is responsible for sending out the email containing details of the bundle and its members. This email can also contain links to respond to the bundle and/or individual Offers. This initial responsibility is the same across all three bundle types. Once the email has been sent, the behavior of the parent Offer flow typically varies slightly based on the bundle type. 12-4

Fixed Bundle In a fixed bundle, the parent Offer flow is responsible for handling responses received for the bundle, as shown in the flow snippet below. Flexible Bundle In a flexible bundle, the parent Offer flow is only responsible for the initial communication of the Offer bundle. Responses received for the bundle will not progress the parent flow. A simple parent flow is shown below. Grouped Offers In a grouped bundle, the parent Offer flow is responsible for the initial communication. Typically, bundle-level response links are not provided in this mode. If a bundle-level link is made available, the parent Offer flow will be resumed. This could be used to trigger a follow-up email with more information and/or update IH records for the parent and all member Offers that haven't been started. Designing Member Offers The flow for a bundle member Offer differs slightly from typical Offer flows since the initial communication of the Offer has already been made by the bundle parent Offer. The Offer flow also differs based on the bundle type. 12-5

Fixed Bundle In a fixed bundle, the member Offer flow is never started. Thus, the member Offer flow can simply be an empty flow. Flexible Bundle and Grouped Offers In both these modes, the member Offer flow is started (or progressed) when a response is received. With the exception of the initial Offer communication, these flows can be designed just like standard Offer flows. Designing Email Treatments for Bundles When designing Email Treatments for bundles, the user needs to consider the type of the bundle. A typical Email Treatment for an Offer bundle includes an overall description of the bundle and details for each of its members. Additionally, based on the bundle type, response links can be provided at the bundle and/or the member level. The top level "BundleTemplate" Email Treatment is provided as an OOTB sample. This treatment includes the following salient pieces of a bundle Email Treatment: Bundle name - References ".OfferData.BundleName" property Response link for bundle Added using the Insert Button functionality Impression capture - References "RecordImpression" section. With bundles, it is typical to include the impression capture section at the parent/bundle level. Member details - References "BundleTemplate" section. This section uses the "BundleOfferMembers" page list property to display the member Offers in a grid with accept and reject response links for each member. 12-6

The "BundleOfferMembers" property is populated at runtime to contain details of the various bundle members. This can be used in dynamic containers such as the repeating grid. Users can also make static references to member offers in this page list. For example, to display the name of the first Offer in the bundle, reference the ".BundleOfferMembers(1).OfferData.pyName" property. Another common usage pattern is to update the grid in the "BundleTemplate" (or equivalent) section at the top level (PegaMKT-Work-Offer) to include a subsection for displaying relevant Offer information, say MemberOfferDetails. Users can then create a top-level version of this section to serve as a base for all member Offers. To customize the details for a particular issue or group, the user simply needs to override the details section in the appropriate issue or group class. Offer Bundle Counts in Program Displays Offer bundles are treated slightly differently than regular offers in terms of Program and Program Run statistics. Offers in bundles are counted based on their bundle type. Fixed and Flexible Bundles - For both these bundle types, the bundle is counted as a whole. As an example, for a bundle with ten members: Offer bundles initiated = 1 per customer that receives the bundle Total Offers initiated = 1 per customer that receives the bundle Grouped Offers - For this bundle type, the member Offers are counted. As an example, for a bundle with ten members: Offer bundles initiated = 1 per customer that receives the bundle Total Offers initiated = 10 per customer that receives the bundle Program Display When a Program includes Offer bundles, this is illustrated with a checkmark in the Run Summary panel on Program displays. 12-7

The number of Offer bundles and total Offers initiated is displayed in the "Program Performance Details" modal dialog. Program Run Display When a Program Run includes Offer bundles, this is annotated alongside the number of Offers identified by the strategy. In addition, the number of Offer bundles and total Offers initiated is displayed in the "Customers & Offers" tab. 12-8

Chapter 13: Microsites A Microsite is a collection of one or more pages which can function as a standalone entity. Microsites can be standalone or can be embedded into existing websites. Microsites can be used for various marketing purposes, such as product announcements and lead generation. Microsites are listed in the "Offer Assets" explorer in Next-Best-Action Studio. Microsites can be defined at the top level or can be nested under an existing Microsite. Note: Next-Best-Action Marketing leverages PRPC 7.1's Stage-based Case Management functionality for building Microsites. Refer to PRPC documentation for more details on this functionality. Creating a Microsite To create a new Microsite, use the "New" right click action on the "Microsites" node or an existing Microsite node. The new Microsite will be created at the appropriate level - either top or under the existing Microsite. Provide a name and description for the Microsite. Users can optionally also configure advanced settings such as inheritance and ruleset information in the modal dialog. 13-1

Upon clicking "OK", the System creates a new class for the Microsite (with class name PegaMKT-Work-Microsite-<MicrositeName>). The System also creates starter rules for the Microsite in this class and then presents the stage-based Microsite view. A newly created Microsite starts out with the following stages: Load Data In this stage, customer and Offer data (if available) is loaded so that it can be used by later stages. For this data to be loaded, at runtime, the Microsite must be launched from a customer and/or Offer-aware context. An example of such a context would be an Offer email that was sent to a customer with a link to the Microsite. Display Microsite 13-2

In this stage, the Microsite is displayed to the customer. A new Microsite starts with a single page, titled "Page1". The System has generated corresponding Flow, Flow Action, and Section rules to support this page. Primarily, users should only modify the section to specify the contents of the Microsite. Use the "Open section" action to open the section rule form. Save Data In this stage, values entered by the customer on Microsite pages are saved. This stage saves two types of data: o Offer data These values can later be used in the progressed Offer flow. o Custom Site data These values are custom fields created and specified by the users. Refer to Custom Site Data for more details. Progress Offer In this stage, the Offer that initiated the Microsite (e.g. via an email containing a link to the Microsite) will be progressed along the "ResponseReceived" path. By default, the response value is set to "Accepted". 13-3

Confirmation In this stage, a confirmation page is displayed to the customer. The OOTB generated confirmation page section is titled "Confirm". Managing Microsite Stages The stages listed above are the default stages created for a new Microsite. Users can add and remove stages to suit the desired requirements for their Microsites. For example, a Microsite that is not customer or Offer-aware wouldn't require the "Load Data" and "Progress Offer" stages. Adding a new Stage Use the + Add stage placeholder stage at the end to add a new stage. Deleting a Stage Use the "Delete this stage" action from the stage menu to delete an existing stage. 13-4

Reordering Stages Use the "Edit Stages" button to launch the edit stages modal dialog. It is possible to add/remove stages and reorder stages from this dialog. Configuring a Stage Each stage can have one or more steps that it performs. Typical steps for Microsites are provided OOTB and are associated with the default stages, e.g. load data, save site data, progress offer, etc. A marketing-specific step type is the page. Page steps are quick ways to inject a screen (or page) into the Microsite process. To add a new page, select the "Add Page" item in the steps area of a stage. Enter the desired page name and the System will automatically create the backing structure (flow, flow action, and section). Use the "Open Section" action to open the section rule form. A newly created section is shown below. 13-5

Use the section editor to include any pertinent information to display to and/or gather from the customer. The "Next" button can be customized as well. To do so, override the "NextButton" section in the Microsite class and apply any desired styles to it. Use the "Delete this page" action to remove the page step from the stage. The backing artifacts are not deleted and this page step can be added back to the stage at a later point. For advanced configuration, use the "Configure process detail" link to view the settings for the stage. Use the "Back to stages" button to return to the stages view. 13-6

Launching another Microsite Sometimes, users may wish to launch a different Microsite at a particular stage in their Microsite. This can be done by using either the "Redirect Microsite" or the "Launch Microsite" step, as outlined below. 1. Add a new step or determine the existing step to replace. In this example, a step has been added to the confirmation stage to redirect to another Microsite. 2. Specify the step name as "Redirect Microsite" 3. Save the Microsite configuration 4. Click the "Configure process detail" link to switch to the advanced view. 5. In the newly added step, select the "RedirectMicrosite" flow from the left navigation. 6. The step configuration will display in the right pane. A message will explain that the selected step is a base version and must be specialized to edit. Click the "Specialize" button. 7. Save the Microsite configuration 8. Use the "Back to stages" button to return to the stages view. 13-7

9. Select the "Open" action for the "Redirect Microsite" step. 10. This should open the specialized version of the "RedirectMicrosite" flow. Check out this flow (if applicable). 11. Open the properties panel for the "RedirectMicrosite" utility shape. 12. Update the "MicrositeClass" parameter value to the class of the Microsite to redirect the customer to. 13. Save the flow and check it back in (if applicable). Defining and Using Custom Fields Users can define custom fields to use in the pages of the Microsite. Any custom field should be defined in the PegaMKT-Data-Microsite class. In the following example, two custom fields "NewValue" and "ProspectEmail" have been defined in the custom data class. 13-8

These fields can then be used in a Microsite page to display/capture information. Access these fields via the ".CustomSiteData" page property on the Microsite class. Use the "Save Site Data" step to save the values entered by the customer for custom fields. Embedding a Microsite Link in an Email Treatment Users can use email treatments to provide links to a Microsite. These links can be configured to contain the customer and Offer context, thereby allowing the Microsite to be customer/offer-aware. Such Microsites can load customer and Offer data, display it to the user, save Offer data (where applicable), and progress the Offer. The following steps outline the process involved in adding a Microsite link in an Email Treatment: 1. Use the "Insert Button" functionality on an Email Treatment to configure the Microsite Link. 2. Select "Open External URL" as the button function. 3. Enter the URL for the Microsite: http://<server>:<port>/ms/index.html?site=<micrositename> 4. To include customer and Offer context in the link, enable the "Include Offer Data" checkbox. 5. Specify text, image, and style for the link (as desired). A sample configuration is shown below: 13-9

Launching and Testing Microsites Microsites can be launched and tested via the following URL: http://<server>:<port>/ms/index.html?site=<micrositename> Note: The above URL pattern can only be used for testing and launching Microsites once the Microsite war (provided as part of Next-Best-Action Marketing) has been installed and configured by the application administrator. Administrators should refer to the installation guide for more details. Example Microsite Configurations This section outlines two basic Microsite configurations to demonstrate the use of custom site data and customer/offer data in Microsites. 1. Microsite using Custom Site Data The following Microsite serves as a basic example of displaying and saving custom site data. This Microsite is not Offer or customer-context aware. This Microsite shows a simple page with the discounted value for the product and provides an input field for customers to sign up. 13-10

The "Page1" section uses two custom site fields (via the.customsitedata page property). A snippet of this section is shown below: The confirmation section simply displays the previously entered (and then saved) email. Since this Microsite does not have an Offer context, the "NewValue" custom data property is initialized via the "pydefault" Data Transform rule in the class of this Microsite. Note: It is critical that this Data Transform must be in the Microsite-specific class and must have the "Call superclass data transform" checkbox enabled. 13-11

Upon launching the Microsite launch URL with "Site=SampleMicrosite", the following is displayed: After entering an email and clicking "Next", the confirmation page is displayed: 2. Microsite using Customer and Offer Data The following Microsite serves as a basic example of utilizing the customer/offer context. This Microsite first loads the relevant Offer and customer data. At runtime, the Offer context is determined from the URL used to launch the Microsite. This context is then used to load the Offer and customer data. The Microsite then uses this data to display a personalized page to the customer with pertinent customer and Offer information. 13-12

In the above section, customer data is referenced via the ".Customer" page property, while Offer data is referenced via the ".Offer.OfferData" page property. On the next page, the customer is prompted for their priority code (an Offer data field). Once the customer enters this information, the "Save Site Data" step saves the Offer data value (since the Microsite is Offer-aware). The "Progress Offer" step resumes the Offer along the "ResponseReceived" path with an "Accepted" response. The Offer can utilize the saved Offer data value (Priority Code, in this example) and use it to branch the flow, as shown below: 13-13

In the above Offer, the initial email shape sends out a link to the Microsite. If the customer responds to this Offer (e.g. via the Microsite), the Offer flow uses the priority code (entered via the Microsite) to branch flow execution. At runtime, when the above Offer is initiated, the customer gets an email with a link for the Microsite. Upon clicking the email link, the Microsite is launched with an Offer and customer context. The Microsite loads the necessary data from these contexts and displays the first page. Upon clicking Next, the customer enters their priority code on the next screen. 13-14

Upon clicking Next again, the priority code is saved (as Offer data) and the Offer is progressed. The Offer uses the entered code value to branch flow execution. Finally, the confirmation page is displayed to the customer. Note on Deleting Microsites Typically, marketing users (and even organizations) do not delete Microsites as they have operational impacts. A Microsite is a publicly facing resource and, as such, deleting it will potentially break customer engagement links that are accessible. This results in a bad customer experience. Instead, in such cases, it is recommended that the user update the Microsite to have customer-facing content that suggests the Microsite is no longer relevant (or available). Administrator Note: In cases that the organization truly wants to remove a Microsite (such as one that was never made public), administrative users can utilize the Delete a Class wizard to delete the class (and all contained rules) that backs the Microsite. 13-15

Manage Subscription Preferences Microsite NBAM 7.12 provides an out-of-the-box sample implementation of a Microsite that manages a customer s subscription preferences. This is labeled the Subscription Microsite and its implementation class is PegaMKT-Work-Microsite-Subscription. This Microsite is associated as a Case Type on the shipped NBAM application. To use this Microsite with a different application, administrators must add it as a Case Type to the desired application. Note: The shipped implementation provides a basic infrastructure for supporting customer unsubscribes and management of subscription preferences. As such, custom implementations are expected to extend the provided functionality and integrate the saved preference data into their marketing processes (such as handling customer unsubscribes). Embedding Subscription Microsite Link Users can utilize the instructions in the Embedding a Microsite Link in an Email Treatment section to add link to the Subscription Microsite, with the following additional notes: URL pattern: http://<server>:<port>/ms/index.html?site=subscription Since the Subscription Microsite is customer-specific, users must enable the Include Offer Data checkbox. A sample link configuration is shown below: 13-16

Subscription Microsite Functionality When a customer receives an Email with the above link, they can click the link to launch the Subscription Microsite, as shown below: On the primary screen, the customer can select a reason for unsubscribing and click the Unsubscribe button to complete the process. Implementer Note: To include additional items in the list of unsubscribe reasons, create appropriate field values for the following property: PegaMKT-Data-Microsite.Reason The next screen displays a confirmation message to the customer. The customer can also use the link at the bottom of the primary screen to manage their subscription preferences. This launches the Subscription Preferences screen, which lists the various communication channels and the customer s current subscription preference for each of these channels. The customer can update individual preferences or can utilize the last checkbox to unsubscribe from all channels. These preferences are retained across multiple sessions. When the customer next visits this page, it will reflect their previous saved subscription preferences. In the 13-17

screen below, the customer had previously opted out of Email communications and, thus, the preference for the Email channel is unchecked. Upon saving the preferences, a confirmation message is displayed to the customer: Viewing Unsubscribe Data The shipped application also includes a sample Report Definition that allows marketing users to review details on customer unsubscribes for the Email channel. This report is available in the Report Browser under the Subscription category. 13-18

Clicking the above link launches the report, which displays a chart for the Email unsubscribes in the last 30 days. The chart groups unsubscribes by Treatment Name. Within each group/bar, there is a further classification based on the unsubscribe reason. In addition to the chart, the report also displays an expandable breakdown of unsubscribes by reason: Clicking on a region in the chart (or an expanded row in the reason breakdown) switches the display to a list. This list includes relevant details that were captured as part of the unsubscribe request, such as the Issue, Group, and Offer Name. 13-19

Subscription Microsite Configuration The Subscription Microsite is backed by the PegaMKT-Work-Subscription-Microsite class. When added as a Case Type in the user s application, this Microsite displays in the Microsites section of the Offer Assets explorer. This Microsite has the following primary stage flow: This includes the following stages: 1. Load Data This stage uses the LoadSupportingData flow to load data for the referenced customer. If a customer context cannot be established, this flow switches to the No Identified Customer alternative stage. 2. Unsubscribe This stage renders the primary unsubscribe screen. 13-20

3. Manage Preferences This stage loads the customer s previous preferences and renders the manage preferences screen. 4. Save Preferences This stage utilizes the UpdateSubscriptionPreferences flow to save any changes to the customer s subscription preferences. This flow also handles the cancel path, when the customer decides to discard their changes. 5. Confirmation This stage renders the confirmation screen. The Subscription Microsite also includes the following alternate stage flow: This includes the following alternate stage: 1. No Identified Customer This stage renders the Customer Not Found screen. Subscription Preference Data Class A customer s subscription preference is stored as an instance of the PegaMKT-Data- Subscription class. This class has the following two keys: CustomerID Channel An instance of this class represents a specific customer s subscription preference for a specific channel. Instances of this class are stored in the MKT_SUBSCRIPTION table in the ExternalMKTData data source. In addition to the above keys, the shipped implementation also includes the following properties in this class: LastUpdatedOn When the preference was last saved OfferIssue Issue of the Offer, from which the Microsite was launched OfferGroup Group of the Offer, from which the Microsite was launched OfferName Name of the Offer, from which the Microsite was launched Preference Subscription preference (true = subscribed, false = unsubscribed) Reason Reason for unsubscribing Treatment Name of the Treatment, from which the Microsite was launched 13-21

Chapter 14: Geofences A Geofence is a virtual boundary around a particular location. Marketing users can define Geofences in the System and then use them to trigger Events. For example, a customer entering (or nearing) a store could trigger the Geofence for that store. This could in turn trigger an Event whereby the customer is presented with an appropriate Offer. Users can also reference Geofences in strategies and can harness this to determine the most relevant Offer for a particular customer. Geofences are listed under the Geofences landing page, which is accessible via: -> Real-Time Artifacts -> Geofences The Geofences landing page provides a quick overview of the various fences configured in the Application. The Geofence rule can be opened by double-clicking the Geofence row or via the Open action from the Actions menu. Geofence Management This section explains the various modes available for managing Geofences. Creating a new Geofence To create a new Geofence, click the New button on the Geofences landing page. Enter a name for the Geofence in the Short Description field and click Create to launch the Geofence rule form. 14-1

A new Geofence rule resembles the following: The Geofence rule has the following tabs: Tab Name Design History Purpose Specify the location details and radius of the Geofence. View other nearby fences. Specify the Description and Usage information for this Geofence. Specifying Geofence Details The following options are available for specifying the Geofence s location: Address Users can directly specify the desired address in the input box. 14-2

Coordinates Users can specify the latitude and longitude of the desired location. After specifying the location for the Geofence, the Search button is used to locate the Geofence in the map. If the specified location is valid, the Map section will render the Geofence and the Details section will display available details for the Geofence. The radius of the Geofence and the unit of measurement can be modified. Upon modification, the Map will re-render using the new radius values. Interacting with the Map The rendered map is a Google map and allows for various interaction patterns, including the following: Zooming in and out Panning in all directions 14-3

Using Street View Viewing satellite imagery In addition to the above common interactions, the following Geofence-specific interactions are also available: Dragging the Geofence pin to relocate the Geofence s location. The details section will display the new address and coordinates. Resizing the Geofence by dragging any of the four endpoints (north, south, east, and west). The details section will display the new radius value. Viewing Nearby Geofences The map on the Geofence rule form can also be used to view nearby Geofences. This is helpful in determining potential overlaps across Geofences. By default, nearby Geofences are not displayed. Use the Nearby Geofences menu on the map to toggle the display of nearby fences. The following three options are available for nearby Geofences: 1. Hide Other Geofences This is the default option. In this mode, nearby Geofences are not displayed. 2. Show without Radius Select this option to view nearby Geofence locations. Each Geofence is represented by a blue pin and the radius of the Geofence is not displayed. Users can hover over the pin to view the name of the Geofence. 14-4

If multiple Geofences are located in too close a radius to render separately, they are represented together by a circle with the number of Geofences it contains. Users can click on the number to view a list of the contained Geofences. 3. Show with Radius Select this option to view nearby Geofences along with their radii. Each neighboring Geofence is represented by a blue pin as its center and a blue circle corresponding in size to its radius. As previously, if there is a high density of Geofences, they are represented by a circle with the number of contained Geofences. The shading of the circle also provides a visual cue to its density. Denser circles will be more opaque than less dense circles. 14-5

Viewing Associated Events Events that have been associated to this Geofence are displayed in the Associated Events grid. When a customer enters this Geofence, the Events listed in the grid will be triggered. Refer to the Events chapter for details on associating Geofences with Events. Importing Geofences Users can also choose to bulk import Geofences into the System. Click the Import button on the Geofences landing page to launch the Import Geofences process. The import process has the following three stages: Import Use the Browse button to select the comma-separated values (CSV) file containing the list of Geofences to import. After selecting the CSV file, use the Next button to proceed to the review stage. 14-6

Notes on the import file: File must be in CSV format The entries in the CSV must be in the following order: Geofence Name, Radius, Radius Unit, Latitude, Longitude, Street Address, City, State, Postal Code, Country Geofence Name must be provided Either location coordinates (latitude/longitude) or address (street/city/state ) must be provided for each Geofence, but not both. Radius unit should be either Miles or Kilometers. If radius unit is not provided, it is defaulted to Kilometers. If radius is not provided, it is defaulted to 1 Example Geofence entries: Using coordinates: PegaBedford,2,Miles,42.928,-71.464,,,,, Using address fields: PegaBedford2,2,Kilometers,,,8 Commerce Drive,Bedford,NH,03110,USA Review This stage enables the user to review the import process and handle any conflicts. The user is presented with total number of Geofence records, number of Geofences that will be created, number of warnings, and number of errors. 14-7

The Geofences to Import grid lists each entry in the import file along with its pertinent details and its status. The grid is paginated if there are sufficient entries in the import file. There are three possible status values: 1. (Blank) Geofence is valid and has no conflicts. This Geofence can be successfully created. 2. Warning Geofence is valid, but has conflicts with either an existing Geofence rule in the System or another Geofence in the import file. The creation of this Geofence will depend on the conflict management option selected in the Import Options section. The reason for the warning is displayed as a tooltip on the status. 3. Error Geofence is invalid and will not be created. The reason for the error is displayed as a tooltip on the status. If desired, users can return to the import stage via the Back button and reimport the file after addressing any errors. 14-8

Managing Conflicts The System provides the following options for handling conflicts in the import process: Skip conflicts and keep my existing data Select this option to ignore any conflicting Geofence entries and retain the original Geofence rule or the first Geofence import file entry, as appropriate. Overwrite all my existing data with the new import data Select this option to overwrite existing Geofence rules (in the System) and/or earlier import file entries with the latest file entry. Overwrite my existing data as marked above Select this option to pick which import file entries should overwrite existing entries. Select the Overwrite checkbox for each desired entry. Entries where the checkbox is not checked will be ignored. After reviewing the import results and managing the conflicts, users must check the I have reviewed checkbox. Finally, use the Next button to finalize the import of Geofences and initiate the backend creation/updating of Geofence rules. Summary This stage provides the user with a summary of the Geofence import process. After reviewing the results, use the Done button to exit the import process. 14-9

Geofence Services In addition to configuring Geofence rules in the Next-Best-Action Marketing; the app, that wishes to detect when a Geofence is entered (tripped), must make service requests to the System to determine if a Geofence is tripped. If a Geofence is tripped, all Events associated with it will be triggered (assuming they are currently applicable). The System provides multiple services which can be used separately or in tandem to facilitate this functionality. Preferred Geofences Lookup The Preferred Geofences set of services can be used to determine the most relevant set of Geofences for a particular location. For example, when a customer launches the app on their device, the app can invoke the preferred Geofences service to determine the list of nearby Geofences to monitor. The app can then provide this list to the device s OS to monitor, thereby avoiding have to continually poll whether the current location has tripped a Geofence. The following two variants of the service exist: HandleMktPreferredFences HTTP Service http://<host>:<port>/prweb/prhttpservice/pegamktgeolocation/services/ha ndlemktpreferredfences?key=closest&baselatitude=<devicelatitude>&baselo ngitude=<devicelongitude>&closestcount=<numberofgeofences> HandleMktPreferredFences REST Service http://<host>:<port>/prweb/prrestservice/pegamktgeolocation/services/ha ndlemktpreferredfences/closest?baselatitude=<devicelatitude>&baselongitu de=<devicelongitude>&closestcount=<numberofgeofences> Both variants expect the following inputs: BaseLatitude Latitude of the device BaseLongitude Longitude of the device ClosestCount Number of closest Geofences to return for the specified location. If this value is not provided, the System returns up to ten Geofences. The content type for the response differs between the variants: Service Type HTTP REST Response Content Type text/plain (content is still JSON) application/json 14-10

A sample (formatted) response is shown below: { } GeolocationArray : [{ "GeofenceName" : "PegaBedford", "RadiusNormalized" : "1000", "Latitude" : "42.928", "Longitude" : "-71.464" }, { "GeofenceName" : "ManchesterBRAirport", "RadiusNormalized" : "3218.688", "Latitude" : "42.928", "Longitude" : "-71.438" } ] In error scenarios, such as when the location coordinates are not provided, an error response is returned. { ErrorsList : [{ "pymessage" : "Error: One or more input parameters are invalid." } ] } Note: The System provides OOTB support for closest Geofence lookup ( Key request parameter is set to Closest in the example URLs above). Custom implementations may extend this functionality to provide support for other lookup modes. Detect/Trigger Geofences The Detect/Trigger set of services are used to detect whether a customer s device has tripped a Geofence in the System and to trigger Events associated with tripped Geofences. These services support handling requests for multiple customers in a single request. The following two variants of the service exist: 14-11

HandleMktGeolocations HTTP Service http://<host>:<port>/prweb/prhttpservice/pegamktgeolocation/services/ha ndlemktgeolocations?customerid=<customerid1,2,..n>&deviceid=<deviceid 1,2,..n>&DeviceLatitude=<DeviceLatitude1,2,..n>&DeviceLongitude=<DeviceL ongitude1,2,.n> When using this service for multiple customers, ensure that each of the values are comma-separated (e.g. CustomerID=A1,A2,B1) and that the length of each of the request fields (such as CustomerID, DeviceLatitude, etc.) is the same. HandleMktGeolocations SOAP Service The following URL provides the WSDL for your this service: http://<host>:<port>/prweb/prsoapservlet/soap/pegamktgeolocation/servi ces?wsdl The following is an example SOAP request for two customers: <soap:envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:geol="geolocationpayload"> <soap:header/> <soap:body> <geol:geolocationpayload> <Geolocation> <CustomerID>JR</CustomerID> <DeviceID>ANDR1234</DeviceID> <DeviceLatitude>41.34</DeviceLatitude> <DeviceLongitude>-71.79</DeviceLongitude> </Geolocation> <Geolocation> <CustomerID>RA</CustomerID> <DeviceID>IO12</DeviceID> <DeviceLatitude>41.797</DeviceLatitude> <DeviceLongitude>-72.077</DeviceLongitude> </Geolocation> </geol:geolocationpayload> </soap:body> </soap:envelope> Both variants of this service expect the following inputs: CustomerID Customer identifier DeviceID Device identifier DeviceLatitude Latitude of the device DeviceLongitude - Longitude of the device 14-12

For each customer location, the System evaluates whether the location trips any of the defined Geofences. For each Geofence that is tripped, the System triggers all Events associated to that Geofence. 14-13

Chapter 15: Real-Time Events Events provide a mechanism for responding to real-time marketing opportunities. An Event is, essentially, an entry-point into the marketing Application which can be initiated by internal or external systems. Events can be mapped to Programs and can trigger their execution. Real-Time Events are listed under the Events landing page, which is accessible via: -> Real-Time Artifacts -> Events The Events landing page provides a quick overview of the various Events configured in the Application. The landing page denotes Events that are enabled with a check in the Active? column. The Valid From and Valid To values (if configured) are displayed in green if they are currently satisfied. Event Management This section explains the various aspects of managing Events. Creating a new Event To create a new Event, click the New button on the Events landing page. Enter a unique name for the Event in the Short Description field and click Create to launch the Event rule form. 15-1

A new Real-Time Event rule resembles the following: The Event rule has the following tabs: Tab Name Event Details History Purpose Specify the availability details for the Event and associate Geofences with the Event. View Programs associated with this Event. Specify the Description and Usage information for this Event. Specifying Event Details The following configuration options are available: Is this event currently active? Select Yes to enable the Event and have it respond to requests. Select No to prevent the Event from responding to requests. If an inactive Event is triggered, it will simply be ignored. 15-2

Does this event have special validity options? These settings allow for both data and time based validity restrictions to be placed on the Event. If the Event is always valid, leave these settings blank. To specify date restrictions, use the Valid From settings. To specify time restrictions, use the Available Hours settings. If the Event is triggered outside the configured date/time windows, it will simply be ignored. Associating Geofences with the Event Events can be associated with Geofence rules defined in the System. When an associated Geofence is tripped, any Event associated with it will be triggered. Select Yes to associate this event with Geofences. Use the add icon to add Geofences one at a time. Use the Edit multiple button to add multiple Geofences using a list-to-list interaction. 15-3

The left list contains the available Geofences while the right list contains the currently selected Geofences. Use the icons adjacent to the lists to manage Geofences between (and within) the lists. Icon Purpose Move all available Geofences to the associated list. Move the selected Geofence from the available to the associated list. Move the selected Geofence from the associated to the available list. Move all associated Geofences back to the available list. Sort the available or associated list in ascending order. Sort the available or associated list in descending order. Move the selected Geofence up in the associated list. Move the selected Geofence down in the associated list. Viewing Associated Programs Programs that have been associated to this Event are displayed in the Associated Programs grid. Refer to the Programs chapter for details on associating Events with Programs. Triggering an Event In the marketing Application, configured Events can be triggered via a SOAP request. The following URL provides the WSDL for your Application s Event handling SOAP Service: http://<host>:<port>/prweb/prsoapservlet/soap/pegamktdatamktevent/services? WSDL 15-4

The following is an example request triggering the AccountOpened Event, passing in the Customer s id, their location (latitude/longitude), and information about the Event: <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:even="eventpayload" xmlns:urn="urn:pegarules:soap:pegamktdatamktevent:services"> <soapenv:header> <even:eventpayload>?</even:eventpayload> </soapenv:header> <soapenv:body> <urn:eventpayload> <CustomerID>JR</CustomerID> <EventName>AccountOpened</EventName> <EventType>Branch</EventType> <Latitude>42.9613</Latitude> <Longitude>-71.4798</Longitude> </urn:eventpayload> </soapenv:body> </soapenv:envelope> When an Event is triggered, the System determines whether the referenced Event is valid, enabled, and available (date/time valid). If so, any Programs that are associated with the events are initiated. The payload for the Event (including customer id) is propagated to the Program, and from there to the Strategy, and finally to the Offer. Refer to the Enabling Events section in the Programs chapter for more information on associating Programs with Events. 15-5

Chapter 16: Real-Time Containers Real-Time Containers provide a way for marketers to manage content that appears in other non-agent assisted real-time channels, such as web and mobile. As an example, a marketer may define a Container to represent a region of a web page. They can then associate the Container with a Program. In real-time when the Container is loaded (say on a web page), the associated Program is executed and the Container gets populated. NBAM provides a set of APIs, which can be invoked from real-time channels, to facilitate the population of a Container and to capture customer responses. Real-Time Containers are accessible in Next-Best-Action Studio via: -> Real-Time Artifacts -> Containers The Containers landing page provides a quick overview of the Containers configured in the Application. The landing page denotes Containers that are enabled with a check in the Active? column. 16-1

Container Management This section explains the various aspects of managing Real-Time Containers. Creating a new Container To create a new Container, click the New button on the Containers landing page. Enter a unique name for the Container in the Label field and click Create to launch the Container rule form. A new Real-Time Container rule resembles the following: The Container rule form has the following tabs: Tab Name Container Details History Purpose Specify the availability details for the Container and view Programs associated with this Container. Specify the Description and Usage information for this Container. Specifying Container Details The following configuration options are available: Is this Container currently active? Select Yes to enable the Container and have it respond to requests. Select 16-2

No to prevent the Container from responding to requests. If an inactive Container is requested, it will simply be ignored. Impression Capture This setting governs how an impression is captured when the Container is requested. Choose between the following two options: Captured on retrieval Select this option to have the NBAM Container processing API ( ExecuteWebContainer ) automatically capture an impression before rendering the Container. Captured by channel Select this option to not capture the impression while rendering the Container. In this case, the channel will need to separately invoke the NBAM impression capture API ( CaptureWebImpression ). Click through behavior This setting governs what happens when the channel invokes the NBAM clickthrough capture API ( CaptureWebClickThrough ). Choose between the following two options: Capture click through only Select this option to simply record a click in Interaction History (IH). Capture click through and initiate offer flow Select this option to record a click in IH and to initiate the Offer for the customer, if it isn t already in-flight. If the Offer is already in-flight, it will not be progressed. Viewing Associated Programs Programs that have been associated to this Container are displayed in the Associated Programs grid. Refer to the Programs chapter for details on associating Real-Time Containers with Programs. 16-3

Note: A Container can have multiple Programs associated with it, as long as only one Program is active at any given point in time. The following table lists the information that displays for each Program, associated with this Container: Column Associated Program Enabled Start Date End Date Status Description Name of the Program, to which this Container is associated. Click the name to open the Program. Whether the associated Program currently has Container processing enabled on it Date and time when this Container becomes active for this Program. Date and time when this Container stops being active for this Program. Current status of the Program. Real-Time Container APIs NBAM provides the following Real-Time Container APIs: ExecuteWebContainer CaptureWebImpression CaptureWebClickThrough ExecuteWebContainer ExecuteWebContainer is a REST service that supports the GET HTTP method. This service allows callers to trigger/populate a Real-Time Container. The URL pattern for this service is: http://<host>:<port>/prweb/prrestservice/pegamktcontainer/services/executeweb Container?CustomerID=<CustomerID>&ContainerName=<ContainerName>&Channel =<Channel>&CurrentPage=<CurrentPage>&PreviousPage=<PreviousPage> For the request, the service expects the following URL parameters (as listed above): CustomerID Customer identifier ContainerName Name of the Container to trigger Channel Channel where the Container will be rendered (optional) CurrentPage Current page that the end-user is visiting (optional) PreviousPage Previous page visited by the end-user (optional) 16-4

For the response, the service returns a JSON object. A sample response from the invocation of this service is shown below: { "Status": "OK", "CustomerID": "CGS1234", "ContainerName": "LatestOffer", "OffersList": [{ "OfferID": "PremierRewardsCard", "Issue": "DemoIssue", "Group": "DemoGroup", "OfferName": "Premier Rewards Card", "ImageURL": "ad-imgs/premierrewardssmall.jpg", "InteractionID": -5352764169004433549, "ClickThroughURL": "http://yournbamserver.com:8080/prweb/prhttpservice/pegamktcontainer/serv ices/capturewebclickthrough?px=%09%7bpr%7dg3gz5sfwminonbrad%2fgiiiyqe9%2f Yvmcv7iEGC%2F%2BMGvpgLCX5mClNRfm4Gv%2F5Uf%2Bup0u2W3uPZrfL%0ADOIgk3JzIAfWN LdgqXWS3wvGZVHrgko%2BJ%2FMdkOFUQjsTVUruMz91WYoKLew1DbGwncXZB7" }] } In the above response, OffersList is an array containing one or more Offers. Each Offer in this list has the following fields: OfferID Name of the Offer rule Issue Issue to which the Offer belongs Group Group to which the Offer belongs OfferName Label of the Offer ImageURL URL for the Offer image InteractionID Interaction History record identifier for this Offer. This will be same for all the Offers in the list since they are all part of the same strategy execution. ClickThroughURL URL to invoke the CaptureWebClickThrough API. The encrypted parameter in this URL contains the actual click-through URL specified as part of the Offer s details. Typically, this leads to a link or file that provides more details about the Offer. In addition, a successful response also contains the following fields (common to all Offers): Status OK for successful result CustomerID Validated identifier of the customer ContainerName Validated name of the triggered Container Message In case of an error, message explaining the error In case of an error, the response object instead contains the following two fields: Status Set to Error 16-5

Message Description of the error Note: If the Container is configured to capture impressions on retrieval, the ExecuteWebContainer API will automatically capture impressions for all Offers that are returned as part of the Container s response. CaptureWebImpression CaptureWebImpression is a REST service that supports the POST HTTP method. This service allows callers to capture impressions for a list of Offers. This service is typically invoked when the Container s automatic impression capture setting is disabled. The URL for this service is: http://<host>:<port>/prweb/prrestservice/pegamktcontainer/services/captureweb Impression For the request, this service expects a JSON object having the following structure: { } "CustomerID":<CustomerID>, "ContainerName":<ContainerName>, "Channel":<Channel>, "InteractionID":<InteractionID>, "OffersList":[{ "OfferID":<OfferID>, "Issue":<Issue>, "Group":<Group> }] The fields in the request are similar to those that were previously described for the ExecuteWebContainer API. OffersList is still an array and this API can be used to capture impressions for multiple Offers. For the response, this service returns a JSON object containing the Status of the request. In case of an error, a Message field is also present in the object with details on the error. CaptureWebClickThrough CaptureWebClickThrough is an HTTP service that allows callers to request the handling of a click on the Container. This service records a click in IH before redirecting to the requested URL. Based on the Container s configuration, this service may also initiate the specified Offer for the customer, if it s not already in-flight. 16-6

To invoke this service, callers must use the ClickThroughURL that was returned for the Offer by the ExecuteWebContainer API. The invocation URL for this service resembles the following: http://yournbamserver.com:8080/prweb/prhttpservice/pegamktcontainer/servi ces/capturewebclickthrough?px=%09%7bpr%7dg3gz5sfwminonbrad%2fgiiiyqe9%2fy vmcv7iegc%2f%2bmgvpglcx5mclnrfm4gv%2f5uf%2bup0u2w3upzrfl%0adoigk3jziafwnl dgqxws3wvgzvhrgko%2bj%2fmdkofuqjstvurumz91wyoklew1dbgwncxzb7 16-7

Chapter 17: Prospects In marketing terms, a prospect is a potential customer, which the marketing user wants to target. The Application provides support for importing Prospect Lists, creating Prospect Segments, and targeting prospects via Programs. Configuring the Prospect Class Administrators of the Application need to configure the class for storing prospects in the system. Administrators should follow the guidelines below while configuring this class: The OOTB base prospect class is PegaMKT-Data-Prospect. This class has direct inheritance to the base customer class (PegaMKT-Data-Customer). This class ships with a set of defined external mappings associating standard properties with column names. The base prospect class can be used (without customizations) if the prospect lists to be imported will obey the shipped structure. If a different structure is expected for the prospect class, a custom prospect class should be created. This class should have the following inheritance configurations: Pattern inheritances from custom customer class (or base customer class, if customer class hasn't been customized) Directed inheritance from base prospect class (PegaMKT-Data-Prospect) All prospects (upon import) will be stored in one table. The set of columns for this table should be the superset of all properties present in the prospect lists to import. If a custom prospect class is used, the ProspectTemplate xlsx binary file in the System should be overtaken in the Application's customization ruleset. This file should be updated to represent the format of the expected prospect list. Use the shipped version of this file as a template and add/remove columns following the established patterns. Provide this template to marketing users to use as a template for their prospect lists. The placeholder row should be replaced by data rows in an actual prospect list. 17-1

Importing Prospect Lists Prospect lists can be imported into the Application via the Prospect Lists landing page, which is accessible via: -> Segmentation -> Prospect Lists This page lists the prospect lists that have already been imported into the System, along with their tags, row counts, and status. The "Open" action can be used to view the import work object. To import a new prospect list, Use the "New" button on the landing page. Clicking this button will initiate a new Prospect Import work object, as shown below: 17-2

Specify a unique name for the prospect list. Users can also specify a tag to apply to each prospect imported from the list. Tags can be used to group prospects imported from different prospect lists. Select the location of the prospect list xlsx file. Next, select between the following options for determining the unique id of the prospect: No, auto-generate a unique value for each Prospect Select this option to have the System generate the unique id for the prospect. The id will be a concatenation of the list name and a uniquely generated string. Yes, I will select the column Select this option to denote one of the fields in the prospect list spreadsheet as the unique field. Select this unique field from the list of available fields. After configuring the necessary fields, click the "Create" button to proceed to the summary stage. Use the "Refresh" action from the "Other actions" menu to periodically check the status of the prospect import. This information is also available on the Prospect Lists landing page. The number of prospect entries created and errors detected are displayed along with details of the invalid rows. 17-3

Use the "See Prospect Data" link to view a report containing information about the prospect data that was imported. A sample report is shown below: Prospect Segments Upon importing a prospect list, the System automatically creates a top-level Segment rule and its backing infrastructure. Before this Segment can be used, the user needs to execute the Segment. The user can also create new Segments against prospects in the System. To create a prospect-based Segment, select "Prospect" as the segment subject on the Segment new form. To target prospects from a specific prospect list, optionally specify the prospect list name on the Segment new form. Click "Create" to launch the Segment rule form. If a prospect list was specified, the System automatically generates the necessary criteria for this in the first criteria tab. Users can specify desired criteria and interact with the Segment form, as they would with customer-based Segments. There are two exceptions to the criteria options available: Analytical criteria (both modeled and static) are not available for prospectbased Segments. 17-4

The data fields that are available as criteria are those that are defined on the prospect class. Users can also configure prospect Segments in non-visual mode, if desired. Execute the Segment via the "Run" button to populate it. After population, the total prospect count and the count of prospects in the Segment are shown. Use the "Show Prospects" button to view data for the selected prospects. Prospect Segments are flagged as such in the Segment rule form. Additionally, the tooltip on the Segment entry in the Decisions explorer denotes when a Segment is prospect-based. 17-5

Targeting Prospects in Programs Users can target prospects with their marketing Programs. To do so, select "Prospect" as the subject type when creating a new Program. When selecting the Program's starting population, the user must select a prospectbased Segment. For the Program's marketing strategy, the user can select a Strategy rule defined in either the prospect or the customer class. Other setup remains the same when targeting prospects via Programs. If the Offers that are being propagated contain email or SMS delivery, the user must ensure that the appropriate delivery address fields (e.g. pyemail1 for Email, pymobilephone for SMS) are populated on the prospect data in the System. 17-6

Chapter 18: Seed Lists A Seed List is a collection of artificial entities (also called seeds ) that can be used to test, monitor, and validate various aspects of the processing infrastructure. For example, such a list can be used to test the timeliness and reliability of processes being handled by a third party. Each seed represents a make-believe Customer and all applicable Customer attributes can be specified for a seed. Multiple lists, each containing their own seed data, can be created and managed within the Marketing application. These lists can be used to test the following capabilities: Program execution Offer execution Personalized email delivery Personalized SMS delivery Each of these modes of testing is explained in the chapter/section pertaining to the entity being tested (e.g. Programs, Offers, etc.). Seed Lists are listed under the Seed Lists landing page, which is accessible via: -> Segmentation -> Seed Lists The following actions are available from the Seed Lists landing page: New See Creating a new Seed List Update Seed List Columns See Updating Seed List Columns Refresh Used to reload the Seed List grid Help View context-sensitive help Close Close the Seed Lists landing page 18-1

Seed List Management This section explains the various actions that can be performed on a Seed List. Creating a new Seed List To create a new Seed List, click the New button on the landing page. Enter a unique name for the Seed List and a helpful description of its contents. Click OK to create the Seed List. At this point, the backing structure of the Seed List is created. The Seed List grid should refresh and display the newly created Seed List. The row count column for the new Seed List will initially be 0. Modifying Seeds in a Seed List Once a Seed List has been created, new seeds can be added to it and existing seeds can be modified or deleted. To do so, either click on the Seed List row in the grid or select the Edit action from the Actions dropdown for the particular Seed List. This will open the Seed List editor, as show below: This editor displays all entries (seeds) as rows in the Seed List. The columns of the Seed List are made up of the columns from the Customer table. To.. Do Add a new seed Click the add button. Fill in all necessary fields and click the save button. To cancel your changes and 18-2

To.. Modify an existing seed Delete an existing seed Do discard the new record, click the cancel button. For editing the data inline, use the lock button. For editing the data standalone, use the open button. While the record is in read-only mode (non-edit), click the delete button and select OK on the confirmation dialog. Duplicate an existing seed Use the insert a copy button. Make any necessary changes and save or cancel the new record. Note: The Segment Map column is present in all Seed Lists and is used for testing the Segments within Strategies feature during Program execution. Its use is explained in the Testing section of the Programs chapter. Deleting a Seed List Existing Seed Lists can be deleted by selecting the Delete action from the Actions menu for the particular Seed List. Updating Seed List Columns All Seed Lists share a common structure (set of columns) and this structure is derived from the columns present on the current Customer class, which is in use in the application. In time, the structure of the Customer class might deviate from what was initially set up for the Seed Lists. In a situation like this, the Seed List structure can be synchronized to the Customer class structure via the Update Seed List Columns button on the Seed Lists landing page. Upon clicking this button, the backing Seed List structure will be synchronized with the Customer class. Upon completion, a confirmation message will be displayed. 18-3

This task should typically be performed by an administrator and will impact all existing Seed Lists. This task should be performed in the following scenarios: Initially after a new install Until the Seed List columns are updated for the very first time, users will not be able to add seeds to Seed Lists. When the Customer class changes When attributes are added to (or removed from) the Customer class and these changes need to be reflected in the seed data 18-4

Chapter 19: Checklists A Checklist represents a set of actionable steps which must be performed to accomplish a goal. Each actionable step is represented by a Checklist Task (herein referred to as Task). A Task is always created in the context of a parent Checklist. A Checklist can be associated with either an Offer or a Program. Checklists are listed in the Programs & Checklists explorer in Next-Best-Action Studio. Checklists can be stored at the top level or can be categorized into Issues and Groups. A new Checklist starts out with input fields where basic information about the Checklist can be entered, as shown below: Note: The Checklist name must be unique across the system. Unlike some of the other rules (such as Offer), the same Checklist name can t be used at different hierarchical levels (Top/Issue/Group). Note: Checklists associated with an Offer / Program can be seen in the Checklists tab on the Offer rule / Program Display. 19-1

Checklist Display Clicking Create after entering the information above creates the Checklist work object and switches to the Checklist work object display, as shown below: The Checklist Display can be split into the following pieces: Checklist Header Checklist Details Panel Tasks Panel Links Panel Pega Pulse and Attachments panels 19-2

Checklist Header The Checklist header displays the following information about the Checklist: Name Work ID Status Button Strip Contains buttons for the actions that can be performed on the Checklist, including: Save As Create a copy of this Checklist. Other actions - View a list of available actions that can be taken on the Checklist at the current point of time. Close Close the Checklist display. Save Save current changes and continue performing the action. Checklist Details Panel The Checklist Details panel displays the following information about the Checklist: Description Associated with Provides a link to the associated Offer or Program. Owner 19-3

Percent Complete Completion percent of this Checklist which is calculated by averaging the completion percent of the child Tasks. Issue Group Start Date Due Date Tasks Panel The Tasks panel lists the various tasks that have been added to this Checklist. It also provides a mechanism for adding new tasks. Individual tasks can be acted upon directly from the Tasks panel by utilizing the Actions menu on the individual Task. The Tasks panel also supports performing actions on multiple tasks via the Actions for Selected Tasks menu. Links Panel The Links panel contains various useful links, including the following: Help View the help topic for Checklists. History - View a historical record of the various actions that have been performed on this Checklist. Follow (For managers) Mark this Checklist as an item to follow. Followed items are displayed in the Following list in the Case Manager portal. 19-4

Unfollow (For managers) Remove this Program from the list of followed items. Tags Manage the tags associated with this Program. Managers can directly search for work objects by tags in the Case Manager portal by selecting the Matching Tags link in the search results pane. Start Checklist Start working on this Checklist. This item is only shown for new Checklists. Reopen Checklist Reopen a Checklist. This item is only shown for completed or withdrawn Checklists. Pega Pulse and Attachments panels The Checklist display also includes the Pega Pulse panel and the Attachments panel. The behavior of these panels is similar across various Marketing work types and has been outlined in the Programs chapter. Actions Available on a Checklist The following is an overview of the various actions that are applicable on a Checklist, during its lifecycle. While performing any of these actions, it is possible to switch to a different action (if it s currently available) via the Other actions button. Start Checklist This action is available directly in the Links panel for new Checklists. Performing this action marks the Checklist as being In Progress. Add Tasks This action enables the user to add Tasks to the Checklist. Tasks are added by using the add button at the bottom. All pertinent information for the Task (such as name, start date, due date, effort, etc.) can be specified in the Update Task dialog. 19-5

Update Checklist Info This action enables the user to update Checklist information. Complete Checklist This action enables the user to mark a Checklist as being completed. The user can enter a completion note and choose whether this note gets shown in the Pega Pulse panel in the Checklist Display. 19-6

Note: Completing a Checklist doesn t complete the individual Tasks on the Checklist. Typically, this action should be taken when all Tasks in the Checklist have been completed. Withdraw Checklist This action enables the user to mark a Checklist as being withdrawn. The user can enter a note and choose whether this note gets shown in the Pega Pulse panel in the Checklist Display. Withdrawn Checklists are moved to the Withdrawn node (under Checklists) in the Programs & Checklists explorer. Note: Withdrawing a Checklist doesn t withdraw the individual Tasks on the Checklist. Reopen Checklist This action is available directly in the Links panel for Checklists that have either been completed or withdrawn. 19-7

Task Display The Task display can be accessed in the following ways: By clicking the link on the Task name in the Tasks panel on the Checklist display. By opening Tasks that are assigned to you from the My Work List section on your home page. The following shows a typical Task display: The Task display can be split into the following pieces: Task Header Task Details Panel Links Panel Pega Pulse and Attachments panels 19-8

Task Header The Task header displays the following information about the Task: Name Work ID Parent Checklist name and work ID Contains link to parent Checklist Status Button Strip Contains buttons for the actions that can be performed on the Task, including: Other actions - View a list of available actions that can be taken on the Task at the current point of time. Close Close the Task display. Save Save current changes and continue performing the action. Task Details Panel 19-9

The Task Details panel displays the displays the following information about the Task: Description Owner Percent Complete Start Date Due Date Issue Group Estimated Effort Actual Effort Remaining Effort Links Panel The Links panel contains various useful links, including the following: Help View the help topic for Tasks. History - View a historical record of the various actions that have been performed on this Task. Follow (For managers) Mark this Task as an item to follow. Followed items are displayed in the Following list in the Case Manager portal. Unfollow (For managers) Remove this Task from the list of followed items. Tags Manage the tags associated with this Task. Managers can directly search for work objects by tags in the Case Manager portal by selecting the Matching Tags link in the search results pane. Start Task Start working on this Task. This item is only shown for new Tasks. Reopen Task Reopen a Task. This item is only shown for completed or withdrawn Tasks. 19-10

Pega Pulse and Attachments panels The Task Display also includes the Pega Pulse panel and the Attachments panel. The behavior of these panels is similar across various Marketing work types and has been outlined in the Programs chapter. Actions Available on a Task The following is an overview of the user actions that are applicable on a Task, during the course of its lifecycle. These actions can be performed in the following two ways: Directly from the Task display. While performing an action in this mode, it is possible to switch to a different action (if it s currently available) via the Other actions button. From the Actions menu on a particular task in the Tasks panel in the Checklist display. Start Task This action is available directly in the Links panel for new Tasks. Performing this action marks the Task as being In Progress. Update Task This action enables the user to update Task details. 19-11

Complete Task This action enables the user to mark a Task as being completed. The user can enter a completion note and choose whether this note gets shown in the Pega Pulse panel in the Task Display. Performing this action on a Task resets the remaining effort on the Task to zero. Withdraw Task This action enables the user to mark a Task as being withdrawn. The user can enter a note and choose whether this note gets shown in the Pega Pulse panel in the Task Display. Withdrawn Tasks no longer appear in the Tasks Panel of the parent Checklist and also do not factor into the Checklist s completion percentage. Reopen Task This action is available directly in the Links panel for Tasks that have either been completed or withdrawn. 19-12

Chapter 20: Email and SMS Account Configuration This chapter outlines the various configuration options for setting up Email and SMS accounts in the Marketing application. This includes the following: Configuring an Outbound Email Account Configuring an Outbound SMS Account Specifying Delivery Time Frames Configuring an Inbound SMS Account Configuring an Outbound Email Account The Outbound Email landing page lists the various Outbound Email accounts that are configured in the System. This landing page is accessible via: -> Channels -> Email -> Outbound Email The following two accounts should already be present in your application: Default: System-wide default account for sending emails. This account is also the default account for sending Email and Passbook Treatments in Offers. PegaMKT-Work: This account is used to send Program-centric emails (such as Program Approved, Program Suspended, etc.). Administrators should configure both these accounts appropriately to ensure proper delivery of emails to both users and customers. To edit the account details inline, use the Edit button on the account row. To view/update other account details (not shown in the inline edit), use the link in the Account Name column to open the account s data record. A sample Outbound Email account configuration is shown below: 20-1

In addition to these two accounts, other accounts can be created via the Add New Connection button. These accounts can then be referenced as the delivery account in the Send Email and Send Passbook shapes in an Offer. The Account Availability options are explained in the Specifying Delivery Time Frames section. Configuring an Outbound SMS Account The Outbound SMS landing page lists the various Outbound SMS accounts that are configured in the System. This landing page is accessible via: -> Channels -> SMS -> Outbound SMS The following account is shipped with the Marketing application: Default: This is the default account for sending SMS Treatments in Offers. 20-2

Administrators should configure this account appropriately to ensure proper delivery of SMS messages. To edit the account details, use the Edit button on the account row. To test the account, use the Test link in the Connection column. The SMS account configuration is broken into two tabs: Setup and Advanced. The Setup tab is used to configure basic account information (such as name, address, port, etc.). The Advanced tab can be used to configure advanced account settings, as shown below: In addition to the Default account, other accounts can be created via the Add New Connection button. These accounts can then be referenced as the delivery account in the Send SMS shape in an Offer. 20-3

Specifying Delivery Time Frames It is possible to specify delivery time frames for both Outbound Email and SMS accounts. Time frames only apply to the delivery of Email and SMS treatments in Offers. Other email delivery (e.g. Work object related correspondence) is not subject to these restrictions. Delivery time frames are configured in the Account Availability section of the Outbound Email/SMS account details dialog. The two availability options are: Always Available This implies that this account is always available to delivery Email/SMS treatments. Specify Range This implies that this account will only deliver Email/SMS treatments during the specified time range. The following values need to be specified with this option: From Start value for the time range To End value for the time range Time Zone Time zone for the start and end time values. This is defaulted to the current user s default time zone. A sample configuration for the Specify Range availability option is shown below: 20-4

Configuring an Inbound SMS Account The Inbound SMS landing page lists the various Inbound SMS accounts that are configured in the System. This landing page is accessible via: -> Channels -> SMS -> Inbound SMS An Inbound SMS account is used to listen for responses to Offers from customers and to then take the next appropriate action based on the response received. The Marketing application provides a variety of options for handling Inbound SMS responses. For example, users can choose to parse the response text to determine the response and then associate each response with a different offer. Or, in a simpler scenario, users can choose to associate all responses to a particular account (inbox) with a single Offer. A new Inbound SMS account can be created via the Add New Connection button on the landing page. This should open the Add/Edit Inbound SMS Connection dialog. The Inbound SMS account configuration is split into two tabs: Connection Setup and Response Behaviors. Connection Setup This tab is used to specify the settings associated with the account connection, such as the host address, host port, user name, etc. A sample configuration is shown below: Salient connection properties are further described below: Property Account Name Account Type Description Unique name for the Inbound SMS account Can be used to further classify account 20-5

Property Host Address Host Port Inbox Address IP Address User ID/Password Run Status Description Address for the SMSC host Port number for the SMSC host Address of inbox, on which to listen for responses IP address of the SMSC host Authentication credentials to connect with the SMSC Serves as the action to be performed on the account: For a new connection, available actions are Start and Stop For a running connection, the available action is Stop For a stopped connection, the available action is Start Upon clicking the OK button, if the Run Status was selected as Start, the system will attempt to establish a connection with the SMSC and start listening for Inbound SMS messages using the specified configuration. Once the connection has been established, the status of the Inbound SMS account should change to Running. This can be verified by refreshing the landing page to see the latest connection status. Response Behaviors This tab is used to specify how the Application should process Inbound SMS messages that are received by this Inbound SMS account. At the highest level, select between the following two options: Select One Response for All Messages Use Decision Tables to Assign Responses to Messages Select One Response for All Messages Select this option to assign one response for all inbound SMS messages that are received for the inbox specified in the Connection tab. For this option, further specify the single response value and the Offer to associate with the response. 20-6

Use Decision Tables to Assign Responses to Messages Select this option for advanced response handling configuration. This option allows for the configuration of one or more decision tables to associate the inbound message received with a response value. Furthermore, each result from the decision table can be associated with an individual offer (if desired). First, select between the following two Manage Offers options: Select an Offer for All Results Select this option if all messages received on this inbox should be associated to a single Offer. In this case, specify the Offer name. This Offer name will be listed as the Offer for all result entries in the decision table grid. Select an Offer for Individual Results Select this option if this inbox is used for receiving responses to multiple Offers. In this case, specify each Offer name alongside the response value in the decision table grid. Then, add and configure your decision tables in the Manage Decision Tables section. To add a new decision table, enter or select it from the list of available decision tables and click Add Table. The newly added decision table should display in the decision table grid. Expand the decision table node in the grid to see the results returned by the decision table. Associate each result with a response value and, if applicable, an Offer name. Multiple decision tables can be added to the grid in a similar fashion. When an inbound message is received, the decision tables will be evaluated in sequential order until a result value is successfully determined. Note: For a decision table to be visible to the Application, it should be created via the Decision Tables node under Other Decision Types in the Business Decisions explorer in Next-Best-Action Studio. The Applies To class for the decision table should be PegaMKT-Work-Offer. 20-7

Accessing message and customer data in decision tables In order to properly determine the appropriate Offer and response values for an inbound message, both message and customer data are made available for use in the decision tables. Customer data can be accessed directly via the.customer page property under the Offer class. Inbound message data is made available under the.inboundresponsedata.sms page property under the Offer class. This page includes properties for the incoming number (.SourceNumber) and the message content (.MessageBody). Note: If multiple decision tables are to be used, do not specify a return value for the otherwise clause in the decision tables. This will allow for processing to move on to evaluating the next decision table in the list. Handling un-initiated responses to Offers In all scenarios outlined above, you can specify how the system should handle uninitiated responses to Offers. The two options available are: Assume it is an error Select this option to prevent customers from responding to Offers that have not been initiated for them. If this option is selected and a response is received from a customer for an un-initiated Offer, the response is treated as an error and moved to the UnhandledInboundSMS work basket for further processing. This workbasket is accessible to Marketing managers via the Case Manager portal. Start the Offer for the customer Select this option to initiate a new Offer for the customer if they respond to an un-initiated Offer. Handling responses from unknown customers When an inbound SMS message is received, the sender s number is looked up against the customer table to determine the customer that sent the message. If no matching customer is found, the message is treated as an error and it is moved to the UnhandledInboundSMS work basket for further processing. 20-8

Chapter 21: Push Notifications Push Notification is a mechanism by which a server sends (pushes) a message to the client. In terms of mobile apps, the push notification mechanism can be used by an app to send notification messages to its users. Next-Best-Action Marketing currently provides support for sending push notifications to apps running on the following platforms: Android - Using Google Cloud Messaging for Android (GCM) http://developer.android.com/google/gcm/index.html ios - Using Apple Push Notification service (APNs) https://developer.apple.com/library/ios/documentation/networkinginternet/co nceptual/remotenotificationspg/chapters/applepushservice.html Refer to the above links for more details on each of these services. The following table lists the various roles involved in the push notification process along with their responsibilities: Role Responsibility Scope App Developer Marketing Administrator App User Marketing Analyst Marketing Creates mobile app, which: Registers and un-registers app users for receiving push notifications from the marketing application, via the provided REST services. See Push Notification User Registration Services for details. Receives and displays push notification messages to app users Deploys app on app platform (e.g. App Store, Google Play, etc.) Provides marketing administrator with key registration information for app Registers app for receiving push notification messages from Next-Best- Action Marketing. See Registering Apps for Push Notification. Downloads and installs app from app store. (Behind the scenes, app registers the user for receiving push notifications) Creates Offers and utilizes the Push Notification flow shape to send notification messages to registered app users. See Configuring Push Notifications in Offers. Handles registrations of apps Handles registrations/un-registrations of Outside of Next- Best-Action Marketing In Next-Best- Action Marketing Outside of Next- Best-Action Marketing In Next-Best- Action Marketing In Next-Best- 21-1

Role Responsibility Scope System app users Delivers notification messages to registered users for registered apps Action Marketing Registering Apps for Push Notification Marketing administrators can register apps for receiving push notification messages from the marketing Application. This is done from the Push Notifications landing page, which is accessible via: -> Channels -> Push Notification Configuring a New App Use the "New" button to configure a new app for receiving push notifications. Provide the following information for the app: Setting Name Description Platform Unique ID Purpose Name of the app. This is how the app will be referred within the marketing Application (e.g. in Offer flows). Description of the app Platform on which this app is available. Choose between Android and ios. Unique ID identifying this app. This ID is used for validating push notification service requests, such as those for registering/un-registering app users. See Push Notification User Registration Services for details. 21-2

For Android apps, additionally provide the following information: Setting Google Key Purpose Google key for this app. This value should be provided by the app developer and is required for using the GCM service. For ios apps, additionally provide the following information: Setting App Certificate Certificate Name Certificate Password Certificate Type Monitor Apple s notification feedback service? Purpose Apple.p12 certificate for this app. Use the Browse button to locate the certificate. Name to use for storing the certificate in the System Password associated with the certificate. The System will validate this password and will not upload the certificate in case the password is invalid. Type of certificate. Select either Production or Development. Apple provides a feedback service which can be used to detect failed push notification message delivery when the user has uninstalled the app from their ios device. Next-Best-Action Marketing ships with an agent that periodically polls the APNs feedback service to detect these errors. If any delivery errors are reported by the feedback service, the System unregisters the associated user/device registrations (as recommended by Apple), thereby preventing future deliveries. Choose Yes to enable the System to monitor the feedback service for this app. When this option is selected, erroneous devices will automatically be unregistered from the marketing System. Alternately, choose No to monitor the feedback service via an external system/mechanism. In this case, the external mechanism should invoke the unregistration service to unregister push tokens that are no longer valid. Refer to the following link for details on the APNs feedback service: https://developer.apple.com/library/ios/documentatio n/networkinginternet/conceptual/remotenotification spg/chapters/communicatingwithaps.html#//apple_ ref/doc/uid/tp40008194-ch101-sw3 21-3

Click "Submit" to create the new app and the associated platform variant. Adding a Variant to an Existing App Typically, mobile apps are available on multiple platforms. This notion is represented in the System via App Variants. The Application entry in the Push Notifications landing page grid represents the conceptual app. The actual app instance on a particular platform is represented via an App Variant. Upon creating a new app, the associated variant is also created. Other variants can be added via the "Add Variant" action from the "Actions" menu for a particular application. 21-4

The configured variants for an app can be viewed via the expand pane icon, located to the left of the app name. Setting the Default App Administrators can mark one app as the default. This is beneficial in scenarios where there is only app or where a particular app is predominantly used. The default app is the (default) target for push notification messages in Offer flows. Marketing analysts can choose to override this by selecting a specific app. See Configuring Push Notifications in Offers for more details. Use the "Make Default" action from the "Actions" menu to mark an application as the default. Testing an App Variant After configuring an app variant, it is recommended that the user tests the configuration of the variant to ensure that push notification messages can be delivered for the app. Testing the variant validates both the variant's configuration and the mobile app itself. Use the "Test" action from the "Actions" menu for an app variant to launch the test variant dialog. 21-5

Provide a value for "Test Push Token" and click the "Test" button to send the test push notification message. A push token uniquely identifies the installation of an app on a particular device. The app developer should be able to provide you with the push token associated with the test device. The System displays the status of the test message in the "Test Result" field. The test message is delivered (as a push notification) to the app on the test device. The following screenshot shows the test notification, as received for a sample app running on the Android platform: Deleting an App Variant Use the "Remove" action from the "Actions" menu for an app variant to delete the app variant. Note: The "Remove" action is disabled on a variant once app users have been registered to receive notifications for it. 21-6

Using Push Notification with Passbook Push Notification functionality can also be used on conjunction with the Passbook functionality for pushing passbook updates. This feature is automatically enabled once Passbook settings have been configured in the System. Refer to the Passbook chapter for more details. Configuring Push Notifications in Offers The Push Notification shape in the Offer flow canvas enables the user to configure notification messages for delivery. General Configuration The following general configuration options are available in the "General" section of the properties panel for this shape: Name Message Play Sound? Key Code Purpose Notification message to push to the customer s registered device(s). This can be plain text or an expression. Associate sound with the notification message. If this setting is enabled, the message payload references the default sound. When the message is received by the device, the device-specific default sound for notifications (if enabled) is played. Marketing code to identify the shape. This value can be passed to the device along with the notification message (as additional values). A sample configuration for the general settings is shown below. 21-7

Application Configuration The following application configuration options are available in the "General" section of the properties panel for this shape: Name Default Application Other Application Purpose Determines whether the notification message should be pushed for the default app. Determines whether the notification message should be pushed for the specified app. Select the app to notify from the dropdown of configured apps. A sample configuration for the applications settings is shown below. Wait After Sending Users can determine whether they would like to wait after the notification message is pushed. The following Wait Configuration options are available for this shape: Name Wait Days Business Days? Hours Minutes Seconds Purpose Determines whether Offer Flow execution should wait after pushing the notification message. When this is enabled, the user can specify the duration for the wait by setting the properties below appropriately. Number of days to wait Determines whether the wait duration should be in terms of business days or regular week days. Number of hours to wait Number of minutes to wait Number of seconds to wait 21-8

Send Additional Values Users can choose to include other information as part of the notification message payload. This data can be used by the app developer. Different platforms place different restrictions on the size of the overall message payload. Users should be aware of this limitation when specifying additional values. A notification message that ends up being larger than the allowed payload size can/will not be delivered. Enable the "Send Additional Values?" checkbox (in the Advanced section of the properties panel) to pass additional values. Use the grid controls to add fields. For each field, specify a name and value. The name must be plain text, but the value can be an expression. The key code specified on the "General" tab can also be passed as an additional field (as shown in the example below). Set Badge The "Set Badge?" option (in the "Advanced" section) allows users to set a numeric badge value along with the notification message. This value only has an impact if it's supported by the app platform. For example, in ios, the badge value is shown as a number on the app's icon. The "Badge Value" field can either be a static number or a numeric expression. 21-9

Push Notification User Registration Services Next-Best-Action Marketing provides two services for registering app users with the System. Push notifications (from Offers) are only sent to registered customers. It is the responsibility of the app developer to code the app to invoke these services, at appropriate points in time. For example, when a customer installs the app, the app must register with the platform push notification service (e.g. APNs, GCM) and should then invoke the marketing registration service. The services provided are: Registration Service Un-registration Service Registration Service The registration service is a REST service that supports the POST HTTP method. The URL for this service is: http://<host>:<port>/prweb/prrestservice/pushnotification/registration/register For the request, this service expects a JSON object having the following structure: { } "AppVariantID":"<AppVariantID>", "PushToken":"<PushToken>", "UserID":"<UserID>" The tokens included in the above request are: AppVariantID - Unique ID for the app variant configured in the System. This is specified when the app variant is created in the System and is used as a means for validating genuine requests. PushToken - Token assigned by the platform messaging service that is used for pushing notification messages for the selected app on the selected device. UserID - ID associating the app user with a customer in the System. In an OOTB implementation, the expected value for this field is the CustomerID. Custom implementations can override the mechanism by which this field is associated to a CustomerID. For the response, this service sets the appropriate HTTP status code. In case of errors, an appropriate message is also returned as part of the error stream. 21-10

Un-registration Service The un-registration service is a REST service that supports the POST HTTP method. The URL for this service is: http://<host>:<port>/prweb/prrestservice/pushnotification/registration/unregister For the request, this service expects a JSON object having the following structure: { } "AppVariantID":"<AppVariantID>", "PushToken":"<PushToken>" The tokens included in the above request are: AppVariantID - Unique ID for the app variant configured in the System. This is specified when the app variant is created in the System and is used as a means for validating genuine requests. PushToken - Token assigned by the platform messaging service that is used for pushing notification messages for the selected app on the selected device. For the response, this service sets the appropriate HTTP status code. In case of errors, an appropriate message is also returned as part of the error stream. Note: Un-registering a push token removes the push token registration from the System. The Data-PushNotification-Delivery- Registration.PreRegistrationDelete activity is provided as an extension point for custom implementations. This activity can be used to insert desired behavior before the registration entry is deleted. This activity can also be used to bypass the deletion process. For more details, refer to the usage guidelines specified in this activity. 21-11

Chapter 22: Marketing Profile Marketing Profile is a way of describing a customer categorically so that they can be grouped for Marketing purposes. This includes a set of characteristics that identifies the customer and their value to the organization. This profile also includes a quick glance of the interaction between the customer and the organization. Marketing Profile is accessible in Next-Best-Action Studio via: -> Segmentation -> Marketing Profile When initially launched, the Marketing Profile simply contains a search box. Users can use this box to search for the desired customer either by the customer s name or ID. Upon searching, the system presents a list of matching customers. Users can select the desired customer from this list to view that customer s profile. 22-1

Profile Elements This section outlines the various elements of a customer s Marketing Profile. This includes the following: Customer Details Customer Dimensions Customer Demographics Propensity Scores Engagement History Customer Details This section provides basic information about the customer such as their name, image, gender, address, and email. In addition to basic information, this section also presents a view of the customer s segmentation, i.e. the Segments to which this customer belongs. In our example, the customer is a member of five different Segments. The customer segmentation view provides the user with a quick insight into the customer s categorization. This information can be useful when determining how to appeal to a particular customer. 22-2

Customer Dimensions This section provides the user with a visual overview of the customer s performance across various dimensions including Lifetime Value, Churn Risk and Credit Risk. The scores on each of these dimensions are visually indicated and are also classified into high (H), medium (M), and low (L). In addition, the recommended next best action for this customer is also displayed. Customer Demographics This section displays basic information about the customer. This information is further categorized into: Communication Customer s email address and mobile phone number Demographics Customer s age, gender, and income Social Handles Customer s handle on various social media outlets 22-3

Propensity Scores This section displays the customer s propensity scores for the top three Offers for the customer. Propensity is the likelihood that the customer will accept the Offer. Engagement History This section presents an overview of the customer s engagement with the organization. The top of this section contains a visual breakdown of this engagement, in terms of customer interactions, impressions, and the Offers taken by the customer. In addition, the interactions count is further broken down into the various communication channels (such as Email, Web, etc.), as shown below: 22-4

Finally, this section also presents a summary of the customer s engagement. This information is displayed in a chronological order, with the most recent engagement at the top. For each engagement, the icon on the timeline indicates the channel of communication. Additionally, if the engagement resulted in an impression or the Offer being taken, this is indicated via the appropriate colored dot next to the interaction date. Users can utilize the calendar icon to specify a different time period for the timeline. Furthermore, users can click the engagement circles to filter the timeline to the specific engagement type (e.g. Impression or Offer Taken). 22-5

Marketing Profile Customization Guidelines This section provides guidelines for customizing the Marketing Profile to work with your application. This includes the following topics: Displaying Next Best Action Displaying Top Offers Displaying Segments Displaying Customer Dimensions Displaying Next Best Action The Marketing Profile displays the Next Best Action to take for the selected customer. This section list the steps involved for displaying the Next Best Action information in the Marketing Profile in your application. Perform the following steps if you already have a Next-Best-Action type strategy: 1. Open the MKTProfileMainStrategy in PegaMKT-Data-Customer 2. Save As this strategy into your implementation ruleset 3. Re-map the NextBestAction component to point to your existing Next-Best- Action strategy Otherwise if you don t have a Next-Best-Action type strategy, perform the following: 1. Open the empty NextBestAction strategy located in PegaMKT-Data-Customer 2. Save As this strategy into your implementation ruleset 3. Implement your Next-Best-Action logic, arbitrating across the business issues you plan to implement (i.e. Sales, Retention, Servicing, etc.) Displaying Top Offers The Marketing Profile also displays the Top Offers (or Offer Categories) for a customer. This section list the steps involved for displaying the Top Offers information in the Marketing Profile in your application. Perform the following steps if you already have a Next-Best-Offer type strategy: 1. Open the MKTProfileMainStrategy in PegaMKT-Data-Customer 2. Save As this strategy into your implementation ruleset 3. Re-map the NextBestOffer component to point to your existing Next-Best- Offer strategy 4. Select the Public Component to output if there is more than one Otherwise if you don t have a Next-Best-Offer type strategy, perform the following: 1. Open the empty NextBestOffer strategy located in PegaMKT-Data-Customer 2. Save As this strategy into your implementation ruleset 22-6

3. Implement your Next-Best-Offer logic, arbitrating across the various types of Offers you plan to make Displaying Segments The Marketing Profile also displays the Segments in which a customer belongs. Only Segments known to the MKTProfileSegment strategy are displayed in the Marketing Profile. Perform the following steps to add your Segments to this display: 1. Open the MKTProfileSegment strategy located in PegaMKT-Data-Customer 2. Save As this strategy into your implementation ruleset 3. Add each of the desired Segments to the strategy canvas using the Segment Filter shape Displaying Customer Dimensions The Marketing Profile also calculates and displays several values that are part of the customer dimension, such as CLV_VALUE, Credit Risk, and ChurnScore. If these properties are already part of your customer data, then you can simply map them in the customer class. On the other hand, to calculate the values of these properties in an NBAM strategy, perform one of the following series of steps. If you already have a CLV/Risk type strategy: 1. Open the MKTProfileMainStrategy in PegaMKT-Data-Customer 2. Save As this strategy into your implementation ruleset 3. Re-map the MKTProfileDecisionResults component to point to your existing CLV and Risk strategy 4. Select the Public Component to output if there is more than one If you don t have a CLV/Risk type strategy: 1. Open the MKTProfileDecisionResults strategy located in PegaMKT-Data- Customer 2. Save As this strategy into your implementation ruleset 3. Implement your CLV/Risk logic as per your requirements 22-7

Appendix A: User Preferences User preferences are accessed via the Preferences item in the operator s drop-down menu. Marketing-specific user preferences are listed in the Next-Best-Action Studio Preferences section of the Preferences dialog and include the following: Preference Name Purpose Default Show Beginner Shortcuts Determines whether beginner shortcuts should be displayed on the user s home page. Value Enabled Validate Key Codes Sets a user preference to require key code entry in Marketing artifacts (such as Offers and Treatments). If this requirement is enabled at the system level by the administrator, this user preference is ignored. Disabled (Number of items in My Work List) Determines the number of items to display in the user s work list on the home page. 10 A-1

Appendix B: Administrative Settings This appendix outlines the various application configuration options that are available for the administrator to configure the Marketing application. These settings should be configured as part of setting up the Marketing application and can be adjusted later, as the need arises. These configuration options are only available to the Marketing administrator and are listed under the Application Settings landing pages, which are accessible via: -> Application -> Settings To change any of these settings, click the Edit button on the particular setting s landing page. In edit mode, click Save to save and apply your changes to the settings; or click Cancel to discard your changes. Note: These settings are stored in a node-level data page. Any changes made to these settings on a particular node should be immediately visible to all processes running on that node. In a multi-node environment, changes may take up to an hour to reflect across other nodes. In such situations, it is advisable to manually flush the data page on each of the nodes after changing these settings. To do so, open up the Declare_MKTSystemSetting data page (under PegaMKT-System- Setting) and click the Clear Data Page button on the Load Management tab. Configuration Settings This landing page includes settings pertaining to the overall execution infrastructure. It is accessible via: -> Application -> Settings -> Configuration Setting Name Outbound Default Data Source Outbound DB Preview File Size Batch Size Setting Purpose Specifies the database instance where the Customer table resides and where the application will store execution data (such as data pertaining to Segments, Program Runs, etc.) Specifies the number of records displayed in the Preview file when previewing the contents of the data written for a Database Template. Specifies the size (number of records) into which back-end processing is chunked, in order to leverage performance improvements from vertical and horizontal scalability. B-1

Setting Name Delete Program Run data older than X days Output File Date Format Enable Database Table Partitioning Setting Purpose Specifies the threshold (in number of days) for purging Program Run data. This only applies to data for Program Runs where all Offers are in a Completed state. Specifies the default format to be applied to date fields in a File Template. Specifies whether database partitioning should be enabled in order to increase performance. Enabling partitioning requires that the Customer table be partitioned on the PartitionKey column. When this setting is enabled, the ProcessBatchJob agent for the Application s artifacts ruleset must also be enabled to support the batch mode of strategy execution. When this setting is enabled, specify the range partition values for the PartitionKey column in the Define Partitions grid, as shown below: Note: Exercise extreme caution in toggling the partitioning setting on a live system. This setting is propagated to the creation of Segment data and Program Run execution data. Toggling this setting after creation of Segments and/or execution of Programs might necessitate the re-creation of these artifacts. B-2

Artifact Settings This landing page includes settings pertaining to the behavior and display of artifacts. It is accessible via: -> Application -> Settings -> Artifact Settings Setting Name Category Setting Purpose Artifact Key Codes Required Default Response Page Default Offer Expired Page Default Offer Not Available Page Mapping License Key Default Customer Location Properties Number of scheduled Program Runs Key Codes Email Responses Email Responses Email Responses Geofences Geofences Upcoming Program Runs Specifies whether key code entry is required for artifacts (such as Programs, Offers, and Treatments). If this setting is enabled, it will over-ride the user preference for specifying key codes. Specifies the Section rule that will be used as the default response page for Email responses. Specifies the Section rule that will be used as the default page for Email responses to expired Offers. Specifies the Section rule that will be used as the default page for Email responses to Offers that are no longer available. Specifies the license key to use for the Google Maps mapping service. Specify the properties on the Customer class to be used as the defaults for the customer s location (latitude and longitude) when filtering on Geofences in Strategies. Specifies the number of Program Runs that the System will schedule at a time for openended Programs (where End Date is not set). Inbound SMS Settings This landing page is accessible via: -> Application -> Settings -> Inbound SMS Settings This landing page is used to specify the list of properties on the Customer class that relate to a phone number. When an inbound SMS is received, the System looks at this list of properties to determine the Customer columns in which it should look for the sender s phone number. Any property specified here must be a property on the Customer class and must be mapped (via the external mappings) to a column in the Customer table. B-3

Manage Data Relationships This landing page is used to configure the Customer and Prospect classes for the application and the associations between various data mart entries. It is accessible via: Relationships -> Application -> Settings -> Manage Data Setting Name Customer Class Name Prospect Class Name Setting Purpose Specifies the name of the Customer class for the Application. This is the class that is mapped to the Customer table. This class must either directly be PegaMKT-Data-Customer or be a class that extends the PegaMKT-Data-Customer class. Specifies the name of the Prospect class for the Application. This class must either directly be PegaMKT-Data-Prospect or be a class that has: Pattern inheritance from the customer class Directed inheritance from PegaMKT-Data- Prospect Associating Entities with the Customer class This landing page enables management and configuration of associations between the Customer class and other external entities that are related to it (e.g. Purchase Data, History, etc.). To add a new relationship for an entity (say PurchaseData) to the Customer class, perform the following steps: 1. Create a page property for the entity directly under the Customer class. The mode of the property must be Page, Page List, or Page Group. The page class for the property should be the class of the entity. B-4

2. Create an Association rule for the entity under the Customer class. The class name should be the class of the entity. Add an entry in the Class Join list to specify the join between the entity and the Customer class. The Type value is ignored (leave it as Include all rows ). Use the Edit Conditions button to specify the join criteria. 3. Click Edit on the Manage Data Relationships landing page. 4. Ensure that the class displayed in the Customer Class Name field is your Customer class. If not, enter your Customer class in this field. Changing the Customer class will clear any currently displayed relationships. To preserve the old relationships, click Cancel to discard your current changes. 5. To add a relationship, select the New action from the Action menu on the Customer entity. 6. In the Add or Edit Customer Data Source dialog, select your newly created property as the Entity Name and the newly created association as the Association Rule. Both these values should be listed in the smart prompt if they were stored under the correct Customer class. Click OK to add the relationship. B-5

The new entity relationship should be listed under the Customer entity in the relationships grid. 7. Repeat Steps 1-6 to add other entity relationships. The same procedure can be used to associate an entity (e.g. Branch) under another entity (e.g. PurchaseData). 8. Finally, click Save to save the data relationships. Note: The steps above use the default Customer class as an example. They should be applied in the context of your Customer class. Note: The History association rule and property is provided under the OOTB Customer class (PegaMKT-Data-Customer). These should be copied and saved under your Customer class. An example configuration with relationships involving multiple external entities is shown below: B-6

Building an Application on Pega Next-Best-Action Marketing Next-Best-Action Marketing ships with a default application (PegaNBAM) which is built on top of the marketing framework application (PegaNBAM_FW). Custom applications can be built on top of the framework application following standard PRPC practices. In such cases, the following access group needs to be updated to point to the new custom application: PRPC:Agents Using a custom Artifacts ruleset The Next-Best-Action Marketing application (PegaNBAM) ships with a ruleset for storing artifacts (PegaNBAM-Artifacts). This ruleset also contains the Agent rule for batch strategy execution. If a different ruleset needs to be used to store artifacts, perform the following steps: 1. Stop the PegaNBAM-Artifacts agent via System Management Application (SMA). 2. In the Records Explorer, navigate to SysAdmin -> Agents 3. From the Instances list, open the PegaNBAM-Artifacts agent entry 4. Do a Save As on the Agent rule into the custom artifacts ruleset 5. If partitioning is enabled in your Application, enable the ProcessBatchJob agent for the newly created Agent rule for the custom artifacts ruleset. This can be done by either updating the Agent rule directly or updating the generated Agent Schedule instance(s) for your node(s). B-7

Appendix C: Passbook Settings In order to use the Passbook functionality and send passes to customers, users must upload valid certificates into the system. This is done via the Passbook Settings landing page, which is accessible via: -> Channels -> Passbook Settings Users/administrators must upload the following the two certificates: Apple Certificate Organization Certificate Uploading the Apple Certificate Users must upload the Apple Worldwide Developer Relations Certification Authority (WWDRCA) certificate. This can be downloaded from: http://www.apple.com/certificateauthority Only one instance of this certificate type can be uploaded into the System. Use the Upload Apple Certificate button to launch the upload certificate dialog. Use the Choose File button to locate the certificate and upload it. No other information is required while uploading this certificate. Uploading the Organizational Certificate Users must also upload the Apple.p12 certificate for their Organization or group. This certificate is associated with a pass type id and can be generated from the ios Provisioning Portal, which is accessed via the ios Dev Center (http://developer.apple.com/devcenter/ios). C-1

Currently, only one instance of this certificate type can be uploaded into the System. Use the Upload Organization Certificate button to launch the upload certificate dialog. Use the Choose File button to locate the certificate. In addition, provide the following information: Setting Certificate Password Organization Name Description Password associated with the certificate. The System will validate this password and will not upload the certificate in case the password is invalid. (Optional) Organization name to display on delivered passes. If this is not provided, the organization name associated with the certificate will be used. To review an existing certificate or to delete a certificate, use the Open action from the Actions menu to launch the certificate rule form. C-2

Appendix D: System Health NBAM 7.12 introduces a new diagnostic tool (for your Marketing application) called System Health. System Health allows marketing administrators to quickly review errors and warnings associated with their Marketing application. The System Health landing page is visible only to administrators and is accessible in Next-Best-Action Studio via: -> Application -> System Health Each time the System Health landing page is launched (or refreshed), the health check is initiated. Once the check is complete, the results of the check are displayed and resemble the following: Note: Due to the nature of some of the checks performed (e.g. validating Email and SMS account connectivity), the System Health check may take some time to complete. During this duration, a loading screen is D-1

displayed. To reduce this load time, administrators should ensure all connection-related errors and warnings are resolved. The System Health page displays the following information: Last updated date and time Errors and Warnings cards Errors and Warnings grids Errors and Warnings Cards These cards are displayed at the top of the System Health landing page and provide the administrator with a quick overview of the status of their application. Each card displays the total number and a breakdown of this total into the following categories: Agent Channel Configuration Runtime Clicking anywhere on a card ensures that the corresponding (Errors/Warnings) grid below is visible. This may result in the other grid being collapsed. D-2

Errors and Warnings Grids These grids provide detailed information on the health check failure (i.e. error/warning). The following columns are available in both grids: Column Name Category Source Message Description Category of the error/warning (Agent, Channel, Configuration, or Runtime) Actionable area of the system associated with this error/warning. This could be a landing page, a data instance, a rule form, or a work object. Clicking this field will open the referenced object/page. In most cases, the administrator should be able to rectify the failure by making appropriate changes in the opened object/page. Descriptive text that explains the error/warning. For longer messages, use the More link to view the complete message and the Less link to revert to the abridged view. The header of each grid displays the total number of items in the grid. Users can also click the header to toggle the grid view between expanded and collapsed. Additionally, each column in the two grids supports sorting and filtering. Agent Errors/Warnings The following table explains the scenarios that contribute to the Agent Errors and Agent Warnings lists. Failure Scenario Type Use Source link to NBAM agent has failed and stopped Error Launch the Agent Detail page for this agent. Administrators can manage (stop/start) the agent from this page. D-3

Failure Scenario Type Use Source link to Basic NBAM agent is stopped on all system nodes Optional NBAM agent is stopped on all system nodes Basic NBAM agent has broken process queue items Optional NBAM agent has broken process queue items Error Warning Error Warning Launch the Agent Detail page for this agent. Administrators can start the agent on one or more nodes from this page. Launch the Agent Detail page for this agent. Administrators can start the agent on one or more nodes from this page. Launch the Broken Process Management landing page for the agent. Administrators can review failures and delete broken queue items from this page. Launch the Broken Process Management landing page for the agent. Administrators can review failures and delete broken queue items from this page. For each entry in the Agent category, if the failure is node-specific, the Message column contains messages for each failing node, prefixed by the node id. Optional NBAM agents are those that are not tied to core functionality and may not be utilized in some installations. Typically, these agents perform channel-specific functionality such as Email, SMS, and Push Notification. Administrators should be aware of the functionalities being used by their Marketing application, so they can better assess the true impact of failures in these agents. Channel Errors/Warnings The following table explains the scenarios that contribute to the Channel Errors and Channel Warnings lists. Failure Scenario Type Use Source link to Default or PegaMKT-Work Outbound Email Account doesn t exist Default or PegaMKT-Work Outbound Email Account fails to connect Other Outbound Email Account fails to connect Error Error Warning Open the Outbound Email landing page. Administrators should create the missing account(s) from this page. Open the Email Account s rule form. Administrators should correct any configuration issues in the account s settings. Open the Email Account s rule form. Administrators should correct any configuration issues in the account s settings. D-4

Failure Scenario Type Use Source link to Default Outbound SMS Account doesn t exist Outbound SMS Account fails to connect Inbound SMS Account connection has failed There are recent Offer Email delivery errors Error occurred while writing to Outbound File/Table Apple or organizational Passbook certificate is missing or expired No default Push Notification app exists or default app has no defined variants Push Notification ios app certificate is missing or expired Warning Warning Warning Warning Error Warning Warning Warning Open the Outbound SMS landing page. Administrators should create the Default account from this page. Open the Outbound SMS landing page. Administrators should correct any configuration issues in the account s settings. Open the Inbound SMS landing page. Administrators should correct any configuration issues in the account s settings. Open the Error Tracking landing page. Administrators can review and mange errors from this page. Open the Outbound File/Table landing page. Administrators can review the error and retry from this page. Open the Passbook Settings landing page. Administrators can manage the certificates from this page. Open the Push Notifications landing page. Administrators can configure apps and app variants from this page. Open the Push Notifications landing page. Administrators can configure apps and app variants from this page. Configuration Errors/Warnings The following table explains the scenarios that contribute to the Configuration Errors and Configuration Warnings lists. Failure Scenario Type Use Source link to Outbound Default Data Source is not configured or doesn t exist in PRPC Outbound Default Data Source fails to connect Customer/Prospect Class doesn t exist Error Error Error Open the Configuration Settings landing page tab. Administrators should update the settings to point to a valid data source. Open the rule form for the data source. Administrators should correct the configuration settings and re-test the connection. Open the Data Relationships landing page tab. Administrators should update the settings to point to the right classes. D-5

Failure Scenario Type Use Source link to A required NBAM property (such as CustomerID ) is not mapped on the Customer/Prospect Class. An optional NBAM property (such as pyemail1 ) is not mapped on the Customer/Prospect Class. Column referenced in External Mappings of Customer/Prospect Class does not exist in the database. NBAM Access Group doesn t have Default Destination Ruleset configured Default Destination Ruleset configured on NBAM Access Group doesn t exist Default Destination Ruleset configured on NBAM Access Group is locked, but an open Ruleset Version exists for the same Ruleset Default Destination Ruleset configured on NBAM Access Group is locked and no open versions exist for the Ruleset Batch decisioning agent is not running on any nodes Batch decisioning agent doesn t have number of threads configured Error Warning Error Error Error Error Error Error Error Open the class rule. Administrators should add a mapping for the missing property. Open the class rule. Administrators should add a mapping for the missing property. Open the class rule. Administrators should review all mappings and make any necessary corrections. Open the Access Group. Administrators should set the Default Destination Ruleset to their Marketing application s artifacts Ruleset. Open the Access Group. Administrators should validate that the correct Ruleset Version is being used. Open the Access Group. Administrators should update instance to reference an unlocked Ruleset Version. Open the Ruleset. Administrators should add a new unlocked version and update the Access Group to reference this new version. Open the Decisioning Topology landing page. Administrators should enable the ProcessBatchJob agent on at least one of the system nodes. Open the Decisioning Topology landing page. Administrators should set the number of threads to a positive number for each enabled node. Public Link URL is not specified Warning Open the Resource URLs landing page. Administrators should set this URL if their Marketing application utilizes the Email delivery channel. D-6

Failure Scenario Type Use Source link to Mapping License Key for Google Maps is not specified Warning Open the Artifact Settings landing page. Administrators should set a value for this key if their application utilizes the Import Geofences wizard. Runtime Errors/Warnings The following table explains the scenarios that contribute to the Runtime Errors and Runtime Warnings lists. Failure Scenario Type Use Source link to Marketing Program or Campaign has failed recently Marketing Program has one or more recent failed Program Runs Error Error Open the failed work object. Open the Program work object with the failed run(s). Note: In most cases when the System Health references recent failures, the time duration is configured as one of the criteria in the backing Report Definition (which is marked as extensible). The shipped implementations usually use a time duration of Greater than or equal to Yesterday for determining whether a failure is recent. D-7