Tracking OERs: Web bugs

This page is one of several describing technical approaches to tracking the use of OERs.

A web bug is an object that is embedded in the HTML of a web page or e-mail and is usually invisible to the user but allows checking that a user has viewed the page or e-mail [Wikipedia ]. Commonly these objects are invisible images (e.g. a single pixel transparent gif), images that act as a badge, or JavaScript. The address for the object in the HTML is given using an absolute URL so that even when the web page is copied from one server to another the web bug object will be obtained from the original server specified. Thus the web bug object is accessed every time the page in which is it embedded is opened, and tracking methods such as web usage stats and online analytics, including information gathered by JavaScript and stored in cookies, applied to the web bug give tracking information for the original page even if it has been copied and is not on a server to which the person doing the tracking has access.

Tracking by web bugs is generally considered to be controversial, partly because it involves silently passing data to a third party (i.e. the person doing the tracking is not the end user or necessarily connected to the site where the resource is hosted), and partly because some high profile uses of web bugs are connected to activities such as checking the validity of email addresses in lists used by spammers. It should be stressed that the information tracked is no different to that available through other means, and specifically that web bugs are not to be confused with more invasive forms of information logging or spyware such as keystroke logging. There are many uses of web bugs which seem to be widely accepted, for example: the use of javascript by Google Analytics amounts to a web bug; the smiley visible somewhere on many wordpress.com blog pages is used for tracking; and, many 'badge' or 'button' images advertising the use of or support of a service, campaign or software (e.g. creative commons) which are inserted using copy and paste code that links to an image on another website could be used as web bugs for tracking.


 * Web bugs can be embedded into resources that can make HTTP requests, typically (but not only) web pages. It doesn't matter if the resource is viewable on the open web or not, so long as the software used to view it can access the web.


 * Web bugs can be used to log automatically when an HTML page has been viewed, even if it has been copied to a server other than the one on which it was originally published.


 * The information logged can include the fact the page containing the web bug has been viewed, technical information such as the location on the internet, the browser and platform used by the person viewing the page.


 * The referrer for the request will contain information on where the web page has been copied to.


 * The web bug may set a cookie on the client machine which can be used for enhanced tracking.


 * The precise URL used to call the web bug may be varied (while still linking to the same object), by use of fragment identifiers of the form #pageID, so that page-level tracking may be achieved with a single object.


 * Since they involve an HTTP request and response loading a web bug will take time even if the image being used is minimally small, this may be an issue if the server on which they reside is slow to respond.


 * While web bugs are usually invisible they need not be, however if the web bug is not invisible then there is a responsibility on the owner of the site from which it is served to maintain access to it.


 * Many people who object to web bugs use filters that block them.


 * If the licence under which the OERs are published allows modification then the web bug may be removed when the resource is copied. This would have the advantage for the person making a copy of the OER that it removes a dependency on a web server not under their control. Some Open Source Software so-called "badgeware" licences allow for sharing on the condition that some text or embedded image is retained.


 * Having a link in the resource to an object on a server under the control of the OER provider may be useful for conveying information after the resource is released. For example, a single pixel transparent gif could be changed to a big red warning that information contained in the resource is no longer valid. (That's a in interesting idea, particularly given the concerns some projects have voiced regarding the currency of OER resources --Lorna 12:18, 16 March 2010 (UTC))