Thursday Mar 27, 2014

Real-Time Responses with Big Data

For an organization to respond in real-time it needs to have systems that must detect, analyze, and act with greater automation making more big data practical and operational. New research from James Taylor discusses how to find value in fast-moving data, high-ROI use cases, and the five essential elements of technology required. 

[Read More]

Thursday Mar 20, 2014

Holland America Enhances Online Guest Experience

Cruise Industry Magazine has issued an article on how Holland America uses Oracle Real-Time Decisions (RTD) software as a "Competitive Weapon" to drive revenue in the right direction by presenting passengers with relevant shore excursions.
[Read More]

Friday Jan 24, 2014

Big Data for Little Decisions, Day to Day Operations

At the BIWA Summit 2014 (Business Intelligence, Warehousing, and Analytics), James Taylor, CEO and Principal Consultant of Decision Management Solutions, provided a provocative keynote on how to make Big Data practical, actionable, and operational. 

As companies invest in Big Data infrastructure they are looking for ways to show a return on that data. Using business analytics to put this data to work improving decision-making is central to success.  But which decisions should be the focus and how will you show improvement? 

James discussed the importance of improving day-to-day operational decisions because of the largest scale and impact in front-line customer interactions across multiple channels on the web, in email, on mobile, in social, in call centers, in stores, in field sales or service.  Strategic and tactical decisions are made less frequently and interactively and are riskier than front-line operational decisions where Big Data's velocity, volume, and variety is most relevant. 

Key to powering more proactive decisions with Big Data is reducing decision latency from the time of an event to action with a better blend of human and machine decision making.  Low decision latency requires automating front-line systems to be active participants, where as making people only more analytical does not have as much impact on day-to-day operations.  

Begin with the outcome in mind then leverage Big Data in Decision Management Systems to test, learn, and adapt in production for quicker returns and better responses.  Think in probabilities for new customer demand in marketing and sales, for reducing uncertainty, risk, and fraud in operations, and for improving the experience in service and support.  The opportunity to democratize Big Data is in Little Decisions.  



Tuesday Nov 20, 2012

Video testimonial from Dell on their use of RTD

Dell Director Mark Sucrese, describes how Oracle’s Real-Time Decisions dynamically personalizes products and services through

predictive and optimization analytics across many customer facing vehicles to improve revenue and the customer experience.

http://medianetwork.oracle.com/video/player/1957033167001

Friday Jun 29, 2012

Combined Likelihood Models

In a series of posts on this blog we have already described a flexible approach to recording events, a technique to create analytical models for reporting, a method that uses the same principles to generate extremely powerful facet based predictions and a waterfall strategy that can be used to blend multiple (possibly facet based) models for increased accuracy.

This latest, and also last, addition to this sequence of increasing modeling complexity will illustrate an advanced approach to amalgamate models, taking us to a whole new level of predictive modeling and analytical insights; combination models predicting likelihoods using multiple child models.

The method described here is far from trivial. We therefore would not recommend you apply these techniques in an initial implementation of Oracle Real-Time Decisions. In most cases, basic RTD models or the approaches described before will provide more than enough predictive accuracy and analytical insight. The following is intended as an example of how more advanced models could be constructed if implementation results warrant the increased implementation and design effort. Keep implemented statistics simple!

Combining Likelihoods

Because facet based predictions are based on metadata attributes of the choices selected, it is possible to generate such predictions for more than one attribute of a choice. We can predict the likelihood of acceptance for a particular product based on the product category (e.g. ‘toys’), as well as based on the color of the product (e.g. ‘pink’).

Of course, these two predictions may be completely different (the customer may well prefer toys, but dislike pink products) and we will have to somehow combine these two separate predictions to determine an overall likelihood of acceptance for the choice.

Offer Metadata

Perhaps the simplest way to combine multiple predicted likelihoods into one is to calculate the average (or perhaps maximum or minimum) likelihood. However, this would completely forgo the fact that some facets may have a far more pronounced effect on the overall likelihood than others (e.g. customers may consider the product category more important than its color).

