To ensure optimal traffic integrity and maximize campaign perf, TyrAds employs a multi-layered security system for our SDK partners.
Fraud Suite v2 Documentation:
Layer 1: User Risk Scoring (Proactive): An automated system that scores every user at the moment they enter the SDK. Using 200+ data sources (including device fingerprints, location, and multi-accounting patterns), it blocks "High Risk" users before they can engage with any offers.
Layer 2: Anomaly Detection (Reactive): A machine-learning system that monitors in-game activity. If a user bypasses Layer 1 but exhibits abnormal behavior patterns, their progress is rejected in real-time.
Our system analyzes post-install event patterns. If a user’s behavior is flagged as non-human or anomalous, the system triggers an automatic rejection.
Standardized Lookback Rules:
14-Day Window: All conversions are subject to a 14-day lookback window, aligning with industry MMP standards.
CPI Model: If an anomaly is detected within 14 days, both the install and all associated events are retroactively rejected.
CPE Model: The specific anomalous event is rejected, and the user is flagged to prevent all future payouts on that campaign.
Post-14 Days: The initial install remains approved, but specific anomalous events are rejected and non-payable.
If you needed to be notified on the rejections to your platform, please do consult Tyrads team to setup a rejected type Postback URL [especially for CPI campaigns where we retroactively reject the install together with the event and make the install non-payable as well]
The following are the important macros for rejected type postback:
{conversion_status}
The state of conversion
rejected
{reject_reason}
The rejection reason for the conversion
Anomoly%20Detection
{conversion_id}
Unique ID of a specific conversion
2563391781
Example of suggested rejected postback URL:
https://your-api-endpoint.com/postback?id={conversion_id}&conversion_status={conversion_status}&reject_reason={reject_reason} + all existing macros setup in Ad Unit that is required
Rejected postback Integration Checklist
Please do not reward the user upon receiving the rejected type postback if implementation of rejected postback is required.
Last updated
