Since its launching, Poke´mon Go has been pointed as the largest gaming phenomenon of the smartphone age. As the game requires the user to walk in the real world to see and capture Poke´mons, a new wave of crowdsourcing apps have emerged to allow users to collaborate with each other, sharing where and when Poke´mons were found. In this paper we characterize one of such initiatives, called PokeCrew. Our analyses uncover a set of aspects of user behavior and system usage in such emerging crowdsourcing task, helping unveil some problems and benets. We hope our eort can inspire the design of new crowdsourcing systems.
INTRODUCTION
e mobile games industry experienced an exponential growth
in the past decade, motivated mainly by (i) an ever increasing
worldwide penetration of smartphones and mobile devices, (ii) the
ability of such devices to deliver quality audio and video; and (iii)
the increasing capacity of network transmissions of these devices,
allowing users to download larger and more complex games [
e largest gaming phenomenon of the smartphone age so far
has been the augmented reality game Poke´mon Go. It was launched
in July 2016, rstly in Australia, New Zeland, and USA. Yet, in
one week aer launching, it had already reached seven million
users, accounting for three to six times more downloads of the
most popular games in history at that time [
ere has been a number of recent studies exploiting behavioral
changes among Poke´mon Go players. Nigg et al. [
Since the game requires the user to walk in the real world to see
and capture the Poke´mons nearby, a new wave of supporting apps
has emerged. In these apps, players can collaborate with each other,
sharing where and when Poke´mons were found. ey represent
the emergence of a crowdsourcing eort of the game players to nd
rare and valuable Poke´mons. PokeCrew1, one such app of great
popularity, is a crowdsourced Poke´mon Go map. It shows reports
of locations of Poke´mon posted by players in real time in a map and
it became quite popular among the most active users. For example,
this website was ranked among the top 15000 domains in the Web,
according to Alexa.com [
In this paper, we characterize the crowdsourcing eort of Poke´mon
Players through PokeCrew. Crowdsourcing systems enlist a
multitude of humans to help solve a wide variety of problems. Over the
past decade, numerous such systems have appeared on the Web.
Prime examples include Wikipedia, Yahoo! Answers, Mechanical
Turk-based systems, and many more [
In the following, we rst describe the data used in our study and then analyze how users collaboratively help each other within the Pokecrew platform. We nish this paper with our conclusions and possible directions for future work. 2
With the increasing popularity of Poke´mon Go in the whole world, many applications emerged with the purpose of enhancing the players experience with the game. Among the most popular ones are Pokecrew2, PokeRadar3, and PokeVision4. e idea is to share Poke´mon maps and their locations in a crowdsourced way: aer nding Poke´mons in the game itself users may report them in the supporting app, making the creatures visible to other players that are not in that specic location and time. is can be very useful to players, since, in the game, it is not possible to see Poke´mons far from where the player is currently physically located.
We have obtained data from Pokecrew, a popular app that oers to users a map containing the location of Poke´mons reported by other users. e application can be found in the PlayStore, AppStore, as well as on the Web. Our dataset contains 39,895,181 reports, from July 12th to August 24th 2016. Each report contains several information elds, including: a report id, reported Poke´mon id, geographic coordinates, time when the report was created and, in some registers, a username.
Our results show that most reports in our dataset (98.7%) do not include a valid username, since the app does not require the user to identify itself in order to create reports. us, although we report general statistics computed over the whole dataset in the next section, we focus on the subset of reports with valid usernames to study user behavior. We note that, despite the small percentage, there is still a considerable amount of identiable reports (over 500k) on which we can perform such analysis. Finally, we also note that the spatial information in our dataset refers to geographic coordinates of the reports. 3
REPORTED POK E´MONS AND THEIR
We start our characterization by analyzing which Poke´mons are the most reported ones and where they were reported. We then discuss the application adoption on specic locations. 3.1
Table 1 shows the top-10 most reported Poke´mons in our dataset. We note that these Poke´mons are evolutions or dicult to nd in the game. An evolution of a given Poke´mon consists of a similar monster but with a higher power, which is very important to bale with other Poke´mons in the so called ’gyms’, popular places across the world where a user (a Poke´mon master) bales with other users in order to take control of that gym. Besides that, having these evolutions contributes to the user’s Pokedex, which is a list containing detailed stats for every creature from the Poke´mon games. e more Poke´mons a user has in her list, more experience she has on the game, which is also important to bale with other players at the gyms. Capturing an evolution is aractive to players because the only alternative way to obtain them is to use an egg, which is earned as the player progress in the game. With this egg, the Poke´mon master can put it to crash, which is achieved by walking. e distance required to crash an egg may vary (2, 2www.pokecrew.com 3hps://www.Pokemonradargo.com/ 4www.pokevision.com 5 or 10 kilometers). e higher the distance, the more valuable the Poke´mon that comes out of the egg is. us, it is much more convenient to catch the evolved Poke´mon right away than it is to walk waiting for the egg to crack and, luckily, be rewarded with a powerful Poke´mon.
is observation shows the great contribution of Pokecrew to Poke´mon players: the interest in rare Poke´mons or evolutions is what drive players to appeal to these crowdsourced apps. ese Poke´mons are more valuable than the most commonly found, which normally have less power to bale.
Golduck Pidgeot Nidoran Tentacool Nidoqueen Magnemite Clefable We note that our dataset contains only geographic coordinates of the reports. In order to characterize the location where these reports were made, we rst converted the coordinates to the cities and countries where the reports are made. Our approach to do that consisted of using a reliable Python library, namely geopy5, which allows us to retrieve the nearest town/city for a given latitude/longitude coordinate.
New York City San Francisco Taipei Paris Santiago Johor Bahru Kuala Lumpur Long Island City Tokyo Kampung Pasir critical, since the adoption of Poke´mon GO was fast and user engagement was very strong. In an application like Pokecrew, if the user does not encounter Poke´mon reports, it is very likely she will not be motivated to use the system and therefore won’t be encouraged to create new reports.
To assess whether the previous presence of Poke´mons in the application inuences the user to create new reports, we compared the amount of reports in a popular area among the days. To that end, we focused on the reports in the city of New York, which concentrates most part of reports. e city geographic area was rst divided into 800 regions of approximately 500m2 , and for each region we counted the total number of reports created on each day. Besides that, we considered the period from August 14th to 26th , which concentrates a larger number of reports. It is possible to see in Figure 1, most of the reports made in New York City, were created in the Central Park area, a very popular place in the game itself. Figure 2 shows a heat map correlating the number of reports in each region showed in Figure 1 in each date. Next, we provide a characterization of the crowdsourced Pokecrew data, exploring aspects of user behavior and their engagement within this crowdsourced system. e dataset collected presents 39,895,181 reports, but only 452,359 (1.3%) are registered users (nonanonymous). We focus the next analysis on the behavior of this identied group of users. 4.1
Analyzing the reports made by registered users, we can notice that some of them, mostly users who contributed with the largest amounts of reports, reported a large number of sightings in just one day. For example, the top 1 user reported 184,615 times, being her reports concentrated between July 21st and 24th . Specically, reported 13,007 times on July 21st and 75,574 on July 22nd , which are very expressive numbers. Similarly, 31,656 reports made by the second most active user, which corresponds to almost 99.7% of his contribution to the Pokecrew system, were concentrated on a single day, August 12th . e 10 most active users in the Pokecrew system, in terms of reports of Poke´mon sightings, are shown in Table 3. We note that some users have reported far many sightings than others, especially the 4 most active ones. Given the large amount of reports associated with these users, and the short time interval during which they were made, we speculate that these reported sightings may not have been made by “legitimate” Pokecrew users.
Based on the amount of reports that the top 5 have made, and the fact that these reports are, in general, concentrated in a few set of days, we’ve disregarded this data for some analysis. Just a few number of users have reported from 30 to 261 times. Most of users have reported from 1 to 20 times. We have categorized users who have reported from 1 to 5 times as less active users, representing 80% of the database.
Given that for each report we have the information about the time when it was created and its location, we can calculate for each pair of reports of a single user the speed in which he would have to dislocate in order to make both reports. Calculating the speed for each pair of user’s report, we obtained a set of speeds from the identied user’s reports. e chart bellow shows the speed distribution across the total identiable users:
As we can see in the plot above, a considerable number of reports made by the users in the system reveal that they would have to move at abnormally high speeds for this kind of game. Even if we consider the case where a user report a Poke´mon in one place, go on an airplane trip and then report another in the destination, which although maybe uncommon, is possible, some speeds are not feasible to achieve. e problem is that, even though the PokeCrew app uses the GPS data from the smartphone and places the map in the user current location, the player has the ability to move the map to any place in the world and therefore report a sighting from anywhere. ere is no validation in the app if the report being created is trustful. is opens a serious aw in the system, because malicious users and even bots could create fake sightings to spoof the system and degrade the legit user experience. Even if the user could not change the location in the map, it would still be possible to report a Poke´mon that does not exist in the game itself at that given time and location. is kind of validation is a key problem in collaborative systems, and can be very challenging due to the lack of mechanisms to control whether the information being supplied to the database is true or not. 4.2
e created at eld represents the date when the the sighting was reported by a user. e chart below shows an analyse about how many reports were made in each day. is scenario changes aer August 8th , with a peak of reports on August 21st . 5
is paper explores one out of a new wave of applications that rely on collaborative databases in the mobile gaming environment. Poke´mon Go was a huge phenomenon in this area and motivated the creation of innumerable initiatives to enhance the gamers’ experience. Since the game requires the user to walk and visit places in order to succeed at being a Poke´mon master, this kind of support showed to be extremely useful to players, because they could go straight to the exact location where a desired Poke´mon is located instead of randomly walk hoping to nd some valuable monster, as we could see with the most reported Poke´mons. One important aspect in this work was to show how vulnerable such systems are to spoofed data. Beyond the gaming environment, we can cite other collaborative systems such as Wikipedia, where it’s possible to see articles with dubious content, although they have more strict controls to prevent these kind of activity. In the Pokecrew application, inconsistent locations over time for some users and the noticeably high amount of reports these users pushed to the system certainly had a negative impact over the legit nal user experience, who could encounter fake reports on the map. e recurrent presence of fake data on crowdsourced applications can be very frustrating to the nal user, who can be discouraged to continue using the system and therefore stop providing useful information to the database. One possible solution for the considered scenario would be add an authentication layer to the system to detect and possibly ban users spamming the system. Besides that, some metrics can be useful to track abnormal activity, as we showed with the speed chart on section 4. us, it’s highly recommended for collaborative systems such as the application studied in this work to implement these mechanisms to keep the system safe from unwanted data.
We would like to thank Pokecrew for kindly sharing its data with our research group and also the Sideways organization for the space to spread this work. is work is supported by author’s individual grants from Capes, Fapemig, and CNPq. F. Benevenuto is also supported by Humboldt Foundation.