688
be divided among
the offer variants.
Otherwise, offer
variant eligibility will
show drop-offs
based on eligible
customers.
7 Pick
Best
Offer
VariantArbitrati
on
(Best
Offer
Variant
by
Offer)This represents the
count of customers
which has passed
the “Pick Best Offer
Variant” funnel step,
which selects the
best Offer Variant
based on pre-
defined rank, in
case multiple offer
variants are eligible
for the same offer
and the same
customer.IdentifyOff
erVariants
ForEligible
OffersIdentify
Best
OfferVaria
nt For
Offerpick_be
st_offer
_var_by
_offer_c
ountYes Pick Best
Offer
VariantPickBestOff
erVariant
8 Global
Contact
Strategy
No
Bundling
(For
Treatme
nts that
do not
use
Bundling
)Contact
Strateg
yThis represents the
count of customers
which has passed
global contact policy
rules.
Please note that
global contact policy
is required to be
enabled at offer
level and it is
ignored for
“Mandatory” offers
and offers available
for Intent with High
Confidence Score.
At this funnel step,
the global contact
policy is only applied
for channels (batch)
which does not use
bundling
functionality;
currently only Email
channel uses
bundling in Bach
mode. Hence,
potential drop-offs


channel uses
bundling in Bach
mode. Hence,
potential drop-offs
will be shown only       This step
is not
relevant
for
GetNBA


689
for non-Email
treatments.
9 Busines
s
Purpose
Contact
Strategy
No
Bundling
(For
Treatme
nts that
do not
use
Bundling
)Contact
Strateg
yThis represents the
count of customers
which has passed
business purpose
contact policy rules.
Please note that
business purpose
contact policy is
required to be
enabled at offer
level and it is
ignored for
“Mandatory” offers
and offers available
for Intent with High
Confidence Score.
At this funnel step,
the business
purpose contact
policy is only applied
for channels (batch)
which does not use
bundling
functionality;
currently only Email
channel uses
bundling in Bach
mode. Hence,
potential drop-offs
will be shown only
for non-Email
treatments.       This
step is
not
relevant
for
GetNBA
10 Offer
Self
Contenti
on
Strategy
No
Bundling
(For
Treatme
nts that
do not
use
Bundling
)Contact
Strateg
yThis represents the
count of customers
which has passed
offer self contention
rules.
Please note that
offer self contention
is required to be
enabled at offer
level and it is
ignored for offers
available for Intent
with High
Confidence Score.AllTreatme
ntsForEligi
bleOffersEligible
Offer Self


Confidence Score.AllTreatme
ntsForEligi
bleOffersEligible
Offer Self
Contention
Strategy
Relevant
Treatment
sself_co
ntention
_treatm
ent_no_
bundlin
g_countYes Offer Self
Contentio
n Strategy
No
BundlingOfferSelfCo
ntentionStra
tegyNoBund
ling


690
At this funnel step,
the offer self
contention is only
applied for channels
(batch) which does
not use bundling
functionality;
currently only Email
channel uses
bundling in Bach
mode. Hence,
potential drop-offs
will be shown only
for non-Email
treatments.
11 Run
time
Volume
Capacity
CheckEligibilit
yThis represents the
count of customers
which has
successfully passed
the run-time volume
capacity check for
the treatment.
Please note that the
run-time volume
limit is calculated as
volume limit defined
at treatment level
considering the
control group (if
enabled) as well as
de-dupe factor.      This step
is not
relevant
for
GetNBA
12 Channel
EligibilityEligibilit
yThis represents the
count of customers
which has passed
channel eligibility
rules for each
business purpose-
channel
combinations as
defined in the
relevant proposition
filter.

Please note that the
following channels
does not apply any
channel eligibility
and hence there will
not be any drop-off IdentifyEli
gibleWebT
reatments,
IdentifyEli
gibleIBCC
Treatment
s,
IdentifyEli
gibleAppTr
eatments,
IdentifyEli
gibleTreat
mentsforIV
RandSMS,
IdentifyEli
gibleRetail
Treatment
sApplyChan
nelEligibilit
ychannel
_eligibili
ty_coun
tYes Channel


nelEligibilit
ychannel
_eligibili
ty_coun
tYes Channel
EligibilityChannelElig
ibility


691
Web
InboundCC
App
IVR
13 Channel
Contenti
onContact
Strateg
yThis represents the
count of customers
which has passed
channel contention
rules.
Please note that
channel contention
is required to be
enabled at treatment
level and and the
contention periods
are needed to be
configured for each
channel.
Please note that the
following channels
does not apply any
channel eligibility
and hence there will
not be any drop-off
Web
InboundCC
App
IVRIdentifyEli
gibleWebT
reatments,
IdentifyEli
gibleIBCC
Treatment
s,
IdentifyEli
gibleAppTr
eatments,
IdentifyEli
gibleTreat
mentsforIV
RandSMS,
IdentifyEli
gibleRetail
Treatment
sApplyChan
nelContent
ionchannel
_conten
tion_co
untYes Channel
Contentio
nChannelCon
tention
14 Treatme
nt
EligibilityEligibilit
yThis represents the
count of customers
which has passed
the eligibility rules
for the treatment
defined in the Squad
(BP)-Channel level
Proposition Filters
as well as defined in
bespoke Squad
(BP) level
strategies.IdentifyEli
gibleWebT
reatments,
IdentifyEli
gibleIBCC
Treatment
s,
IdentifyEli
gibleAppTr
eatments,
IdentifyEli
gibleTreat
mentsforIV
RandSMS,
IdentifyEli
gibleRetail
Treatment


mentsforIV
RandSMS,
IdentifyEli
gibleRetail
Treatment
sApplyTreat
mentEligibi
litytreatme
nt_eligi
bility_co
untYes Treatment
EligibilityTreatmentEl
igibility
15 Pick
Best Arbitrati
onThis represents the
count of customers       This step
is not


692
Treatme
nts For
Offer
(Pick
Best
Channel
)(Best
Treatme
nt By
Offer)which has passed
the Pick Best
Treatments For
Offer (Pick Best
Channel) step which
selects the best
treatment for the
offer for the
customer when
customer is eligible
for multiple
treatments for the
same offer and Pick
Best Treatments For
Offer is enabled with
appropriate method.
This will only show if
drop off if multiple
treatments are
eligible for the offer
and the functionality
is enabled.relevant
for
GetNBA
16 Global
Contact
Strategy
Bundling
(For
Treatme
nts that
use
Bundling
)Contact
Strateg
yThis represents the
count of customers
which has passed
global contact policy
rules.
Please note that
global contact policy
is required to be
enabled at offer
level and it is
ignored for
“Mandatory” offers
and offers available
for Intent with High
Confidence Score.
Please also note
that, for bundled
treatments, contact
strategy is only
applied for Parent
treatment.
At this funnel step,
the global contact
policy is only applied
for channels (batch)
which use bundling
functionality;
currently only Email       This step
is not
relevant
for
GetNBA


693
channel uses
bundling in Bach
mode. Hence,
potential drop-offs
will be shown only
for Email
treatments.
17 Busines
s
Purpose
Contact
Strategy
Bundling
(For
Treatme
nts that
use
Bundling
)Contact
Strateg
yThis represents the
count of customers
which has passed
business purpose
contact policy rules.
Please note that
business purpose
contact policy is
required to be
enabled at offer
level and it is
ignored for
“Mandatory” offers
and offers available
for Intent with High
Confidence Score.
Please also note
that, for bundled
treatments, contact
strategy is only
applied for Parent
treatment.
At this funnel step,
the business
purpose contact
policy is only applied
for channels (batch)
which use bundling
functionality;
currently only Email
channel uses
bundling in Bach
mode. Hence,
potential drop-offs
will be shown only
for Email
treatments.      This step
is not
relevant
for
GetNBA
18 Offer
Self
Contenti
on
Strategy
BundlingContact
Strateg
yThis represents the
count of customers
which has passed
offer self contention
rules.      This step
is not
relevant
for
GetNBA


694
(For
Treatme
nts that
use
Bundling
)Please note that
offer self contention
is required to be
enabled at offer
level and it is
ignored for offers
available for Intent
with High
Confidence Score.
Please also note
that, for bundled
treatments, contact
strategy is only
applied for Parent
treatment.
At this funnel step,
the offer self
contention is only
applied for channels
(batch) which use
bundling
functionality;
currently only Email
channel uses
bundling in Bach
mode. Hence,
potential drop-offs
will be shown only
for Email
treatments.
19 Bundled
Treatme
nt (For
Treatme
nts that
use
Bundling
)Eligibilit
yThis represents the
count of customers
which has
successfully passed
bundling
functionality.
This step will not
show any drop-offs
for parent
treatments and will
potentially show
drop offs for child
treatments which
are “orphan” i.e.
does not have
eligible Parent
treatment.      This step
is not
relevant
for
GetNBA
20 Pick
Best
TreatmeArbitrati
onThis represents the
count of customers
which has IdentifyBe
stTreatmeIdentifyBes
tTreatment
ForBatchpick_be
st_treat
ment_foYes Pick Best
Treatment PickBestTre
atmentForC
ustomerA new


ment_foYes Pick Best
Treatment PickBestTre
atmentForC
ustomerA new
“Priority
Score


695
nt For
Custom
er
(Arbitrati
on)successfully passed
the arbitration step
of the funnel which
selects the best
treatment for the
customer.
Please note that
“Mandatory”
offers bypasses
arbitration step
and it is only
applied for “non-
Mandatory”
offers. Hence the
drop offs will only
be available for
“non-Mandatory”
offers.
Arbitration step
is applied at offer
level i.e offer
with highest
priority is
selected first and
all eligible
treatments for
the best offers
are selected.
This count also
includes drop off
by Priority Score
Cut OffntforSubsc
riptionr_custo
mer_co
untFor
CustomerCut Off”
simulatio
n funnel
step has
been
consider
ed but
has been
parked
for now
pending
new
story to
change
where
the
“Priority
Score
Cut Off”
funnel
will be
applied.
21 Treatme
nt
Variant
EligibilityEligibilit
yThis represents the
count of customers
which has passed
the eligibility rules
for the Treatment
Variants for each
Treatment defined in
the Squad (BP) level
Proposition Filters
as well as defined in
bespoke Squad
(BP) level
strategies.
Please note, at
treatment variant
level, the eligible
treatments and
eligible offer variants IdentifyTre


treatment variant
level, the eligible
treatments and
eligible offer variants IdentifyTre
atmentVari
ationsEligible
Treatment
Variations
For Eligible
Treatment
streatme
nt_var_
eligibilit
y_countYes Treatment
Variant
EligibilityTreatmentV
ariantEligibili
ty From this
funnel
step, the
count is
shown at
treatment
variant
level.


696
come together and
hence any drop offs
at offer
variant/treatment
level will be visible
at this step along
with drop off due to
eligibility rules.
Please also note
that when multiple
treatment variants
are configured for
an treatment, only if
a “catch-all”
treatment variant
(default, without
eligibility) is defined,
the offer
variant/treatment
eligibility count will
be divided among
the treatment
variants. Otherwise,
treatment variant
eligibility will show
drop-offs based on
eligible customers.
This step also
includes the count
of customers
which has passed
the additional
eligibility rules for
specific Treatment
Variants such as
(TOBI,
Webchat,Online)
using IH and
Tealium Aggregate
Events data.
22 Pick
Best
Treatme
nt
Variant
By
Treatme
ntArbitrati
on
(Best
Treatme
nt
Variant
by
Treatme
nt)This represents the
count of customers
which has passed
the “Pick Best
Treatment Variant”
funnel step, which
selects the best
Treatment Variant
based on pre-
defined rank, in
case multiple IdentifyTre
atmentVari
ationsBest
Treatment
Variant By
Treatmentpick_be
st_treat
ment_v
ar_by_tr
eatment
_countYes Pick Best
Treatment
Variant By
TreatmentPickBestTre
atmentVaria
ntByTreatm
ent


697
treatment variants
are eligible for the
same treatment and
the same customer.
23 Pick
Best
Treatme
nt
Variant
For
Custom
erArbitrati
on
(Best
Treatme
nt
Variant
by
Custom
er)This represents the
count of customers
which has passed
the “Pick Best
Treatment Variant
by Customer ”
funnel step, which
selects the best
Treatment Variant
based on Priority
(inherited from Offer
level Priority).IdentifyTre
atmentVari
ationsBest
Treatment
Variant For
Customerpick_be
st_treat
ment_v
ar_by_c
ustomer
_countYes Pick Best
Treatment
Variant
For
CustomerPickBestTre
atmentVaria
ntForCusto
mer
24 Control
Group
Split -
TargetControl
Group
SplitThis represents the
count of customer in
the potential “target”
group for the
treatment.
Please note that this
is not a typical
funnel step but
created just to
represent the target-
control split and this
will only show a split
if a control group is
configured.
Otherwise, all count
will be shown in
“target”.
Please also note
that control group
can be set at Offer
level as well as
Treatment level.
Treatment level
control group, if set,
overrides Offer level
control group. If not
set, Treatment level
inherits Offer level
control group.SelectBet
weenOffer
ORTreatm
entPotenti
alControlS