We could opt for calculating some sort of weighted average, but this would require us to specify up front the relative importance of the different facets involved. This approach would also be unresponsive to changing consumer behavior in these preferences (e.g. product price bracket may become more important to consumers as a result of economic shifts).

Preferably, we would want Oracle Real-Time Decisions to learn, act upon and tell us about, the correlations between the different facet models and the overall likelihood of acceptance. This additional level of predictive modeling, where a single supermodel (no pun intended) combines the output of several (facet based) models into a single prediction, is what we call a combined likelihood model.

Facet Based Scores

As an example, we have implemented three different facet based models (as described earlier) in a simple RTD inline service. These models will allow us to generate predictions for likelihood of acceptance for each product based on three different metadata fields: Category, Price Bracket and Product Color. We will use an Analytical Scores entity to store these different scores so we can easily pass them between different functions.

Analytical Scores

A simple function, creatively named Compute Analytical Scores, will compute for each choice the different facet scores and return an Analytical Scores entity that is stored on the choice itself. For each score, a choice attribute referring to this entity is also added to be returned to the client to facilitate testing.

Offer Scores

One Offer To Predict Them All

In order to combine the different facet based predictions into one single likelihood for each product, we will need a supermodel which can predict the likelihood of acceptance, based on the outcomes of the facet models. This model will not need to consider any of the attributes of the session, because they are already represented in the outcomes of the underlying facet models.

For the same reason, the supermodel will not need to learn separately for each product, because the specific combination of facets for this product are also already represented in the output of the underlying models. In other words, instead of learning how session attributes influence acceptance of a particular product, we will learn how the outcomes of facet based models for a particular product influence acceptance at a higher level.

We will therefore be using a single All Offers choice to represent all offers in our combined likelihood predictions. This choice has no attribute values configured, no scores and not a single eligibility rule; nor is it ever intended to be returned to a client. The All Offers choice is to be used exclusively by the Combined Likelihood Acceptance model to predict the likelihood of acceptance for all choices; based solely on the output of the facet based models defined earlier.

All Offers and Combined Likelihood Model

The Switcheroo

In Oracle Real-Time Decisions, models can only learn based on attributes stored on the session. Therefore, just before generating a combined prediction for a given choice, we will temporarily copy the facet based scores—stored on the choice earlier as an Analytical Scores entity—to the session. The code for the Predict Combined Likelihood Event function is outlined below.

// set session attribute to contain facet based scores.
// (this is the only input for the combined model)
session().setAnalyticalScores(choice.getAnalyticalScores);

// predict likelihood of acceptance for All Offers choice.
CombinedLikelihoodChoice c = CombinedLikelihood.getChoice("AllOffers");
Double la = CombinedLikelihoodAcceptance.getChoiceEventLikelihoods(c, "Accepted");

// clear session attribute of facet based scores.
session().setAnalyticalScores(null);

// return likelihood.
return la;

This sleight of hand will allow the Combined Likelihood Acceptance model to predict the likelihood of acceptance for the All Offers choice using these choice specific scores. After the prediction is made, we will clear the Analytical Scores session attribute to ensure it does not pollute any of the other (facet) models.

To guarantee our combined likelihood model will learn based on the facet based scores—and is not distracted by the other session attributes—we will configure the model to exclude any other inputs, save for the instance of the Analytical Scores session attribute, on the model attributes tab.

All Offers and Combined Likelihood Model Attributes

Recording Events

In order for the combined likelihood model to learn correctly, we must ensure that the Analytical Scores session attribute is set correctly at the moment RTD records any events related to a particular choice. We apply essentially the same switching technique as before in a Record Combined Likelihood Event function.

// set session attribute to contain facet based scores 
// (this is the only input for the combined model).
session().setAnalyticalScores(choice.getAnalyticalScores);

// record input event against All Offers choice.
CombinedLikelihood.getChoice("AllOffers").recordEvent(event);

// force learn at this moment using the Internal Dock entry point.
Application.getPredictor().learn(InternalLearn.modelArray, 
				 session(), 
				 session(), 
				 Application.currentTimeMillis());

// clear session attribute of facet based scores.
session().setAnalyticalScores(null);

