Every so often, I’ll hear a pitch for an idea that the presenter is convinced is novel: a traffic trade network on mobile — but especially for mobile games — in which participants swap traffic with each other so as to avoid paying for installs. This “traffic co-op,” in theory, allows members to substitute users that have no demonstrable economic value to the publisher with users from other members’ apps that might.
These systems are usually designed to use some centralized routing logic to distribute an equal number of impressions to all members on a monthly basis. Each member installs some sort of impression-serving SDK (it could be a built-for-purpose SDK or the SDK of a service provider that is facilitating the traffic trade program) and “contributes” a fixed number of impressions each month to the co-op’s pool by filling them with the ads of other co-op members, as directed by the central routing logic. In return, each member receives back the same number of impressions, distributed evenly from within other members’ apps.
The prima facie appeal of a program like this is obvious: it helps apps with existing user bases leverage their non-paying users (NPUs) for the purpose of acquiring new users. In Every freemium app needs non-paying users, I discuss the benefits of having non-paying users in a freemium app, and a traffic trade like the one described above doesn’t negate those benefits. If a user in my app is unlikely to ever monetize, nothing is really lost in “trading” that user for another new user who may or may not monetize.
And yet, no traffic trade program has achieved appreciable commercial traction, though I’ve seen a number be proposed. There are a few reasons a system like this is difficult to coordinate between parties and to operate. The most obvious of these issues is that of adverse selection: if someone is trying to send a user to me, that user must not be worth very much. But this isn’t actually the most critical flaw in the concept, since participants expect to be receiving users that have not historically monetized in the source app (and are themselves only exposing members’ ads to users that do not monetize). So while any given participant can expect to receive low quality users from the program, they are also “paying into” the system with impressions from low quality users, and a symmetry of expectation exists: companies are swapping users with no monetization histories, hoping the absence of monetization was simply a lack of resonance with the original app-to-user pairing.
A second problem is that developers only really need a program like this until they can build the equivalent within their own portfolios for the purposes of cross promotion. The idea of “covering the market” by building a portfolio of first-party games that spans many genres is a relic of the 2012-2015 era of mobile gaming. Most studios now recognize that specialization is a competitive advantage: the most successful games tend to be those that monetize best, and monetization strategy varies widely from genre to genre within gaming. And so game developers scope portfolio development around the game genre for which they have the most institutional knowledge, and they are able to cross promote users across that same-genre portfolio as soon as their second game is published. Thus, participants in traffic trade co-ops leave as soon as they can internalize traffic trading as cross promotion, and a traffic trade program thus faces difficulties in scaling to new publishers.
And a third problem is that trading a fixed number of impressions doesn’t guarantee equal outcomes to publishers. Click-through and conversion rates are impacted by ad creatives and the relevance of those creatives to the users to which they are exposed — more on this idea in The click-through rate conundrum. In participating in a traffic trade program, a publisher is forfeiting a predictable amount of value (what they could receive from ad networks by selling their impressions) for a random amount of value in return (whatever the users sent to them, in whatever number they manifest, happen to spend in the recipient app). This isn’t what happens when an advertiser buys traffic from an ad network, because ad networks are most often optimizing for conversions on the basis of vast amounts of performance data. An ad network can capably estimate the number of installs that will be delivered for an advertiser by some volume of impressions served, and can often estimate value beyond that: retention, monetization, etc. This is all as a result of an ad network benefiting from vast amounts of performance data related to which ads work in what placements, and, especially, which users monetize in what types of games (although the ability to do this will be eliminated when the IDFA is deprecated). The infrastructure that ad networks use to efficiently route traffic adds a tremendous amount of value to the process of serving ads.
And lastly, a fourth problem with traffic trade co-ops is that they require a non-trivial amount of coordination to execute. Someone has to actually manage the logical layer that routes traffic and counts contributions versus redemptions, and while companies may get excited about the concept of participating in such a system, very few want to build or operate it — especially not for free (and once they start charging other participants for its use, they essentially become a PMP or ad network).
On the surface, traffic trade programs seem practical. But for most use cases, traffic trade systems likely don’t fulfill a pressing need or provide value that justifies the overhead — operationally, contractually — of running them.
Recent