Frequently Asked Questions for //Signal

Last Updated March 11, 2019

//Signal can help your site earn greater ad revenue by delivering more impressions with even fewer ads. Read the most frequently asked questions about //Signal, and get the answers that you need.

How is //Signal implemented?

//Signal is implemented via a single line of script (also known as //Connect) which can be delivered to the page either directly or through third party systems (like through an ad-server or tag management system).

Once on the page, //Signal automatically identifies all ad placements and will apply the pre-defined logic to the appropriate ads that have been selected to run.

How quickly can it be implemented?

Once the //Signal tag is created, the implementation time depends on the method of integration. If through the ad server it can take as little as 5 minutes, but it should work relatively quickly through other integration methods.

Will it require any dev resources?

If served through your ad-server or tag manager, then no, it will not require dev resources. The tag was built so that it could be implemented by commercial ad operations teams without the need to request development resources.

The most that is required to implement a //Signal ad is to hardcode the ad on a page in the site’s head.

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.

Please note that certain ‘add-on’ features, such as specific line item type blocking are currently only supported in DFP Premium and DFP Small Business.

Will all ad types be eligible for //Signal?

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.

Please note that //Signal will not reload any video ads.

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 VET (i.e. sponsorship = no //Signal)
  • If the ad is not permitted to run //Signal, Sovrn will disable the functionality

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. Contact us to get started.

Does it work across mobile?

Yes, //Signal will work across all devices. It looks for specific engagement events based on the device type that is loaded.

Does this only work for standard IAB?

No, //Signal 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 this cause any page latency?

Not at all. The //Connect script is super lightweight (sub 50kb), all decisions around user engagement are happening within the browser itself. 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 should you require.

Why is it 20-30 seconds?

20-30 seconds is default //Signal setting. Both internal, external and independent research has shown that after 20-30 seconds of viewable time there is no additional impact to both performance (CTR, Engagement) and impact (Brand Recall).

Can I restrict this to run in certain geos only?

Yes, you can restrict your ads to run in certain geos.

Can demand partners be blocked from accessing //Sovrn 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 (ie, BSkyB)
  • Category Level (ie, Media & Communications)
  • Buyer Level (ie, MediaCom, Xaxis, GroupM)
  • SSP Level (ie, AppNexus)
Are there multiple types of implementation to choose from?

The recommended implementation is as outlined above via a single line of script delivered to the page. This method provides the publisher the highest level of control with regards to modification of behaviour (i.e., reload rate, disengagement threshold) and blocking of certain ad types.

There are additional implementation types that can be considered, such as DFP creative wrapper, or using a stand alone tag, but these are not common, and should only be considered on a case by case basis.

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, Sovrn will disable the functionality

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.

Learn more about applying exclusions in Signal with the help of this article.

How is //Signal different from other refresh features?

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, or 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 ad viewability and user engagement.

Put simply, //Signal is smarter and more efficient than any other refresh technology out there.

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
    • flip to another screen (if using multiple screens)

Once the ‘focused’ condition has been met, we look at engagement triggers (such as mouse movement, keyboard movement, scrolling, etc.) to determine a user is active.

From an active state and 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, or once the disengagement threshold is met.

When do you determine that a user is no longer engaged?

The disengagement threshold determines the period of time that should be allowed with no engagement events being received before determining the user to be inactive. This setting is customizable, however our standard is 5 seconds.

We are constantly looking to evolve and evaluate this number based on the data we collect on user behavior. It could be that this threshold should be different for each site as each set of users have their unique browsing habits. That is something we can look to address further down the line of our product evolution.

A chart to demonstrate how a user changes from an active to an inactive state via the disengagement threshold.

What metrics combine to generate a //Signal refresh?

//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 is in view 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 45 separate engagement metrics.

Here’s a few of those metrics that Sovrn collects:

  • Mouse movements (like mouse up, mouse down, mouse click)
  • Keyboard movements (like key up, key down)
  • Focus & Blur events (initiated in multiple occasions, for example, when a user flips tab)
  • Touch events (specific to mobile and tablet environments)
How do you measure viewability?

We use the geometric method to measure viewability, which is the industry standard. Click here to see an  in-depth Introduction to Viewability article from AppNexus.

Is //Signal against Google AdSense’s policies?

Broadly speaking, no.

There is nothing in Google’s terms which relate remotely to this practice. In fact, key publishers are already employing similar technology using their ad server (DFP or GAM) and monetizing through their ad exchange (AdX).

In addition, it’s worth noting that DFP has a metric which outlines viewable time of an ad unit, perhaps indicating that they might also enable ads to be traded on viewable time in the future.

Could //Signal be confused with ad fraud?

It is our job to ensure we are clear on how //Signal is different from legacy refresh. Legacy refresh has given the concept of ‘time based selling’ a totally bad reputation. As legacy refresh involves refreshing impression based on no quality thresholds, it has in the past been synonymous with ad fraud.

While legacy refresh is arguably not as severe as other elements of ad fraud, like redirects and other malware, it has nevertheless been a tool that less reputable publishers and networks have benefitted from.

//Signal is not legacy refresh, and it’s far from it. It is a totally innovative solution which helps the industry address an evolving need and rewards publishers which create highly engaging content.

If you’re ready to get started with //Signal ads, contact our Publisher Support team to let them know.

How satisfied are you with this article?

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