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.
- 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.
- Protected Media
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. For CTV environments you are limited to Protected Media, Forensiq, or WhiteOps 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 you could decide between Protected Media, Forensiq, or WhiteOps HUMAN.
What percentage of traffic should I validate?
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
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.
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 a 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.