Engaged Time Window
Events Indicating Engagement
Listed with the event name, DOM target, and description:
Captures when a page is brought to the foreground either by tabbed browsing, or by bringing the browser window with the active page to the foreground.
Captures any time the window/document is scrolled by any means (arrow keys, scroll bar, mousewheel).
Captures any time the browser window dimensions are changed.
Captures mouse movement over the document body.
Captures any time a mouse button is depressed in the document.body.
Captures any time a non-scroll keyboard key is pressed. Fires continuously if held down in almost every browser.
Page load and page focus are treated as acts of initial engagement, representing either loading or returning to a page, respectively. Scroll, mousemove, mousedown, and keydown all serve as proxies for ongoing engagement as these actions capture ways the user can navigate or interact with the page. Resize is also treated as an act of engagement as the user is specifically manipulating their view of the page.
Note on What is not Tracked
Other possible events are ignored because they are redundant with the ones currently monitored and tracking them would impose unnecessary additional load on a page.
keyupis not needed when keydown fires continuously.
mouseupcould fire absent a proximate mousedown or mousemove, such as when a user holds the mouse button down for a long period of time before releasing it. But Chartbeat believes such an event is an edge case and not worth the extra event listener.
pointerevents are not included as adding listeners for them can have an effect on the presentation, functionality, and/or performance of client sites in iOS Safari.
keypressare redundant when listening to mousedown and keydown.
mousewheelcould potentially fire when scroll does not, such as scrolling the mousewheel over an un-scrollable element, but Chartbeat believes that this type of scenario is an atypical way to engage with a page, and the user is likely to immediately adjust their behavior in a way that triggers one of the other engaged events (scroll, mouse move, etc.). Additionally, Chartbeat has observed that mousemove is usually triggered simultaneously with mousewheel events.
Exclusion of Video Play Time
We do not count video playing time toward our engaged time metrics (Average Engaged Time, Total Engaged Time, Total Engaged Minutes), even for sites with our Video tracking integration enabled where we actively measure video play state for all users on the website. When a video is playing, the user might be actively on the page, or the user might just have the tab open to the client site with the video playing, unwatched. When multiple users participate in this behavior throughout a given day, many hours of video play time can be racked up, which would have the unwanted side effect of significantly inflating page engaged time numbers erroneously if video play time were to be counted toward our engaged time metrics.
Note on Mobile Activity
Essentially all mobile browsers fire desktop mouse events at the end of a touch tap to better accommodate legacy web pages that do not take advantage of the touch events. We do not listen to mobile-specific touch events as they can have negative effects on client sites.
In-Focus Browser Window
Chartbeat considers both whether a given browser tab is the active tab in that window ('Tab Focus') and whether the window is the active application ('Browser/Application Focus') before deciding that the page is visible.
By requiring both Tab Focus and Browser/Application Focus, Chartbeat does not consider some technically visible scenarios as viewable, such as a page in a window behind another window, but still on the screen, as there are inconsistencies in how these scenarios are measured.
Auto-Refresh and virtualPage
If a page is auto-refreshed while the page has both tab and application focus (see In-Focus Browser Window above), a viewable impression and active exposure time will likely be registered for any ads that are in view in the new session. During daily data processing, Chartbeat uses page referrer data to detect impressions generated via a full page refresh by checking to see if the referring URL matches the page URL.
Chartbeat offers a public API method called virtualPage that enables publishers to signal a new page session even when there was no actual page load. This is used on AJAX layouts where scrolling or other interaction triggers new content loaded dynamically into the page. A new URL is usually pushed and new ads are loaded, making this effectively a new page load, and Chartbeat handles it accordingly by resetting all aspects of Chartbeat's tracking. So a virtualPage will record viewable impressions and active exposure time for any ads that meet the criteria afterwards.
In the event that an ad unit becomes viewable or the campaign data within an ad changes, Chartbeat immediately sends a "force ping" back to its servers to confirm the event. A "force ping" is identical to a "standard ping"–it just occurs outside the usual ping cycle, when an event of interest has occurred.
External: Chartbeat hooks into the beforeunload event for any users exiting the page (except via an internal anchor element click, which will be captured via the internal mechanism detailed below) to attempt one final ping. As this is an asynchronous event it is not guaranteed to succeed but Chartbeat has found that when combined with the internal unload pinging there is a 68% rate of success in capturing the final state of the pinger. Chartbeat does not attempt the ping in the unload event, as that would make exiting a page synchronous and in turn block the loading of the next page. This would contribute to users' perception of slowness across Chartbeat's client network and is an anti-pattern.
Internal: Chartbeat hooks into the unload event to store the current state of the pinger in the client for an hour after the user leaves a page. If the user returns to any page on that domain with Chartbeat's pinger within the hour their final state will be sent.
As with any tracking philosophy Chartbeat suffers from certain technological limitations that prevent complete measurement coverage. Below is a full list of weaknesses unique to Chartbeat in addition to those shared by all analytics providers.
- If a user leaves a page in-between ping intervals, there is a chance that activity after the last ping will not be recorded. This will only affect time metrics as Chartbeat sends a Force Ping when viewable impressions occur.
- Chartbeat stores certain information on the client side in localStorage or cookies. If the user has disabled this type of storage, certain information cannot be persisted between sessions.
- Chartbeat may be specifically targeted in Do Not Track software, blocking script loading or functionality.
- Chartbeat infers that viewability measurements are taken of an ad appearing both a) in its container and b) in its intended form.
- While Chartbeat follows industry best practices, not all robot traffic can be identified and it is possible that a certain number of impressions are still triggered by non-humans.
- Due to inconsistencies in browser location detection Chartbeat assumes a browser is always fully on screen if not collapsed or otherwise disabled.
- Chartbeat does not have a system to identify or estimate unique audience metrics in situations where cookies cannot produce an accurate measure. Chartbeat has found that among US customers fewer than 0.1% of impressions occur with cookies disabled while fewer than 0.3% of impressions have cookies disabled among European customers.
General Measurement Limitations
- Chartbeat may not detect ad blocking software unless it affects the geometry, visibility, or labeling of the ad.
- Chartbeat relies on image beacons which can be disabled by a user resulting in no information being collected.
- Not all caching can be eliminated so it is possible that certain users will run old versions of Chartbeat code.