Pega Marketing 731 User Guide - 7 PDF

P E G A M A RK E TI NG
Pega Marketing
USER GUIDE
7.31
© 2017
Pegasystems Inc., Cambridge, MA
All rights reserved.
Trademarks
For Pegasystems Inc. trademarks and registered trademarks, all rights reserved. All other trademarks or service marks are property of
their respective holders.
For information about the third-party software that is delivered with the product, refer to the third-party license file on your
installation media that is specific to your release.
Notices
This publication describes and/or represents products and services of Pegasystems Inc. It may contain trade secrets and proprietary
information that are protected by various federal, state, and international laws, and distributed under licenses restricting their use,
copying, modification, distribution, or transmittal in any form without prior written authorization of Pegasystems Inc.
This publication is current as of the date of publication only. Changes to the publication may be made from time to time at the
discretion of Pegasystems Inc. This publication remains the property of Pegasystems Inc. and must be returned to it upon request. This
publication does not imply any commitment to offer or deliver the products or services described herein.
This publication may include references to Pegasystems Inc. product features that have not been licensed by you or your company. If
you have questions about whether a particular capability is included in your installation, please consult your Pegasystems Inc. services
consultant.
Although Pegasystems Inc. strives for accuracy in its publications, any publication may contain inaccuracies or typographical errors, as
well as technical inaccuracies. Pegasystems Inc. shall not be liable for technical or editorial errors or omissions contained herein.
Pegasystems Inc. may make improvements and/or changes to the publication at any time without notice.
Any references in this publication to non-Pegasystems websites are provided for convenience only and do not serve as an
endorsement of these websites. The materials at these websites are not part of the material for Pegasystems products, and use of
those websites is at your own risk.
Information concerning non-Pegasystems products was obtained from the suppliers of those products, their publications, or other
publicly available sources. Address questions about non-Pegasystems products to the suppliers of those products.
This publication may contain examples used in daily business operations that include the names of people, companies, products, and
other third-party publications. Such examples are fictitious and any similarity to the names or other data used by an actual business
enterprise or individual is coincidental.
This document is the property of:
Pegasystems Inc.
One Rogers Street
Cambridge, MA 02142-1209
USA
Phone: 617-374-9600
Fax: (617) 374-9620
www.pega.com
DOCUMENT: Pega Marketing User Guide

SOFTWARE VERSION: 7.31
PUBLISHED: Tuesday, January 16, 2018
Feedback
If you have suggestions or comments for how we can improve our materials, send an email to AppDocBug@pega.com.
CONTENTS
Preface xvii
Intended Audience xviii
Guide Organization xviii
Chapter 1: Pega Marketing Overview 1
Features 2
Logging In 2
Pega Marketing Portal 3
Header 4
Reports Menu 4
Configuration Menu 5
Navigation Panel 6
RECENT pane 7
Home Page 8
Customizing the Home page 8
Transitioning from Next-Best-Action Studio 9
Chapter 2: Marketing Dashboard 11
Using the Dashboard 11
Understanding the Widget Display 12
Insight & Action 12
Display Types 12
Applying Filters 20
Customizing the Dashboard 21
Managing Widgets 21
Adding a New Widget 21
Removing a Widget 22
Re-organizing widgets 23
Configuring Widget Options 23
Customizing Insight & Action 25
Customizing the Default Dashboard 26
Chapter 3: Next-Best-Action 27
Pega Marketing User Guide i

Configuring the NBA Hierarchy 28
Configuring NBA Definitions 30
Configuring the Next-Best-Action Node 30
Configure Actions 31
Prioritize Actions 32
Configuring a Business Issue Node 33
Configure Relevance 33
Select and Prioritize Results 34
Configuring a Business Group Node 35
Configuring Outcomes 36
Configuring Usage 36
Associating NBA with Real-Time Containers 36
Saving Configuration Changes 37
Deleting an NBA Configuration 37
Scheduled NBA Execution 38
Configuring the Outbound Schedule 38
Launching the Outbound Schedule 39
Other Schedule Actions 40
Monitoring Outcomes 41
Supporting Decisions 42
Creating and Configuring a Supporting Decision 43
Chapter 4: Multi-Channel Campaigns 45
Campaign Management 45
Campaign Creation 47
Campaign Configuration 48
Specifying Details 49
Campaign details 49
Financials 50
Specifying Goals 50
Selecting a Strategy 50
Selecting an Audience 52
Configuring Campaign Engagement 54
Pega Marketing User Guide ii

Campaign schedule 54
Real-time events 57
Real-time containers 59
Configuring a Fallback Strategy 61
Selecting a Constraint 61
Campaign Approval 62
Submitting a Campaign for Approval 63
Recalling a Submitted Campaign 63
Approving and Rejecting Campaigns 64
Campaign Validation 64
Campaign Testing 64
Distribution Test 65
Seed Test 66
Campaign Execution 68
Running a Campaign 68
Rescheduling a Campaign 69
Suspending a Campaign 70
Resuming a Campaign 70
Stopping All Runs 71
Stopping a Run 71
Restarting a Run 72
Skipping a Run 73
Campaign Execution Cycle 73
Scheduled execution 74
Event-enabled execution 74
Container-enabled execution 74
Campaign Monitoring 74
Monitoring Campaign Performance 74
Campaign overview 75
Performance 76
Run schedule 76
Goals 77
Viewing Run Details 78
Pega Marketing User Guide iii

Campaign Completion 80
Wrapping up a Campaign 81
Archiving a Campaign 81
Restoring a Campaign 82
Reopening a Campaign 82
Chapter 5: Outbound Campaigns 83
Outbound Campaign Lifecycle 83
Creating an Outbound Campaign 85
Configuring an Outbound Campaign 86
Specifying Details 86
Selecting the Audience 87
Selecting the Offer 90
Selecting the Flow 92
Specifying Goals 95
Validating an Outbound Campaign 95
Running an Outbound Campaign 96
Monitoring Outbound Campaign Goals 97
Wrapping up an Outbound Campaign 98
Other Outbound Campaign Actions 99
Rescheduling an Outbound Campaign 99
Suspending an Outbound Campaign 100
Withdrawing an Outbound Campaign 100
Archiving an Outbound Campaign 101
Restoring an Outbound Campaign 101
Reopening an Outbound Campaign 101
Chapter 6: Segments 102
Creating a Criteria Segment 102
Designing Criteria Segments 103
Criteria Types 106
Designing Criteria Segments by Using a Rule Form 114
Optional: Configuring Criteria Segment Runs 115
Intelligent Segmentation 116
Pega Marketing User Guide iv

Configuring a Sample 116
Configuring Analysis Projects 118
Creating List Segments 122
Importing Customers 122
Manually Adding Customers to a List Segment 124
Managing Segments 124
Exporting Customers in a Segment 125
Removing Customers from a List Segment 126
Repopulating a Segment 127
Reviewing Segment History Information 127
Chapter 7: Control Groups 128
Creating a Control Group 128
Populating a Control Group 129
Determining Control Group Membership 129
Chapter 8: Strategies 132
Guided Strategy Creation 132
Bundled offers 133
Customer Lifetime Value 134
Offer prioritization 135
Configuring Prioritization Driver 135
Configuring Prioritization Calculation 136
Configuring Prioritization Threshold 136
Configuring Prioritization Output 137
Priority ranked offers 137
Configuring Targeting Options 138
Arbitrating over Targeting Approaches 143
Configuring Overall Prioritization 144
Saving and Reviewing the Generated Strategy 145
Marketing-centric Strategy Actions 145
Using Segments within Strategies 145
Using Contact Policies within Strategies 147
Requirements for Contact Policies to be Applicable 148
Pega Marketing User Guide v

Note on Using Contact Policies with Offer Bundles 149
Using Geofences within Strategies 149
Selecting Geofences 150
Configuring Filter Options 151
Using a Strategy to Stop In-Flight Offers 152
Chapter 9: Contact Policies 154
Contact Policy Management 154
Creating a new Contact Policy 154
Specifying Contact Policy Availability 155
Specifying Contact Policy Channel Limits 156
Deleting a Contact Policy 156
Chapter 10: Volume Constraints 157
Configuring Constraint Reset Options 159
Specifying Offer Constraints 160
Specifying Channel Constraints 161
Chapter 11: Offers 163
Creating the Offer Flow 165
Adding Flow Shapes 165
Send Email 167
Send SMS 171
Send Generic 175
Send Multiple Treatments 178
Send Passbook 180
Inbound 182
Wait 184
Update Status 185
Hand Off 187
Decision 192
Schedule Appointment 193
Start 194
End 195
Connecting Two Shapes 195
Pega Marketing User Guide vi

Simple Connectors 196
Decision Connectors 196
Wait Connectors 197
Response Received Connector 198
Offer Flow Validation 199
Adding Inbound Channel Support 200
Sample Offer Flow 202
Specifying Offer Details 203
Basic Offer Attributes 203
Offer details 203
Availability 204
Financials 205
Expected outcomes 205
Bundle Attributes 205
Field Marketing Details 205
Custom Attributes 206
Creating a New Attribute 207
Adding an Attribute to a Group's Decision Data Rule 207
Testing the Offer Flow 208
Monitoring Waiting Offers 210
View Waiting Offer Counts 210
Update Expiration Time for Waiting Offers 212
Stop Waiting Offers 213
Reviewing Offer Metrics 213
Performance 214
Key Predictors 214
Chapter 12: Treatments 216
Email Treatments 216
Configuring the Email Treatment 217
Embedding Relevant Data 218
Embedding a Response Link 219
Previewing Included Sections 222
Pega Marketing User Guide vii

Testing the Email Treatment 222
Passbook Treatments 224
Configuring Pass Elements 226
General tab 226
Pass Header tab 227
Primary tab 228
Secondary tab 228
Auxiliary tab 228
Barcode tab 228
Relevance tab 229
Back tab 229
Configuring Pass Fields 230
Configuring Advanced Passbook Options 231
Testing the Passbook Treatment 231
Configuring and Sending the Test Email 231
Reviewing the Test Pass 231
Sections 232
SMS Treatments 233
Using the SMS Treatment Editor 234
Embedding Relevant Data 235
Testing the SMS Treatment 236
Chapter 13: Customer Journey 238
Defining Customer Journeys 238
Managing Customer Journeys 240
Chapter 14: Templates 243
File Template 243
Database Template 243
Configuring Output Destination 244
Configuring Output Content 245
Specifying Header and Footer Information 245
Specifying Output Fields 245
Configuring File and Table Finalization 246
Pega Marketing User Guide viii

File and Database Landing Page Actions 249
Chapter 15: Offer Bundles 250
Offer Bundling Basics 250
Offer Roles 250
Offer Bundle Types 250
Specifying Offer Bundle Settings 252
Using the Details Tab on the Offer Rule Form 252
Specifying Bundle Characteristics in the Strategy 252
Designing Offer Flows for Bundles 253
Designing the Parent Offer 253
Fixed Bundle 254
Flexible Bundle 254
Grouped Offers 254
Designing Member Offers 255
Fixed Bundle 255
Flexible Bundle and Grouped Offers 255
Designing Email Treatments for Bundles 255
Chapter 16: Microsites 257
Creating a Microsite 257
Managing Microsite Stages 259
Adding a New Stage 260
Deleting a Stage 260
Reordering Stages 260
Configuring a Stage 260
Launching another Microsite 261
Defining and Using Custom Data Fields 262
Embedding a Microsite Link in an Email Treatment 263
Launching and Testing Microsites 263
Example Microsite Configurations 264
Microsite using Custom Site Data 264
Microsite using Customer and Offer Data 265
Note on Deleting Microsites 268
Pega Marketing User Guide ix

Manage Subscription Preferences Microsite 268
Embedding Subscription Microsite Link 268
Subscription Microsite Functionality 269
Viewing Unsubscribe Data 270
Subscription Microsite Configuration 272
Subscription Preference Data Class 273
Chapter 17: Geofences 274
Geofence Management 274
Creating a new Geofence 274
Specifying Geofence Details 275
Interacting with the Map 276
Viewing Associated Events 278
Importing Geofences 278
Import 278
Review 279
Summary 281
Geofence Services 282
Preferred Geofences Lookup 282
Detect/Trigger Geofences 283
Chapter 18: Real-Time Events 286
Event Management 286
Creating a new Event 286
Specifying Event Details 287
Associating Geofences with the Event 288
Viewing Associated Campaigns 289
Triggering an Event 289
Integration with Event Strategy Manager 290
Directly use hook activity 290
Use integration ruleset 291
Chapter 19: Real-Time Containers 292
Container Management 292
Creating a New Container 292
Pega Marketing User Guide x

Specifying Container Details 293
Viewing Associated Entities 294
Real-Time Container APIs 295
Container 296
CaptureResponse 298
CustomerOfferHistory 300
ExecuteContainer 302
ExecuteMobileContainer 304
ExecuteWebContainer 305
Returning Custom Properties in ExecuteWebContainer Response 306
CaptureMobileImpression 307
CaptureWebImpression 308
CaptureClickThrough 309
CaptureMobileClickThrough 310
CaptureWebClickThrough 310
CaptureResponse (Legacy) 310
CaptureWebResponse 312
Sample Container Invocation Script 312
Chapter 20: Prospects 315
Configuring the Prospect Class 315
Importing Prospect Lists 316
Prospect Segments 318
Targeting Prospects in Campaigns 319
Chapter 21: Seed Lists 320
Seed List Management 321
Creating a new Seed List 321
Modifying Seeds in a Seed List 321
Using the SegMap column 322
Deleting a Seed List 323
Updating Seed List Columns 323
Chapter 22: Exclusion List 325
Configuring the Global Exclusion List 325
Pega Marketing User Guide xi

Ignoring the Exclusion List 326
Multi-Channel Campaigns 326
Outbound Campaigns 327
Field Campaigns 327
Chapter 23: Checklists 328
Checklist Display 329
Checklist Header 330
Checklist Details Panel 330
Tasks Panel 331
Links Panel 331
Pega Pulse panel 332
Actions Available on a Checklist 332
Start Checklist 332
Add Tasks 332
Update Checklist Info 333
Complete Checklist 333
Withdraw Checklist 334
Reopen Checklist 334
Task Display 334
Task Header 336
Task Details Panel 336
Links Panel 337
Actions Available on a Task 338
Start Task 338
Update Task 338
Complete Task 339
Withdraw Task 339
Reopen Task 339
Chapter 24: Email and SMS Account Configuration 340
Configuring an Outbound Email Account 340
Configuring an Outbound SMS Account 341
Specifying Delivery Time Frames 343
Pega Marketing User Guide xii

Configuring an Inbound SMS Account 344
Connection setup 345
Additional settings 346
Response behaviors 347
One response 347
Decision table 347
Handling un-initiated responses to Offers 349
Handling responses from unknown customers 349
Chapter 25: Push Notifications 350
Registering Apps for Push Notification 351
Configuring a New App 351
Adding a Variant to an Existing App 353
Setting the Default App 354
Testing an App Variant 354
Deleting an App Variant 355
Using Push Notification with Passbook 355
Configuring Push Notifications in Offers 355
General Configuration 355
Application Configuration 356
Wait After Sending 356
Send Additional Values 357
Set Badge 357
Push Notification User Registration Services 358
Registration Service 358
Un-registration Service 359
Chapter 26: Marketing Profile 360
Profile Elements 361
Customer Details 361
Customer Dimensions 362
Customer Demographics 362
Propensity Scores 363
Engagement History 363
Pega Marketing User Guide xiii

Marketing Profile Customization Guidelines 364
Displaying Next Best Action 365
Displaying Top Offers 365
Displaying Customer Dimensions 366
Chapter 27: Data Management 367
Viewing and Searching for Instances 367
Managing Individual Instances 368
Importing Instances 369
Exporting Instances 370
Chapter 28: Revision Management 371
Revision Management Widget 371
Segments and Samples 372
Included with an existing Revision 373
Packaged directly 374
Importing Revision Packages 374
Chapter 29: Identity Matching 376
Identity Matching in Email 376
Identity Matching in Microsites 377
Identity Matching in Real-Time Containers 378
Identity Matching and Marketing Profile 379
Chapter 30: Paid Media Manager 381
Next-Best-Action-driven Paid Media Audiences 381
Paid Integration Methods 381
CRM Matching-based Destinations 382
Configuring Facebook Ads Destinations 382
Configuring Google AdWords Destinations 384
File-based Destinations 386
Configuring Adobe Audience Manager Destinations 387
Web-based Paid Destinations 388
Configuring Web Destinations 389
Configuring the Next-Best-Action hierarchy for Paid Media 389
CapturePaidResponse REST service 390
Pega Marketing User Guide xiv

Monitoring for Paid Media 391
Paid Media Audiences Landing Page 391
Monitoring Outbound Runs and Real-time Container Updates 392
Error and Warning Handling 393
Tuning Paid Media Manager Performance 393
Appendix A: User Preferences 395
Appendix B: Administrative Settings 396
Configuration Settings 396
Artifact Settings 398
Inbound SMS Settings 398
Manage Data Relationships 399
Associating Entities with the Customer Class 399
Pega Marketing Dynamic System Settings 399
Appendix C: Passbook Settings 402
Uploading the Apple Certificate 402
Uploading the Organizational Certificate 402
Appendix D: System Health 404
Errors and Warnings Cards 405
Errors and Warnings Grids 405
Agent Errors and Warnings 406
Channel Errors and Warnings 407
Configuration Errors and Warnings 407
Runtime Errors and Warnings 409
Appendix E: Using a Configuration Modal Window 410
Configuration Window Components 410
Selecting Items 411
Pega Marketing User Guide xv

Pega Marketing User Guide xvi
Preface
Preface
This guide is designed to provide you with an overview of Pega Marketing and its various
components. Pega Marketing is a comprehensive marketing automation solution that delivers
inbound offer management and outbound marketing campaigns on a single platform. Pega
Marketing 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:
l Use the Pega Marketing portal
l Create Campaigns and Strategies to deliver Offers to customers
l Leverage Segment visualization to hone in on the ideal set of customers
l Configure constraints to optimize throughput
l Create complex cross-channel Offers and group them into bundles
l Design and create compelling Treatments
l Design, deliver, and update (Apple) Passbook passes
l Deliver push notifications to configured apps on Android and iOS devices
l Configure, trigger, and respond to real-time Events and Geofences
l Use stage-based case management to define dynamic Microsites
l Create Seed Lists and utilize them for testing Offers and Campaigns
l Import Prospect Lists and target prospects via Campaigns
l Define and populate Control Groups and utilize them in Strategies
l Create Checklists and Tasks
l Utilize the Customer Profile to view customer details
Pega Marketing User Guide xvii

Preface
l Assess the health of your Pega Marketing application
l Utilize other common marketing functions
Intended Audience
This guide is intended for marketing analysts and managers with Pega Platform and Decision Strategy
Manager (DSM) experience. This guide also provides various insights for administrators and
implementers of Pega Marketing applications.
Guide Organization
This guide contains the following chapters:
Chapter Description
Pega Marketing Provides a business overview of Pega Marketing and explains the basics of the Pega Marketing portal.
Overview
Next-Best-Action Explains how to configure Next-Best-Action, the always-on brain that lets marketers model real-time
inbound experiences.
Marketing Explains how users can utilize and customize the Dashboard to view and monitor application
Dashboard performance.
Multi-Channel Provides an in-depth look into the Multi-Channel Campaigns. Topics covered include Campaign
Campaigns configuration, execution, and monitoring.
Outbound Provides a detailed look into Outbound Campaigns. Topics covered include Outbound Campaign
Campaigns lifecycle, configuration, and available actions.
Segments Provides an in-depth look into Segments, Samples, and Analysis Projects. Topics covered include
designing Segments, running Segments, scheduling Segments, and Intelligent Segmentation.
Control Groups Provides information on creating and populating Control Groups; and determining Control Group
memberships via Strategies.
Strategies Provides information on marketing-specific Strategy shapes and their usage.
Contact Policies 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.
Volume Provides information on creating Offer and Operational Volume Constraints; and configuring constraint
Constraints reset options.
Offers Provides insights into various aspects of the Offer, such as creating and testing Offer flows, and
specifying Offer details.
Treatments Provides information on how to create and test Email, Passbook, and SMS Treatments.
Pega Marketing User Guide xviii

Preface
Chapter Description
Templates Explains how Templates can be utilized to write content to output files and database tables.
Offer Bundles Provides information on creating Offer bundles and designing bundle Offer flows and Email Treatments.
Microsites Provides information on various aspects of creating Microsites using stage-based case management.
Geofences Provides details on creating and importing Geofences; and invoking Geofence APIs.
Real-Time Events Provides information on configuring and triggering Events.
Real-Time Provides information on configuring Real-Time Containers and the APIs available for supporting their
Containers execution.
Prospects Provides information on importing prospect lists and using Prospect-based Segments to target
prospects via Campaigns.
Seed Lists Provides information on configuring and managing Seed Lists.
Exclusion List Provides information on the exclusion list functionality.
Checklists Provides an overview of the various aspects of Checklists and Tasks.
Email and SMS Provides information on configuring Inbound SMS, Outbound SMS, and Outbound Email accounts.
Account
Configuration
Push Provides information on configuring apps for push notifications, using Offers to push notifications to
Notifications customers, and invoking push notification services.
Marketing Profile Provides details on the various elements of the Marketing Profile and guidelines on using it in custom
applications.
Revision Provides an overview of using Revision Management with marketing rules.
Management
Identity Matching Provides an overview of Identity Matching and how it is incorporated into various Pega Marketing
features.
In addition, this guide also includes the following appendices:
Appendix Description
User Preferences Provides an overview of marketing-specific user preferences.
Administrative Settings Provides information for configuring various administrative facets of the application.
Passbook Settings Provides details on uploading certificates for using the Passbook functionality.
System Health Provides an overview of the System Health functionality.
Pega Marketing User Guide xix

Chapter 1: Pega Marketing Overview
Chapter 1: Pega 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.
The Pegasystems 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 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 Marketing dynamically manages multi-channel conversations through the entire customer
lifecycle, from offer design to offer fulfillment.
The solution embraces customer focus by providing measurable business benefits to marketing
organizations by:
l 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.
l Giving users more control – Design, change, measure, and control multi-channel customer
strategies with a single marketing portal that doesn’t require IT involvement. Pega Marketing is the
only solution to support marketing operations with a robust business process management
platform that seamlessly connects sales with customer fulfillment processes.
l Optimizing customer lifetime value - Maximize revenue with proactive cross-sell, up-sell, and
retention opportunities for customers. 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.
Pega Marketing User Guide 1

Features
Pega Marketing features the following high level capabilities:
n 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.
n Shared artifacts and components

Pega Marketing includes a core set of out-of-the-box capabilities leveraged by every module of
the solution that allows users to design, execute, deliver, and adapt to marketing strategies.
Shared components include a single portal that has customizable dashboards, offer and
campaign design, treatment design, channel configuration, constraints optimization, and
response management.
n Analytics-based campaigns
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 select the best customers for your marketing
initiative.
n Marketing Operations
Marketing operations capabilities include dynamic case management that can orchestrate
multiple processes, systems, and people. This allows marketing to adapt to complex business
needs. The Marketing 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.
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 log in to the system.

Role Login Password Default Portal Other Portals

Analyst MarketingAnalyst install Pega Marketing (none)
Manager MarketingManager install Case Manager Pega Marketing
Administrator MarketingAdministrator install Designer Studio Pega Marketing, Case Manager
Pega Marketing Portal

The Pega Marketing portal is specially built for the marketing user and provides the user with quick
and convenient access to a wide variety of resources.
Note: Users of previous Pega Marketing releases (version 7.12 and earlier) should review the
Transitioning from Next-Best-Action Studio section to understand the variations introduced in
the new Pega Marketing portal.
The Pega Marketing portal comprises the following pieces:
l Header
l Navigation Panel
l Home Page

Header
The portal header provides icons for easy access to various tools and menus. This includes the
following:
Icon Label Purpose

Reports Provides access to various report-centric utilities and landing pages
Configuration Provides access to configuration-related landing pages
(operator initials) Provides access to operator resources, such as preferences.
Help Launches Pega Marketing Help
Reports Menu
The Reports menu provides access to the following landing pages and utilities:
l Interaction History - Launches the Interaction History (IH) landing page which provides access
to IH reports.
l Adaptive Models - Launches the Adaptive Models landing page which provides access to ADM
models and predictors.
l Visual Business Director - Launches Visual Business Director.
l Customer Profile- Launches Marketing Profile.
l Marketing Calendar - Launches Marketing Calendar.
l Report Browser - Launches the Report Browser which facilitates the management of reports in
the system.
l Report Settings - Launches the Report Settings landing page which provides access to various
reporting settings. Available to the Administrator role only.
l Simulations - Launches the Simulations landing page which provides access to Data Flow runs
and simulation runs.

Configuration Menu
The Configuration menu provides access to the following landing pages and utilities:
l Predictive Analytics - Provides links to the Adaptive Models Management and Predictive
Analytics Director Settings landing pages.
l Decision Management - Provides links to the Proposition Management, Simulations,

and Data Flows landing pages.
l Visual Business Director - Launches the Visual Business Director (VBD) landing page which
provides access to VBD data sources, KPIs, and views.
l Segmentation - Provides links to the following landing pages:

Segmentation Support - Enables management of Samples and Analysis projects, which are
used in intelligent segmentation.
Seed Lists - Enables management of Seed Lists in the system.
Prospect Lists - Enables management of Prospect Lists in the system.
l Settings - Provides links to the following landing pages. Most of these pages are only available to
the Administrator role.
Application Settings - Provides ability to configure various settings for the application.
Channels - Provides links to the following channel-related landing pages:
SMS – Enables management of Inbound and Outbound SMS Accounts.
Email – Enables management of Outbound Email Accounts and handling of email delivery
errors.
File – Enables management of File Output Templates.
Database – Enables management of Database Output Templates.
Passbook – Enables configuration of Passbook certificates.
Push Notifications– Enables management of Push Notification applications and their

variants.

Infrastructure - Provides links to various infrastructure-related landing pages, such as

Proposition Group Authorization , Decision Services, and Revision Management.
Migration - Launches the Migrate Adaptive Model Schema wizard.
System Health - Initiates a health check of the marketing application.
l Contact Policies - Launches the Contact Policies landing page which facilitates the management
of Contact Policies in the system.
Navigation Panel
The navigation panel occupies the left side of the portal and provides direct access to salient
marketing artifacts. In addition, it also includes search and access to the user's recent items.
Users can collapse (and restore) the panel by clicking anywhere along its right edge. Dragging the
right edge allows resizing of the panel. Additionally, the system may automatically collapse the panel
for small screen sizes.
The navigation panel includes the following links:
l Home - Launches the home page.
l Dashboard - Launches the Dashboard which displays widgets pertaining to the performance of
the Pega Marketing application.
l Next-Best-Action - Expandable section that includes the following landing pages:

Designer - Launches the Designer landing page which enables Next-Best-Action configuration
and authoring.
Supporting Decisions - Enables the management of supporting decision configurations
l Campaigns - Launches the Campaigns landing page which enables the management of
Campaigns.
l Content - Expandable section that includes links to the following landing pages:
Offers - Enables the management of Offers.
Real-Time Artifacts - Enables the management of Real-Time Events, Real-Time Containers,

and Geofences.

Microsites - Enables the management of Microsites.
Image library - Enables users to search for images in the system.
l Intelligence - Expandable section that includes links to the following landing pages:
Strategies - Enables the management of Strategies.
Volume Constraints - Enables the management of Volume Constraints.
Eligibilities - Enables the management of Proposition Filter and When Condition rules.
Tables and Trees - Enables the management of Decision Table and Decision Tree rules.
Scorecards - Enables the management of Scorecard rules.
Analytical Models - Enables the management of Adaptive Model and Predictive Model rules.
l Audiences - Launches the Audiences landing page which enables the management of Segments
in the system.
l Revision Management - Launches the Revision Management landing page which provides role-
based access to the Revision Management functionality. Available only to users with Revision
Management role(s).
RECENT pane
The RECENT pane in the navigation panel lists the items most recently accessed by the user.
Users can click the pane header to expand (and collapse) the pane. Clicking an entry in the pane
opens the corresponding artifact.

Each entry in the pane includes the artifact's name and type (e.g. Offer, Landing Page, etc.). For work
objects, the work id is also displayed.
Tip: The number of items displayed in the RECENT pane is governed by the MaxRecentsCount
Dynamic System Setting.
Home Page
The Home page is the chief starting point for every user. It provides the user with direct access to
items and actions that are relevant to them. Users can also customize the display and content of their
Home page.
The default Home page contains the following widgets:
l Create a new campaign - Shortcut to create a new Campaign.
l Define your audience - Shortcut to create a new Segment rule to define the target audience.
l Monitor outcomes - Shortcut to launch Visual Business Director.
l My Work - Displays the user's work list. Click an entry to open the corresponding work object.
Users can include any other available widgets on their Home page. Other available marketing-centric
widgets include the following:
l Manage Next-Best-Actions - Shortcut to launch Next-Best-Action Designer.
l Checklists - Displays Checklists in the system and provides link to create new Checklists.
Requires Marketing Operations to be enabled on the system.
l Marketing Calendar - Shortcut to launch the Marketing Calendar.
l Revision Management - Displays Change Requests that are assigned to the user and lists each
rule within the request. Requires user to have Revision Management role.
Customizing the Home page

The Pega Marketing portal Home page is a standard dashboard and can be customized in the same
manner as other dashboards.

This process includes the following steps :
1. Click the gear icon (in the top right) to switch the dashboard to edit mode.
2. Use the Switch template link to select the desired template for the dashboard.
3. Add desired widgets to each slot in the template.
4. Configure options for applicable widgets. Hover over the widget to determine if it has available
options. If it does, the text Click to edit is displayed.
5. Use the Publish button to apply your changes and save your customized dashboard.
Refer to official Pega Platform documentation for more details on the customization process.
Tip: The default Home page configuration can be modified by users with suitable access. This access
is governed by the CanPublishToDefault Privilege, which is furnished to marketing managers and
administrators via the PegaNBAM_FW:MarketingManager role. The PegaMarketing_
FW:PortalAdministrator Access Role wraps this privilege and can be added to desired Access Groups.
Users with this requisite access can utilize the Publish to default option in the Publish button menu
to update the default Home configuration.
Transitioning from Next-Best-Action Studio

The Pega Marketing portal replaces the Next-Best-Action Studio portal that marketers used in
previous releases of Pega Marketing. The new portal is built using standard Pega Platform constructs
and is thereby more robust and customizable.
Existing users transitioning to the Pega Marketing portal will notice various differences from the
previous portal. This section outlines these differences and the rationale behind them.
One of the key differences between the two portals is the simplicity of the new portal. In the new
portal, marketers can quickly and directly access primary artifacts (such as Campaigns, Offers, and
Segments). Secondary artifacts are now accessed and, in most cases, created in context of their
usage.
For example, consider the case of Volume Constraints. In order to be utilized by the system, a
Volume Constraint needs to be associated with a Campaign. In the new portal, users would begin by
creating (or modifying) a Campaign. If the user wishes to utilize Volume Constraints with their
Campaign, they simply utilize the appropriate selector while configuring the Campaign to review (and
select from) existing Volume Constraints or create a new one.

Contextual creation of secondary artifacts also enabled the removal of the various explorers through
which users had to previously navigate. The end result is a simplified navigation model with direct
role-based access to all primary artifacts.
Finally, existing users will also notice a change in the verbiage used to represent certain artifacts.
These changes were added to better align the product's feature set with commonly used marketing
terminology.
The key verbiage changes (from previous versions) are:
l Campaigns from version 7.12 are now referred to as Outbound Campaigns to better indicate their
specialization.
l Programs are now referred to as Multi-Channel Campaigns (or simply Campaigns).
l Segments are now also referred to as Audiences.

Chapter 2: Marketing Dashboard

The Dashboard provides marketers with a customizable set of widgets. These widgets display the
application's performance across various marketing metrics. Marketers can customize the widgets
displayed in the Dashboard and configure the goals for each widget. Once configured, the Dashboard
enables marketers to quickly assess how their business is doing. The marketer can also apply
different filters to further refine the displayed metric data.
The Dashboard is accessible in the Pega Marketing portal via the Dashboard link in the left
navigation pane.
Marketing widgets displayed on the Dashboard are categorized into groups. The following table lists
the available marketing widgets in each group.
Widget Group Available Widgets

ACQUISITION - Owned Media Spend
- Owned Media Spend Trend
- Owned Media Spend by Channel Trend
AWARENESS - Net Promoter Score
- Net Promoter Score Trend
- Social Sentiment
- Social Sentiment Trend
BUSINESS KPI - Churn Rate
- Churn Rate Trend
- Net Revenue
- Net Revenue Trend
- ROMI
- ROMI Trend
- Retention Save Rate Trend
- Retention Save Rate and Cost Trend
ENGAGEMENT - Email Engagement
- Email Engagement Trend
- Microsite Total Visitors Trend
- Web Engagement
- Web Engagement Trend
Using the Dashboard

This section explains the basics of the Dashboard and provides information on the following topics:

l Understanding the widget display
l Applying filters
Understanding the Widget Display

Marketing widgets provide a great deal of information pertaining to the performance of each widget's
metric(s). The Dashboard utilizes different visual paradigms to display these widgets in order to
highlight relevant data points and salient performance aspects.
Insight & Action

The Insight & Action view of a widget displays customizable information pertaining to the
performance of the widget metric against its goal. Marketers can access this view by clicking the ...
icon in the widget header.
Clicking this icon displays the configured message for the widget. The default message indicates
whether the goal for the widget has beet met. In addition, the color of the icon also indicates this
information - the icon color is green when the goal is met and red otherwise.
Clicking anywhere outside the view switches the widget back to its default view.
Display Types
This section highlights key features of the various displays used by marketing widgets. Each display
includes the following common elements:
l Widget name
l Insight & Action icon

l Current metric value
l Target metric value (e.g. goal, benchmark, etc.)
Marketing widgets can be classified into the following categories based on their data visualization:
l Visualizing data for the current time period
l Visualizing data trends across time periods
There are multiple display types within each of the above categories. Additional information
presented on the widget varies based on the display type.
Current Data Display Types
Engagement Trend
This display type is specific to engagement related widgets and includes the following additional
features:
l Conversion Goal line
l Left y-axis corresponds to the area chart (Impressions)
l Right y-axis corresponds to the dual line charts (Conversion Rate, Click Through Rate)
l Hovering over a data point displays the corresponding metric value
l Clicking the metric name in the legend toggles the display of the metric's chart
This display type is utilized by the following widgets:

l Email Engagement Trend
l Web Engagement Trend
Metric Bar
This display type includes the following additional features:
l Bar color indicates whether the goal is met - green if met, red otherwise
l Bar visually denotes previous, goal, and current values
l Call-out value denotes the difference from goal value
l Sentence highlights metric value change (increase vs. decrease) against configured time period
(e.g. quarter) and current performance against goal (above vs. below)
l Churn Rate
l Net Revenue
l Owned Media Spend
l ROMI

Engagement Funnel
features:
l Current and goal values for each of the three metrics
l Funnel portion for each metric with portion size corresponding to metric volume
l Hovering over a funnel portion highlights the corresponding metric and its value
l Color of the funnel portion indicates whether the corresponding metric goal is met - green if met,
red otherwise
l Sentence indicates performance of the conversion metric against goal
l Email Engagement
l Web Engagement

Social Sentiment
This display type is specific to the Social Sentiment widget and includes the following additional
features:
l Major metric value (e.g. 50.00%) denotes the score for positive social sentiment
l Sentiment bar displays percentage breakdown for each sentiment
Net Promoter Score
This display type is specific to the Net Promoter Score widget and includes the following additional
features:
l Major metric value (e.g. 17) denotes calculated net promoter score (NPS)
l Number and percentage of individuals in each NPS grouping (promoter, passive, detractor)