control group.SelectBet
weenOffer
ORTreatm
entPotenti
alControlS
plitTarget
Treatment
s Onlytreatme
nt_in_p
otential
_target_
countNo N/A N/A  Only
used for
IVR,
SMS &
App
25 Control
Group
Split -
ControlControl
Group
SplitThis represents the
count of customer in
the potential SelectBet
weenOffer
ORTreatm
entPotentiControl
Treatment
s Onlytreatme
nt_in_p
otentialNo N/A N/A  Only
used for
IVR,


698
“control” group for
the treatment.
Please note that this
is not a typical
funnel step but
created just to
represent the target-
control split and this
will only show a split
if a control group is
configured.
Otherwise, all count
will be shown in
“target”.
Please also note
that control group
can be set at Offer
level as well as
Treatment level.
Treatment level
control group, if set,
overrides Offer level
control group. If not
set, Treatment level
inherits Offer level
control group.alControlS
plit_control
_countSMS &
App
26 Final
Selectio
nFinal
Selectio
nThis step is only
relevant for
Customer Leven
Simulation and
represents the final
selection after
passing all funnel
steps
 N/A N/A N/A Yes Final
SelectionFinalSelecti
on


699
GetNBA Funnel and Distribution Simulation Query
Funnel Step Simulation :  Run the below query and provide simulation id as input in single quotation(''), as shown in the screenshot, when
prompted.
Distribution test Simulation: Run the below query and provide table name( distributiontestsimulation1 or distributiontestsimulation2 ) as
input , as shown in the screenshot, when prompted.

GetNBA_Funne …
08 Sep 2022, 11:32 AM_V2.txt
 GetNBAFunnelqu
08 Apr 2022, 09:21 AMery (1)
Distribution tes …
16 Dec 2020, 07:35 AMn Query


700
Running the Simulation Case
CaseIgnitor
Settings
Segment
RefreshSegment
SimulationT ype
BaselineRun
UseBaselineData
ExecutionMode
Channel and SubChannel
PrimaryContext and SecondaryContext
RequestStartDate and RequestEndDate
Results
Distribution Run
Funnel Run
Customer Run
Baseline Run (for BatchNBA  execution)
Baseline Run (for GetNBA  execution)
CaseIgnitor
An activity found in the Simulation Work class allows a user to run a simulation case tailored to their specific requirements by adjusting
various parameters before clicking on the Run button. Details on how each of these parameters affects the simulation case and what sort of
values are expected for them can be found in the Settings section of this page.
Settings
Segment

Name of the segment that will be used to prepare the data for the simulation case. The specified segment must exist as a segment rule in
the target environment to be a valid setting and is mandatory for all configurations of the simulation case except for UseBaselineData runs.
RefreshSegment


701
When this checkbox is enabled, the segment specified in the ‘Segment’ setting will be created or recreated in the database table for the
target environment using the settings for the segment rule that is being used, otherwise the simulation case will use the already-existing
database table instead. This setting is an option can be used in all configurations of the simulation case except for UseBaselineData runs.
SimulationType
Name of the type of simulation that is being ran. The three options for this are: Distribution, Funnel or Customer. Distribution simulations
focus on the average statistics for each offer that is simulated, Funnel simulations focus on the effects that each funnel has on each offer
that is simulated, and Customer simulations focus on providing details for every offer for every customer that is simulated. The input for this
setting must be one of these given options to be a valid setting and is mandatory for all configurations of the simulation case.
BaselineRun
When the checkbox is enabled, the simulation case will store the results of the prepared data into a BaselineSimulation data set, so that it
can be accessed again in later UseBaselineData simulation case runs without having to prepare the data again, otherwise the prepared
data will be cleaned upon the case’s completion. This setting is an option can be used in all configurations of the simulation case except for
UseBaselineData runs.
UseBaselineData
When this checkbox is enabled, the simulation case will run using data from the already-populated BaselineSimulation data set instead of
preparing the data again as part of the case, cutting down on the time taken for the case to complete. This setting cannot be used with an
input for the ‘Segment’ setting or if RefreshSegment/BaselineRun are enabled.
ExecutionMode


input for the ‘Segment’ setting or if RefreshSegment/BaselineRun are enabled.
ExecutionMode
Name the execution mode. There are two options: BatchNBA or GetNBA. BatchNBA prepares data for existing customers on a daily basis
(within a particular time) to check the eligible customers to send data to outbound channels eg. Email or SMS. GetNBA focuses in real-time
simulation (Inbound), where the decision is captured for each customer after receiving through an inbound channel.
Channel and SubChannel
If the ExecutionMode is GetNBA: Channel and SubChannel are mandatory parameters that require an input. These are the means of
communication customers use to interact.
Example of Channel: IVR
Example of SubChannel:PostNLCS


702
PrimaryContext and SecondaryContext
These parameters are not mandatory, they are inputs for when the ExecutionMode is GetNBA. The context stated by the customer is used
to identify the intent based on the mapping.
RequestStartDate and RequestEndDate
If the ExecutionMode is GetNBA: RequestStartDate and RequestEndDate are mandatory parameters that require an input. To run the
simulation for the customer requests that are within this date.
Format: 20211222202112 20211222 2021122220211222

Results
Distribution Run
Output data: simulation_distribution_summary database table
Funnel Run
Output data: simulation_funnel_summary database table
Customer Run
Output data: SimulationFunnelAudit Database Table data set (linked to simulation_funnel_audit database table)


703
Baseline Run (for BatchNBA execution)
Prepared data (for UseBaselineData runs): BaselineSimulation Cassandra data set
Output data: BaselineSimulationExport Database Table data set (linked to baseline_simulation_export database table)


704
Baseline Run (for GetNBA execution)
Prepared data (for UseBaselineData runs): BaselineSubscriptionDataForGetNBA Cassandra data set
Output data: BaselineGetNBASimulationExport Database Table data set (linked to baseline_getnba_simulation_export database table)


706
Simulation Funnels (TIL)

Description about each Funnel in Simulation:

Strat
egyComp
onentColumn
Name in
Pega
Simulatio
n QueryIn
Custo
mer
Level
Simul
ationFunnel
Name in
Custome
r Level
Simulati
onColumn
Name in
Customer
Level
Simulation
Query
1 Base
Pop
ulati
onBase
Popul
ationTotal number of customers in the
simulation.
This is tracked for all available
propositions (which are imported in the
Strategy Canvas for decisioning) and it
should be same for all propositions.Identi
fyEligi
bleOff
ersImport
All
OffersBase
Populatio
nNo N/A No
2 Offer
s By
Eligi
ble
Inten
tsEligibili
tyThis represents the count of customers
eligible for the ”Intent” which is making
the offer available for decisioning.
This should show drop-offs in the count
of customer from “base population”
based on intent eligibility and relevant
mapping of offers (Global Intent level,
Squad Level or Business Purpose
level).Identi
fyEligi
bleOff
ersIdentify
Offers
For
Eligible
Intents
(Batch)intent_eli
gibility_c
ountYes Offers By
Eligible
IntentsOffersByEli
gibleIntents
3 Glob
al
Eligi
bility
For
Batc
hEligibili
tyThis represents the count of customers
which has passed the global batch


hEligibili
tyThis represents the count of customers
which has passed the global batch
eligibility rules.       This
step is
not
relevan
t for
TIL
4 Cont
rol
Grou
p
Cont
entio
n
(quaEligibili
tyThis represents the count of customers
which has passed the Control Group
Quarantine check by Business
Purpose.
This should show drop offs if Control
Group Quarantine is setup and
customer is within Control Group
Quarantine.Identi
fyEligi
bleOff
ersApplyB
usines
sPurpo
seQuar
antine
Check
ForCo
ntrolbp_quara
ntine_co
untYes Control
Group
Contentio
nControlGro
upContentio
n Or
de
rFun
nel
StepFunne
l Step
Group
ingDescription Pega OOTB Decisioning
Funnel SimulationPega Customer Level
SimulationComm
ents /
Recom
menda
tion


707
ranti
ne)
5 Offer
Core
Eligi
bilityEligibili
tyThis represents the count of customers
which has passed the eligibility rules for
the offer defined in the Squad (BP) level
Proposition Filters.    Yes Offer
Core
EligibilityOfferCoreEl
igibility
6 Offer
Squ
ad
Eligi
bilityEligibili
tyThis represents the count of customers
which has passed the eligibility rules for
the offer defined in bespoke Squad
(BP) level strategies.   Yes Offer
Squad
EligibilityOfferSquad
Eligibility
(5)Offer
Eligi
bilityEligibili
tyThis represents the count of customers
which has passed the eligibility rules for
the offer defined in the Squad (BP) level
Proposition Filters as well as defined in
bespoke Squad (BP) level strategies.Identi
fyEligi
bleOff
ersEligible
Offersoffer_elig
ibility_co
unt
7 Offer
Varia
nt
Core
Eligi
bilityEligibili
tyThis represents the count of customers
which has passed the eligibility rules for
the Offer Variants for each offer defined
in the Squad (BP) level Proposition
Filters.
Please note that when multiple offer
variants are configured for an offer, only
if a “catch-all” offer variant (default,
without eligibility) is defined, the offer
eligibility count will be divided among
the offer variants. Otherwise, offer
variant eligibility will show drop-offs
based on eligible customers.   Yes Offer
Variant
Core
EligibilityOfferVariant
CoreEligibili
ty


Variant
Core
EligibilityOfferVariant
CoreEligibili
ty
8
 Offer
Varia
nt
Squ
ad
Eligi
bilityEligibili
tyThis represents the count of customers
which has passed the eligibility rules for
the Offer Variants for each offer defined
in bespoke Squad (BP) level strategies.
Please note that when multiple offer
variants are configured for an offer, only
if a “catch-all” offer variant (default,
without eligibility) is defined, the offer
eligibility count will be divided among
the offer variants. Otherwise, offer
variant eligibility will show drop-offs
based on eligible customers.   Yes Offer
Variant
Squad
EligibilityOfferVariant
Squad
Eligibility
(6)Offer
Varia
nt
Eligi
bilityEligibili
tyThis represents the count of customers
which has passed the eligibility rules for
the Offer Variants for each offer defined
in the Squad (BP) level Proposition
Filters as well as defined in bespoke
Squad (BP) level strategies.Identi
fyOffe
rVaria
ntsFo
rEligi
bleOff
ersEligible
Offer
Variant
soffer_var
_eligibilit
y_countYes Offer
Variant
EligibilityOfferVariant
Eligibility


708
Please note that when multiple offer
variants are configured for an offer, only
if a “catch-all” offer variant (default,
without eligibility) is defined, the offer
eligibility count will be divided among
the offer variants. Otherwise, offer
variant eligibility will show drop-offs
based on eligible customers.
9 Pick
Best
Offer
Varia
ntArbitra
tion
(Best
Offer
Variant
by
Offer)This represents the count of customers
which has passed the “Pick Best Offer
Variant” funnel step, which selects the
best Offer Variant based on pre-defined
rank, in case multiple offer variants are
eligible for the same offer and the same
customer.Identi
fyOffe
rVaria
ntsFo
rEligi
bleOff
ersIdentify
Best
OfferV
ariant
For
Offerpick_best
_offer_va
r_by_offe
r_countYes Pick Best
Offer
VariantPickBestOff
erVariant
10Glob
al
Cont
act
Strat
egy
No
Bun
dling
(For
Treat
ment
s
that
do
not
use
Bun
dling
)Conta
ct
Strate
gyThis represents the count of customers
which has passed global contact policy
rules.
Please note that global contact policy is
required to be enabled at offer level and
it is ignored for “Mandatory” offers and
offers available for Intent with High
Confidence Score.
At this funnel step, the global contact
policy is only applied for channels
(batch) which does not use bundling


policy is only applied for channels
(batch) which does not use bundling
functionality; currently only Email
channel uses bundling in Bach mode.
Hence, potential drop-offs will be shown
only for non-Email treatments.      This
step is
not
relevan
t for
TIL
11Busi
ness
Purp
ose
Cont
act
Strat
egy
No
Bun
dling
(For
Treat
ment
s Conta
ct
Strate
gyThis represents the count of customers
which has passed business purpose
contact policy rules.
Please note that business purpose
contact policy is required to be enabled
at offer level and it is ignored for
“Mandatory” offers and offers available
for Intent with High Confidence Score.
At this funnel step, the business
purpose contact policy is only applied
for channels (batch) which does not use
bundling functionality; currently only
Email channel uses bundling in Bach        This
step is
not
relevan
t for
TIL


709
that
do
not
use
Bun
dling
)mode. Hence, potential drop-offs will be
shown only for non-Email treatments.
12Offer
Self
Cont
entio
n
Strat
egy
No
Bun
dling
(For
Treat
ment
s
that
do
not
use
Bun
dling
)Conta
ct
Strate
gyThis represents the count of customers
which has passed offer self contention
rules.
Please note that offer self contention is
required to be enabled at offer level and
it is ignored for offers available for Intent
with High Confidence Score.
At this funnel step, the offer self
contention is only applied for channels
(batch) which does not use bundling
functionality; currently only Email
channel uses bundling in Bach mode.
Hence, potential drop-offs will be shown
only for non-Email treatments.AllTre
atme
ntsFo
rEligi
bleOff
ersEligible
Offer
Self
Conten
tion
Strateg
y
Releva
nt
Treatm
entsself_cont
ention_tr
eatment_
no_bundl
ing_coun
tYes Offer Self
Contentio
n
Strategy
No
BundlingOfferSelfCo
ntentionStra
tegyNoBun
dling
13Run
time
Volu
me
Cap
acity
Che
ckEligibili
tyThis represents the count of customers
which has successfully passed the run-
time volume capacity check for the
treatment.
Please note that the run-time volume


