By Michel Adar on Dec 18, 2009
Another simpler example is the decision by a bank to offer a credit card to a customer. The events in this situation may be:
- Offer Extended
- Applied for card
- Used card
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:
- Compute the likelihood for the deepest event for which we have a converged model
- If the event is the desired one (usually the deepest) stop here and use this likelihood
- Compute the average likelihood across all choices for all the events that are deeper than the one we used in step 1
- Using the average likelihoods compute the proportion between the different events and apply that proportion to the likelihood we got in step 1.
- Click : 20%
- Apply : 12%
- Use: 8%
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.