Trend Data Display Types
Trend Single Line
l Goal line
l Data point color indicates whether the goal is met for a time period - it is green if the goal is met,
red otherwise
l Call-out value on the final data point (e.g. 30.53M above) denotes the difference in metric value
from the previous period.
Color of the arrow (green or red) indicates whether the change in value is towards the
betterment of the metric
Direction of the arrow (up or down) indicates whether the change is an increase or decrease
from the previous value
l Churn Rate Trend
l Microsite Total Visitors Trend
l Net Promoter Score Trend
l Net Revenue Trend

l Retention Save Rate Trend
l Social Sentiment Trend
Trend Single Bar
l Goal line
l Metric values for each period
l Bar color indicates whether the goal is met for a time period - it is green if the goal is met, red
otherwise
This display type is utilized by the Owned Media Spend Trend widget.
Trend Single Bar Single Line

l Left y-axis corresponds to the bar chart metric (e.g. Average Spend)
l Right y-axis corresponds to the line chart metric (e.g. Save Rate)
l Major value (e.g. 70.59%) is the value of the line chart metric for the current time period (e.g. Q2)
l Hovering over a data point or bar area displays the corresponding metric value
This display type is utilized by the Retention Save Rate and Cost Trend widget.
Trend Dual Bar Single Line
This display type functions similarly to the Trend Single Bar Single Line type described above. The
only difference is that it supports multiple bar metrics in the left y-axis.
This display type is utilized by the ROMI Trend widget.
Engagement Trend

features:
l Conversion Goal line
l Left y-axis corresponds to the area chart (Impressions)
l Right y-axis corresponds to the dual line charts (Conversion Rate, Click Through Rate)
l Email Engagement Trend
l Web Engagement Trend
Applying Filters
Marketers can use the controls at the top of the Dashboard to set filters on the data utilized by
marketing widgets.
The following filter options are available:
l Start - Start date for the data being fetched
l End - End date for the data being fetched
l Timeframe - Time period into which the fetched data should be grouped
l Issue / Group - Issue and Group for which the data should be fetched. By default, the Dashboard
fetches data across all Issues and Groups.
Clicking the View button applies configured filter criteria and triggers the Dashboard to reload.

Customizing the Dashboard

This section explains how users can customize the Dashboard to include desired widgets and
configure the options for these widgets.
To make any changes, marketers can use the gear icon in the top right to switch the Dashboard into
edit mode. In edit mode, marketers can perform the following actions:
l Manage widgets
l Configure widget options
Additionally, application implementers can also perform the following:
l Customize Insight & Action
l Customize default Dashboard
Managing Widgets
This section explains how marketers can add, remove, and re-organize widgets in the Dashboard.
Adding a New Widget

In edit mode, users can perform the following steps to include a new widget:
1. Click Add widget in the desired slot.
2. In the widgets modal window, select the desired widgets to add and click Add selected. The
modal displays widgets in their groups and includes a description for each widget.

3. Optionally, configure options for the added widgets.
4. Click Publish to save the customized dashboard.
Removing a Widget
In edit mode, users can remove a widget from the dashboard by either of the following:
l Clicking the delete icon in the top right corner of the widget
l Clicking the delete icon in the row for the particular widget in the Widgets grid

Re-organizing widgets
In edit mode, users can re-organize widgets within a slot and move widgets across slots by either of
the following:
l Dragging the widget to the desired position in the target slot
l Using the drag icon to drag and drop the widget row to the desired position in the Widgets grid
Configuring Widget Options

Most marketing widgets have options that should be configured after adding the widget. If a widget
has configuration options, the text Click to edit displays when hovering over the widget in edit
mode.
To view available configuration options, users can either select the widget directly or click the link for
the widget in the Widgets grid.

The options for the widget are displayed in the Edit dashboard panel.
Users can click Preview to view the impact of their changes on the widget. Clicking Save saves the
configuration options and applies them to the widget.
Note: Changes to configuration options are not final until the user publishes these changes via the
Publish button. Users may use the Discard button to revert to the previous configuration of the
Dashboard.
All widgets related to marketing metrics have a configurable goal option. The name and type of this
option varies based on the metric. For example, the goal for the Return on Marketing Investment
(ROMI) metric is a percentage, while the goal for the Net Revenue metric is a number. However, there
are two deviations from the single goal option.
l Multiple goals - The Email Engagement and Web Engagement widgets have three configurable
goals.
Impressions (number)
Click through rate (percentage)
Conversation rate (percentage)
l Retention Issue - Retention related marketing widgets include an additional option to specify
the retention issue. Once specified, the widget only includes those data points associated with the
configured retention issue.

Customizing Insight & Action

Individuals configuring the marketing application can perform the following steps to customize the
Insight & Action messages for each widget.
1. Switch the Dashboard into edit mode by clicking the gear icon.
2. Select a widget to configure.
3. In the Edit dashboard panel, click Edit in the Insight & Action field.
4. This will open the backing Decision Table rule for the widget. The Decision Table rule has two
outcomes - Met and Missed. These outcomes are mapped to messages using Field Value rules.
Switch to the Results tab and expand the Additional Allowed Results section to view the
name of the corresponding Field Value for each outcome.
5. To customize the message for a widget outcome, take over the corresponding Field Value rule in
your implementation layer and update it to include the desired message.

Marketers will now see the customized message when they review the insight information for this
widget.
Customizing the Default Dashboard

The default Dashboard configuration can be modified by users with suitable access. This access is
governed by the CanPublishToDefault Privilege, which is furnished to marketing managers and
administrators via the PegaNBAM_FW:MarketingManager role. The PegaMarketing_
FW:PortalAdministrator Access Role wraps this privilege and can be added to desired Access Groups.
Users with this requisite access can utilize the Publish to default option in the Publish button menu
to update the default Dashboard configuration.

Chapter 3: Next-Best-Action
In today’s digital world, marketers can no longer dictate the purchasing path and where, when, and
how customers engage with companies. Customers demand personalized and consistent experiences
across every channel be it the call center, web, retail locations, IVR, or mobile apps. Marketers need a
way to create timely and relevant actions that can be integrated into every customer interaction.
Unlike traditional Campaigns which typically target segments of customers for specific products and
services over a set time frame, Pega's Next-Best-Action (NBA) is “always-on”, serving as the brain for
every interaction with customers across all channels. This leads to increased customer value while
enhancing the customer experience with every interaction. The NBA authoring experience helps
marketers coordinate their customer journeys using customer data and derived customer insights to
provide proactive contextual actions. Key aspects include:
l Real-time automated contextual decisions, with optimal scalability
l Effectiveness of predictive and adaptive decision making
l Business users directly manage changing requirements, with a platform built for agility and
control.
This chapter includes the following topics that explain the various aspects of Next-Best-Action:
l Configuring the NBA hierarchy - This topic explains how to build the hierarchy of business issues
and groups that will participate in NBA.
l Configuring NBA definitions - This topic explains how to configure each stage of the NBA
hierarchy.
l Scheduled NBA execution - This topic explains how to utilize NBA configuration to perform
outbound marketing.
l Monitoring outcomes - This topic explains how to monitor the performance of NBA nodes across
configured metrics.
l Supporting decisions - This topic explains how to create and configure supporting decisions, which
are constructs used to associate Strategies with Real-Time Containers.

Configuring the NBA Hierarchy

The first step in configuring Next-Best-Action is defining an NBA hierarchy - i.e. the business issues
and groups that will participate in NBA. The Hierarchy portion of NBA Designer enables users to
configure this hierarchy. NBA Designer can be accessed in the Pega Marketing portal via: Next-Best-
Action > Designer
At the onset of NBA configuration, the Designer starts out in hierarchy management mode. Once a
hierarchy has been defined, use the gear icon in the Hierarchy panel header to switch to hierarchy
management mode. In this mode, click the Edit button to make changes to the hierarchy.
Note: The ability to modify the NBA hierarchy is controlled by the CanManageNBA privilege. This
privilege is granted (by default) to marketing managers and administrators via the PegaNBAM_
FW:MarketingManager role. Users that do not have this privilege will not see the controls referenced
in this section to configure the NBA hierarchy.
To begin configuring a new hierarchy, click the Add link in the top-level Next-Best-Action row.
The Configure Next-Best-Action modal window is displayed. This modal lists the business issues that
are part of the marketing application. Select the desired business issues to activate for NBA.

This modal window even allows for creation of new hierarchy items. Click the Create link and enter
a name for the new issue.
Note: Any newly created hierarchy item can be updated until the hierarchy changes are saved.
Click Apply after selecting the desired business issues. The selected issues are displayed under the
top-level Next-Best-Action node.
Next, use the individual Add links for each issue to select the groups to activate for NBA. As before,
use the Create link in the configuration modal window to create new groups. After selecting the

desired issues and groups, click the Save button on the landing page to submit your changes and
activate the selected hierarchy.
As part of saving the hierarchy changes, the system creates any new hierarchy items (business issues
and groups) and generates any necessary backing artifacts. After the hierarchy has been successfully
saved, the display switches back to the main Designer view.
The Delete button enables users to reset the configured NBA hierarchy.
The Close button exits the user from hierarchy management mode and returns them to the main
Designer display.
Configuring NBA Definitions

The Next-Best-Action panel of NBA Designer enables marketers to configure the desired behavior
of the Next-Best-Action functionality. The marketer should configure every level of the activated NBA
hierarchy. The marketer can choose to adopt a top-down or bottom-up approach when configuring
the hierarchy. This flexibility in configuration also enables multiple marketers to be responsible for
different portions of the hierarchy.
To configure the definitions for a node, select the node in the left navigation and click Edit.
The configuration options for hierarchy nodes vary based on the node type. Refer to the following
topics for more details:
l Configuring the Next-Best-Action node
l Configuring a business issue node
l Configuring a business group node
At any node, the marketer can configure the outcomes to monitor and configure the node's
usage - i.e. specify where to apply the node's results.
Finally, after making the desired changes, save the updated configuration.
Configuring the Next-Best-Action Node

The following steps are involved in configuring the top-level Next-Best-Action node:
1. Configure the actions to take with customers
2. Specify how to prioritize the actions

Configure Actions
Use the Next-Best-Actions section to configure the actions to take with customers. Click the Add
action link to define a new action. Upon clicking this link, a configurable action is added.
First, enter a Name for the action. The system generates an identifier for the action based on the
name. Users can utilize the pencil icon to edit the identifier, if needed.
Next, use the Select results from drop-down to specify the source of results for the action. Select the
source business issue or group from the active hierarchy.
Finally, use the Add criteria link to configure the conditions that make this action relevant. Users
must specify at least one relevance criteria for each action. For each criteria, use the Component field
to select an issue or group from the active hierarchy. Then, specify the attribute to inspect in the
Property field. The NBARelevance property serves as the default relevance property. The property
specified should be set by the NBA Strategy for the specified component. Use the Operator and Value
fields to specify the relevance threshold.
When specifying multiple relevance criteria, use the Logic string field to specify how to combine the
criteria. Each criteria label (A, B, etc.) must be present in the logic string. Users can combine these
labels using parentheses, AND, and OR.
Repeat the above process to create and configure more actions. The drag icon, located at the left of
the action's name, enables the re-ordering of actions. The order in which the actions are listed
represents their respective rank.

Prioritize Actions
When multiple actions are added to NBA, use the Action prioritization section to rank these
actions.
Click the Configure link in this section to launch the Configure Prioritization modal window. Usage
patterns for this modal window are described in the Using a Configuration Modal Window
appendix.
Select the desired prioritization Strategy from the list of rules and click Apply.
Note: The Configure Prioritization window only lists those Strategies that have the NBACategory
custom field set to ACTIONPRIORITIZATION. New rules created from this window automatically have
this custom field set.
Marketers can use the power of Strategies to design their desired action prioritization logic. Two
simple options for this Strategy involve prioritizing by rank and prioritizing by relevance.
Prioritizing by Rank
Prioritizing by rank is as simple as manually ordering the actions in the Next-Best-Actions section (by
using the drag control) and then using a Prioritize shape in the Strategy to order by the Rank
property. This is demonstrated in the following Strategy configuration:

Prioritizing by Relevance
Prioritizing by relevance simply involves using a Prioritize shape in the Strategy to order by the
relevance property (e.g. NBARelevance).
Configuring a Business Issue Node

The following steps are involved in configuring the definitions for a business issue:
1. Configure the issue's relevance
2. Specify how to select and prioritize results
Configure Relevance
Use the Next Best Action relevance section to specify the relevance for the hierarchical unit - i.e.
issue or group. If this unit is the driver for an action in the top-level NBA, the relevance value of this
unit will be inspected against the configured threshold to determine if the action is relevant for the
customer.

Click the Configure link in this section to launch the configuration modal window. Usage patterns
for this modal window are described in the Using a Configuration Modal Window appendix.
Select the desired relevance Strategy from the list of rules and click Apply.
Note: The relevance configuration window only lists those Strategies that have the NBACategory
custom field set to RELEVANCE. New rules created from this window automatically have this custom
field set.
Select and Prioritize Results

Use the Engagement policies section to specify how to select and prioritize results from the
groups that belong to this issue. Choose between the following modes:
l Guided - In this mode, use the Configure links in the Eligibilities and Prioritization sub-
sections to select the desired rules. The configuration windows for these two components are
similar to the ones used in the guided Strategy creation process. Refer to the Configure Eligibilities
and Configure Prioritization topics in the Strategies chapter for more details. An example
configuration using this mode is shown below.
l Manual - Use this mode if the operations available in the guided mode are not sufficient for your

needs. In such cases, use the Alternate strategy link to switch to this mode. Then use the
Configure link in the Alternate strategy sub-section to select the Strategy rule to use to
prioritize group results. Clicking this link launches the Configure Alternate Strategy modal window.
Usage patterns for this modal window are described in the Using a Configuration Modal Window
appendix.
Select the desired alternate Strategy from the list of rules and click Apply. Upon application, the
selected Strategy is listed in the Alternate strategy section. Marketers can click the Strategy name
to open it.
Use the Prioritization link to switch back to guided mode, if needed.
Configuring a Business Group Node

The following steps are involved in configuring the definitions for a business group:
1. Select a template - Use the Configure link in the Business template sub-section to choose one
of the following objectives for the group:
a. Priority ranked offers - Select this template to utilize the guided Strategy creation mechanism
to power the NBA for the group. This process is described in detail in the Strategies chapter.
Refer to the following topics for details: Configuring Targeting Options, Arbitrating over
Targeting Approaches, and Configuring Overall Prioritization.
b. Use alternate strategy - Select this template to instead use a manually created Strategy. In such
cases, use the Configure link in the Alternate strategy sub-section to select the Strategy
rule to use for the group's NBA.
2. Configure the group's relevance - This is done in a similar fashion as configuring relevance at the
issue level.
3. Configure the selected objective - Use the reference topics mentioned above to configure the
sections applicable to the selected business template.

Configuring Outcomes
At any NBA hierarchical level, use the Monitor outcomes section to specify the outcomes to track
for that level. Click the Configure link to select the metrics to track. Clicking this link launches the
Configure Metrics modal window. Usage patterns for this modal window are described in the Using
a Configuration Modal Window appendix. Use this window to select up to nine metrics to monitor
as part of NBA. Each metric is a Key Performance Indicator (KPI) configured on the Visual Business
Director landing page.
Once the NBA configuration is saved, the selected metrics are activated. The system displays the
performance results for these metrics for the selected node. Refer to the Monitoring Outcomes
topic later in this chapter for details on how to review the performance of configured metrics.
Configuring Usage
At any NBA hierarchical level, use the Usage section to specify where to apply the results for that
NBA level. The system provides support for the following:
l Associating NBA with Real-Time Containers
l Scheduled NBA execution
Associating NBA with Real-Time Containers

Marketers can associate their Next-Best-Action configurations with Real-Time Containers, thereby
utilizing their NBA logic when the associated Container is triggered.
Click the Configure link in the Real-time containers section to launch the Configure Containers
modal window. Use this modal to add the Containers that should be associated with this NBA level.
appendix.

Click Apply after adding the desired Containers to return to the main display. Upon application, the
added containers are listed in the Real-time containers section. An active status indicates that the
Container will currently respond to requests, while an inactive status indicates that it will not.
Marketers can click a Container name to open the associated Container rule.
Note: A Container can only be associated to a single NBA level, Supporting Decision, or active Multi-
Channel Campaign at a given point in time.
Saving Configuration Changes

After making the desired configuration changes, click the Save button to persist the changes. As part
of this operation, the system will first validate the specified configuration and report any errors. Once
all reported errors have been addressed, the system will save the associated configuration and re-
generate the associated Strategy. Once the save operation is complete, the display switches back to
review mode.
To review the generated Strategy, use the Open canvas menu item from the Actions landing page
menu.
Note: NBA Strategies are automatically managed behind the scenes by the system. Any manual
changes to these Strategies will be overwritten when the corresponding NBA configuration is saved.
Deleting an NBA Configuration

Marketers can use the Delete button in the NBA header for a particular node to remove the NBA
configuration for that node. Marketers may choose to take this action to reset a node's configuration.
Deleting an NBA configuration does not delete the generated Strategy.
Note: The Delete button is disabled if the NBA configuration has an active outbound schedule.

Scheduled NBA Execution

Pega Marketing also enables marketers to utilize their NBA configuration to perform outbound
marketing. Marketers can configure a recurring schedule for outbound execution of their NBA
configuration.
Refer to the following topics for more details:
l Configuring the outbound schedule
l Launching the outbound schedule
l Other schedule actions
Configuring the Outbound Schedule

To configure an outbound schedule, edit the configuration of the desired NBA node. Click the
Configure link in the Outbound schedule section (under Usage) to launch the Configure
outbound schedule modal window. Use the fields in this window to set up a recurring schedule for
NBA. The scheduling options are similar to the recurring options available when scheduling a Multi-
Channel Campaign. Refer to the Campaign Schedule topic in the Multi-Channel Campaigns chapter
for more details.
In addition to configuring a schedule, marketers can also choose to directly output Campaign results
to a database table (referenced by a Database Template rule), thereby bypassing Offer processing
altogether. Check the Write results using a database template checkbox to enable this mode. After
enabling this option, click the Add template link to see a list of available Database Template rules.
Note: The direct output feature requires the Database Template rule to utilize the Append writing
mode. The configuration window only lists those templates that utilize this mode.
After selecting a template, click the Add template button to return to the schedule configuration.
After configuring the rest of the schedule, click Apply to close the schedule configuration window.
A sample schedule configuration is shown below:

Next, the marketer must specify the audience to target with the outbound schedule. To do so, click
the Configure link in the Audience sub-section. Clicking this link launches the Configure Audience
modal window. Usage patterns for this modal window are described in the Using a Configuration
Modal Window appendix. Use this window to select the Segment that defines the target audience for
the scheduled NBA execution.
The marketer can also choose to utilize a Volume Constraint to constrain the Offers output by the
outbound scheduled execution. To do so, click the Configure link in the Constraint sub-section.
Clicking this link launches the Configure Constraint modal window. Usage patterns for this modal
window are described in the Using a Configuration Modal Window appendix. Use this window to
select the Volume Constraint that defines the Offer and/or channel constraints to apply to the
scheduled NBA execution.
Launching the Outbound Schedule

Once changes to the NBA configuration are saved, the outbound schedule is in a draft state. The
marketer can activate the schedule using the Run action from the Actions menu in the Outbound
schedule sub-section.
Note: The Run action is only available after all required components of the schedule have been
configured.
Upon taking this action, the system validates the configured schedule and triggers its execution. If the
schedule can be successfully applied, the status of the outbound schedule changes from Draft to
Running.

The Run schedule section lists the active and upcoming runs for the schedule. As a run is initiated,
its entry moves from the upcoming list to the active list. While a run is executing, its status displays
as Scheduled. During this phase, the marketer can utilize the Stop link to attempt to stop the
executing run.
When the run successfully completes execution, its status changes to Completed. The system also
displays the number of Offers that were sent as part of the run.
If there is an issue with the scheduled run, its status changes to Failed. In such cases, the marketer
can utilize the Skip link to ignore the failed run or the Restart link to initiate a replacement run.
Other Schedule Actions

This section describes the following actions that the marketer can perform with an outbound
schedule:
l Suspend an active schedule
l Modify an active schedule
l Start another schedule
Note: If the Run, Suspend, or Configure schedule action is performed while the NBA configuration is
in edit mode, the action is queued and applied when the configuration is saved. If multiple such
actions are performed, only the last action takes effect.
Suspending an active schedule
To deactivate an active schedule, marketers can utilize the Suspend action from the Actions menu.

Upon completion of this action, the outbound schedule reverts back to the draft state.
Modifying an active schedule
Marketers can also modify an active schedule. To do so, switch to edit mode and then use the
Configure link to update the schedule configuration. Save the NBA configuration to apply the changes
made to the schedule.
Starting another schedule
After all runs of the configured schedule have completed, the status of the outbound schedule
changes to Completed.
When the configured schedule has completed, marketers can configure a new schedule if desired. To
do so, switch the configuration to edit mode and re-configure the outbound schedule. Upon saving
the new configuration, the status of the outbound schedule changes to Draft. The system now
displays information about the new schedule in the active and upcoming runs lists. The marketer can
launch this updated schedule following the aforementioned guidelines.
Monitoring Outcomes
The system displays the performance of selected outcomes in the Monitor outcomes section for
each configured NBA node. The results are context-specific, i.e. they are filtered based on the
business context (top-level, issue, or group) of the corresponding node .
The default view presents the outcomes spanning all of time.

To switch to a drill-down view of these results, click any metric box or the line chart icon (shown in
the image above). A sample detailed view is shown below:
The detailed view includes the following information for each metric:
l A line chart spanning the selected time frame with data points for the selected frequency.
The default time frame is the past year and the default frequency is quarterly.
To change the time frame or frequency, use the controls above the charts.
Hover over a data point to see the metric name, the time period, and the metric value.
The call-out on the last data point indicates the trend of the metric, i.e. the change in the metric
between the last two time periods. The arrow icon indicates whether the metric is trending up
or down, while the call-out value denotes the actual change in the metric's value.
l An information box with the name of the metric, the latest time period, and the value of the metric
for that time period.
Supporting Decisions
Next-Best-Action Designer facilitates the association of Real-Time Containers with NBA
configurations. In certain cases, marketers may additionally want to associate Containers with other
Strategies. Pega Marketing provides support for this requirement via supporting decisions.
The Supporting Decisions landing page lists the configured supporting decisions in the system. This
landing page is accessible in the Pega Marketing portal via: Next-Best-Action > Supporting
Decisions
Marketers can use this landing page to perform the following actions:

l Search for and view supporting decisions - Use the Search input field to specify the search text.
Click View to view the matching supporting decisions.
l Open a supporting decision - Click a supporting decision's name in the grid to open it.
l Create a new supporting decision
Creating and Configuring a Supporting Decision

Perform the following steps to create and configure a supporting decision:
1. Click the Create button in the Supporting Decisions landing page header. This opens the Create a
supporting decision page.
2. Enter a name for the supporting decision in the Decision name field. The system automatically
generates an identifier based on the name. To change the identifier, click the pencil icon.
3. Use the Description field to enter any relevant details.
4. Use the Alternate strategy section to select the Strategy that this supporting decision will
reference. Click the Configure link in this section to launch the Configure Alternate Strategy
modal window. Usage patterns for this modal window are described in the Using a Configuration
Modal Window appendix.
5. By default, the supporting decision utilizes all results from the selected Strategy. To use a specific
component, use the Strategy results drop-down to select the desired Strategy result.
6. Next, use the Real-time containers section to select one or more Real-Time Containers to
associate with the selected Strategy. Click the Configure link in this section to launch the
Configure Containers modal window. Usage patterns for this modal window are described in the
Using a Configuration Modal Window appendix.

Upon closing the configuration window, the selected Containers are displayed along with their
current status. An active status indicates that the Container will currently respond to requests,
while an inactive status indicates that it will not.
7. After configuring the Strategy and Containers, click the Save button.
At this point, the system validates the specified configuration. If there are validation failures, the
system displays these. Some of the validations that the system performs during this phase are:
l Decision name (generated identifier) is not already used by an existing supporting decision.
l Supporting decision must have a Strategy configured if Real-Time Containers have been
configured
l Specified Containers are not currently active elsewhere - such as part of a Next-Best-Action
configuration, another supporting decision, or an active Multi-Channel Campaign.
Once the supporting decision is successfully saved, the display switches to review mode. To make
any further changes, click Edit to switch back to edit mode. Marketers can update all elements of a
created supporting decision, with the exception of the identifier.
Marketers can also use the Delete button to remove a supporting decision.

Chapter 4: Multi-Channel Campaigns
Chapter 4: Multi-Channel
Campaigns
Multi-Channel Campaigns (commonly referred to as Campaigns) enable marketers to use the power
of intelligent segmentation and analytics to deliver the right offering to the right customer at the right
time.
This chapter includes the following sections that explain various aspects of Multi-Channel Campaigns:
l Campaign Management - Describes the Campaigns landing page and how users can utilize it to
view and search for Campaigns
l Campaign Creation - Describes how users can create a new Multi-Channel Campaign
l Campaign Configuration - Provides information on how users can configure the different elements
of the Campaign
l Campaign Approval - Provides an overview of the approval process and the actions available to
the marketer and the manager
l Campaign Validation - Describes how users can validate their Campaigns
l Campaign Testing - Explains how users can test their Campaigns by running distribution and seed
tests
l Campaign Execution - Explains execution specific actions available on Campaigns and runs
l Campaign Monitoring - Describes how users can monitor the performance of their running
Campaigns
l Campaign Completion - Provides an overview of the actions available at the end of the Campaign's
execution cycle
Campaign Management
Campaigns are listed on the Campaigns landing page which is accessed in the Pega Marketing portal
via the Campaigns link in the left navigation. This landing page lists the twenty most recently
updated Multi-Channel Campaigns and Outbound Campaigns available in the system. The View

more results link (at the bottom) enables users to view the next twenty results. Users can utilize the
filters at the top of the page to filter the results by Status, Issue / Group, Name, and Created by.
Note: A Campaign is deemed available if its status is not Archived or Withdrawn.
Each Campaign is represented by a card in the landing page.
Users can click anywhere on the card to open the Campaign. The card displays the following salient
information about the Campaign:
l Name
l Work id
l Status icon - icon's tooltip displays status text
l Enabled engagement types - available types are Outbound, Event, and Container
l When the Campaign was last updated
l Configured audience size
l Total number of impressions
l Overall conversion rate
l Image associated with the Campaign
l Channel icon array, containing icon for each channel utilized within the Campaign - icon's tooltip
displays channel name

l Conversion goal achievement indicator - This is the color bar at the bottom of the card and
indicates performance against the Outbound Conversion Rate goal. It displays one of the following
colors:
Gray - If Outbound Conversion Rate is not a configured goal for the Campaign or when the
Campaign is in design mode.
Green - If the conversion rate goal has been met
Red - If the conversion rate goal is not met
Campaign Creation
Users can utilize either of the following mechanisms to create Multi-Channel Campaigns:
l Using the Create button on the Campaigns landing page
l Using the Create a new campaign shortcut widget in the Pega Marketing portal Home page
Upon creation, a new Campaign resembles the following:

Note: The Campaign's name must be unique across the system. Unlike some of the other rules
(such as Offer), the same Campaign name can’t be used at different hierarchical levels
(Top/Issue/Group). The name must also begin with a letter and shouldn’t contain any special
characters (except spaces and underscores).
Campaign Configuration
Marketers can start configuring the Campaign right from the Create a campaign 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.
As the user updates the Campaign's configuration, the updated values are displayed in the overview
pane on the right. This pane provides an overview of the Campaign's various configurations. The
overview pane is displayed at all times and includes links to open relevant artifacts.
A sample configured Campaign is shown below:
The following sections provide details on the steps involved in configuring a Campaign:
l Specifying Details
l Specifying Goals
l Selecting a Strategy

l Selecting an Audience
l Configuring Campaign Engagement
l Selecting a Constraint
Specifying Details
Users can utilize the Plan tab to specify various details about the Campaign. These details are
organized into the following sections:
l Campaign details
l Financials
Campaign details
This section includes basic details about the Campaign and includes the following:
l Name
l Issue
l Group
l Business objective
l Campaign type
l Key code
l Priority
l Campaign image - Image associated with the Campaign. This image is displayed in the right
overview pane and in the card for the Campaign on the Campaigns landing page.
l Target audience type - Type of audience (Customer or Prospect) to target via this Campaign.
The value selected for this field determines the items presented in the Audience and Marketing
strategy sections in the Build tab.
l Anticipated planning and launch dates

l Ignore global exclusion list - Authorized users can enable this option to have outbound
processing of Offers for this Campaign ignore the global exclusion list. Refer to the Exclusion List
chapter for details.
Note: The Campaign's Name, Issue, and Group values cannot be changed once it is created.
Financials
This section includes fields to specify financial metrics for the Campaign. These values typically play
an important role in the approval of the Campaign.
Specifying Goals
The Goals section in the Plan tab enables the user to specify goals for their Campaign. Users can
add up to nine goals. Each available goal is a Key Performance Indicator (KPI) configured on the Visual
Business Director landing page.
The operator displayed between the goal field and the target value automatically toggles (between >=
and <=) depending on whether higher or lower performance of the goal metric is the desirable result.
For example, the Outbound Conversion Rate goal utilizes the >= operator while the Decline Rate goal
utilizes the <= operator.
Similarly, a percentage symbol is displayed alongside appropriate goals.
Selecting a Strategy
The Marketing strategy section in the Build tab enables users to designate a Strategy rule as the
backing strategy for their Campaign.
Clicking the Configure button launches the Configure Marketing Strategy modal window which
lists available Strategies in the system. Usage patterns for this modal window are described in the
Using a Configuration Modal Window appendix.
A sample list entry for a Strategy rule is shown below.

This view includes the following information about the Strategy:
l Friendly name / label
l Rule name
l When the Strategy was last updated
Selecting this Strategy displays further information about it in the details panel.
This view displays the following information about the Strategy:
l Friendly name - Click to open the Strategy rule.
l Description
l Target audience type
l Issue, Group categorization
l List of Offers output by the Strategy. Along with the Offer, icons are displayed for each channel
that the Offer utilizes. Clicking an Offer name opens the Offer rule.
After selecting a Strategy, the user must also select the desired result component to use from the
Strategy. This is done via the Strategy results field in the Marketing strategy section. Once a results
component has been selected, the system displays the Offers that are utilized by the selected
component along with their channel icons. The delete icon can be used to dissociate the selected
Strategy from the Campaign.

Selecting an Audience
The Audience section in the Build tab enables the selection of the desired audience for the
Campaign. Audience selection is optional for certain engagement types. It is required when the
Campaign has scheduled executions. It is also required if customer validation is enabled in an event-
based engagement.
Clicking the Configure button launches the Configure Audience modal window which lists
available Segments in the system. Usage patterns for this modal window are described in the Using
a Configuration Modal Window appendix.
A sample list entry for a Segment rule is shown below.
This view includes the following information about the Segment:
l Rule name
l Total number of customers in the Segment
l Percentage of the total customer population included in this Segment
l When the Segment population was last refreshed
Selecting this Segment displays further information about it in the details panel. This panel displays
the following information for all Segment types:

l Segment image
l Friendly name - Click to open the Segment rule.
l When the Segment rule was last edited
l Number of Campaigns utilizing this Segment
Criteria Segments
The following information is only shown for criteria Segments:
l Number of Segments referenced within this Segment
l List of criteria utilized by the Segment
List Segments
The following information is only shown for list Segments:
l Name of the last imported customer file
l Date and time when this file was imported
l Name of the user who imported this file

Configuring Campaign Engagement

The Engagement section in the Build tab enables the configuration of the modes in which the
Campaign engages with the customers.
Clicking the Configure button launches the Configure Engagement modal window which
presents the following three engagement types:
l Campaign schedule
l Real-Time events
l Real-Time containers
Users can enable multiple engagement types on the same Campaign.
Campaign schedule
This engagement type represents scheduled Campaign execution. Users can configure desired
scheduling options and the system will automatically run the Campaign based on the configured
schedule.
To begin with, the user must select between single or recurring execution.
The following additional configuration is available for the One-time only option:
l Start on – Specify the start date and time for the Campaign execution.
The following additional configurations are available for the Recurring option:
l 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.

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:
Every day
Every weekday - leave days field empty (shown below)
Every X days – specify X in days field
Weekly - The following modes are supported:

Recur every X weeks based off a start date – specify X in weeks field, do not select any week
days
Recur every X weeks on selected days – specify X in weeks field, select week days (as shown
below)
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.
l Start campaign – Select the start date and time for Campaign execution.
l End campaign – Determines when scheduled Campaign execution should end. Select from the
following three options:
No end date
Set number of occurrences - Specify the number of occurrences.
End by a date - Specify the end date and time.

Refreshing Campaign audience
In addition to configuring scheduling options, the user can also determine whether to refresh the
audience for the Campaign as part of the scheduled execution. The user can further opt between
refreshing the population for each run or just for the first run.
Note: The refresh audience option is only available when the Campaign audience is a criteria
Segment.
Direct output to template
For Multi-Channel Campaigns, Pega Marketing provides support for directly outputting the results of
a scheduled run to a configured Database Template rule. In this mode, Offer processing is bypassed.
To utilize this feature, the marketer can enable the Write Campaign results using a database
template check box and specify the desired Database Template rule in the Template field.
Note: This feature requires the Database Template rule to utilize the Append writing mode. The
smart-prompt for the Template field only lists templates that utilize this mode.
After configuring the schedule, marketers can utilize the template link in the Engagement section or
the right overview pane to open the Database Template rule.
Real-time events
This engagement type represents event triggered execution of the Campaign. Refer to the Real-Time
Events chapter for details on creating and triggering Events.

The following configuration options are available for this engagement type:
l Validate that customer is part of audience – If this is enabled, when a Campaign is

triggered by an Event, the customer associated with the Event is validated against the configured
audience on the Campaign. Only if the customer is present in the Campaign's audience, Campaign
execution is triggered.
Note: If the Campaign 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 a part of
the Campaign audience in this scenario.
l Listen for events from/to – Specify the start and, if desired, end date and time values during
which the Campaign will listen for the Events associated to it. Any Event that is received outside of
the specified time frame will be ignored.
Users should use the Add events link to associate Real-Time Events with this Campaign. Clicking this
link launches the Configure Engagement modal window which lists available Real-Time Event
rules in the system. Usage patterns for this modal window are described in the Using a
Configuration Modal Window appendix.
A sample list entry for a Real-Time Event rule is shown below.
This view includes the following information about the Event rule:
l Validity time period
Selecting this Event displays further information about it in the details panel.

This view displays the following information about the Event:
l Friendly name - Clicking the name opens the Real-Time Event rule.
l Whether the Event is active, i.e. available to respond to requests
l List of Geofences that the Event triggers. Clicking the name opens the Geofence rule.
l List of Campaigns that utilize this Event. Clicking the name opens the Campaign.
Clicking Add Event in the modal adds the selected Event to the list of Events associated with the
Campaign.
Users can continue to add more Events to the Campaign following the process prescribed above.
Clicking the delete icon next to an Event removes it from the Campaign.
Note: Volume Constraints and any Contact Policy limitations specified in the Strategy are not
applicable during Event triggered Campaign execution.
Note: The Configuring a Fallback Strategy section provides details on using a fallback Strategy
with Real-Time Events.
Real-time containers
This engagement type allows marketers to expose the results of a marketing Campaign to real-time
channels such as web and mobile. Refer to the Real-Time Containers chapter for more details on
creating and triggering Containers.
The following configuration options are available for this engagement type:

l Listen for container requests from/to – Specify the start and, if desired, end date and time
values during which the Campaign will be valid for the specified Container. If a Container request
is made outside of the specified time frame, this Campaign will not be considered for execution.
Multiple Campaigns can reference a single Container as long as the active listening dates do not
overlap.
Users should use the Add containers link to associate Real-Time Containers with this Campaign.
Clicking this link launches the Configure Engagement modal window which lists available Real-
Time Container rules in the system. Usage patterns for this modal window are described in the Using
a Configuration Modal Window appendix.
A sample list entry for a Real-Time Container rule is shown below.
This view includes the following information about the Real-Time Container rule:
l When the Container was last updated
Selecting this Container displays further information about it in the details panel.
This view displays the following information about the Container:

l Friendly name - Clicking the name opens the Real-Time Container rule.
l Whether the Container is active, i.e. available to respond to requests
l Impression capture setting for the Container
l Click-through behavior setting for the Container
l List of Campaigns that utilize this Container. Clicking the name opens the Campaign.
Clicking Add Container in the modal adds the selected Container to the list of Containers associated
with the Campaign.
Users can continue to add more Containers to the Campaign following the process prescribed above.
Clicking the delete icon next to a Container removes it from the Campaign.
Note: The Configuring a Fallback Strategy section below provides details on using a fallback Strategy
with Real-Time Containers.
Configuring a Fallback Strategy

For Real-Time Events and Containers, Pega Marketing supports defining a fallback Strategy which gets
executed in case the Strategy defined on the Campaign fails. To utilize this functionality, users should
save the FallbackStrategy Strategy rule into their implementation layer and replace the placeholder
Set Property component in this Strategy with the Offer(s) that should be rendered in case of a failure.
Selecting a Constraint
The Constraint section in the Build tab enables users to designate a Volume Constraint rule as the
backing constraint for the Campaign.
Clicking the Configure button launches the Configure Constraint modal window which lists
available Volume Constraints in the system. Usage patterns for this modal window are described in
the Using a Configuration Modal Window appendix.
In the list of entries, the following information is shown for each Volume Constraint:

l Rule identifier
l When the Volume Constraint was last updated
Selecting this Volume Constraint displays further information about it in the details panel.
This view displays the following information about the Volume Constraint:
l Friendly name - Click to open the Volume Constraint rule.
l Scope - Whether constraints defined in the rule are reset individually or as a group
l Grid of Offer constraints - Includes Offer name, minimum, and maximum volumes. Click the Offer
name to open the Offer rule. A check mark next to a row in the grid indicates that the
corresponding constraint is enabled.
l Grid of channel constraints - Includes channel name, minimum, and maximum volumes. A check
mark next to a row in the grid indicates that the corresponding constraint is enabled.
Campaign Approval
Pega Marketing provides supplementary support for incorporating an approval process into the
Campaign lifecycle. This functionality is included in the Marketing Operations module along with

other operational features.
As part of this functionality, Campaigns must be approved before they can be launched.
Implementers of marketing applications can customize the criteria for Campaigns to require
approval. Advanced implementations may even consider customizing the approval flow to better suit
their needs.
In the out-of-the-box process, marketers can perform the following actions:
l Submit Campaign for approval
l Recall submitted Campaign
The marketer's manager can perform the following action:
l Approve or Reject a Campaign
Submitting a Campaign for Approval

The Submit for Approval action enables the user to submit their Campaigns for approval. Most
Campaigns require approval before they can be executed. Users can enter a note along with their
approval request.
The system automatically routes approval requests to the manager of the user’s organizational unit.
In addition to adding the Campaign to the manager’s Work List, the system also notifies the manager
about the approval request via email. This email contains salient Campaign details, the marketer's
note, and a link to directly open the Campaign.
Recalling a Submitted Campaign

After a Campaign has been submitted for approval, no further changes are allowed to the Campaign.
If a user wishes to make further updates to the Campaign, they must first recall the Campaign from
the manager via the Recall action.
Users can enter a note explaining the reason for recalling the Campaign from the manager.
As before, the manager is notified via email when a Campaign is recalled from their Work List. This
email contains the recall note and a link to directly open the Campaign.
Once a Campaign has been successfully recalled, it can be updated and re-submitted for approval
when ready.

Approving and Rejecting Campaigns

Managers need to approve (or reject) Campaigns that are submitted to them for approval. To do so,
the manager can open the Campaign work object either directly from their email (by clicking the
Campaign link) or from their Work List. The Approve and Reject actions enable the manager to take
the corresponding approval action once they have reviewed pertinent Campaign details.
When approving the Campaign, the manager can also enter an approval note. A note is required if the
manager is rejecting the Campaign.
After the manager performs an approval action on the Campaign, the system notifies the user that
submitted the Campaign for approval. This email contains the approval status, manager's note, and a
link to directly open the Campaign.
The approval status and the manager's note are also displayed in the Campaign.
Note: When a Campaign is rejected, the marketer must make updates to its configurations (via the
Edit action) before other actions can be performed on the Campaign.
Campaign Validation
While the Campaign is in the design stage, the marketer can utilize the Validate action from the
Actions menu to validate their Campaign's configurations. Reported violations are categorized into
critical items and warnings. Critical items 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.
The system automatically invokes this same validation routine when the Campaign is tested or run. If
the validation returns any critical items, the user must correct these in order to perform the desired
action. Warnings do not prevent these actions from being taken but should still be individually
heeded and addressed, where necessary.
Campaign Testing
After configuring the Campaign, marketers can utilize the Test tab on the Campaign to test their
configurations and review test results.
Pega Marketing supports two types of Campaign testing:

l Distribution Test
l Seed Test
Note: The above test modes are disabled on Campaigns that utilize the direct output to template
feature.
Distribution Test
A distribution test enables the user to test the execution of a Campaign in terms of assessing the
Offers made and the customers targeted. The result of a distribution test is a series of reports
outlining various distribution metrics. No offers are actually made to customers in this form of
Campaign testing.
The Distribution test link in the Tests section enables the user to initiate a distribution test. This
link is enabled when the following conditions are met:
l Strategy and Strategy result component is selected
l At least one engagement is configured
l Audience is configured
l Campaign isn't utilizing direct output of results using a database template
Clicking this link performs Campaign validation and presents the user with validation violations and
configuration options. The user must resolve all critical violations before they can initiate the
distribution test.
Additionally, the user can enable the following options for the distribution test:
l Refresh the Campaign's audience before executing the test
l Apply the Campaign's Constraint as part of executing the test

Upon clicking Submit, the system initiates a distribution test. An entry for this test is added to the
test runs grid. Users can refresh the Campaign display to view the current status of the test.
Clicking the test row displays various details about the distribution test. Refer to Viewing Run
Details for information on using this view.
The delete icon in the row enables users to remove the corresponding distribution test from the
Campaign.
Seed Test
A seed test enables the user to configure and initiate a simulation of Campaign execution. 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 Interaction History.
The Seed test link in the Tests section enables the user to initiate a seed test. This link is enabled
when the following conditions are met:
l Strategy and Strategy result component is selected
l Campaign isn't utilizing direct output of results using a database template
Clicking this link performs Campaign validation and presents the user with validation violations and
configuration options. The user must resolve all critical violations before they can initiate the seed
test.
For a seed test, the user must simply select a Seed List to represent the audience for the Campaign.
Refer to the Seed Lists chapter for information on creating and configuring Seed Lists.
Upon clicking Submit, the system initiates a seed test. An entry for this test is added to the test runs
grid. Users can refresh the Campaign display to view the current status of the test.

Clicking the test row displays various details about the seed test. Refer to Viewing Run Details for
information on using this view.
The delete icon in the row enables users to remove the corresponding seed test from the Campaign.
Campaign Execution
This section explains the following areas pertaining to Campaign execution:
l Running a Campaign
l Rescheduling a Campaign
l Suspending a Campaign
l Resuming a Campaign
l Stopping all runs
l Stopping a run
l Restarting a run
l Skipping a run
l Campaign execution cycle
Running a Campaign
After the Campaign has been configured and approved, it is ready to be launched. This readiness is
indicated by the availability of the Run action.

Clicking the Run button or selecting the Submit for Execution action from the Actions menu
performs Campaign validation and presents the user with any reported validation violations and run
configuration options. The user must resolve all critical violations before the Campaign can be
launched.
From this screen, the user can configure the desired engagement types for the Campaign. The
options available in this screen are explained in the Configuring Campaign Engagement section.
The user must select at least one engagement type in order to launch the Campaign.
After configuring the desired engagement type(s) for the Campaign, users can click Confirm to
launch the Campaign. Upon doing so, the system generates artifacts necessary for Campaign
execution and transitions the Campaign to the running stage.
Note: After submitting a Campaign for execution (and while it is still running), 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 Campaign. Examples
of these changes include modifying the Strategy's result component and adding Segment usage
within Strategies. After making the desired structural change, the Campaign must be updated and
resubmitted for execution.
Rescheduling a Campaign
Marketers can utilize the Reschedule action (in the Actions menu) if they need to modify the
schedule of a running Campaign. The new schedule will apply only to upcoming runs and does not

impact any runs that are currently running. All upcoming runs for the Campaign are suspended while
this action is in progress.
The configuration options available for the Reschedule action are explained in the Configuring
Campaign Engagement section. However, during this action the user can only make updates to
schedule-related configurations. They can not enable or disable engagement types, or modify
associated Events or Containers. To make such changes, the user must first suspend the Campaign.
Once the user completes the Reschedule action, the previous set of upcoming runs is removed and a
new set of upcoming runs is generated based on the newly specified schedule.
The system also notifies the user who submitted this Campaign for execution. The notification email
contains a link to the Campaign and relevant schedule information, such as the next scheduled run
time.
Suspending a Campaign
Marketers can utilize the Suspend action (from the Actions menu) if they need to suspend a running
Campaign. An important use case for this action is when the marketer needs to make modifications
to the Campaign's configurations, such as its audience or Strategy.
Suspending a Campaign prevents any upcoming runs from executing. When performing this action,
the marketer must enter a note.
Upon completion of this action, the system transitions the Campaign back to the design stage and
notifies the user who launched the Campaign that it has been suspended. The notification email
contains the marketer's note and a link to open the Campaign.
Resuming a Campaign
Marketers can utilize the Resume action (from the Actions menu) to resume a suspended
Campaign. This action is only available if the marketer hasn't modified the Campaign after it was
suspended.
When performing this action, the marketer can determine what the system should do to scheduled
runs.
l Resume all unexecuted campaign runs - In this option, all runs that were not executed will be
resumed. This will also include all runs that are now in the past. Campaign execution will start with
the earliest run (that was not executed) 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.
l Remove all past unexecuted campaign runs - In this option, any run that is not executed but in
the past will be removed. This option basically provides a mechanism for ignoring (skipping over)
runs that are in the past and resuming Campaign execution with the next run, i.e. one that is
scheduled to execute on or after today.
l Remove all past unexecuted campaign runs except the last - In this option, all past runs that
were not executed will be removed with the exception of the last one. This option will execute the
last run immediately on submission and then follow the rest of the upcoming Campaign schedule.
Regardless of the option selected above, the system displays the list of runs that will be resumed so
that the marketer can see the impact the various resumption options will have on Campaign
execution. The marketer can enter a note when they resume the Campaign.
Upon submission of this action, the system transitions the Campaign back to the running stage and
notifies the user who launches this Campaign for execution that it has been resumed. The notification
email contains a link to open the Campaign.
Stopping All Runs

The Stop all runs action (in the Actions menu) enables marketers to stop all active runs of the
Campaign.
Upon initiating this action, the system presents the user with a list of all runs that will be stopped.
The user must enter a note detailing why the stop action was selected.
Upon submission of this action, the system issues stop requests for each of the listed runs. The
system will halt run processing (if possible) at the earliest possible instance. When the system
successfully stops a run, a notification email is sent to the user who submitted the Campaign for
execution.
Stopped runs can then be individually restarted or skipped by selecting the appropriate action from
the runs grid in the Campaign display.
Stopping a Run
At times, marketers may wish to stop an individual Campaign run. To do so, they can utilize the Stop
link in the row for the desired run in the Run schedule section. The marketer can also enter a note
along with the stop request.

Upon submission of this action, the system will attempt to halt run processing at the earliest possible
instance. Once the system successfully stops the run, a notification email is sent to the user who
submitted the run's Campaign for execution. The system also assigns the run to this user by adding it
to their work list. The user must act on this stopped run, i.e. perform either restart or skip, in order
for the Campaign to be eligible for wrap-up and completion.
Restarting a Run
The Restart action enables marketers to re-initiate a failed or stopped run. Marketers can utilize this
action after taking necessary steps to address the failure or stoppage of the previous run.
To perform this action, marketers can utilize the Restart link in the row for the desired run in the
Run schedule section. The marketer can also enter a note along with the restart request.

Upon submission of this action, the system automatically skips the current run. The system then
initiates a new run and starts processing it. The user will initially see the previous run in their run
schedule with a skipped status. When the user refreshes (or reopens) the Campaign, the skipped run
will be removed and the newly created run will display along with its current status.
As part of this action, the system also notifies the user via email that the run has been restarted.
Skipping a Run
The Skip action enables marketers to ignore a failed or stopped run. To perform this action,
marketers can utilize the Skip link in the row for the desired run in the Run schedule section. The
marketer can also enter a note along with the skip request.
Upon submission of this action, the run is initially displayed in the run schedule with a skipped
status. When the user refreshes (or reopens) the Campaign, the skipped run will no longer be
displayed in the run schedule.
As part of this action, the system also notifies the user via email that the run has been skipped.
Campaign Execution Cycle

The life cycle of the Campaign's execution (i.e. running) stage depends on the individual execution
cycles for each of its configured engagement types. Once each of these types have completed their
execution cycles, the Campaign moves to the wrap-up stage.

Scheduled execution
The system generates the execution schedule for the Campaign and then waits for the execution time
of the first scheduled run. As a run completes, the system schedules the next run and repeats this
process until all runs are complete.
Note: For Campaigns where the end date is not specified, the system generates the upcoming
schedule for the first ten runs. It will add the next set of runs to the upcoming schedule when there
are fewer than five runs remaining. The application administrator can use the Application Settings
landing page to configure the number of runs the system generates at a time.
Once all scheduled runs of a Campaign are complete, the scheduled execution cycle is also
considered to be complete.
Event-enabled execution
The system listens for configured Events during the configured time frame. If an end time is
configured for the window, the Campaign stops listening for the Event once the end time is reached.
At this point, the event execution cycle of the Campaign is considered to be complete.
Container-enabled 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 Campaign once the end time is reached. At this
point, the container execution cycle of the Campaign is considered to be complete.
Campaign Monitoring
This section includes the following topics pertaining to Campaign monitoring:
l Monitoring Campaign Performance
l Viewing Run Details
Monitoring Campaign Performance

Once a Campaign is in its running stage, the Campaign display switches to the monitoring view. This
view includes the following sections which aid marketers in monitoring various aspects of their
Campaigns.

l Campaign overview
l Performance
l Run schedule
l Goals
Campaign overview
This section provides a visual representation of how the Campaign is performing since the start of its
execution across the following salient metrics:
l Total impressions
l Click-through rate
l Conversion rate
The key usage aspects of the chart in this section are:
l The x-axis represents time from the start of Campaign execution till its end, or till the current day
if the Campaign is still running.
l The left y-axis corresponds to the impressions metric, while the right y-axis corresponds to the
two rate metrics.

l Hovering over a data point in the chart displays details about the corresponding metric value.
l Clicking the metric name in the legend toggles the display of the metric's line chart.
Performance
This section lists both cumulative and individual metrics pertaining to the Campaign's overall
performance.
The metrics displayed in the boxes are cumulative across the execution cycle of the Campaign. The
following metrics are displayed:
l Offers - Number of distinct Offers utilized during Campaign execution
l Impressions - Total number of impressions for this Campaign
l Click-throughs - Overall click-through rate of this Campaign
l Conversion - Overall conversion rate of this Campaign
l Offers Initiated - Total number of Offers initiated during Campaign execution
The Details sub-section below the boxes presents a drill-down view of the above metrics for each
Offer that was utilized by the Campaign. Clicking the Offer name opens the corresponding Offer rule.
Run schedule
In the monitoring view, the Run schedule section displays two grids - one for initiated runs and the
other for upcoming runs.

Initiated runs
This grid lists each initiated Campaign run with the most recent run at the top. Each run row in the
grid contains the following:
l Date and time when the run started its execution
l Number of Offers initiated by the run
l Status of the run - typical values are Scheduled, Running, Completed, Failed
l Links for available actions

When running, available action is Stop
If failed, available actions are Restart and Skip
Additionally, users can click the run's row to see a detailed view of the run. Refer to Viewing Run
Details for information on using this view.
Upcoming runs
The Upcoming grid displays the date and time of upcoming runs for the Campaign.
Goals
This section displays the performance of the Campaign against the goals configured by the marketer.
At a high level, the overall goal achievement status for the Campaign can have one of the following
values:

l Goals Met - When at least half of all configured goals have been met
l Goals Missed - When less than half of configured goals are met (as shown above)
l Goals Not Set - When no goals have been configured for the Campaign
For each configured Campaign goal, the system shows current value and the target goal value. The
current value displays in green if the corresponding goal has been met.
Viewing Run Details

Clicking a row for an initiated Campaign run, distribution test, or seed test presents an expanded
view which contains details about the specific run. Users can click the row again or click Close to
collapse this view and return to the grid view.
To begin with, the section provides an overview of the execution stages and the progress of the run
through these stages. This view contains the following three boxes:
l Audience - This box displays the number of customers that make up the run's audience.
l Marketing Strategy - This box displays the number of Offers that were identified by the
Campaign's Strategy and the number that were actually initiated by the system. These numbers
may be different if the Campaign also utilizes a Constraint, as shown in the example above.
Note: For distribution tests, this box only shows the number of Offers identified by the Strategy
since distribution tests do not initiate Offers.
l Result - This box shows the overall result of the run (or test).
Each of the above boxes also include the date and time when the corresponding stage was
completed.
Additionally, the color of a box visually indicates the status of the corresponding stage.
l White - Stage is yet to be started
l Blue - Stage is currently in progress
l Gray - Stage has completed
l Green - Run has successfully completed. Only shown on the result box.
l Yellow - Run has completed, but with Offer failures. The number of failures is also displayed. Click

the link to launch a report that shows error details. Only shown on the result box.
l Red - Run has failed. Only shown on the result box.
The usage of these colors is demonstrated by the following failed run.
The stage progress colors aid in depicting that the run has failed during the strategy phase (blue). The
error message at the top provides more details on the failure and suggests steps that the marketer
can perform to rectify the situation.
The Offers grid displays the list of distinct Offers initiated as part of the run (or test) along with their
instantiated counts. Clicking an Offer name in the grid opens the corresponding Offer rule.
When the run includes Offer bundles, there are additional rows in the grid for bundled members and
the Bundle member count column displays the count of each initiated member.

Clicking the Reports link at the bottom displays the distribution reports that were generated as part
of the run (or test).
Campaign Completion
This section includes the following topics pertaining to Campaign completion:
l Wrapping up a Campaign
l Archiving a Campaign
l Restoring a Campaign
l Reopening a Campaign

Wrapping up a Campaign
When a Campaign completes its execution cycle, it moves to the wrap-up stage. In this stage, the
marketers can utilize the Wrap-up button or the Wrap-up action (in the Actions menu) to complete
the Campaign.
As part of this action, the marketer can enter any additional remarks on the Campaign and classify it
based on its outcome into one of four categories: Successful, Not successful, Neutral, or Not
specified.
Upon submission of this action, the Campaign transitions to the completed stage. Users can no
longer make any edits to this Campaign.
Archiving a Campaign
Once a Campaign is complete, the marketer can use the Archive button or the Archive action (in the
Actions menu) to archive the Campaign. Once the Campaign is archived, it will not appear (by
default) in the list of Campaigns on the Campaigns landing page.
To view archived Campaigns in the Campaigns landing page, the marketer should set the Status
filter to Archived and then click View.

Restoring a Campaign
The Restore action (in the Actions menu) enables the marketer to move an archived Campaign back
to the stage it was in before being archived, i.e. either the completed or the wrap-up stage. Once the
Campaign is restored, it will be visible in the list of Campaigns on the Campaigns landing page.
Reopening a Campaign
The Reopen action (in the Actions menu) enables the marketer to revert a completed Campaign
back to the wrap-up stage.

Chapter 5: Outbound Campaigns

For advanced marketing initiatives, Multi-Channel Campaigns 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 Outbound Campaign construct provides
just this functionality using a visual card paradigm that highlights all aspects of the initiative on a
single canvas. This allows marketers to focus on key aspects, such as the Audience, the Offer, and the
Flow.
High-level features of the Outbound Campaign functionality include the following:
l Simplified canvas, which includes all details in single view
l Visual ‘card’ paradigm for easier building
l Traceable goals and the ability to monitor their performance
Outbound Campaigns have a lifecycle of their own and go through various stages. These stages are
outlined in the Outbound Campaign Lifecycle section. The remaining sections in this chapter
outline the various interactions available to the user. These interactions include the following:
l Creating an Outbound Campaign
l Configuring an Outbound Campaign
l Validating an Outbound Campaign
l Running an Outbound Campaign
l Monitoring Outbound Campaign Goals
l Wrapping up an Outbound Campaign
l Other Outbound Campaign Actions
Outbound Campaign Lifecycle

Each Outbound Campaign has a lifecycle and goes through various stages along this lifecycle. The
user can perform appropriate actions on the Outbound Campaign at some of these stages.
Performing an action on the Outbound Campaign may move to it a different stage. The following

graphic illustrates the stages in the Outbound Campaign lifecycle and the actions that can be
performed by the user at each stage.
The stages in the Outbound Campaign lifecycle are:
l New – Initial stage, Outbound Campaign is yet to be saved
l In Design – Outbound Campaign has been created and is in design
l Scheduled – Outbound Campaign is pending the scheduled run time
l Running – Outbound Campaign is currently running
l Awaiting Wrap-Up – Outbound Campaign has completed running and is available for wrap-up
l Failed – Outbound Campaign has failed. Actions in this stage are similar to those in the design
stage.
l Completed – Outbound Campaign has been wrapped-up
l Archived – Outbound Campaign has been archived
l Withdrawn – Outbound Campaign has been withdrawn

Creating an Outbound Campaign

Outbound Campaigns are listed alongside Multi-Channel Campaigns on the Campaigns landing page.
This landing page is accessed in the Pega Marketing portal via the Campaigns link in the left
navigation.
To create a new Outbound Campaign, users should select the Create Outbound Campaign item in
the Create button menu on the Campaigns landing page.
Upon creation, a new Outbound Campaign resembles the following:

Configuring an Outbound Campaign

Marketers can start configuring the Outbound Campaign right from the Create a Campaign
screen. Once the Outbound Campaign has been created, they can use the Edit button to go into edit
mode and make further updates to the Outbound Campaign’s configurations. This section provides
details on the various aspects of configuring the Outbound Campaign. This includes the following:
n Specifying Details
n Selecting the Audience
n Selecting the Offer
n Selecting the Flow
n Specifying Goals
Specifying Details
The Campaign details section contains various details about the Outbound Campaign, such as its
name, issue/group information, objectives, planned start date, and basic financial information. The
Name, Issue, and Group can’t be modified after the Outbound Campaign has been created.
Note: The Outbound 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).
The user can utilize the Campaign Image field to associate an image with the Outbound Campaign.
This image will be displayed in the card for the Outbound Campaign in the Campaigns landing page.
In addition to basic information, marketers can also add tags to their Outbound Campaigns. Tagging
is available once the Outbound Campaign has been created.
Currently, tagging allows the marketer to further classify the Outbound Campaign as desired. In
future iterations of the product, the tagging capabilities may be further enhanced to allow for tag-
based searching.

Authorized users can enable the Ignore global exclusion list option to have processing of Offers
for this Outbound Campaign ignore the global exclusion list. Refer to the Exclusion List chapter for
details.
Selecting the Audience

A key element of Outbound Campaigns is the audience, which is the set of individuals the user plans
to target with their marketing message. Audience selection in Outbound Campaigns utilizes the
Segment rule, which can be used by the marketer to hone in on their desired audience. When
configuring an Outbound Campaign, the marketer can review their existing Segments (along with
pertinent details) right from the Outbound Campaign canvas. The marketer can also create a new
Segment and reference it in the Outbound Campaign.
The Audience card in the Outbound 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 Configure Audience 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.
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 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 Configure Audience modal
displays further details about the selected Segment. This includes the following common information
for all Segment types:
l Segment image
l Friendly name - Click to open the Segment rule.
l When the Segment rule was last edited

l Number of Campaigns (both multi-channel and outbound) that are using this Segment as their
audience
The following information is only shown for criteria Segments:
l Number of Segments that the selected Segment references
l List of criteria utilized by the Segment
The following information is only shown for list Segments:
l Name of the last imported customer file
l Date and time when this file was imported
l Name of the user who imported this file
To complete the selection process, click the Add button to denote the selected Segment as the
Outbound 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. The user can then select a different Segment using the process
outlined above.

Selecting the Offer

Next, the marketer can select the Offer they want to use in their Outbound Campaign. The Offer
portion of the Outbound 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 Outbound Campaign canvas. They can also create a new
Offer and reference it in the Outbound Campaign.
The Offer card in the Outbound Campaign canvas displays the currently selected Offer and its details.
Initially, this card is empty as shown below:
Marketers can click anywhere in the card to launch the Configure 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.

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 Configure 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 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. Users can click the treatment name to open the associated treatment rule.
To complete the selection process, click the Add button to denote the selected Offer as the Outbound
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.
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 Pega Marketing, the Offer and Flow cards are inter-related 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.
Selecting the Flow

Finally, the marketer can select the Flow they want to use in their Outbound Campaign. The Flow
determines the means in which the Outbound 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 flow-centric information and provides a
different view to the marketer. The Flow card in the Outbound 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 Configure 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.
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 Outbound 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.

Specifying Goals
The Goals section of the Outbound Campaign allows marketers to define goals for their Outbound
Campaigns and to monitor the performance of these goals once the Outbound Campaign is running.
When the Outbound Campaign is in edit mode, the Manage goals link is available in this section.
Clicking this link launches a modal dialog that marketers can use to specify various goals for their
Outbound Campaign. Initially, this modal contains a single row for the Outbound Conversion Rate
metric.
Users can specify up to nine goal metrics. Each of these metrics is a Key Performance Indicator (KPI)
configured on the Visual Business Director landing page. Clicking Apply adds all goals with target
values to the Outbound Campaign.
The Goals section displays all goals that have been configured for the Outbound Campaign. Users
can continue to make changes to these goals and their target values while the Outbound Campaign is
in design mode. Once the Outbound Campaign is launched, these goals can no longer be edited.
Validating an Outbound Campaign

The marketer can utilize the Validate action from the Actions menu to validate their Outbound
Campaign. This action enables the user to validate the various configurations that they provided for
the Outbound Campaign. Any violations are categorized into critical items and warnings. Critical
items denote violations that will prevent the Outbound Campaign from being launched. Warnings
represent best practice violations and other scenarios which may potentially impact Outbound
Campaign execution.

The user can use the edit link to make any necessary updates to the Outbound Campaign.
Running an Outbound Campaign

Once the user is satisfied with their Outbound Campaign’s configurations, they can launch the
Outbound Campaign via the Run button or the Run action in the Actions menu.
When this action is initiated, the system automatically performs Outbound Campaign validation and
reports the validation results to the user. The user must address any validation errors before the
Outbound Campaign can be launched. Warnings do not prevent the Outbound 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 Outbound Campaign. The
user can choose to run the Outbound Campaign right away or schedule it for a time in the future. The
system pre-populates the scheduled run time with the Outbound Campaign's Planned Start Date, if it
is set.
The user can also choose to refresh the audience for the Outbound Campaign before it is run.

Note: The refresh audience option is only available when the audience of the Outbound Campaign
is a criteria Segment.
After the user completes this action, the Outbound Campaign status switches to either Running or
Scheduled based on the run option that was selected. The Outbound Campaign Status card displays
this information along with the Outbound Campaign run duration (if running) or the scheduled
Outbound Campaign start time (if scheduled).
Monitoring Outbound Campaign Goals

Once the Outbound Campaign enters the running stage, the system tracks its performance and stores
relevant information in Interaction History (IH). If the user specified performance goals on the
Outbound Campaign, they can monitor these goals as the Outbound Campaign progresses.
The Goal performance section displays relevant metrics both for the Outbound 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. Target goal value – Set by the user as part of designing the Outbound Campaign
Goal metrics are fetched each time the Outbound Campaign is refreshed or re-opened. To get the
latest metric values, the user can simply refresh the Outbound Campaign.
Wrapping up an Outbound Campaign

Once an Outbound Campaign has finished running, the user can perform one of the following
actions:
l Edit – This action allows the user to update Outbound Campaign details and enter actual values
for data collected and other pertinent information about the Outbound Campaign and its
outcome.
l Wrap-Up – This action allows the user to complete the Outbound Campaign and is available in
the Actions menu. The user must select a value for the Outbound Campaign’s outcome and can
enter an outcome note as well.

Upon completion of this action, the Outbound Campaign moves to the Completed stage.
Other Outbound Campaign Actions

This section provides details on the following additional actions that a user can perform on their
Outbound Campaign:
l Reschedule
l Suspend
l Withdraw
l Archive
l Restore
l Reopen
Rescheduling an Outbound Campaign

When the Outbound Campaign is in the scheduled stage, the user can update its run time (if desired)
by utilizing the Reschedule action from the Actions menu. The Outbound Campaign is once again
validated and the user is presented with the same configuration options as the Run action. Upon
completing this action, the Outbound Campaign moves to either the running or the scheduled stage
based on the run option that was selected.

Suspending an Outbound Campaign

If the user desires to make changes to a scheduled Outbound Campaign, they must first suspend it.
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 Outbound Campaign, the system sends an email to the user that launched
the Outbound Campaign notifying them of the Outbound Campaign’s suspension. This email also
includes the note that was entered.
Suspending an Outbound Campaign returns it back to the In Design stage. The user can make further
modifications to the Outbound Campaign before running it.
Withdrawing an Outbound Campaign

While the Outbound Campaign is in either the design or the failed stage, the user can also withdraw it
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.

Withdrawing an Outbound Campaign moves it to the withdrawn stage. No further actions are
available on this Outbound Campaign. The user can still utilize the Save as button to create a copy
of this Outbound Campaign. The Outbound Campaign is also no longer listed (by default) in the
Campaigns landing page. To view withdrawn Outbound Campaigns, users can set the Status filter
on this landing page to Withdrawn.
Archiving an Outbound Campaign

Once the Outbound Campaign has finished running, the user can archive it via the Archive button or
the Archive option in the Actions button menu. Archiving an Outbound Campaign moves it to the
completed stage. The Outbound Campaign is also no longer listed (by default) in the Campaigns
landing page. To view archived Outbound Campaigns, users can set the Status filter on this landing
page to Archived.
Restoring an Outbound Campaign

To restore an archived Outbound Campaign, the user can utilize the Restore button or the Restore
option in the Actions button menu. Restoring an Outbound Campaign moves it back to the stage it
was in before being archived.
Reopening an Outbound Campaign

To reopen a completed - either wrapped-up or restored - Outbound Campaign, the user can utilize
the Reopen button or Reopen option in the Actions button menu. Re-opening an Outbound
Campaign places it back in the awaiting wrap-up stage.

Chapter 6: Segments
Chapter 6: Segments
Segments identify a group of customers to use as audience in Campaign and scheduled Next-Best-
Action processing. You can also use Segments on the decision strategy canvas to filter offers based on
a Segment or audience.
The following types of Segments are supported:
l Creating a Criteria Segment
l Creating List Segments
Creating a Criteria Segment

With Criteria Segments, marketers can define one ore more conditions that must be true before a
customer can be part of audience.
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 Marketing solves this issue
through the use of intelligent segmentation. Intelligent segmentation uses statistical analysis to
discover predictors within the customer data that contribute positively towards a targeted outcome,
for example, the purchase of a product. For more information about intelligent segmentation, see
Intelligent Segmentation.
1. Click Audiences > Segments.
2. Click Create.
3. Enter a Description for the new Segment.
4. In the Segment subject section, select Customer.
Note: If you want to create a Prospect Segment instead, see Prospect Segments. Prospect
Segments are Segments which group potential customers.
5. In the Type section, select Criteria.
6. Optional: If you have an Analysis Project which you want to use in this Segment, select it from the
Analysis Project drop-down list. For more information, see Configuring Analysis Projects.
7. Click Create and Open .

Chapter 6: Segments
8. Add criteria groups to your Segment. For more information, see Designing Criteria Segments.
9. Click Save. The Criteria Segment is saved and checked in.
10. Click Run to populate the Segment with the current set of customers. You can click Stop to stop
the Segment execution, or continue with other work while the Segment populates. After Pega
Marketing finishes populating the Segment, the total number of customers in this Segment is
displayed in the Population count field.
11. Optional: To automatically refresh your Segment, configure a schedule. For more information, see
Optional: Configuring Criteria Segment Runs.
Once a Segment is created, you can view it in the Segments landing page. For more information, see
Managing Segments.
Designing Criteria Segments

Note: This section describes the default method of designing Criteria Segments. If required, you can
also build a Criteria Segment by using a legacy non-visual rule form. For more information, see
Designing Criteria Segments by Using a Rule Form.
To design a Criteria Segment, add one or more criteria groups. A group is a container for multiple
criteria that can be combined together to represent a desired logical grouping of the population.
These groups are evaluated from top to bottom and can be organized into sets.
1. In the Design tab of a Criteria Segment, click Add group.
2. Click Add criteria.
3. Provide values in the fields on the following tabs:
l Analysis project - Lists all the predictors available in the Analysis Project. This is only
available when you associate an Analysis Project with the Segment and run the Analysis Project
at least once.
Recommendations - Lists the best performing predictors from the modeled analysis for
the selected Analysis Project. That is, it shows the predictors which are the most effective at
predicting the required outcome.
Modeled fields - Lists all the predictors available in the Analysis Project that have been
assembled during the execution of the modeled analysis. By default, the predictors are

Chapter 6: Segments
sorted by the Performance column. The predictors which are the most effective at
predicting the required outcome are displayed on top of the list.
Static fields - Lists the set of static attributes from the Analysis Project which have been
processed as part of static analysis execution. The Group column displays the number of
groupings for the predictor. The Count column displays the number of items across all
groupings for the predictor.
For more information about Analysis Projects, see Configuring Analysis Projects.
l Data fields - This tab allows you to select the customer data fields which you want to use as
criteria in your Segment. Use the Search box to look for specific data fields, or scroll through
the list of available fields. The following types of data fields are available in this tab:
Customer - data fields for customer properties, for example CustomerType or

Customer Lifetime Value.
Customer > History - data fields for customer history, for example the Outcome of an
interaction with the customer.
You can also configure other associated data entities which should be available in this tab,
for example Customer > Address. To configure additional data entities, go to
Configuration > Settings > Application Settings > Manage Data Relationships.
l History fields - This tab allows you to select the criteria related to treatment and offer
responses. For example, you can use the Received offer via channel during a time
period to look for customers who were sent an email with an offer within the last two weeks.
l Segments - This tab allows you to select other Segments as criteria within this Segment. For
example, you can select which existing customer Segment should be excluded from this
Segment by selecting the existing Segment as a criterion and then clicking Exclude. Selecting a
Segment criterion automatically includes or excludes all customers in that Segment.
4. Click any criteria to add them to the criteria group. For example, if you want the Segment to
include only customers above a specific Customer Lifetime Value, add the Customer Lifetime
Value criterion and then enter a Greater than value. Depending on the criteria type, you may
need to specify additional settings. For more information, see Criteria Types.
You can add up to 26 criteria to a criteria group. By default, the criteria are applied with an
AND logic. For example, you can look for customers with Customer Lifetime Value greater than
100 000 AND located in the United States.

