The widget visible event (called
widget_visible) is triggered every time a set of recommendations (whether LiftIgniter's or any other algorithm's) enters the user's viewport. Developers can get a quick summary at the Widget Events page. This page is more for people interested in data science and analysis.
For more on how this metric relates to other metrics, see our Metrics summary .
The widget visible event should be triggered whenever a widget showing recommendations by LiftIgniter or any other recommendation system enters the user's viewport. LiftIgniter's default implementation of this event automatically gets used if you implemented our Tracking Widgets functionality. Note that if you haven't implemented tracking, we won't receive this event. If you implement your own custom tracking function, you will need to make sure to include the visible event there (which is marked as optional) in order to have the event fire.
On standard HTML page layouts, any widget that is part of the viewport on page load (i.e., above the fold) will have the
widget_visible event triggered immediately. Otherwise, the event will trigger when the user scrolls down to the widget. Note that if the widget loads late for some reason, and the user has already scrolled past the area, we won't get a
widget_visible event (unless the user scrolls back up).
The following caveats apply to our default implementation of visibility. Although these reduce the level of insight you can derive, they keep our integration simpler and less custom, and they also make our code less computationally intensive for the client's browser. However, you can implement custom visibility tracking logic if you have more advanced needs.
- We track "all-or-none" visibility: we send a single
widget_visibleevent for the entire widget, even though a user may actually have only a few items in their viewport.
- Our default implementation of visibility tracking puts the listener only on the first item being shown. In other words, it triggers when the first item in the list enters the viewport.
- Our listener checks the status every 250 ms, so if people scroll rapidly or bounce off the page immediately, it may not capture the event.
Our definition of
widget_visible accounts for the recommendation widget entering the user's viewport. It does not, however, mean the user actually saw or noticed the recommendation, which is the event we are more interested in. Unfortunately, unless the user interacts with the widget in a meaningful way (e.g., by clicking on it), it's very hard to definitively know if the user noticed the widget. Even if the user did, it's hard to know how much attention the user paid to the recommendations.
We do have some general guidelines, based on eye-tracking studies as well as CTR measurements, of how the placement and style of a widget can affect the extent to which it's actually noticed.
LiftIgniter does A/B testing by user. This means that when we do a 50/50 A/B test, 50% of users see LiftIgniter's recommendations all the time, and the other 50% see the baseline recommendations all the time.
By and large, when an A/B test is launched, LiftIgniter and the base have an equal number of
widget_visible. However, differences in the algorithm can lead to differences in the total number of
widget_visible events for three possible reasons:
- The direct effect: If the CTR is high (generally if it is over 5%) and the pages that users click to also show the same recommendation widget, then the slice with higher CTR will also end up getting more
- The first indirect effect (increased visibility): People who have seen better quality recommendations in a recommendation widget may be more inclined to scroll back to the recommendation widget on subsequent pageviews.
- The second indirect effect (increased return visits): People who have been exposed to a better quality experience (through better recommendations) may return to the site more.
|Supported by LiftIgniter?
|Yes, with tracking implemented
|Visible Click-Through Rate (VCTR)
|Yes, with tracking implemented
|Engaged Visible Click-Through Rate (EVCTR)
|Yes, with tracking implemented and engagement definition
|Conversion (through click)
|Yes, with tracking implemented and conversion tracking implemented