In this example, Internal Learn is a special informant configured as the learn location for the combined likelihood model. The informant itself has no particular configuration and does nothing in itself; it is used only to force the model to learn at the exact instant we have set the Analytical Scores session attribute to the correct values.

Reporting Results

After running a few thousand (artificially skewed) simulated sessions on our ILS, the Decision Center reporting shows some interesting results. In this case, these results reflect perfectly the bias we ourselves had introduced in our tests. In practice, we would obviously use a wider range of customer attributes and expect to see some more unexpected outcomes.

The facetted model for categories has clearly picked up on the that fact our simulated youngsters have little interest in purchasing the one red-hot vehicle our ILS had on offer.

Drivers For Cars

Also, it would seem that customer age is an excellent predictor for the acceptance of pink products.

Drivers For Pink

Looking at the key drivers for the All Offers choice we can see the relative importance of the different facets to the prediction of overall likelihood.

Combined Drivers For Acceptance

The comparative importance of the category facet for overall prediction might, in part, be explained by the clear preference of younger customers for toys over other product types; as evident from the report on the predictiveness of customer age for offer category acceptance.

Predictiveness Of Customer Age For Categories

Conclusion

Oracle Real-Time Decisions' flexible decisioning framework allows for the construction of exceptionally elaborate prediction models that facilitate powerful targeting, but nonetheless provide insightful reporting. Although few customers will have a direct need for such a sophisticated solution architecture, it is encouraging to see that this lies within the realm of the possible with RTD; and this with limited configuration and customization required.

There are obviously numerous other ways in which the predictive and reporting capabilities of Oracle Real-Time Decisions can be expanded upon to tailor to individual customers needs. We will not be able to elaborate on them all on this blog; and finding the right approach for any given problem is often more difficult than implementing the solution. Nevertheless, we hope that these last few posts have given you enough of an understanding of the power of the RTD framework and its models; so that you can take some of these ideas and improve upon your own strategy.

As always, if you have any questions about the above—or any Oracle Real-Time Decisions design challenges you might face—please do not hesitate to contact us; via the comments below, social media or directly at Oracle. We are completely multi-channel and would be more than glad to help. :-)


Update (20th September, 2012): Please note that the above is intended only as an example. The implementation details shown here have been simplified so as to keep the application comprehensive enough for a single blog post. Most notably, an unhighlighted shortcut has been taken with regards to the way feedback events are recorded.

When implementing combined likelihood models in production systems, care must be taken to assure that the analytical scores used when recording feedback for a choice are exactly identical to the scores used when this particular choice was recommended. In real world applications, this will require that all scores for recommended choices are stored separately on the session for later retrieval, rather than recalculating the scores when feedback occurs (which is what the example above will do when feedback is provided through a separate integration point).

The method described here is far from trivial. We therefore would not recommend you apply these techniques in an initial implementation of Oracle Real-Time Decisions and that you enlist the help of experienced RTD resources to ensure the resulting implementation is correct.

Wednesday May 30, 2012

A conversation with world experts in Customer Experience Management in Rome, Italy - Wed, June 20, 2012

It is my pleasure to share the registration link below for your chance to meet active members of the Oracle Real-Time Decisions Customer Advisory Board.

Join us to hear how leading brands across the world have achieved tremendous return on investment through their Oracle Real-Time Decisions deployments and do not miss this unique opportunity to ask them specific questions directly during our customer roundtable.

Please share this information with anyone interested in real-time decision management and cross-channel predictive process optimization: http://www.oracle.com/goto/RealTimeDecisions

Monday Apr 16, 2012

Waterfall Predictions

Facet Based Predictions are a powerful method to increase predictive accuracy and facilitate rapid learning and knowledge transfer, but the simple approach described in an earlier post comes at a price. By using a single facet rather than individual choices for prediction, we decrease the granularity of our predictions. Choices that share the same facet value will be treated as equals by our predictive model; and even when important distinctions could be made after sufficient feedback is collected our simple facet based model will never learn to exploit these differences.

In most cases, the advantages of facet based models will outweigh the drawback of a reduction in granularity. This is especially true in implementations where shelf-life is short and no individual choice is ever expected to gather enough responses to build a predictive model. However, sometimes we will want to combine the power of facet based prediction with the accuracy of models defined at the lowest level of granularity; for instance when some choices are expected to collect sufficient feedback while others are not.

