Pixalate announced the launch of its High‑Risk Apps (HRA) mobile‑app pre‑bid blocklist, a daily‑updated feed that identifies iOS and Android applications deemed dangerous or fraudulent. The service aggregates persistent invalid‑traffic signals, app‑store compliance checks, app‑ads.txt verification, and privacy‑risk indicators into a single list that can be applied before a bid is placed in real‑time bidding environments.
A new layer of protection for programmatic buyers
Programmatic fraud detection has traditionally relied on evaluating each impression in isolation, often missing broader patterns that emerge at the app level. Pixalate’s blocklist aligns with the Media Rating Council’s recommendation to supplement impression‑level invalid‑traffic (IVT) measurements with curated lists of known risky sources. By offering a pre‑bid filter, the HRA feed enables advertisers, agencies, and platforms to exclude entire applications rather than reacting after an impression has been served.
Nine distinct risk categories
Each app in the blocklist is examined against nine separate risk dimensions. An application may carry multiple tags simultaneously, allowing buyers to fine‑tune their blocking logic. The risk codes and their definitions are:
| Risk Type | Code | Definition |
|---|---|---|
| High GIVT | highGivt | General Invalid Traffic rate above 5 % over a rolling three‑month window |
| High SIVT | highSivt | Sophisticated Invalid Traffic rate above 15 % over a rolling three‑month window |
| Missing Privacy Policy | missingPrivacyPolicy | No privacy policy that satisfies global regulations or the guidelines of Google Play and the Apple App Store |
| Abandoned App | abandonedApp | No developer updates for three years or more, indicating possible neglect or non‑compliance |
| Missing app‑ads.txt | noAdsTxt | Generates ad impressions without a valid app‑ads.txt file, suggesting unauthorized inventory |
| Developer Anonymity | developerAnonymity | Developer contact information is absent or cannot be verified |
| VPC Bypass Risk | vpcBypass | Likely child‑directed app that transmits IP or location data without Verifiable Parental Consent, exposing the app to COPPA‑related risk |
| Delisted App | delistedApp | Removed from the official app store yet continues to serve ad traffic |
| Made for Advertising | mfaApp | Built primarily to generate ad impressions rather than deliver user value, often employing ad stacking or similar tactics |
The presence of multiple tags on a single app gives buyers the flexibility to, for example, block only those flagged for high SIVT while still allowing apps that are merely abandoned.
Separating app‑level risk from impression‑level IVT
The HRA blocklist treats structural app risk and impression‑level invalid traffic as separate signals. Under the Media Rating Council’s “Invalid Traffic Detection and Filtration Interim Update Memo,” property‑level risk reporting is distinct from the measurement of invalid impressions. Consequently, an app appearing on the blocklist does not automatically label its impressions as IVT. Only when the underlying impression exhibits invalid characteristics will IVT be reported, preserving the integrity of both metrics.
Practical applications for SSPs, exchanges, DSPs and agencies
Supply‑side platforms and exchanges can use the blocklist to:
- Remove inventory where IVT is entrenched and inseparable from legitimate traffic.
- Apply selective blocking based on individual risk codes, tailoring decisions to their risk appetite and publisher relationships.
- Present app‑level risk data independently of impression‑level IVT, keeping measurement accuracy intact.
Demand‑side platforms and agencies gain the ability to:
- Pre‑bid filter by excluding specific App IDs from campaign targeting.
- Mitigate regulatory exposure by blocking apps flagged for missing privacy policies, VPC bypass risk, or delisting.
- Protect brand safety by avoiding “Made for Advertising” apps, abandoned apps, and those with unverifiable developers.
Technical delivery and data schema
The blocklist is distributed as a CSV file refreshed daily. Delivery options include Pixalate’s AWS RTB Fabric, REST APIs, FTP, or an S3 bucket—allowing seamless integration with existing pre‑bid infrastructure. The feed’s schema comprises the following fields:
| Column | Type | Description |
|---|---|---|
| appId | STRING | Unique identifier for the app (e.g., “310633997” or “com.whatsapp”) |
| bundleId | STRING | Bundle identifier, when available |
| osName | STRING | Operating system—iOS or Android |
| riskType | STRING | Comma‑separated list of applicable risk codes (e.g., highSivt,abandonedApp,missingPrivacyPolicy) |
| appStoreUrl | STRING | Direct link to the app’s store listing |
| appStoreName | STRING | Store name—Google Play or Apple App Store |
In addition to the raw feed, Pixalate surfaces a boolean flag in its analytics dashboard indicating whether an app appears on the HRA list, alongside a share‑of‑voice metric that quantifies traffic volume originating from flagged apps.
Why the timing matters
Programmatic advertising continues to expand across mobile, connected TV, and web environments, but fraudsters are increasingly targeting the app ecosystem. The rise of “made‑for‑advertising” apps and the persistence of sophisticated bots have pressured industry bodies like the MRC to call for more proactive safeguards. Pixalate’s blocklist arrives as a concrete response to those calls, offering a data‑driven method to keep risky inventory out of the bidding pool before any spend occurs.
Analyst perspective
According to several independent observers, the shift from reactive IVT detection to proactive app‑level exclusion represents a maturing of the ad‑tech fraud‑prevention stack. By providing nine discrete risk signals, Pixalate gives buyers the granularity needed to align blocking strategies with internal compliance policies and brand‑safety thresholds. The daily refresh cadence also ensures that newly compromised or delisted apps are captured quickly, reducing exposure windows.
Disclaimer
The information presented reflects Pixalate’s viewpoints on factors it believes are relevant to the digital‑media sector. All data is derived from Pixalate’s proprietary analytics platform, which undergoes continuous refinement. References to external sources are not endorsements, and the statements should be regarded as opinions rather than definitive facts or guarantees. The release does not intend to damage the reputation of any entity, individual, or application; its purpose is to convey observed trends within programmatic advertising.
Per the Media Rating Council, “fraud” in this context follows a custom definition for advertising measurement, distinct from legal definitions of fraud. “Invalid traffic” is defined as traffic that fails to meet quality or completeness standards, including non‑human activity or deliberately deceptive practices.
data programmatic advertising platforms content strategy
Get in touch with our Adtech experts