Chapter 6: Segments
5. If you want to change the relationship between some criteria to OR, edit the value in the Logic
string field. For example, you can configure the criteria group to look for customers who match
both criterion A AND criterion B, OR criterion C.
6. Optional: To remove a criterion from the logic string and the Segment, click the Delete icon .
7. Click Add group to add another criteria group, if needed. You can add multiple criteria groups
and combine them by using the following actions:
l Start with – Selects customers in the top group to be combined with the actions of the other
criteria groups.
l Intersect – Includes customers that meet the group’s criteria in the Segment population. This
action is available for groups other than the first.
l Exclude – Removes customers that meet the group’s criteria. This action is available for all
groups.
l Merge – Adds customers matching the criteria to the Segment. These customers do not have to
meet the criteria that is specified in the preceding groups. The Merge action removes the
duplicate customers that would be added to the Segment. The Merge action is available for

Chapter 6: Segments
groups other than the top group.
The WATERFALL COUNT field reflects the flow of customers through Segment criteria groups.
8. Optional: To rename a criteria group, double-click on the group name.
9. Optional: To remove a criteria group, click Actions > Remove.
10. You can also organize criteria groups into separate sets for easier viewing. Click the + icon to add a
new criteria set.
11. Optional: To rename a set, double-click on the set name.
12. Optional: To remove a set, click X by the set name.
Criteria Types
The configuration options for a criterion depend on the criteria type. The following criteria types are
supported:
l Analysis project > Modeled fields
Histograms
Categoricals
Long Categoricals
l Analysis project > Static fields
Categoricals
Long Categoricals
l Data fields
Strings

Chapter 6: Segments
Numbers
Dates and Times
Histograms
A histogram displays a numerical property which produced meaningful analysis information during
modeled analysis execution.
The following information is available in a histogram:
l Performance - The predictive power of this criterion.
l The grouping of the analyzed data, displayed as individual columns of the histogram. Ranges for
the groupings are displayed as labels on the horizontal axis.
l The percentage of the overall population within the group, represented by the height of each
column. Percentage values are displayed as labels on the left vertical axis.
l The propensity of individual groups, represented by the red performance line. Propensity is the
ratio of the number of positive responses to the total number of responses. The propensity values
are displayed as labels on the right vertical axis.
Click on a column to select or deselect groupings. You can select multiple groupings for the criterion.
The system selects the column with the highest propensity by default.
Pega Marketing uses the range values associated with each group to compose queries against the
customer source. It treats the left edge of a range as greater than or equal to (>=) and the right
edge as less than (<) in its queries.

Chapter 6: Segments
Categoricals
The categorical criteria editor is used for the following criteria types when they have no more than
eight groupings:
l Symbolic modeled analysis criteria
l Numeric and symbolic static analysis criteria
The following information is available:
l Performance - The predictive power of this criterion.
l The percentage of the population within the group, represented by the length of each bar.
Percentage values are displayed as labels on the bottom horizontal axis.
l The propensity of individual groups, represented by the red dots. Propensity is the ratio of the
number of positive responses to the total number of responses. The propensity values are
mapped to the top horizontal axis. This information is only available for modeled analysis criteria.
l Range - Symbols in this group. To see this information, move your mouse over a bar or a
propensity dot. The information is displayed as a tool tip.
l People(%) - Percentage of population (based on Sample data) in this group. To see this
information, move your mouse over a column. The information is displayed as a tool tip.
l The predictive power of this group. To see this information, move your mouse over a propensity
dot.
Click on a bar to select or deselect groupings. You can select multiple groupings, including Missing.
For modeled analysis criteria, the system selects the bar with the highest propensity by default.

Chapter 6: Segments
Pega Marketing uses the symbols associated with each group to compose suitable queries for this
criterion. When multiple symbols exist in a group, the system will query for all present symbols. For
the Missing group, the system translates the query to search for where the criterion value is null.
Long Categoricals
If the number of elements for a categorical criterion is greater than eight, it becomes impractical to
visualize this criterion as a bar chart. Instead, the criterion is displayed as a long categorical.
Click Select items to open a pop-up window with a list of groupings for the criterion. You can select
one or more groupings.
The following information is available:
l Name - Name of the grouping
l Count - Number of items in the grouping
l Percent - Percentage of items (based on Sample data) in the grouping.
Strings
The string criteria editor is used for text criteria available on the Data fields tab.
The following operators are available for string criteria:
l Contains
l Starts with
l Ends with
l Search Exact
l Is null

Chapter 6: Segments
l Count - For more information, see Aggregating Data
l In list - For more information, see Selecting Criteria Values from a List
The following additional options are available:
l Exclude – Negate the current condition
l Include missing values – Include results that do not have a value specified for the selected
criterion
l Ignore case – Perform a case-insensitive search
Numbers
The number criteria editor is used for numerical criteria available on the Data fields tab.
The following operators are available for number criteria:
l Between
l Greater than
l Greater than or equal to
l Less than
l Less than or equal to
l Equal to
l Missing value
l Count - For more information, see Aggregating Data
l In list - For more information, see Selecting Criteria Values from a List
criterion

Chapter 6: Segments
Dates and Times
The date and time criteria editor is used for date and time criteria available on the Data fields tab.
Use it to configure criteria for a range of dates and times or perform standard comparison tests
against date and time values.
The following options are available for date and time criteria:
l Date - Configure only dates for this criterion
l Date & Time - Configure both dates and times for this criterion.
l Time - Configure only times for this criterion.
l Missing value- Search for instances where this criterion value is null.
l Relative date - Search for instances of this criterion value using date operators relative to the
current date. The following operators are available for relative date comparison:
More than - Use this option to search for instances where this criterion is strictly more than X
days before today (i.e. X + 1 days before or earlier).
At least - Use this option to search for instances where this criterion is at least X days before
today.
In exactly - Use this option to search for instances where this criterion is exactly X days after
today. To search for days before today, specify a negative value for Days. For example, use -X
days with this option to search for instances where this criterion is exactly X days before today.
In more than - Use this option to search for instances where this criterion is at least X days
after today.
In at least - Use this option to search for instances where this criterion is strictly more than X
days after today (i.e. X + 1 days after and later).
In last - Use this option to search for instances where this criterion is within the last X days.
In next - Use this option to search for instances where this criterion is within the next X days.
l Occurrences - For more information, see Aggregating Data

Chapter 6: Segments
criterion
Aggregating Data
For string, number, and date and time criteria fields that belong to a repeating structure (such as a list
of purchases), you can select the Occurrences search operator to aggregate the criteria values.
1. Select the Occurrences search operator to display input fields for the comparison operator and
the comparison value. The following example criteria targets all customers that have more than
thirty Interaction History records.
2. Click Add additional criteria to specify additional criteria for the aggregation. Each additional
criterion must be on the same parent entity as the original criteria being aggregated.
3. After selecting the additional criteria, fields relevant to the criteria type are displayed. Use these
fields to configure the additional criteria. The additional criteria are combined using AND logic. The
following example targets all customers that have had more than five outbound email

Chapter 6: Segments
communications.
Note: Aggregation using the Occurrences operator is only available for first-level entities, that is,
those entities that are directly associated with the customer class and not nested under other
associated entities.
Selecting Criteria Values from a List
For string and number criteria available on the Data fields tab, you can select the In list search
operator to view, search for, and select filter values for the criterion from a list of possible values.
The items grid in the criteria editor lists the values that are currently selected for the criterion.
1. Select the In list search operator, and then click Select items to open the Select items dialog
box.
2. To find specific values, enter the search text in the Search field, and then click the search icon.
3. To add or remove individual items, select or clear the check box next to an item. You can select or
clear multiple items.
4. To add or remove all items, click Select all or Deselect all.
5. To exclude customers from the results who have any of the selected values as their value for the
criterion, select Exclude.
6. To include customers that do not have a value specified for the selected criterion, select Include
missing values.
7. Click Apply.

Chapter 6: Segments
Designing Criteria Segments by Using a Rule Form

In this approach, you provide a series of criteria by identifying the appropriate column, the
relationship type, and the value for which to search. These criteria are then combined in the Filter
conditions field to allow the user to describe the logic for applying the various criteria.
Note: This approach to designing Criteria Segments is deprecated. If possible, design all Segments
using the standard approach. For more information, see Designing Criteria Segments.
1. On the Design tab of a Criteria Segment, click the rule form icon .
2. In the rule form, click Add filter.
3. In the Column source field, enter or select the property which you want to use as a criterion.
4. In the Relationship list, select the operation that evaluates the property and value.
5. In the Value field, enter the required value of the property.
6. Use the gear icon to add filter options, such as Ignore case and Use null if empty.
7. In the Filter conditions to apply field, define the relationship between the criteria. By default,
the criteria are applied with an AND logic. If needed, you can change the relationship between
some criteria to OR.
8. Optional: Select other Segments as criteria within this Segment. Selecting a Segment criterion
automatically includes or excludes all customers in that Segment.
a. In the Segments section, click Add Segment.
b. Select the Segment from the SEGMENT NAME list.

Chapter 6: Segments
c. In the IN / NOT IN list, select whether the new Segment evaluates customers who are in or
not in the existing Segment.
d. In the Filter Segments field, define the relationship between the Segments.
9. Click Save.
Optional: Configuring Criteria Segment Runs

In the Options and Schedule tab of the Segment, you can configure various options for the
Segment and schedule its execution. All settings in this section are optional and can be configured
according to your needs.
1. In the Data Options section, configure how data in the Segment is refreshed at run time. The
following options are available:
l Refreshable Segment - Segments which refer to this Segment as part of their criteria can
automatically refresh this Segment when they are run.
l Refresh Child Segments - The Segment can automatically refresh data in its child segments,
so long as they are marked as refreshable.
If the refreshable option is not enabled, then the Segment's contents will remain untouched and
used as is in the criteria evaluation of the parent, and any child Segment beneath the non-
refreshable Segments are also not refreshed.
Note: Top-level Segments in a dependency chain are always refreshed. Normally, Segments
lower down in a dependency chain should also be marked as refreshable, as this ensures that any
parent Segment is set up in the most accurate way. However, as a best practice, disable the
refreshable option for all Segments that are too costly (in terms of time and processing resources)
to refresh every time a parent Segment is refreshed.

Chapter 6: Segments
2. In the Sampled Segments Options section, select a sample of criteria results. For more
information, see Control Groups.
3. In the Control Group Options section, designate Segment results as a control group. For more
information, see Control Groups.
4. In the Scheduling Options section, select the Enable Schedule check box to control when the
segment runs.
Caution: You must check in the Segment. Segment scheduling or the removal of any prior
schedule only takes place after the Segment is checked in.
5. In the Delivery Options panel, configure the Pega Marketing to send email notifications for
scheduled runs and refreshes. You can customize the email by using the provided fields. The email
recipient must be an operator in the system.
Intelligent Segmentation
Intelligent segmentation assembles recommended criteria from statistical analysis of various input
sources and ranks them according to how well they do at predicting certain outcomes. This helps the
marketer to identify groups of customers, form Segments, and use them without the need for guess
work.
Intelligent segmentation is supported by Analysis Projects, which create a set of predictors based on
samples of the main customer data. Intelligent segmentation also uses sampling strategies to
optimize the processing involved in discovering these predictors.
Configuring a Sample
You can use a Sample to define a sample of the overall customer 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 goal, for example the purchase of a
product or service.
1. Click Configuration > Segmentation > Segmentation Support.
2. In the Sample populations tab, click Create.
3. Enter the Sample name.
4. Optional: Enter the Issue and Group to classify the Sample.
5. Click Create and open .

Chapter 6: Segments
6. On the Design tab, in the About This Sample Population section, configure the following
information according to your requirements:
l Sample Source - Describes the location of the sample data.
l Anticipated Sample Size - Describes the required size in terms of an absolute number
(Fixed) or a percentage (for example, 10%).
l Sample Strategy - Describes various sampling strategies. For Ascending and Descending,
use the Ordered On field to identify the field in the data set on which to order.
7. In the Sample Fields section, clear any check boxes corresponding to fields which are not useful
in analysis. As a general rule, fields that are system-related (for example partition key) or unique
for individual customers (for example their customer id or their full name) typically have no value
from an analysis perspective.
8. Click Save.
9. Run the Sample.
l To run the Sample manually:
a. Click Run . The Run Sample pop-up window is launched.
b. Click Confirm to populate the Sample. The Sample size field is updated to reflect the
number of rows in the Sample.
c. Click Preview to preview the contents of the Sample and its associated customer data.
l To run the Sample automatically, schedule the sample execution in the Schedule tab. Sample
scheduling works in the same way as Segment scheduling. For more information, see Optional:
Configuring Criteria Segment Runs.
10. Optional: Click the History tab to see details of the Sample population.

Chapter 6: Segments
Configuring Analysis Projects

Analysis Projects analyze Sample data to assemble a set of predictors that have influence on the
nominated outcome, or to conduct distribution analysis on a data set.
1. Click Configuration > Segmentation > Segmentation Support > Analysis Projects.
2. Click Create.
3. On the Create Analysis Project form, enter the following information:
l Analysis Project name
l Sample – Select a Sample from the list.
4. Click Create and open .
5. Configure the analysis type for the Analysis Project. The following analysis types are supported:
l Configuring Static Analysis 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.
l Configuring Modeled Analysis provides a statistical assessment of the significance of the

individual properties and their influence or power in predicting the targeted outcome.
6. Click Save.
7. Run the Analysis Project.
l To run the Analysis Project manually, click the Results tab, and then click Run .
For Static Analysis, the Run button is in the Static Results section. If the Run button is
inactive, check out the Analysis Project.
For Modeled Analysis, the Run button is in the Modeled Results section. If the Run
button is inactive, check out the Analysis Project.
l To run the Analysis Project automatically, schedule the Analysis Project execution in the
Schedule tab. Analysis Project scheduling works in the same way as Segment scheduling. For
more information, see Optional: Configuring Criteria Segment Runs.
8. Optional: If you want to manually run the Analysis Project,

Chapter 6: Segments
9. Click the Results tab to review the results of manual and scheduled analysis runs.
10. Optional: Click the History tab to see the analysis execution statistics.
Configuring Static Analysis
You can configure the Analysis Project to use static 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. It 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.
1. Click the Static Analysis tab of an Analysis Project.
2. Review the available properties which have been retrieved from the supporting sample.
3. Describe which grouping type is required for each property.
l Distinct Count- This property will be processed during the execution phase and a distinct
count of the grouping will be performed. Apply this grouping to properties which have a limited
set of values and where knowing how many customers are in each group would be very
valuable.
l No Grouping - This property will be ignored. However, it may still be used as part of the
modeled analysis. Apply this grouping type to properties which are likely to be a continuous
value with a large number of groups and which are less useful from a grouping and distribution
analysis perspective.
4. If the Sample fields changed since this Analysis Project was created, click Refresh .
Configuring Modeled Analysis
You can configure your Analysis Project to use modeled analysis. This approach uses statistical
analysis to 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.
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.

Chapter 6: Segments
1. Click the Modeled Analysis tab of an Analysis Project.
2. In the Select Offer section, you can train the analysis on specific instances of responses to
previously delivered offers. You can train the analysis using responses to previous offers for the
same product or product group. Alternatively, for a new product offering, you can use similar
products or product groups to assemble likely predictors that will help illustrate the type of
customers who are likely to buy the new product.
a. Select the Issue, Group, or Offer on which you want to focus.
b. Leave any of these values blank to bring through all entries for the parent category. For
example, if you select the Sales Issue and the Handsets Group, and leave the Offer field
blank, the analysis will consider the responses to all offers that belong under Sales or
Handsets.
3. In the Interaction Details section, you can train the analysis on specific interaction details, in a
similar way as with responses to offers. Select the Direction , Treatment, and Channel on
which you want to focus. Use the Offered After field to restrict the analysis only to responses to
those offers that were offered after a specified date and time.
4. In the Select Predictors section, remove or add properties from the base Sample which will be
used as predictors for the analysis. Predictors which have no predictive value in modeled analysis
should be removed from this section.
5. In the Define Behaviors section, select positive and negative outcomes for the modeled analysis
based on the set of responses received so far.
Review each response type in the Available Behaviors section and mark it as a positive,
negative, or ignored behavior for the analysis. To reload the list of available behaviors, click
Refresh . Marking as Positive or Negative moves the response type into the corresponding
response category (Positive Behavior or Negative Behavior).

Chapter 6: Segments
Associating Analysis Projects with Segments
You can associate a Segment with an Analysis Project so that you can reuse static and modeled
analysis predictors during criteria assembly. For more information about associating an Analysis
Project with a Segment at Segment creation, see Creating a Criteria Segment.
You can also associate Analysis Projects with existing Criteria Segments.
1. Click Audiences > Segments.
2. Open the Criteria Segment which you want to associate with an Analysis Project.
3. Click Check out.
4. On the Design tab, click More.
5. In the Analysis Project list, select an Analysis Project which is relevant to your Segment. If the
Criteria Segment was already associated with an Analysis Project, selecting a new Analysis Project
will clear any existing criteria for this Segment.
6. Click OK to proceed or Cancel to cancel the change.

Chapter 6: Segments
7. Optional: To view or modify the Analysis Project configuration, click the Open icon next to the
Analysis Project list.
8. Click Save.
Creating List Segments

You can use a List Segment to quickly convert a list of customers into a Segment that Pega Marketing
can use as the audience in Campaign and scheduled Next-Best-Action execution. Advanced users can
use the customer list to update existing customer data. You can also manually edit the list of
customers included in the Segment.
1. Click Audiences > Segments > Create.
2. Enter a Description for the new Segment.
3. From the Type list, select List.
4. Click Create and Open .
5. Add customers to your Segment. There are two ways of adding customers to List Segments:
l Importing Customers
l Manually Adding Customers to a List Segment
6. Populate the segment.
l If you have Check in / out enabled, click Check in .
l Otherwise, click Save.
Pega Marketing automatically starts to populate the Segment with the current customer list. The
total number of customers in this Segment is displayed in the Population count field.
7. After you create a Segment, you can view it in the Segments landing page. For more information,
see Managing Segments.
Importing Customers
You can use a comma-separate values (CSV) file to import customer data into your application. By
adding or updating customer records in bulk, you can quickly update the Segment. You can import
customer data at any time.

Chapter 6: Segments
1. On the Customers list tab of the Segment, click Import.
Tip: The import process uses the Data Management functionality of Pega Platform. For details on
this process, click the help icon in the wizard to launch the Pega Platform help topic.
2. Click Choose file, and then upload the CSV file with your customer data.
3. In the Purpose list, select one of the following options:
a. Add or update - Creates customer records for entries in the import file that do not exist in
the customer table, updates existing customer records, and adds all valid customers to the List
Segment.
b. Add only - Creates customer records for entries in the import file that do not exist in the
customer table, ignores existing customers, and adds all valid customers to the List Segment.
c. Populate Segment Only- Adds existing customers from the import file to the List Segment,
but does not modify the customer table.
4. Click Next.
5. In the Match existing records by field, select the data field from your import file which will be
used to match existing customer records. For example, select CustomerID. The field used to
match records must be unique.
6. For each Source field in the import file, specify the Target field mapping. If you previously
saved a field mapping template, you can select it from the Template type list.
7. Optional: If you selected the Add or update import purpose, you can use the Update type list
to control which fields are updated for existing customers. To set different conditions for different
fields, clear the Update all fields check box and set the conditions in the Update type column.
8. Click Next.

Chapter 6: Segments
9. Optional: To save a field mapping template, select the Save import settings as a template
check box.
10. Click Start validation .
Tip: If the validation reports any invalid rows, click the See more link to download a CSV file
containing the records which failed to import. The last column in this file contains a description of
the error that occurred. Resolve the errors before you proceed.
11. Click Continue import.
When importing large files, the import progress can take some time. You can close the import
window and continue with other activities. The system displays the status of the import at the top
of the customer grid. Once the import completes, the system displays the number of instances
that were added or updated by the import. If there were errors during the import, the number of
erroneous records is also shown.
12. Click Finish .
Manually Adding Customers to a List Segment

You can manually add existing customer records to your Segment.
1. On the Customers list tab of the List Segment, click Add.
2. Enter a part of the customer name, email, or ID into search box, and then click the search icon.
3. Select one or more customers to add to the List Segment, and then click Add.
4. Optional: Repeat the above steps to add more customer records to the Segment.
5. Click Done.
Managing Segments
You can view and manage List and Criteria Segments by using the Segments landing page.
1. In the Pega Marketing portal, click Audiences > Segments.
2. For each Segment, review the following information:

Chapter 6: Segments
l Image associated with the Segment
l Description
l Rule name of the underlying Segment rule
l Number of customers in the Segment
l Percentage of the total customer population represented by the Segment
l When the Segment population was last refreshed
l Segment type
l When the Segment rule was last updated
Tip: The landing page lists the twenty most recently updated Segments in the system. To load the
next twenty results, click the View more results link at the end of the list.
3. To search for Segments by Issue / Group, Type, and Name, use the filters at the top of the page.
4. Click the link in the Segment description to open the Segment.
Exporting Customers in a Segment

After you populate a Segment, you can export a list of its unique customers.
1. Use the customer grid to view the customers in the Segment.
l For Criteria Segments, click the Show customers link in the Segment header panel. This
launches a pop-up grid listing the customers in the Segment.

Chapter 6: Segments
l For List Segments, the same customer grid is available directly on the Customer list tab of the
Segment.
2. The customer grid displays the built-in Default customer view. If your implementation team
defined other views for the customer grid, you can switch to them by selecting the view in the list
and clicking View.
Tip: To define a custom data view, create a Report Definition in the Customer- class that has a
custom field named DataManagement and value Views.
3. Export the data view to a CSV file.
l For Criteria Segments, click Export in the pop-up window which displays the customer grid.
l For List Segments, ensure that the Segment is checked in, and then click Export on the
Customer list tab of the Segment.
Removing Customers from a List Segment

You can manually remove one or more customer record from a List Segment.
1. Check out the List Segment.
2. Use the columns in the grid to sort and filter for the customers you want to remove from the
Segment.
3. Click the Delete icon in the customer's row in the customer grid.
Note: For Criteria Segments, this option is not available. To change which customers are included in
a Criteria Segment, adjust the selection criteria instead. For more information, see Designing Criteria
Segments.

Chapter 6: Segments
Repopulating a Segment
After you make changes, such as adding customers or adjusting criteria, to a Segment, repopulate it
to apply your changes.
1. Check out the Segment and edit it as needed.
2. Click Save.
3. Check in the Segment.
l For List Segments, checking in the Segment repopulates it automatically.
l For Criteria Segments, click Run after checking in the Segment. Running a Criteria Segment
repopulates it.
Reviewing Segment History Information

The History tab provides a historical view of the Segment, its updates and its population.
1. Click Audiences > Segments, and then click the name of a Segment.
2. Click the History tab.
3. For Criteria Segments, review statistics about previous Segment runs in the Segment Statistics
section.
4. For List Segments, review details about previous uploads of files with customer data records in the
Import History section.

Chapter 7: 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.
Pega 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: Pega 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.
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.

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:
l MktType - This must be set to "ControlGroup"
l 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.
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:
l Member - Customer is currently IN the specified Control Group
l NonMember - Customer is currently NOT IN the specified Control Group, but has previously been
a member of this group.
l (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:
@if(@equals(LatestCGStatus.ControlGroupValidityStart,""), true, @
(Pega-RULES:DateTime).CompareDates(@(Pega-
RULES:DateTime).CurrentDateTime(),
LatestCGStatus.ControlGroupValidityStart)) && @if(@equals
(LatestCGStatus.ControlGroupValidityEnd,""), true, @ (Pega-
RULES:DateTime).CompareDates (@(Pega-RULES:DateTime).CurrentDateTime
(), LatestCGStatus.ControlGroupValidityEnd))

Chapter 8: Strategies
A Marketing Strategy enables the user to match the Offers that are available for a Campaign 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.
The Strategies landing page lists available Strategy rules in the system. This landing page is accessible
in the Pega Marketing portal via: Intelligence > Strategies
The Issue / Group filters and the search input field allow marketers to refine the list of Strategies
displayed on this landing page.
Pega Marketing provides support for the following Strategy creation modes:
l Guided - To create a new Strategy using this mode, directly click the Create button on the
Strategies landing page or select the Guide me through it item from the create button's menu. To
re-configure created Strategies using this mode, select the Open Strategy Builder action from the
Actions menu in the row of the Strategy on the Strategies landing page.
l Manual - To create a new Strategy using this mode, select the Start with new canvas item from the
create button's menu. To review or re-configure created Strategies using this mode, double-click
the Strategy row or select the Open Canvas action from the Actions menu. For information on
manually creating a Strategy rule and configuring its various tabs, refer to Pega Platform
documentation.
Pega Marketing includes marketing-centric Strategy shapes that aid marketers in further harnessing
the powers of Strategies. These shapes are described in the Marketing-centric Strategy Actions
section.
Guided Strategy Creation

The Strategy Builder utility in Pega Marketing guides marketers in designing their marketing
Strategies.
The following steps are involved in the Strategy creation process:
1. Specify a name for the new Strategy. The system automatically generates an identifier for the
Strategy based on the specified name. To change the identifier, use the pencil icon.

2. Enter a description for the Strategy.
3. Select the objective of the Strategy. Click Configure in the Objective section to launch the
Configure Objective modal window. Usage patterns for this modal window are described in the
Using a Configuration Modal Window appendix. After selecting an objective, click Apply to close
the window.
4. Configure the various elements of the selected objective. Refer to the appropriate configuration
topic in the following list for more details:
a. Bundled offers
b. Customer Lifetime Value
c. Offer prioritization
d. Priority ranked offers
5. Save and review the generated Strategy.
Bundled offers
This objective enables marketers to create a Strategy to create Offer bundles using various targeting
approaches. Marketers can utilize Segments, Eligibility rules, and Prioritization rules to priority rank
the Offers within each bundle.
The sequence of steps for configuring this objective and the configuration options are mostly similar
to the ones for configuring the Priority ranked offers objective.
The one additional configuration that is specific to the Bundled offers objective is the specification of
the bundle parent when configuring a targeting approach. This is applicable for both audience-driven
and analytics-driven targeting approaches.
When configuring a targeting approach under this objective, use the Configure link in the Bundle
sub-section of the approach to launch the Configure Bundle modal window. This window lists all
Offers in the selected groups that are bundle parents. Select the desired Offer to use as the bundle
parent for the targeting approach and click Apply to close the modal window.
After selecting a bundle parent, marketers can use the Name and Type fields to modify the name and
type of the bundle. Any modifications to the name and/or type are only applied in the generated
Strategy. The backing Offer is not impacted.

Customer Lifetime Value

This objective enables marketers to create a reusable customer lifetime value (CLV) Strategy. CLV is a
prediction of the net profit attributed to the entire future relationship with a customer.
To configure this objective, first select the calculation method to use. Click the Configure link in the
Method section to launch the Configure Calculation Method for CLV modal window. This window
lists the available calculation methods. The details section shows the expression used by the
calculation method. Pega Marketing provides the Simple calculation method out of the box. Select a
calculation method and click Apply.
Next, configure the fields pertaining to the selected calculation method. For the default Simple
calculation method, this includes the following fields:
l Acquisition cost - This is the cost to acquire the customer.
l Annual profit - This is the yearly profit from the customer excluding one-time acquisition costs.
l Retention rate - This is the annual rate of retention of your customer base.
For each of the above fields, marketers can use one of the following sources for the value:
l Constant - Directly specify a numeric value
l Property - Select a property from the customer class that contains this value
l Strategy - Use the Configure link to select a Strategy that returns this value. After selecting a
Strategy, select the strategy result property that contains the value.
The following example demonstrates the usage of these fields to determine the CLV for a customer
using the Simple calculation method:
l Sample values: Acquisition cost = 50, Annual profit = 1400, Retention rate = 80%
l Simple CLV expression = (CustomerProfit x YearsACustomer) - AcquisitionCost

l YearsACustomer = 1 / (1 - Retention rate) = 1 / (1 - 0.8) = 1 / 0.2 = 5
l Simple CLV = (1400 * 5) - 50 = 6950
Offer prioritization
This objective enables marketers to create a reusable Strategy to define how Offers will be prioritized.
Marketers can utilize analytical models to determine the Offer priority. The generated Strategy uses
an external input. As such, this Strategy can be applied to any set of Offers.
Strategies generated for this objective have built-in propensity smoothing, thereby giving new Offers
a chance to compete with existing Offers. Marketers can additionally boost priority by assigning
weights to results.
The following steps are involved in configuring this objective:
1. Configure prioritization driver
2. Configure prioritization calculation
3. Configure prioritization threshold
4. Configure prioritization output
Configuring Prioritization Driver

Marketers can choose from the following options for driving their prioritization Strategy:
l Analytical model - Select this option to use a predictive or adaptive model as the driver for
prioritization. Click the Configure link in the Analytical model section to launch the Configure
Analytical Model configuration window. This window lists the adaptive and predictive models in
the system. Usage patterns for this modal window are described in the Using a Configuration
Modal Window appendix. Select the desired analytical model and click Apply to close the window.
After selecting a predictive model, marketers must additionally specify a property from the model
results to use as the basis for prioritization.

l Property - Select this option to use a property as the driver for prioritization. Use the smart
prompt to select the desired property.
Configuring Prioritization Calculation

After selecting the driver for the prioritization, marketers can optionally configure the following
aspects to tweak the prioritization calculation:
l Weighting - Marketers can utilize a Decision Table to assign weights to prioritization results. Use
the Configure link in the Weighting section to launch the Configure Weighting configuration
window. This window lists Decision Table rules in the strategy result (SR) class. Usage patterns for
this modal window are described in the Using a Configuration Modal Window appendix. Select the
desired Decision Table and click Apply to close the window.
l Priority - Marketers can also customize the expression used to calculate the priority. These
expressions are represented using Field Value rules stored under the Embed-PegaMKT-
NBAComponent-PriorityCalculation class with the Field Name set to PriorityCalculation. The
system provides a few basic priority calculation expressions out of the box. Use the Configure
link in the Priority section to launch the Configure Priority configuration window. Usage patterns
for this modal window are described in the Using a Configuration Modal Window appendix. The
detail pane shows the expression used by the selected priority calculation. Select the desired
priority calculation and click Apply to close the window.
Configuring Prioritization Threshold

Marketers can also specify a threshold to apply to the prioritization results. If a threshold is specified,
only those results that meet the threshold criteria will be considered for output by the prioritization
Strategy.
To specify a threshold, select Threshold in the drop-down in the Prioritization threshold section.
Then select an operator in the Condition drop-down and specify the comparison value in the Value
field. Marketers can specify a static threshold value or reference a strategy result property as the
comparison value.

Configuring Prioritization Output

Finally, marketers can use the fields in the Prioritization output section to determine how the
generated Strategy should rank and output results. Marketers can select the order in which to rank
priority values - ascending or descending. They can also select whether the prioritization Strategy
should output all results or a limited number of results. To return a limited set of results, specify the
desired number in the Top field.
A sample configuration returning the top ten results sorted on descending priority order is shown
below:
Priority ranked offers

This objective enables marketers to create a Strategy to priority rank one or more offers using
various targeting approaches. Marketers can utilize Segments, Eligibility rules, and Prioritization rules
to achieve the desired results.
The following steps are involved in configuring this objective:
1. Select the business issue to address using this objective.
Note: Changing the business issue clears out all configurations for the previous issue.
2. Select one or more groups within the selected issue to utilize in the generated Strategy.
3. Configure targeting options
4. Arbitrate over targeting approaches
5. Configure overall prioritization

Configuring Targeting Options

After selecting the groups to utilize in the strategy, the next step is to determine how to target the
audience with this Strategy. This is done by adding and configuring targeting approaches. To add a
new targeting approach, perform the following steps:
1. Click the Add targeting approach link in the Targeting approach section.
2. Select the targeting type from the Add Targeting modal window. Choose between the following
options:
a. Audience driven - Choose this option to use audience configurations (i.e. Segments) to
determine how to target the audience.
b. Analytics driven - Choose this option to use (predictive and adaptive) analytical models to
determine how to target the audience.
3. After selecting the targeting type, click Apply to submit the selection and close the modal window.
4. Configure the selected targeting approach. See Configuring Audience-driven Targeting and
Configuring Analytics-driven Targeting for details.
5. Repeat steps 1-4 to add and configure more targeting approaches.
Configuring Audience-driven Targeting
A new audience-driven targeting approach starts out as shown below:
The first step of configuring this targeting approach is to select one or more Segments to represent
the starting audience targets. Click the Configure link to launch the Configure Audience modal
window. Usage patterns for this modal window are described in the Using a Configuration Modal
Window appendix.
After adding the desired Segments, click Apply. The targeting panel now displays the audiences
added for this approach.

The two rows each represent a branch of logic execution in the generated Strategy.
The following actions are available for each Segment row:
l Assign offers
l Split by segment
l Remove segment
Repeat the above process to fully configure each row in the audience-driven targeting approach.
Assign offers
Use the Assign offers link to launch the Configure Offers modal window. Use this window to select
the Offers that should be included for customers that are members of the corresponding Segment.
appendix.
Note: The Configure Offers modal only shows those Offers that are in the Strategy's selected
groups.
After configuring the desired Offers, click Apply to associate them to the corresponding Segment
row.
Split by segment
Select the Split by segment item from the Actions menu to split the execution logic for the selected
row. Upon selecting this item, the Configure Audiences modal window launches. Use this window to

add and select the Segment(s) to use in the split.
In the example above, the marketer has split the high value customers path into two paths. Now, the
marketer can target customers who are members of each path differently. They can select one Offer
(or set of Offers) for those customers who belong to High Value Customers and Frequent Flyers, and
a different set of Offers for customers that belong to High Value Customers and New Renters.
Remove segment
Select the Remove segment item from the Actions menu to remove the current Segment row and
its associated configurations - i.e. Offers and split Segments.
Configuring Analytics-driven Targeting
The first step of configuring an analytics-driven targeting approach is to select the business groups to
include in the approach. If the Strategy being generated is only applicable to one business group, this
group is selected by default. Otherwise, click the Configure link to launch the Add groups modal
window.
Note: Only those groups that were selected to be included in the Strategy are shown in the Add
groups modal window.
Click Apply after selecting the desired groups. The targeting panel now displays each of the selected
groups along with action links to configure them.

The following actions are available for each group:
l Select applicable offers
l View all offers
l Remove group
l Configure eligibilities
l Configure prioritization
Select Applicable Offers
By default, all Offers in the group are considered. However, marketers can choose the Select Offers
menu item to individually select the Offers to use.
Use the Configure link to launch the Configure Offers modal window and select the desired Offers.
After applying their changes, marketers can click a selected Offer to open it.

View All Offers
The View all offers action in the Actions menu enables marketers to view the Offers in a particular
group,
Selecting this action launches a report that displays the group's Offers.
Remove Group
The Remove group action in the Actions menu enables marketers to remove the corresponding
group from the analytics-driven targeting approach.
Configure Eligibilities
As part of configuring a group in an analytics-driven approach or configuring a business issue node in

Next-Best-Action Designer, the marketer can optionally utilize Proposition Filter rules to specify
eligibility criteria for the selected Offers. Click the Configure link in the Eligibilities sub-section to
launch the Configure Eligibilities modal window. Usage patterns for this modal window are described
in the Using a Configuration Modal Window appendix.
After adding the desired rules, click Apply. Upon application, the configured Proposition Filter rules
are listed in the Eligibilities section. Clicking an entry in the list opens its rule form.
Note: Refer to Pega Platform documentation for more details on Proposition Filter rules.

Configure Prioritization
As part of configuring a group in an analytics-driven approach or configuring a business issue node in

Next-Best-Action Designer, the marketer must specifying how selected Offers should be prioritized. A
prioritization Strategy should determine the relative priority of Offers in the group and rank them so
that the customer is always presented with the right Offer. Click the Configure link in the
Prioritization sub-section to launch the Configure Prioritization modal window. Usage patterns for
this modal window are described in the Using a Configuration Modal Window appendix.
Select the desired prioritization Strategy rule from the list of rules and click Apply.
Note: The Configure Prioritization window only lists those Strategies that have the NBACategory
custom field set to PRIORITIZATION. New rules created from this window automatically have this
custom field set.
Upon application, the configured prioritization Strategy is listed in the Prioritization section.
Marketers can click the name of the Strategy to open it.
Arbitrating over Targeting Approaches

When multiple targeting approaches are added to the Strategy, the marketer must also configure how
the system should arbitrate over these approaches. Each targeting approach is assigned a label (A, B,
and so on). Marketers can choose one of the following options to arbitrate across targeting
approaches:
l A/B Testing
l Conditional
A/B Testing
This mode of arbitration allows marketers to specify the frequency (using percentages) when each
targeting approach should be applied. A value must be specified for each approach and the values
must add up to 100%.

In the example above, approach A will be applied 60% of the time while approach B will be applied
40% of the time.
Conditional
This mode of arbitration allows marketers to use conditional expressions to arbitrate between
targeting approaches. Marketers can re-order the approaches using the drag icons. Marketers can
access both Offer data and customer data in their expressions. Offer data can be accessed directly
using the "." notation, while customer data can be accessed by using the "Primary." notation.
In the example above, approach A will be applied for customers over the age of 40 and approach B
will be applied for all other customers.
Configuring Overall Prioritization

The overall prioritization configuration of a group Strategy determines how the system should
prioritize across all selections. This prioritization determines the order in which Offers will be made

to a customer. An overall prioritization is required if the marketer has configured multiple targeting
approaches and/or if an analytics-driven approach includes more than one business group.
The process for configuring an overall prioritization is same as the one for configuring a group or
issue level prioritization.
Saving and Reviewing the Generated Strategy

After completing the various portions of the guided Strategy creation process, click Save to generate
the Strategy. If there are any configuration errors, these are reported. Once all errors have been
addressed, the system generates the Strategy and the Strategy Builder switches to review mode.
Marketers can view the generated Strategy by selecting the Open canvas action in the Actions
menu in Strategy Builder.
Note: Any modifications made to the Strategy outside of Strategy Builder will be over-written when
the Strategy Builder configuration is re-saved. In such cases, the system displays a message to warn
the user of this situation.
Marketers can use the Delete button in Strategy Builder to remove a Strategy Builder configuration.
Note: Deleting a Strategy Builder configuration does not delete the generated Strategy. Marketers
can continue to use this Strategy and modify it using the Strategy canvas.
Marketing-centric Strategy Actions

This section provides details on the following marketing-centric Strategy actions and operations:
l Using Segments within Strategies
l Using Contact Policies within Strategies
l Using Geofences within Strategies
l Using a Strategy to stop in-flight Offers
Using Segments within Strategies

Strategies built within Pega 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).

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:

