What incentivised traffic is
Incentivised traffic (incentivized in US spelling) comes from users who are paid or rewarded for an action, such as installing an app or registering. In a lender's funnel the rewarded action could also be an application. The reward might be in-app currency, points, cashback, gift cards or money. Offerwalls are one common format: Adjust describes an offerwall as an in-app monetisation format that rewards users with virtual currency, features or content for completing advertiser-defined tasks, such as surveys, app installs, subscriptions or creating an account.
Rewarded is not the same as fraudulent. Branch, a mobile attribution vendor, says in its fintech guidance that traffic where users get rewards or cashback for installing an app is not fraud on its own. It becomes fraud when a sub-publisher routes rewarded users into a campaign that does not allow incentives and disguises them as organic-quality acquisition. The advertising standards draw the same line. TAG's draft invalid traffic taxonomy lists the undisclosed use of incentives to make users interact with ads as sophisticated invalid traffic, and excludes incentives known or properly disclosed to the other party. The MRC addendum does likewise for disclosed reward programmes.
These standards are written for advertising measurement. The MRC addendum is mandatory for metrics that MRC or certification auditors audit, and encouraged for other organisations that measure advertising traffic. Use them as shared vocabulary in a contract, not as a compliance test for a lending funnel.
Rewarded traffic can raise counts and lower intent
The reward attaches to a named action, so users do what the reward requires and little else. AppsFlyer argues, in a 2017 analysis, that on offerwall install campaigns most users will likely do only the minimum needed to collect the reward, which lifts vanity metrics more than real engagement. Some rewards are paid further down the funnel, for instance after an account is set up.
Reward apps are a second source of rewarded installs. AppsFlyer describes wallet and get-paid-to apps that give users gift cards or money for downloading many apps, and says that, while not necessarily fraudulent in themselves, they make fraudulent behaviour more appealing to end users.
Branch describes the cost in fintech: the installs come from real devices, but the users have no interest in the product, and downstream they look identical to fake installs. Concealed rewarded traffic burns KYC verification credit on people who were never going to finish onboarding.
If the lender has its own app, store policy is a second exposure. Google Play's policy prohibits manipulating app placement by inflating ratings, reviews or install counts by illegitimate means, names incentivised reviews and ratings among the practices it lists, and tells developers not to use automated services to inflate installs. Whether bought installs to a lender's app breach it depends on how they are generated, so check the full policy before buying them.
Rewarded traffic can distort CPI and cost per application
Cost per install (CPI) and cost per application are ratios, and rewarded traffic can inflate the denominator. When it is in the mix, installs and submitted applications rise while approvals and disbursals do not, so the reported cost per application falls while the cost per disbursed loan can rise. A buyer who optimises to the cheapest application sends more spend to the source with the weakest outcomes. AppsFlyer's warning is that a low CPI is meaningless if users do not engage in a way that meets business goals. The sources cited here document the mechanism for app installs and fintech onboarding; the effect on loan applications follows from the same mechanism and is not a published lending benchmark. AppsFlyer's finance guide adds that fraud in finance apps is most often aimed at registrations or other down-funnel conversions rather than installs.
| Measure | Source A, search | Source B, rewarded |
|---|---|---|
| Spend | 5,000 | 3,000 |
| Installs | 1,000 | 1,000 |
| Install to application rate | 15% | 40% |
| Applications | 150 | 400 |
| Approved | 60 | 40 |
| Disbursed | 45 | 20 |
| Approval rate | 40% | 10% |
| Cost per install | 5.0 | 3.0 |
| Cost per application | 33.3 | 7.5 |
| Cost per disbursal | 111.1 | 150.0 |
Illustrative and fictional: two sources for one lender in one month, in currency units.
Source B wins on cost per install and cost per application, and loses on approval rate and cost per disbursal. A high install-to-application rate paired with a low approval rate is the pattern to look for; see lead quality by source for the full set of measures. The billable event needs the same care. A CPA billed on every submitted application pays for the inflated count. CPD, or a CPA tied to a qualified application or an agreed partner outcome, moves the price closer to the result. See pricing for how billable events are defined.
Signals that point to rewarded traffic
No single metric proves it. Read these together, by source, and over a window long enough for repayment to show. Sub-ids are what make the split by source possible. Sub-source concentration and sub-id hygiene are general fraud and source-transparency checks rather than tests for rewards.
| Signal | What to check | Why it matters |
|---|---|---|
| Install-to-application timing | Time from click to install, and from install to submitted application, by sub-source, against the lender's own baseline. | A reward invites the shortest route to the payout, so unusually short gaps stand out. Branch advises comparing install-to-registration rates against your own baselines rather than universal thresholds; baseline click-to-application time per source in the same way. |
| Completion pattern | How far applicants go after the step that earns the reward: document upload, a second session, repayment set-up. | AppsFlyer points to an unnaturally steep drop in engagement after the first app open, compared with other sources and with other sub-publishers in the same network. |
| Sub-source concentration | Share of volume and of conversion by sub-source, and any source whose rate differs sharply from the rest. | Branch lists abnormal volumes from specific sub-publishers and low install-to-registration rates among the triggers for investigation. |
| Approval and repayment by sub-source | Approval rate, disbursal rate and first-payment default by sub-source, on cohorts old enough to mature. | High application volume with weak approval or repayment is the lending form of the engagement drop. See lead quality by source. |
| Sub-id hygiene | Empty, missing or inconsistent sub-ids on clicks and applications. | A source that hides who is behind the traffic also hides whether rewards are involved. AppsFlyer treats an empty site ID, or one publisher sent under several site IDs, as grounds for blocked installs; the same check applies to a lender's sub-ids. |
A fast application can be a returning applicant with saved details, and a low completion rate can be a weak form, so weigh each signal against the same source's own history and against comparable sources before acting on it. For the session side, see velocity and behavioural signals. For devices that are not real, see emulators and device farms.
Contract controls that keep rewarded traffic out
Detection usually finds a problem after delivery, and often after payment. The contract is where the lender sets what may be bought.
- Disallowed source types. Name offerwalls, rewarded installs, and cashback or points for applying as excluded, or allowed only on a separately labelled campaign with its own target and price.
- Declaration. Require the partner to declare any reward mechanic, including inside a blend of sources, and to name the placement and ad format behind each sub-id. The MRC addendum counts activity from users compensated for visiting as purchased traffic, and says purchased traffic that is unknown to buyers or not declared should be considered for filtration.
- Sub-id transparency. Every click and application carries a sub-id for the real traffic source, passed through unchanged, and empty sub-ids are rejected.
- Data access. Timestamps and device-level data on request, so the lender can cross-check against its own records. Branch advises treating a network that will not provide sub-publisher IDs, device-level data and timestamps as a red flag.
- Outcome-based billing with a validation window. Pay on a qualified application or an agreed partner outcome, hold payment for a defined window, and allow reversal for traffic later found to carry an undisclosed reward.
- Caps and removal. Cap each new source until its outcomes have matured, and keep the right to remove a sub-source and reverse its billing.
Screening complements source rules
Source rules and outcome data come first, because rewarded users are often real people on real devices. CYBERTECH screens applicants against the criteria the lender defines and routes only suitable applicants; the lender keeps the final credit decision. Where the lender returns outcomes by postback, they help tune the checks over time. The terms above suit any acquisition partner; the billable event is defined together with the lender before launch. See how screening works.
Related guides
- Measure loan lead quality by source, from approval to delinquencyHow a lender measures lead quality by source: approval, disbursal, first-payment default, 30+ DPD, fraud rate and cost per disbursed loan.
- Velocity and behavioural signals expose scripted loan applicationsHow velocity windows and form-fill behaviour expose bots and rings, where they misfire on shared devices and networks, and how to tune them.
- Emulators and device farms are found by patterns, not one device checkHow emulators, rooted or cloned devices and device farms appear in loan applications and installs, which signals expose them and what lenders can control.
- Screen loan leads for fraud and fit before they reach youFive checks, including fit to your own criteria, screen applicants before handoff. No single signal decides, and a stopped applicant is not delivered to you.
Sources
- Media Rating Council: Invalid Traffic Detection and Filtration Standards Addendum, June 2020 update (2020)
- Trustworthy Accountability Group: TAG Invalid Traffic Taxonomy, version 2.0 draft (2019)
- Branch: Fake App Installs in Fintech, How To Detect and Prevent Install Fraud (2026)
- AppsFlyer: Rewarded advertising: The good, bad, and ugly (2017, updated 2026)
- AppsFlyer: Measurement and analytics for Finance apps, guide (2025)
- AppsFlyer Help Center: About link structure and parameters (accessed 2026)
- Adjust: What is an offerwall? (accessed 2026)
- Google Play Console Help: User Ratings, Reviews, and Installs (accessed 2026)