Top FAQs
What is Signal?
Signal is a product that allows you harness the power of your engaged readers through collecting valuable engagement and viewability metrics.
What products are available that take advantage of this technology?
We have 2 great options to empower you to monetize your readers:
Option 1 (Whitespace monetization)
Take advantage of unused space on your site, displaying ads in the whitespace or the footer of your page after viewability and engagement thresholds have been met.
Option 2 (Viewable Engagement Time (Signal) reload monetization)
Allows for additional impressions to be served after viewability and engagement thresholds have been met for existing ad units or slots. No additional placements need to be created to serve more creatives.
How is Signal implemented?
Signal is implemented via a single line of script which can be delivered to the page either through DFP or direct via hardcoding. Once on the page, the Signal Viewable Engagement Time (Signal) automatically identifies all ad placements and will apply the predefined Signal logic to the appropriate ads that have been selected to run.
How quickly can it be implemented?
Implementation time depends on the method of integration. If through the ad server it can take as little as 5 minutes. Should you need assistance with the implementation ask your Publisher Advocate or Account Manager to walk you through the steps outlined here.
Will it require any dev resources?
If served through DFP there is no dev work required. The Signal tag was designed so that it could be implemented by commercial ad operations teams without the need to request development resources. If the only possible implementation method is hardcoding then yes, it is likely that some dev resource will be required.
What ad servers do you support?
Signal is ad server agnostic and works across all major ad serving and programmatic systems currently in use in the marketplace. Certain ‘add-on’ features, such as specific line item type blocking, however, are currently only supported in DFP Premium and DFP Small Business.
Will all ad types be eligible for Signal Option 2 – Signal reload monetization?
Yes — the default setting for Signal is to reload any placement that meets the pre-defined criteria regardless of the type of ad loaded (i.e., sponsorship, programmatic, direct). We can customize the logic to remove the reload from running on specific ad placements on a page, if so desired.
Can we block specific campaigns or line item types from running Signal Signal reload?
Yes — if you are using either DFP Premium or DFP Small Business we can accommodate this. We would need limited API reporting access to your DFP (this can be managed via your DFP UI) to enable this feature. This feature works as follows:
- By identifying the line item ID on page load for each ad
- Making an API query to your DFP for the line item type
- Identifying whether the line item type is permitted to run Signal (i.e., sponsorship = no Signal)
- If the ad is not permitted to run the reload, Signal will disable the functionality
If you haven’t done so already, you will need to enable third-party access to your DFP API. Instructions to do that can be found here. If you do not use DFP but would like to implement this blocking feature we’d recommend a custom integration session with one of our implementation engineers.
Does it work across mobile?
Yes – Signal technology is device agnostic and looks for specific engagement events based on the device type that is loaded.
Does this only work for standard IAB?
No – it can also be applied to all creatives served out of 1x1s, out of page units or any consistent element which exists on a page.
Will the Signal feature cause any page latency?
No – Signal’s script is super lightweight (sub 50kb). All decisions around user engagement are happening within the browser itself, and the only outbound server connections are made with DFP after all initial ads have been loaded. We have an in-depth study on page latency that we are happy to share.
Why is it 20 seconds?
20 seconds is default Signal setting that we have across the Sovrn Signal High Viewability and Engagement Exchange Marketplace. Both internal, external and independent research has shown that after 20 seconds of viewable time there is no additional impact to both performance (CTR, engagement) and impact (brand recall). If you have any questions or believe your site’s engagement patterns render an alternative engagement time, please talk to your publisher advocate.
General
What is Viewable Engagement Time?
Viewable Engagement Time (Signal) is an alternative currency for monetizing banner advertising online, compared to the existing ‘served impression’ CPM model. The premise is that the way that banner ads are currently monetized (Served Impression CPM model) assumes that every impression sold has the same attributes and as such has the same value. The reality is far different. Not every ad that is served is seen, and even if it is seen the extent of time which that ad is seen, or the engagement level of the user can vary tremendously.
At Sovrn, we believe that publishers who create engaging content should be able to fully monetize their users’ engagement, rather than have a static one-size-fits-all approach to monetization. Under the current model, a site which focuses on low user engagement and low page dwell time is rewarded in the same way as a site that nurtures engagement and dwell time. Signal is a solution that enables publishers to readdress this and monetize the full extent of the engaged users that they have nurtured on their sites.
What is the benefit of Signal to a publisher?
Put simply, publishers can flip from monetizing a static number of ads per page impression to an infinite number of impressions based on the engagement levels of their users. If they are creating engaging content, then they are going to be rewarded. This shift can help publishers to create substantial net new inventory, which they/we can then monetise with assurances of quality, creating previously unobtainable revenue lines. We’ve helped multiple publishers and publishing groups create upwards of 50% inventory overnight from applying this method to existing placements.
How is this different from DFP’s refresh feature?
DFP has a setting which enables auto-refresh of specific ad units.
That being said, Google’s auto refresh feature is in line with other legacy refresh solutions where the ad unit is re-loaded based on a pre-defined time from initial page load, without factoring in whether or not the ad is or has been in view or whether or not the user is or was active. Therefore, with DFP’s solution you are just creating new inventory without having any minimum barometers on their quality, lowering the overall quality of ads served (ie viewability rate, viewable time). This will in turn lead to buyers paying a low rate (if buying them at all), and potentially even get your inventory banned from ad exchanges as this type of ad refresh can be considered as ad fraud.
Is that also the same for all ad servers / CMS systems / websites which have a refresh feature?
Yes – broadly speaking, most existing refresh systems build into ad servers or employed by websites are legacy refresh. This means that the impression, or in some cases the page refreshes on the predetermined time (refresh rate) from initial page or ad load as opposed to anything more comprehensive that takes into account a) ad viewability and b) user engagement.
How should Signal ads be priced?
Pricing is a tricky question to answer, as there are so many variables that dictate rates. What we can say with certainty is that Signal enables a publisher to price the ad unit more accurately with a minimum level of ad quality (IAB Viewability) and max level of ad quality (Signal Reload Rate). Previously, pricing was made without knowing the attributes, and as such value of the ads. Signal, on the other hand, provides transparency on that and, as a result, clarity on pricing.
Technology
How do you determine that a user is engaged?
We only determine a user to be active if two conditions are met:
That they are ‘focused’ on the tab. They will be deemed inactive if they:
- Click on to the URL bar
- Flip to another tab in the browser
- Cover any portion of the browser window with another app (i.e., skype)
- Flip to another screen (if using multiple screens)
Once this condition has been met we look at engagement triggers (such as move, keyboard movement) to determine a user is active. From an active state, when the tab is in focus, the user can only flip to being inactive if no engagement events occur for a period of pre-defined time (the disengagement threshold).
When do you determine that a user is engaged?
There is a setting called the disengagement threshold which determines the period of time that should be allowed with no engagement events being received before determining the user to be inactive. This setting can be customized, however our standard is 5 seconds.
A chart to demonstrate how a user changes from an active to an inactive state via the disengagement threshold
What metrics combine to generate Signal?
Signal is a time based metric which counts how long two conditions have been met:
- A given ad is ‘viewable’ by the user (51% of the ad for 1+ second)
- The user is active and engaged
The timer starts when both of the above conditions are met and stops if either of the conditions are not met. The time can then restart from a lapsed position, commencing on the Signal time it left on.
How many engagement events do we measure?
We currently measure 10 separate engagement metrics. These include:
- Mouse movements (mouse up, mouse down, mouse click)
- Keyboard movements (Key up, key down)
- Additional scroll events
- Focus & Blur events (initiated in multiple occasions, for example, when a user flips tab)
- Touch events (specific to mobile and tablet environments)
Does the technology work across all devices?
Yes – the product is device agnostic. We have specific engagement events (such as touch) which are specific to mobile/tablets.
How do you measure viewability?
We use the geometric method to measure viewability, which is the industry standard.
Implementation Details
How is Signal imlemented?
Signal is implemented via a single line of script which can be delivered to the page either through DFP or direct via hardcoding. Once on the page, the Signal Viewable Engaged Time (Signal) automatically identifies all ad placements and will apply the predefined Signal logic to the appropriate ads that have been selected to run.
What ad servers do you support?
Signal is ad server agnostic and works across all major ad serving and programmatic systems currently in use in the marketplace. Certain ‘add-on’ features, such as specific line item type blocking, however are currently only supported in DFP Premium and DFP Small Business.
Do you provide implementation documentation?
Yes, upon request.
How quickly can it be implemented?
Signal can be implemented within 24 hours of the initial request. From there, implementation time depends on the method of integration. If through the ad server it can take as little as 5 minutes.
Will it require any dev resources?
If served through DFP there is no dev work required. The tag was built so that it could be implemented by commercial ad operations teams without the need to request development resources. If the only possible implementation method is hardcoding then yes it is likely that some dev resource will be required.
Will all ad types be eligible for Signal reload?
Yes – the default setting for Signal is to reload any placement that meets the pre-defined criteria regardless of the type of ad loaded (i.e., sponsorship, programmatic, direct). We can customize the logic to remove Signal from running on specific ad placements on a page, if so desired.
Can we block specific campaigns or line item types from running Signal?
Yes – if you are using either DFP Premium or DFP Small Business we can accommodate this. We would need limited API reporting access to your DFP (this can be managed via your DFP UI) to enable this feature. This feature works as follows:
- By identifying the line item ID on page load for each ad
- Making an API query to your DFP for the line item type
- Identifying whether the line item type is permitted to run Signal (i.e., sponsorship = no Signal)
- If the ad is not permitted to run Signal, Signal will disable the functionality
Can demand partners be blocked from accessing Signal demand on a publisher’s request?
Yes – should you wish to block certain advertisers / buyers from accessing Signal inventory we can do so on the following levels:
- Brand / Advertiser level (i.e., BSkyB)
- Category Level (i.e., Media & Communications)
- Buyer Level (i.e., MediaCom, Xaxis, GroupM)
- SSP Level (i.e., AppNexus)
Can the Signal reload rate time be modified?
Yes – both the reload time and disengagement threshold can be modified at any time. Contact your publisher advocate with questions.
Can we implement by piggybacking existing Signal tags?
Potentially – depending on your existing setup and tags used. Please request an evaluation from an Signal implementation engineer.
Who can implement this at the publisher level?
If served through your ad-server, then generally this would be implemented by a member of either the operations or commercial teams. The tag was built so that it could be implemented without the need to request development resources.
