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 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 can grow and lead to a stalled and finally crashing HTTP service. See below the techniques that help avoid these problems.
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 before sending the events. The connection to the browser can remain open for the time of processing, but it is 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 right after the browser request is received instead of waiting for this process to finish.
Using server proxy¶
An overview of pros and cons for every technique:
|Feature||Pixel||Server-side||Page bottom||Async. reporting||JSONP||XMLHttpRequest + Proxy|
|Is not blocked by ad blockers or do-not-track plug-ins.||-||✔||✔||✔||-||✔|
|Is compatible with frontend caching on the server.||-||-||-||-||✔||✔|
|Doesn't delay page rendering.||✔||-||✔||✔||✔||✔|
|Supports authentication for event tracking (not implemented yet).||-||✔||✔||✔||-||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.