The complete and open decision management framework architecture of Oracle Real-Time Decisions allows us to blend predictive models in several ways. In this post, we will describe how we can mix-and-match two models at different levels detail using an approach we call waterfall prediction.

Waterfall Prediction

In essence, the waterfall method described here will try to predict a likelihood at the lowest possible level of granularity. If the choice based model at this grade has not received enough feedback to be considered mature, we will resort to a facet based model.

This implementation will build on the example described in our previous post about facet based prediction.

Product Model Setup

In addition to the facet based category events model configured earlier we will need a choice based event model Product Events. This model will predict likelihoods of events (Accepted and Ordered) based on feedback for individual choices.

Product Model

Recording Events

Previously, we would record feedback events only for our facet based model. As we now have two models at different levels of granularity, we will alter our code slightly to ensure we record any event against both models.

// create a new choice to represent the product
ProductsChoice p = Products.getChoice(request.getChoice());
// create a new choice to represent the category attribute
CategoriesChoice c = new CategoriesChoice(Categories.getPrototype());

// set properties of the category choice
c.setSDOId("Categories$" + p.getCategory());

// record choice in models (catching an exception just in case)
try { p.recordEvent(request.getEvent()); } catch (Exception e) { logError(e); }
try { c.recordEvent(request.getEvent()); } catch (Exception e) { logError(e); }

Note that we are recording the same event twice, but against two separate choices p and c representing the two different levels of granularity. The Oracle Real-Time Decisions framework will automatically ensure the relevant models are updated accordingly.

Predicting Likelihoods

In this implementation, a new function will be used to predict likelihoods for our products. Rather than just returning the likelihood at the category level like before, this function will first check whether the more granular model has received enough feedback (in this case 100 events) to be considered mature. If the product model is deemed sufficiently trained, the function will use this model instead of the more general facet base one.

// get instance of the model used for predicting Product Events
ProductEvents productmodel = ProductEvents.getInstance();
// get instance of the model used for predicting Category Events
CategoryEvents categorymodel = CategoryEvents.getInstance();

// check if model for Product Events is sufficiently trained
if (productmodel.getChoiceEventModelCount(ModelCount.POSITIVE_COUNT, 
	product.getSDOId(), event) >= 100)
{
    // return the likelihood based on the Product Event model
    return productmodel.getChoiceEventLikelihood("Products$"+product.getSDOId(), event);        
}
// else if the model is not sufficiently trained
else {  
    // return the likelihood based on the Category Event model
    return categorymodel.getChoiceEventLikelihood("Categories$"+product.getCategory(), event);
}

Waterfall Function 

Proper decision design and continuous in-live testing are crucial here. Precisely how much feedback should be considered “enough feedback” can wildly differ between implementations and use-cases. Moreover, some implementation might also permit the use of the quality of the models as reported by RTD, rather than the number of positive events, to determine the cascade threshold. Decision Center is an indispensable tool in this process.

Choice Group Scores Setup

Similar to before, on the scores tab for the Products choice group we configure the Likelihood performance goal to be populated by the new WaterfallLikelihood function instead of the PredictLikelihood function.

Waterfall Score

These simple changes to our previous example empower our new implementation to benefit from two models at varying levels of granularity; leveraging both the accuracy of choice based models and the advantages of facet based prediction.

The Power of Waterfall Prediction

Waterfall prediction is a compelling example of how Oracle Real-Time Decisions enables us to blend multiple real-time models for use in rapid decisioning. This advanced approach to modeling can easily be expanded to cover more than just two levels and more than one hierarchy to further improve the predictive prowess of an RTD implementation.

Cascading models allows businesses to express various forms of decision logic that are far more subtle than simple one-step prediction models. In implementations where convergence time is incompatible with business requirements – or there is a low tolerance for random behavior in the initial stages of deployment – this flexibility in designing models and decisions is crucial.

In a future post, we will discuss another approach to amalgamate models, taking us to a whole new level of predictive modeling and analytical insights; combination models predicting likelihoods using multiple child models.

