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.

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.

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.)

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.

But conditioning can be a powerful tool for self-improvement. I’ve deliberately been playing the Brian Eno song Thursday Afternoon every time I felt myself immersed in ‘the zone‘. In my mind, the track and the mental state have now become intricately linked. This is so much the case that I can now descend into productivity Walhalla simply by listening to my personal work anthem.

In effect, I’ve brainwashed myself to work better in response to a particular tune.

There is nothing special about this trick. Anyone can do it and almost no real effort is required.

A few guidelines.

• Choose a song that is long. Not a two minute ditty. This will also help for the next prerequisite.
• Choose a song that can stand to be repeated. You’ll want to be productive for longer than one play.
• Choose a song without lyrics. This is more personal. To me, words and melody are distracting.
• Choose a song that is timeless. Something you wouldn’t mind listening to in a few years time.
• Choose a song that is not a classic. Classics are played on the radio. That is not what you want.
• Carry your song with you always. You need to be ready. Productivity can strike at any moment.
• Play your song every time you are in the zone. Especially initially you want the bonding to be strong.
• Play your song without interruptions. Interruptions kill productivity. Interruptions break the spell.
• Never play your song when you are not in the zone. That would break the spell. Don’t do it.
• Don’t overuse. There are limits to how productive you can be. This trick does not fix that.
• Don’t expect magic. The song will not always work. If it doesn’t work, stop listening right away.

Have I missed anything important? Feel free to add your tips and tricks in the comments below.

I’m not entirely sure why someone would even search for something like this, but I’m pretty confident this person did not find what he or she was looking for.

Oracle Real-Time Decisions is definitely not a waste of money.

I have a brain busting with thought, an inbox full of interesting ideas and a stack of draft posts containing loads of links and random ramblings on disparate topics. All this pondering without publication is paralyzing.

Analysis without action is a crippling affliction that affects individuals as well as businesses. Wasting time or wasting money; we all need to be mindful of our conversion rates.

Time to stop thinking and start typing.

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. ]

About 60% of the people stopped when we had 24 jams on display and then at the times when we had 6 different flavors of jam out on display only 40% of the people actually stopped, so more people were clearly attracted to the larger varieties of options, but then when it came down to buying, so the second thing we looked at is in what case were people more likely to buy a jar of jam.

What we found was that of the people who stopped when there were 24 different flavors of jam out on display only 3% of them actually bought a jar of jam whereas of the people who stopped when there were 6 different flavors of jam 30% of them actually bought a jar of jam.  So, if you do the math, people were actually 6 times more likely to buy a jar of jam if they had encountered 6 than if they encountered 24, so what we learned from this study was that while people were more attracted to having more options, that’s what sort of got them in the door or got them to think about jam, when it came to choosing time they were actually less likely to make a choice if they had more to choose from than if they had fewer to choose from.

A fascinating psychological effect with clear implications for display advertising, but there is a lesson here for online marketeers and analysts as well.

In this study, fewer people stopped when there was less choice, but more people actually bought something. If we were only measuring the former (i.e. attention), and not the latter (i.e. sales), we would be led to think more choice would be about 50% more effective at bringing in customers. And boy, would we be wrong!

Metrics matter; especially when you are using a system which can automatically optimize your process in order to maximize those metrics.

Don’t get yourself in a jam; remember this next time you decide to measure click acceptance instead of actual sales to drive your online marketing effort. Clickthrough rates are useful as a measure by proxy, but they can be misleading.

While there remains a considerable amount of controversy around the transfer of learnings, I’ve always personally believed that certain mental skills can be transferred from one domain to another. My aspiration to learn to fashion authentic and articulate appraisals was part of the reason I started writing restaurant reviews in the first place.

To me, it certainly feels like significant progress was made. I’ve certainly expanded upon my vocabulary of adjectives.

I’d like to thank all who provided me with feedback and helped me hone my skills. Keep up the good work!

He asked me what I wanted to drink.

I said that a beer would do just fine.

He asked me what kind.

I mumbled something about having no preference.

Obviously that last statement was a half-hearted lie. This being England, the bar had a respectable selection of beers and ales on offer; not all of which I would have enjoyed. Perhaps I did not want to seem picky, or did not want to waste time perusing the bar. Whatever the reason, he seemed unfazed and wandered off towards the bar to order while I attended our luggage and seats.

Q: What beverages would you have purchased if you were in his position?

Presumably, one does not become the boss of the boss of the boss of the boss of the boss of me without a lot of effort, skill and hard work. One does not simply walk into a top-position at a multi-national cooperation without some special abilities and a lot of experience.

Technology and tools change fast, but people will be around for some time. I enjoy keeping up with and learning about new technology in my spare time, but people experience takes serious effort and dedicated investment. It is why I do the work I do the way I do it. A chance encounter like this is a great opportunity to leapfrog ahead.

Pay attention to the details, and you might learn a trick or two.

My high-placed patron returned from the bar with two completely different beers, stated he was fond of both and let me choose between a dark ale and a normal lager; thereby maximizing (doubling) the odds of me getting something I liked in the absence of more information. Furthermore, because I was allowed to choose, the endowment effect almost guaranteed I would be satisfied with what I got; even if it wasn’t really what I wanted. Simple, but effective!

A: Buy two diametrically opposed beverages you personally enjoy equally. Let the other choose.

Think big, start small. They say happiness is in the little things, but so is success.

Being able to label the back button is a big reason why the iPhone’s on-screen buttons are better than Android’s hardware Back button. A dedicated hardware Back button can never answer the question “Where?”

Oh really‽

The Back button on my browser is not labeled in any way, nor are the (to Gruber perhaps confusingly labeled) emergency “exit” signs in most buildings. Some things are just so blindingly obvious they do not warrant a label at all.

I guess I never really considered the “Where?” question to be important. I always figured the Back button on my phone would do pretty much what it says on the tin: take you back. Back to where you came from; wherever that may have been.

Conversely.

When I click my Android hardware Back button after moving from one application to the next (for instance when opening a map, webpage or dialing a number from within an app) Android does exactly what I would expect; it goes back to the previous screen. As long as I keep tapping that button, Android will take me back; even if I have been moving acros a multitude of applications. Right up until I return to the Home screen.*

This makes total sense to me.

When the user presses the BACK key, the current activity is popped from the top of the stack (the activity is destroyed) and the previous activity resumes (the previous state of its UI is restored). Activities in the stack are never rearranged, only pushed and popped from the stack—pushed onto the stack when started by the current activity and popped off when the user leaves it using the BACK key.

For me, this consistent Back functionality across applications is a big reason why Android’s Back button is better than the iPhone’s on-screen buttons. Even if they do have fancier labels.

[* As a side note, I've always felt the Android applications integrate more often and more nicely producing a more natural flow between apps. Perhaps this point is not a salient to those used to the more clunky iOS flow where manual application switching is more common, at least for me. ]