[{"data":1,"prerenderedAt":25},["ShallowReactive",2],{"article:en:organic-traffic-in-arbitrage-android-ios-apps":3},{"id":4,"locale":5,"title":6,"seoTitle":6,"description":7,"dateLabel":8,"dateValue":9,"slug":10,"metaDescription":11,"keywords":12,"ogTitle":20,"ogDescription":21,"ogImageTitle":22,"bodyMarkdown":23,"bodyHtml":24},"organic-traffic-in-arbitrage-apps","en","\"Organic Traffic\" in Arbitrage Apps: Bonus or Shave?","A closer look at what app rental services mean when they say organic traffic lets them provide apps for free: is it simple shaving, or a side effect of ASO?","26.04.2026","2026-04-26","organic-traffic-in-arbitrage-android-ios-apps","What is organic traffic in arbitrage Android and iOS apps: does real organic traffic exist, or are app rental services simply shaving traffic?",[13,14,15,16,17,18,19],"organic traffic in apps","shave","traffic arbitrage apps","app rental","attribution","Android apps","iOS apps","Organic Traffic in Arbitrage Android and iOS Apps","What app rental services call organic traffic, and whether it is shaving or a real ASO effect.","What Is Organic Traffic in Arbitrage Apps","Today, many app rental services for traffic arbitrage offer their apps very cheaply, or even for free. A relatively new market player, [\"Banda Apps\"](/en/service/banda-apps/), made this its signature move and surprised many competitors enough that some of them soon switched to a free model as well. The explanation is simple: rental services used to be greedy and charged for every install, but on top of rental fees they had supposedly always been earning from organic traffic. The story goes like this: app stores see that traffic to an app keeps growing, start promoting it in recommendations, and the rental service monetizes that extra traffic for itself.\n\nIt sounds tidy, of course, but in practice organic traffic in arbitrage apps has to be viewed together with two neighboring topics: attribution loss and plain shaving, meaning traffic theft.\n\n## What organic traffic means in apps\n\nIn the classic sense, organic traffic means installs from Google Play or the App Store that are not tied to an ad campaign. They appear when a user finds the app through search or recommendations.\n\nFor a rental service, this can be a legitimate revenue source. For the renter, the question is different: is the service taking valuable traffic under the label of organic traffic or technical discrepancies?\n\nReal ASO-driven organic traffic requires several things to line up: clear search demand, a relevant app name, a store page that converts, stable app lifetime in the store, and enough install volume. Arbitrage apps usually struggle with this. They rarely look like normal ASO products. They need to live longer, pass moderation, and avoid looking too obvious. That is why direct game or brand names are often replaced with name variations, calmer graphics, and avoidance of obvious keywords in metadata.\n\nThe main conclusion is simple: organic traffic is possible, but it should not be taken on faith just because a service calls part of the traffic organic.\n\n## Why organic traffic is hard to verify\n\n> First, it is worth noting that this article is only about native apps and naming-based traffic buying: the type of traffic where attribution is handled through MMP systems such as AppsFlyer, Adjust, and others.\n\nThe issue is the traffic route and the way modern ad networks work:\n\n1. The user sees an ad creative. At that moment, the ad network sends an \"impression\" event to the MMP. Along with that event, the MMP receives information about the user, but not about the ad campaign.\n2. The user clicks the ad and installs the app. At the same time, the MMP receives a \"click\" event, with information similar to step 1.\n3. The user launches the app. The MMP module integrated into the app, or into the rental service backend, sends install information to the MMP backend for matching.\n4. The MMP asks traffic sources to confirm the install and provide click/impression data, because most traffic sources, such as Meta, Google, and TikTok, are SRNs — Self-Reported Networks. They decide themselves whether an install belongs to one of their ad campaigns. You can read more about this in [\"Ad Platforms vs MMP vs First-Party Data\"](https://www.airbridge.io/en/blog/why-mobile-attribution-numbers-dont-match-ad-platforms-vs-mmp-vs-first-party-data).\n5. After receiving the data, the MMP returns information to the rental service.\n\n\u003Cfigure class=\"md-figure\">\n\u003Cimg class=\"md-figure__image\" loading=\"lazy\" decoding=\"async\" src=\"https://raw.githubusercontent.com/trafficarts/static/refs/heads/main/attribution_flow_uml_en.svg\" alt=\"Traffic route in mobile attribution: impression, click, MMP, SRN, and app\" style=\"padding-left:0;padding-right:0;\">\n\u003Cfigcaption class=\"md-figure__caption\">Traffic route in mobile attribution: impression, click, MMP, SRN, and app\u003C/figcaption>\n\u003C/figure>\n\nStep 4 can take quite a long time. MMP documentation usually avoids this detail carefully, although [AppsFlyer states](https://www.appsflyer.com/glossary/mmp/) in its marketing materials that real-time attribution exists. But \"real-time\" on a marketer's dashboard and \"real-time\" for naming in arbitrage are very different things: in practice, attribution can take 5 or 20 seconds, and sometimes several minutes. **Will the app keep showing a loading screen until the very end, waiting for attribution and risking the loss of a conditionally \"organic\" install?**\n\nSo when a service explains a low app price with \"organic traffic\", it is worth asking for details:\n\n* which queries bring organic installs to the app;\n* whether the renter can see an install log for their naming on the rental service side;\n* whether the renter can see organic traffic reports from the MMP;\n* who monetizes unattributed users, and how;\n* how the app behaves if it did not receive install attribution during the first launch, but attribution appears by the next opening;\n* whether it is possible to buy out organic traffic for the needed GEOs.\n\nIf there are no answers, that does not prove fraud. But it does mean the rental service is not showing all its cards.\n\n## Organic, default, and mistracking are not the same\n\nIt is important to separate several different flows.\n\n**Organic traffic** — the user found the app in the store and installed it without ads.\n\n**Default traffic** — users whom the routing or attribution system could not confidently connect to a specific renter, buyer, or campaign.\n\n**Mistracking** — a technical attribution error: the click, install, or opening happened, but the tracker, MMP, app, or intermediate logic did not connect the events correctly.\n\n**Naming mistakes** — a separate topic outside this article, but a common one. Always check that naming is filled in correctly, and ideally test the naming-based routing yourself.\n\n**Normal discrepancies** — the natural difference between the ad account, tracker, MMP, store, and internal stats. Such discrepancies happen even in clean white-hat products and do not always mean someone is taking traffic. For example, two ad networks can claim the same install on different grounds: the install may have happened after a Google ad click and been attributed as click-through, while earlier the user had seen an Instagram ad for the same product, so the install also received view-through attribution. The MMP then deduplicated the events and selected only one source according to its settings.\n\nThe problem in the app rental market is that these flows are often hidden from the renter. You see that some users did not reach your stats, and then the question becomes interpretation: is it real organic traffic, default traffic, attribution loss, or shaving of your traffic?\n\n## Can 100% of traffic be attributed?\n\nNo. In practice, 100% attribution is unreachable.\n\nThe reasons vary: event delays, iOS restrictions, SKAN, browser transitions, redirects, VPNs, anti-fraud systems, user behavior after install, SDK errors, naming-logic issues, caching, and ordinary integration failures. Even if the rental service works honestly, part of the traffic will still be lost or fall into an undefined flow.\n\nSo the correct question is not \"are there losses\", but \"what level of loss is normal for my setup\". That level can differ between Android and iOS. It can also differ by source, GEO, and campaign type.\n\nIf you lose a few percent on small volume, that may be ordinary technical reality. If losses become double-digit on stable volume and repeat in the same pattern, it is time to dig deeper.\n\n## How to measure losses\n\nStart with measurement, not accusations. The minimum set:\n\n1. Compare data from the traffic source, tracker, MMP, and rental service stats.\n2. Look at Android and iOS separately, because attribution and restrictions differ.\n3. Break data down by GEO, source, campaign, and buyer.\n4. Test naming and routing on small controlled campaigns.\n5. Compare the share of unattributed traffic across different services with a similar buying structure.\n\nIt is important to look not only at percentages, but also at money. If turnover is small, even unpleasant discrepancies can be cheaper than in-house development. If turnover is large, the same 5-10% becomes a number you can no longer ignore.\n\nSeparately, ask services about default traffic: whether it exists, who monetizes it, whether the needed countries can be bought out, whether there is a fixed daily price, and what reports are available.\n\n## What alternatives exist\n\nApp rental remains convenient: fast, understandable, and free from the need to maintain your own development team or deal with publishing problems. But if the economics run into attribution loss, alternatives appear.\n\n* First — a private app for one team. It is more expensive, but gives more control over traffic, naming logic, and default monetization. Unfortunately, rental services rarely agree to such terms, and this is not necessarily because shaving is attractive. It is also because an app usually earns more when rented out.\n\n* Second — buying out default traffic for the needed GEOs. This can be a compromise if the service is ready to sell that flow transparently, and such services [exist in the catalog](/en/catalog/?organicAndroid=yes).\n\n* Third — in-house development. It gives maximum control, but requires money, people, accounts, design, publishing, support, and constant app replacement. Most importantly, it requires expertise, which is acquired through your own trial and error, and not for free. For many teams, this is not savings but a new headache.\n\n* Fourth — PWA. A PWA has no store and no classic app attribution, so some problems disappear. Other limitations appear instead: fewer system capabilities, weaker bot filtering, and lower trust compared with a native app.\n\nSometimes the best option is to change nothing. If you need many apps for in-app, UAC, or testing, and your volume does not yet justify your own infrastructure, rental can remain rational even with inevitable losses.\n\n## What comes next\n\nOrganic traffic in arbitrage apps is not a myth, but it is not a universal explanation for low prices either. The cheaper a service gives away Android or iOS apps, the more closely you should look at traffic loss volume.\n\nWhen choosing a service, it is useful to compare not only rates and platforms, but also transparency: what happens to unattributed traffic, what reports are available, whether default traffic can be bought out, how routing is structured, and what losses are considered normal.\n\nFor an initial comparison, you can use the [app rental services catalog](/en/catalog/), but the final decision should still be made from your own numbers after comparing several services.\n","\u003Cp>Today, many app rental services for traffic arbitrage offer their apps very cheaply, or even for free. A relatively new market player, \u003Ca href=\"/en/service/banda-apps/\" target=\"_blank\" style=\"color:#333; text-decoration: underline;\" rel=\"noopener\">\"Banda Apps\"\u003C/a>, made this its signature move and surprised many competitors enough that some of them soon switched to a free model as well. The explanation is simple: rental services used to be greedy and charged for every install, but on top of rental fees they had supposedly always been earning from organic traffic. The story goes like this: app stores see that traffic to an app keeps growing, start promoting it in recommendations, and the rental service monetizes that extra traffic for itself.\u003C/p>\n\u003Cp>It sounds tidy, of course, but in practice organic traffic in arbitrage apps has to be viewed together with two neighboring topics: attribution loss and plain shaving, meaning traffic theft.\u003C/p>\n\u003Ch2>What organic traffic means in apps\u003C/h2>\n\u003Cp>In the classic sense, organic traffic means installs from Google Play or the App Store that are not tied to an ad campaign. They appear when a user finds the app through search or recommendations.\u003C/p>\n\u003Cp>For a rental service, this can be a legitimate revenue source. For the renter, the question is different: is the service taking valuable traffic under the label of organic traffic or technical discrepancies?\u003C/p>\n\u003Cp>Real ASO-driven organic traffic requires several things to line up: clear search demand, a relevant app name, a store page that converts, stable app lifetime in the store, and enough install volume. Arbitrage apps usually struggle with this. They rarely look like normal ASO products. They need to live longer, pass moderation, and avoid looking too obvious. That is why direct game or brand names are often replaced with name variations, calmer graphics, and avoidance of obvious keywords in metadata.\u003C/p>\n\u003Cp>The main conclusion is simple: organic traffic is possible, but it should not be taken on faith just because a service calls part of the traffic organic.\u003C/p>\n\u003Ch2>Why organic traffic is hard to verify\u003C/h2>\n\u003Cblockquote>\n\u003Cp>First, it is worth noting that this article is only about native apps and naming-based traffic buying: the type of traffic where attribution is handled through MMP systems such as AppsFlyer, Adjust, and others.\u003C/p>\n\u003C/blockquote>\n\u003Cp>The issue is the traffic route and the way modern ad networks work:\u003C/p>\n\u003Col>\n\u003Cli>The user sees an ad creative. At that moment, the ad network sends an "impression" event to the MMP. Along with that event, the MMP receives information about the user, but not about the ad campaign.\u003C/li>\n\u003Cli>The user clicks the ad and installs the app. At the same time, the MMP receives a "click" event, with information similar to step 1.\u003C/li>\n\u003Cli>The user launches the app. The MMP module integrated into the app, or into the rental service backend, sends install information to the MMP backend for matching.\u003C/li>\n\u003Cli>The MMP asks traffic sources to confirm the install and provide click/impression data, because most traffic sources, such as Meta, Google, and TikTok, are SRNs — Self-Reported Networks. They decide themselves whether an install belongs to one of their ad campaigns. You can read more about this in \u003Ca href=\"https://www.airbridge.io/en/blog/why-mobile-attribution-numbers-dont-match-ad-platforms-vs-mmp-vs-first-party-data\" target=\"_blank\" style=\"color:#333; text-decoration: underline;\" rel=\"noopener\">\"Ad Platforms vs MMP vs First-Party Data\"\u003C/a>.\u003C/li>\n\u003Cli>After receiving the data, the MMP returns information to the rental service.\u003C/li>\n\u003C/ol>\n\u003Cfigure class=\"md-figure\">\n\u003Cimg class=\"md-figure__image\" loading=\"lazy\" decoding=\"async\" src=\"https://raw.githubusercontent.com/trafficarts/static/refs/heads/main/attribution_flow_uml_en.svg\" alt=\"Traffic route in mobile attribution: impression, click, MMP, SRN, and app\" style=\"padding-left:0;padding-right:0;\">\n\u003Cfigcaption class=\"md-figure__caption\">Traffic route in mobile attribution: impression, click, MMP, SRN, and app\u003C/figcaption>\n\u003C/figure>\n\n\u003Cp>Step 4 can take quite a long time. MMP documentation usually avoids this detail carefully, although \u003Ca href=\"https://www.appsflyer.com/glossary/mmp/\" target=\"_blank\" style=\"color:#333; text-decoration: underline;\" rel=\"noopener\">AppsFlyer states\u003C/a> in its marketing materials that real-time attribution exists. But "real-time" on a marketer's dashboard and "real-time" for naming in arbitrage are very different things: in practice, attribution can take 5 or 20 seconds, and sometimes several minutes. \u003Cstrong>Will the app keep showing a loading screen until the very end, waiting for attribution and risking the loss of a conditionally "organic" install?\u003C/strong>\u003C/p>\n\u003Cp>So when a service explains a low app price with "organic traffic", it is worth asking for details:\u003C/p>\n\u003Cul>\n\u003Cli>which queries bring organic installs to the app;\u003C/li>\n\u003Cli>whether the renter can see an install log for their naming on the rental service side;\u003C/li>\n\u003Cli>whether the renter can see organic traffic reports from the MMP;\u003C/li>\n\u003Cli>who monetizes unattributed users, and how;\u003C/li>\n\u003Cli>how the app behaves if it did not receive install attribution during the first launch, but attribution appears by the next opening;\u003C/li>\n\u003Cli>whether it is possible to buy out organic traffic for the needed GEOs.\u003C/li>\n\u003C/ul>\n\u003Cp>If there are no answers, that does not prove fraud. But it does mean the rental service is not showing all its cards.\u003C/p>\n\u003Ch2>Organic, default, and mistracking are not the same\u003C/h2>\n\u003Cp>It is important to separate several different flows.\u003C/p>\n\u003Cp>\u003Cstrong>Organic traffic\u003C/strong> — the user found the app in the store and installed it without ads.\u003C/p>\n\u003Cp>\u003Cstrong>Default traffic\u003C/strong> — users whom the routing or attribution system could not confidently connect to a specific renter, buyer, or campaign.\u003C/p>\n\u003Cp>\u003Cstrong>Mistracking\u003C/strong> — a technical attribution error: the click, install, or opening happened, but the tracker, MMP, app, or intermediate logic did not connect the events correctly.\u003C/p>\n\u003Cp>\u003Cstrong>Naming mistakes\u003C/strong> — a separate topic outside this article, but a common one. Always check that naming is filled in correctly, and ideally test the naming-based routing yourself.\u003C/p>\n\u003Cp>\u003Cstrong>Normal discrepancies\u003C/strong> — the natural difference between the ad account, tracker, MMP, store, and internal stats. Such discrepancies happen even in clean white-hat products and do not always mean someone is taking traffic. For example, two ad networks can claim the same install on different grounds: the install may have happened after a Google ad click and been attributed as click-through, while earlier the user had seen an Instagram ad for the same product, so the install also received view-through attribution. The MMP then deduplicated the events and selected only one source according to its settings.\u003C/p>\n\u003Cp>The problem in the app rental market is that these flows are often hidden from the renter. You see that some users did not reach your stats, and then the question becomes interpretation: is it real organic traffic, default traffic, attribution loss, or shaving of your traffic?\u003C/p>\n\u003Ch2>Can 100% of traffic be attributed?\u003C/h2>\n\u003Cp>No. In practice, 100% attribution is unreachable.\u003C/p>\n\u003Cp>The reasons vary: event delays, iOS restrictions, SKAN, browser transitions, redirects, VPNs, anti-fraud systems, user behavior after install, SDK errors, naming-logic issues, caching, and ordinary integration failures. Even if the rental service works honestly, part of the traffic will still be lost or fall into an undefined flow.\u003C/p>\n\u003Cp>So the correct question is not "are there losses", but "what level of loss is normal for my setup". That level can differ between Android and iOS. It can also differ by source, GEO, and campaign type.\u003C/p>\n\u003Cp>If you lose a few percent on small volume, that may be ordinary technical reality. If losses become double-digit on stable volume and repeat in the same pattern, it is time to dig deeper.\u003C/p>\n\u003Ch2>How to measure losses\u003C/h2>\n\u003Cp>Start with measurement, not accusations. The minimum set:\u003C/p>\n\u003Col>\n\u003Cli>Compare data from the traffic source, tracker, MMP, and rental service stats.\u003C/li>\n\u003Cli>Look at Android and iOS separately, because attribution and restrictions differ.\u003C/li>\n\u003Cli>Break data down by GEO, source, campaign, and buyer.\u003C/li>\n\u003Cli>Test naming and routing on small controlled campaigns.\u003C/li>\n\u003Cli>Compare the share of unattributed traffic across different services with a similar buying structure.\u003C/li>\n\u003C/ol>\n\u003Cp>It is important to look not only at percentages, but also at money. If turnover is small, even unpleasant discrepancies can be cheaper than in-house development. If turnover is large, the same 5-10% becomes a number you can no longer ignore.\u003C/p>\n\u003Cp>Separately, ask services about default traffic: whether it exists, who monetizes it, whether the needed countries can be bought out, whether there is a fixed daily price, and what reports are available.\u003C/p>\n\u003Ch2>What alternatives exist\u003C/h2>\n\u003Cp>App rental remains convenient: fast, understandable, and free from the need to maintain your own development team or deal with publishing problems. But if the economics run into attribution loss, alternatives appear.\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cp>First — a private app for one team. It is more expensive, but gives more control over traffic, naming logic, and default monetization. Unfortunately, rental services rarely agree to such terms, and this is not necessarily because shaving is attractive. It is also because an app usually earns more when rented out.\u003C/p>\n\u003C/li>\n\u003Cli>\u003Cp>Second — buying out default traffic for the needed GEOs. This can be a compromise if the service is ready to sell that flow transparently, and such services \u003Ca href=\"/en/catalog/?organicAndroid=yes\" target=\"_blank\" style=\"color:#333; text-decoration: underline;\" rel=\"noopener\">exist in the catalog\u003C/a>.\u003C/p>\n\u003C/li>\n\u003Cli>\u003Cp>Third — in-house development. It gives maximum control, but requires money, people, accounts, design, publishing, support, and constant app replacement. Most importantly, it requires expertise, which is acquired through your own trial and error, and not for free. For many teams, this is not savings but a new headache.\u003C/p>\n\u003C/li>\n\u003Cli>\u003Cp>Fourth — PWA. A PWA has no store and no classic app attribution, so some problems disappear. Other limitations appear instead: fewer system capabilities, weaker bot filtering, and lower trust compared with a native app.\u003C/p>\n\u003C/li>\n\u003C/ul>\n\u003Cp>Sometimes the best option is to change nothing. If you need many apps for in-app, UAC, or testing, and your volume does not yet justify your own infrastructure, rental can remain rational even with inevitable losses.\u003C/p>\n\u003Ch2>What comes next\u003C/h2>\n\u003Cp>Organic traffic in arbitrage apps is not a myth, but it is not a universal explanation for low prices either. The cheaper a service gives away Android or iOS apps, the more closely you should look at traffic loss volume.\u003C/p>\n\u003Cp>When choosing a service, it is useful to compare not only rates and platforms, but also transparency: what happens to unattributed traffic, what reports are available, whether default traffic can be bought out, how routing is structured, and what losses are considered normal.\u003C/p>\n\u003Cp>For an initial comparison, you can use the \u003Ca href=\"/en/catalog/\" target=\"_blank\" style=\"color:#333; text-decoration: underline;\" rel=\"noopener\">app rental services catalog\u003C/a>, but the final decision should still be made from your own numbers after comparing several services.\u003C/p>\n",1779450052968]