Deployment Parameters

The parameters set when configuring the deployment are pushed to the ecosystem.Ai runtime and, together with the environment variables, set the behaviour of the runtime.

Case Configuration

Case configuration contains the high level details of the deployment:

• Prediction Case Id: The name of the prediction case. This is the name for the predictor that will be stored in the logs and, together with the version and project name, uniquely identifies a deployment configuration. When creating a deployment for a Dynamic Interaction configuration this should match the name of the Dynamic Interaction configuration.
• Description, Type, Purpose: These fields are used to describe the deployment and the description is pushed to a commented section in the properties file to assist with maintenance.
• Version: The version of the configuration. Together with the project name and deployment_id (Prediction Case Id) this uniquely identifies a deployment configuration.
• Environment Status: The environment to which the deployment confioguration should be pushed. Different endpoints and database settings can be configured for different environments.
• Performance Expectation, Complexity: These are informational fields used to assist with maintenance.

The types of functionality to be used by the endpoint can be set using the available check boxes which will make the relevant parameters available for configuration.

Build and Generate Settings

The build and generate settings are used to configure the optional Generate and Build functionality. The Generate functionality is used to create a git branch with the plugin code created for the deployment. The Build functionality is used to build a jar file and image for the deployment.

Path Settings

The path settings configure the location of the data and models to be used by the runtime.

Database and Logging Database Settings

The database settings are used to configure the MongoDB instance to be used by the runtime. The logging database settings are used to configure the database and collections in which the logs for the runtime should be stored.

Target Scoring Engine

The endpoints to push the deployment to for the different environments. The endpoint that will be used is defined by the Environment Status setting in the Case configuration section.

Prediction Model

Specify the models to be used for the Deployment. The models are specified as a comma separated list of model namesin the Models to Load input field. The models should be available to the runtime at the path specified in the Models Path setting.

Model Selector

Configure the deployment to different models from the Prediction Model list, based on a lookup from a database.

• Data Source: The type of data source to be used for the lookup.
• Database: The database to be used for the lookup.
• Table: The table to be used for the lookup.
• Selector Column: The name of the field to use to determine which model to select.
• *Lookup: A JSON object specifying how the lookup should be performed. The input should have the following form {"key":"customer_identifier","value":123,"fields":"selector_key"}. key is the name of the field in the customer feature store to be used for the lookup, the value is both the default value to be used if the lookup fails and specifies the type of the lookup field and fields is a comma separated list of fields to be returned from the lookup.
• Selector Setting: A JSON object specifying which model to use based on the value of the field specified in Selector Column. The input should have the following form {"key_value_a":[1],"key_value_b":[2]}. The key is the value of the field specified in the Selector Column and the value is the index of the model in the Models to Load list.

Parameter From Data Source

The configuration for the customer data lookup to be used by the runtime.

• Data Source: The type of data source to be used for the lookup.
• Database: The database to be used for the lookup.
• Table: The table to be used for the lookup.
• Key Field: The name of the customer lookup field in the customer feature store.
• Key Type and Default: You can specify a default customer key to use if the lookup fails. This field is also used to specify the type of the the customer lookup field. If the value entered is a string it denotes that the customer lookup field is a string. If the value entered is a number it denotes that the customer lookup field is a number. If you do not want to specify a default value you can use 123 or ‘123’ to sepcify the type.
• Lookup Field List: The fields to be looked up from the customer feature store.
• Lookup Defaults: Default values to be used for the fields if they are missing from the customer feature store when the lookup is performed.
• Create Virtual Variables: Checkbox to indicate whether Virtual Variables should be created based on the lookup from the customer feature store. The User Guide for Virtual Variables contains more information on how to use Virtual Variables.

Virtual Variable Settings

Once the create virtual variables checkbox is selected and the Add Variable button is clicked, the following fields will be available for configuration:

• Variable Name: The name of the virtual variable to be created.
• Variable Type: The type of the virtual variable to be created. The options are:
  • Discretize: Bucket the values of the base variables
  • Concatenate: Combine multiple variables by combining their values The remaining fields are dependent on the type of virtual variable selected.

Discretize

• Field To Discretize: The field in the customer feature store to be discretized.
• Default Value: The default value to be used if the field value does not fall into any of the defined buckets.
• Label: The value to assign to the new variable if the feature store variable values falls within the defined bucket
• From: The lower bound of the bucket
• To: The upper bound of the bucket To remove a bucket use the delete icon next to the bucket.

Concatenate

If the Concatenate type is selected, the Add Field button will be available to add additional fields to the concatenation. In the Field input dropdown you can select the fields to be concatenated. To remove a field use the delete icon next to the field.

Offer Matrix

The Offer Matrix contains information about the items to be recommended by the Deployment. The Offer Matrix can be used in the post scoring logic when applying eligibility rules.

• Data Source: The type of data source to be used for the lookup.
• Database: The database to be used for the lookup.
• Table: The table to be used for the lookup.
• Offer Lookup ID The name of the field in the Offer Matrix that uniquely identifies the offer.