Thursday Mar 08, 2012

The Era of the Decision Graph

Gone are the days when “electronic billboards” for targeted merchandizing programs were leading edge.

Over the course of the last few years we observed a dramatic qualitative shift in how companies have applied Analytical Decision Management techniques to drive Customer Experience Optimization programs. It used to be the case that marketers were happy when they were allocated a dedicated piece of real-estate on their company’s web site (or contact center or any interaction channel for that matter) that they could use at their discretion for the purpose of one-off targeting programs. What companies now want is granular control over the whole user experience so that the various elements composing this cross-channel dialog can be targeted and relevant. Such a shift requires a new approach to analytics, based on understanding how the various elements of the user interaction relate one to the other.

Let me introduce the concept of Decision Graph in support of this idea.

To move from electronic billboard / product spotlight optimization to customer experience optimization, analytics must shift away from focusing on “the right offer for the right customer”. The focus of the Decision Graph is to identify “the right user experience for the right customer”. This change of focus has a critical impact on your analytics requirements as one dimensional targeting approach for matching customers with offers won’t address the need to optimize multiple dimensions at once.

This is where the Decision Graph comes in. Let’s consider the following graph eliciting the relationships between the various facets of the user experience to be optimized in the context of a Marketing Optimization use case.

Now imagine that for every offer presentation on any interaction channels, your analytical engine can record and identify the characteristics of the customer interactions that are associated with success (say click or offer acceptance) across all those dimensions.

Let’s take an example.

  • You see a nice picture of bear cubs on a forest background with a punchy banner stating “please give us back your share of the 20,000 tons of annual account statements” call to action to sign-up for electronic bill payment on the “recommended for you” section of the login page of your financial service web site and … you decide to click on the “one click wildlife donation” link.
  • Our Decision Graph, can then record the fact your customer profile is positively associated with “positive responses” to marketing messages in the following context: Channel (Web), Offer / Product (Electronic Bill Payment), Creative (The Bear Cub image), Tags (Environmental, Wildlife, Donation, Provocative), Slot Type (Image), Slot (Recommended for you), Placement (Login Page). As predictive models are attached to the Decision Graph, this means that such a business event updates 10 predictive models that marketers can now use for reporting and decision management purposes.

You can now generalize the idea and imagine that this graph collects information about all marketing events across all channels and you end-up with an analytical system that let all the actors of customer experience optimization discover the relationship between the different facets of user interactions

With the Decision Graph

  • Marketing stakeholders will learn about customer segments that are receptive to eco-centric marketing messages and which customers in the right context will step out of their standard routine (why they came to web site in the first place) to subscribe to specific causes.
  • Web user experiences stakeholders will learn about which type of marketing messages are appropriate and for whom at the start / at the end or throughout a logged-in web session
  • Content owners can focus their digital agencies on the most effective creative themes as they will be able to correlate response rates based on associated tags
  • And the company as a whole will have learned who is receptive to eco-centric marketing messages when displayed in a given context of a secured dialog from which it will be in a position to dynamically tailor user experiences across channels based on such empirical evidence

Now contrast this with a system that would only record the fact you’ve subscribed to the Electronic Bill Payment option as part of the “Go Green” Campaign and you will get a sense for the power of the Decision Graph. The bottom line is that companies need analytical systems that operate at multiple levels of the Decision Graph if they want to delight their customers with relevant customer experiences.

My next post will be on how the Oracle RTD Decision Manager product enables you to create and configure such graphs and to automatically identify the predictive drivers of response across the whole spectrum of the user experience.

Friday Mar 02, 2012

Announcing RTD 3.0.0.1.11

It is our pleasure to let you know that Oracle just released a new version of the RTD platform addressing some important scalability requirements for high end deployments.

The driver for this new version, released as a patch on top of the RTD 3.0.0.1 platform was the need to address increasing volumes of “learnings” generated by ever-increasing volumes of “decisions”. This stems from the fact several of our high-end customers now have production environments with multiple cross-channel Inline Services supporting multiple “decisions” which make use of multiple predictive models using hundreds of data attributes to select from potentially thousands of “choices”. Addressing those high-end business requirements required increased RTD Learning Server capacity than was provided by RTD 3.0.0.1.

