False positives aren’t an issue for HUMAN malvertising defense. A false positive in our world doesn’t impact revenue since we never block the delivery of the purchased ads; rather, we only block the malicious code that negatively impacts users.
No. All behavior analysis is done at runtime so post-delivery analysis duplicates the work.
Unlike our competitors, our solution doesn’t rely on a blocklist. Our solution is predominantly a behavioral analysis solution. We don’t blocklist or block auctions from completing like the various other market solutions do. We allow the auctions to complete and the original creative that was approved to render (usually a stolen brand ad)—we simply neutralize the malicious behavior.
This allows the publishers to get paid, the user experience to be preserved, and the bad actor to get zero engagement from their buy. We actually make the malicious activity unprofitable for bad actors.
Our primary solution for publishers is a CLIENT-SIDE solution where a single line of JavaScript sits on your page. This solution monitors the execution of JavaScript in runtime when ads are rendering. We also have a solution for SSPs that allows you to inject our script into your ad delivery on a sampled basis.
There is negligible latency added by the HUMAN script. We use a globally distributed content delivery network (CDN) and Edge computing to deliver the script to the page. Once loaded, the script performs real-time behavioral analysis to catch malicious ads, which takes milliseconds to perform.
The optimal location for the HUMAN script is in the <head> HTML tag as a synchronous <script> tag that is placed above any ad calling code (e.g., GPT, Prebid).
This ensures that the script is loaded into memory and available before any ad calls are made, allowing it to inspect each ad for malicious code and ensuring maximum effectiveness.
Implementing the HUMAN script asynchronously can impact its ability to block malicious threats.
If you would prefer to implement the script asynchronously, please reach out to HUMAN Support.
Yes, the HUMAN script has undergone extensive integration testing with the ReactJS front-end framework to ensure compatibility with the framework.
Additionally, we perform quarterly integration testing with the ReactJS framework to ensure compatibility with new versions of ReactJS.
We don’t recommend integrating the HUMAN script within GTM. The reason is that we don’t have any control over when our script loads on the page, so we could load after pre-bid or other ad-related code that is delivered to your site.
When the HUMAN script is loaded after ad-related code, it hurts our ability to effectively block and report on threats.
However, we’re happy to review and give you feedback on a test page with your desired setup.
Mapping is based on a domain name, so you can certainly use one script if that’s easier for you. We would display threat statistics in your dashboard for all domains protected by the script.
We recommend multiple scripts only for organization and ease of use for our publishers. For example, a script can be turned off within the dashboard for one site without removing protection on other sites.
The HUMAN script has a negligible impact on advertisement viewability. We partner with the top MRC-accredited viewability vendors to validate that the HUMAN script doesn’t impact advertisement viewability metrics. Additionally, we perform quarterly validations with these vendors to ensure continued compliance with viewability standards.
Using a 10% sample rate, we collect and report when Chrome browsers block an ad as heavy. Based on the criteria set by Google, an ad is considered heavy and blocked by Chrome-family browsers, if it hasn’t been interacted with (e.g., clicked or tapped) and meets one of the following:
VAST/VPAID ads are mostly exempt from this, as this only applies to banner and native formats.
Mitigation shouldn’t be necessary unless the dashboard percentage grows larger than 2%. Users are protected by the browser and revenue isn’t impacted, So even above-average levels are acceptable.
Over 2% is an indication of a possible site issue, problem with a custom ad format, or site content erroneously blocked because it’s being classified as an ad. This should be investigated and we’re here to support those efforts.
Ads may not get flagged as heavy until well after being served, making it difficult to trace them back to responsible platforms. Also, Chrome sometimes blocks non-ads, with no identifiable ad platform.
The average dashboard percentage is .01%, but ranges up to .2% are quite common. Percentages are based on page views and will vary significantly among sites due to differences in number of ads per page and page dwell time.
For publishers who operate their own sites, this gives meaningful insight to changes in heavy ad volumes to understand how often ads are being blocked and possibly from whom. This isn’t because they don’t want to protect users but because a page littered with broken ad messaging creates a poor user experience and reflects poorly on the site. Please note that usually, publishers still get paid for these ads so there’s not an associated loss of revenue.
Yes. This is available on the Deployments tab in the dashboard.
Yes, navigate to the Deployments tab in the dashboard to rename.
Threat Level Value is calculated by dividing the total number of page views by the number of malvertising attacks prevented, over a period of time.
This is the beauty of our product. You don’t need to reach out to SSPs. Our goal is to provide maximum protection with no ongoing management. Our solution blocks the malicious redirect but doesn’t impact revenue or the user experience. We make it as simple as possible for our partners so you don’t have to reach out to SSPs and can focus on your business.
We’re regularly enhancing our offensive technology to ensure our clients are protected. Our deployments are scheduled based on the release type. Deployments are executed on a multi-tier basis to ensure our team can properly monitor, QA, and confirm each successful deployment. Our tiered approach allows us to partner with trusted publishers to ensure everything is working as expected before moving to the next tier. Our engineering team has a strict pre-release and post-release test plan that validates multiple data sets in real time. Our customers are our most valued asset and protecting them flawlessly is our number one priority.
The threat network grows with each attack we see. There may be times when tying threats to the ad source may not be immediately possible based on threat architecture and ad path. Our team is continually working to attribute threats where possible.
There are many different browsers across both desktop and mobile devices. In order to provide you with the most useful information, we classify each browser uniquely and avoid roll ups where possible. For example, Safari Mobile would be the Safari app on your iOS device. But Safari Mobile In-App would be the webview of that browser being used if you opened a link while you were using another iOS app—like a game.
While we strive for 100% protection, the bad actors are constantly developing new, innovative methods of attack. We take a real-time, behavioral approach to protecting sites (not just a blocklist), but even this requires tweaking to stop attacks at the root of the problem.
If a user has reported an issue, please capture as much information as possible and send a message to malvertising-support@humansecurity.com. Ideally, user info should include:
Also, if a screenshot and/or network log (e.g. Charles .har log) is available, please collect this as well.
You can also submit tickets via the dashboard by selecting Need Help in the left-hand navigation.