从百万条推特分析,谁真正关心比特币

关于比特币或其创始人Satoshi Nakamoto的推文,他希望从这些信息中了解那些真正对比特币感兴趣的人,并了解推特上的活动是如何追踪大事件的,另外还详细分析了关于推文发布者、发布地和具体信息情况。本文来自Gigaom,下面看Derrick Harris给我们带来的精彩解读。

以下为译文:

综述:为了了解比特币这一全球现象,我分析了二月份共计约130万条关于比特币的推特。以下是关于推文发布者、发布地和具体信息的分析。最近我分析了今年二月份的共计约130万条关于比特币或其创始人Satoshi Nakamoto的推文。我希望从这些信息中了解那些真正对比特币感兴趣的人(至少他们的兴趣足以推动他们发这推特),并了解推特上的活动是如何追踪大事件的。

是谁在推特上谈论比特币

共计333,144个推特账户发布过有关比特币的推文。但各账户发布的推文数量大不相同。有些账户明显是垃圾邮箱账户或其它类型的机器人账户——数千个账户仅仅发布过一条推文或者干脆没有发布过推文——其余的持续的关注着比特率和比特币的新消息。下图是2月份最活跃的十个账户。

下图是被@次数最多的十个用户。毫无意外的比特币的新闻专家Coindesk占据了榜首。实际上大部分数字还要更高(有些甚至会高出许多),因为推文经常会引用多个推特账户,但是因为数据格式的原因,我们很难计算那些推文。

有些账户只是“昙花一现”,某条推文突然被大量转发,如脱口秀主持人Conan O’Brien的这条推文。

和一位名叫Bacon Bangkok.的用户的这条推文。

加V用户中,Marc Andreessen最活跃,并备受关注

我认为也有必要分析加V用户的情况来了解都有哪些知名人士在推特上探讨比特币。下图是2月最活跃的加V用户,风险投资家Marc Andreessen(@pmarca)位居榜首。

Andreessen也被提到了很多次,这也在意料之中——他被提到了3600多次(包括被其它用户提到)——考虑到他只发布了145条推特,这个数字很庞大。我们通过一个交互式表格(点击这里)展示他创建的庞大的网络。小黄点代表提及Andreessen和其他人的推文,蓝色点代表发表推文的推特账户。Andreessen是一个大黄点,他连接了提到他的人和他提到的人。

你可以发现,Andreessen直接回复或直接推的网络用户数目很小。

比特币(可能)在哪里流行

下图统计了发布推文数目最多的时区,考虑到垃圾账户的存在和一些账户没有明确的时区或者时区错误,这是一个大概的结果。此外,这个统计是针对单条推文的,不是面向不同时区中的不同推特账户的。例如,ALLThingsBTC账户所发布的15,000条推文中的20%是来自伦敦时区的。

如果通过用户定义的地点来分析,问题会大不相同。例如,你会发现有成千上万种说法来指代纽约,而且Cryptogeeks代表#Bitcoin #Litecoin #Altcoins。

如果你想看这些数据的视觉效果图,下图是使用Google Fusion Tables对小样本用户位置映射得到的效果图。这并不完全精确——Fusion Tables视图将每个事物定位,即使有些没有真正的位置——但它大致描述了全球比特币的现状。

Mt.Gox垮台

上述的图表描述都是谁在发布推文,但为了完整的分析二月比特币的形式,我们还需要分析比特币交易服务Mt.Gox的消亡。

Mt.Gox的垂死挣扎见下图时间轴。2月7日是一个大跌,当天Mt.Gox官方宣布暂停比特币的取款。2月10日,Mt.Gox延长了对取款的禁令,比特币价格大跌。2月24日晚,Mt.Gox已经‘丢失’了750,00比特币,市值3.75亿美元,隔日早晨,推文数目猛增。2月28号,Mt.Gox申请破产保护。

下图以小时为单位进行分析。注意从2月8日开始,垃圾账户数飙增。