To address those needs, Oracle re-architected its RTD Learning Server engine to enable some level of parallelization. This new architecture relies on multi-threaded models updating and asynchronous learning records reading/deletions operations. This change provides a 150% improvement in learning record processing rates, which enables RTD to now process more than 58M incremental learning records per day with a deployment configuration consisting of 3 concurrently active inline services each with 900 choices, 200 data attributes, and 4 choice event predictive/learning models. This was achieved on a machine with 4 core / 6GB RAM allocated to the RTD learning server.

This new version of RTD is an important release for companies setting-up Big Data Analysis & Decision platforms in support of real-time and batch targeted customer experience enterprise deployments.

For complete details on this patch please refer to http://www.oracle.com/technetwork/middleware/real-time-decisions/psu11-1532856.html

Friday Feb 17, 2012

Facet Based Predictions

The analytical models method detailed in a previous post are not only extremely valuable for reporting, but can also be used to predict likelihoods for things other than regular choices. We can for instance generate predictions based on statistics for an attribute of a choice, rather than the choice itself. We use the term facet based prediction to describe this advanced form of generating predictions.

This novel approach to modeling can be applied to significantly improve predictive accuracy and model quality. It can also facilitate the rapid transfer of existing learnings to newly created choices based on their facet values. These capabilities can be of use to practically all implementations, but they are of utmost importance in cases where the number of choices is very high or individual choices have short shelf life. In these instances, there might simply not be enough time or data to be able to predict likelihoods for individual choices. We could predict likelihoods for certain facets of our choices; as long as their cardinality remains relatively low.

Consider the following example in which we recommend products based on the acceptance of other products in the same category. In our ILS, Oracle Real-Time Decisions will be used to recommend a single product based on a single performance goal: Likelihood.

Choice Groups Setup

Products that may be recommended are stored in a choice group Products (we will use static choices, but this approach could be implemented for dynamic choices also). Product choices have an attribute Category which will contain a category name. We will use a second and separate dynamic choice group Categories to record acceptance of the different product categories.

Choice Group Setup

Note that we never intend to return any choices from the Categories choice group to a client. It is configured using a dummy source and will not contain any actual choices. This group is only used within the ILS for predicting likelihoods. Statistics for this group may however be viewed in decision center reports.

Recording Events

Similar to the example for analytical models, we will record events against a dynamically generated choice representing a facet value rather than against the actual choice. In this example, both the actual choice and the event to record will be passed through a request represented as Strings.

// create a new choice to represent the category facet
CategoriesChoice c = new CategoriesChoice(Categories.getPrototype());
// set properties of the choice
c.setSDOId("Category" + "$" + Products.getChoice(request.getChoice()).getCategory());
// record event in model (catching an exception just in case)
try { c.recordEvent(request.getEvent()); } catch (Exception e) { logError(e); }

Model Setup

Our model setup is practically identical to before, but this time we'll enable "Use for prediction".

Predicting Likelihoods

A function PredictLikelihood will be used to predict likelihoods for our products. The function takes a Products choice and an Event (String) as parameters and returns a Double value representing the predicted likelihood.
// get instance of the model used for predicting Category Events
CategoryEvents m = CategoryEvents.getInstance();
// return the likelihood based on the generated SDOId and the "Accepted" event
return m.getChoiceEventLikelihood("Categories$"+product.getCategory(), event );

 

Choice Group Scores Setup

On the scores tab for the Products choice group we configure the Likelihood performance goal to be populated by the PredictLikelihood function using parameters this and "Accepted". The keyword this refers to the particular choice being scored and will ensure each choice is scored according to its category facet.

That is all that is required to score choices against a facet. We can now create decisions and advisors that use these predictions to recommend products based on their categories.

In this example, we have predicted likelihoods based on a single product facet. As a result, products in the same category will be scored the same. In practical implementations this will rarely be an issue, because there will presumably be multiple performance goals. Also, likelihoods may be mixed with product specific attributes like price or cost; resulting in score differentiation between products regardless of equality in likelihoods.