Using Contact Policies within Strategies

Strategies built within Pega 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:
l 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.

l 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:
l 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.
l 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”.
l 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 proposition. For the Contact Policy to be applicable, this value must
be set to match (exactly) one of the channels in the referenced rule.
l Available Contact Policy – Contact Policy limitations are only applied if the referenced Contact
Policy rule is marked as being available.
l 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.
Note on Using Contact Policies with Offer Bundles

If Offer Bundles are present in the Strategy and Contact Policies need to be applied, only the bundle's
parent Offer should be passed into the Contact Policy shape. If the Contact Policy shape passes out
the bundle parent, member Offers should be added to the strategy output.
An example implementation of this pattern is shown in the following Strategy:
In the above example, the Include Bundle Members Filter shape is used to add the member Offers
only if the Contact Policy shape outputs the parent Offer. This is achieved via the following filter
condition:
@String.equals(GlobalContactPolicy.BundleName,"SampleBundleName")
Using Geofences within Strategies

Strategies built within Pega 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:
l 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.

l 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.
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:
l Customer – Prefix the property with “Primary.”, e.g. Primary.Latitude
l Offer Data – Prefix the property with a period, e.g. .Latitude
l 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 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 and 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 Campaign. Target the Campaign 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 Campaign.
3. Submit the Campaign for a one-time execution.
When this Campaign 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.

Chapter 9: 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 accessible in the Pega Marketing via:

Configuration > 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:
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 and open .
A new Contact Policy rule resembles the following:

The Contact Policy rule has the following tabs:
Tab Name Purpose

General Configure the Contact Policy’s availability and per-channel contact limits.
History Specify the Description and Usage information for this Event.
Specifying Contact Policy Availability

The following configuration options are available:
l 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.
l 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.
l 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:
l Channel - Select the channel (from the list of available channels) on which to restrict outbound
communication.
l Contact(s) per customer - Specify the maximum number of contacts allowed per customer.
l 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 1st to the 15th of a month; and from the
16th to the end of the month
Monthly
Quarterly – New quarters start on the first day of January, April, July, and October
Yearly
Contact Policy restrictions only apply to communications with customers that are triggered by
strategies during Campaign 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.

Chapter 10: Volume Constraints

A Volume Constraint enables the user to limit the number of Offers that are delivered.
The following two constraint types are supported:
l 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.
l 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 or Email server throughput.
To apply these constraints, the Volume Constraint rule should be associated with a Campaign. When
a Campaign runs, 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 Campaign, 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 Campaign, it must have at least one
constraint enabled. If no constraints are enabled on this Volume Constraint, the Campaign will not
execute. At this point, the user can either enable a constraint and restart the specific run; or update
the Campaign to no longer use Volume Constraints and re-submit the Campaign for execution.
Volume Constraints are primarily accessed from and created in the context of Campaigns. The
Constraint setting of a Campaign references a Volume Constraint rule. When configuring this setting,
users can use the Configure Constraint selector to review existing Volume Constraints and create
a new one if needed.

Volume Constraints can be stored at the top level or can be categorized into Issues and Groups. A
new Volume Constraint resembles the following:
The Volume Constraint rule has the following tabs:
Tab Purpose
Name
General Specify the offer and channel constraints to be applied. Also configure the constraint reset
options.
History 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.
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:
l Manage each constraint individually - In this mode, the reset option is specified individually
for each (offer and channel) constraint along with its limits.
l 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:

l Manually: Select this option to manually reset constraint counts via the provided reset button(s).
The Volume Constraint rule must be checked in for the reset button(s) to be enabled.
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):
l Each time it is accessed: System will reset constraint limits each time the Volume Constraint
rule is applied. This setting provides the option for applying the same volume constraints during
each run of a Campaign.
l Daily: System will reset the constraint limits the first time they are applied on a particular day.
l Weekly: System will reset constraint limits the first time they are applied in a particular week (first
day of week = Sunday).
l 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 first and sixteenth days of each month).
l Monthly: System will reset constraint limits the first time they are applied in a particular month.
l Quarterly: System will reset constraint limits the first time they are applied in a particular quarter
(quarters begin on the first day of January, April, July, and October of each year).
l Yearly: System will reset constraint limits the first time they are applied in a particular year.
Specifying Offer Constraints

For each Offer constraint, the following must be specified:
l Enabled – Whether this constraint should be enabled. This provides an easy mechanism to switch
constraints on and off as product volumes fluctuate.

l Offer – Name of the Offer to be constrained. The smart prompt presents a list of Offers
categorized by their Issue and Group.
l 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.
l 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.
l Maximum Volume – Desired maximum volume for this Offer.
In addition, the following are also displayed:
l 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
l 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:
l Enabled – Whether this constraint should be applied.
l Channel – Delivery channel that is being constrained.
l 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.

l Minimum Volume – Desired minimum volume for this channel.
l Maximum Volume – Desired maximum volume for this channel.
In addition, the following are also displayed:
l Remaining – Number of Offers that can still be made on this channel.
l 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:
l pyChannel – This needs to be set to the channel being constrained (Email, SMS, etc.)
This is demonstrated in the Strategy snippet below:

Chapter 11: Offers
Chapter 11: 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, and deleting the proposition instance 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.
The Offers landing page lists available Offer rules in the system. This landing page is accessible in the
Pega Marketing portal via: Content > Offers
This landing page lists the twenty most recently updated Offers in the system. Users can use the
View more results at the end of the list to load the next twenty results. Users can also use the
filters at the top of the page to search for Offers by Issue / Group and Name.
For each listed Offer, the landing page displays the following information:
l Rule name - Clicking the name opens the Offer rule.
l Friendly name
l Offer availability - Start and/or end date of the Offer, if configured

Chapter 11: Offers
l Impression rate of this Offer - Ratio of total impressions (associated with this Offer) and the Offer
volume
l Offer volume - Total number of times this Offer has been initiated by Campaigns
l Conversion rate of this Offer - Ratio of total conversions (associated with this Offer) and the Offer
volume
l Icons indicating the channels utilized by the Offer
l Image associated with the Offer
The Create button enables marketers to create a new Offer.
A newly created Offer starts out with the Start and End shapes, as shown below.
The Offer rule contains the following tabs:
Tab Name Purpose

Diagram Create the Offer Flow. Refer to the Creating the Offer Flow section.
Details Specify the details about the offering. Refer to the Specifying Offer Details section.
Checklists View any checklists associated with this Offer. Refer to the Checklists chapter.
Test Offer Test the Offer Flow. Refer to the Testing the Offer Flow section.
History Specify the Description and Usage information for this Offer.

Chapter 11: Offers
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.
The following shapes are available in the Shapes Palette:
Shape Icon Purpose

Name
Send Email Configure and send an Email.

Chapter 11: Offers
Shape Icon Purpose

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

Chapter 11: Offers
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 Purpose
Treatment Name of the Email Treatment to send. In the case of Online Delivery, the Treatment Name
Name specified must be backed by an existing Email Treatment rule since this is used as the content
of the email to be sent.
Key Code 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

Chapter 11: Offers
enable one or more of these modes at the same time.
The following Delivery Configuration options are available for this shape:
Name Purpose
Deliver Online Determines whether an actual email should be sent using the content in the specified
Treatment Name.
Use Subject From Denotes that this shape should directly use the Email subject specified in the
Treatment referenced Email Treatment. This subject is shown as read-only in the “Email Subject”
(Online mode) field.
Specify Subject Denotes that this shape should use the specified “Email Subject”.
(Online mode)
Email Subject Subject of the email to be sent.
(Online mode)
Write To File Determines whether a record should be written to an output file.

Write To DB Determines whether a record should be written to an output database table.
Select Template File/DB Template rule which contains the specifics of what should be output to the
(File/DB modes) 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!"

Chapter 11: Offers
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.
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 Purpose
Use Default Email Determines whether the Default Email account should be used for sending this email.
Account
Specify Email Account Determines whether a user-specified Email account should be used for sending the
email.
Account Name of the Outbound Email account to use for sending the email.
From/Reply To: Denotes that the sender’s name (from) and reply-to address in the email being sent
Use Email Account should be taken from the values specified on the Email account.
Settings
From/Reply To: Denotes that the name and email address of the operator that initiates this email (e.g.
Use Operator Settings by launching a Campaign that sends it) should be used for the sender’s name and
reply-to address.
From/Reply To: Denotes that user-specified values should be used for the sender’s name (from) and
Override Settings reply-to address in the email being sent.
From Name that will be used as the sender’s name in the email being sent.
Reply To Email address that will be set as the reply-to address in the email being sent.

Chapter 11: Offers
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 reply-to address). Finally, this also enables the user to verify any data
references (both 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:
l 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 predefined 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.
l 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.

Chapter 11: Offers
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.
Send SMS
The Send SMS shape enables the user to configure an SMS message for delivery.
Name Purpose
Treatment Name of the SMS Treatment to be sent.
Name
Key Code 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.

Chapter 11: Offers
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.
Name Purpose
Deliver Online Determines whether an actual SMS message should be sent using the content in the specified
Treatment Name.
Use Existing Determines whether an existing treatment, specified by the Treatment Name property, should
SMS be used to get the content of the SMS message.
(Online mode)
Quick Create Determines whether to use the text specified in the “Write Message” box as the content of the
SMS SMS message.
(Online mode)
Write Message Content of the message to be sent in “Quick Create SMS” mode.
(Online mode)
Select File/DB Template rule which contains the specifics of what should be output to the file/table.
Template This includes the file/table name, location, header information, and the specific data fields that
(File/DB need to be output. Refer to the Templates chapter for more information.
modes)
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.

Chapter 11: Offers
The following Account Configuration options are available in the “SMS Account” sub-section under the
“Advanced” section of the Send SMS Properties modal:
Name Purpose
Use Default SMS Determines whether the Default SMS account should be used for sending this SMS message.
Account
Specify SMS Account Determines whether a user-specified SMS account should be used for sending the SMS
message.
Account 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:
l 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 predefined 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.
l Test SMS Account Options – These settings specify the SMS account (Default or custom) used
to send the test SMS message.

Chapter 11: Offers
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.

Chapter 11: Offers
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 (such as email or SMS). The user can use this shape to output
relevant data to an output file or database table for processing by legacy systems.
Name Purpose
Treatment Name of the treatment. This can be used to track and organize the output data.
Name
Key Code Marketing code used to identify the treatment. This value can be output in the output file or
table and can be used to track the performance of different treatments.

Chapter 11: Offers
Delivery Options
Generic treatments can be written to a data warehouse (file or database table) for processing by other
systems. Users can enable one or more of these modes at the same time.
Name Purpose
Select File or Database Template rule which contains the specifics of what should be output to the file
Template or table. This includes the file or table name, location, header information, and the specific data
(File/DB fields that need to be output. Refer to the Templates chapter for more information.
modes)
Wait After Sending
Users can determine whether they would like to wait after sending a generic treatment or proceed
Field Marketing Options
This set of options is available when the application includes Pega 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.

Chapter 11: Offers
Both links and files can be uploaded using this section. The user can also enter a description for each
item. Once the file or link is added, it displays in the content grid at the bottom of this section.

Chapter 11: Offers
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:
l Treatment Origin – This setting determines how the channel for delivery is determined. The two
options are:

Chapter 11: Offers
Strategy/Offer – In this scenario, the channel value determined by strategy execution (as part
of a run) is used as the delivery channel. The user can alternately set the channel value
(.OfferData.pyChannel property) directly in the Offer Flow prior to this shape.
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.
l 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 check boxes. 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
l 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
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:
l Write to File/DB options – In the “Output” section
l Email Account options – In the “Advanced” section
l SMS Account options – In the “Advanced” section

Chapter 11: Offers
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 Purpose
Passbook Style Style of the Passbook Treatment to send. Currently available options are “Coupon” and
“Generic”.
Passbook Name of the Passbook Treatment (pass) to send. Refer to the “Passbook Treatments”
Treatment section in the Treatments chapter for details on creating and configuring Passbook
Treatments.
Key Code 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.
Email 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.

Chapter 11: Offers
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:
Name Purpose
Email Subject 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
Campaign).
The following configuration options are available for updating passes:
Name Purpose
Push Select this option to utilize the Apple Push Notification service (APNs) to signal the device that
Notification an update is available for the pass. The device will then make a web service call to get the latest
pass.
Email Select this option to send the updated pass as an attachment to the email (specified in the
Notification Email Treatment field).
Note: If neither notification option (Push or Email) is enabled, the system will generate and store the
updated pass internally. This updated pass will be available to pass holders (customers) 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

Chapter 11: Offers
described in the Email Account sub-section of the “Send Email” shape.
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
The Inbound shape provides a means to specify the content that should be returned when an
inbound application, such as Next-Best-Action Advisor (NBAA), requests this Offer to display within
their application.

Chapter 11: Offers
The following configuration options are available for this shape:
Name Purpose
Section Name of the Section rule to use. The content of this section is returned when an inbound
application (such as NBAA) requests Offer content from the system.
Channel Inbound channel for the Treatment (Default value for this shape is CallCenter).
Work Status of the Offer after executing this step in the Offer Flow.
Status
Note: There should be only one Inbound shape in an Offer flow. Having multiple Inbound shapes in
the same Offer flow could cause non-deterministic behavior in resolving the content that should be
returned to the inbound application.
The Inbound 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.

Chapter 11: Offers
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.
This shape supports the following modes for specifying the wait duration:
l Offset - Use this mode to set the wait time to a specified duration from when this shape is
executed. Use the Days, Hours, Minutes, and Seconds fields to specify the offset. Optionally,
enable the Business Days check box to apply the specified offset only using business days.
l Date/Time - Use this mode to set the wait expiration time to a specified future date and time.
Specify the desired date and time.
l Property - Use this mode to set the wait expiration time using the value of a date time property or

Chapter 11: Offers
expression. Select the desired property or specify the desired expression.
Note: Ensure that the specified property (or expression) will have a valid date and time value
during Offer runtime.
Users can also enable a wait in Offer flow execution 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 after sending” check box on these shapes.
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.

Chapter 11: Offers
The following Configuration options are available for the Update Status shape:
Name Purpose
Work Status Status of the Offer.
The out-of-the-box values for the Offer status include:
l New
l OfferSent
l Resolved-OfferAccepted
l Resolved-OfferExpired
l Resolved-OfferRejected
Behavior Denotes the behavior of the customer to the particular Offer. This information gets recorded in History.
The out-of-the-box values for Behavior include:
l Negative
l Neutral
l Positive
Response Denotes the response of the customer to the particular Offer. This information gets recorded in History.
The out-of-the-box values for Response include:
l Accepted
l NoResponse
l Pending
l Rejected

Chapter 11: Offers
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 Purpose
Work Class Name Name of the class which contains the process (Work Object flow) to be started.
Work Flow Name Name of the process (flow) to be started.
Work Status Status of the Offer after the new process has been initiated.
(Status section)
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 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

Chapter 11: Offers
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 handed-off 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:
l Data Transform:
pyDefault
l Properties:
Channel
CustomerID
OfferName
l Flow:
FulfillOffer
l Work Parties:
Default
l Flow Action:
Approve
l Section:
FulfillOffer

Chapter 11: Offers
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:
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.

Chapter 11: Offers
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:
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:

Chapter 11: Offers
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 Pega 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.

Chapter 11: Offers
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:
l Boolean Expression
l Decision Table
l Decision Tree
l Fork
l Map Value
l Predictive Model
l Scorecard Model
Note: More information on the various options for configuring each of the decision types (listed
above) can be found in Pega Platform documentation.

Chapter 11: Offers
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:
l Current Operator – Routes the appointment to the operator that initiates this Offer (e.g. by using it
in a Campaign and executing the Campaign).
l Specify Operator – Routes the appointment to the operator specified in the “Operator” field.
l Workbasket – Routes the appointment to the workbasket specified in the “Workbasket” field.

Chapter 11: Offers
Schedule Options
The user can choose from the following options:
l 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.
l Specify Date – Sets the appointment time to the specified date and time
Start
The Start shape denotes the beginning of the Offer Flow. Each Offer Flow must have one and only
one Start shape.

Chapter 11: Offers
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
Pega Platform documentation.
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:
l Simple Connectors
l Decision Connectors
l Wait Connectors
l Response Received Connector

Chapter 11: Offers
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:
l Inbound
l Update Status
l Hand Off
l Start
Decision Connectors
These connectors emanate from the Decision shape. Decision connectors can be sub-categorized
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.
Always Condition Type
This condition type represents a connector that is always taken.

Chapter 11: Offers
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:
l Send Email
l Send SMS
l Send Generic
l Send Passbook
l Send Multiple Treatments
l Push Notification
l Wait

Chapter 11: Offers
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.
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 a
Send Email or Send SMS shape after an Offer email or 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.

Chapter 11: Offers
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.
To add a Response Received connector to a Send Email or Send 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).
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.

Chapter 11: Offers
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:
l Missing required fields
l Invalid rule references – e.g. Treatment, Template, Decision, Email Account, etc.
l 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.
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 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.

Chapter 11: Offers
The InboundTicket is enabled by specifying it as the value for the Ticket Name in the Tickets
section (under Advanced) of the appropriate Offer flow shape, as shown below.
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.
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.

Chapter 11: Offers
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:
l A shape designated as the resumption point for inbound requests by having the InboundTicket set
on it
l A branch in flow execution for channel-specific paths (as needed)
Note: When integrating with an inbound application (such as NBAA), it is typical to use the Inbound
shape to hold the InboundTicket.
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:
l Initial branching on Channel – Contact Center (CC) vs. Outbound
l Specifying the InboundTicket on the Inbound shape
l Specifying the Inbound Treatment on the Inbound shape

Chapter 11: Offers
l Waiting for a response after sending out the Offer email
l Branching on the type of response received – Accepted vs. Rejected
l Handing off to a Fulfillment mechanism upon Offer acceptance
l 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. These details
can be used in Strategies for making decisions. They can also be included in treatments.
Tip: Each of the data fields listed in the following sections is part of the proposition associated with
the Offer. To utilize a particular field in a different part of the application, reference the associated
property using the OfferData page under the Offer class.
Offer details are classified into the following groups:
l Basic Offer Attributes
l Bundle Attributes
l Field Marketing Details
l Custom Attributes
Basic Offer Attributes

Basic Offer attributes are available for every Offer and are categorized into the following sections:
l Offer details
l Availability
l Financials
l Expected outcomes
Offer details
The following table describes the data fields contained in the Offer details section:

Chapter 11: Offers
Input OfferData Description / Purpose

Field Property
Key code KeyCode Marketing identifier for this Offer. Users can output this value in treatments and/or use it
internally to track Offer performance.
Variant Variant Variation in a set of offers (e.g. size, color, etc.). This property is used in Offer bundling for
Advisor. Variants for the same Offer will be grouped and selectable during bundling.
Category Category Classification of the Offer. This property is used in the Advisor Negotiation use case.
Description ShortDescription Brief description of the Offer. This property is used in the Advisor Assessment and
Negotiation use cases.
Benefits Benefits Benefits associated with the Offer
Image URL ImageURL Use this field to provide a link to an image to display for this Offer when it is rendered as
part of a Real-Time Container.
Click ClickThroughURL Use this field to provide a link to a web page or a file that provides more details on this
through Offer. When this Offer is included in a Real-Time Container, clicking this Offer in the
URL Container will re-direct to the URL specified in this field.
Note: For proper re-direction, this URL should begin with the protocol prefix - such as
http:// or https://
Offer pyImage Use this field to reference an image (Binary File rule) which represents this Offer. This
image image displays in the details side bar, in the Offers landing page, and when the Offer is
referenced in Outbound Campaigns (in the Offer card and the Add Offer configuration
window).
Starting StartingEvidence Number of Offer responses required before a model is reliable. This field is used in
Evidence conjunction with Starting Propensity in the adaptive model propensity smoothing formula.
Starting StartingPropensity Default propensity for the Offer before the model is reliable. This field is used in
Propensity conjunction with Starting Evidence in the adaptive model propensity smoothing formula.
Availability
The following table describes the data fields contained in the Availability section:
Input Field OfferData Description / Purpose

Property
Start Date StartDate Date the Offer becomes active
End Date EndDate Date the Offer is no longer valid
Relevant WhyRelevant Description of the circumstances under which this Offer is relevant for a
description customer
Eligibility EligibilityDescription Description of the circumstances under which this Offer is eligible for a
description customer

Chapter 11: Offers
Financials
The following table describes the data fields contained in the Financials section:
Input OfferData Description / Purpose

Field Property
Original cost OfferValue MSRP or the full cost of this Offer
Marketing BudgetedCost Costs associated with the marketing of this Offer
cost
Internal cost InternalCost Costs to the organization when a customer accepts this Offer. This amount is
reflected in the Retention Negotiation budget.
Customer Cost Actual cost to the customer for this Offer
cost
Agent AgentCompensation Compensation amount for the agent if a customer accepts this Offer
compensation
Price Pricing Description of the customer cost of this Offer (e.g. $45 per month)
description
Expected outcomes
The following table describes the data fields contained in the Expected outcomes section:
Input Field OfferData Property Description / Purpose

Expected response rate ExpectedResponseRate Expected rate of customer response to this Offer
Expected revenue Expected revenue Expected earnings from this Offer
Bundle Attributes
Bundles attributes are used to specify the bundling settings for the Offer. Refer to the Offer Bundles
chapter for more details.
Field Marketing Details

This section is available when your application includes Pega Field Marketing. It contains
configuration options for using this Offer as a template in Field Marketing Campaigns. Refer to the
Pega 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.

Chapter 11: Offers
Once this checkbox is enabled, the user can configure the following additional options:
l Whether Field Marketing Campaigns based on this Offer must be submitted for approval
l 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:
Finally, authorized users can choose whether Field Marketing Campaigns that utilize this Offer should
ignore the global exclusion list. Refer to the Exclusion List chapter for details.
Custom Attributes
The Custom Attributes section lists other proposition fields defined for use by implementers of
the application. The following sets of attributes display in this section:
l All top level custom attributes
l All Issue level custom attributes belonging to the Issue for this Offer
l All Group level custom attributes belonging to the Group for this Offer

Chapter 11: Offers
If the Offer belongs to a versioned Group, implementers can customize the display of attributes. In
such a case, this section will utilize the customized form for specification of these attributes. Refer to
Pega Platform documentation for guidelines on creating custom forms for Decision Data rules.
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. Go to the Proposition Management landing page. This page is accessible in the Pega Marketing
portal via: Configuration > Decision Management > Proposition Management
2. Use the controls in the Hierarchy tab to perform the desired action, as described in the following
table.
To Do
Create a top level attribute Ensure Top Level is selected under the Business issues & groups
tree. Click the New Property… button to launch the New form.
Create an issue or group level Select the appropriate issue and/or group in the Business issues
attribute & groups tree. Click the New Property… button to launch the
New form.
3. Specify the Name and Type of the new attribute in the Create Property form and click Create.
The next steps vary based on whether the application utilizes Decision Data rules to version
propositions.
l Application doesn't version propositions - No further action is needed.
l Application versions propositions - The new attribute must be added to the Decision Data rule of
each group where it needs to be utilized. This process is described below.
Adding an Attribute to a Group's Decision Data Rule

1. Open the Decision Data rule for the group. This rule can be opened by clicking the link in the
Decision data records grid after selecting a group in the Hierarchy tab of the Proposition
Management landing page.

Chapter 11: Offers
2. Check out the Decision Data rule.
3. Switch to the Form tab.

a. If the Decision Data rule uses a custom form, add the new attribute to the desired location in
the custom form following Pega Platform development practices.
b. If the Decision Data rule uses the standard form, Click Add field in the Form fields section.
In the new row, find and select the newly created attribute in the Identifier column.
4. Save the Decision Data rule and check it in.
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:
l 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.
l 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.
l 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

Chapter 11: Offers
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.

Chapter 11: Offers
Monitoring Waiting Offers

After configuring an Offer and propagating it to customers via Campaigns, marketers can monitor the
Offer's progress and, if necessary, perform certain actions on active Offers. The Wait Volumes overlay
provides this capability. Marketers can use this overlay to perform the following actions:
l View waiting Offer counts
l Update expiration time for waiting Offers
l Stop waiting Offers
View Waiting Offer Counts

Applying the Wait Volumes overlay on a particular Offer displays the number of waiting instances of
the Offer for the selected Campaign. The overlay displays this count for each wait-enabled shape in
the Offer.
To view this overlay, perform the following steps:
1. Select the Wait Volumes item from the Overlay toolbar menu in the Offer canvas.
2. Specify the Campaign for which you wish to view waiting Offer counts. You can specify either the
name or the work id of the Campaign.
3. Click Submit.

Chapter 11: Offers
Upon application of the overlay, the count of Offers waiting is shown on every wait-enabled shape. In
addition, the name and work id of the selected Campaign is displayed in the canvas toolbar next to
the Overlay menu. The count shown on each shape represents the number of instances of the Offer
that are waiting at the shape and have been initiated as part of the selected Campaign - either via a
scheduled run or via a triggered Event.
Hovering over the count on a shape displays an expanded view of the overlay with links to perform
the Update wait time and Stop offers actions.
Note: Action links in the overlay are disabled when no Offers are waiting at the corresponding
shape or if an action is currently being applied.
To view the wait volumes for a different Campaign, re-apply the overlay (by following steps 1-3
above) and select the desired Campaign.
To remove the applied overlay, select the None item from the Overlay menu.

Chapter 11: Offers
Update Expiration Time for Waiting Offers

The Update wait time overlay action enables marketers to update the time left before instances of
the Offer waiting at a particular shape expire. An example use case for this action would be to grant
customers more time to respond to an Offer.
To initiate this action, click the action link from the overlay detail pane.
Then, choose one of the following options to set the new wait expiration time:
l Offset - Select this option to increment the current expiration time of each waiting Offer by a
specified duration. Use the Days, Hours, and Minutes fields to specify the desired offset.
l Date/Time - Select this option to set the expiration time of each waiting Offer to a specified future
date and time. Specify the desired date and time.
Click Submit to update the expiration time of waiting Offers. The system performs this update in the
background. During this time period, a busy message is shown at the top of the Offer rule and all
further overlay actions are disabled.
Upon completion of the update, a confirmation message is displayed along with the number of
waiting Offers that were updated.

Chapter 11: Offers
Stop Waiting Offers

The Stop offers overlay action enables marketers to stop execution of all instances of the Offer that
are waiting at a particular shape. This provides granular control over the processing of the Offer flow.
For example, if we had an Offer with an initial outreach (Email, SMS, etc.) followed by other
downstream processing. If the outreach was under-performing or if the Offer was no longer viable,
the marketer could stop all instances waiting at the outreach shape without impacting any customers
who had already responded and progressed to a later stage in the Offer flow.
To initiate this action, click the action link from the overlay detail pane.
Confirm the stop request by clicking Submit. Upon submission, the system performs the update in
the background. During this time period, a busy message is shown at the top of the Offer rule and all
further overlay actions are disabled.
Upon completion, a confirmation message is displayed along with the number of waiting Offers that
were stopped.
Reviewing Offer Metrics

The side bar on the right side of the Details tab displays information pertaining to the performance
of the Offer. In addition to the Offer image, the side bar contains the Performance and Key

Chapter 11: Offers
Predictors sections.
Performance
This section provides an overview of how the Offer is performing across the following three metrics:
l Volume - Total number of times this Offer has been made
l Impression rate - Ratio (expressed as a percentage) of the number of times this Offer has been
opened (i.e. impressions) to the volume of the Offer
l Conversion rate - Ratio (expressed as a percentage) of the number of times this Offer has been
accepted to the volume of the Offer
A sample performance summary is shown below.
Key Predictors
This section provides information on Adaptive Models that include this Offer. Each model is listed
separately and the first model is expanded by default. The information presented for each model
provides a quick profile of a customer that is likely to respond to this Offer.
The following information is presented for each model:
l Model name - Click to open the behavior report associated with the model.
l Overall performance of the model
l Direction and channel for the corresponding predictor information
l Active predictors for the model. For each predictor, the group with the highest propensity is
shown. Hover over the green circle to see this propensity value.
A sample predictors summary is shown below.

Chapter 11: Offers

Chapter 12: 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.
Treatment rules are primarily accessed from and created in the context of Offers. When designing the
Offer, users can use the property panel of appropriate Offer shapes (e.g. Send Email, Send SMS, etc.)
to review existing treatments of the corresponding type. To create a new treatment, the user simply
needs to type in the desired name and click the magnifying glass to launch the Create form for the
treatment.
Treatments can be defined at the top level or can be categorized into issues and groups. The system
automatically selects the issue and group in the Create form using the corresponding values from the
Offer rule. Users can change these selections to store the new treatment at a different hierarchical
level.
Email Treatments
A newly created Email Treatment starts out with input fields - for Subject and Key Code - and a blank
canvas to compose the email content, as shown below.

The Email Treatment rule includes the following tabs:
Tab Name Purpose

Treatment Create the contents of the Treatment. Refer to Configuring the Email Treatment.
Test Message Test the content and format of this Treatment by sending it. Refer to Testing the Email Treatment.
History 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:
l Design – This is the default editing mode. In this mode, users can enter free-form 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.
l 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.
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 this button, 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:
l Format – Reference to a Format rule that determines how this field should be formatted.
l 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 button:
Clicking this button 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 drop-down. The following options are
available:
l 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.
l 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.
l 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).

l Open External URL – This option embeds a link to launch an external URL. The user must specify
the external URL to open.
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 to be displayed when the customer clicks on a response link in the Offer
email. This response screen is an internal page in the application and is typically configured using a
Section rule.
l 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.
l 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 out-of-the-box default response screen
(DefaultEmailResponse) will be used. Both customer and Offer data are available to be referenced
when building and 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:
l C – Customer ID
l R – Customer response
l I – Issue of the Offer
l G – Group of the Offer
l O – Name of the Offer
l T – Name of the Email Treatment
l W – ID of the Campaign Run that initiated the Offer
l RA – Rank of the Offer in the Campaign Run (batch output) table
l OU – Name of the Campaign Run (batch output) class containing the Offer instance
Adding Style Options
The following style options can be specified for the response link:
l Button Text – The text that is displayed to the user as the link
l Button Image – Reference to an image that is displayed alongside the link
l 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:
l 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 predefined 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 Email 1 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.
l Subject – Enter the subject for test email.
l 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
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
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.

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:
l Coupon – Appropriate for coupons, discounts, and special offers
l 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.

The Passbook Treatment rule includes the following tabs:
Tab Name Purpose

Passbook Configure the contents of the pass and preview how the pass will be rendered. Refer to Configuring Pass
Details Elements.
Advanced Configure how pass updates should be handled. Refer to Configuring Advanced Passbook Options.
Test Message Test the content and format of this Treatment by sending it. Refer to Testing the Passbook Treatment.
Note: For more details on Passbook, refer to Apple’s Passbook Programming Guide, available at:
https://developer.apple.com/library/ios/documentation/userexperience/conceptual/PassKi
t_PG/Chapters/Introduction.html

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 Accessibility Description that the device will use for accessibility to differentiate this pass from other
Description passes
Visual Pass icon Icon that the Apple device shows with the pass on the lock screen and in iOS apps (such as
Elements Mail) when representing this pass. A preview of the selected icon is shown next to the field.
Visual High-res (or High-res version of the pass icon
Elements 2x) pass icon (used in Retina displays)
Visual Strip image Image that displays behind the Primary fields
Elements (Coupons
only)
Visual Thumbnail Image that displays to the right of the Primary fields
Elements image
(Generic
passes only)
Colors Large text Color used for the values of the fields shown on the front of the pass
elements
Colors Label text Color used for the labels of the fields shown on the front of the pass
elements
Colors Background Color used for the background of the front and back of the pass
of the
passbook
For images, users can use the gear 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 the desired color.

Pass Header tab

Use this tab to configure the pass header. This tab is split into the following two sections:
l Header Visual Appearance
l Header Fields
Header Visual Appearance
Use the following settings to configure the header logo:
Name Purpose
Main logo Logo image that displays at the top left corner of the pass
High-res (or 2x) logo High-res version of the logo icon
(used in Retina displays)
Logo text Optional text that displays next to the logo icon
For images, users can use the gear 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.

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.
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.
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.
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:
l Aztec
l Quick Response (QR) code
l 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:

l 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 injected link invokes appropriate the service on the system and
the positive response is captured.
l 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:
l Location information - Users can either select a Geofence rule or directly specify the latitude and
longitude of the location. Refer to the Geofences chapter for more details on the Geofence rule.
l Notification message – Users can specify the message to display on the pass holder’s device when
the holder is at or 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 can 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.

Configuring Pass Fields

Users can add and remove fields from the various tabs by using the appropriate links displayed over
the grid, as shown below:
For each field, users must specify the following:
l 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.
l 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
magnifying glass icon to open a referenced property and the gear icon to launch the expression
builder.
l Value – Value of the field. The value can be static, a property reference, or an expression. Users
can use the magnifying glass icon to open a referenced property and the gear icon to launch the
expression builder.
l 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.
l 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.
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/conceptual/PassKi
t_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):
l 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 Campaign.
l Keep updating the pass even if different offers use this treatment
In this option, the system will update the existing pass when this Passbook Treatment is used in a
new Offer or Campaign. The pass update will be propagated to the customer’s device using the
update mechanism specified in the Send Passbook shape on the Offer canvas. A treatment with
this option enabled is frequently referred to 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 configuration options available in this section are identical to those available for testing Email
Treatments.
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.

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
Sections
A newly created Section starts out as shown below.