Mt.Gox于2月6号深夜发布了通告后,当媒体开始讨论Mt.Gox的垮台时,推特上关于提款问题的抱怨、宣称Mt.Gox即将灭亡的言论也越来越多。2月5日Mt.Gox上比特币大约贬值100美元的也是原因之一。

2月4日,瑞典海盗党创始人Rick Falkvinge宣称,Mt.Vox已经积累了高达3千8百万的未提款(即,比特币离开用户账户但并未支付给用户)。

总之,关于Mt.Gox的言论紧随最新消息。在下图表中,蓝线代表态度消极的推文,黄线代表态度积极的推文,紫线代表当天所有关于比特币的推文。2月25日,提及Mt.Gox的消极推文数量占据了所有关于比特币推文数量的四分之一。

将记者算进来

当记者了解一个故事后,他们的文章往往传播广泛。2月,共计247,000个不同的连接被分享,共被分享102万次。我分析了被分享次数最多的前10,705条连接,这些链接最少被分享了12次。其中,1328(不足总链接数目的1%)——程度上、形式上——来自25个技术和通用新闻网站。他们被分享了121.931次,占据了2月份分析活动总次数的12%。

(关于链接的一点说明:考虑到RSS、Google或其它社交媒体在分享链接时会修改链接,我们很难获得针对每个链接的确切数字。通过Excel我将单元格们缩短为100个特征,这是一种对付有多个链接单元格的好办法。)

长话短说:评估出版物的普及度时,使用总分享量比使用单一链接得到的结果更精准。对前44,810个链接使用这种分析方式,我们将得到针对每个出版物的多个链接,最低限度的更高分享数。

现在来看看当我们加入Coindesk,这个关注货币流通的新闻站点时,我们将得到什么。点击这里查看这个图表的交互式版本。

同样,新闻站点与垃圾信息、比特币钱包链接、交易所、监视器或其它非新闻站点并不匹配。分享次数最多的前15个链接正是如此的站点,共计76,534次分享。这篇来自Wired的文章(这个版本似乎取代了早期的版本)是分享次数最多的链接,被分享了1404次。

原文发布时间为:2014-05-10

时间: 2024-08-24 15:36:54

从百万条推特分析,谁真正关心比特币的相关文章

分析百万条推特 看看究竟谁关心比特币