In a later post, we will discuss how we can expand on this to include multiple product facets in our likelihood prediction.

Tuesday Jan 31, 2012

Introducing Nicolas Bonnet

Nicolas is the Director of Product Management for RTD. He has recently joined us as an author for the RTD blog.

As we pick up the pace on sharing information and ideas on this blog, readers please feel free to participate through comments and ideas for blog entries.

Tuesday Jan 24, 2012

RTD, Big Data and Map Reduce algorithms

I was recently asked to compare and contrast the way that RTD processes its learning with Map Reduce, Big Data systems like Hadoop. The question is very relevant, and in reality you could implement RTD Learning using Map Reduce for many or most cases without significant difference in functionality. Nevertheless, there are a few interesting differences.

RTD learning is incremental. As data to be learned is generated by the decision nodes, the learning server learns on this data incrementally updating its models. A Map Reduce implementation would accumulate all the data and periodically use several nodes to learn in parallel (Map) on portions of the data and accumulating that knowledge into a single view of the truth (Reduce). This implementation would be non-incremental, with the full data processed each batch to produce a brand new model.

If enough nodes are used together with fast storage, and when the volume of data is not extremely high, then it is possible that the latency in the production of model can be managed and new models be produced in a matter of minutes. The computing requirements to maintain these models fresh would be much higher than the current requirements for a typical RTD implementation. For example, a single 2 core node dedicated to learning can cope with a volume of more than 20 million records per day. If the time window used is a quarter, then the total number of records for a model is about 3 billion, considering that each model learns for 2 time windows. As fast as Map Reduce may be, processing three billion records with a few hundred attributes each, for two model overlapping time windows) would probably take quite a long time.

 Is there an alternative? Is it possible to use the Map Reduce principles to process data incrementally similarly to what RTD does?

I believe it is. The batch oriented Map Reduce principles can be modified and extended to work on streams of data, instead of stored shards of data. For example, there could be several Map nodes that continuously accumulate the learning from a number of records each in parallel and pass the accumulated learning to a consolidating Reduce node that incrementally maintains the models. The number of records the Map nodes accumulate to summarize will affect the latency of the data to affect the models, providing interesting configuration options to optimize for throughput or latency. Ultimately the tradeoff could be done dynamically with the Map nodes processing larger windows when they see more load.

An additional consideration is the cost of consolidation of the Map produced summaries, as it needs to be relatively smaller than the resources needed to do the accumulation in the first place, as we do not want the Reduce phase to be a dominant bottleneck. Additionally, it would be possible to have layers of accumulation where several summaries are consolidated.

The fact that RTD models are naturally additive facilitates the distribution of work among the Map nodes.

In spite of this long discussion of theoretical uses for Map Reduce in the RTD context, it is important to note that with parallel learning and suitable configurations RTD learning, as it stands today, can cope with very high volumes of data.

Monday Jan 23, 2012

Analytical Models

As explained in a previous post, we can record events against unsourced dynamic choices created on-the-fly using the getPrototype method. Choices instantiated in this fashion, and the events recorded against them, will be visible in decision center reports.

This enables us to create extensive reporting based on arbitrary input from different sources without the need to specify all the possible choice values upfront. Creating so-called analytical models can be very useful for analysis.

Recording Client Input

Consider the following example which shows how this approach can be used to create an analytical model based on informant input. In our ILS, Oracle Real-Time Decisions will be used to find and report on correlations between a regular session attribute and arbitrary codes passed through an informant.

Choice Group Setup

A choice group Reason is used to store codes passed through the informant. During initialization, the choice group will attempt to grab choices from the ReasonEntityArray, but the array is a dummy entity that will always return nothing, because we've not defined a value for it.

Reason choice group configuration, dynamic choices tab.

Reason choice group configuration, group attributes tab.

Informant Setup

When invoked, a RecordReason informant will record an event for the ReasonCode input parameter. The logic for this informant is pretty straightforward.