For more information about creating Sections, refer to the Pega Platform documentation.
Note: Unlike other marketing artifacts, a Section rule does not show Issue and Group drop-downs
in the Create form. However, these are still correctly set using the values from the Offer rule. The
Apply To setting of the Section rule is automatically set to correspond to the issues and group class
under PegaMKT-Work-Offer.
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 Purpose

Message Create the contents of the Treatment. Refer to Using the SMS Treatment Editor.
Test Message Test the content and format of this Treatment by sending it. Refer to Testing the SMS 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:
l 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.
l 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:
l Format – Reference to a Format rule that determines how this field should be formatted.
l When – Reference to a When rule that determines whether this field should be displayed or not.
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:
l 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 predefined 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.
l Test Account Settings – 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.


Chapter 13: Customer Journey

A customer journey is the stages and steps customers go through as they engage with a brand for a
specific outcome, such as applying for a credit card or adding a new mobile device. It is important for
marketers to understand how customers are engaging with their brand, on which channels, and the
messages that are resonating or need attention. Because customer journeys show an aggregation of
customers that are in any stage or life cycle for a particular outcome, you can use them to see the
paths and volumes that customers are following. You can also drill down to see more details about
the offers and the characteristics of customers that respond to these offers.
You can define stages for each unique scenario in a customer journey, and specify the conditions in
which customers move between them. For example, customers may become aware that they need or
want a new mobile phone. They consider different phones, compare features and pricing, and make
a decision to purchase the product that best meets their needs. To capture this process, you can
define a customer journey with phases such as Awareness, Consideration, Decision, and Purchase.
Each stage has defined entry criteria, and can be further divided into steps. Each customer journey
step can be linked to an Offer.
Pega Marketing automatically selects relevant customer journeys based on entry criteria you define.
A customer may participate in multiple journeys at the same time. Customers progress through these
journeys in two ways:
l When customers respond to an Offer associated with a specific journey stage and step, they
progress to that stage and step in the journey.
l When data from data streams such as web analytics or event streams indicates that a customer
entered, progressed, or completed a specific journey. Pega Marketing compares the available data
to the entry criteria you define and moves the customer to the relevant stage of the journey.
Defining Customer Journeys

To better understand how your customers engage with your brand and which offers are the most
effective, define customer journeys with stages and steps that describe your customers' engagement.
You can define new customer journeys manually, or use predefined templates.
1. In the Pega Marketing portal, click Next-Best-Action > Customer Journey.
2. Click Create.

3. In the Journey details section, enter the following information:
l Name and Description
l Issue and Group (Present content from) - Specify an Issue or Group if you want to assign
Offers to journey steps. Specifying an Issue or Group filters the list of Offers according to the
Issue or Group you select.
l Maximum journey length - Specify the expected number of days it takes the customer to
complete this journey. After this time, the customer will no longer be eligible for this journey.
l Journey rank - Specify the priority of this journey, relative to other journeys in your
application.
4. In the Entry Criteria section, click the gear icon to define proposition filters, which are
similar to offer eligibilities. For more information, see Configure Eligibilities.
5. In the Select how you want to configure your journey section, select if you want to create
the journey using a predefined template, or define all stages and steps manually.
l To create the journey from a template, click Start with a template, and then select a
predefined template from the list.
l To manually add journey stages, click Create new.
6. Define the stages that make up the customer journey. For example, a sales journey can consist of
Awareness, Consideration and Decision, after which the journey is considered complete.
l To add a new journey stage, click Add Stage.
l To remove a stage, click the down arrow by the name of the stage, and then click Delete
stage.
7. Define the entrance criteria for each stage in the customer journey. This helps ensure that the
customer's progress from stage to stage is tracked. For more information, see Configure
Eligibilities.
a. Click the name of the stage.
b. Click the gear icon in the ENTRY CRITERIA section.
8. Define the steps which make up the journey stages.

a. To add a step to a stage, click Add Step.
b. For each step, you can specify the entry criteria to define when a customer is eligible for this
step. Click the name of the step, then click the gear icon in the ENTRY CRITERIA section. For
more information, see Configure Eligibilities.
c. Optional: You can also link selected steps with Offers that should be extended to a customer at
this step of the journey. To associate a step with one or more offers, click the name of the step,
then click the gear icon in the CONTENT section. For more information, see Offers.
9. Click Save.
10. Click Activate to activate the customer journey.
Managing Customer Journeys

You can view all customer journeys in your system by using the Customer Journey landing page. Use
the Customer Journey landing page to examine the effectiveness of each message at each step of an
active customer journey. With the Journey Overview, you can see which channels and messages
provide the best success rates, and discover where you may want to focus your marketing efforts.
1. In the Pega Marketing portal, click Next-Best-Action > Customer Journey.
2. Click a customer journey to review its stages and steps. An Overview of the journey is displayed.

3. For each step in the journey, review the messages and communications on different channels,
displayed as nodes on the journey graph. Click a node to examine the performance of specific
messages for a specific journey step.
For example, you can compare the number of customers who progressed to the next journey step
to the number of customers who declined the Offer at this step. You can also view the top
grouping for each active predictor from the adaptive model in the Customer Predictors section. If
the step is associated with multiple Offers, you can compare volume, impression and click-
through statistics for each Offer.
4. Optional: To change the timeframe from the current quarter, select Last Quarter or This Year
in the Timeframe section.

5. Optional: To view an animated version of the journey progress, click Explore, and then click a
journey node. The number of customers who progressed through this step is displayed.
6. Create a template from the customer journey, so that other marketers can reuse it. To save a
customer journey as a template, click Actions > Save as template.
7. To activate or deactivate a customer journey, click Activate or Deactivate.
Note: To activate a customer journey, first make sure that you defined entry criteria for all
journey stages. For more information, see Defining Customer Journeys.
8. To edit a customer journey, deactivate it, then click Edit. You cannot edit a customer journey while
it is active.
9. To delete a customer journey, deactivate it, then click Delete. You cannot delete an active
customer journey.

Chapter 14: 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:
l Send Email
l Send SMS
l Send Generic
l 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 Purpose

Definition Configure the output location and the writing mode. See Configuring Output Destination.
Details Specify the contents to be written to the output source. See Configuring Output Content.
Finalize Configure schedule options, delivery options, and post-processing activity. See Configuring
File/Table Finalization.
History Specify the Description and Usage information for this Template.
File Template
File Templates are listed on the Outbound tab of the File landing page. This landing page is
accessible in the Pega Marketing portal via: Configuration > Settings > Channels > File
Database Template
Database Templates are listed on the Outbound tab of the Database landing page. This landing
page is accessible in the Pega Marketing portal via: Configuration > Settings > Channels >
Database

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 Create 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
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 File, Whether existing output content should be over-written

data Database
Append to existing File, Whether new output content should be appended to existing
data Database 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:
l File Template:
Specified file path must be a valid directory
Write access must be available for the specified file path

Note: Output file paths must be accessible by all configured system nodes.
l Database Template:
Should be able to connect to the specified database
Should be able to create tables in the specified database
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 and Footer Information

This option is only available in File Templates. The following information can be added as part of the
file header or footer:
l Free form text – Any text specified by the user
l File name – Name of the output file
l Record Count – Number of records at the time of finalization
l 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:
l Data Fields – Any relevant data fields (such as customer information, Offer details, etc.)
l 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:
Note: Upon execution of a Database Template, the columns created in the corresponding database
table are of type varchar and of size 100.
Configuring File and 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 or 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:
l 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 File or Database landing page.
l 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.
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.

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.
Note: For File Templates, if the finalized file is greater than 5 MB and the Attach File option is
enabled, a small chunk of the file's contents are attached to the notification email. Users can
download the entire file from the File landing page.
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 and Database Landing Page Actions

The File and Database landing pages provide various actions (via the Actions menu) that can be
taken on a specific template. The set of available actions depends on the status of the output file or
table. This includes the following actions:
l Download - (File only) Download the output file.
l Finalize – Trigger finalization of the output file or table.
l Finalize and Download – (File only) Trigger finalization of the output file, and then download
the resulting file.
l 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.
l Retry – In case of a failure, this option can be used to retry writing the records to the appropriate
output file or table.

Chapter 15: 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 incentives, 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:
l 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.
l 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.
l 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.
l 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.

l 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 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 Same behavior for all three bundle types:
- Start the parent Offer flow
- Record initial IH entry for parent and all members
Respond to Email link - Resume the parent - Start all member Offer flows that - Resume the parent Offer flow
for bundle (all Offer flow haven’t been started
members) - Parent flow does not resume
Respond to Email link - Resume the parent - Start or resume the member Offer - Start or resume the member Offer
for individual Offer Offer flow flow flow
Update Status shape - Record IH response - Record IH response for parent and - Record IH response for parent and
in parent Offer for parent and all member Offers that haven’t been member Offers that haven’t been
members started started
Update Status shape N/A - Record IH response for member - Record IH response for member
in member Offer (since member Offer and its parent only
is never started)
Parent Offer - Complete parent and - Complete parent and member - Complete parent and member
completion all member Offers Offers that haven’t been started Offers that haven’t been started
Member Offer N/A - Complete member Offer only - Complete member Offer only
completion (since member Offer
is never started)
Note: Volume Constraints are currently only applied for fixed bundles.

Specifying Offer Bundle Settings

There are two ways to specify the Offer bundle settings for an Offer.
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.
l 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.
l 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.
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.

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.

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 Interaction History 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.
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 out-of-the-box sample.

This treatment includes the following salient pieces of a bundle Email Treatment:
l Bundle name - References .OfferData.BundleName property
l Response link for bundle – Added using the Insert Button functionality
l Impression capture - References RecordImpression section. With bundles, it is typical to include

the impression capture section at the parent level.
l 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.
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 sub-section 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.

Chapter 16: Microsites

A Microsite is a collection of one or more pages which can function as a standalone entity. Microsites
can be also be embedded into existing websites. They can be used for various marketing purposes,
such as product announcements and lead generation.
Microsites are listed in the Microsites landing page, which is accessed from the Pega Marketing portal
via: Content > Microsites
Note: Pega Marketing leverages Pega Platform's stage-based Case Management functionality for
building Microsites. Refer to official documentation for more details on this functionality.
Creating a Microsite
To create a new Microsite, use the Create button on the Microsites landing page.
Note: The Create button is only visible to users that have the CanCreateMicrosite Privilege. The
PegaNBAM_FW:MicrositeAdmin Access Role encapsulates this privilege and can be added to desired
Access Groups.
Provide a name and description for the Microsite. Users can also utilize the Advanced Settings
section to configure advanced options, such as inheritance and ruleset information.

Note: To nest the new Microsite under an existing one, select the existing Microsite in the Derives
From (Pattern) field (under Advanced Settings).
Upon clicking Submit, 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:
l 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.
l Display Microsite
In this stage, the Microsite is displayed to the customer. A new Microsite starts with a single page,
titled Page 1. Behind the scenes, the system has automatically 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. To do so, click the step in the stage to select it.
Then, click the Configure view button in the right pane to open the backing Section rule.
l Save Data

In this stage, values entered by the customer on Microsite pages are saved. This stage saves two
types of data:
Offer data – These values can later be used in the progressed Offer flow.
Custom Site data – These values are custom fields created and specified by the users. See
Defining and Using Custom Data Fields for details.
l 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.
l Confirmation
In this stage, a confirmation page is displayed to the customer. The identifier of the out-of-the-box
generated confirmation page Section rule is Confirm.
Note: The system performs identity matching at relevant stages in the Microsite case lifecycle. Refer
to the Identity Matching in Microsites section in the Identity Matching chapter for details.
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 + STAGE placeholder stage at the end to add a new stage.
Deleting a Stage
Use the Delete stage action from the drop-down menu in the stage header to delete an existing
stage. Hover over the header to see a down arrow icon. Click this icon to open the actions menu.
Reordering Stages
Use the drag icon in the stage header to move the stage to its desired location among other stages.
Configuring a Stage
Each stage can have one or more steps that it performs. Typical steps for Microsites are provided out-
of-the-box 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, the user can select the + STEP item in the steps area of a

stage. After the user specifies the desired page name, the system will automatically create the backing
structure (Flow, Flow Action, and Section).
To open the generated Section rule, users can select the page step and click the Configure view
button in the right pane.
Users can customize the section content to include any pertinent information to display to or gather
from the customer. The Next button in the section can be customized as well. This can be done by
overriding the NextButton section in the Microsite class and applying any desired styles to it.
In the Microsite stage view, the X icon on a step facilitates the deletion of the step while the four-
directional cursor allows for steps to be moved to their desired position within a stage. When a step
is deleted from a 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, select the process item (first item) in a stage and then use the Open
process link in the right pane to open the backing Flow rule for the selected stage.
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. Select More > Processes > Redirect Microsite and then click Select
3. Save the Microsite configuration.

4. Select the newly added step and click the Open process link in the right pane. This will open the
RedirectMicrosite Flow rule.
5. Create a copy of this Flow into your Microsite class.
6. Check out the specialized Flow.
7. Open the properties panel for the RedirectMicrosite utility shape.
8. Update the MicrositeClass parameter value to the class of the Microsite to redirect the customer
to.
9. Save the Flow and check it back in (if applicable).
Defining and Using Custom Data Fields

Users can define custom data fields to use in the pages of the Microsite. Any such field should be
defined in the PegaMKT-Data-Microsite class. In the following example, two data fields NewValue and
ProspectEmail have been defined in the custom data class.
These fields can then be used in a Microsite page to display or 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 data 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- and/or 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:
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 Pega 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.
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.
The Page1 Section rule 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.
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:
Microsite using Customer and Offer Data

The following Microsite serves as a basic example of utilizing the customer and Offer context.
This Microsite first loads 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.
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:

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.
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 public 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).
Tip: 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.
Manage Subscription Preferences Microsite

Pega Marketing 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 sample 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 a link to the Subscription Microsite, with the following additional notes:
l URL pattern: http://<server>:<port>/MS/index.html?Site=Subscription
l Since the Subscription Microsite is customer-specific, users must enable the Include Offer Data
checkbox.
A sample link configuration is shown below:

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.
Tip: To include additional items in the list of unsubscribe reasons, implementers should 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 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.

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.

Subscription Microsite Configuration

The Subscription Microsite is backed by the PegaMKT-Work-Microsite-Subscription class.
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.
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 rule 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:
l CustomerID
l 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:
l LastUpdatedOn – When the preference was last saved
l OfferIssue – Issue of the Offer, from which the Microsite was launched
l OfferGroup – Group of the Offer, from which the Microsite was launched
l OfferName – Name of the Offer, from which the Microsite was launched
l Preference – Subscription preference (true = subscribed, false = unsubscribed)
l Reason – Reason for unsubscribing
l Treatment – Name of the Treatment, from which the Microsite was launched

Chapter 17: 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 accessible in the Pega Marketing portal, via: Content > 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.
Geofence Management
This section explains the various modes available for managing Geofences.
Creating a new Geofence

Users can use the Create link in the Geofences landing page to create a new Geofence.
A new Geofence rule resembles the following:

The Geofence rule has the following tabs:
Tab Name Purpose

Design Specify the location details and radius of the Geofence. View other nearby fences.
History Specify the Description and Usage information for this Geofence.
Specifying Geofence Details

The following options are available for specifying the Geofence’s location:
l Address – Users can directly specify the desired address in the input box.
l 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:
l Zooming in and out
l Panning in all directions
l Using Street View
l Viewing satellite imagery
In addition to the above common interactions, the following Geofence-specific interactions are also
available:
l Dragging the Geofence pin to relocate the Geofence’s location. The details section will display
the new address and coordinates.
l 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.
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.
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 link on the
Geofences landing page to launch the Import Geofences process. The import process has the
following three stages:
Import
Use the Choose File 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.

Notes on the import file:
l File must be in CSV format
l 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
l Geofence Name must be provided
l Either location coordinates (latitude/longitude) or address (street/city/state…) must be provided for

each Geofence, but not both.
l Radius unit should be either “Miles” or “Kilometers”. If radius unit is not provided, it is defaulted to
“Kilometers”.
l If radius is not provided, it is defaulted to 1
Example Geofence entries:
l Using coordinates:
PegaBedford,2,Miles,42.928,-71.464,,,,,
l 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.
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 re-import the file after
addressing any errors.
Managing Conflicts
The system provides the following options for handling conflicts in the import process:

l 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.
l 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.
l 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 back-end creation (or
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.

Geofence Services
In addition to configuring Geofence rules in Pega 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 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 having to continually poll whether the current
location has tripped a Geofence.
The following two variants of the service exist:
l HandleMktPreferredFences HTTP Service
http://<host>:<port>/prweb/PRHTTPService/PegaMKTGeolocation/Services/HandleMktPreferredF
ences?Key=Closest&BaseLatitude=<DeviceLatitude>&BaseLongitude=<DeviceLongitude>&Closest
Count=<NumberOfGeofences>
l HandleMktPreferredFences REST Service
http://<host>:<port>/prweb/PRRestService/PegaMKTGeolocation/Services/HandleMktPreferredFe
nces/Closest?BaseLatitude=<DeviceLatitude>&BaseLongitude=<DeviceLongitude>&ClosestCount=
<NumberOfGeofences>
Both variants expect the following inputs:
l BaseLatitude – Latitude of the device
l BaseLongitude – Longitude of the device
l 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 Response Content Type

HTTP text/plain
(content is still JSON)
REST application/json
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 out-of-the-box 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:
l HandleMktGeolocations HTTP Service
http://<host>:<port>/prweb/PRHTTPService/PegaMKTGeolocation/Services/HandleMktGeolocatio
ns?CustomerID=<CustomerID1,2,..n>&DeviceID=<DeviceID1,2,..n>&DeviceLatitude=<DeviceLatitu
de1,2,..n>&DeviceLongitude=<DeviceLongitude1,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.
l HandleMktGeolocations SOAP Service
The following URL provides the WSDL for your this service:
http://<host>:<port>/prweb/PRSOAPServlet/SOAP/PegaMKTGeolocation/Services?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
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.

Chapter 18: 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 Multi-Channel Campaigns and can trigger their execution.
Real-Time Events are listed on the Events tab of the Real-Time Artifacts landing page. This landing
page is accessible in the Pega Marketing portal via: Content > Real-Time Artifacts
The Events landing page provides a quick overview of the Event rules configured in the application.
The landing page indicates whether an Event is active or inactive. 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

Users can use the Create link in the Events landing page to create a new Event rule.
A new Real-Time Event rule resembles the following:

The Event rule has the following tabs:
Tab Name Purpose

Event Details Specify the availability details for the Event and associate Geofences with the Event. View
Campaigns associated with this Event.
History Specify the Description and Usage information for this Event.
Specifying Event Details


l 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.
l 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 and 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.

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 Campaigns

Campaigns that have been associated to this Event are displayed in the Associated Campaigns
grid. Clicking an entry in this grid opens the Campaign work object. Refer to the Multi-Channel
Campaigns chapter for details on associating Events with Campaigns.
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
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 and time are valid). If so, any Campaigns that are associated with the events are
initiated. The payload for the Event (including customer id) is propagated to the Campaign, and from
there to the Strategy, and finally to the Offer. Refer to the Multi-Channel Campaigns chapter for more
information on associating Events with Campaigns.
Integration with Event Strategy Manager

Event Strategy Manager (ESM) is a Pega Platform feature that enables users to design and execute
event strategies that detect patterns in streams of customer data and react to these patterns by taking
the Next Best Action for the customer.
Further, users can integrate ESM with Pega Marketing Real-Time Events. This integration enables the
triggering of a Real-Time Event in Pega Marketing by an ESM Data Flow.
Pega Marketing provides integration support for ESM in a variety of deployment scenarios:
1. Pega Marketing and ESM are deployed on same instance, ESM Data Flows have access to the Pega
Marketing application.
2. Pega Marketing and ESM are deployed on same instance, ESM Data Flows do not have access to
the Pega Marketing application.
3. Pega Marketing and ESM are deployed on different instances.
In scenario 1, integrators can directly use a hook activity. For scenarios 2 and 3, integrators will need
to use an integration ruleset.
Directly use hook activity

In this scenario, the integration steps are minimal since the two components are both available as
part of the same application. To trigger a Real-Time Event from an ESM Data Flow, configure the
destination of the Data Flow to be the TriggerPegaMKTEvent activity.

Use the parameters of this activity to specify the values necessary for triggering the Real-Time Event,
such as EventName and CustomerID. The EventType parameter determines which Event service will
be invoked. Pass in either HTTP or SOAP for this parameter based on the protocol you wish to
utilize.
The SampleCEPDF Data Flow rule provides an example configuration that invokes the hook activity.
Use integration ruleset

In scenarios where the ESM application doesn't have access to Pega Marketing, integrators need to
first add the PegaMKT-Integration ruleset to their ESM application.
Note: The PegaMKT-Integration ruleset is provided in PegaMarketing_Integration_0722.zip, which is

located under the rules directory of your Pega Marketing installation.
This ruleset includes the following items that enable the triggering of Pega Marketing Events:
l TriggerPegaMKTEvent Activity rule - Use this activity (as described previously) to trigger a Real-
Time Event in Pega Marketing.
l ConnectMKTURL Dynamic System Setting - Update this setting to the URL where the Pega
Marketing application is deployed.
l MKT_Integration:SysAdmins Access Group - Update this access group to reference the application
that has access to the PegaMKT-Integration ruleset.

Chapter 19: Real-Time Containers

Real-Time Containers provide a way for marketers to manage content that appears in 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 Campaign. In real-time when the
Container is loaded (say on a web page), the associated Campaign is executed and the Container gets
populated.
Pega Marketing 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 listed on the Containers tab of the Real-Time Artifacts landing page. This
landing page is accessible in the Pega Marketing portal via: Content > Real-Time Artifacts
The Containers landing page provides a quick overview of the Containers configured in the
application.
Container Management
This section explains the various aspects of managing Real-Time Containers.
Creating a New Container

To create a new Container, use the Create link in the Containers landing page. Enter a unique name
for the Container in the short description field and click Create and open 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 Purpose

Container Details Specify the availability details for the Container; view Campaigns and Next-Best-Action
configuration associated with this Container.
History Specify the Description and Usage information for this Container.
Specifying Container Details


l Is this Container currently active?
Select Yes to enable the Container and have it respond to requests. Select No to prevent the
Container from responding to requests. If an inactive Container is requested, it will simply be
ignored.
l 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 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 impression capture API
(CaptureWebImpression).
l Click through behavior
This setting governs what happens when the channel invokes the click-through 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 the Offer is already in flight for the specified
customer, the particular Offer is loaded and Offer Flow execution is forced down the Inbound
path. If the specified Offer is not currently in flight for the specified customer, the system
instantiates a new Offer and starts executing the Offer Flow on it. This is done in the context of
the Channel that was part of the inbound request. Refer to Adding Inbound Channel Support for
more details.
Note: The click-through URL is configured on the Details tab of the Offer rule form. This URL can
also be over-ridden in the Strategy. For proper re-direction, this URL should begin with the
protocol prefix - such as http:// or https://.
Viewing Associated Entities

Real-Time Containers can be associated both with Multi-Channel Campaigns and Next-Best-Action
(NBA) configurations.

The Campaigns Associated with this Container section displays Campaigns that have been
associated with this Container. Refer to the Multi-Channel Campaigns chapter for details on
associating Containers with Campaigns.
The Next-Best-Action Strategies Associated with this Container section displays the NBA
configuration that has been associated with this Container. Refer to the Next-Best-Action chapter for
details on associating Containers with NBA.
Note: A Container can have multiple entities associated with it, as long as only one of them is active
at any given point in time.
The following table lists the information that displays for each entity - i.e. Campaign or NBA
configuration - associated with this Container:
Column Description
Associated Campaign / Name of the Campaign or NBA configuration, to which this Container is associated. Click
Associated Strategy the name to open the entity.
Enabled Whether the associated entity currently has Container processing enabled on it
Start Date Date and time when this Container becomes active for this entity
End Date Date and time when this Container stops being active for this entity
Status Current status of the associated entity
Real-Time Container APIs

This section provides information on the APIs available for use with Real-Time Containers.
When invoked, each API sets one of the following HTTP status codes in its response:

l 200 - Successful invocation
l 400 - Bad request
l 500 - Internal error
Container
Container is a REST service that supports the POST HTTP method. This service allows callers to trigger
a Real-Time Container. Unlike other Container services, this service supports the concept of a
centralized decisioning hub, where a Pega Marketing application behaves as the hub for decision
logic and any other Pega application can leverage Container features without being built on Pega
Marketing.
Note: This service supports identity matching only for the Web and Mobile channels.
The URL pattern for this service is:
http://<host>:<port>/prweb/PRRestService/PegaMKTContainer/V1/Container
Service Request
For the request, the service expects a JSON Object with the following attributes:
l CustomerID – Customer identifier (optional for the Web or Mobile channel)
l ContainerName – Name of the Container to trigger
l Channel – Channel where the Container will be rendered (optional)
l Direction – Direction of communication (optional)
A sample request JSON Object is shown below:
{
"ContainerName": "SampleContainerName",
"CustomerID": "SampleCustomerID",
"Channel": "SampleChannel",
"Direction": "Inbound"
}
Service Response
For the response, the service returns a JSON Object with the following attributes:

l Status – OK for successful result
l RankedResults - An array containing one or more Offers returned by Strategy execution. Each
Offer in this array has the following attributes:
Channel – Channel for communicating this Offer
Direction – Direction for communicating this Offer
Name – Name of the Offer
Issue – Issue to which the Offer belongs
Group – Group to which the Offer belongs
InteractionID – Interaction History record identifier for this Offer. This will be same for all 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.
Rank - Offer rank based on Strategy configuration
Propensity - Offer propensity value
Priority - Offer priority based on Strategy configuration
CampaignID - Work ID of the active Campaign associated with this Container
In case of an error, the response object instead contains the following two fields:
l Status – Set to ERROR
l Message – Description of the error
A sample response from the invocation of this service is shown below:

{
"Status": "OK",
"RankedResults":
[{
"Channel": "Web",
"Rank": 1,
"Direction": "Inbound",
"Group": "Handsets",
"CampaignID": "P-3968",
"Issue": "Sales",
"Propensity": 0.5,
"InteractionID": "-3457926003646498105",
"Priority": 0.5,
"Name": "SamsungGalaxyS4",
"ClickThroughURL": "",
"Label": "Samsung Galaxy S4",
},
{
"Channel": "Web",
"Rank": 2,
"Group": "Handsets",
"Issue": "Sales",
"Propensity": 0.5,
"InteractionID": "-3457926003646498105",
"Priority": 0.5,
"Name": "NokiaLumia",
"ClickThroughURL": "",
"Label": "Nokia Lumia",
}]
}
CaptureResponse
CaptureResponse is a REST service that supports the POST HTTP method. This service allows callers
to capture responses to Offers triggered via Real-Time Containers.
http://<host>:<port>/prweb/PRRestService/PegaMKTContainer/V1/CaptureResponse
This service can also be used to initiate the first offer in its request. To utilize this feature and include
offer initiation, use the following URL pattern:
http://<host>:<port>/prweb/PRRestService/PegaMKTContainer/V1/CaptureResponse/Initiate

Service Request
l CustomerID – Customer identifier
l ContainerName – Name of the Container that presented the Offer(s)
l RankedResults – An array containing Offers for which to capture responses. Each Offer in this list
should have the following attributes:
Name – Name of the Offer
Channel – Channel via which this Offer was communicated
Direction – Direction of communication for this Offer (e.g. Inbound)
Behaviour - Predefined behavior for the specified outcome (e.g. Positive, Negative, Neutral,
etc.)
Outcome - Response to record for this Offer (e.g. Accepted, Rejected, Impression, etc.)
InteractionID – Interaction History record identifier for this Offer
CampaignID - Work ID of the active Campaign associated with this Container

A sample invocation request is shown below:
{
"CustomerID": "CGS1234",
"ContainerName": "LatestOffer",
"RankedResults": [{
"Name": "PremierRewardsCard",
"Issue": "DemoIssue",
"Group": "DemoGroup",
"InteractionID": "-5352764169004433549",
"Outcome": "Accepted",
"Behaviour": "Positive"
"Channel": "Web",
"Direction": "Inbound"
}]
}
Service Response
For the response, the service returns a JSON object with the following attributes:
l Status – OK for successful result, Error otherwise
l Message – Confirmation message when successful, error message in case of an error
A sample service response is shown below:
{
"Status": "OK",
"Message": "Response captured successfully"
}
CustomerOfferHistory
CustomerOfferHistory is a REST service that supports both GET and POST HTTP methods. This service
returns the Interaction History records for a customer.
http://<host>:<port>/prweb/PRRestService/PegaMKTContainer/V1/CustomerOfferHistory
Service Request
l CustomerID – Customer identifier (required)

{
"CustomerID": "CONNOR",
}
Service Response
l OfferHistory – An array of History records for the customer. Each record contains the following
attributes:
Name - Name of the Offer
Issue - Issue to which the Offer belongs
Channel – Channel via which this Offer was communicated
Direction – Direction of communication for this Offer
ExternalID - Associated work object identifier
OutcomeTime - Time when the outcome was captured
Outcome - Response recorded for this Offer (e.g. Accepted, Rejected, Impression, etc.)
Behaviour - Behavior of the specified outcome (e.g. Positive, Negative, Neutral, etc.)
Identifier - Identifier for the Offer
Note: For Negotiation history records, there is a nested OfferHistory element which is an array of
Offer names.
A sample service response is shown below:

{
"OfferHistory": [
{
"Name": "Negotiation",
"Issue": "Negotiation",
"Channel": "CallCenter",
"InteractionID": "7382338912749122452",
"ExternalID": "S-13805",
"OutcomeTime": "20160225T125501.526 GMT",
"Behaviour": "Negative",
"OfferHistory": [
{ "Name": "Handsets_fromGoogleNexus4" },
{ "Name": "DataPlan100Min" },
{ "Name": "MemoryCard_V2_M3" }
],
"Outcome": "Rejected",
"Identifier": "/Negotiation/Negotiation/Negotiation",
"Group": "Negotiation"
},
{
"Name": "MI",
"Issue": "Sales",
"Channel": "CallCenter",
"InteractionID": "-7714067498846096636",
"ExternalID": "",
"OutcomeTime": "20160224T101058.055 GMT",
"Behaviour": "Positive",
"Outcome": "Accepted",
"Identifier": "/Sales/Handsets/MI",
"Group": "Handsets"
}]
}
ExecuteContainer
ExecuteContainer is a generic channel REST service that supports the POST HTTP method. This service
allows callers to trigger a Real-Time Container.
http://<host>:<port>/prweb/PRRestService/PegaMKTContainer/Services/ExecuteContainer
Service Request

l Channel – Channel where the Container will be rendered
l Direction – Direction of communication (optional)
l CurrentPage – Current page that the end-user is visiting (optional)
l PreviousPage – Previous page visited by the end-user (optional)
A sample service request is shown below:
{
"Channel": "Web"
}
Service Response
l Status – OK for successful result
l CustomerID – Validated identifier of the customer
l ContainerName – Validated name of the triggered Container
l Channel – Communication channel
l Direction – Direction of communication
l OffersList - An array containing one or more Offers. Each Offer in this array has the following
attributes:
OfferID – Name of the Offer rule
CampaignID - Work id of the active Campaign for this Container
Rank – Rank of the Offer as determined by Strategy execution

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 case of an error, the response object instead contains the following two fields:
l Status – Set to Error
l Message – Description of the error
A sample response from the invocation of this service is shown below:
{
"Status": "OK",
"Channel": "Web",
"OffersList": [{
"OfferID": "PremierRewardsCard",
"OfferName": "Premier Rewards Card",
"ImageURL": "ad-imgs/PremierRewardsSmall.jpg",
"InteractionID": "-5352764169004433549",
"ClickThroughURL":
"<yourmktserver>:<port>/prweb/PRHTTPService/PegaMKTContainer/Services
/CaptureClickThrough?Px=<encryptedurlstring>"
}]
}
ExecuteMobileContainer
ExecuteMobileContainer is a REST service that supports the POST HTTP method. This service allows
callers to trigger a Real-Time Container from a mobile application.

http://<host>:<port>/prweb/PRRestService/PegaMKTContainer/Services/ExecuteMobileCont
ainer
Service Request
l Intent – Intent for which the Strategy needs to be executed (optional)
l AdvertisingID – Used to identify the mobile device (optional)
{
"Intent": "Retention",
"AdvertisingID": "M3445432"
}
Service Response
The response from this service is identical to that from the ExecuteContainer service, with the
following exceptions:
l Channel is always Mobile, Direction is always Inbound
l ClickThroughURL references the CaptureMobileClickThrough service
Note: If the Container is configured to capture impressions on retrieval, the

ExecuteMobileContainer API will automatically capture impressions for all Offers that are returned as
part of the Container’s response.
ExecuteWebContainer
ExecuteWebContainer is a REST service that supports the POST HTTP method. This service allows
callers to trigger a Real-Time Container for the Web channel.

http://<host>:<port>/prweb/PRRestService/PegaMKTContainer/Services/ExecuteWebContai
ner
Service Request
l CustomerID – Customer identifier (optional)
l CurrentPage – Current page that the end-user is visiting (optional)
l PreviousPage – Previous page visited by the end-user (optional)
{
"CurrentPage": "ViewOffers",
"PreviousPage": "SignOut"
}
Service Response
The response from this service is identical to that from the ExecuteContainer service, with the
following exceptions:
l Channel is always Web, Direction is always Inbound
l ClickThroughURL references the CaptureWebClickThrough service
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.
Returning Custom Properties in ExecuteWebContainer Response

Application implementers can perform the following steps to return custom properties in the JSON
response of the ExecuteWebContainer service:
1. Create properties to return in response under the Embed-PegaMKT-Container-OfferDetails class.
2. Copy the TransformSROutput Data Transform rule into the implementation ruleset.

3. In the Pages & Classes tab of this rule, update the Class for the PublicComponent.pxResults
entry to be the implementation layer's SR class.
4. In the Definition tab of this rule, add mappings for the properties to include in the JSON
response.
CaptureMobileImpression
CaptureMobileImpression is a REST service that supports the POST HTTP method. This service allows
callers to capture impressions for a list of Offers on the Mobile channel. This service is typically
invoked when the Container’s automatic impression capture setting is disabled.
http://<host>:<port>/prweb/PRRestService/PegaMKTContainer/Services/CaptureMobileImpr
ession
Service Request
For the request, this service expects a JSON Object with the following attributes:
l ContainerName – Name of the rendered Container
l OffersList – An array of Offers for which to capture impressions. Each Offer should have the
following attributes:

{
"OffersList":[{
"Group": "DemoGroup"
"InteractionID": "-5352764169004433549"
}]
}
The captured impression will automatically be associated with the "Mobile" channel and the
"Inbound" direction.
Service Response
For the response, this service returns a JSON Object which contains the following attributes:
l Status - OK for successful result, Error otherwise
l Message - Confirmation message when successful, error description in case of an error
CaptureWebImpression
CaptureWebImpression is a REST service that supports the POST HTTP method. This service allows
callers to capture impressions for a list of Offers on the Web channel. This service is typically invoked
when the Container’s automatic impression capture setting is disabled.
http://<host>:<port>/prweb/PRRestService/PegaMKTContainer/Services/CaptureWebImpres
sion
Service Request
For the request, this service expects a JSON Object with the following attributes:
l ContainerName – Name of the rendered Container
l OffersList – An array of Offers for which to capture impressions. Each Offer should have the

{
"OffersList":[{
"InteractionID": "-5352764169004433549"
}]
}
The captured impression will automatically be associated with the "Web" channel and the "Inbound"
direction.
Service Response
For the response, this service returns a JSON Object which contains the following attributes:
l Status - OK for successful result, Error otherwise
l Message - Confirmation message when successful, error description in case of an error
CaptureClickThrough
CaptureClickThrough is an HTTP service that allows callers to request the handling of a click on the
Container for a generic channel. 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.
To invoke this service, callers must use the ClickThroughURL that was returned for the Offer by the
ExecuteContainer API.
The invocation URL for this service resembles the following:

