Social Web accommodates a wide spectrum of user activities, including information sharing via social media networks (e.g., Twitter), question answering in collaborative Q&A systems (e.g., StackOver ow), and more profession-oriented activities such as social coding in code sharing systems (e.g., Github). Social Web enables the distinctive opportunity for understanding the interplay between multiple user activity types. To enable such studies, a basic requirement, and a big challenge, is the ability to link user pro les across multiple social networks. By exploiting user attributes, platform-speci c services, and di erent matching strategies, this paper contributes a methodology for linking user accounts across StackOver ow, Github and Twitter. We show how tens of thousands of accounts in StackOver ow, Github, and Twitter could be successfully linked. To showcase the type of research enabled by datasets built with our methodology, we conduct a comparative study of user interaction networks in the three platforms, and investigate correlations between users interactions across the di erent networks.
Social Web comprises a diversity of social networking platforms, which cover
a wide range of user activities. With the fact that a single user has multiple
accounts across di erent social networks, it has now become increasingly
important to link distributed user pro les belonging to the same user from multiple
sources, which can bene t various applications. For instance, it has been shown
that aggregating user pro les could improve personalized Web service such as
recommendation systems by solving the cold-start problem [
Linking user pro les across multiple social networks also provides an opportunity for better understanding the interplay between di erent types of people's activities. Let us take as an instance the domain of software programmers: they share software related content in Twitter, seek or provide answers to software engineering related questions in StackOver ow, and collaboratively code in Github. These three di erent social networks (i.e., Twitter, StackOver ow and Github) are used by programmers di erently, in terms of their purposes and correspondingly their activities. By aggregating the data sources from multiple networks, we might explore at large scale the complete spectrum of programmers' on-line professional activities.
Linking users' accounts across multiple social networks is considered a
wellknown problem, thus attracting multiple techniques and solutions [1, 6{8, 4, 5].
Previous studies addressed the online activities of professional users, but
investigated a single type of activities in a single system [
To drive a deeper investigation over users' professional activities, we are motivated to construct a cross-system users' accounts matching dataset from Twitter, StackOver ow, and Github, to enable future studies of professional activities from multiple perspectives. For instance, a dataset as such can help us understand how di erent types of users (e.g., users with di erent expertise) are engaged in di erent professional activities; it can also help in understanding how di erent types of social interactions among users can in uence the evolution of communities of di erent professional activities. This paper contributes a methodology to link online users' accounts across Twitter, StackOver ow and Github, by exploiting di erent attributes of user pro les, platform speci c API's and services, and a variety of accounts' matching strategies. As a rst trail of valuing this dataset, we construct three social networks, including follower-followee networks of Twitter and Github, and helper-helpee networks of StackOver ow. By characterizing the networks features, we present our ndings of how users interact with others in di erent activities, and how di erent activities of the same user correlate with each other.
The rest of the paper is organised as follows. Section 2 describes our methodology of matching users across StackOver ow, Github and Twitter, together with the corresponding results of user matching. Based on these matched users, Section 3 introduces our comparative study of user interactions between three user interaction networks in StackOver ow, Github ad Twitter, and Section 4 concludes our work.
This section describes our methodology of matching users across StackOver ow, Github and Twitter. We rst discuss the general settings of data retrieval for the three social networking platforms, then present our user matching strategies and work ows. 2.1
StackOver ow. We downloaded the most recently released data dump from Internet archive3. Due to privacy concern, since the end of 20144 StackOver ow 3 https://archive.org/details/stackexchange, accessed at April, 2015 4 http://meta.stackexchange.com/questions/221027/where-did-emailhash-go data dump no longer contains hashed user emails. While not crucial, hashed emails are a convenient and e ective way to unambiguously match accounts. To overcome this limitation, we extended the data from the data dump released on September 2013 (which is the last released dump with hashed email addresses) with the latest data contained in the 2015 data dump.
Github. The GHTorrent project5 has incrementally released Github data every two months since March 2012. We parsed its data from the rst release containing user information (i.e., July, 2012) until the latest one on March 2015, and kept all versions of user information in our database for account matching. Twitter. Given an existing user name, the related account information (e.g., pro le picture, website) and related posts in Twitter can be retrieved via Twitter REST API6. The Twitter.com Search7 functionality, on the other hand, allows for fuzzy retrieval of users accounts, returning a candidate set of accounts having screen names similar to the one provided as input. For our purposes, the latter proved more useful than the former for fuzzy matching.
The main work ow of accounts' linking across the three platforms is depicted in Figure 1. Accounts from StackOver ow and Github were dumped and processed rst. We retrieved 4,132,407 and 4,288,132 accounts in StackOver ow and Github, respectively. These sets of accounts were then matched to each other and the resulting overlap further matched to a set of Twitter accounts. The latter was retrieved using a strategy that we will discuss later in this section. 5 http://ghtorrent.org, accessed at April, 2015 6 https://dev.twitter.com/rest/public 7 https://twitter.com/search-home 2.2
We design three account matching strategies to nd the same set of users in the platforms under study: { explicit matching, which aims at identifying the links explicitly provided by users in one platform to their accounts in other platforms for user matching. { attribute-based matching, which leverages unique attributes of users' accounts such as email to connect pro les across multiple platforms from the same user. { fuzzy matching, which exploits less accurate user attributes such as login names and pro le images to match user pro les.
Explicit matching is performed to link user accounts between StackOver ow and Github, and further link them to Twitter. Attribute-based matching is performed only between StackOver ow and Github, while fuzzy matching aims at linking matched users in StackOver ow and Github to Twitter. We introduce as follows the concrete steps we took for each of the matching strategies.
Explicit matching. Starting from our built dumps of StackOver ow and Github, we perform explicit matching by analyzing user-provided links from the user pro les in each of these platforms to the other platforms. We consider this a very reliable method for account linking: matching information are provided by users themselves, with strong incentives for truthful linking.
From StackOver ow to Github, Twitter. We analyze StackOver ow user proles to nd explicit links to GitHub and Twitter users. For StackOver ow users that provide links to their Github link, we parse the direct links, which are in the form of https://github.com/GitHubLoginName and obtain their Github login names, i.e., GithubLoginName. For StackOver ow users that provide direct links to Twitter, which is usually in the form of http://www.twitter.com/ TwitterScreenName, we parse the Twitter screen name, i.e., TwitterScreenName. Both GitHub login name and Twitter screen name uniquely identi es one user in GitHub and Twitter, respectively.
From Github to StackOver ow, Twitter. We analyze Github user pro les similarly to match user pro les in StackOver ow and Twitter. For StackOverow, we adopt an additional strategy to obtain a cross-reference to the same user: since some Github users provide their StackOver ow Careers pro le8, which is a CV-like page of senior StackOver ow users, we parse the HTML code of the corresponding pages in order to retrieve the direct link (in the form http://stackoverflow.com/users/id) to their real StackOver ow pro le pages.
The result of explicit matching is reported in Table 1. As it can be observed, we are able to match thousands of users between the three platforms. 8 http://careers.stackoverflow.com/, StackOver ow Careers StackOver ow TGwitihtutebr
4,536 10,068
Attribute-based matching. StackOver ow and Github provide users with
the option of registering their emails, which are encrypted into MD5 hashes in
the data dumps. This technique is known from literature [
There are in total 2,185,162 ( 52.9%) StackOver ow users and 510,523
( 11.9%) Github users with email hash. Note that email hashes were
previously considered for matching users between StackOver ow and Github in [
Combing email hashes explicitly provided by users, and implicitly revealed from their Gravatar Id, we use Query 1 for StackOver ow-Github user matching, which encodes all meaningful joins between MD5 email hash and Gravatar Id attributes across the two platforms. The result of attribute-based matching is shown in Table 2. We nally obtained more than 600k exactly matched users between StackOver ow and Github.
Fuzzy matching. Matching accounts from StackOver ow and Github with Twitter accounts is intrinsically more di cult, since Twitter pro les need to be obtained via Twitter API services.
Lookup and search. Two types of query requests are here considered, namely Twitter REST API and Twitter.com Search, hereinafter referred to as Lookup 9 https://en.gravatar.com/ Gravatar, a globally recognized avatar. 10 https://en.gravatar.com/site/implement/images/ Gravatar: Image Request
SO emailhash - GH emailhash SO gravatarid - GH emailhash SO gravatarid - GH gravatarid Union all above types 580,979 107,572 1,224 4,752 604,083 and Search, respectively. The former method returns the full pro le information of the user corresponding to a given user screen name. Using Twitter REST API, each request can process up to 100 inputs. By contrast, Twitter.com Search permits to process only a single input for each request. While being less e cient, Twitter.com Search is however more exible in terms of the input | it accepts any textual input.
We consider the following options of input for the Search method: { login names, and names of users' StackOver ow and Github accounts; { URLs of user's StackOver ow and Github accounts; { users' website URLs identi ed from their StackOver ow and Github pro les.
To nd the best input for the Search method, we analyzed how many accounts can be matched by using di erent user attributes. Matching is performed in two steps: (1) given a user attribute, retrieve candidate users via Twitter.com Search; (2) try matching the website URL of the Twitter candidates and the website URL of the user StackOver ow (Github) pro le. Results have shown that using Github login name provides better matching of Twitter pro les than the URLs of their accounts in StackOver ow or Github, as well as their website URLs. We therefore chose to take Github login name as an input for Search to retrieve candidate Twitter pro les for matching.
Accuracy of Lookup and Search methods. To assess the performance of the Lookup and Search matching methods, we rst categorized the Github login names into the following categories: 1) the login contains only lower-case characters, 2) it contains at least one upper-case character, 3) it contains numbers, and 4) it contains special characters. Figure 2a shows the distribution of Github login names according to the categorization above, from which we observe that the majority of them are in the \lower-case" category.
To understand how di erent categories di er in the probability that at least one candidate can be returned by Lookup and Search, in Figure 2b we analyzed the percentages of Github login names that have at least one candidate returned by Lookup and Search. High values indicate higher probability that the user can be matched. We observe that the Search method performs better than Lookup in all categories except in the \Number" category.
0.8 ft#oHG saennm00 ..64 en i rce lgo0.2 P 0 Special N umber Upper Lower
Category (a)
Special Number Upper Lower
Category (b)
For each category, we randomly selected 100 Github login names, took them as input for both Lookup and Search methods, then manually checked the matched accounts. A user is considered to be matched with a Twitter account if there is explicit Twitter information (e.g., personal website, pro le description) that can identify the user with high con dence. Table 3 shows that Search performs better than Lookup, especially for Github login name that belong to the \lowercase" and \special characters" categories. The least gain of Search over Lookup corresponds to the category \Number" (less than 5%). Considering Figure 2b and the higher e ciency of Lookup method, we chose to use Lookup for Github login names in the \Number" category, and Search for the other categories. Work ow of fuzzy matching. Figure 3 depicts the work ow of Lookup and Search methods. Given a user Github login name, it rst determines whether to use Lookup or Search, then checks Twitter pro les for account matching. In the step of "Twitter Pro le Check", a user is matched to a Twitter account if s/he satis es the following criteria: 1. the website attribute of the user's Twitter pro le is exactly the same as the website of his/her StackOver ow (Github) pro le; 2. otherwise, the Twitter pro le picture needs to be highly similar (e.g., 90%) to her/his pro le picture in StackOver ow (Github).
In criterion 1 we ignored ambiguous websites such as http://facebook. com, which can bring to have False Positive for website matching, while for criterion 2 we performed image similarity via image hashing 11. We manually checked 100 users matched by website and pro le picture, respectively. As before, user pro les were considered as matched if the provided information gives high con dence that they belong to the same user. The true positive rate of website and pro le pictures are 100% and 98%, respectively, which indicate that users can be regarded as exactly matched.
Lookup Search Total 176,508 240,000 416,508 9,316 37,449 46,765 5.28% 18.43% 11.23%
To account for limitations with the Twitter APIs, at the time of this writing we were able to analysis a subset of linked accounts from StackOver ow and Github. We ordered accounts according to their popularity (measured by #fol11 http://hzqtc.github.io/2013/04/image-duplication-detection.html, Image Duplication Detection
lowees) in Github, and matched them to Twitter accordingly. Table 4 reports the user matching results. We analyzed 416k accounts, speci cally 240k by using Search and 176k by using Lookup. The number of accounts matched are 37k and 9k, respectively, with a total of 46k accounts matched to Twitter. 3
To showcase the type of research that is enabled by a dataset built with our methodology, we designed a study aimed at providing an answer to the following two research questions: RQ1: how do users connect with each other in different social networks? RQ2: does the relative importance of users vary across social networks? To this end, we rst inferred the interaction networks over the same set of users in the three platforms, then analyzed network features and correlations of user centrality in the three networks.
GT W ; GGH that encode following relationships of users in Twitter and Github, respectively, i.e., a directed edge e = u ! v indicates that user u follows user v. While being absent of explicit following-followee relationship, StackOver ow provides an implicit "help network" among users according to who answers to whom. Therefore, we built a directed graph GSO such that an edge e = u ! v indicates that user u is helped by v, i.e., at least one question of u is answered by v.
Due to the rate limit of Twitter REST API, we built the three user interaction network graphs for the 20k most popular users among the 46k matched users (Table 4). As before, popularity is de ned according to #followees in Github.
works? Table 5 reports basic statistics of the users' networks in the considered social networks. By comparing the #nodes in the three networks, we observe that, in the same set of 20k users, more users are involved in both Github and Twitter interaction networks than those involved in StackOver ow interaction network. This indicates that users are more likely to be active in explicit interaction based on followship than in helping-based interaction.
Comparing the density of these networks, results show that users have similar connection intensity in StackOver ow and Github, both of which are however (a) StackOver ow in- and out- degree.
(b) Github in- and out-degree.
(c) Twitter in- and out-degree. 10 times lower than user interaction in Twitter. This would imply that users are more likely to connect with each other in general-purpose social networks like Twitter than in profession-oriented networks like StackOver ow and Github.
Figure 4 shows the in-degree and out-degree distributions over the three networks. In StackOver ow, both distributions conforms to power-law, indicating that most users follow (resp. are followed by) a small number of users, while there is a small number of users that follow (resp. are followed by) many users. In addition, in-degree distribution looks more skewed than out-degree distribution { in other words, users tend to follow the same set of users, who is followed by many users. Similarly in Github and Twitter, in-degree distribution is more skewed than out-degree distribution, indicating that a small number of users are highly popular in the network. Comparing the three networks, StackOver ow is the one that has most similar distributions of in-degree and out-degree. We consider the fact that the StackOver ow helping-helpee network is built implicitly from question-answering activity between users, while the following-followee relations in Github and Twitter are explicitly constructed by users. The result suggests that explicit connection mechanisms result in a more skewed popularity among the users of a platform.
works? To answer this question, we choose to correlate users' centrality scores (a) StackOve ow - Github
(b) StackOve ow - Twitter (c) Github - Twitter in the di erent networks. A high cross-network correlation of user centrality scores would indicate similar user importance in di erent settings; for instance, a high correlation of user centrality in StackOver ow and Github networks will suggest that a user who is helpful in answering to others' questions in StackOverow will be followed by many users in Github (and vice versa); on the contrary, a low correlation would indicate that users' activity in one platform is not indicative of their activities in another platform, e.g., an in uential user in Github may not likely to answer questions in StackOver ow.
To obtain users' centrality values, we used classic PageRank model. We then calculated Pearson correlation of the centrality values for the same set of users in every pair of graphs. Results are shown in Figure 5. For StackOve ow and Github networks, we have a Pearson coe cient of -0.0185170 that reveals no linear correlation between PageRank values of users on both platforms; this means that, as shown in Figure 5a, most in uential users on StackOver ow do not have the same importance on Github and vice versa. Similar remark can be made on StackOve ow versus Twitter, where Pearson correlation is -0.0014857. By contrast, in the Github - Twitter case, we observe a Pearson coe cient of 0.7554060, which implies that user interactions of Github and Twitter networks are correlated. We addressed the problem of user matching across StackOver ow, Github and Twitter social networks. We proposed a methodology that combines di erent matching strategies and makes use of di erent user attributes and platformspeci c services for linking user accounts. Many of the proposed linking strategies can be generalized to other social networking platforms. For instance, most social networking platforms provide REST API's and search, for which the linking techniques Lookup and Search can be applied. These methods together allow us to obtain much better results than in literature. Our study of interaction networks based on the matched users in the three platforms has provided interesting insights: 1) users in general-purpose social media networks like Twitter are more connected than in profession-oriented social networks like StackOver ow and Github; 2) social networking platforms that enable the functionality of explicit user connection (Github and Twitter) will result in more skewed distribution of user popularity, and more correlated user activities between them, than (with) the one that only provides implicit user connection mechanisms (StackOver ow). As part of future work, we plan to deepen our analysis of the user interaction networks properties such as the formation and evolution of communities, and the topics discussed by the users and communities across the three networks.