Common Cheating Methods in Mobile App Promotion and How to Detect

The previous article introduced some common cheating methods and basic strategies for anti-cheating: Review of Common Cheating Methods: [link]

  1. Click Fraud
  2. Attribution Hijacking
  3. Emulator Simulation
  4. Offer Wall Fraud
  5. Ad Impression Attribution Grabbing

Now let’s discuss some commonly used anti-cheating methods, divided into basic and advanced versions. First, the basic methods:

  1. Conversion Rate Check: Specifically targets click fraud, checking if an entire channel or specific sub-site shows extremely poor click-to-install conversion rates, typically indicating mass click fraud for attribution grabbing. However, due to the combination of multiple cheating methods nowadays, this method is prone to oversight.
  2. CTIT (Click-to-Install Time): The attribution hijack usually involves simulating another click after receiving the application installation successful broadcast, grabbing the last click attribution. Thus, shorter CTIT is often observed. AF’s P360 backend includes CTIT data, but it should be used cautiously for assessment as longer CTIT periods don’t necessarily confirm absence of hijacking; they just indicate a higher likelihood.
  3. New Device Percentage: Also visible in P360 backend, a high percentage of new devices strongly suggests emulator fraud. Note that pre-installed channels or adwords may also show high new device percentages because Google sometimes prioritizes displaying ads on newly purchased devices.
  4. Assist Ratio: If a single channel shows significant assist ratios in its attribution, with high proportions for the first and second assists, it likely involves hijacking—waiting for others to click, download, and install before sending another click. This data is available in AF’s raw logs under “attribution click” (perhaps I remember incorrectly).
  5. Retention Rate Check: Poor retention rates indicate issues—possibly due to fraud, incentivized CPI, or users who don’t match your product’s target audience. Conversely, exceptionally high retention rates should also be treated with caution, as they can be artificially inflated. Longer retention periods like 30 or 90 days might reveal abnormalities, although few examine that far. Retention rates should be analyzed in conjunction with other parameters.
  6. Trend Analysis of Organic and Paid Channels: Observe changes in trends for natural and purchased channels, as well as FB and Google traffic. If hijacking enters the scene, organic and other channel traffic typically plummets while FB account data remains normal—only third-party data collapses. When you notice declining curves, trace back to corresponding periods to investigate the cheating method.
  7. Post-Event Proportion: We often release several events for channel optimization. Even if they cheat to trigger an event, they struggle to accurately simulate subsequent event proportions, crucial for anti-cheating.

These are basic methods for detecting cheating based on third-party data. The usual approach is to first detect anomalies in data, then investigate how the other party cheats, and then…

Next, we’ll introduce more advanced anti-cheating methods, which may require technical support or Excel mastery.

Advanced Methods for Anti-Cheating in Mobile App Promotion

  1. Analysis of All Ad Click Time Intervals: Certain channels may concentrate on silent clicks during late nights or other quiet times. Analyze the intervals of click times and compare them with FB or Google to check for basic alignment.
  2. Analysis of Installation Time Intervals Corresponding to Channels: Silent installations, such as quietly installing and starting after gaining root permissions late at night, then silently deleting. Analyze if the installation time intervals align with proportions seen in other normal channels.
  3. Querying IP Region Distribution of Installations: Channels with traffic from true device brushing may concentrate in very small IP ranges or regions.
  4. Querying Device Operator Distribution of Installations: For example, whether all installations come from China Telecom.
  5. Querying Device Model Distribution: Typically, device brushing sells a large number of low-end devices or uses a single model for device wall true brushing. Issues can be identified through device models.
  6. Querying Routing Nodes: When true device wall brushing, even if the IP is fake, the IP segment will ultimately be concentrated near a base station, and the final network routing node cannot be falsified.
  7. Querying Device Restart Times: Analyzing whether it is a new device, and how long since the last restart, finding a pattern. After all, normal users don’t frequently restart Android devices (apparently the Gaid will change after a restart?), used to prevent device brushing that restarts devices continuously or virtualizes new devices to inflate numbers.
  8. Querying Average Launch Frequency of App on Channel: Analyzing the overall launch time interval and whether it aligns with the app’s expected launch frequency, and how many times it is launched normally in a day. This is generally used for device brushing or script operation.
  9. Distribution of Time Points for Completing Certain Events, IP, Device Model, Operator, etc.: To prevent device brushing or mixed cheating methods such as human device brushing.
  10. Click to Install Time Difference, Installation to Certain Event Time Difference: Preventing scripted device brushing, etc.
  11. Abnormal App Heartbeat Data:
  12. Whether ROI data is normal: And many other proprietary data, in principle, all data, can be taken out to make comparisons with different channels, Facebook, natural volume, google volume, and analyze abnormal conditions. The difficulty is that … processing a large amount of data, the technical implementation is basically too difficult.

These tasks are ideally handled by third parties due to their complexity. Besides accessing individual product data, third parties can also utilize additional product data for supplementary analysis, such as:

  1. Devices that previously installed other apps through Facebook ads, but are now coming from a smaller channel, with Facebook contributing a single assist.
  2. Devices that have installed other apps previously, but show little activity.
  3. Devices that have never installed any apps and remain inactive.
  4. Devices normally active only in Beijing suddenly generating a large number of new installations in Guangzhou or nationwide.

Moreover, they can provide an analysis of overall cheating levels on certain channels:

  1. Installations from this channel are inactive across multiple apps.
  2. This channel’s installations have significant assists across multiple apps.
  3. Installations and activity from this channel are limited to a few base stations.

Implementing these extensive data aggregation and analysis tasks requires substantial computing power and technical expertise. It aims to pinpoint all device levels directly for analysis of which devices are authentic and which channels are likely to contribute attributions (apart from the last click attribution, incorporating more factors). While various third parties may already be engaged in these efforts, overall anti-cheating measures still require significant enhancement.

Leave a Reply

Your email address will not be published. Required fields are marked *