time volume capacity check for the
treatment.
Please note that the run-time volume
limit is calculated as volume limit
defined at treatment level considering
the control group (if enabled) as well as
de-dupe factor.      This
step is
not
relevan
t for
TIL
14Cha
nnel
Eligi
bilityEligibili
tyThis represents the count of customers
which has passed channel eligibility
rules for each business purpose-
channel combinations as defined in the
relevant proposition filter.Identi
fyEligi
bleTr
eatm
entsB
yTrig
gersApplyC
hannel
Eligibili
tychannel_
eligibility
_countYes Channel
EligibilityChannelElig
ibility
15Cha
nnel
Cont
entio
nConta
ct
Strate
gyThis represents the count of customers
which has passed channel contention
rules.
Please note that channel contention is
required to be enabled at treatment Identi
fyEligi
bleTr
eatm
entsBApplyC
hannel
Conten
tionchannel_
contentio
n_countYes Channel
Contentio
nChannelCo
ntention


710
level and and the contention periods
are needed to be configured for each
channel.yTrig
gers
16Treat
ment
Core
Eligi
bilityEligibili
tyThis represents the count of customers
which has passed the eligibility rules for
the treatment defined in the Squad
(BP)-Channel level Proposition Filters.   Yes Treatmen
t Core
EligibilityTreatmentC
oreEligibility

17Treat
ment
Squ
ad
Eligi
bilityEligibili
tyThis represents the count of customers
which has passed the eligibility rules for
the treatment defined in bespoke Squad
(BP) level strategies.   Yes Treatmen
t Squad
EligibilityTreatmentS
quadEligibili
ty
(1
4)Treat
ment
Eligi
bilityEligibili
tyThis represents the count of customers
which has passed the eligibility rules for
the treatment defined in the Squad
(BP)-Channel level Proposition Filters
as well as defined in bespoke Squad
(BP) level strategies.Identi
fyEligi
bleTr
eatm
entsB
yTrig
gersApplyT
reatme
ntEligib
ilitytreatment
_eligibilit
y_countYes Treatmen
t EligibilityTreatmentEl
igibility
18Appl
yT2T
VSel
fCon
tenti
onFo
rSim
ulati
onConta
ct
Strate
gyThis represents the count of customers
which has passes the Treatment level
contact rules. Identi
fyBes
tTreat
ment
sByTr
igger
sApplyT
reatme
ntSelfC
ontenti
onTreatment
_Self_Con


igger
sApplyT
reatme
ntSelfC
ontenti
onTreatment
_Self_Con
tention_C
ountYes Treatmen
t Self
Contentio
nTreatmentS
elfContentio
n
19Pick
Best
Treat
ment
s For
Offer
(Pick
Best
Cha
nnel)Arbitra
tion
(Best
Treat
ment
By
Offer)This represents the count of customers
which has passed the Pick Best
Treatments For Offer (Pick Best
Channel) step which selects the best
treatment for the offer for the customer
when customer is eligible for multiple
treatments for the same offer and Pick
Best Treatments For Offer is enabled
with appropriate method.
This will only show if drop off if multiple
treatments are eligible for the offer and
the functionality is enabled.Identi
fyBes
tTreat
ment
sByTr
igger
s
 Identify
BestTr
eatme
ntsFor
Offerspick_best
_treatme
nt_by_off
er_countYes Pick Best
Treatmen
ts For
OfferPickBestTre
atmentsFor
Offer
20Glob
al
Cont
act
Strat
egy Conta
ct
Strate
gyThis represents the count of customers
which has passed global contact policy
rules.
Please note that global contact policy is
required to be enabled at offer level and
it is ignored for “Mandatory” offers and       This
step is
not
relevan
t for
TIL