The Offer Matrix stored in the params JSONObject accessible in the post scoring logic. The runtime will attempt to load the Offer Matrix in three different forms:

• offerMatrix: Loaded as a JSONArray with one element for each row in the Offer Matrix. The rows themselves will be loaded as JSONObjects with the column names as the keys. This structure can be used to efficiently loop through the Offer Matrix.
• offerMatrixWithKey: Loaded as a JSONObject with the key being the value of the Offer Lookup ID field in the Offer Matrix configuration. The value will the corresponding row of the Offer Matrix represented as a JSONObject with the column names as the keys. This structure can be used to efficiently lookup a specific offer in the Offer Matrix.
• offerMatrixStatic: Loaded as a JSONArray with one element for each row in the Offer Matrix. The rows themselves will be loaded as JSONObjects with the column names as the keys. Will only load rows in the Offer Matrix which have a column named static_offers and the value in that column is greater than 0. offerMatrixStatic is returned by the getOfferMatrix function in the post scoring logic when a a default value is used when performing the look up configured in Parameters From Data Source. This can allow you to specify offers for new customers where the customer lookup fails. If any of these three loads fails the corresponding item in params will be empty.

Plugins

The pre and post scoring logic and API structure java classes to use in the Deployment.

API endpoint

The API endpoint is used to configure the API structure to be used in the Deployment. To use the default API structure leave this section blank. See the API configuration for more information on how to configure the API structure.

Pre Scoring logic

The pre scoring logic is used to configure the pre scoring plugin to be used in the Deployment. The pre scoring plugin is used to perform any pre processing of the input data before it is passed to the model for scoring. For Dynamic Interaction configurations select PreScoreDynamic.java for a pre scoring template. For static model configurations PrePredictCustomer.java is the default template and is the pre scoring logic that will be used by default. If you wish to customise your pre scoring logic see the pre scoring logic documentation as well as the guide for setting up a local development environment.

If using custom pre scoring logic, use the compile button to make the pre scoring class available to the runtime. You can also set up a build pipeline to compile the custom pre scoring logic.

Post Scoring logic

The post scoring logic is used to configure the post scoring plugin to be used in the Deployment. The post scoring plugin is used to perform any post processing of the output data after it has been scored by the model. There are a number of template classes available:

• PostScoreBasic: General-purpose post-score handling. Use when there’s no need for specialized post-scoring logic, just general output handling.
• PlatformDynamicEngagement: Post scoring logic for Dynamic Interaction configurations. Iterates through the options store and use the Offer Matrix if one is configured.
• PostScoreNetwork: Post score for a network runtime. This post score should not need to be customised.
• PostScoreRecommender: Generic recommender scoring. When a model generates recommendations, but no specific offer matrix is required.
• PostScoreRecommenderOffers: Generic recommender scoring with an Offer Matrix. When a model generates recommendations and the post scoring logic should loop through the Offer Matrix.
• PostScoreRecommenderMulti: Recommender scoring using a multi model approach and asynchronous scoring.
• PostScoreSpendingPersonality: The post score for spend personality scoring.
• PostScoreMoneyPersonality: The post score for money personality scoring.
• PostScoreSentimentalEquilibrium: The post score for sentimental equilibrium scoring. If you wish to customise your post scoring logic see the post scoring logic documentation as well as the guide for setting up a local development environment.

If using custom post scoring logic, use the compile button to make the post scoring class available to the runtime. You can also set up a build pipeline to compile the custom post scoring logic.

Whitelist

Specify a list of customers who are eligible for specific offers. The whitelist is specified as a table containing two columns; the first is the customer identifier and the second is a list of offers for which that customer is eligible. If a customer does not appear in the table the default offer eligibility rules specified in the post scoring logic will be applied.

New Knowledge

In the New Knowledge accordion you can specify three parameters:

• Epsilon: The portion of offers to be allocated to explore in params in the post scoring logic. See the epsilon exploration user guide for more information.
• Cache Duration: This amount of time for which customers will be shown the same offer.
• Pulse Responder Reference: The name and UUID of the Dynamic Interaction configuration to link to the deployment.

Additional Corpora

Add additional data sets to the Deployment, these will be loaded into the runtime. Select Add Corpus and complete the following fields:

• Corpus Name: The name to give the loaded corpus in the runtime.
• Datasource: The type of data source to be used for the lookup.
• Database: The database to be used for the lookup.
• Table: The table to be used for the lookup.
• Type: How the corpora should be loaded into the runtime. Static corpora are loaded at start up or after a refresh. Dynamic corpora are loaded each time a prediction is made. Experiment corpora are used to condifure an experiment_selector type network runtime.
• Key: If a Key field is specified the corpus will be loaded as a JSONObject with the value of the Key field as the key for the JSONObject. If the Key field is not specified the corpus will be loaded as a JSONArray.