There are several ways to integrate event reporting into the webpage. The simplest way is to generate code of a tiny image and put it on the webpage (pixel tracking) where the event must be sent.
1 2 3 4
The drawback of this option is that such a call can be blocked by ad blockers or do-not-track plugins on the client side.
Server side tracking¶
Another option is to call the tracker from the server. The most important drawback is the increase in request time by the time of the recommendation request. If the network is overloaded or the Recommendation Engine is not available the number of requests could grow and lead to a stalled and finally crashing httpd service. There are several techniques which help to avoid it.
Tracking in the bottom¶
You can place the code at the very end of the generating script and flush the output buffer to the client just before sending events. The connection to the browser will usually still be open during processing, but it will be transparent for the end customer.
If the website is implemented in a language which supports multithreading, non-blocking I/O or messaging infrastructure, it is possible to start the recommendation request just after the browser request is received and/or not wait until this process is finished.
Client side tracking¶
Using a server proxy¶
An overview of pros and cons for every technique:
|Problem||Image||Server Side||Bottom Reporting||Async. Reporting||JSON||XMLHttpRequest + Proxy|
|Is not blocked by ad blockers or no-track plug-ins.||-||Yes||Yes||Yes||-||Yes|
|Is compatible with frontend caching on the server.||-||-||-||-||Yes||Yes|
|Does not delay page rendering.||Yes||-||Yes||Yes||Yes||Yes|
|Supports authentication for event tracking (not implemented yet)||-||Yes||Yes||Yes||-||depends|
What we recommend
We suggest using Image/Pixel tracking for non-complex events and where every page is generated on the server side without caching logic. Some hints how to use preload image URLs with (
var img = new Image(); img.src="uri") or without (