Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

Table of Contents

Account Settings

...

Enabling Optimization will turn on auto-optimization for your supply tag based on the selected performance metrics. Optimization uses a proprietary algorithm to periodically re-prioritize the demand tags in your waterfall based on their performance. For more information on optimization, click here.

What is the difference between a

...

blocklist and

...

an allowlist?

A Whitelist An Allowlist will ALLOW requests from only the domains that appear in the list.

A Blacklist Blocklist will BLOCK all requests from domains on that list.

...

Unclassified domains are those which have low request volume (under 15 requests per hour) but no impressions. These requests do come in and have a chance to be monetized, but at the end of each hour they are compiled into "unclassified" in order for reporting to deal with these long tails. One way to deal with these domains is to talk to your supply partners about the quality of the inventory that they're sending to you. You may want to implement a whitelist an allowlist in order to reduce the number of long-tail domains. You do have the option of running an hourly domain report at the beginning of the hour before domains have been bucketed into unclassified. This will show you domains that have low volume and no impressions for the last hour.

Note that a domain can be unclassified one hour and not unclassified the next. Consider the case where you have 10 requests and no impressions from lowquality.com in the hour between 12 and 1; it will be unclassified. In the next hour, lowquality.com gets 10 requests and 1 impression; it will appear in your domain report as lowquality.com. The 10 requests from the noon hour remain unclassified. For this reason, it is not necessarily best practice to blacklist blocklist domains that get unclassified. They could start out with low volume and no fill and become better performers in the subsequent hours.

...

You can make Mobile Web and In-App tags in SpringServe. In the settings tab of your supply tag, select your desired environment. Mobile web and in-app tags are JS VPAID enabled by default. The tag can be made VPAID none by expanding the Advanced section and selecting None in the VPAID Enabled pillbox. Assign demand tags of type JS VPAID or VAST Only to your mobile tag. Note that you should implement some sort of targeting on your mobile supply tag - we suggest using whitelistallowlist, device and geo targeting.

...

Create your domain list in Targeting → Domain lists. You can add new domains to the text box (comma or newline separated) or you can upload a csv file with your domains. In the Supply tab of your new domain list, you will see all of your supply tags . Mark the box in the first column to apply targeting the domain list to the tag. In the last column, select Blacklist or Whitelist. The . To add more supply tags, click +Supply and select "As Allowlist" or "As Blocklist" from the dropdown. The same procedure is used for the Demand tags in the Demand tabother objects in additional tabs.

2) On the Targeting tab for your tag:

You can also apply domain list targeting on the Targeting tab of supply and demand tags, you can select whitelist allowlist or blacklist blocklist and a domain Lists box will pop up. Enter the name or ID of the domain list.

Note that a tag cannot have both a blacklist blocklist and a whitelistan allowlist. However, you can apply as many domain lists as you like to a single tag.

...

You may be low on your Supply Partner's waterfall. Talk to them to see how you can get to a higher priority. This may entail being put on a whitelist an allowlist and/or having a request cap.

...

SpringServe offers a seamless plug-in for both Pre-bid and Post-Impression detection with various partners. Detection is available on both your supply and demand tags.

Pre-Bid:

  • WhiteOps HUMAN - Desktop, Mobile-web. Could be used for In-app traffic as well. 
  • Protected Media - Available for Desktop, Mobile-web, In-app traffic.  CTV is in beta. Please let your account manager know before activating.
  • SpringServe - Pre-bid based on specific things that SpringServe has come up. Not algorithm based.

Post-Impression:

  • WhiteOpsHUMAN
  • MOAT
  • IAS
  • Protected Media
  • Forensiq

...

SpringServe suggests sampling at least 20% from each post-imp IVT vendor. You could always change the sample rates to find the results you desire. You could also choose your vendor based on the environment of your tag. Protected Media is currently the only vendor available for CTV environmentsFor CTV environments you are limited to Protected Media, Forensiq, or HUMAN.

Which IVT vendor should I use based on the environment of my tags?

For Desktop and Mobile web all IVT vendors could be used. For In-app tags we recommend Forensiq and Protected Media and for CTV the only option is you could decide between Protected Media, Forensiq, or HUMAN.

What percentage of traffic should I validate?

...

How do I select between pre-bid and Post-imp IVT detection?

Pre-bid verification analyzes the request before a bid is even made. It uses previously gathered data alongside real-time machine learning to determine if an ad should even be shown to a user.  Pre-bid IVT filtering is available on both supply and demand tags in SpringServe. Enabling pre-bid on a demand tag protects specific demand sources from IVT, so that you could reduce costs by not running it on your entire supply. Only requests that have been approved by the selected vendors will be passed to the demand tag.

