Skip to content
  • There are no suggestions because the search field is empty.

High Risk Mobile Apps (Version 2.0) - Standard and Enterprise (Beta)

Overview

High Risk Mobile Apps 2.0 Standard and Enterprise (Beta) are mobile app blocklists that identify known dangerous and fraudulent sources by combining high historical IVT rates, app store compliance signals, app-ads.txt compliance, and privacy risk indicators into a unified feed with transparent risk reason codes.

Apps are evaluated across multiple risk dimensions including IVT rates, app store compliance, developer transparency, and inventory quality signals. Apps are included on the list when app-level blocking is the appropriate control — meaning impression-level filtering cannot reliably isolate valid traffic from invalid traffic.

Each app on the list is tagged with one or more risk reason codes, providing transparency into the specific signals that triggered inclusion.

Risk Types

Risk Type

Code

Description

High GIVT

highGivt

Apps with General Invalid Traffic rates exceeding 5% over a 3-month rolling window

High SIVT

highSivt

Apps with Sophisticated Invalid Traffic rates exceeding 15% over a 3-month rolling window

Missing Privacy Policy

missingPrivacyPolicy

Apps missing mandatory privacy policies required by Google Play and Apple App Store

Abandoned App

abandonedApp

Apps that have not been updated by developers for 3+ years and may be unmaintained, insecure, or non-compliant with current app store requirements

Missing app-ads.txt

noAppTxt

Apps generating ad impressions without a valid app-ads.txt file, indicating unauthorized inventory

Developer Anonymity

developerAnonymity

Apps where the developer has missing or unverifiable contact information

VPC Bypass Risk

vpcBypass

Child-directed apps transmitting IP or location data without Verifiable Parental Consent, creating COPPA compliance exposure

Delisted App

delistedApp

Apps removed from app stores that continue to generate ad traffic

Made for Advertising

mfaApp

Apps designed primarily to generate ad impressions rather than deliver genuine user value, including apps exhibiting ad stacking and other manipulative ad placement tactics


File Format and Delivery

Attribute

Value

File Format

CSV

Delivery Method

FTP or S3 Bucket

Naming Convention

MobileHighRiskAppSelection_YYYYMMDD

Update Frequency

Daily


Schema

High Risk Mobile Apps 2.0 Standard and Enterprise (Beta) evaluate each app against nine risk dimensions. An app can be flagged for multiple risk types simultaneously — for example, an app may be both abandoned and missing a privacy policy.

The probability field is set to 1 for all entries. High Risk Mobile Apps 2.0 (Beta)  uses deterministic inclusion criteria — an app either meets the threshold for a risk type or it does not.

High Risk Mobile Apps 2.0 Standard (Beta)

In Version 2.0 Standard (Beta), when an app has multiple risk types, the riskType field displays the string value "various".

Column

Type

Description

appId

STRING

The identifier for the mobile app (e.g., "310633997" or "com.whatsapp")

bundleId

STRING

The bundle ID associated with the app, if available

osName

STRING

The operating system associated with the app (iOS or Android)

riskType

STRING

Risk type code; displays the string value "various" when multiple risk types apply

probability

FLOAT

Value of 1 for all entries

appStoreUrl

STRING

URL to the app store listing

appStoreName

STRING

Name of the app store (Google Play or Apple App Store)


High Risk Mobile Apps 2.0 Enterprise 
(Beta)

High Risk Mobile Apps 2.0 Enterprise (Beta) provides full granularity by listing all applicable risk types as comma-separated values (e.g., highSivt,abandonedApp,missingPrivacyPolicy) instead of displaying various. This enables you to build custom blocking logic based on specific risk type combinations.

Column

Type

Description

appId

STRING

The identifier for the mobile app (e.g., "310633997" or "com.whatsapp")

bundleId

STRING

The bundle ID associated with the app, if available

osName

STRING

The operating system associated with the app (iOS or Android)

riskType

STRING

Comma-separated list of all applicable risk types

appStoreUrl

STRING

URL to the app store listing

appStoreName

STRING

Name of the app store (Google Play or Apple App Store)

Contact your Customer Success representative to upgrade to High Risk Mobile Apps 2.0 Enterprise (Beta).

Note: Access to High Risk Mobile Apps 2.0 Standard (Beta) requires acceptance of an updated Master Service Terms (MST). Access to the Enterprise (Beta) version requires an upgrade to your subscription. Contact your Customer Success representative for details.

Integration Recommendations

Pre-bid blocking: When blocking apps from this list, use appId + osName at minimum to ensure you block the correct app. For greater precision, use appId + bundleId + osName.

Risk-based filtering: Use the riskType field to implement selective blocking based on your risk tolerance. For example, you may choose to block only apps flagged for highSivt or mfaApp while permitting apps flagged solely for abandonedApp.

Frequently Asked Questions

How should I use the App ID, Bundle ID, and OS columns?

When blocking an app, use appId + osName at minimum. This prevents inadvertently blocking an app on a different operating system that shares the same identifier. For better precision, include bundleId as well.

Why do some apps appear on the list and then disappear?

Apps are evaluated using a rolling lookback window. If an app's risk indicators improve over time (e.g., IVT rates fall below thresholds), the app will age off the list for that particular risk type. However, an app that ages off may be re-added in the future if risk indicators resurface, or may be flagged for different risk types.

What is the difference between High Risk Mobile Apps 2.0 Standard (Beta) and Enterprise (Beta)?

High Risk Mobile Apps 2.0 Standard (Beta) maintains backward compatibility with existing integrations by showing a single risk type value (or various for multiple) and includes a probability field. High Risk Mobile Apps 2.0 Enterprise (Beta) provides full granularity with comma-separated risk type codes and removes the probability field.

How can an app be removed from the list?

Apps are automatically removed when they no longer meet the inclusion criteria for any risk type. For IVT-based risk types, this occurs when IVT rates fall below thresholds over the lookback period. For compliance-based risk types (e.g., missingPrivacyPolicy, abandonedApp), removal occurs when the app resolves the underlying issue.

How does this list relate to IVT reporting in Analytics?

Impressions from apps on this list are not automatically classified as IVT. The MRC's Invalid Traffic Detection and Filtration Interim Update Memo emphasize that IVT measurement should occur at the traffic level, distinct from app-level risk assessment. High Risk Mobile Apps 2.0 (Beta) aligns with this guidance by separating app-level risk signals from impression-level IVT classification.

If an app is on this list, does that mean the app is flagged for IVT?

Not necessarily. Apps on the list may be present due to reasons that may or may not include IVT risk. There are a couple of risk types that are IVT-related (highGivt and highSivt) but High Risk Mobile Apps 2.0 (Beta) also identifies apps that could present other types of risk (e.g., app store compliance, developer transparency, and inventory quality signals).

What data sources are used to compile this list?

Pixalate collects data from various sources to compile the list, including traffic data, third-party data, and app store metadata.

I work directly with a publisher on this list. What should I do?

The list provides app-level risk signals based on observed data across the ecosystem. If you have a direct relationship with a publisher and have visibility into their traffic quality, you may choose to use the risk type codes to make informed decisions about which risk types to block based on your risk tolerance and business requirements.


Related Resources

Contact

For questions about High Risk Mobile Apps 2.0 (Beta), contact your Customer Success representative or reach out to support@pixalate.com.