<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=134132097137679&amp;ev=PageView&amp;noscript=1">

Ad Fraud and IVT Detection: Domain and App Spoofing

Amit Shetty
Mar 16, 2022 1:00:00 PM

The Wall Street Journal recently reported that Gannett Co. provided advertisers with misrepresented domain information for nine months. Gannett says the issue was caused by human error and that it has been resolved.

The article has generated multiple discussions in the ad tech industry — and has illuminated certain misconceptions — about ad fraud detection, specifically about domain spoofing and misrepresentation.

We always welcome discussions about the critical issue of ad fraud. This blog post responds to many of the questions we’ve seen and addresses the confusion that has been generated around this topic. (We also gave a primer on app laundering back in 2018 if you want to learn more.)

What are the key takeaways?

  • Pixalate detected and identified the mismatches related to the incident described in the WSJ article. The mismatches were reported in our clients’ Analytics Dashboards.
  • Pixalate’s data science team analyzed its data set for all declared Gannett domains from October 2021 to January 2022 and found a mismatch rate of 1.2%* related to this incident, which did not rise to the level of adding Gannett websites to Pixalate’s domain blocklist.
  • To block actual domain spoofing, which constitutes invalid traffic (“IVT”), on an individual impression-by-impression basis, buyers could use either ads.txt or selective blocking based on sources. However, in the specific case referenced in the WSJ article, the substantial benefits of ads.txt would not have been on display.
    • Although ads.txt is generally effective against spoofing, it would not have been effective in this instance because all the properties involved were owned by Gannett and utilized the same ads.txt identifiers. So the declared domain and real domain had the same Seller IDs in the ads.txt files.
    • The Pixalate Analytics dashboard surfaced the domain mismatches, as well as the sellers associated with those impressions. By way of an example, if the mismatches were reported in Pixalate Analytics as only coming from a small subset of sellers, buyers could use those insights to target away from the impacted domain/seller combinations while still allowing other inventory through from other domain/seller combinations.

Below are some FAQs about this specific instance as well as more information about spoofing as a form of IVT and best practices.

How do MRC guidelines define spoofing?

The Media Ratings Council, Inc. (“MRC”) specifically refers to “spoofing” as a type of sophisticated invalid traffic (“SIVT”) known as “domain laundering;” but “spoofing” is the more common colloquial term used, particularly in the press. (See MRC IVT Guidelines, June 2020.)

Pixalate holds accreditation from the MRC for SIVT detection and filtration. Domain laundering is reflected via Pixalate’s “High risk domain” SIVT type and is one of 40+ types of IVT which Pixalate detects and reports via the Analytics platform.

What is domain and app spoofing?

Domain laundering (often called “spoofing” in the industry) is a form of SIVT that has existed for many years and often plays a critical role in ad fraud schemes, both on websites and within mobile and CTV apps. Pixalate’s CTV ad fraud scheme discoveries of Monarch and DiCaprio, as well as the mobile app scheme discoveries of Megacast and Matryoshka, all involved spoofing.

With domain or app spoofing, the seller masquerades as a different domain or app (if done maliciously, it’s usually done in order to attract buyers at higher CPM values than the underlying real inventory). When the ad is actually rendered, it is on a different, often less-desirable, domain or app — and not the one the buyer expected. In many cases, the malicious party may also combine this deception with the use of bots and other mechanisms to generate higher traffic. 

Did Pixalate identify the domain mismatches?

Yes.

Pixalate has confirmed that our systems properly detected and identified the mismatches related to the incident described in the WSJ article throughout the entirety of the nine month period specified in the article.

analytics-3

This is surfaced to our clients via:

  • Real-time reports in the Pixalate Analytics dashboard (clients can also add source dimensions such as seller/publishers, and can subscribe to view supply path reports as well)
  • Customizable daily emailed automated reports; and
  • Customizable queries in the Pixalate Analytics dashboard to show the declared domain versus the “true” domain.