711
Bun
dling
(For
Treat
ment
s
that
use
Bun
dling
)offers available for Intent with High
Confidence Score.
Please also note that, for bundled
treatments, contact strategy is only
applied for Parent treatment.
At this funnel step, the global contact
policy is only applied for channels
(batch) which use bundling functionality;
currently only Email channel uses
bundling in Bach mode. Hence,
potential drop-offs will be shown only
for Email treatments.
21Busi
ness
Purp
ose
Cont
act
Strat
egy
Bun
dling
(For
Treat
ment
s
that
use
Bun
dling
)Conta
ct
Strate
gyThis represents the count of customers
which has passed business purpose
contact policy rules.
Please note that business purpose
contact policy is required to be enabled
at offer level and it is ignored for
“Mandatory” offers and offers available
for Intent with High Confidence Score.
Please also note that, for bundled
treatments, contact strategy is only
applied for Parent treatment.
At this funnel step, the business
purpose contact policy is only applied
for channels (batch) which use bundling
functionality; currently only Email
channel uses bundling in Bach mode.
Hence, potential drop-offs will be shown
only for Email treatments.      This
step is
not
relevan
t for
TIL
22Offer
Self
Cont
entio
n
Strat
egy
Bun
dling
(For


Cont
entio
n
Strat
egy
Bun
dling
(For
Treat
ment
s
that
use
Bun
dling
)Conta
ct
Strate
gyThis represents the count of customers
which has passed offer self contention
rules.
Please note that offer self contention is
required to be enabled at offer level and
it is ignored for offers available for Intent
with High Confidence Score.
Please also note that, for bundled
treatments, contact strategy is only
applied for Parent treatment.
At this funnel step, the offer self
contention is only applied for channels
(batch) which use bundling functionality;
currently only Email channel uses
bundling in Bach mode. Hence,
potential drop-offs will be shown only
for Email treatments.      This
step is
not
relevan
t for
TIL


712
23Bun
dled
Treat
ment
(For
Treat
ment
s
that
use
Bun
dling
)Eligibili
tyThis represents the count of customers
which has successfully passed bundling
functionality.
This step will not show any drop-offs for
parent treatments and will potentially
show drop offs for child treatments
which are “orphan” i.e. does not have
eligible Parent treatment.      This
step is
not
relevan
t for
TIL
24Pick
Best
Treat
ment
For
Cust
omer
(Arbi
tratio
n)Arbitra
tionThis represents the count of customers
which has successfully passed the
arbitration step of the funnel which
selects the best treatment for the
customer.
Please note that
“Mandatory” offers bypasses
arbitration step and it is only applied
for “non-Mandatory” offers. Hence
the drop offs will only be available
for “non-Mandatory” offers.
Arbitration step is applied at offer
level i.e offer with highest priority is
selected first and all eligible
treatments for the best offers are
selected.
This count also includes drop off by
Priority Score Cut OffIdenti
fyBes
tTreat
mentf
orSub
scripti
onIdentify
BestTr
eatme
ntForTI
Lpick_best
_treatme
nt_for_cu
stomer_c
ountYes Pick Best
Treatmen
t For
CustomerPickBestTre
atmentForC
ustomerA new
“Priorit
y
Score
Cut


atmentForC
ustomerA new
“Priorit
y
Score
Cut
Off”
simulat
ion
funnel
step
has
been
consid
ered
but has
been
parked
for now
pendin
g new
story to
change
where
the
“Priorit
y
Score
Cut
Off”
funnel
will be
applied
.
25Treat
ment
Varia
nt
Core Eligibili
tyThis represents the count of customers
which has passed the eligibility rules for
the Treatment Variants for each
Treatment defined in the Squad (BP)
level Proposition Filters.   Yes Treatmen
t Variant
Core
EligibilityTreatmentV
ariantCoreE
ligibility From
this
funnel
step,
the


713
Eligi
bilityPlease note, at treatment variant level,
the eligible treatments and eligible offer
variants come together and hence any
drop offs at offer variant/treatment level
will be visible at this step along with
drop off due to eligibility rules.
Please also note that when multiple
treatment variants are configured for an
treatment, only if a “catch-all” treatment
variant (default, without eligibility) is
defined, the offer variant/treatment
eligibility count will be divided among
the treatment variants. Otherwise,
treatment variant eligibility will show
drop-offs based on eligible customers.
This step also includes the count of
customers which has passed the
additional eligibility rules for specific
Treatment Variants such as (TOBI,
Webchat,Online) using IH and
Tealium Aggregate Events data.count
is
shown
at
treatm
ent
variant
level.

26Treat
ment
Varia
nt
Squ
ad
Eligi
bilityEligibili
tyThis represents the count of customers
which has passed the eligibility rules for
the Treatment Variants for each
Treatment defined in bespoke Squad
(BP) level strategies.
Please note, at treatment variant level,
the eligible treatments and eligible offer
variants come together and hence any
drop offs at offer variant/treatment level
will be visible at this step along with
drop off due to eligibility rules.
Please also note that when multiple
treatment variants are configured for an
treatment, only if a “catch-all” treatment
variant (default, without eligibility) is
defined, the offer variant/treatment


variant (default, without eligibility) is
defined, the offer variant/treatment
eligibility count will be divided among
the treatment variants. Otherwise,
treatment variant eligibility will show
drop-offs based on eligible customers.
This step also includes the count of
customers which has passed the
additional eligibility rules for specific
Treatment Variants such as (TOBI,
Webchat,Online) using IH and
Tealium Aggregate Events data.   Yes Treatmen
t Variant
Squad
EligibilityTreatmentV
ariantSquad
Eligibility
(2
2)Treat
ment Eligibili
tyThis represents the count of customers
which has passed the eligibility rules for Identi
fyTreEligible
Treatmtreatment
_var_eligiYes Treatmen
t Variant TreatmentV
ariantEligibilFrom
this


714
Varia
nt
Eligi
bilitythe Treatment Variants for each
Treatment defined in the Squad (BP)
level Proposition Filters as well as
defined in bespoke Squad (BP) level
strategies.
Please note, at treatment variant level,
the eligible treatments and eligible offer
variants come together and hence any
drop offs at offer variant/treatment level
will be visible at this step along with
drop off due to eligibility rules.
Please also note that when multiple
treatment variants are configured for an
treatment, only if a “catch-all” treatment
variant (default, without eligibility) is
defined, the offer variant/treatment
eligibility count will be divided among
the treatment variants. Otherwise,
treatment variant eligibility will show
drop-offs based on eligible customers.
This step also includes the count of
customers which has passed the
additional eligibility rules for specific
Treatment Variants such as (TOBI,
Webchat,Online) using IH and
Tealium Aggregate Events dataatme
ntVari
ationsent
Variatio
ns For
Eligible
Treatm
entsbility_cou
ntEligibility ity funnel
step,
the
count
is
shown
at
treatm
ent
variant
level.

27Appl
yT2T
VSel
fCon
tenti
onFo
rSim
ulati
onConta
ct
Strate
gyThis represents the count of customers
which has passes the Treatment To
Treatment Variant level contact rules. Identi
fyTre
atme
ntVari
ationsApplyT
2TVSel
fConte


fyTre
atme
ntVari
ationsApplyT
2TVSel
fConte
ntionT2TV_Sel
f_Contenti
on_CountYes ApplyT2T
VSelfCon
tentionFo
rSimulatio
nApplyT2TV
SelfContent
ionForSimul
ation
28Pick
Best
Treat
ment
Varia
nt By
Treat
mentArbitra
tion
(Best
Treat
ment
Variant
by
Treat
ment)This represents the count of customers
which has passed the “Pick Best
Treatment Variant” funnel step, which
selects the best Treatment Variant
based on pre-defined rank, in case
multiple treatment variants are eligible
for the same treatment and the same
customer.Identi
fyTre
atme
ntVari
ationsBest
Treatm
ent
Variant
By
Treatm
entpick_best
_treatme
nt_var_b
y_treatm
ent_coun
tYes Pick Best
Treatmen
t Variant
By
Treatmen
tPickBestTre
atmentVaria
ntByTreatm
ent
29Pick
Best
Treat
ment
VariaArbitra
tion
(Best
TreatThis represents the count of customers
which has passed the “Pick Best
Treatment Variant by Customer ” funnel
step, which selects the best Treatment Identi
fyTre
atme
ntVari
ationsBest
Treatm
ent
Variant
For pick_best
_treatme
nt_var_b
y_custoYes Pick Best
Treatmen
t Variant
For
CustomerPickBestTre


y_custoYes Pick Best
Treatmen
t Variant
For
CustomerPickBestTre
atmentVaria
ntForCusto
mer


715
nt
For
Cust
omerment
Variant
by
Custo
mer)Variant based on Priority (inherited from
Offer level Priority).Custo
mermer_cou
nt
30Cont
rol
Grou
p
Split
-
Targ
etContro
l
Group
SplitThis represents the count of customer
in the potential “target” group for the
treatment.
Please note that this is not a typical
funnel step but created just to represent
the target-control split and this will only
show a split if a control group is
configured. Otherwise, all count will be
shown in “target”.
Please also note that control group can
be set at Offer level as well as
Treatment level. Treatment level control
group, if set, overrides Offer level
control group. If not set, Treatment level
inherits Offer level control group.Selec
tBetw
eenO
fferO
RTre
atme
ntPot
ential
Contr
olSpli
tTarget
Treatm
ents
Onlytreatment
_in_pote
ntial_targ
et_countNo N/A N/A  Only
used
for
IVR,
SMS &
App
31Cont
rol
Grou
p
Split
-
Cont
rolContro
l
Group
SplitThis represents the count of customer
in the potential “control” group for the
treatment.
Please note that this is not a typical
funnel step but created just to represent
the target-control split and this will only
show a split if a control group is
configured. Otherwise, all count will be


show a split if a control group is
configured. Otherwise, all count will be
shown in “target”.
Please also note that control group can
be set at Offer level as well as
Treatment level. Treatment level control
group, if set, overrides Offer level
control group. If not set, Treatment level
inherits Offer level control group.Selec
tBetw
eenO
fferO
RTre
atme
ntPot
ential
Contr
olSpli
tControl
Treatm
ents
Onlytreatment
_in_pote
ntial_con
trol_coun
tNo N/A N/A  Only
used
for
IVR,
SMS &
App
32Final
Sele
ctionFinal
Selecti
onThis step is only relevant for Customer
Leven Simulation and represents the
final selection after passing all funnel
steps
 N/A N/A N/A Yes Final
SelectionFinalSelecti
on


716
TIL Funnel and Distribution Simulation Query
Funnel Step Simulation :  Run the below query and provide simulation id as input in single quotation(''), as shown in the screenshot, when
prompted.
Distribution test Simulation: Run the below query and provide table name( distributiontestsimulation1 or distributiontestsimulation2 ) as
input , as shown in the screenshot, when prompted.

TIL Funnel Qu
12 May 2022, 12:05 PMery (1)
Distribution tes …
16 Dec 2020, 07:35 AMn Query


717
Simulation Output Tables
Tables to query for Batch Simulation
simulation_funnel_batchnba_V1 for Batch CustomerLevel Simulation version 1.
simulation_funnel_batchnba_V2 for Batch CustomerLevel Simulation version 2.
simulation_funnel_summary_batchnba for Batch Funnel Simulation.
simulation_distribution_summary for Batch Distribution Simulation.
Tables to query for GetNBA Simulation
simulation_funnel_getnba_V1 for GetNBA CustomerLevel Simulation version 1 .
simulation_funnel_getnba_V2 for GetNBA CustomerLevel Simulation version 2.
simulation_funnel_summary_getnba for GetNBA Funnel Simulation.
simulation_distribution_summary for GetNBA Distribution Simulation .
Tables to query for TIL Simulation
simulation_funnel_til_V1 for TIL CustomerLevel Simulation version 1.
simulation_funnel_til_V2 for TIL CustomerLevel Simulation version 2.
simulation_funnel_summary_til for TIL Funnel Simulation.
simulation_distribution_summary for TIL Distribution Simulation.


718
Miscellaneous


719
AOM Proposition Hierarchy


720
AOM Decisioning Funnel

1 Identify Intent Intent &
Confidence
RulesNo No No No No No Yes
2 Identify Offers for
Eligible Intents No No No No No No Yes
3 Identify Eligible
OffersOffers & Offer
EligibilityYes Yes Yes Yes Yes Yes Yes
4 Identify Offer
Variants For
EligibleOffersOffer Variants
& Offer
Variants
Eligibility,
Offer to Offer
VariantsYes Yes Yes Yes Yes Yes Yes
5 All Treatments for
Eligible OffersSeparation by
execution
modeNo Yes -
SMS,
OBC &
AppPushYes - SMS, OBCYes - Web Yes -
IBCCYes -
Web,
IBCC,
RetailYes -
Email,
SMS,
OBC,
DM,
AppPush
6 Apply Channel
EligibilityChannel
Eligibility by
Business
PurposeNo Yes Yes Yes Yes Yes Yes
7 Apply Channel
Contention No Yes - OBC
OnlyNo No No No No
8 Apply Treatment
EligibilityTreatments,
No Eligibility
(for now)Yes Yes Yes Yes Yes Yes Yes # Decisioning
Funnel StepDescription Separated
by Squad
ZoneApplied
for
Executio
n Mode -
TIL
(MVP)
e.g Data
DepletionApplied for
Execution
Mode - Process
Events
e.g Text2SwitchApplied for
Execution
Mode -
GRPL
e.g. HBB
UpgradeApplie
d for
Execut
ion
Mode -
NBAA


UpgradeApplie
d for
Execut
ion
Mode -
NBAA
e.g.
Assiste
d
Upgrad
eApplied
for
Executi
on
Mode -
GetNB
A
e.g.
Trade InApplied
for
Executio
n Mode -
Batch
e.g.
AdCons


721
 9 Identify Best
TreatmentPriority
calculation,
use of
models,
Ranking and
choosing top xNo Yes Yes Yes Yes Yes Yes
10 Identify Treatment
Variations Treatment
Variants &
Treatment
Variants
Eligibility,
Treatment to
Treatment
VariantsYes Yes Yes Yes Yes Yes Yes
11 Populate Output
PropertiesChannel/Interf
ace specificNo Yes Yes Yes Yes Yes Yes
12 Control Groups
(Real-time) No Yes -
AppPush
OnlyNo No No No No
13 Set IH Reporting
focused or
use in rulesNo Yes Yes Yes Yes Yes Yes
14 Revalidate
(Extractor) No Yes - OBC
OnlyNo No No No No
15 Dedupe (Extractor) No Yes - OBC
OnlyYes - OBC Only No No No Yes -
OBC &
DM Only
16 Volume Constraints
(Extractor)By Channel or
Sub Channel
(Managed by
App)No Yes - OBC
OnlyNo No No No Yes -
Email,
SMS
OBC, DM
&
AppPush
17 Control Groups
(Extractor) No Yes - OBC
OnlyYes - OBC Only No No No Yes -
Email,
SMS
OBC, DM
&
AppPush


722
Trade In - Phase 2; Payment Methods & When Bought With (WBW) Offers
Background:
Trade-In Enhancements aim is to introduce a multi-channel device trade-in capability that will allow new and existing customers to get value
in exchange for their old device.
Customers completing the trade-in valuation journey will be able to get a confirmed price by completing an on-device diagnostic process.
They will be able to choose how they get paid from a number of payment methods. A new partner (MCE) will provide the core device
valuation capability.
The device trade-in value is to be integrated in a way such that the value of the device is used instead of e.g. cash/card payment (or part
payment), in any transaction, whether that be to reduce monthly fees, pay upfront for something, or simply to get something without paying';
trade in-ins will be offered stand alone, as part of new acquisitions, as part of upgrades.
The 20.12 (previous Phase B) component delivered the capability to assess the eligibility of a given customer for certain payment methods
and determine the provision of One-off, Monthly Bill Credit and BACS payment options depending on a number of determining factors.
Phase D, this phase of work, will deliver the capability to assess the eligibility of a given customer for further payment methods and
determine the provision of Upfront / Flexi BC credit payment options depending on a number of customer and transaction attributes.
Further, this phase of work allows for an ‘enhanced’ price to be returned to a customer under a given set of specified circumstances; this
‘enhanced’ price is associated with what are known as When Bought With (WBW) offers.
The ’scope’ of this phase of Trade In can be, broadly speaking, broken down into a number of discreet, logically decomposed, ‘functional’


areas (note, this is not the totality of the required work, nor should it be interpreted as a solution blueprint). These are:
1. Configuration of API(s) GetNBA and SetNBAResponse for updated payloads
2. Extending payment method rules
3. Implementing WBW enhanced pricing rules
4. Provision of a toolset to allow business users to configure rulesets associated with enhanced pricing
5. Extension of data being captured and being written to reporting system(s)
6. Extension of underlying logic framework(s)
7. Extension to logic error handling


723
Solution Overview:
List of Solution Jira Tickets:
List of Logic Specific Jira Tickets:
AOM-2717 Extend Trade In Payment Method Eligibility Rules
AOM-2720 Create Trade In WBW Eligibility Rules
AOM-2721 Extension of PM Tool for WBW Offers
AOM-2722 Extension of IH for When Bought With (WBW) Offers
AOM-2723 Update IH extract to EDW for When Bought With (WBW) Offers
AOM-2745 Extend NBA Logic Exception Report for WBW Processing
AOM-2747 Extend Product Catalogue for Additional Payment Methods
AOM-2753 Create Trade In WBW ‘Multiplier’ Component
AOM-2828 Include SetNBA API in TradeIn Channel Response(s)
AOM-2884 Extend NBA Decisioning Funnel for Trade In
AOM-2931 Create Data Pages to Support Extended Product CatalogueAOM-2716 TradeIn - Extend Customer Payment Method Options & Introduce “When Bought With” (WBW) Offers [Ticket Type:
EPIC]


724
NBA Funnel:
A number of changes are required to the underlying logic funnel ‘architecture’ already implemented. This funnel architecture ensures all
applicable ‘inputs’ are taken into account, associated rulesets are executed and the correct action is determined, with any / all elements of
that decision process written (as applicable) for reporting purposes.
1. Add Intent Logic to GetNBA Flow for Trade In
1.1 Intent Configuration
List of Intents
Intent to BusinessPurpose
1.2 Update DDS -EventToIntent
Update EventToInent Decision data structureAOM-2720 Create Trade In WBW Eligibility Rules
AOM-2753 Create Trade In WBW ‘Multiplier’ Component
AOM-2884 Extend NBA Decisioning Funnel for Trade InAOM-2717 Extend Trade In Payment Method Eligibility Rules
New TradeIn-Handset TradeIn Handset Intent Key Level1 Intent Level2 Intent
TradeIn-Handset Null TradeInIntent Key Confidence Score High Confidence Score Low


725
Data for TradeIn will be as follows (assumption):
2. Add Cohorts for Trade In WBW Rules
Cohorts was decommissioned based on feedback from CVM
A Cohort (for current purposes) represents a grouping of eligibility rules that allows for the definition (and subsequent identification) of
customer(s) who meet the criteria for the various ‘From’ and ‘To’ rules contained within the WBW Rules Matrix (see Trade In_HLD v4.0,
Section 8.2.2.1).
2.1 Assumptions
We will create 1 customer cohort per WBW rule (6 cohorts in total).
Note: based on what is documented, it has been determined that any WBW ‘multiplier’ (component for determining any uplift for an
‘enhanced’ customer price, is the same across all payment methods. Should it subsequently be determined the multiplier can vary by
payment method, the number of cohorts will grow in line with that decision; there is nothing apparent that inclines us to believe the
multiplier can vary by Payment Method from the published rules within the HLD.
Whilst the multipliers outlined in the DDS structure (below) might imply a 'fixed' multiplier value, it has been confirmed in discussion with
the business that a 'multiplier', at least in the first instance, might reasonably be one of the following:
A set £ value / amount
A simple multiplier based on quote price
A guaranteed minimum (future) price (e.g. equal to the flex upgrade fee)
A % increase over the top of the quote price
A £ increase over the top of the quote price
List of "Specified" and "Any +£" for tariff/plan and device will be managed by the business via the PM Tool; anything that is not defined /


does not meet the criteria for these two designations will naturally be determined as "Any" (structure below).
The condition for .Eligible flag for cohorts is dependent on DDS for tariffs and devices.Web GetNBA TradeIn  TradeIn-Handset TBC
Retail GetNBA TradeIn  TradeIn-Handset TBC
InboundCC GetNBA TradeIn  TradeIn-Handset  TBCChannel ExecutionMode PrimaryContext SecondaryContext Intent ConfidenceScore


726
2.2 Cohort Design
It has been agreed that the PM tool (business configuration ‘portal’) will allow for the definition of any / all WBW rules; that is the creation
and mapping of the cohorts, and the allocation of a single multiplier to each cohort mapping. In this way it is expected the business will be
provided with a solution that meets their needs, provides sufficient flexibility going forward, and remains consistent with the broader
implementation framework.


727
Sample cohort in PM Tool


728
A number of steps will be followed in the execution of the logic underpinning the WBW Matrix definition.
a. Create strategies to check if the customer is eligible for the cohort based on the relevant columns as per the
table below
For each of the strategies above, follow the design pattern as below:
Enable External Input
Connect to Set Property component and set Eligible = false
Connect to Filter Component - check if the column value is Empty
Connect to Set Property component and set Eligible = true
Connect to Filter Component - check if the column value is not Empty
Evaluate cohort eligibility based on the relevant requirement (TBC) and set Eligible to true/false as relevant
Connect to Results
The diagram below details an example for the strategy EvaluateCohortByCustomerType (existing strategy):
b. Update Strategy - EvaluateCohorts
Add sub-strategy calls to below and join to filter and group by as per the below diagram:
EvaluateCohortByPlan
EvaluateCohortByDevice
EvaluateCohortByPlan Plan
EvaluateCohortByDevice DeviceStrategy Column from decision data


729
3. Trade In Offer Catalog
Payment Methods are Parent Offers
WBW Products are Child Offers
Payment eligibility matrix will be implemented as Offer eligibility.
WBW rules matrix will be implemented via Customer Cohorts.
Context data will be used for eligibility rules.
List of payment methods & price will be provided within context.
Only eligible payment methods with corresponding prices will be available in output.
3 Channels Web, InboundCC & Retail
Default Variants will be used for offer & treatments
Each Payment method will be mapped to a product code (Offer-OfferVariant mapping functionality) (Codes TBC)
Each WBW child offer will be mapped to the product code (Offer-OfferVariant mapping functionality) (Codes TBC)


730
4. Strategy Framework Changes
4.1 High Level Diagram


731
4.2 TradeInRules1
Add new rules for Payment Method Eligibility as per offer catalog
Add new rules for WBW Eligibility as per offer catalog
4.3 IdentifyEligibleTradeInOffers
Update “TradeInOfferEligibility“ proposition filter to add new parent offers (Payment Methods)
TradeInUpfront
TradeInFlexiBC
Update “TradeInOfferEligibility“ proposition filter to add new child offers (WBW)
WBWDiscountMonthlyCredit
WBWDiscountOneTimeCredit
WBWDiscountUpfront
WBWDiscountFlexiBC
4.4 IdentifyEligibleOffers
Remove switch that flips between IVR and TradeIn for GetNBA execution mode (as per diagram below)
Connect the IdentifyOffersForEligibleIntents sub strategy to ChooseOffersByExecutionMode switch


732
4.5 ApplyTradeInTreatmentEligibility
Update TradeInWebTreatmentEligibility proposition filter to add the below 2 web treatments and set to “Default criteria” for eligibility
TradeInUpfront_Web
TradeInFlexiBC_Web
Update TradeInInboundCCTreatmentEligibility proposition filter to add the below 2 web treatments and set to “Default criteria” for
eligibility
TradeInUpfront_InboundCC
TradeInFlexiBC_InboundCC
Update TradeInRetailTreatmentEligibility proposition filter to add the below 2 web treatments and set to “Default criteria” for eligibility
TradeInUpfront_Retail
TradeInFlexiBC_Retail


733
4.6 PopulateOutputPropertiesForGetNBA
Add logic to calculate enhanced price (Note: as per TIL SOA Specification samples, pricing is excluding VAT)
Add enhanced price by ensuring that spot price and enhanced price for same payment method are linked together (join on payment
method)
Update strategy to send 2 items (product codes) per offer if enhanced price is available (parent + child)


734
4.7 SetIHForWeb
Add the below 3 properties (TBC) to the “Set IH” component:
PaymentMethod
SpotPrice
EnhancedPrice
4.8 SetIHForInboundCC
Add the below 3 properties (TBC) to the “IH properties” component:
PaymentMethod
SpotPrice
EnhancedPrice


735
4.9 SetIHForRetail
Add the below 3 properties (TBC) to the “Set IH” component:
PaymentMethod
SpotPrice
EnhancedPrice


736
5. Impact Assessment*


737

*Remain subject to (minor) refinement
**Pure development effort
***Overall manday of the analysis, design, development, testing, transition to Operations, delivery and management


738
Assisted Upgrade - Record Deal - Options
Please note that the Impacted Area and VROM does not include the impact for “Capture Response for Deal” as that design will
follow the outcome of the discussion on the options below but will not have additional impact based on the option chosen.
Option 1 - IH & IH Reporting
Summary
Write all deal details in IH (AS-IS)
Write additional reporting details (Deal Level and Product Level) in IH Reporting (AS-IS)
Impacted Areas
Option 2 - IH, IH Reporting & DealDetails (New)
Summary
Introduce a “Dummy” Deal level headline proposition which does not flow through the Assisted Funnel but get attached to the output
Only Deal level headline proposition will be written to IH
Deal level additional reporting details will be written to IH Reporting
New DealDetails table will be introduced to write all details of individual assisted propositions including Product level additional reporting
details
Product level additional reporting attributes will be removed from IH ReportingNo changes to existing process & logic
All deal information (IH only) is available for decisioning in both
Assisted and Non-Assisted contextAdditional IH will be available to decisioning in both Assisted and
Non-Assisted context but there is no requirement to use this data
(so far)
Depending on the size of these additional records, there may be
a performance impact
Future IH changes on Non-Assisted area may have impact in
Assisted area as IH is common
Difficult to distinguish between Assisted IH and Non-Assisted IH
for Assisted specific reporting Pros Cons
Logic Yes Changes for new attributes in IH Reporting 5
App Yes Class changes for IH Reporting
Change in IH Reporting Extract?
DB Yes  Change in IH Reporting table 2
DWH Yes Change in IH Reporting Extract ingest process Low (AS-IS process of


DWH Yes Change in IH Reporting Extract ingest process Low (AS-IS process of
changing extract)Area Yes/No Comments VROM


739
Impacted Areas
Option 3 - Deal (New) & DealDetails (New)
Summary
New Deal table will be introduced to write all Deal level information (without any need for “Dummy” Deal level headline proposition)
including Deal level additional reporting details
New DealDetails table will be introduced to write all details of individual assisted propositions including Product level additional reporting
details
Deal & Product level additional reporting attributes will be removed from IH Reporting
Impacted AreasOnly headline deal level details (IH Only) is available for
decisioning in both Assisted and Non-Assisted context
Flexibility on accessing Deal Details for individual assisted
propositions on demand in both Assisted and Non-Assisted
context, as and when needed
No performance impact to processingBespoke solution which requires maintenance through Pega
Upgrades
Impact on DWH IH Ingest process due to additional extracts and
change to existing extracts Pros Cons
Logic Yes New “Dummy” Deal level headline proposition
Changes to IH write logic15
App Yes Class changes for IH Reporting
New Class for Deal Details table
Change in IH Reporting Extract
New Deal Details Extract ?
DB Yes Change in IH Reporting table
New Deal Details table4
DWH Yes Change in IH Reporting Extract ingest process
New ingest process for Deal Details ExtractMediumArea Yes/No Comments VROM
Flexibility on accessing Deal & Deal Details for individual assisted
propositions on demand in both Assisted and Non-Assisted
context, as and when needed
No performance impact to processing (more performant than
Option 2 as nothing is being written in IH)Bespoke solution which requires maintenance through Pega
Upgrades
Impact on DWH IH Ingest process due to additional extracts and
change to existing extracts
Common Contact Strategy between Assisted and Non-Assisted


change to existing extracts
Common Contact Strategy between Assisted and Non-Assisted
context is complex as Deal is not available in IHPros Cons
Area Yes/No Comments VROM


740
Logic Yes Changes to IH write logic 10
App Yes Class changes for IH Reporting
New Class for Deal & Deal Details table
Change in IH Reporting Extract
New Deal & Deal Details Extract ?
DB Yes Change in IH Reporting table
New Deal & Deal Details table4
DWH Yes Change in IH Reporting Extract ingest process
New ingest process for Deal & Deal Details ExtractHigh


741
Prepare Data Data Flow Usage
 PrepareBatchData PrepareDataForBatchNBA Batch, Pega OOTB Simulation
PrepareBatchData PrepareDataForBaselineSimulation Customer Level Baseline Simulation
PrepareDataForGetRecommendation IdentifyCustomerIntentsForGetRecommenda
tionNBAA (Assisted Upgrade)
GetProductList
PrepareRealtimeData IdentifyCustomerIntentsRealTime GetNBA, TIL
PrepareRealtimeData GetNextBestContent Get Next Best Content (Next Scenario
Template)
PrepareRealtimeData GetRecommendationList GRPL
PrepareRealtimeData IdentifyBestMicrositeTreatments Landing Pages
PrepareRealtimeDataForProcessEvent IdentifyCustomerIntentsRealTimeForProcess
EventProcessEventPrepare Data Data Flow Referenced by Data Flow Execution Context


742
Adding New Channel In AOM
Ingest Data Events/New Feed into AOM Yes Capability change Capability change
Mode of Execution Specify which Execution Mode
the channel will be introduced
- e.g.
Batch
BundleEvent (TIL)
ProcessEvent (T2S)
GetNBA Yes Capability change Capability
Change ( need to
pass the Mode of
Execution to
Datalfow as
Context
parameter from
App)
Use of Intent Specify if the Channel will use
AOM Intent FrameworkYes Capability (if
channel needs to
be excluded from
Intent FW)
Config/Opti - if
channel uses Intent
FWNo Impact
Global Eligibility This feature is Channel
agnostic and is included as
part of the AOM Strategy FW
for Batch ModeNo Config/Opti - if
channel uses this
featureNo Impact
Control Group Contention
(quarantine)This feature is Channel
agnostic and is included as
part of the AOM Strategy FW No Config/Opti - if
channel uses this
featureNo Impact
Global Contact Strategy This feature is Channel
agnostic and is included as
part of the AOM Strategy FW
for Batch ModeNo Config/Opti - if
channel uses this
featureNo Impact
Business Purpose Contact
StrategyThis feature is Channel
agnostic and is included as
part of the AOM Strategy FW
for Batch ModeNo Config/Opti - if
channel uses this
featureNo Impact
Offer Self Contention StrategyThis feature is Channel
agnostic and is included as
part of the AOM Strategy FWNo Config/Opti - if
channel uses this
featureNo Impact
Offer Eligibility This feature is Channel


channel uses this
featureNo Impact
Offer Eligibility This feature is Channel
agnostic and is included as
part of the AOM Strategy FWNo Capability - to
introduce the
eligibility
placeholdersNo ImpactFeature Comments Story Needed Logic Change App & Data
Change


743
Config/Opti - if
channel uses this
feature
Offer Variant Eligibility This feature is Channel
agnostic and is included as
part of the AOM Strategy FWNo Capability - to
introduce the
eligibility
placeholders
Config/Opti - if
channel uses this
featureNo Impact
Pick Best Offer Variant This feature is Channel
agnostic and is included as
part of the AOM Strategy FWNo Config/Opti - if
channel uses this
featureNo Impact
Run time Volume Capacity
CheckThis feature is included as part
of the AOM Strategy FW for
Batch ModeNo Config/Opti - if
channel uses this
featureNo Impact
Channel Eligibility Specify if the Channel will use
Channel EligibilityYes Capability - to
introduce the
eligibility
placeholders
Config/Opti - if
channel uses this
featureNo Impact
Channel Contention Specify if the Channel will use
Channel ContentionYes Config/Opti - if
channel uses this
featureNo Impact
Treatment Eligibility This feature is included as part
of the AOM Strategy FWNo Capability - to
introduce the
eligibility
placeholders
Config/Opti - if
channel uses this
featureNo Impact
SubChannel Configuration Specify if the Channel will use
SubChannel/DivisionYes Capability change No Impact
Pick Best Treatments For
OfferThis Feature is included as
part of the AOM Strategy FW
for execution modes which
involves with multiple channels
fora customer in same
decisioning context No Config/Opti - if
channel uses this
featureNo Impact
Bundling Specify if the Channel will use
BundlingYes Capability change No Impact


featureNo Impact
Bundling Specify if the Channel will use
BundlingYes Capability change No Impact
Pick Best Treatment For
CustomerSpecify requirements for
arbitration and decision mix for Yes Capability change No Impact


744
the channel
Friendly User Testing
(Treatment Variant Level)This feature is included as part
of the AOM Strategy FWNo Config/Opti - if
channel uses this
featureNo Impact
Treatment Variant Eligibility This feature is included as part
of the AOM Strategy FWNo Config/Opti - if
channel uses this
featureNo Impact
Pick Best Treatment Variant
By TreatmentThis feature is included as part
of the AOM Strategy FWNo Config/Opti - if
channel uses this
featureNo Impact
Pick Best Treatment Variant
For CustomerThis feature is included as part
of the AOM Strategy FWNo Config/Opti - if
channel uses this
featureNo Impact
Control Group This feature is included as part
of the AOM Strategy FW for
Batch Mode
Specify requirements for
control group for the channel if
it is not Batch ModeYes Capability change No Impact
Populate Output Properties Specify requirements for
channel outputYes Capability change Capability change
( new File or any
other means of
output)
Only Data
Impact
Set Interaction History on
SelectionSpecify requirements for
channel specific IH Yes Capability change Capability change
Revalidation This feature is part of the
Extractor process and only
available for Channels which
are delivered online
 Specify requirements for
channel if relevantYes Capability change No Impact
Dedupe This feature is part of the
Extractor process and only
available for Channels which
are delivered online
Specify requirements for
channel if relevantYes Capability change No Impact
Volume Constraints This feature is part of the
Extractor process and only
available for Channels which
are delivered online Yes Capability change No Impact


745
 Specify requirements for
channel if relevant
Set Interaction History on real-
timeSpecify requirements for
channel specific IH if available
in real-time (Capture
Response)Yes Capability change Cabability
Change
Set Interaction History via
Batch FeedSpecify requirements for
channel specific IH if available
as off-line feedYes Capability change Cabability
Change
Need to consume
the feeds using
Event Framework

Seed testing Specify if this feature is
required for the channel (as
this functionality is not part of
the main flow in AOM Strategy
FW) Yes Capability change Capability change
Conditional Investigation This feature is included as part
of the AOM Strategy FW for all
real-time mode of execution No Config/Opti - if
channel uses this
featureNo Impact
Development Verification
Testing (DVT)This feature is included as part
of the AOM Strategy FW for all
real-time mode of execution No Config/Opti - if
channel uses this
featureNo Impact
Simulation This feature is included as part
of the AOM Strategy FW for
the following execution modes
-
Batch
GetNBA
BundleEvent
If the channel is part of any of
the above execution modes,
then no additional change is
required.
Otherwise, specify
requirements for the channelYes Capability change Capability change


746
Adding New Squad In AOM
Mode of Execution Squad is introduced for all
Execution Modes in AOMNo Capability change
Business Purpose Contact
StrategyThis feature is available all
Squads No Config/Opti - if
Squad uses this
feature
Offer Eligibility This feature is included as part
of the AOM Strategy FW
included bespoke Squad Level
eligibility placeholderNo Capability - to
introduce the
eligibility
placeholders
Config/Opti - if
Squad uses this
feature
Offer Variant Eligibility This feature is included as part
of the AOM Strategy FW
included bespoke Squad Level
eligibility placeholderNo Capability - to
introduce the
eligibility
placeholders
Config/Opti - if
Squad uses this
feature
Treatment Eligibility This feature is included as part
of the AOM Strategy FW
included bespoke Squad Level
eligibility placeholderNo Capability - to
introduce the
eligibility
placeholders
Config/Opti - if
Squad uses this
feature
Treatment Variant Eligibility This feature is included as part
of the AOM Strategy FW
included bespoke Squad Level
eligibility placeholderNo Capability - to
introduce the
eligibility
placeholders
Config/Opti - if
Squad uses this
feature
Populate Output Properties This feature is included as part
of the AOM Strategy FW
included bespoke Squad Level
placeholderNo Capability - to
introduce the
placeholders
Config/Opti - if
Squad uses this  Feature Comments Story Needed Logic Change App & Data
Change


747
 feature
Set Interaction History on
SelectionThis feature is included as part
of the AOM Strategy FW
included bespoke Squad Level
placeholderNo Capability - to
introduce the
placeholders
Config/Opti - if
Squad uses this
feature


748
Logic Design Approach
This page will detail the logic design and changes to strategy FW for various workstreams in VFUK AOM Project


749
Release 1.7


750
AppPush Design Approach
0. Rule Renaming and Rehousing (Ravi)

1. PM Tool Catalogue (Ravi)
Introducing New Channel - AppPush
Extending TreatmentToTreatmentVariations for AppPush Sub channels - Inbox, In App, Push Notification
Create new entries as per the Offer catalogue shared

2. Data Flow - IdentifyBestTreatmentsByTriggers (existing)(Sunand)-Done
New Filter for AppPush channel → New Destination for App Push Data Flow

3. Data Flow - ProcessAppPush(Sunand).Done
Destinations
Call New Activity for AppPush (need the activity name from App Team)
Interaction History (need to check relevant User story for AppPush IH requirements) - AOM-848
IH is loading when the error message is empty, the properties asper AOM-848 will be added in SetIHAndTILResponse strategy.

4. Strategy - IdentifyEligibleUpsellOffers (existing) (Zeynep)-Done
Update global rules as per renamed rules
Implement offer level arbitration as per new requirement; replace existing

5. Proposition Filter - UpsellOfferEligibility (existing) (Sunand) inprogress
Update eligibility rules as per offer catalogue

6. Proposition Filter - OfferVariationsEligibility (existing) (Sunand) Done
Update eligibility rules as per offer catalogue

7. Proposition Filter - ChannelBusinessPurposeEligibility (existing) (Zeynep) Done
Add channel eligibility rules for AppPush channel as per offer catalogue

8. Proposition Filter - AppPushTreatmentEligibility (Ravi)Done
Add  eligibility rules for AppPush treatments as per offer catalogue

9. Strategy - ApplyTreatmentEligibility (existing) (Ravi)Done


751
Add New filter for AppPush channel
Link to new proposition filter - AppPushTreatmentEligibility

10. Strategy - IdentifyBestTreatment (existing) (Zeynep) Done
Add New filter for AppPush channel
Add new prioritize component for AppPush treatments

11. Strategy - IdentifyTreatmentVariations  (existing) (Sunand) Done
Update data join component - Eligible Treatment Variants For Eligible Treatment to include new mapping for AppPush specific properties.
We will be setting attributes  in below (one ore multiple) that comes from PM tool through “TreatmentToTreatmentVariations”
PushNotificationJSON
InAppNotificationJSON
InboxNotificationJSON
12. Proposition Filter - TreatmentVariationsEligibility (existing)(Ravi) Done
Update eligibility rules as per offer catalogue

13. Strategy - PopulateOutputPropertiesForTrigger (existing)(Zeynep)Done
Introduce a new path ( with Filter) for App push channel. Introduce New strategy for AppPush PopulateOutputPropertiesForAppPushTrigger
Populate output properties as per Chetan’s email on dynamic fields

14. Strategy - CheckForDefaultOffer (existing)(Sunand) Done
Introduce a new path ( with Filter) for App push channel.
assuming: no default offer(based on the current catalogue)
15. Strategy - SetIHAndTILResponse (existing)(Sunand)
Add new Set property to set AppPush related IH attributes like
1.Push ID
2.Subchannel
Note: Push ID will populate from API, so need to get how we can get it to our logic.
16. Strategy - ApplyRampUpRule (existing)(Zeynep) Done
Current logic will alow only SMS and outbound channels, so we will Introduce a new path ( with Filter) for App push channel.


753
Batch NBA Design Approach
A. In NBA Case
1. Preparing data for Batch NBA (Praveen)
1a. Data Flow - PrepareDataForBatchNBA
Class - VFUK-FW-AOMFW-Data-Subscription
Uses PrepareBatchData and writes to Cassandra data set SubscriptionDataForBatchNBA
Failure - Restart: If Fails, truncate data set SubscriptionDataForBatchNBA and restart data flow
1b. Data Flow - PrepareBatchData (Use existing)
1c. C* Data Set - SubscriptionDataForBatchNBA
Class - VFUK-FW-AOMFW-Data-Subscription
Key - CustomerID

2. Identify Customer’s Intent and update C* Data Set - SubscriptionDataForBatchNBA (Homayra)
2a. Data Flow - IdentifyCustomerIntents
Uses data set SubscriptionDataForBatchNBA as input and calls strategy IdentifyCustomerIntents and updates CustomerIntents pagelist in
Subscription class in data set SubscriptionDataForBatchNBA
Failure - Restart: If Fails, truncate data set SubscriptionDataForBatchNBA and  restart data flow
2b. Create Class - VFUK-FW-AOMFW-Data-CustomerIntents (Jira for App Team)
Properties
Intent (text)
BusinessPurpose (text)
2c. Create pagelist property - CustomerIntentList (Jira for App Team)
of type (VFUK-FW-AOMFW-Data-CustomerIntents) in VFUK-FW-AOMFW-Data-Subscription
2d. Strategy - IdentifyCustomerIntents
Identifies customer intents and returns eligible customer intent (one per BusinessPurpose)
2d.1. Decision Data - Intent
Disaffected TRUE 07/05/2020 31/12/3500 90


Disaffected TRUE 07/05/2020 31/12/3500 90
Discover TRUE 07/05/2020 31/12/3500 60
Enhance TRUE 07/05/2020 31/12/3500 70Intent Enabled Start Date End Date Score


754
2d.2. Decision Data - BusinessPurpose
2d.3. Proposition DecisionData - BusniessPurposeToIntent under Issue NonPropositonsHelp TRUE 07/05/2020 31/12/3500 80
Join TRUE 07/05/2020 31/12/3500 100
Leave TRUE 07/05/2020 31/12/3500 100
Neutral TRUE 07/05/2020 31/12/3500 50
Renew TRUE 07/05/2020 31/12/3500 80
Acquisition TRUE 07/05/2020 31/12/3500 100 FALSE
Service TRUE 07/05/2020 31/12/3500 10 FALSE
Care TRUE 07/05/2020 31/12/3500 90 TRUE
Engagement TRUE 07/05/2020 31/12/3500 50 TRUE
Reward TRUE 07/05/2020 31/12/3500 70 TRUE
Cross Sell TRUE 07/05/2020 31/12/3500 60 TRUE
Upsell TRUE 07/05/2020 31/12/3500 70 TRUE
Renew TRUE 07/05/2020 31/12/3500 80 TRUE
Retain TRUE 07/05/2020 31/12/3500 100 FALSEBusiness Purpose Enabled Start Date End Date Score ApplyContactRules
Enhance Cross Sell TRUE 07/05/2020 31/12/3500
Enhance Upsell TRUE 07/05/2020 31/12/3500
Enhance Renew TRUE 07/05/2020 31/12/3500


Enhance Renew TRUE 07/05/2020 31/12/3500
Join Acquisition TRUE 07/05/2020 31/12/3500
Discover Engagement TRUE 07/05/2020 31/12/3500
Discover Reward TRUE 07/05/2020 31/12/3500
Discover Cross Sell TRUE 07/05/2020 31/12/3500
Discover Upsell TRUE 07/05/2020 31/12/3500
Discover Renew TRUE 07/05/2020 31/12/3500
Neutral Service TRUE 07/05/2020 31/12/3500
Neutral Care TRUE 07/05/2020 31/12/3500
Neutral Engagement TRUE 07/05/2020 31/12/3500
Neutral Reward TRUE 07/05/2020 31/12/3500Intent Business Purpose Enabled Start Date End Date


755

2d.4. Strategy - GetBusniessPurposeToIntent
a. Import BusinessPurpose
b. Check for Active BusinessPurpose - based on Enable = true as well as Start/EndDate
c. Import BusniessPurposeToIntent
d. Check for Active BusniessPurposeToIntent - based on Enable = true as well as Start/EndDate
e. Join both
2d.5. Strategy - DefineIntentByInteraction

2d.6. Strategy - DefineIntentByJourneysNeutral Cross Sell TRUE 07/05/2020 31/12/3500
Neutral Upsell TRUE 07/05/2020 31/12/3500
Neutral Renew TRUE 07/05/2020 31/12/3500
Help Care TRUE 07/05/2020 31/12/3500
Help Engagement TRUE 07/05/2020 31/12/3500
Help Reward TRUE 07/05/2020 31/12/3500
Help Retain TRUE 07/05/2020 31/12/3500
Leave Care TRUE 07/05/2020 31/12/3500
Leave Engagement TRUE 07/05/2020 31/12/3500
Leave Reward TRUE 07/05/2020 31/12/3500
Leave Retain TRUE 07/05/2020 31/12/3500
Renew Engagement TRUE 07/05/2020 31/12/3500
Renew Reward TRUE 07/05/2020 31/12/3500
Renew Renew TRUE 07/05/2020 31/12/3500
Disaffected Care TRUE 07/05/2020 31/12/3500


Disaffected Care TRUE 07/05/2020 31/12/3500
Disaffected Engagement TRUE 07/05/2020 31/12/3500
Disaffected Reward TRUE 07/05/2020 31/12/3500
Disaffected Retain TRUE 07/05/2020 31/12/3500


756

2d.7. Strategy - DefineIntentByModels

2d.8. Strategy - DefineIntentByRules
2d.9. Strategy - DefineIntentByContract
Create new PF - DefineIntentByContract

2d.99. Strategy - IdentifyCustomerIntent

a. Import Intent
b. Check for Active Intent - based on Enable = true as well as Start/EndDate
c. call sub-strategy GetBusniessPurposeToIntent
d. Join both
e. call sub-strategies
f. Group By Business Purpose and Pick Top score

3. Batch NBA (Sravani)
3a. Data Flow - IdentifyBestOBTreatmentsByBatch
Uses data set SubscriptionDataForBatchNBA as input and calls strategy IdentifyBestOBTreatmentsByBatch and writes to Cassandra data
set BestOBTreatmentsByBatch
 Failure - Restart: If Fails, truncate data set BestOBTreatmentsByBatch and restart data flow


757
3b. Strategy - IdentifyBestOBTreatmentsByBatch
Tag Output as “Batch”
Strategy similar to IdentifyBestTreatmentsByTriggers without components those are not relevant.
3b.1. Proposition Decision Data - CrossSell under Issue Offer
3b.2. Strategy - IdentifyOffersForEligibleBusinessPurposeToIntents
a. Import CustomerIntentList
b. Import Offers but put a filter for OfferExecutionMode contains “Batch”
c. Filter offers for Eligible BusinessPurpose from CustomerIntentList

3b.3. Strategy - IdentifyEligibleUpsellOffers
a. External Input
b. Proposition Filter - CrossSellOfferEligibility

3b.4. Strategy - IdentifyEligibleBatchOffers
a. Call Sub-strategy - IdentifyOffersForEligibleBusinessPurposeToIntents
b. Filter for CrossSell Business Purpose
c. Call sub-strategy - IdentifyEligibleCrossSellOffers

3b.5. Strategy - IdentifyEligibleOffers (existing)
a. Call Sub-strategy - IdentifyEligibleBatchOffers
b. Add new switch component between SelectEligibleOffers and Results
c. Select SelectEligibleOffers for real-time context (.EventType is populated or NTID is populated in Primary.Context )
d. Select IdentifyEligibleBatchOffers, otherwise
3b.6.  Strategy- IdentifyEligibleOBTreatments (New)
        a .Call following SubStrategies:
               1. AllTreatmentsForEligibleOffers:
               2.ApplyChannelEligibility:
                      a.Update proposition data i:e ChannelBusinessPurpose with email channel.
                      b.Update proposition filter and set the condition to true.
               3.ApplyChannelContention:


b.Update proposition filter and set the condition to true.
               3.ApplyChannelContention:
                       a.Update Decision data i:e Channel Contention as per the offer catalogue.
                4.ApplyTreatmentEligibility:
                       a. Add New path for email treatments.
                       b. Proposition filter -  EmailTreatmentEligibility (New)
                       c. Import Email treatments in the PF and set the criteria as per the offer catalogue.
     3b.7   Strategy- IdentifyBestOBTreatmentsByBatch(New)


758
             a. Call Sub- Strategy -  IdentifyEligibleOBTreatments
     --TBC
3d. C* Data Set - BestOBTreatmentsByBatch
B. In Extractor Case
1. Prepare Batch Data For Post Process (in Extractor) (Praveen)
1a. Data Flow - PrepareForOBProcessForBatch
Uses BestOBTreatmentsByBatch as input and writes to BestOBTreatmentsBeforeRevalidation & SubscriptionsForOBRevalidation
 Failure - Restart: If Fails, truncate data set BestOBTreatmentsBeforeRevalidation &  SubscriptionsForOBRevalidation and restart this data
flow as well as PrepareForOBProcess1/2 (as appropriate)

2. Changes in Revalidation (Homayra)
2a. Strategy RevalidateOBTreatments (existing)
Do not do revalidation for records coming out from Batch (with tag as “Batch”)

3. Changes in Channel Delivery DF (Sravani)
3a. Data Flow - ProcessOutbound (existing)
Introduce 2 new filters followed by destinations -
Filter Email → C* Data Set - BestEmailTreatmentsAfterControlGroups
Filter SMS → C* Data Set - BestSMSTreatmentsAfterControlGroups

4. Identify customers who have been selected for Email/SMS by Batch  (Praveen)
4a. Table -  subscription_campaign_flags (Jira to DB Team)
subscription_id (primary key)
sms_eligible (char 1)
email_eligible (char 1)
4b. Class - VFUK-FW-AOMFW-Data-SubscriptionCampaignFlags (Jira to App team) (Sravani)
subscription_id - text (key)
sms_eligible - text
email_eligible - text


subscription_id - text (key)
sms_eligible - text
email_eligible - text
4c. Data Set - SubscriptionCampaignFlags
4d. Data Flow - SetSubscriptionCampaignFlags
Uses SubscriptionsForOB data set as input, joins with BestEmailTreatmentsAfterControlGroups & BestSMSTreatmentsAfterControlGroups
and inserts into SubscriptionCampaignFlags with email_eligible = Y/sms_eligible = Y as appropriate
 Failure - Restart: If Fails, truncate data set SetSubscriptionCampaignFlags and restart data flow


759

5. Update to CustomerData Data flow (Sravani)
Use BestEmailTreatmentsAfterControlGroups data set using Compose shape and populate TreatmentList pagelist
Use BestSMSTreatmentsAfterControlGroups data set using Compose shape and populate TreatmentList pagelist

6. Pega Marketing campaign for Email (Sravani)
6a. Segment - EmailSegment
Identifies all customers with email_eligible = Y
6b. Strategy - PrepareEmailTreatments
Imports TreatmentList and Email Treatments proposition data
Match to Email Treatment propositions
Identifies parent & relevant child treatments
calls sub-strategy CreateEmailBundles to prepare the bundle
6c. Campaign - Email Campaign
6d. Execute Email Campaign (Jira to App Team)
App team needs the Campaign Work Item ID for triggering

7. Pega Marketing Campaign for SMS (Sravani)
7a. Segment - SMSSegment
Identifies all customers with sms_eligible = Y
7b. Strategy - PrepareSMSTreatments
Imports TreatmentList and SMS Treatments proposition data
Match to SMS Treatment propositions
7c. Campaign - SMS Campaign
7d. Execute SMS Campaign (Jira to App Team)


761
Release 1.8


762
HBB - 2 Design Approach
 0. Rule IDs and Rule Implementation

1. PM Tool Catalogue

Introducing New Channel - Web
Create new entries as per the Offer catalogue shared

2. New Data Flow - IdentifyBestWebTreatments (Ravi)-done
Similar to GetRecommendationList DF
Need to use standard PrepareRealTimeData DF - Add EventStatus data set

3. New Strategy - IdentifyEligibleRenewOffers  (Ravi)-done
Will be similar to IdentifyEligibleUpsellOffers

4. New Proposition Filter - RenewOfferEligibility (Ravi)-done

5. Update IdentifyEligibleOffers to include the IdentifyEligibleRenewOffers(Ravi)-done
Use “Channel” attribute on context to switch renew offers.

6. Update OfferVariationsEligibility PF for variants (Subrata)-done
New variants for HBB2 needs to be returned. Variant eligibility is churn score range.

7. Update IdentifyOfferVariantsForEligibleOffers to call new strategy IdentifyOfferVariantsForHBB only for HBB offers
HBB2 has  no impact to this logic.
8. New strategy - IdentifyOfferVariantsForHBB (Subrata)
Will be managed in different place.
9. Update AllTreatmentsForEligibleOffers-(done)
Add filter for Web
Update Outbound to SMS/OutboundCC only - to be used for the MVP

10. Update IdentifyEligibleTreatmentsByTriggers to use AllTreatmentsForEligibleOffers - for Outbound Filter only-(done)

11. New strategy - IdentifyEligibleWebTreatments (Ravi) (done)


763
This should only call strategy - ApplyTreatmentEligibility

12. Update ApplyTreatmentEligibility (Ravi)(done)
Add Filter for Web channel
Create new PF WebTreatmentEligibility

13. New Strategy - IdentifyBestWebTreatments (Ravi)
This strategy does the prioritization
This will call a new sub-strategy for HBB prioritization -  IdentifyBestHBBWebTreatment

14. New strategy - IdentifyBestHBBWebTreatment (Zeynep)-done
This strategy will make call to CalculateRankForHBB sub strategy and calculate the offer treatment rank  e based on the prioritization tab in
requirement.
Churn Model :
To calculate the churn model score a new strategy is created -CalculateChurnScoreRange
Model ID =7
experimental_probability > Propensity (No null / zero) (example : 0.5)
Validity : same as T2S
15. Strategy - IdentifyBestWebTreatmentsForSubscription (Ravi)-done
Will be similar to IdentifyBestTreatmentsByTriggers

This will call
IdentifyBestWebTreatments → IdentifyTreatmentVariations → PopulateOutputPropertiesForWeb

16. new strategy - PopulateOutputPropertiesForWeb
Set all the attributes needed for output for Items (eligible offers) & Discount.
new strategy CalcualteDiscountAmount-> the logic to populate discount attributes should be here

17. new startegy-SetIHforWeb Ravi (done)


764
File Extractor Design Approach
1. OBCC Treatment Proposition-PM tool Consume
a. Remove TargetSubChannel  attribute
2. TreatmentToSubChannels -New DDS -PM tool ConsumepyLabel --> Description (Text)
pyName  --> Generated Unique ID - for each Treatment/SubChannel(Text)
pyGroup --> hard coded to "TreatmentToSubChannels" (Text)
pyIssue --> hard coded to "NonPropositions" (Text)
TreatmentName --> Treatment Name (Text)
Channel --> Channel Name (Text)
TargetSubChannel --> Sub Channel Name (Text)
Populate data for All treatment into new DDS. Other than OBCC channel, TargetSubChannell will be N/A.
2. VolumeConstraints DDS Update
pyLabel --> Description (Text)
pyName  --> Generated Unique ID - for each Treatment/SubChannel(Text)
pyGroup --> hard coded to "TreatmentToSubChannels" (Text)
pyIssue --> hard coded to "NonPropositions" (Text)
TreatmentName --> Treatment Name (Text)
Channel --> Channel Name (Text)
TargetSubChannel --> Sub Channel Name (Text) (If no subchannel value N/A)
VolumeLimit --> Integer
Import exiting data & edit & export.
3. PopulateVolumeConstraintsPriority Strategy
Remove  VolumeConstraints join
Remove the logic to set  VolumeLimit
4.TreatmentsForOB DataSet
Add Key TargetSubChannel
5. PopulateMasterDataSets DF
 TreatmentsForOB Path
Remove covert shape add an DF  PopulateVolumeConstraints (new)
In DF
 Input is SR abstract data, call a strategy PopulateVolumeConstraints (new)
join with VolumeConstraints on “TreatmentName”
Populate TargetSubChannel from VolumeConstraints
Set Volume limit  normalized with Control groupFile Extractor AOM-1306 Ability to define Volume Limit at Treatment


and Sub Channel Level
File Extractor AOM-1475 Provide the ability to maintain Control Group
orchestration when OBC Split RequiredFile Extractor AOM-1297 Ability to define for a Treatment Multiple Sub
Channels where relevant


765
VolumeLimit=@if(.VolumeLimit=0||.VolumeLimit="",-1,@if(.ControlGroupPercentage>0,.VolumeLimit*
(1+@Math.divide(.ControlGroupPercentage,100)),.VolumeLimit))
 Add Convert shape map TargetSubChannel,pyName,VolumeLimit
OffersBySubChannelForOB Path
Remove covert shape add an DF PopulateSubchannelBasedOffers (new)
In DF
Input SR abstract data, call a Strategy PopulateSubchannelBasedOffers (new)
join with TreatmentToSubChannels on “TreatmentName”
Populate TargetSubChannel from TreatmentToSubChannels
Add Convert shape map  TargetSubChannel,OfferID,Zip,Encrypt,ContactListNumber


766
Control Group Design Approach

NBA Batch Impact
1. Update on Offer data -PM tool
a. add ControlGroupPercentage attribute to DDS
Updated following decision data in Ruleset - AOMFW-PM-Catalogue:01-01-01
CrossSell
Renew
Retain
Retention
Service
Upsell
1. IdentifyOfferVariantsForEligibleOffers -Strategy
a. Set OfferControlGroupPercentage  populated from Offerdata make sure available in the output
2. AllTreatmentsForEligibleOffers
a. Set OfferControlGroupPercentage  populated from IdentifyOfferVariantsForEligibleOffers make sure available in the output
3. IdentifyBestOBTreatmentsByBatch
a. add  sub strategy call “PopulateControlGroupPercentage”
b. Override ControlGroupPercentage (treatment level) with OfferControlGroupPercentage
c. Set ControlGroupLevel =”Offer”
 BatchFW 2 - Logic AOM-1253 Control Group needed


767
Extend IH
New attributes & mappings BatchFW 2 - Logic AOM-1262 Extend IH to support the strategy framework
Intent Exists Text 255 Varchar(255)  Intent  Offer.Intent
Journey ID
(leave blank
for 1.7) New Text 255 Varchar(255)  AOMJourneyID Default
to blank
Journey step
(leave blank
for 1.7) New Text 255 Varchar(255)  AOMJourneyStep Default
to blank
Selection
type: NBA,
Default Offer,
Real time New Text 50 Varchar(50)   AOMSelectionType Default to
“NBA”
Offer
Propensity
(arbitration
coefficient) Exists Decimal  Numeric(p,s)7 6 pyPropensity Offer.pyProp
ensity as
calculated in
logic
Offer Value
(arbitration
coefficient) New Decimal  Numeric(p,s)10 2 OfferValue Offer.OfferVa
lue
Intent Weight
(arbitration
coefficient) New Decimal  Numeric(p,s)10 2 IntentScore Intent.Ranki
ngScore
Intent
Relevance
(arbitration
coefficient) New Decimal  Numeric(p,s)7 6 IntentRelevance IntentReleva
nce (Calculat
ed in logic)
Business
Purpose
ScoreNew Decimal  Numeric(p,s)10 2 BusinessPurposeScoreBusinessPur
pose.Busine
ssPurposeS
core
Offer Weight
(arbitration
coefficient) New Decimal  Numeric(p,s)10 2 OfferWeight  Offer.OfferW
eigh
 DBType  Max LenghtData type Precisi
onScale SR/IHAttributeName  Value to


DBType  Max LenghtData type Precisi
onScale SR/IHAttributeName  Value to
populate in
logic


768

1. Update Crossel Offer data  -PM tool consume
Add new attributes
StartingPropensity
OfferValue
OfferWeight
2. IdentifyOffersForEligibleBusinessPurposeToIntents
remove the reference to OfferArbitrationParameters
Delete OfferArbitrationParameters DDS
3. SetCommonIHPropertiesForBatch
 set SR attributes used in IH
4. ApplyTreatmentDataToTreatments
Coopy IH SR attrbiutes from eligible treatment list treatments.InAOMContro
lGroup (this is
placeholder
for control
group in
Intent
Identification)New Text 255 Char(1)   InAOMControlGroup Default to N
Control Group
LevelNew Text 50 Char(50)   ControlGroupLevel Offer/Treatm
ent etc


769
OBCC output for NBA Batch
 BatchFW 2 - Logic
AOM-951Build logic to output to OBC channel


770
Release 1.9


771
CR - AOM-1531
1. New strategy - GlobalInclusionsForBatch (Rule set - AOMFW-Business-Artifacts:01-03-02)
         Enable External Input
      Add the rules as specified in the Jira in a filter component
2. New Data-flow: Prepare Inclusion List (Rule set- AOMFW-Artifacts:01-03-02
    1. Import Subscription List
   2. Call the strategy GlobalInclusionsForBatch and map the strategy results to Page list property of type SR.
   3. Add a filter and check if the Page-list has at-least 1 page in it.
3. Update Prepare Batch Data data flow to Include Prepare Inclusion List data-flow as a source.


772
Epic - Tealium

Ruleset - AOMFW-Artifacts:01-03-02

1. HL E2E  Design

1. Stream Dataset
Create Stream Dataset TealiumEvents
Class :VFUK-FW-AOMFW-Int-TealiumEvent
Partition Key : CustomerID
Authentication : Basic
2. Event Strategy
Class:VFUK-FW-AOMFW-Int-TealiumEvent
Name : AggregateTealiumEventsAOM-1510 Create ESM Strategy to Capture Aggregated Information on Page
Visits
AOM-1612 Create RT Data Flow to handle Tealium Events
AOM-1436 {This functionality is handled at app layer}Provide Ability to
Identify URL’s in scope for Tealium and store for analysisAOM-1511 Provide CIS Data Set in which to store Tealium Aggregated Events
for Page Visits


773
Add Split & Join components , Windows  and aggregates as in below.

Window Configurations :
Each window configured have separate windows for the group of attributes listed in below:
CustomerID
page_section
page_subsection
page_sub_subsection
page_url
Window Type
Sliding. Each one is configured for with related period in days / hours
Aggregations
Window Aggregation : Calculate the Count of the events in corresponding window and popualate  internal attributes.
Number of Times Access in last 24 Hours
Number of Times Accessed  in last 7 Days
Number of Times Accessed in last 30 Days
Number of Times Accessed in last 60 Days
Number of Times Accessed in last 90 Days
Number of Times Accessed in last 120 Days
Example :


774

Join Component Configuration :
Join Condition  : The attributes listed in below should match for two windows
CustomerID
page_section
page_subsection
page_sub_subsection
page_url
Output
Map Count attribute of secondary path to a new attribute to be able to move the value up. (repeat it for each attribute coming form
below path)
Example
Join 2 :

3. Data Flow


775
Class :VFUK-FW-AOMFW-Int-TealiumEvent
Name : ProcessTealiumEvents
Input : TealiumEvents
Event Strategy
AggregateTealiumEvents
Populate Event Counts to related attributes in Properties output mapping section
Destination
 DataSet : AggregatedTealiumEvents (Class: VFUK-FW-AOMFW-Int-TealiumEvent)
Keys :
CustomerID
page_section
page_subsection
page_sub_subsection
page_Url
Captured Data/Aggregations:
Last Access Timestamp
Last Known Purchase Type
Last Known Page Tab
AccessCountForLast24Hours
AccessCountForLast7Days
AccessCountForLast30Days
AccessCountForLast60Days
AccessCountForLast90Days
AccessCountForLast120Days
AccessCountForLast60To31Days
AccessCountForLast90To61Days
AccessCountForLast120To91Days

 4. Work Item
DF should be configured as Realtime DF to be able to listen stream  & run event strategy


777
Epic - NBA Batch FW (excluding Squad Zones)

Proposition DD - Intents (under issue NonPropositions)
Create as:
DD - QualifierTypes
EnabledAOM-1560 Map qualifier to intent
AOM-1561 Intent Scoring
AOM-1562 Configure list of intents
AOM-1570 Map intent to business purpose
AOM-1571 Determine business purpose
AOM-1572 Arbitrate offersAOM-1634 Qualifier type definition


778

Strategy - EvaluateCustomerIntents (Artifacts)
Import Intents
Active check
Sub strategy for each qualifier type
e.g. EvaluateCustomerIntentsByProductState
Aggregate Confidence Score from sub-strategies for each Intent and add them to get IntentConfidenceScore

Strategy - EvaluateCustomerIntentsByProductState (Artifacts)
External Input
Check against DD - QualifierTypes, use only if enabled and use the Score
PF - EvaluateCustomerIntentsByProductState (Default = false) (Business-Artifacts)

DD - IntentConfidenceScoreThreshold

DD - IntentsToOffer (Single Offer) - Intent unique (optional mapping)
This will be used if Confidence score is high
but if Confidence score is high for Intent and no records in here, use IntentToBusinessPurpose

DD - IntentToBusinessPurpose (multiple BP) - Intent,BP combination is unique (mandatory mapping)
This will be used if Confidence score is low or high but no record in IntentsToOffer

Strategy - IdentifyOffersForEligibleIntents (Artifacts)
use the logic above to identify offers and pass to results


779
Epic - DM Channel

1. New Proposition Decision Data - DirectMail (Ruleset - AOMFW-PM-Catalogue:01-01-01)
Create new Group under Issue - Treatments
Structure - same as OutboundCC

2. PM Catalogue
Introduce new Channel - DirectMail
PM Should push DirectMail treatments to new decision data - DirectMail

3. Update strategy - AllTreatmentsForEligibleOffers  (Ruleset - AOMFW-Artifacts:01-03-02)
3a. Replace “Outbound Treatments” filter with 5 individual filters for each outbound channels namely -
Email Treatments
SMS Treatments
OutboundCC Treatments
DirectMail  Treatments
AppPush Treatments
3b. Remove OutboundTreatmentsByTriggers  filter and Create 3 Set properties as follows and connect to results -
OutboundTreatmentsByBatch
OutboundTreatmentsByTrigger
OutboundTreatmentsByEvents
3c. Connect new filters created by outbound channels to new set property components as follows -
Email, SMS, OutboundCC, AppPush, DirectMail → OutboundTreatmentsByBatch
SMS, OutboundCC, AppPush → OutboundTreatmentsByTrigger
SMS, OutboundCC → OutboundTreatmentsByEvents

4. New strategy - IdentifyEligibleTreatmentsByEvents (Ruleset - AOMFW-Artifacts:01-03-02)
Save strategy IdentifyEligibleTreatmentsByTriggers as the new strategy
Update component reference for the sub-strategy AllTreatmentsForEligibleOffers to OutboundTreatmentsByEvents


5. Update strategy - ProcessEvent (Ruleset - AOMFW-Artifacts:01-03-02)
Replace sub-strategy call to IdentifyEligibleTreatmentsByTriggers with sub-strategy IdentifyEligibleTreatmentsByEventsAOM-1641 Create new Channel Direct Mail to be utilised by treatments


780

6. Update strategy - IdentifyEligibleTreatmentsByTriggers (Ruleset - AOMFW-Artifacts:01-03-02)
Update component reference for the sub-strategy AllTreatmentsForEligibleOffers to OutboundTreatmentsByTrigger

7. Update strategy - IdentifyEligibleOBTreatments (Ruleset - AOMFW-Artifacts:01-03-02)
Update component reference for the sub-strategy AllTreatmentsForEligibleOffers to OutboundTreatmentsByBatch

8. Update proposition decision data - ChannelBusinessPurpose
Add new entries for channel - DirectMail

9. Update proposition filter - ChannelBusinessPurposeEligibility (Ruleset - AOMFW-Business-Artifacts:01-03-02)
Map channel eligibility rules for channel - DirectMail

10. new proposition filter - DirectMailTreatmentEligibility (Ruleset - AOMFW-Business-Artifacts:01-03-02)
Create PF on Issue - Treatments, Group - DirectMail
Map eligibility. rule for the DM Treatment

11. Update strategy - ApplyTreatmentEligibility (Ruleset - AOMFW-Artifacts:01-03-02)
Add new filter for DirectMail channel
Add new eligibility filter using PF DirectMailTreatmentEligibility

12. Update strategy - IdentifyBestTreatmentForBatch (Ruleset - AOMFW-Artifacts:01-03-02)
Add new filter for DirectMail channel
Add new Prioritize component for DirectMail channel ; return Top 1

13. Update strategy - PopulateOutputPropertiesForBatch (Ruleset - AOMFW-Business-Artifacts:01-03-02)


13a. Add filter components after Set Property - Set Common Output Properties for each channel -
Email
SMS
OutboundCC
DirectMail
AppPush
13b. Add Set Property components for each channel connecting from respective Channel filter -
SetContactDetailsForEmail
SetContactDetailsForSMS
SetContactDetailsForOutboundCC


781
SetContactDetailsForDirectMail
SetContactDetailsForAppPush
connect all back to filter component - Valid ContactDetail

14. Update strategy - DedupeByContactDetail ??? (Ruleset - AOMFW-Artifacts:01-03-02)

15. Update Data flow - ApplyControlGroups (Ruleset - AOMFW-Artifacts:01-03-02)
Update filter - All IH For OBCC & AppPush to include DirectMail

16. New Data set - BestDirectMailTreatmentsAfterControlGroups (Ruleset - AOMFW-Artifacts:01-03-02)

17. Update Data flow - ProcessOutbound (Ruleset - AOMFW-Artifacts:01-03-02)
Create new filter for DirectMail and use new destination data set - BestDirectMailTreatmentsAfterControlGroups

18. New strategy - PopulateOutputPropertiesForDirectMail (Ruleset - AOMFW-Business-Artifacts:01-03-02)
Populate output as per Jira

19. Update strategy - PopulateOutputProperties (Ruleset - AOMFW-Business-Artifacts:01-03-02)
Create new filter for DirectMail and call new sub-strategy PopulateOutputPropertiesForDirectMail


782
Release 1.10


783
Assisted Upgrade - Drop 1
Requirements GSheet
https://docs.google.com/spreadsheets/d/1fLJv7Rq-CTiYe9yNtQfclU2pM57tYjYlq7iKnO9jgkc/edit#gid=1781913676 -

A. Proposition Hierarchy in NBA FW
Offer - UpgradeMobile
OfferVariant - SIMToSIM
Channel - InboundCC
Treatment - UpgradeMobile_InboundCC
TreatmentVariant - TreatmentVariantDefault

B. Eligibility Rules
Offer Eligibility - As per R1.10.37 (User Story - TBC)
OfferVariant Eligibility - SIMToSIM /SIMO30toSIMO30/SIMOtoSIMO30/SIMO30toSIMO (details available in offer catalog)
Channel Eligibility - None
Treatment Eligibility - None
TreatmentVariant - None

C. Strategy FW for InboundCC
Connect your Googl
e account


784

D. Strategy  - Calculate Discounts for Assisted Upgrade
This sub-strategy will calculate the discount & discounted price for Assisted Upgrade offers. For Release 1.10, this strategy will be called
only for InboundCC channel, however, in later releases the same strategy could referenced for all other channels those are used in assisted
upgrade or requires the discount & discounted price for Assisted Upgrade offers.

Separate sub-strategies identifies the current tariff for customer as well as Recommended Tariff(s) which are used as an input to   3
separate sub-strategies based on the agent profile (Omni, Save, Super-Save) and return the  discount & discounted price.
Calculate Customer Star Rating Information can be another strategy to populate from models scores and passed to discount logic as it is
used in discount calcualtion.Model Id =10 & STAR_SCORE model attribute will be used to populate value.(AOM-1788 has the details of
model, also no value case behaviour is covered)