Database Realtime Decision
A database realtime decision allows you to personalize web content based on a known website visitor’s attribute values, as retrieved from the data warehouse or an auxiliary database.
To use a database decision, RPI must be provided with a lookup key value, which can be used to uniquely identify the visitor. This can happen when e.g.:
The visitor submits a web form containing e.g. an email address, and the field within which the value is provided is mapped to a cached attribute list. The submitted value can then be used as a lookup to the list of attributes, values for which can be retrieved and persisted in the realtime cache. Note that, when a web form is used to determine a lookup key, an entry in the site’s web.config’s ParameterToDataMappings setting is not required.
The visitor logs into a Facebook app using an RPI Facebook Login button, and the site’s web.config includes a ParameterToDataMappings setting that maps the name of piece of data provided by Facebook at successful login to a cached attribute list. Attribute values can then be retrieved and persisted in the realtime cache.
The same mechanism can be used to map a URL parameter, present in the query string used to navigate to a web page, to a cached attribute list lookup key.
ParameterToDataMappings are defined in the RPI Realtime website’s appsettings.json file, as per the following example:
"ParameterToDataMappings": [
{"ParameterName": "Email", "CALName": "CAL01"},
{"ParameterName": "Employee", "CALName": "CachedTable01"},
{"ParameterName": "CustomerKey", "CALName": "Cassandra"},
{"ParameterName": "Cassandra2", "CALName": "Cassandra2"}]
Full details of cached attribute lists can be found in the Configuration Workbench documentation.
Note that RPI looks for changes to cached attributes every 10 minutes and updates the realtime cache if any attribute values are found to have changed in the intervening period.
A database decision exposes additional properties when compared to other realtime decision types:
[Using]: this dropdown property allows you to specify the basis upon which decision criteria will be added to the realtime decision. It exposes the following values:
Cached attribute list: the default value. Selection of this value displays the cached attributes list property below the dropdown.
Realtime cache offer: selecting this value displays the Offer property below the dropdown.
Cached attributes list: if displayed, you can select a cached attributes list that will be used when adding decision criteria to the database decision using a dropdown, in which all cached attributes lists are listed alphabetically. You can choose an attribute- or NoSQL definition-based cached attribute list.
Offer: this property is mandatory when displayed. It allows you to select a realtime cache offer, and then use the attributes from that offer when building the realtime decision's decision criteria.
You can populate the property by browsing for a realtime cache offer, or by using drag and drop. The offer selected must support the realtime cache delivery method. Having selected an offer, you can open its latest version in the Offer Designer. You can also clear the property.
Note that selection of a cached attribute list or realtime cache offer is simply a mechanism to be used when adding decision criteria to a database decision – both are, after all, just vehicles for the population of data within the realtime cache. If required, you can include decision criteria based on cached attribute list and realtime cache offers in the same database decision.
If a database decision is currently configured to use a cached attribute list when adding decision criteria, the decision criteria types available are contingent on the selected cached attribute list.
If a NoSQL cached attribute list is selected, if a DisplayName was provided for a criterion, it is shown instead of its Name. The criterion editor utilized is the same as the criterion editor used at the JSON realtime decision.
If the decision is configured to use a realtime cache offer, you can choose an attribute from the same when adding a new decision criterion.
Having established a visitor’s identity, you can use a database decision to vary smart asset content in accordance with attribute values.
If more than one record with a different attribute value exists for the same lookup key, more than one value is persisted in the realtime cache.
If a given visitor qualifies to be served more than one piece of content, the content element order within the smart asset determines which content will be displayed.
After a number of days defined by a cached attribute's Lifetime value, on a visitor’s re-visiting the site and presenting a lookup key, the attribute value is refreshed from the data warehouse or auxiliary database.
When using a cached attribute list that has been created as a table in the cache in the context of a database realtime decision, lookups are performed against a visitor's profile entry with a name matching that of the cached attribute list's Lookup key attribute. You can use cached attributes from such a list as the basis for decision criteria. If data is not present in the cache when the lookup is performed, it is retrieved from the database. If the cached attribute with the lowest Lifetime (Days) value has expired at the point of a lookup being made, a full refresh of the cached attribute list virtual table is performed. If data is not present in the virtual table (due to the MaxRowsPerCachedTable setting having been reached), the decision criterion using the same will not be satisfied. Similarly, if the Lookup key is not present in the visitor profile, decision criteria based on cached attributes from the virtual table will not be able to be satisfied. Note that if RPI is unable to locate a cached attribute in a virtual table, the visitor profile will be checked for its presence; if located in this way, the value thus retrieved will be used.
When using a database decision criterion based on a database column attribute with a List or Map data type, the comparison of the value supplied at the decision criterion is performed against all individual values contained within the attribute’s value.