Widget Analytics – Measuring the widgets in the wild

Helping web analysts navigate the measurement and tracking of widgets.

Posts Tagged ‘widget time spent’

Widgets and time spent – measuring the duration of a widget view.

Posted by widgetgirl on January 7, 2008

Measuring the time that someone spends viewing a widget is not as easy as it sounds. If you consider the page view, the way to measure how long someone spends with that particular page is the difference between the time the page was loaded and the time that the next page was loaded. For example:

  1. Visitor requests www.clearspring.com at 12:01:36
  2. Visitor requests www.clearspring.com/advertising at 12:02:14
  3. Visitor requests www.clearspring.com/adnetwork at 12:04:34

What we know from this example is that the visitor spent 38 seconds on the page www.clearspring.com and 2 minutes and 20 seconds on the page www.clearspring.com/advertising. We do not know how long a visitor spent viewing www.clearspring.com/adnetwork though as there is no next page to calculate a differential on. Traditional web analytics tools allow you to calculate the difference between time stamps on pages.

Clock 2

Calculating time spent for a widget relies on periodic communication from the widget back to the widget serving platform that is collecting the analytics data for the widget. When the widget first loads on a page, the container (flash or javascript) that is wrapped around the widget will send off a tracking packet to the widget platform in order to record that the widget has loaded. Then periodically the widget will “ping” the server collecting the data for widget analytics to let it know that the widget is still being viewed. The communication of a widget view might look something like this:

  1. Widget loads on www.clearspring.com/widgets/464eb40d70d61eff at 09:15:00 and tracking packet is sent to server.
  2. Widget continues to be viewed on page. At 09:15:30 the widget container sends a tracking packet to the server.
  3. Widget continues to be viewed on page. At 09:16:00 the widget container sends a tracking packet to the server.
  4. Widget is clicked on for the first time at 09:16:20. At 09:16:20 the widget container sends the click in a tracking packet back to the server (which will also contain an update to the time spent metric).
  5. Widget continues to be viewed on the page. At 09:16:50 the widget container sends a tracking packet to the server.
  6. Widget is clicked on again at 09:16:52. At 09:16:57 the widget sends the click in a tracking packet back to the server (again, containing an update to the time spent metric).
  7. Visitor navigates away from the widget at 09:17:12

The total time spent viewing this widget will be calculated at 1 minute 57 seconds (you were probably thinking that I was going to say 2 minutes 12 seconds). The reason that the time spent metric is capped at 1 minute 57 seconds is because that was the last time that the widget had communication back to the server.

In the Clearspring widget serving platform, our widget tracking capability for time spent is set at a 30 second interval of communication. What this means is that the widget will reach out every 30 seconds to the servers collecting widget analytics to indicate that it is still being viewed on the page. Deviations to this methodology are that we send off tracking packets to our servers immediately if someone clicks on a widget or mouses over the widget (we only count what we call “strong” hovers – those of a half a second or more). On subsequent clicks or interactions with the widget we send the tracking packet off 5 seconds later. Each time a tracking packet is sent, the 30 second clock is reset.

The methodology of how the data is collected differs from traditional “on-site” web analytics, but is the only to truly assess how long a widget is viewed on a page. Each time the page is reloaded, the clock for the widget is set back to zero. Think of each view as a session and the widget view as the session duration. The only way to calculate the session duration or time spent is to force a communication effort between the widget and data collection server.

Periodic communication between the widget and the server may be viewed as “chatty”. We provide the ability for the Widget Creator (WC as we call them around here) to dial up the communication or dial it down (especially if it is an interactive game that requires a lot of clicking) to manage the user experience.

I am including a colleague’s personal widget for my “widget of the week”. The “Rob and Elliott” widget is a comic strip widget. The WC updates it weekly. You can check out the widget here.

Rob and Elliott

Posted in widget analytics | Tagged: , , , | Leave a Comment »