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 where the event must be sent (so-called pixel tracking).
For example, with HTML:
1 2 3 4
The drawback of this option is that such calls can be blocked by ad blockers or do-not-track plugins on the client side.
Another option is to call the tracker from the server. The most important drawback is that the event request increases the general request time. If the network is overloaded or the Personalization server is not available, the number of requests could grow and lead to a stalled and finally crashing HTTP service. There are several techniques that can help you avoid it.
Tracking at 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 the events. The connection to the browser might remain open for the time of processing, but it will be transparent for the end user.
If the website is implemented in a language that supports multithreading, non-blocking I/O or messaging infrastructure, you can start the event request just after the browser request is received instead of waiting for this process to finish.
Using a server proxy¶
An overview of pros and cons for every technique:
|Problem||Pixel||Server-side||Page bottom||Async. reporting||JSONP||XMLHttpRequest + Proxy|
|Is not blocked by ad blockers or do-not-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||-||Yes/No|
The recommended approach
An Ibexa-recommended solution is to use pixel tracking for non-complex events,
or where every page is generated on the server side without any caching logic.
var img = new Image(); img.src="uri")
or without them (
<img src="uri"... />), see How to Preload Images.