综述:为了了解比特币这一全球现象,我分析了二月份共计约130万条关于比特币的推特.以下是关于推文发布者.发布地和具体信息的分析. 最近我分析了今年二月份的共计约130万条关于比特币或其创始人Satoshi Nakamoto的推文.我希望从这些信息中了解那些真正对比特币感兴趣的人(至少他们的兴趣足以推动他们发这推特),并了解推特上的活动是如何追踪大事件的. 以下是我得到的信息.点击图片阅读更详细的信息. (免责声明:我既不是统计学家,也不是程序员,因此我使用的是比较简单的统计工具,并和其它领域的公

谁关心比特币,看大数据百万条推特分析

Derrick Harris分析了今年二月份的共计约130万条关于比特币或其创始人Satoshi Nakamoto的推文,他希望从这些信息中了解那些真正对比特币感兴趣的人,并了解推特上的活动是如何追踪大事件的,另外还详细分析了关于推文发布者.发布地和具体信息情况.本文来自Gigaom,下面看Derrick Harris给我们带来的精彩解读. 以下为译文: 综述:为了了解比特币这一全球现象,我分析了二月份共计约130万条关于比特币的推特.以下是关于推文发布者.发布地和具体信息的分析. 最近我分析了

查询一百万条数据就需要20多秒的时间

问题描述 用C#开发了个查询系统,查询一百万条数据就需要20多秒的时间,并且程序会占用500M内存.数据库占用120多M内存.有什么好的方法进行优化. 解决方案 解决方案二:太夸张了.优化数据库啊.尽量用存储过程解决方案三:说错了,用了1分20秒的时间解决方案四:通过DataReader或分页存储过程实现分页查询解决方案五:给你点建议:1.如果这个查询与其他的表的查询有关系的话,最好先根据条件做表的合并再做查询,那样可以减小查询表的大小;2.如果数据还是很多,那么看看能否在查询条件上下功夫,把条

算法,PHP取数据库中百万条数据中随机20条记录

额,为什么要写这个? 在去某个公司面试时,让写个算法出来,当时就蒙了,我开发过程中用到算法的吗?又不是大数据开发,分析. 今天偶然想起来一个坑爹数据,如:PHP取百万条数据中随机20条记录,当时就用的算法. 1.先统计统计数据库多少条记录(这个做个数据缓存,如1小时重新统计一次), 2.根据总条数,随机1次,1次性取出20条记录(当然这个就相当于分页了,要求不高的话,这个最快,我用的就是这个): 还有一种方法,随机20次,重复执行20次. 例如: $sum=800000;//得到总条数 //循环

Facebook是怎么做到每秒索引数百万条记录的?

编者按:作者Pedro Eugênio Rocha 现任Facebook系统工程师,2016年毕业于巴西巴拉那州联邦大学信息学专业,研究兴趣包括数据库与存储系统,尤其是与分布式系统和大数据相关的数据库与存储系统.作者在文章中介绍了Cubrick:一种多维内存数据管理系统.Cubrick是由Facebook开发的新型分布式多维内存数据库管理系统,其目的在于解决大量数据资源并行运行所存在的问题.为达到交互式分析高度动态数据集这一目的,Cubrick运用一种用于管理柱形内存数据的新策略,这种策略允许在

Facebook是怎么做到每秒索引数百万条记录的?

编者按:作者Pedro Eugnio Rocha 现任Facebook系统工程师,2016年毕业于巴西巴拉那州联邦大学信息学专业,研究兴趣包括数据库与存储系统,尤其是与分布式系统和大数据相关的数据库与存储系统.作者在文章中介绍了Cubrick:一种多维内存数据管理系统.Cubrick是由Facebook开发的新型分布式多维内存数据库管理系统,其目的在于解决大量数据资源并行运行所存在的问题.为达到交互式分析高度动态数据集这一目的,Cubrick运用一种用于管理柱形内存数据的新策略,这种策略允许在数

java-今天面试的时候遇到一个问题,查三张表,有一百万条纪录,怎么查?他是想问什么,数据库优化吗

问题描述 今天面试的时候遇到一个问题,查三张表,有一百万条纪录,怎么查?他是想问什么,数据库优化吗 今天面试的时候遇到一个问题,查三张表,有一百万条纪录,怎么查?他是想问什么,数据库优化吗 解决方案 我不认为索引或分页是重点. 那不是怎么查的问题,而是怎么优化数据库的问题. 我觉得应该是查的方式或访问数据的方式,防止内存溢出,两种方法. 1.用游标查,而不是一下子取到内存中. 2.一回查询一定量数据,取多回. ps: 查的时候,在有必要的时候加上HINT句,可以优化效率. 这个你也说了的话,我觉

友盟推送 在手机端一个用户提交一个信息,其中包含一个“受理人”,让指定的受理人 收到一条推送消息

问题描述 友盟推送 在手机端一个用户提交一个信息,其中包含一个"受理人",让指定的受理人 收到一条推送消息 友盟推送 在手机端一个用户提交一个信息,其中包含一个"受理人",让指定的受理人 收到一条推送消息 怎么实现? 解决方案 首先针对某一个用户推送,必须知道对方的token(信鸽产生的token,每个手机不一样),所以你要有一个后台接口,你提交信息后,接口从数据库中查找这用户的token,然后调用信鸽的接口发推送

可以实现每条推送消息的昵称都自定义么?

问题描述 可以实现每条推送消息的昵称都自定义么? 解决方案 我们下一步会支持自定义推送消息模板.每个app可以有自己特定的模板.但按照备注来推送,这个估计支持起来是有困难的.还没想好怎么支持.