Post-imp verification analyzes the request after the ad has already shown. It allows a user to see where the traffic sources come from and set their own blacklists blocklists and whitelists allowlists according to the data that is found in reports.

...

IVT Metrics show the amount of "invalid" traffic coming through your account measured by different vendors. These metrics are extremely useful for creating blacklists blocklists to block domains with a high frequency of "invalid" traffic. 

...

Please note that the data depends on when our partners make the data available to us. If you see 'zeros' in reporting, it means thats SpringServe does not have the data yet. Data delays for each IVT partner are as follows:

  • White OpsHUMAN - 7 hours
  • Moat - 3 to 9 hours
  • IAS - 12-36 hours
  • Forensiq - 1 full day/24 hours
  • Protected Media - 2 hours

If your tag has a high bot/IVT rate, run a new report with the time range set to Custom spanning 2-3 days, and add the dimension 'Declared Domain' for Desktop and Mobile web, and App Bundle or app name for In-app and CTV campaigns. You could then narrow down the results of the sources with high IVT rates and add them to new or existing blacklistsblocklists.  This can be a blacklist blocklist for the tag specifically, for a supply partner, or a master blacklist blocklist for all of your tags, whatever your preference is. Make sure the blacklist blocklist is implemented in the tag's targeting. 

...

Why are my IVT numbers different between ad servers?

Given that White Ops HUMAN is constantly learning and every account in every platform would be giving them different training data, White Ops HUMAN actually tailors their blocking algorithm per account and per system. So, it's quite plausible that the rules for another ad server are different than the rules for SpringServe.

Why are pre-bid IVT numbers different than post-imp IVT?

White Ops uses HUMAN uses Post-imp detection data to decide what to block in pre-bid. If Post-imp detection was not initially turned on for some tags or only enabled for a short period of time there is little to no detection data available therefore White Ops therefore HUMAN may not have had good enough information to know what to block when pre-bid was enabled.

On this note, we recommend implementing whiteops implementing HUMAN post-bid filtering imp detection on demand tags, because White Ops because HUMAN pre-bid filtering makes its decisions based on past White Ops past HUMAN post impression detection data. White Ops  HUMAN recommends that if a tag has White Ops has HUMAN pre-bid filtering enabled, its White Ops its HUMAN post imp detection is 50% or greater.

...

Pre-bid does not guarantee that IVT impressions will not be served. It uses the information that it has upon request, then makes its assessment. If it passes pre-bid it is possible for it to be determined to be IVT after the impression, when the algorithm has much more information to analyze.

Why is

...

HUMAN prebid stats not available when I add "detected domain" as a dimension?

Blocking requests based on Pre-Bid IVT is only possible if the supply tag has Pre-Bid IVT Blocking enabled in the tag's settings. Pre-Bid blocking happens at the request level.

This data is unavailable for detected domains, because a domain can only be detected if a request is not blocked.

Why don't we see data in our

...

HUMAN reporting console?

Make sure you are clicking on "data sources" at the top of the summary page to toggle accounts.

...

1. DC supply tag does not pass White Ops pass HUMAN blocks and does not get included in the parent waterfall.

In this case we are going to log a White Ops HUMAN attempt but not a usable request to the tag.

2. DC supply tag passes White Ops passes HUMAN blocks and gets included in the parent waterfall.

In this case we will log both a Whiteops HUMAN attempt and an usable request.

What is the difference

...

between HUMAN prebid and HUMAN post-imp?

White Ops (WO) preHUMAN pre-bid filtering uses data from White Ops HUMANs post imp detection to try to predict if the incoming request is IVT or not. Because WO Because HUMAN pre-bid filtering makes its decisions based on past WO past HUMAN post impression detection data, they recommend that if a tag has WO has HUMAN pre-bid filtering enabled, set WO set HUMAN post imp detection with a sample rate of 50% or greater.

...

On the reporting side, you can pull reports and have them emailed to you before you come in to work, you can schedule periodic reports that you can then summarize in ways you want to see, etc. On the optimization side, you can use some of the data in these reports to make waterfall changes based on performance, make budget changes, modify object configurations (like change MOAT percents, Whiteops  HUMAN percents), etc.

The API documentation is a good starting point for your team on making programmatic changes. Below is the link to our API documentation: https://springserve.atlassian.net/wiki/spaces/SSD/pages/12517384/SpringServe+API+SDK.

...