How should I track widget renders?

Question

I created a widget that users of my site will embed on their web sites. I want to track the amount of times a widget renders as well as the referring URL. The widget was written in flex and my back end is Rails.

One obvious way to do this would be to have my widget make a service call to the back end to register a hit. However, when my widget loads, it grabs a config XML. If I add another render service call, that will be 3 requests per widget render (one to get the swf, one to get the config, one to render). I could make the config.xml dynamic and just process a render there, and then return the XML...but could this be bad for scaling?

Another would be to make the embed source URL point to a script that processes a hit and then returns a swf...i am pretty sure this is possible. But I am also not sure if this is the best way.

I am interested in any professional advice on this. How do the pros efficiently implement this simple system?

Thanks!

Answer 1

All of the three options you mention seem like perfectly valid ways to do this, but registering these hits at the same time as returning either the .swf or the .xml config file seems like a smart thing to do because AFAIK most browsers have a pretty low limit to the number of concurrent HTTP requests they can make to the same host (I think it's two or something like that) so if more requests have to be made in order to render something in the browser, the ones going over this limit will have to wait for the first ones to finish before being initiated. It'd also probably entail slightly less work for you.

The only difference I can think of is that returning the .swf doesn't yet mean that a Flash Player instance will render it so "registering renders" when returning the config xml seems like it would give you a more solid measurement of how many times someone's browser has successfully loaded and shown them this .swf (assuming that the Flash app will initiate the request for this config file after it has successfully been loaded).

As far as the scaling issue goes, regardless of when you'd be registering the hit it'd still require the same amount of processing on the server (which I can't imagine being very high for something like this), so I don't see this as a big concern.

Answer 2

The standard way to do this is load a 1px image ("bug") from your site, and use analytics on your site to keep tracks of the stats. There are lots of innovations on this technique, but they all are based on the simple 1px image load, and using the associated HTTP headers.

Wikipedia has a good article on this technique:

http://en.wikipedia.org/wiki/Web_bug

(Also, the browser limit on concurrent HTTP requests only applies to requests sent to the same domain. You get around this by using multiple subdomains, or any other technique to ensure your resources are not all from the same domain.)