A "pixel" is an online advertising term for snippets of code used to track conversions on an advertiser' site.
A conversion tracker reports to the ad server or any other platform that a conversion has occurred, but equally as important, it associates this conversion with the impression that initiated this conversion process thus allowing for optimization and billing of the right partner (the one who bought the impression).
The name "pixel" for this conversion tracker comes from the first method of implementing these trackers: the first trackers were implemented as small images of 1x1 size (1 pixel) which were transparent (so as not to be seen by the user) and resided after the action page (in the conversion page). This image was inserted into the page by a simple html "img" tag. The image itself is taken from the ad server and not from the advertises' server as the rest of the page, and the ad server records the call made to the image and counts it as a conversion.
Conversion types:
1. Image pixel: the image pixel's basic behavior is as I described it above and it has changed very little since the time that the concept was born. There have been small improvements to its functionality. The first one is that today the url called for the image is not an actual image, rather, it is a script page that records the conversion and after it is done, it sends the browser back this 1 pixel, transparent image.
The second improvement was the addition of the cookie which is introduced to the browser with the impression and read by the ad server during the processing of the script mentioned above. This cookie is used to associate the conversion with the impression that started the conversion process.
This type of conversion tracker is being used less and less.
2. Script pixel: this is the most commonly used conversion tracker and it has nothing to do with any pixel image. It is a piece of JavaScript code that is embedded inside the advertiser page. Once the page loads, this piece of code is activated by the browser, and this code usually calls a page on the ad server. This page usually does 2 things: the first, it retrieves the user cookie (that was planted by the ad server with the impression) and records the conversion. The second thing it does is send the browser back some additional pixels (either image pixel or script pixel) so that other systems can know about the conversion.
3. Token pixel (or as it is more widely known as server side pixel): a token pixel does not rely on the user cookie in order to be able to match the conversion to an impression, rather it relies on a token (usually an impression ID) that the ad server generates. This token is then passed from the publisher site through the ad server to the advertiser's site who is responsible for remembering this pixel in order to report is back to the ad server in case of a conversion. This type of conversion tracking is currently used for advertisers that cannot rely on the user cookie at the time of the conversion. example cases can be that a conversion is logged after downloading a ringtone and so the conversion happens on a mobile phone who has no access to the cookie in the browser in which the user saw the ad. Another example is registration from within a downloaded software etc...
In these cases we report the conversion ("fire the pixel") from the advertiser server to the ad server directly without using the user's browser, hence the name "server side pixel". But as these pixels are the most reliable ones out of the three methods, we are starting to use them in situations that we do have cookie access and can use the browser for the reporting action and so the name "server side pixel" no longer describes the pixel accurately hence the new name - "token pixel".
The problems with these conversion tracking methods:
- The first two methods rely very heavily on cookies:
Cookies are quite unreliable as many of the users block them altogether and many other erase them for various reasons. The average lifetime of a cookie is about 3 weeks and if the user either blocked the usage of third party cookies or deleted them between the time of the impression and the time of the conversion, there is no way to attribute this conversion to the impression that generated it and thus no way of optimizing it or paying the right vendor for it. In addition to that, regulations on cookie usage are constantly increasing, causing this technology to be less and less reliable for billing and optimizing. - Duplication and de-duplication:
The first two methods described above usually cause many duplication problems. A duplication problem is the problem of two service providers being assigned a single conversion (which means they will both get paid for it). This is a result of the very basic data that is saved on the cookie so that if a user encounters two banners for the same advertiser by two different ad networks/agencies/affiliate, they will both plant a cookie on this user's browser. Later on, when a conversion occurs, they will both claim ownership on this conversion (who is to say which banner really triggered the user to buy the product later on). De-duplication is the process of trying to diminish the number of duplications for an advertiser. - http protocol:
All three implementation methods described above use the http protocol to report the conversion. This protocol is the least reliable protocol available. It makes a call without knowing or verifying whether this call was actually received, it is not persistent with its data transfers and has very little error tracking and correcting and very basic hand-shake process. It is a session-less protocol relying basically on one-way communication. - Poor implementation:
Pixels are usually implemented on the advertiser's website by one of the low level programmers. This in no way insinuates that they are not good programmers, but definitely not the most experienced ones. On top of that, the whole implementation is usually carried our in low programming standards (like exception handling, error checks, return codes etc...) as this is the current implementation standard.
I was talking to Mike Nolet of AppNexus about hiring programmers in NY and he told me that the banking industry is taking all the best programmers because they are dealing with financial transaction and there is no room for error there. Well guess what, conversions are financial transactions as well, so why are they dealt with usually by the lowest level of programmer in the advertiser's organization, and in such low programming standards?
Interesting, precise and comprehensive explanation of all conversion tracking methods.
ReplyDeleteI couldn't agree more about the programmers that are in-charge of these implementations. companies spends unrealistic budgets on the advertising and visuality and don't think that the most significant thing would be counting the conversions properly!
This was very eye opening, thanks for the post.
ReplyDeleteBut, what would be even for helpful, is you answering, what procedures to take in conversion tracking OR what you do to get the best accuracy???...
That's what we all want to know!
I previewed and still over looked my mistake, I meant, "even more helpful,"
ReplyDeleteDon't drink beer and read posts, LOL =)
Hello,
ReplyDeleteThere is a followup post I wrote called "The Perplexities Of Pixels" (can be read here: http://www.adotas.com/2010/11/the-perplexities-of-pixels/ ) which addresses some of the questions raised here but in essence, cookie based conversion tracking will always be inaccurate. In order to be have a higher reliability of the pixels, you need to employ token pixels which provide a much higher level of accuracy and dependability. However, these pixels require a high level of coordination between the advertiser and the advertising platform and sometimes the publisher as well, for both the tracking and the reporting of the impression IDs that converted.