Additionally, if a large portion of traffic (across customers) from a domain appears to be spoofed, the domain will get marked as a high-risk domain and get included in our pre-bid blocklists. The IVT levels will also be marked in Pixalate’s Media Ratings Terminal (MRT). 

How big is the problem of domain spoofing?

Domain spoofing is not as rampant as it used to be. Much credit for this goes to IAB Tech Lab’s ads.txt standard, which was built specifically to address this issue. With ads.txt, publishers declare the sellers of their inventory along with corresponding Seller IDs. This means that buyers are able to compare the Seller ID on the bid requests with what they see on the ads.txt files to ensure they are buying only from authorized sellers. A bid request from a “spoofer” would not meet this criteria since they will not have the Seller ID from the actual domain’s ads.txt.

However, spoofing does still occur. CTV for example has high “app spoofing” because OS and app store fragmentation is high, with limited app-ads.txt support. In addition, there may be cases where a seller is misrepresenting traffic among their own apps or domains in order to sell lower value inventory as higher value. This would look similar to the instance described in the Gannet incident. There are also valid scenarios where the content may be embedded within other pages, and so the actual domain for the inventory might look different from the declared domain.

For all these reasons, it is important to continue to verify the actual domain and/or app in which the ad was delivered to/rendered within, assess the origins of identified mismatches, and consider this signal regarding whether the traffic constitutes IVT.

How do you identify and stop this type of issue?

The best way to stop the problem of domain spoofing is to correctly implement ads.txt. Publishers should ensure that their ads.txt implementations are correct and up to date (across all their domains). Buyers should verify that the seller ids in the bid request match what the ads.txt file(s) contain.

In addition, ad verification and ad fraud detection companies should verify the domain that the ad is rendered on and not just accept the domain declared by the seller. At Pixalate, we check the actual domain for impressions we measure, and provide both the declared domain and the “true” domain to our customers in the analysis of their data. With such data points, our customers can then slice and dice the data in order to find the source (and the seller) and take appropriate action.

In addition to identifying IVT, it is also important to understand the sellers involved and the supply paths involved in high IVT traffic, which Pixalate has solutions for with the Supply Chain Object and our Supply Path Optimization (“SPO”) reporting capabilities. Most importantly, Pixalate believes in empowering customers with granular data insights to inform and optimize across the digital advertising ecosystem.

*Pixalate measured how often one Gannett site was misrepresented as another Gannett site (i.e. when the discerned true domain did not match the declared domain, and both domains were owned by Gannett). According to Pixalate’s data, 1.2% of all programmatic inventory across Gannett sites were misrepresented in this way from October 2021 through January 2022. Please note that the viewpoints expressed herein do not reflect analysis of all programmatic advertising traffic for any particular domain for any given period, but rather are limited to the subset of that traffic for which one or more of Pixalate’s clients were a buyer or seller during the relevant period.

Disclaimer

Please note that the viewpoints expressed herein do not reflect analysis of all programmatic advertising traffic for any particular domain for any given period, but rather are limited to the subset of that traffic for which one or more of Pixalate’s clients were a buyer or seller during the relevant period.

We use the term “fraud” in this blog post similarly to how the MRC uses it, in that it “is not intended to represent fraud as defined in various laws, statutes and ordinances or as conventionally used in U.S. Court or other legal proceedings, but rather a custom definition strictly for advertising measurement purposes;” and also per the MRC, “'Invalid Traffic' [or “IVT”] is defined generally as traffic that does not meet certain ad serving quality or completeness criteria, or otherwise does not represent legitimate ad traffic that should be included in measurement counts. Among the reasons why ad traffic may be deemed invalid is it is a result of non-human traffic (spiders, bots, etc.), or activity designed to produce fraudulent traffic.”

Search Blog

Follow Pixalate

Subscribe to our blog

*By entering your email address and clicking Subscribe, you are agreeing to our Terms of Use and Privacy Policy.

Subscribe to our blog

*By entering your email address and clicking Subscribe, you are agreeing to our Terms of Use and Privacy Policy.