//Signal Data Offering

Last Updated February 12, 2020
What are ‘Engagement Events’?

‘Engagement’ Events are specific DOM Events related to how a user consumes and interacts with a website.

DOM Events are sent to notify code of interesting things that have taken place. Events can represent everything from basic user interactions (mouse click, keyboard move) to automated notifications of things happening in the rendering model (ie, the page has fully rendered). A full list of DOM Events (along with descriptions) can be found here.

Events are actions or occurrences that happen in the system you are programming — the system will fire a signal of some kind when an event occurs. These signals can then either be used to a.) understand how a user interacts with a page or b.) to provide a mechanism by which some kind of action can be automatically taken. For example, if the user clicks a button on a webpage, you might want to respond to that action by displaying an information box.

With //Signal we are exclusively focused on measuring DOM events that pertain to user interaction. These can be broken into 8 categories:

  • View
  • Focus
  • Keyboard
  • Mouse
  • Clipboard
  • Pointer
  • Touch
  • Drag and Drop

Across these 8 categories, there are 53 events in total.

//Signal currently captures 45 of these events. The 8 that are currently not captured are not considered essential to capture, as they do not happen in isolation but rather in tandem with one of the 45 events that we do capture.

What engagement data do we collect and store?

Page-level:

  1. scrollDepth – The beacon frequently checks the documentHeight of the webpage, and the number of pixels the user has scrolled down. This calculates the percent scroll depth reached and helps us understand how users engage with content.
  2. dwellTime & engagedDwellTime – The number of seconds since the user arrived on the webpage gives us the dwellTime. engagedDwellTime is the total number of seconds a user spent engaged on the page. For a user to be engaged on the page, a focus event has been sent showing the user is active within that viewport. //Signal then looks for any of 45 DOM events that could be sent to the browser, showing that the user is engaging with the page ie. mouse move, scroll, key press. As long as the user is focused in the viewport and //Signal is seeing these events being sent, the engagedDwellTime continues to count. If the user is no longer engaged (no events emitted) after 10 seconds, we pause the engagedDwellTime.

Placement-level:

  1. viewableSeconds – the number of seconds an ad has been in-view, according to the IAB specification.
  2. engagedViewableSeconds – the number of seconds an ad has been in-view, according to the IAB specification, and the user is engaged on the page (based on engagement requirements above).

We then send these metrics to our data collectors each time a user disengages or leaves a page, to get both accurate data but minimal impact on the user experience. On both a page and placement level, the //Signal beacon collects several other data points including device type, OS, domain, consent string & ad slot (‘selector’). A sample data set can be provided upon request.

Why don’t we store all engagement data?

Based on experiments run by Sovrn, on average, 500 DOM events are sent per page session. This is a lot of data! We believe all DOM events equally contribute to the engagement of the user. Therefore, to be able to inform the publisher of activity on the page, distilling these events down to overall engaged time has proven to accomplish our publisher’s goals. We are always happy to work with you to provide additional data if a clear use case is presented.

Don’t forget to reach out to the Sovrn Publisher Support team if you have any questions.

How satisfied are you with this article?

  • Not at all satisfied
  • 1
  • 2
  • 3
  • 4
  • 5
  • Completely satisfied