Hi Team,
I just wanted to know the internal architecture of model monitoring and storing snapshots in PR_DATA_DM_ADMMART_MDL_FACT table. Pega Currently stores all the model instance created for Adaptive model in PR_DATA_DM_ADMMART_MDL_FACT table. Currently this table has 34 columns. We wanted to have a new context (say “Location”) for this Adaptive model. Along with this we already had Issue, group, Channel, Direction, and Proposition Name as model identifiers. As per business requirement, we wanted to add Location as one of the model identifier.
Can we add new column name “Location” to store the location value in the table?
As this is OOTB pegadata table, this gets restructured during the Pega upgrades?
Currently, this new model identifier is getting stored under pyName column along with Proposition Name in Json format. {“Location”:“CA-Location”,“pyName”:“BTADefault”}. Can we change the format of storing this value.
Is it advisable not to alter this table structure or value storing in this and Create a view to see the results as desired?
Please suggest me the possible solution for this requirement.
Thanks in advance.
Hi Navakanth,
That table is an internal table. You cannot change the layout of it. If you customize ADM context keys, they end up in a JSON string in pyName, as you have noticed.
If you need to unpack this for reporting you’ll need to do this as you suggested, creating either a view using some “fromJSON” functions in your database or in the BI layer.
Technically, adding location as a context key in a single rule is equivalent to having different model rules. Note that adding context keys will force more splits of models and might lead to insufficient data for the models to be reliable - if location has many distinct values we don’t recommended doing so. From a data science perspective you will need to consider why doing this vs simply adding location as a predictor. What is the reason behind wanting to add location as a context key?
Regards,
Otto
PS see Pegasystems Documentation for a description of all the datamart monitoring tables.
Thanks Otto for responding.
We have suggested to go with a View or to write SQL query using “fromJSON” functions from their end when reporting.
I strongly agree with you Otto, by adding location as a context key it creates different model rules. Our existing models already has location as its predictors from long time.
As part of the experimentation, business wants us to do a POC by creating a new instance with Location as new model identifier. The goal of this analysis is to select a list of Proposition-location combinations where the location level ADMs could potentially exert great positive impact on the outcome rate.
We are doing this POC with few propositions which have high volume of interactions & positive response and active at multiple locations. The goal here is to choose propositions of which the corresponding channel level ADMs perform well at channel level but under-perform at location level. We believe such propositions will benefit the most from the location level ADMs because
•Proposition performance are more likely to vary significantly between locations for these types of propositions;
•Location-specific ADM models could better predict the proposition performance at each location level.
Thanks for the context Navakanth. I’d be interested to hear the outcomes of this experiment, feel free to touch base off-line.
Cheers
Otto
Hi Navakantham,
Is your location context refers to a region/state/postcode-prefix in your POC? We would like to hear the outcome of the POC & the performance of the ADM model(s) with & without location context attribute.
My Suggestion is go with location as region/state specific (very less Variance) for better performance instead of adding GeoCode/city-level. More variance of adm model context parameters will end-up with creating many more adm model instances & it might not predict the behavior you want to achieve?
Thanks,
Nanjundan Chinnasamy