http://<yourmktserver>:<port>/prweb/PRHTTPService/PegaMKTContainer/Services/Capture
ClickThrough?Px=<encryptedurlstring>"
CaptureMobileClickThrough
CaptureMobileClickThrough is an HTTP service that allows callers to request the handling of a click on
the Container for the Mobile channel. 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.
ExecuteMobileContainer API.
MobileClickThrough?Px=<encryptedurlstring>"
CaptureWebClickThrough
CaptureWebClickThrough is an HTTP service that allows callers to request the handling of a click on
the Container for the Web channel. 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.
ExecuteWebContainer API.
WebClickThrough?Px=<encryptedurlstring>"
CaptureResponse (Legacy)
CaptureResponse is a REST service that supports the POST HTTP method. This service allows callers
to capture responses to Offers triggered via Real-Time Containers.
http://<host>:<port>/prweb/PRRestService/PegaMKTContainer/Services/CaptureResponse

Service Request
l ContainerID – Name of the Container that presented the Offers
l OffersList – Array of Offers for which to capture responses. Each Offer in this list should have the
Outcome - Response to record for this Offer (e.g. Accepted, Rejected, Impression, etc.)
Behaviour - Predefined behavior for the specified outcome (e.g. Positive, Negative, Neutral,
etc.)
Channel - Channel via which this Offer was communicated
Direction - Direction of communication for this Offer (e.g. Inbound)

{
"CustomerID" : "CGS1234",
"ContainerID" : "LatestOffer",
"OffersList": [{
"InteractionID" : "-5352764169004433549",
"Outcome" : "Accepted",
"Behaviour" : "Positive"
"Channel" : "Web",
"Direction" : "Inbound"
}]
}
Service Response
For the response, the service returns a JSON Object with the following attributes:
l Status – OK for successful result, Error otherwise
l Message – Confirmation message when successful, error message in case of an error
CaptureWebResponse
CaptureWebResponse is a REST service that supports the POST HTTP method. This service allows
callers to capture responses to Offers triggered via Real-Time Containers for the Web channel.
http://<host>:<port>/prweb/PRRestService/PegaMKTContainer/Services/CaptureWebRespo
nse
This service is a specialization of the legacy CaptureResponse service. It defaults the Channel to "Web"
and the Direction to "Inbound" for each Offer.
Sample Container Invocation Script

To facilitate the invocation of Real-Time Container APIs, Pega Marketing includes an out-of-the-box
sample JavaScript file - webwb/RealTimeContainerScript.js

This script includes a service controller object which has methods that invoke the various Container
APIs.
To utilize this script, perform the following steps:
1. Download and copy the JavaScript file to your web directory.
2. Include the file in your web content. For example:

<script src="realtimecontainerscript.js" />
3. Instantiate the service controller object. For example:

var nbamServiceCtrl = getNBAMServiceControl();
4. Initialize the service controller object using one of the following mechanisms.
a. Directly update serverHostName and serverPort in realtimecontainerscript.js, as shown in the

snippet below. When using this mechanism, the instantiation of the service controller (Step 3
above) will already initialize the controller using these values.
var serverHostName = "localhost";

var serverPort = "8080";
b. Invoke the initialize method on the service controller after instantiating it. For example:
nbamServiceCtrl.initialize(window.location.hostname,
window.location.port);
5. Invoke the desired API using the corresponding service controller method.
Service API JavaScript Method Method Parameters

ExecuteWebContainer getOffers customerID, containerName, channel, previousPage,
currentPage, callback
CaptureWebImpression captureSingleWebImpression containerID, customerID, offerID, issue, group, interactionID,
callback
CaptureWebResponse captureWebResponse containerID, customerID, offerID, issue, group, interactionID,
outcome, behaviour, channel, direction, callback
CaptureResponse captureResponse containerID, customerID, offerID, issue, group, interactionID,
outcome, behaviour, channel, direction, callback
The following snippet shows an example invocation of the ExecuteWebContainer API to get the list
of Offers to display in the Container:

nbamServiceCtrl.getOffers("CGS1234", "LatestOffer", "Web", "Login",

"Home", handleResponse);

Chapter 20: Prospects

In marketing terms, a prospect is a potential customer, which the marketing user wants to target.
Pega Marketing provides support for importing Prospect Lists, creating Prospect Segments, and
targeting prospects via Campaigns.
Configuring the Prospect Class

Application administrators need to configure the class for storing prospects in the system.
Administrators should follow the guidelines below while configuring this class:
l 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.
l The base prospect class can be used (without customizations) if the prospect lists to be imported
will obey the shipped structure.
l 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)
l 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.
l 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.
l If a custom prospect class is used, copy the following rules into the extended prospect class.
Prospect Data Set
ProspectListImportResults Report Definition

Importing Prospect Lists

Prospect lists can be imported into the application via the Prospect Lists landing page. This landing
page is accessible in the Pega Marketing portal via: Configuration > 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 (in the Actions menu) 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:

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:
l 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.
l 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.
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 and open 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:
l Analytical criteria (both modeled and static) are not available for prospect-based Segments.
l 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.
Targeting Prospects in Campaigns

Users can target prospects with their marketing Campaigns. To do so, select Prospect as the Target
audience type when creating a new Multi-Channel Campaign.
When selecting the Campaign's audience, the user must select a prospect-based Segment. For the
Campaign'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 Campaigns. 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.

Chapter 21: 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:
l Campaign execution
l Offer execution
l Personalized email delivery
l Personalized SMS delivery
Each of these modes of testing is explained in the chapter pertaining to the entity being tested (e.g.
Campaigns, Offers, etc.).
Seed Lists are listed under the Seed Lists landing page, which is accessible in the Pega Marketing
portal via: Configuration > Segmentation > Seed Lists
The following actions are available on the Seed Lists landing page:
l Create – Create a new Seed List. See Creating a new Seed List.
l Refresh icon – Reload the Seed List grid
l Help – View context-sensitive help
l Close icon – Close the landing page

In addition, the Update Seed List Columns operation is available in the Manage Data
Relationships tab of the Application Settings landing page. See Updating Seed List Columns for
details.
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 Create link on the landing page. Enter a unique name for the
Seed List and a helpful description of its contents.
Click Submit to create the Seed List. At this point, the backing structure of the Seed List is created.
The landing page 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, double click a Seed List row in the grid. 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 icon. Fill in all necessary fields and click anywhere outside the input row to
save the record. To cancel your changes and discard the new record, click the delete icon
at the right end of the row.
Modify an existing seed Click anywhere in the desired row. The row should toggle to editable mode. After making
the desired changes, click anywhere outside the row to save your changes.
Delete an existing seed Click the delete icon at the right end of the row.
Using the SegMap column

The SegMap column is present in all Seed Lists. This column is utilized by the Segments within
Strategies feature while performing Seed Tests in Multi-Channel Campaigns. If your Strategy
uses this feature, set the SegMap column to a colon delimited string of all Segments to which the
seed belongs.
Note: Ensure that the SegMap string ends with a colon.
An example configuration is shown below:

Deleting a Seed List

Existing Seed Lists can be deleted by using the row-level delete icon in the grid on the Seed Lists
landing page.
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 use with Seed Lists. In
a situation like this, administrators can synchronize the Seed List structure to the customer class
structure via the Update Seed List Columns button on the Manage Data Relationships tab of the
Application Settings landing page.
Upon clicking this button, the backing Seed List structure will be synchronized with the customer
class.
This task should typically be performed by the administrator and will impact all existing Seed Lists.
This task should be performed in the following scenarios:
l Initially after a new install
l Whenever the customer class changes
l When attributes are added to (or removed from) the customer class and these changes need to be
reflected in the seed data
The administrator can also use the Seed List Definition link to view the current Seed List structure.
Clicking this link opens the SeedListPopulationRD Report Definition, which represents the structure
utilized by the Seed List editor. If desired, administrators can directly modify this Report Definition to

update the columns visible in the Seed List editor. However, any manual updates to this Report
Definition will be overwritten when the Update Seed List Columns button is used on the landing
page.

Chapter 22: Exclusion List

The exclusion list feature in Pega Marketing automatically prevents outbound contact with a specified
set of customers. This can be used to address various business needs, such as handling opt-outs,
unsubscribes, and bounce backs.
The implementation of the exclusion list functionality utilizes the Segment rule. This enables
marketers to use the power of segmentation to build a global list of customers to exclude from
outbound communication. When a global exclusion list is specified in the system, outbound
processing evaluates target recipients against the exclusion list and ignores those recipients that are
in the exclusion list.
Exclusion list membership is checked during offer initiation and wait expiration in outbound paths.
These include the following:
l Scheduled and event-based Multi-Channel Campaigns
l Outbound Campaigns
l Field Campaigns
Configuring the Global Exclusion List

The exclusion list feature is disabled by default. To enable the feature, the marketing administrator
simply needs to specify a value for the Global Exclusion List Segment on the Configuration
Settings tab of the Application Settings landing page. This landing page is accessible in the Pega
Marketing portal via: Configuration > Settings > Application Settings
The exclusion list Segment can be any customer-based Segment in the system. Marketers can utilize
the rich feature set of the Segment functionality to construct the exclusion list Segment. Furthermore,
the scheduling capability of Segments provides marketers with the ability to keep their exclusion list
up to date.

A sample exclusion list Segment configuration is shown below. In this example, the exclusion list
contains all customers that have either opted out or have had bounce backs.
To disable the exclusion list feature, the administrator simply needs to clear out the aforementioned
configuration setting.
Note: Whenever a change is made to the exclusion list configuration setting, all event-based
Campaigns need to be suspended and re-submitted for execution.
Ignoring the Exclusion List

There may be a need to not apply the exclusion list in certain scenarios. Pega Marketing allows
authorized users to override the application of the exclusion list. This authorization is controlled by
the MKTOverrideExclusion privilege, which is granted to marketing managers and administrators via
the PegaNBAM_FW:MarketingManager role.
Multi-Channel Campaigns
For Multi-Channel Campaigns, the ignore exclusion list option is available in the Plan tab when the
audience type is customer.

Outbound Campaigns
For Outbound Campaigns, the ignore exclusion list option is available in the Campaign details
section.
Field Campaigns
For Field Campaigns, the ignore exclusion list option is available in the Field Marketing Details
section of the Campaign's backing Offer Template.

Chapter 23: 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
Campaign.
The Checklists widget displays existing Checklists in the system. Users wishing to utilize Checklists
should add this widget to their home page. The Create link in this widget enables users to create
new Checklists. 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.
Note: Checklists associated with Offers can be seen in the Checklists tab on the Offer rule, while
those associated with Multi-Channel Campaigns can be seen in the overview pane in the Campaign
display.

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:
l Checklist Header
l Checklist Details Panel
l Tasks Panel
l Links Panel
l Pega Pulse panel

Checklist Header
The Checklist header displays the following information about the Checklist:
l Name
l Work ID
l Status
l 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:
l Description
l Associated with - Provides a link to the associated Offer or Campaign.
l Owner

l Percent Complete - Completion percent of this Checklist which is calculated by averaging the
completion percent of the child Tasks.
l Issue
l Group
l Start Date
l 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:
l Help - View the help topic for Checklists.
l History - View a historical record of the various actions that have been performed on this
Checklist.
l Follow - (For managers) Mark this Checklist as an item to follow. Followed items are displayed in
the “Following” list in the Case Manager portal.
l Unfollow - (For managers) Remove this Checklist from the list of followed items.

l Tags - Manage the tags associated with this Checklist. 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.
l Start Checklist - Start working on this Checklist. This item is only shown for new Checklists.
l Reopen Checklist - Reopen a Checklist. This item is only shown for completed or withdrawn
Checklists.
Pega Pulse panel

The Checklist display also includes the Pega Pulse panel. Pega Pulse provides a mechanism for users
to collaborate while they work on work objects by sharing messages, files, and links with other users.
Refer to Pega Platform documentation for details on Pega Pulse.
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 modal window.

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.

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.
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.
Task Display
The Task display can be accessed in the following ways:

l By clicking the link on the Task name in the Tasks panel on the Checklist display.
l By opening Tasks that are assigned to you from your work list.
The following shows a typical Task display:
The Task display can be split into the following pieces:
l Task Header
l Task Details Panel
l Links Panel

Task Header
The Task header displays the following information about the Task:
l Name
l Work ID
l Parent Checklist name and work ID - Contains link to parent Checklist
l Status
l 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
The Task Details panel displays the displays the following information about the Task:
l Description
l Owner

l Percent Complete
l Start Date
l Due Date
l Issue
l Group
l Estimated Effort
l Actual Effort
l Remaining Effort
Links Panel
The Links panel contains various useful links, including the following:
l Help - View the help topic for Tasks.
l History - View a historical record of the various actions that have been performed on this Task.
l Follow - (For managers) Mark this Task as an item to follow. Followed items are displayed in the
“Following” list in the Case Manager portal.
l Unfollow - (For managers) Remove this Task from the list of followed items.
l 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.
l Start Task - Start working on this Task. This item is only shown for new Tasks.
l Reopen Task - Reopen a Task. This item is only shown for completed or withdrawn Tasks.

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:
l 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.
l 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.

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 added to the Pega Pulse feed. 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 added to the Pega Pulse feed. 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.

Chapter 24: Email and SMS Account Configuration
Chapter 24: 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:
l Configuring an Outbound Email Account
l Configuring an Outbound SMS Account
l Specifying Delivery Time Frames
l Configuring an Inbound SMS Account
Configuring an Outbound Email Account

The Outbound tab on the Email landing page lists the various outbound email accounts that are
configured in the system. This landing page is accessible in the Pega Marketing portal via:
Configuration > Settings > Channels > Email
The following two accounts should already be present in your application:
l Default: System-wide default account for sending emails. This account is also the default account
for sending Email and Passbook Treatments in Offers.
l PegaMKT-Work: This account is used to send Campaign-centric emails (such as Campaign

Approved, Campaign 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 icon on the
account row. To view or 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.
In addition to these two accounts, other accounts can be created via the Add new link on the landing
page. These accounts can then be referenced as the delivery account in the Send Email, Send
Passbook, and Send Multi shapes in an Offer.
A sample outbound email account configuration is shown below:
Refer to Specifying Delivery Time Frames for details on configuring availability options for the
account.
Configuring an Outbound SMS Account

The Outbound tab on the SMS landing page lists the various outbound SMS accounts that are
Configuration > Settings > Channels > SMS
The following account is shipped with the marketing application:
l Default: This is the default account for sending SMS Treatments in Offers.

Administrators should configure this account appropriately to ensure proper delivery of SMS
messages. To edit the account details, use the Edit link on the account row. To test the account, use
the Test link in the Connection column.
In addition to the Default account, other accounts can be created via the Add new connection
button on the landing page. These accounts can then be referenced as the SMS delivery account in
the Send SMS and Send Multi shapes in an Offer.
An outbound SMS account configuration is split into the following three tabs:
l Setup - The Setup tab is used to configure basic information about the SMS account, such as
name, address, port, etc.
Refer to Specifying Delivery Time Frames for details on configuring availability options for the
account.

l Advanced - The Advanced tab can be used to configure advanced account settings, such as
response timeout, character encoding, and reconnect options.
l Additional settings - The Additional settings tab enables the administrator to directly specify
additional SMPP configuration settings as name-value pairs. This provides a mechanism to set
SMPP properties which are not exposed in the Setup and Advanced tabs.
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
and SMS account details dialog.
The two availability options are:
l Always Available - This implies that this account is always available to deliver messages.
l Specify Range - This implies that this account will only deliver messages 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:
Configuring an Inbound SMS Account

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. In a
simpler scenario, users can choose to associate all responses to a particular account (inbox) with a
single Offer.
The Inbound tab on the SMS landing page lists the various inbound SMS accounts that are
Configuration > Settings > Channels > SMS

Use the Add new connection button on the landing page to create a new inbound SMS account.
Clicking this button opens the connection configuration modal window. This modal is split into three
tabs: Connection setup, Additional settings, and Response behaviors.
After creating an account, use the toggle control in the Running column to start and stop the
account. The Connection status column indicates the current status of the account.
Connection setup
This tab is used to specify the connection details for the inbound SMS account. This includes the
following settings:
Field Description
Account name Unique name for the Inbound SMS account
Host address Address for the SMSC host

Host port Port number for the SMSC host
Inbox address Address of inbox, on which to listen for responses
IP address IP address of the SMSC host
User ID, Authentication credentials to connect with the SMSC
Password
A sample configuration of this tab is shown below:

Additional settings
This tab enables the administrator to directly specify additional configuration settings as name-value
pairs. This provides a mechanism to set SMSC properties which are not exposed in the Connection
setup tab.

Response behaviors
This tab is used to specify how the application should process inbound SMS messages that are
received by this inbound SMS account.
Perform the following steps to configure the response behaviors for the account:
1. Select and configure the mechanism for matching received messages to responses. Choose from
the following options:
l One response
l Decision table
2. Specify how the system should handle un-inititated responses.
One response
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, use the Responses for inbound messages
section to specify the single response value and the Offer to associate with the response.
Decision table
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).
Use the Manage decision tables section to specify desired configuration options.
First, select between the following options:
l One offer – Select this option if all messages received on this inbox should be associated to a
single Offer. In this case, specify the Offer. This Offer name will be listed as the Offer for all result
entries in the decision table grid.

l Individual offers – 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. To add a new decision table, enter or select it from the
list of available decision tables and click Add decision 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 in the PegaMKT-
Work-Offer class.
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 un-initiated responses
to Offers.
The two options available are:
l Push it to a workbasket – 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 Offer that is not active for the customer, 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.
l Start the Offer for the customer – Select this option to initiate a new Offer for the customer if they
respond to an Offer that is not active for them.
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.

Chapter 25: 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.
Pega Marketing currently provides support for sending push notifications to apps running on the
following platforms:
l Android - Using Google Cloud Messaging for Android (GCM)

http://developer.android.com/google/gcm/index.html
l iOS - Using Apple Push Notification service (APNs)

https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteN
otificationsPG/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 l Creates mobile app, which: Outside of
Developer Registers and un-registers app users for receiving push notifications from the Pega
marketing application, via the provided REST services. See Push Notification User Marketing
Registration Services for details. (PM)
Receives and displays push notification messages to app users
l Deploys app on app platform (e.g. App Store, Google Play, etc.)
l Provides marketing administrator with key registration information for app
Marketing l Registers app for receiving push notification messages from Pega Marketing. See In PM
Administrator Registering Apps for Push Notification.
App User l Downloads and installs app from app store. Outside of PM
(Behind the scenes, app registers the user for receiving push notifications)
Marketing l Creates Offers and utilizes the Push Notification flow shape to send notification In PM
Analyst messages to registered app users. See Configuring Push Notifications in Offers.
Marketing l Handles registrations of apps In PM
System l Handles registrations/un-registrations of app users
l Delivers notification messages to registered users for registered apps

Registering Apps for Push Notification

Marketing administrators can register apps for receiving push notification messages from the
marketing application. This is done from the Applications tab of the Push Notifications landing
page. This landing page is accessible in the Pega Marketing via: Configuration > Settings >
Channels > Push Notifications
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 Purpose
Name Name of the app. This is how the app will be referred within the marketing application (e.g. in Offer flows).
Description Description of the app
Platform Platform on which this app is available. Choose between Android and iOS.
Unique ID Unique identifier for this app. This ID is used for validating push notification service requests, such as those
for registering and un-registering app users. See Push Notification User Registration Services for details.
For Android apps, additionally provide the following information:
Setting Purpose
Google Google key for this app. This value should be provided by the app developer and is required for using the GCM
Key service.

For iOS apps, additionally provide the following information:
Setting Purpose
App Apple .p12 certificate for this app. Use the Choose File button to locate the certificate.
Certificate
Certificate Name to use for storing the certificate in the system
Name
Certificate Password associated with the certificate. The system will validate this password and will not upload the
Password certificate in case the password is invalid.
Certificate Type of certificate. Select either Production or Development.
Type
Monitor Apple provides a feedback service which can be used to detect failed push notification message delivery when
Apple’s the user has uninstalled the app from their iOS device. Pega Marketing ships with an agent that periodically
notification polls the APNs feedback service to detect these errors. If any delivery errors are reported by the feedback
feedback service, the system un-registers the associated device registrations (as recommended by Apple), thereby
service? 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 un-registered from the marketing system.
Alternately, choose No to monitor the feedback service via an external system or mechanism. In this case, the
external mechanism should invoke the un-registration service to un-register 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/documentation/NetworkingInternet/Conceptual/RemoteNotificationsP
G
/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW3
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.
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.
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
image 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.
Using Push Notification with Passbook

Push Notification functionality can also be used in 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 Settings appendix 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 Purpose
Message Notification message to push to the customer’s registered device(s). This can be plain text or an expression.
Play Associate sound with the notification message. If this setting is enabled, the message payload references the
Sound? default sound. When the message is received by the device, the device-specific default sound for notifications (if
enabled) is played.
Key Marketing code to identify the shape. This value can be passed to the device along with the notification message
Code (as additional values).
A sample configuration for the general settings is shown below.
Application Configuration
The following settings are available in the Application Configuration section of the properties
panel for this shape:
Name Purpose
Default Determines whether the notification message should be pushed for the default app.
Application
Other Determines whether the notification message should be pushed for the specified app. Select the app to
Application notify from the drop-down 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 options are available in the Wait After Sending section for this shape:

Name Purpose
Wait 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.
Days Number of days to wait
Business Determines whether the wait duration should be in terms of business days or regular week days.
Days?
Hours Number of hours to wait
Minutes Number of minutes to wait
Seconds Number of seconds to wait
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 may not be delivered.
Enable the Send Additional Values? checkbox (in the Additional Details 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
can also be passed as an additional field (as shown in the example below).
Set Badge
The Set Badge? option (in the Additional Details section of the properties panel) 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.

Push Notification User Registration

Services
Pega 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:
l Registration Service
l 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:
l 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.
l PushToken - Token assigned by the platform messaging service that is used for pushing
notification messages for the selected app on the selected device.

l UserID - ID associating the app user with a customer in the system. In the out-of-the-box
implementation, the expected value for this field is the CustomerID property. Custom
implementations can override the mechanism by which this field is associated to a customer in
the system.
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.
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:
l 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.
l 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.

Chapter 26: 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 the Pega Marketing portal via: Reports > Customer 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.
Note: Marketing Profile can also be used to search for and review anonymous customers. Refer to
the Identity Matching and Marketing Profile section in the Identity Matching chapter for details.

Profile Elements
This section outlines the various elements of a customer’s Marketing Profile. This includes the
following:
l Customer Details
l Customer Dimensions
l Customer Demographics
l Propensity Scores
l 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.

Note: The Segments list for a customer does not display virtual Segments.
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:
l Communication – Customer’s email address and mobile phone number
l Demographics – Customer’s age, gender, and income
l Social Handles – Customer’s handle on various social media outlets

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:
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).
Marketing Profile Customization

Guidelines
This section provides guidelines for customizing the Marketing Profile to work with your application.
This includes the following topics:
l Displaying Next Best Action
l Displaying Top Offers

l 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 strategy rule 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 rule located in PegaMKT-Data-Customer
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:
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 rule located in PegaMKT-Data-Customer
3. Implement your Next-Best-Offer logic, arbitrating across the various types of Offers you plan to
make
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 a Pega Marketing strategy, perform one of the following
series of steps.
If you already have a CLV and Risk type strategy:
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 and Risk type strategy:
1. Open the MKTProfileDecisionResults strategy rule located in PegaMKT-Data-Customer
3. Implement your CLV and Risk logic as per your requirements

Chapter 27: Data Management

Pega Marketing enables marketers to manage customer, prospect, and associated data through the
Data Management landing page.
Marketers (with suitable permissions) can launch this landing page via the Manage Data link for a
particular entity (e.g. customer or prospect) on the Manage Data Relationships tab of the Application
Settings landing page.
Upon clicking this link, the Data Management landing page opens in the context of the launching
entity (e.g. customer). Marketers can utilize this landing page to perform the following actions:
l View and search for instances
l Manage individual instances
l Import instances
l Export instances
Viewing and Searching for Instances

The Data Management landing page displays a grid of instances of the data type, as shown below.

When the landing page initially opens, it displays the Default view. This view displays all externally
mapped properties for the data type. In this view, the first column in the grid is the key property of
the data type. The Default view for the customer entity has an additional feature. Marketers can click
the link value in the first (key) column in the grid to open the Marketing Profile for the corresponding
customer.
Implementers of the application can define other views to use with their data types. Marketers can
see the list of available views in the drop-down above the header and can switch to a different view
by selecting it in the drop-down and clicking the View button.
Tip: Each view is backed by a Report Definition in the entity's data class. For a Report Definition to
be available as a data view, it must have a custom field defined with the field name set to
DataManagement and the value set to Views.
Marketers can also search for particular instances by specifying the desired text in the search input
field above the grid and clicking the magnifying glass icon. The system performs the search across all
columns in the current view and displays the results in the data grid.
Marketers can also refine grid contents by using column filters.
Managing Individual Instances

Marketers can use the instances grid on the Data Management landing page to perform the following
actions:
l Add an instance - To add an instance, click the Add record link at the bottom of the grid. Fill in
all necessary fields and click anywhere outside the input row. To cancel your changes and discard
the new record, click the delete icon at the end of the row.
l Modify an instance - To modify an instance, click anywhere in the desired row. The row will

toggle to editable mode. After making the desired changes, click anywhere outside the row to save
the modified instance.
Note: The key value of an instance cannot be modified.
l Delete an instance - To delete an instance, click the delete icon at the end of the row.
Note: Access to add, modify, or delete data instances is managed by standard Pega Platform
security constructs. Administrators can utilize these constructs to grant or restrict access as needed.
Importing Instances
Marketers can utilize the import mechanism on the Data Management landing page to import
multiple instances using a comma-separated-values (CSV) file.
To initiate an import, click the Import link above the instances grid.
Note: The Import link is disabled if a data import is already in progress for the data type.
At a high level, the import process has the following three steps:
1. Upload CSV file and select one of the following import purposes:
a. Add or update - Use this option to create new records for those instances in the import file that
don't currently exist in the system, and to update records for those instances that do exist.
b. Add only - Use this option to only create new records for those instances in the import file that
don't currently exist in the system. Records for existing instances will not be updated.
c. Delete- Use this option to delete matching records from the system.
2. Map fields - Select the field to use for matching records and specify the mappings for all fields to
import.
3. Import records - Trigger the import process. Optionally, choose to save the specified field
mappings for subsequent imports.
Tip: The import process utilizes the Data Management functionality of the Pega Platform. Use the
help icon in the wizard to launch the Pega 7 Help topic for details on this process.
When importing large files, the import progress can take some time. Marketers can close the import
window and continue with other activities. The system displays the status of the import at the top of
the Data Management landing page. Once the import completes, the system displays the number of

instances that were added or updated by the import. If there were errors during the import, the
number of erroneous records is also shown.
Click the See more link to download a CSV file containing the records which failed to import. The last
column in this file contains a description of the error that occurred.
Note: Import functionality is not currently supported for prospect data from the Data Management
landing page. Users can import prospects from the Prospect Lists landing page. Refer to the
Prospects chapter for details.
Exporting Instances
Click the Export link above the instances grid in the Data Management landing page to export a CSV
file containing data instances represented by the currently selected view.
Note: Export functionality is not currently supported for prospect data.

Chapter 28: Revision Management

Revision Management is a Pega Platform feature that enables business users (such as marketers) to
take ownership of parts of the enterprise application. Marketers can make controlled changes in the
business sandbox and test these in production within the boundaries defined by IT. Refer to official
Revision Management documentation (DMSample Cases - Revision Management) for details on
various features, such as the roles involved and the actions they can perform in Revision
Management.
Revision Management enables marketing users to revision, package, and import marketing artifacts.
The DecisionManager:PegaMarketing role facilitates Revision Management in the Pega Marketing
portal. This role is automatically added to the RevisionManager and StrategyDesigner access groups
for overlays created for Pega Marketing applications.
Most marketing artifacts can be included and updated in revisions using the processes described in
the Revision Management guide. Revision managers can start a new Revision and create Change
Requests within the Revision. A Change Request can contain marketing rules and can be assigned to a
marketer. The My Work widget (shown below) and the Revision Management widget enable
marketers to view their assigned Change Requests.
Revision Management Widget

Marketing users can also add the Revision Management widget to their Home page in the Pega
Marketing portal.

This widget displays Change Requests that are assigned to the user and lists each rule within the
request. Users can click Edit to open the rule directly from the widget.
Segments and Samples

Segments and Samples are handled differently in Revision Management in order to preserve data
integrity between their definition and stored results. Rules of these two types, included in the overlay,
are listed in the Segmentation tab (under Rules) on the Revision Management landing page. This
landing page can be accessed via the Revision Management link in the Pega Marketing portal.

Users can directly open these rules from the grid shown above. Unlike other rule types, these rules
will need to be checked out before they can be updated. Once the rule has been updated, it should be
checked back in.
These rules can be managed in the following two ways:
l Included with an existing Revision
l Packaged directly
Included with an existing Revision

If there is an active Revision, updated Segments and Samples will automatically be associated with
the Revision. The Revision object displays the list of included Segments and Samples along with their
current status. An In progress status indicates that the rule is currently checked out, while Updated
indicates that the rule is checked in.
No special action is required to package these rules as they will be included in the revision package
which is generated upon completion of the Revision.

Packaged directly
Even when there isn't an active Revision, users can open and modify Segments and Samples. In such
a case, once all modified rules have been checked in, revision managers can utilize the Package
rules... button to package these rules directly from the Segmentation tab in the Revision
Management landing page.
Clicking this button automatically generates a Revision, completes it, and makes the revision package
available.
Importing Revision Packages

Basic revision packages can be imported following the prescribed Revision Management process.
However, revision packages that contain any of the following rule types require an additional
configuration during import to prevent compromising live data.
l Output Templates
l Segments

l Samples
l Volume Constraints
For such packages, the optional test phase of the import process must be skipped by enabling the
Skip test phase checkbox in the Review contents stage.
After the import is complete, the following actions are recommended for such packages:
l Run imported Segments and Samples to apply the latest definitions.
l Review imported Volume Constraints and determine if any of the manually reset constraints
should be reset.
Note: For marketing rules that support scheduling (Segments, Samples, Analysis Projects, Output
Templates), the import process retains the schedule configuration (if configured) on the destination
environment.

Chapter 29: Identity Matching

Identity matching is a feature that allows a Pega Marketing application to identify individuals across
their addressable devices. This feature also enables a seamless transition between an anonymous
individual and a recognized customer.
When an individual is anonymous (e.g. not logged in), relevant information is captured during their
various interactions with the application. This information can then be utilized to determine the Next-
Best-Action for this individual. When the individual authenticates themselves as a customer, their
anonymous interaction data is merged with their previous interaction history. This allows the
marketing application to maintain a complete view of the customer journey.
Identity matching is incorporated in the following functional areas:
l Email
l Microsites
l Real-Time Containers
Identity matching utilizes browser cookies to store identifying information. For individuals yet to be
identified, a unique id is stored in the cookie. Once an individual has been identified as a customer,
their (encrypted) customer id is stored. During the individual's interactions with the application,
additional data is collected and associated with the appropriate identifier (customer id or unique id).
The captured associations are specific to the functional area and are listed in the corresponding
section.
Identity Matching in Email

Identity matching occurs when users open and respond to marketing emails sent via the application.
The following associations are captured when a customer opens a marketing email (handled by the
IMPR service):
l CustomerID ↔ UniqueID
l CustomerID ↔ Email Address
l CustomerID ↔ IP Address

l UniqueID ↔ Email Address
l UniqueID ↔ IP Address
The following associations are captured when a user clicks on a response link in a marketing email
(handled by the PORE service):
l UniqueID ↔ IP Address
Identity Matching in Microsites

Identity matching also allows marketers to track unidentified customers and their interactions with
Microsites. When an anonymous individual visits a Microsite, the system identifies the individual
with a unique identifier. Later, when customer information is available to the Microsite, the system
associates the anonymous user's interactions with the customer.
The following associations are captured during interactions with the Microsite:
l CustomerID ↔ Email Address
l UniqueID ↔ Email Address
Identity matching in Microsites is handled by the following stages in the lifecycle:
1. Load Data - In addition to loading customer data, this stage also saves the aforementioned
association data. For example, if the browser cookie contains the unique id but the Microsite is
aware of the customer, this stage associates the unique id and the customer id. Additionally, the
cookie is updated with customer information.
2. Confirmation - In this stage, the Perform Identity Matching step associates available Microsite
attributes. For example, if the Microsite collects email information, this information is associated

with the available identifier (customer id or unique id).
Note: To perform identity matching during a different stage, include the Perform Identity Matching
step in that stage.
In addition to the above stages, identity matching also occurs in the following areas in Microsites:
l Impression capture - When the section RecordImpressionForMicrosite is included in a Microsite

stage to capture impressions, it calls the IMPR service. For anonymous users, this service records
the impression using the unique id.
l Launching another Microsite - When a Microsite launches (or redirects to) another Microsite,
identity matching attributes - such as customer id or unique id - are propagated to the new
Microsite.
Note: If the Perform Harness rule is specialized in the new Microsite class, ensure that the
IdentityMatchingConfiguration Section rule is included in this Harness. This section enables the
Internet Application Composer (IAC) gadget to update the browser cookie.
Identity Matching in Real-Time Containers

Identity matching also allows marketers to track anonymous individuals and their interactions with
Real-Time Containers. When a marketer defines a Container to represent a portion of a web page, the
Container uses browser cookies to perform identity matching.
The following associations are captured during interactions with the Real-Time Container:
Additionally, identity matching is implicitly performed by the following Real-Time Container services:
l Container - Only for the Web channel
l ExecuteWebContainer

l CaptureWebImpression
l CaptureWebClickThrough
Identity Matching and Marketing Profile

Marketers can use Marketing Profile to search for anonymous users and view their interactions with
the marketing application.
Note: To allow for the searching of anonymous users, the MKTProfileEnabled When rule must be
enabled (i.e. set to true).
The Marketing Profile search functionality provides an additional Search by UID checkbox to allow
for searching of anonymous users.
When this checkbox is unchecked, the search looks for existing customers based on their identifier
and name.
When this checkbox is checked, the search looks for anonymous customers using their unique
identifier.
Upon clicking the link for the anonymous customer, their interaction details are displayed.

At a later point, if the anonymous individual identifies themselves as a known customer, the
anonymous interaction details are merged with the customer's interaction history. Searching for the
anonymous individual (by their unique id) now reveals the identified customer in the search results.

Chapter 30: Paid Media Manager

Marketers can use Paid Media Manager for Pega Marketing to apply Next-Best-Action to advertising-
driven interactions on paid destinations such as Facebook Ads, Google AdWords, and web-based
advertising platforms such as Demand Side Platforms. Paid Media Manager provides customers with
a personalized, consistent, and coordinated experience across both owned and paid channels.
Paid Media Manager is included in Pega Marketing 7.31. You can enable it with the appropriate
license on top of the Pega Marketing 7.31 license.
Next-Best-Action-driven Paid Media Audiences

Paid Media Manager uses audiences on advertising platforms as a mechanism to communicate
which offers have been selected for each customer based on Next-Best-Action. When Next-Best-
Action selects an offer for a customer, the customer is placed in the corresponding Paid Media
Audience. If the next strategy execution selects them for a different set of offers, the customer is
removed from the Paid Media Audiences corresponding to the previous offers and added to the new
ones.
After Next-Best-Action adds customers to a Paid Media Audience, they are targeted with
corresponding advertisements at the specified priority. For example, a customer may be in a Paid
Media Audience for mortgage - high propensity and travel credit card – low propensity based on the
strategy results. The advertising campaigns that target each of these audiences are configured with
the appropriate advertising creative assets and the proper bidding threshold that is appropriate for
the given offer and priority.
Paid Integration Methods

