Friday Dec 18, 2009

Learning and predicting for short and long term events

In many RTD deployments we see that the business wants to optimize decisions based on the long term effect of the decision. For example, selecting a retention offer to display to a customer in the web site should not be driven by the likelihood that the customer will click on the offer, but by the likelihood the customer will have been retained, say after 3 month.

Another simpler example is the decision by a bank to offer a credit card to a customer. The events in this situation may be:

  1. Offer Extended
  2. Clicked
  3. Applied for card
  4. Used card
The goal of the bank is to have the customer use the card. The problem is that the feedback for whether the card is used will come weeks after the initial offering. This not only requires the capability of closing the loop at a later time (the subject of a future entry in this blog), but it also leaves us a long time without the capability of having reliable models.

RTD provides built-in functionality to handle these cases gracefully, utilizing the maximum of available information. This is why the positive events for an RTD model can be more than one and their order matters. The idea behind this feature is that the events are naturally ordered. The use of the card comes after the application and after the click. Therefore, a model for the "Click" event can be used as a proxy for the deeper events for as long as we do not have a good model for them.

Using a closer event as a proxy for the farther one is a good strategy, but it requires management of events, levels of conversion, etc. and it gets even more complicated when you think that the different offers can be at different levels of conversion. RTD does all this management automatically.

Before we describe how RTD makes this all work, there is one more consideration. When comparing offers it is not fair to compare the likelihood of click for one offer with the likelihood of Card Use for another offer.

The way that RTD works is as follows. When computing the likelihood for a choice:

  1. Compute the likelihood for the deepest event for which we have a converged model
  2. If the event is the desired one (usually the deepest) stop here and use this likelihood
  3. Compute the average likelihood across all choices for all the events that are deeper than the one we used in step 1
  4. Using the average likelihoods compute the proportion between the different events and apply that proportion to the likelihood we got in step 1.
For example, if the only likelihood that can be computed for a specific choice is Click, and it is 10%, and the averages across all other choices are:

  • Click : 20%
  • Apply : 12%
  • Use: 8%
Then for our choice we take the 10% and multiply it by 8/20 to get the likelihood of use, which gives 4% if I am not mistaken. The likelihood of Apply for the same choice (and customer) would be 6%.

As mentioned before, if you define the events in the proper order as the positive events for the model RTD will take care of the logistics for you, following the algorithm described above.

Happy Holidays.


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