Introduction to Parameterized Session Events

One of the most commonly requested features for MarkedUp has been the ability to support parameterized session events, and as of the release of MarkedUp Analytics SDK for .NET 1.0 this feature is now publicly available to our customers.

Parameterized session events help you group and categorize related user events that occur inside your applications; this gives you the ability to maintain a high-level view of how people are using your application while also allowing you to expose more details if needed.

For example: I have a Hacker News Windows Store application that I’ve been working on in my spare time and I want to be able to track how many articles people actually view when they use it.

So, I embedded a standard MK.SessionEvent call inside my WinJS application to track how many people viewed an article:

And this allows me to see the total number of times someone has viewed an article using my app:

Hacker News application with a simple, unparameterized event

But what if I want more information – what if I want to know which articles users are viewing? Parameterized session events can help us with that.

I’m going to modify the call to MK.SessionEvent and include a new parameter: “ArticleUrl.”

“ArticleUrl” is the name of my parameter, and the value of this is the URL of whatever article a user is viewing. In C# / XAML you can just pass in an IDictionary<string, string> object for all of your parameters and values, but in WinJS you need to use a Windows.Foundation.Collections.PropertySet collection.

Once I’ve run the app with this custom parameter included, I can drill down into the ViewArticle event and see a new parameter:

Hacker News app with an ArticleUrl parameter for the ViewArticle session event

And if I click on the “ArticleUrl” parameter, guess what we see next? A list of all of the URLs for each event!

hacker-news-viewarticle-articleurl-parameter-values

With that simple change, our ViewArticle event becomes much more informative and valuable – we can even use the date picker to see which articles were most popular amongst our userbase during each month or week!

Advanced Example: Distinct Session Event Parameters

Let’s take our usage of parameterized session events a step further. One of the features of my Hacker News application is the ability for it cache articles to the local filesystem in order to conserve bandwidth. I’m considering extending this capability to enable the app to run entirely offline – so my question is: how often do people really look at cached articles?

Parameterized session events can help us answer this question.

I’m going to move my MK.SessionEvent call from viewItem.js and into my caching layer – that way I can tell if the article I am serving is cached or not. Here’s my code looks like for that:

I have to different methods that are called by my app when we need to view an article – one that checks if the content is cached and serves it if it is, and another that downloads the content from the Internet.

Whenever we serve the content from cache, I pass in a ps[“Cached”] = true parameter and a ps[“NotCached”] = true whenever we don’t.

So after running the app a few times, it looks like most users don’t view cached articles very often:

Hacker News WinJS app - cached vs. uncached articles

I’m doing it this way so I can see directly at the ViewArticle view how many articles are served from cache versus those who aren’t without having to drill down any further.

But the choice is yours – parameterized session events are designed to be flexible and allow you to use them however you wish.

Make sure you check out our tutorial on using parameterized events with MarkedUp Analytics, and please let us know if you have feedback!

How-To: Last Chance Exception Handling in WinJS Applications

One of the things we designed MarkedUp to do was to be able to capture and save fatal errors that crash your Windows 8 applications and to reliably transmit them back to the developer for analysis and diagnosis.

Most fatal errors fall into one of two categories:

  1. Something went wrong with the environment outside the application, like an OS / driver error or an hardware issue; or
  2. The application failed to handle an exception thrown by the application itself.

Fatal errors in category #1 are impossible to recover from (usually because the application runtime or OS crashed) and are typically outside the control of the developer anyway.

Errors in category #2 are firmly in the control of the developer, however – and I’m going to show you how to tackle them in WinJS.

Sometimes you’re going to forget to handle an error in-context in your application – so what can you do to stop unhandled exceptions from crashing your application? Use the last-chance exception handler.

If you’ve done any serious Windows Phone 7 development, then you might have worked with LittleWatson at some point for simple last-chance exception handling and reporting – like this:

So how do you tackle this in WinJS?

The answer is fairly simple – in your default.js file you just need to chain an event handler to WinJS.Application.onerror event, like this:

In this instance I’m just using MarkedUp to transmit the fatal error message back to our servers next time the app starts (which is really the only safe way to capture a fatal error message.)

This technique has worked well for me for my Windows Phone 7 applications and should work fine for WinJS / Win8 too!