Within Pega Marketing, paid destinations represent accounts on advertising platforms where Paid
Media Audiences can be sent. Synchronize Paid Media Audiences with paid destinations using one or
more of the following integration mechanisms:
l CRM Matching-based Destinations
l File-based Destinations
l Web-based Paid Destinations

CRM Matching-based Destinations
Modern media platforms offer the ability to associate users to an audience by comparing a hashed
version of an email address or other personally identifiable information (PII) over a secure
connection. After an anonymous link is established, Paid Media Manager can add and remove
customers based on the offers that have been assigned to them by NBA in near real-time. These
updates can be triggered by scheduled runs, real-time container calls, or offer responses.
The primary benefit of this people-based approach is that Paid Media Audience updates for a
customer can be made outside of web-sessions and across devices. The main limitation is the need to
have PII that matches what a media platform may have, for example, an email address or a phone
number.
Paid Media Manager uses the Customer Relationship Matching matching APIs for Facebook Ads and
Google AdWords to synchronize Paid Media Audiences.
Notes: Paid Media Manager for Pega Marketing 7.31 uses Google AdWords API v201705 and
Facebook Marketing API v2.10 by default. Since both Facebook and Google periodically release new
versions of their API, make sure to install any API-related hotfixes available on the Pega Marketing
hotfixes page. Paid Media Manager API hotfixes are published before the relevant API enters its
sunset phase. For more information about the availability dates of each API, refer to Google
AdWords API and Facebook Marketing API documentation:
l Facebook Ads API: Changelog
l Google AdWords API: Deprecation Schedule
For more information on targeting audiences via Facebook Ads and Google AdWords, refer to
Facebook Ads and Google AdWords documentation:
l Facebook Ads: Targeting Audiences
l Google AdWords: Remarketing and Audience Targeting
Configuring Facebook Ads Destinations

You can configure one or more paid destinations for Facebook Ads under Paid Media Settings in the
Pega Marketing portal.
1. Log in to your Pega Marketing portal as an administrator user.
2. Click Configuration > Settings > Channels > Paid Media > Facebook Ads.

3. Click New Facebook Ads.
4. Fill out the following required fields:
l Destination name
l Account ID
l App token
5. In the Field mapping section, map the Facebook API properties to Pega Marketing properties.
For example, you can map Email (EMAIL) to .pyEmail1. Mapping these properties will allow the
integration to match your existing customers to their Facebook accounts and target them with the
right ads on the right platform.
You can map the Email (EMAIL) and Phone (PHONE) Facebook API properties to multiple Pega
Marketing properties. In this way, you can specify multiple emails or phone numbers for each
customer and rank them in order of priority. Mapping multiple emails or phone numbers makes it
possible to generate higher match rates and reach more customers. At least one email or phone
mapping is required.
6. Optional: In the Field mapping section, use the Use External Id (EXTERN_ID) field to specify a
unique customer ID that can be used in place of hashed customer data for subsequent updates for
a given customer. This feature is enabled and set to use the customer class key from your
customer class by default. Keep in mind that disabling this setting will result in slower
synchronization with Facebook.
The property used as external ID is not hashed during synchronization with Facebook. If you want
to change it, select a property that can identify a customer uniquely without exposing their
internal data.
7. Optional: Configure the additional settings in the Facebook Ads assets generation section:
l All customers audience - This setting is enabled by default. While this setting is enabled,
after customers are placed in a Paid Audience, they are also added to an automatically
generated audience containing all next-best-action managed customers. To ensure that
customers who are placed in the All customers audience do not receive anonymously targeted
ads, negative target this audience on Facebook in all advertising campaigns that are not based
on next-best-action strategies. Customers who are present in the segment for the consecutive
outbound runs or real-time container updates will be removed from this audience. For more
information, refer to Facebook Ads documentation: Exclude specific audiences for better ad

results.
The default name for the All customers audience is Next-Best-Action managed. If you
disable or rename the All customers audience for a previously configured destination,
customers who are assigned to this audience will be removed from it.
l Enable offline conversion push – Enable this experimental setting to synchronize

customers who have accepted offers with an existing event set that was previously configured
on Facebook. For more information on offline event sets, refer to the Facebook Business
Manager documentation.
l Enable campaign generation – Enable this setting if you want Paid Media Manager to
speed up campaign generation by automatically creating campaigns for each offer and ad
group with the following default settings:
Name – The same as the name of the related offer.
AdSet name – The same as the name of the Paid Audience. The audience created on
Facebook will be associated with the AdSet.
Campaign objective – Set to LINK_CLICKS.
Billing event for AdSet – Set to IMPRESSIONS.
Daily budget – Set to 100 (equivalent to 1 USD).
isAutoBid – Enabled.
Automatically generated campaigns are created inactive. Review the campaign settings on the
Campaigns landing page, make any required changes and activate them manually.
8. Click Apply.
Configuring Google AdWords Destinations

You can configure one or more paid destinations for Google AdWords under Paid Media Settings in
the Pega Marketing portal.
2. Click Configuration > Settings > Channels > Paid Media > Google AdWords.
3. Click New Google AdWords.

l Destination name
l Client ID
l Client secret
l Developer token
l Refresh token
l Client customer ID
5. In the Field mapping section, map the Google AdWords Email (EMAIL) property to a Pega
Marketing property, for example .pyEmail1. Mapping the emails will allow the integration to
match your existing customers to their Google accounts and target them with the right ads on the
right platform.
You can map the Email (EMAIL) Google AdWords property to multiple Pega Marketing
properties. In this way, you can specify multiple emails for each customer and rank them in order
of priority. Mapping multiple emails makes it possible to generate higher match rates and reach
more customers. At least one email mapping is required.
6. Optional: Configure the additional settings in the Google Adwords assets generation section:
ads, negative target this audience on Google AdWords in all advertising campaigns that are not
based on next-best-action strategies. Customers who are present in the segment for the
consecutive outbound runs or real-time container updates will be removed from this audience.
For more information, refer to Google AdWords documentation: Exclude specific audiences
from your targeting.
customers who are assigned to this audience will be removed from it.
l Enable campaign generation – Enable this setting if you want Paid Media Manager to

speed up campaign generation by automatically creating campaigns for each offer and ad
group with the following default settings:
Name – The same as the name of the related offer.
AdSet name – The same as the name of the Paid Audience. The audience created in Google
AdWords will be associated with the AdSet.
Campaign objective – Set to LINK_CLICKS.
Billing event for AdSet – Set to IMPRESSIONS.
Daily budget – Set to 100 (equivalent to 1 USD).
isAutoBid – Enabled.
Automatically generated campaigns are created inactive. Review the campaign settings on the
Campaigns landing page, make any required changes and activate them manually.
Automatic campaign generation is not available for AdWords manager accounts.
7. Click Apply.
File-based Destinations
Some advertising technology platforms allow audiences to be updated in bulk based on transferred
files. Paid Media Manager supports this type of synchronization for Adobe Audience Manager. Use
Adobe Audience Manager to push Paid Media Audiences to one or more paid destinations, for
example, The Trade Desk, TubeMogul or DoubleClick Bid Manager.
The primary benefit of this approach is the ability to synchronize Paid Media Audiences across many
media platforms with a single integration. However, data management platforms such as Adobe
Audience Manager take 24 to 36 hours to sync Paid Media Audiences with downstream destinations.
For more information about building CRM-based audiences for paid destinations via Adobe Audience
Manager, see Adobe Inbound Customer Data Ingestion FAQ.

Configuring Adobe Audience Manager Destinations

You can configure one or more paid destinations for Adobe Audience Manager under Paid Media
Settings in the Pega Marketing portal.
2. Click Configuration > Settings > Channels > Paid Media > Adobe Audience Manager.
3. Click New Adobe Audience Manager.
l Destination name
l DP ID
l Data source ID
l API user name
l API password
l API client ID
l API secret key
5. In the Sync Configuration section, map the Adobe Audience Manager Sync ID property to a
Pega Marketing property that holds the value of the universally unique identifier (UUID) that
identifies the customer. The UUID property is implemented as part of the Adobe ID
synchronization and works as a synchronization key, allowing the integration to match your
existing customers to their accounts and target them with the right ads on the right platform.
6. Optional: Configure the additional settings in the Sync Configuration section.
l Full synchronization - Enable this setting if you want to send all Paid Media Audience
information to Adobe Audience Manager destinations every time that the synchronization runs.
Enabling full synchronization results in larger files being uploaded into Adobe Audience
Manager. This can slow the synchronization. This setting is not enabled by default. When full
synchronization is not enabled, the synchronization only sends information which has been
updated in Pega Marketing since the last synchronization date.

ads, negative target this audience in Adobe Audience Manager in all advertising campaigns that
are not based on next-best-action strategies. Customers who are present in the segment for the
consecutive outbound runs or real-time container updates will be removed from this audience.
customers assigned to this audience will be removed from it.
7. In the Delivery Configuration section, configure the location where Paid Media Manager sends
files with synchronization data to be uploaded into Adobe Audience Manager. Adobe Audience
Manager provides an FTP location or an Amazon S3 bucket for the files. For more information,
contact your Adobe Audience Manager implementation team.
8. Click Apply.
Web-based Paid Destinations

Legacy advertising technology platforms, including demand-side platforms (DSPs) and data
management platforms (DMPs) rely on third-party pixels or remarketing tags provided by an
advertising platform.
The primary benefit of this approach is the ability to update Paid Media Audiences in real-time
without a reliance on having shared personally identifiable information (PII). However, updates can
be made only while a customer is in a web session in a browser that allows access to third-party
cookies.
You can use a tag management solution such as Google Tag Manager or Adobe Dynamic Tag
Management instead of directly manipulating JavaScript. For more information on using Google Tag
Manager to send values to a remarketing tag, see Implement AdWords, Doubleclick, and
Dynamic Remarketing.

Configuring Web Destinations

You can configure one or more paid web destinations under Paid Media Settings in the Pega
Marketing portal.
2. Click Configuration > Settings > Channels > Paid Media > Web.
3. Click New destination .
4. Fill out the Destination name field.
5. Click Apply.
6. Configure the web service call for this web destination. You can use the example service call as
your template, or enter your own code into the box.
7. Click Apply.
Configuring the Next-Best-Action hierarchy

for Paid Media
After you set up the connection with a Paid Media destination, configure the Next-Best-Action
hierarchy so that your customers can be placed in the Paid Media Audiences that correspond to the
offers selected for them by your Next-Best-Action strategies. You can configure paid audiences at any
level in the Next-Best-Action hierarchy. For more information on configuring the Next-Best-Action
hierarchy, see Next-Best-Action.
1. Log in to the Pega Marketing portal as an administrator.
2. Click Next-Best-Action > Designer.
3. Click the business issue or group in which you want to enable paid audiences.
4. Click Edit.
5. In the Triggered by section, specify the trigger for the audience update:

l Real-time containers - If paid audiences and a real-time container are configured at any
level of the hierarchy, each real-time container call will result in a paid audience update. The
system makes a secondary call with direction as outbound and channel as paid. If you want to
configure the real-time container to use a broader range of offers than what is required for the
current page, see step 7. For more information on configuring real-time containers, see Real-
Time Containers.
Real-time containers are currently supported for Facebook Ads and Google AdWords
destinations.
l Outbound schedule - If you configure paid audiences and outbound runs at any level of the
hierarchy, each outbound run results in a paid audience update. If you configure paid
audiences at multiple levels of the hierarchy, the paid audiences are selected based on the
latest decision for each customer. For best results, configure a single paid outbound schedule at
the highest level of the hierarchy. For more information on configuring outbound campaigns,
see Outbound Campaigns.
6. In the Paid Media > Media strategy section, click Configure to select the media strategy. For
more information on configuring strategies, see Strategies.
7. In the Paid Media > Paid accounts section, click Configure to select one or more paid
destinations.
8. Optional: To execute the paid update from the highest level where you configured a paid real-time
container, click Paid Media > Paid accounts > Use Real-time container configured at
Next-Best-Action level. For example, if you configure a real-time container at the group level
and at the issue level above the group in the Next-Best-Action hierarchy, this setting executes the
real-time container at the issue level.
9. Click Save.
CapturePaidResponse REST service

Use the CapturePaidResponse REST service to push paid clicks into Interaction History. The following
is an example of JSON data for a POST request:

{ "CustomerID":"TestID31265",
"externalaudienceid":"90a6",
"AccountId" : "facebook_test_ac",
"ReferredUrl": "facebook.com",
"Source": "facebook",
"Utm_medium":"Banner Ad" ,
"AudienceID":"23842593604320755"}
The externalaudienceid must resolve to valid pyIssue, pyGroup, and pyName properties. The
Paid Media Audiences landing page displays the externalaudienceid for each audience in the
AUDIENCE KEY field. For more information, see Monitoring for Paid Media.
Monitoring for Paid Media

You can monitor the sizes and match rates of Paid Media Audiences using the Paid Media Audiences
landing page. Use the landing page to find information required to configure and manage Next-Best-
Action campaigns for paid audiences or to check for trends in audience sizes. For Facebook Custom
Audiences and Google Customer Match, the landing page displays information about the match rates
for your audiences.
Paid Media Audiences Landing Page

The Paid Media Audiences landing page displays a list of paid audiences created after a paid run, with
their sizes, the match rates, and other information that is required to set up a campaign.

The audiences are grouped by offer. The top row contains the offer name and the number of
audiences created for this offer. The child rows contain audiences grouped by destination. The
following information is displayed for each audience:
l Platform icon
l Audience name
l Audience key
l Issue and group name
l Destination type and destination name
l Number of customers in the audience
l Number of matched customers for Google and Facebook destinations
l Match rate for Google and Facebook destinations
A spark line graph shows the trends of population and matched count over the last thirty days. To see
the audience count for a specific date, hover your mouse over a point on the spark line.
To access the Paid Media Audiences landing page, log in to the Pega Marketing portal and click
Audiences > Paid Media Audiences.
Monitoring Outbound Runs and Real-time Container Updates

Use the Data Flows landing page to monitor the progress of each ongoing outbound run or real-time
container update. The Data Flows landing page provides developers and application users with an
overview of the current state of each run or update.
1. Click Configuration > Decision Management > Data Flows.
2. To review the ongoing outbound runs list, click the Batch processing tab.
3. To review the real-time container updates list, click the Real-time processing tab.
4. To see the details, click an item ID.

Error and Warning Handling

Any errors and warnings that occur in the integrated advertising platform during scheduled and real-
time paid runs are displayed as work objects in the Next-Best-Action Designer. Errors and warnings
are displayed chronologically for the Next-Best-Action hierarchy level and paid destination on which
they occurred. If multiple errors are generated for the same destination, they are added to the
existing work object. Paid Media Manager maintains a history of errors and warnings, as well as
information about the number of records affected.
If an error occurs, confirm that your account in the integrated platform is properly configured and
activated, then resolve the error work object before triggering another paid run.
Errors displayed in the Next-Best-Action Designer come directly from the integrated external system.
If you cannot resolve the problem yourself, contact the product team for your advertising platform.
Tuning Paid Media Manager Performance

Tune the performance of Paid Audience updates by adjusting the following settings:
l RTPaidMediaCustomersForAPeriod event strategy - This event strategy accumulates events for a

given customer for a given period of time. The default time is 5 minutes. Adjust this value if you
want the updates to happen more or less frequently. Less frequent but larger API calls will raise
the memory consumption.
l RTPaidMediaCustomersBatch event strategy - This event strategy accumulates a given number of

events. The default number of accumulated events is 1000. Raise this value if you want the API
calls to happen less frequently. Less frequent but larger API calls will raise the memory
consumption.
l dataflow/paidmedia/customerBatchSize dynamic system setting - This setting defines the number

of customer records processed during an outbound batch run. The default number of records is
2000. Adjust this value if you want to raise or lower the number of records which Paid Media
Manager accumulates before it prepares an API call to Google or Facebook. Less frequent but
larger API calls will raise the number of memory pages created.
l paidmedia/allNBAAudience/TimeToLive dynamic system setting - This setting defines how long

the system stores a customer record in the All customers audience. Customers who are not
targeted for more than the number of days specified in this setting are removed from the

audience and are available for anonymously targeted campaigns on Facebook, Google, and Adobe
Audience Manager. The default is 1 day. Raise this value to keep customer records in the All
customers audience for a longer time.
Optional: Modify any of the following dynamic system settings for Adobe Audience Manager. For
more information, contact your Adobe Audience Manager implementation team.
l paidmedia/adobe/api/authserver/url - This setting specifies the Auth Server URL for Adobe

Audience Manager. By default, the URL is set to https://api.demdex.com/oauth/token.
l paidmedia/adobe/api/resourceserver/url - This setting specifies the Resource Server Base URL for

Adobe Audience Manager. By default, the URL is set to https://api.demdex.com:443/v1.
l paidmedia/adobe/traitsegment/toplevel/folder/name - This setting defines the name of the top

level segment and trait folder created under the parent folder in Adobe Audience Manager. The
default name of this folder is Paid Media Audiences.
l paidmedia/adobe/file/push/maxfilesizeinbytes - The maximum size in bytes of synchronization

files sent to Adobe Audience Manager. The default file size in bytes is 1000000000.
l paidmedia/adobe/file/push/retrycount - The number of times Paid Media Manager automatically

tries to resend the synchronization file to Adobe Audience Manager in case of any synchronization
problems. The default number of tries is 3.

Appendix A: User Preferences
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 Pega Marketing preferences section of the
Preferences dialog and include the following:
Preference Purpose Default

Name Value
Validate Key Codes Sets a user preference to require key code entry in marketing artifacts Disabled
(such as Offers and Treatments). If this requirement is enabled at the
system level by the administrator, this user preference is ignored.

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.
The Application Settings landing page is available only to marketing administrators and lists various
configuration options. This landing page is accessible in the Pega Marketing portal via:
Configuration > Settings > 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 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 contains settings pertaining to the overall execution infrastructure.
Setting Name Setting Purpose

Outbound Default Specifies the database instance where the customer table resides and where the
Data Source application will store execution data (such as data pertaining to Segment and Campaign
execution).
Outbound DB Specifies the number of records displayed in the preview file when previewing the
Preview File Size contents of the data written for a Database Template.
Batch Size Specifies the size (number of records) into which back-end processing is batched, in order
to leverage performance improvements from vertical and horizontal scalability.
Delete Campaign Specifies the threshold (in number of days) for purging Campaign execution data. This
Run data older than only applies to data for Campaign Runs where all Offers are complete.
X days
Output File Date Specifies the default format to be applied to date fields in a File Template.
Format


Global Exclusion List Specifies the Segment that represents the global exclusion list. Refer to the Exclusion List
Segment chapter for details. When no value is specified, the exclusion list feature is disabled.
Note: Whenever a change is made to this setting, all event-based Campaigns need to be
suspended and re-submitted for execution.
Use Simulation Data Specifies whether Dashboard widgets should use simulated data. Enable this setting to
review the Dashboard and its capabilities in the absence of real data.
Use Decision Data Specifies whether a decision date store (such as Cassandra) should be utilized to store
Source customer-centric data, such as Segment membership and Contact Policy usage.
Note: The use of decision data sources requires a DNode to be configured in your
system. Refer to Pega Platform documentation for more details.
Enable Partitioning 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 partitioning is enabled, the following partitioning mode options may further be
available:
l Data Partitioning - Data partitioning logically groups data into chunks to achieve
performance gains.
l Table Partitioning - Table partitioning leverages database-level features (with faster
disk access) to structure the data in smaller chunks. Table partitions typically provide
more optimal performance than data partitions. This is primarily due to their faster
rate of disk access.
Note: Table partitioning is only available if supported by the underlying database.
Typically, this feature is only supported by enterprise editions of database systems. In
cases where the database system doesn't support table partitioning, the system
automatically uses the data partitioning mode when partitioning is enabled. In this case,
the partitioning mode options are not displayed.
After enabling partitioning, specify the range partition values for the PartitionKey column
in the Partition Ranges grid, as shown below:
Note: Exercise extreme caution in toggling the Enable Partitioning and Use Decision Data
Source settings on a live system. These settings are propagated to and utilized in the creation of
Segment and Campaign execution data. Toggling these settings after creation of Segments or
execution of Campaigns might necessitate the re-creation of these artifacts.

Artifact Settings
This landing page contains settings pertaining to the behavior and display of artifacts.
Setting Name Category Setting Purpose

Disable campaign Campaign Specifies whether Campaigns should validate the existence of Offer rules
offer validation Validation utilized by the Campaign Strategy.
Require key codes Campaign Specifies whether key code entry is required for artifacts (such as
Validation Campaigns, Offers, and Treatments). If this setting is enabled, it will over-
ride the user preference for specifying key codes.
Default Response Email Specifies the Section rule that will be used as the default response page
Page Responses for Email responses.
Default Offer Email Specifies the Section rule that will be used as the default page for Email
Expired Page Responses responses to expired Offers.
Default Offer Not Email Specifies the Section rule that will be used as the default page for Email
Available Page Responses responses to Offers that are no longer available.
Mapping License Geofences Specifies the license key to use for the Google Maps™ mapping service.
Key
Default Customer Geofences Specifies the properties on the customer class to use as defaults for the
Location Properties customer’s location (latitude and longitude) when filtering on Geofences
in Strategies.
Number of Upcoming Specifies the number of Campaign Runs that the system will schedule at a
scheduled Campaign time for open-ended Campaigns - i.e. where the end date is not set.
Campaign Runs Runs
Campaign contacts Field Determines the mode to use when managing contacts in Field
editing mode Campaigns Campaigns. This setting is only visible if the application includes Pega
Field Marketing.
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.
Note: 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.

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.

Customer Class Specifies the name of the customer class for the application. This is the class that is
Name mapped to the customer table. This class must either directly be PegaMKT-Data-Customer
or a class that extends the PegaMKT-Data-Customer class. Refer to the implementation
guide for guidelines on using a custom class.
Customer Class Specifies the ruleset and ruleset version to use for storing system-generated rules
Ruleset, Version pertaining to the customer class. Ensure that the specified ruleset version is unlocked.
Prospect Class Specifies the name of the prospect class for the application. Refer to the implementation
Name guide for guidelines on using a custom class. Manage Data link launches the Data
Management landing page for the prospect entity.
Note: The name of any database column listed in the External Mapping tab of the customer and
prospect classes must not exceed 27 characters.
This landing page also enables synchronization of the Seed List structure with the customer class
structure. For details, refer to the Updating Seed List Columns section of the Seed Lists chapter.
Associating Entities with the Customer Class

The Manage Data Relationships 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.).
Refer to the Configuring your Customer Class chapter of the Pega Marketing Implementation Guide
for details.
Use the Manage Data link next to a data entity to launch the Data Management landing page for
that entity.
Pega Marketing Dynamic System Settings

The following table describes the Dynamic System Settings utilized by Pega Marketing which can be
modified manually by administrators, if the need arises.

Owning Setting Name Description Default

RuleSet Value
PegaMKT-Engine ADMTimeoutForDelayedLearning Duration (in seconds) to store results for 2592000
adaptive learning. (30 days)
PegaMKT-Engine ADMShortTimeoutForDelayedLearning Short duration (in seconds) to store results for 86400
adaptive learning. Currently, this short (1 day)
duration is utilized for Real-Time Container
scenarios.
PegaMKT-Engine HelpURI/MarketingHelp URL where the MarketingHelp WAR file is
deployed. This should be configured as part of
installing Pega Marketing.
PegaMKT-Engine MKTDDFProgressNewTimeout Timeout duration (in seconds) used internally 60
to determine if Data Flow execution is stuck in
the New state, i.e. hasn't started execution.
PegaMKT-Engine MKTDDFProgressRefreshInterval Refresh duration (in seconds) used internally 30

for monitoring progress of Campaign
execution Data Flows.
PegaMKT-Engine MKTDDFProgressRefreshTimeout Timeout duration (in seconds) used internally 600
to determine if Data Flow execution is stuck (10
processing a batch of records. minutes)
PegaMKT-Engine MKTDefaultTemplateTextLength Default size of text columns created in 200
Database Template tables. This value is only
used for those properties which do not have
max length specified. For individual cases, it is
recommended to set the max length on the
property rule rather than updating this setting.
PegaMKT-Engine MKTSegmentRefreshInterval Refresh duration (in seconds) used internally 10
for monitoring progress of Segment execution
Data Flows.
PegaMKT-Engine WaitAgentReQueueTime Duration (in seconds) used internally to re- 600
queue wait agent processing if a Campaign (10
Run table still has records that are in a minutes)
pending state.
PegaMKT- ConnectMKTURL URL where Pega Marketing is deployed. This
Integration setting needs to be configured on a remote
Event Strategy Manager environment when
integrating with Pega Marketing Events. Refer
to the Real-Time Events chapter for details.
PegaMKT-Portal MaxRecentsCount Number of items to show in the RECENT pane 10
in the Pega Marketing portal.
PegaMKT- NumberOfPartitions Number of buckets used internally to divide 5
PushNotification Push Notification processing items. Each

Owning Setting Name Description Default

RuleSet Value
bucket can be picked up individually by a node
where the Push Notification Processor agent is
running.
PegaMKT- RequestorBatchSize Number of Push Notification items to process 1000
PushNotification at a time. The Push Notification Processor
agent retrieves items till this size is met (or all
items have been retrieved) before processing
them.

Appendix C: Passbook Settings

In order to use the Passbook functionality and send passes to customers, the administrator must
upload valid certificates into the system. This is done from the Certificates tab of the Passbook
landing page. This landing page is accessible in the Pega Marketing portal via: Configuration >
Settings > Channels > Passbook
Administrators must upload the following two certificates:
l Apple Certificate
l 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).

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 Description
Certificate Password associated with the certificate. The system will validate this password and will not
Password upload the certificate in case the password is invalid.
Organization (Optional) Organization name to display on delivered passes. If this is not provided, the
Name 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.

Appendix D: System Health

Pega Marketing provides a 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 the Pega Marketing portal via: Configuration > Settings > 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 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:
l Last updated date and time
l Errors and Warnings cards

l 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:
l Agent
l Channel
l Configuration
l 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.
Errors and Warnings Grids

These grids provide detailed information on the health check failure (i.e. error or warning). The
following columns are available in both grids:
Column Description
Name
Category Category of the error or warning
(Agent, Channel, Configuration, or Runtime)
Source Actionable area of the system associated with the error or 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 or page. In most cases, the administrator should be able
to rectify the failure by making appropriate changes in the opened object or page.
Message Descriptive text that explains the error or 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 and Warnings

The following table explains the scenarios that contribute to the Agent Errors and Agent Warnings
lists.
Failure Scenario Type Use Source link to…

Pega Marketing (PM) agent Error Launch the Agent Detail page for this agent. Administrators can manage (stop and
has failed and stopped start) the agent from this page.
Basic PM agent is stopped Error Launch the Agent Detail page for this agent. Administrators can start the agent on
on all system nodes one or more nodes from this page.
Optional PM agent is Warning Launch the Agent Detail page for this agent. Administrators can start the agent on
stopped on all system nodes one or more nodes from this page.
Basic PM agent has broken Error Launch the Broken Process Management landing page for the agent.
process queue items Administrators can review failures and delete broken queue items from this page.
Optional PM agent has Warning Launch the Broken Process Management landing page for the agent.
broken process queue items 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 Pega Marketing 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 functionality being used by
their marketing application, so they can better assess the true impact of failures in these agents.
Channel Errors and Warnings

The following table explains the scenarios that contribute to the Channel Errors and Channel
Warnings lists.

Default or PegaMKT-Work Outbound Email Error Open the Outbound Email landing page. Administrators should
Account doesn’t exist create the missing account(s) from this page.
Default or PegaMKT-Work Outbound Email Error Open the Email Account’s rule form. Administrators should correct
Account fails to connect any configuration issues in the account’s settings.
Other Outbound Email Account fails to Warning Open the Email Account’s rule form. Administrators should correct
connect any configuration issues in the account’s settings.
Default Outbound SMS Account doesn’t exist Warning Open the Outbound SMS landing page. Administrators should
create the Default account from this page.
Outbound SMS Account fails to connect Warning Open the Outbound SMS landing page. Administrators should
correct any configuration issues in the account’s settings.
Inbound SMS Account connection has failed Warning Open the Inbound SMS landing page. Administrators should
correct any configuration issues in the account’s settings.
There are recent Offer Email delivery errors Warning Open the Error Tracking landing page. Administrators can review
and mange errors from this page.
Error occurred while writing to output file or Error Open the Outbound File or Database landing page. Administrators
table can review the error and retry from this page.
Apple or organizational Passbook certificate Warning Open the Passbook Settings landing page. Administrators can
is missing or expired manage the certificates from this page.
No default Push Notification app exists or Warning Open the Push Notifications landing page. Administrators can
default app has no defined variants configure apps and app variants from this page.
Push Notification iOS app certificate is Warning Open the Push Notifications landing page. Administrators can
missing or expired configure apps and app variants from this page.
Configuration Errors and Warnings

The following table explains the scenarios that contribute to the Configuration Errors and
Configuration Warnings lists.


Outbound Default Data Source is not configured or Error Open the Configuration Settings landing page tab.
doesn’t exist in the system Administrators should update the settings to point to a
valid data source.
Outbound Default Data Source fails to connect Error Open the rule form for the data source. Administrators
should correct the configuration settings and re-test the
connection.
Customer or prospect class doesn’t exist Error Open the Data Relationships landing page tab.
Administrators should update the settings to point to the
right classes.
A required PM property (such as CustomerID) is not Error Open the class rule. Administrators should add a
mapped on the customer or prospect class. mapping for the missing property.
An optional PM property (such as pyEmail1) is not Warning Open the class rule. Administrators should add a
mapped on the customer or prospect class. mapping for the missing property.
Column referenced in External Mappings of Error Open the class rule. Administrators should review all
customer or prospect class does not exist in the mappings and make any necessary corrections.
database.
PM Access Group doesn’t have Default destination Error Open the Access Group. Administrators should set the
ruleset configured Default destination ruleset to their marketing
application’s artifacts ruleset.
Default destination ruleset configured on PM Access Error Open the Access Group. Administrators should validate
Group doesn’t exist that the correct RuleSet Version is being used.
Default destination ruleset configured on PM Access Error Open the Access Group. Administrators should update
Group is locked, but an open RuleSet Version exists instance to reference an unlocked RuleSet Version.
for the same RuleSet
Default destination ruleset configured on PM Access Error Open the RuleSet. Administrators should add a new
Group is locked and no open versions exist for the unlocked version and update the Access Group to
RuleSet reference this new version.
Batch decisioning agent is not running on any nodes Error Open the Decisioning Topology landing page.
Administrators should enable the ProcessBatchJob agent
on at least one of the system nodes.
Batch decisioning agent doesn’t have number of Error Open the Decisioning Topology landing page.
threads configured 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.
Mapping License Key for Google Maps is not Warning Open the Artifact Settings landing page. Administrators
specified should set a value for this key if their application utilizes
the Import Geofences wizard.

Runtime Errors and Warnings

The following table explains the scenarios that contribute to the Runtime Errors and Runtime
Warnings lists.

Marketing Campaign has failed recently Error Open the failed work object.
Marketing Campaign has one or more recent failed runs Error Open the Campaign 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.

Appendix E: Using a Configuration Modal Window
Appendix E: Using a Configuration

Modal Window
The configuration modal window is utilized in multiple places within Pega Marketing. This appendix
outlines the components of a configuration window and how to use the window to select items.
Configuration Window Components

The configuration modal window has the following components:
1. Items list - The left half of the window has a list of selectable items. This component has the
following usage patterns:
l The modal presents the twenty most recently updated rules (e.g. Strategies) in the system.
l If there are more than twenty results, use the View 20 more results link at the bottom to
load the next set of results.
l Use the search box to search for rules by name or description.
l The refresh icon refreshes the list of results, retaining any search criteria that was previously
entered.
l Use the Create link (if available in the window) to create a new rule. The system pre-populates
relevant fields on the rule's create form. After creating the rule, refresh the list of results in the
modal to see your new rule.
l Click an entry in the list to select it. Upon selection, the system displays information about the
selected entry in the details panel on the right.
2. Item details panel - The upper portion of the right half of the window lists pertinent details
about the currently selected item. Use the link in this panel (if present) to open the corresponding
rule.
3. Selected items panel - The lower portion of the right half of the configuration window lists the
items that have been selected so far. Clicking an item link in this section opens the corresponding
rule. This panel also displays an informational message (either Only 1 can be added or Multiple
can be added) to indicate how many elements can be selected using this configuration window.

Appendix E: Using a Configuration Modal Window
Selecting Items
Based on the element being configured and its intended usage, users can either select a single item
from the list or multiple items.
Click Add to include the corresponding item as a selection for the configuration. In the case of a
single-select configuration modal, the Add button is disabled on all other rows once an item has been
selected. To select a different item, first remove the currently added item by either clicking Remove
in the item's row or by clicking the corresponding trashcan icon in the selected items panel.
After adding the desired items, click Apply to confirm your selection changes and close the
configuration window. Alternately, click Cancel at any time to discard selection changes and close
the configuration window.
Note: When a configuration window is triggered from an already open configuration modal
window, the new window slides in. Upon application of selected values or cancellation, the
secondary window slides out and returns the user back to the original configuration window.

Pega Marketing 731 User Guide - 7 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Pega Marketing 731 User Guide - 7 PDF

Cargado por

Copyright:

Formatos disponibles

P E G A M A RK E TI NG

This document is the property of:

DOCUMENT: Pega Marketing User Guide

Pega Marketing User Guide i

Pega Marketing User Guide ii

Pega Marketing User Guide iii

Pega Marketing User Guide iv

Pega Marketing User Guide v

Pega Marketing User Guide vi

Pega Marketing User Guide vii

Pega Marketing User Guide viii

Pega Marketing User Guide ix

Pega Marketing User Guide x

Pega Marketing User Guide xi

Pega Marketing User Guide xii

Pega Marketing User Guide xiii

Pega Marketing User Guide xiv

Pega Marketing User Guide xv

This guide explains how to:

l Use the Pega Marketing portal

l Create Campaigns and Strategies to deliver Offers to customers

l Leverage Segment visualization to hone in on the ideal set of customers

l Configure constraints to optimize throughput

l Create complex cross-channel Offers and group them into bundles

l Design and create compelling Treatments

l Design, deliver, and update (Apple) Passbook passes

l Deliver push notifications to configured apps on Android and iOS devices

l Configure, trigger, and respond to real-time Events and Geofences

l Use stage-based case management to define dynamic Microsites

l Import Prospect Lists and target prospects via Campaigns

l Define and populate Control Groups and utilize them in Strategies

l Create Checklists and Tasks

l Utilize the Customer Profile to view customer details

Pega Marketing User Guide xvii

l Assess the health of your Pega Marketing application

l Utilize other common marketing functions

Pega Marketing User Guide xviii

In addition, this guide also includes the following appendices:

Pega Marketing User Guide xix

Chapter 1: Pega Marketing

Pega Marketing User Guide 1

Capabilities to allow marketers to create cross-channel engagement strategies that continuously

n Shared artifacts and components

Analytics-based campaign capabilities include intelligent segmentation that leverages predictive

Pega Marketing User Guide 2

Role Login Password Default Portal Other Portals

Pega Marketing Portal

The Pega Marketing portal comprises the following pieces:

Pega Marketing User Guide 3

Icon Label Purpose

Configuration Provides access to configuration-related landing pages

(operator initials) Provides access to operator resources, such as preferences.

Help Launches Pega Marketing Help

l Visual Business Director - Launches Visual Business Director.

l Customer Profile- Launches Marketing Profile.

l Marketing Calendar - Launches Marketing Calendar.

Pega Marketing User Guide 4

l Decision Management - Provides links to the Proposition Management, Simulations,

l Segmentation - Provides links to the following landing pages:

Seed Lists - Enables management of Seed Lists in the system.

Prospect Lists - Enables management of Prospect Lists in the system.

Channels - Provides links to the following channel-related landing pages:

SMS – Enables management of Inbound and Outbound SMS Accounts.