// create a new choice based on the request attribute (a string that describes the reason)
ReasonChoice c = new ReasonChoice(Reason.getPrototype());
// set properties of the choice (SDOId should be of the form "{ChoiceGroupId}${ChoiceLabel}")
c.setSDOId("Reason" + "$" + request.getReasonCode());
// record choice in model (catching an exception just in case)
try { c.recordChoice(); } catch (Exception e) { logTrace("Exception: " + e); }

Model Setup

In order to actually find and report on correlations, we will need to define at least one event model on our choice group. For this example, we'll keep things as simple as possible.

Reasons choice event model configuration.

Reports

The reports in decision center will show the reason codes sent to the informant as if they were dynamic choices and calculate statistics and correlations against session attributes.

(In this example, an Oracle Real-Time Decisions Load Balancer script was used to send four different codes to the ILS with a severe bias towards certain age groups.)

Decision center report for Reason choice, analysis tab.

This approach enables us to generate detailed reporting and analysis of more than just regular choices in the familiar decision center environment. In this example we were using informant input, but this technique can also be applied using the attributes of other choices to gain additional insight into the correlations between session attributes and choice attributes like product group or category (rather than individual choices).

This method can also be used in conjunction with predictive models. We will explore this possibility and its applications in future posts.

Friday Jan 06, 2012

Recording Events

There is always more than one way to skin a cat; it's just that some ways to excoriate a feline are more efficient than others. This is certainly true for the way in which we can record events against choices in RTD, and the differences in performance can be striking.

getChoice

A common approach to record events against static choices is to use the getChoice API.

Choice ch = MyChoiceGroup.getChoice("MyChoiceId");
ch.recordEvent("Clicked");

On the first line, we are asking RTD to go through the list of all choices in MyChoiceGroup and retrieve one particular choice keyed MyChoiceId. On the second, we record a Clicked event against the returned choice. 

Because we are asking RTD to go through the list of all choices, we require that RTD has a full list of choices available; even if we only end up using a single choice. If we use the same code for dynamic choices, RTD will thus have to fetch and instantiate the full list of dynamic choices in order to find the single one we are interested in. This may be an expensive operation, as it may require accessing an external database or web service; execution of complex custom code; and/or instantiating a large number of dynamic choices.

(Note that dynamic choices do not cache at the choice level. They cache at the entity level. These entities hold the data for the dynamic choices but not the choices themselves. The RTD API could perhaps be optimized differently, but the current implementation will instantiate all the dynamic choices and then find the one the API call is looking for. Consider also that the actual source data used for the dynamic choices could come from anywhere and need not come from cached entities at all; it might even be generated on the fly through custom functions. This flexibility in sourcing dynamic choices makes retrieving a single choice non-trivial from the RTD API perspective.)

This approach will certainly work, but may waste precious time and resources retrieving and instantiating dynamic choices that are never used.

getPrototype

For recording an event, it is sufficient that we have a choice that has the desired SDOId; all other choice attributes are irrelevant for this purpose. A more efficient way to record events against dynamic choices is therefore to create a new empty dynamic choice; assign it an SDOId; and record the event against that, rather than retrieving the 'actual' dynamic choice. The result in terms of statistics and learning are the same, but in this approach there is no need for RTD to retrieve any choices at all.

We can instantiate an empty dynamic choice using the getPrototype API.

Choice ch = new MyDynamicGroupChoice(MyDynamicGroup.getPrototype());
ch.setSDOId("MyDynamicGroup" + "$" + "MyChoiceId");
ch.recordEvent("Clicked");

This approach can provide significant performance improvements in implementations with a large number of dynamic choices; or in implementations where retrieving dynamic choices is a non-trivial complex operation and entity caching proves insufficient.

Being able to record events on choices that are not retrievable through the dynamic list is an additional advantage that has several interesting applications which we will explore in future posts.

(Special thanks to Michel Adar for bringing this to my attention and providing an initial draft of this article.)

Introducing Lukas Vermeer

I have the pleasure to introduce a new contributor to this blog, Lukas Vermeer. He has been an RTD practicioner for a long time and I'm very happy he will be contributing from his field experience to this blog.

Michel

About

Issues related to Oracle Real-Time Decisions (RTD). Entries include implementation tips, technology descriptions and items of general interest to the RTD community.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today