Easy way to add pyTreatment/enable channel (properties) when importing actions?
Hello,
Looking to do a bulk update for all my actions in CDH to set a 'generic treatment' rule and enable them for a particular channel (web -> isWebEnabled property).
I found that by setting the treatment via app studio for an individual action, the export of said action does not show the pyTreatement field being updated so leads me to be hesitant in attempting a mass update by importing the actions with the pyTreatment field set to the name of the rule as well as setting isWebEnabled property to true.
Can anyone advise if they have done this before? Thanks!
Pegasystems Inc.
US
Which version of the product are you using? It isn't recommended to use the same generic treatment for every action. Assuming you have a different treatment for every Action, you can bulk import web treatments into the treatment library through the Decision Data Rule (DDR) directly. You can access this DDR from the treatment landing page and clicking on the "Manage treatments" link. Depending on the version you are on, you can also import the relationship between Actions and Treatments through the OfferTreatmentsJoin DDR.
Accenture
CA
@SethRobinson Hi Seth, we are on 8.5.1 - we found that there were some auto-generated rules within the NBAStrategyFramework that required us to have IsTransactional as well as the channels set for each action otherwise it would get filtered out by said auto-generated rules. The treatment themselves serve no purpose aside from us having a treatment - this is because for our inbound service (headless), we return a set of data for the UI layer to manipulate.
Is there a way to get around the need to set a treatment for our inbound service if there is no need to use a treatment?
Updated: 12 Apr 2021 15:30 EDT
Pegasystems Inc.
US
The IsTransactional property is a boolean and should default to false if it's not set. The "IsTransactional" property determines whether the Action and Treatment level Predictions get invoked as well as outbound policy limits applied and should never cause an actions to get filtered out unless your Outbound Limit is causing the action to be filtered. I haven't heard of this being an issue before.
Accenture
CA
@SethRobinson as we do not want to invoke any of the auto-generated models (predictive models from the PredictActionPropensity rule), we have set IsTransactional to true to bypass the predictive model together. Based on your description, we are correctly setting this to true.
As for the treatments - I do not know how to disable them altogether (in app studio/NBAD) although I do see the decision data that hosts the record. In the scenario where in a call center/retail/web world where the actions we return do not have variations of actions, we will encounter somewhere within the strategy framework strategy flow the data joins that will filter/exclude our actions because there are no associated treatments (hence why we figured we would create a 'generic treatment').
NBAStrategyFramework -> TreatmentsChannel -> InboundChannels -> AssistedTreatmentStrategy
If these rules are expecting at least one treatment if we do not turn off treatment processing altogether (as the switch in InboundChannels shows), per my understanding, we must have a treatment. Do you have a suggestion on how to handle the situation in the limited context I have provided thus far? Thanks Seth!
Pegasystems Inc.
US
@AndrewN0 Why do you want to not invoke the auto-generated models? You are by-passing the product and best practices by doing so. Setting IsTransactional would be a hack to an underlying need which we don't fully understand and would be good to get further clarity on. What is causing you to consider such an implementation?
For treatments, again, why do you want to disable them? They represent the actual content meta data of what you want to communicate to a customer in a channel centric manner. Treatments should hold meta data that renders an action presentable to a client. It would be a bad practice to try and not have one of these as well, or a single treatment universally for all actions. In some use cases it makes sense for a subset of actions to share treatments, but to have a single treatment for all actions in the system is a very bad anti-pattern. Again, what is causing you to consider such an implementation rather than stick to the best practices that are declared for you in the product?
Accenture
CA
@Saleem_A evaluating and trying to make sense of what is happening within the predictive model components in the PredictTreatmentPropensity or PredictActionPropensity strategy, we are unsure where all arbitration is done and how this potentially impacts the existing static (currently non-adaptive) arbitration (e.g. scorecard prioritized) model the client's actions leverage. Having disabled propensity under the NBAD arbitration tab and looking at the strategy, reviewing components such as RealtimeControls (BusinessControlSettings) and comparing it to what we set in NBAD, I have not been able to find documentation that speaks to the immediate correlation to ensure we have a better idea of what exactly is running and how it is used for the auto-generated models. Is the suggestion to just leave it be and let it execute if there is currently no appetite for leveraging propensity driven NBAs?
@Saleem_A evaluating and trying to make sense of what is happening within the predictive model components in the PredictTreatmentPropensity or PredictActionPropensity strategy, we are unsure where all arbitration is done and how this potentially impacts the existing static (currently non-adaptive) arbitration (e.g. scorecard prioritized) model the client's actions leverage. Having disabled propensity under the NBAD arbitration tab and looking at the strategy, reviewing components such as RealtimeControls (BusinessControlSettings) and comparing it to what we set in NBAD, I have not been able to find documentation that speaks to the immediate correlation to ensure we have a better idea of what exactly is running and how it is used for the auto-generated models. Is the suggestion to just leave it be and let it execute if there is currently no appetite for leveraging propensity driven NBAs?
There is currently only the retail channel and all action metadata required for talking points have been implemented within the action itself for both presentation and speaking points alike. I suppose it cannot be fully appreciated yet as the action has been originally implemented with an extremely narrow view for an inbound channel. We could create an agent-assisted treatment for each of our actions but the data would not differ from what already exists within the action. The text itself may change in the future with the inclusion of more channels (e.g. in an SMS world, we may want less verbiage and hence have a need to override the property values with the text defined in the SMS treatment) but as of now, I am unsure of the immediate benefit. Given the current implementation, the treatment would not provide any more value than having an associated treatment image which I suspect could will change in the future. We can 'extract' the imageURL out of all existing actions and create an equivalent treatment for each action with the imageURL for the agent-assisted channels. I suppose in this context, it will better prepare us for the omni-channel world - not necessarily knowing which attributes would be 'common/shared' across various channels at the immediate moment, would you agree that 'decoupling' the metadata from the actions into the treatment for the existing (lone) channel makes sense?
Pegasystems Inc.
US
@AndrewN0 So the question to ask is why would a customer not use the best-practice adaptive propensities? Why is there no appetite for that? Have they not purchased Pega for that intelligence? If there are good reasons for not using the best-practice approach, then the next place to review is the prediction. A prediction is an abstraction layer that allows you to define how the implementation of the prediction towards an outcome. As such, this is the place to review to replace the best-practice adaptive models implementation with a score card type implementation of the the prediction. If this is done, then the prediction is a centralized and abstracted location that can be changed to support score based modeling and then in the future updated to Adaptive models. I'd actually recommend using both, score based implementation that would be champion/challenged with an adaptive model within the prediction. This abstraction means that the internal implementation of the prediction can change over time, without having to rework the strategy framework.
@AndrewN0 So the question to ask is why would a customer not use the best-practice adaptive propensities? Why is there no appetite for that? Have they not purchased Pega for that intelligence? If there are good reasons for not using the best-practice approach, then the next place to review is the prediction. A prediction is an abstraction layer that allows you to define how the implementation of the prediction towards an outcome. As such, this is the place to review to replace the best-practice adaptive models implementation with a score card type implementation of the the prediction. If this is done, then the prediction is a centralized and abstracted location that can be changed to support score based modeling and then in the future updated to Adaptive models. I'd actually recommend using both, score based implementation that would be champion/challenged with an adaptive model within the prediction. This abstraction means that the internal implementation of the prediction can change over time, without having to rework the strategy framework.
As for treatments, the purpose of a treatment is to create a channel seperation. If you implement all the logic at the action level because the current implementation is specific to one channel, you create a long term problem in that all the details are now baked into the wrong layer. As such, I'd strongly suggest that you review what should be pushed into the treatment layer and managed explicitly at that level, even if it feels strange right now, because you are implementing one channel.