Here's a secret: Mark Zuckerberg didn't write all of Facebook in his dorm room at Harvard. (Sorry, Mark, your secret is out.) He had a lot of help. No, I'm not talking about all the wonderful folks who work on the site every day. I'm talking about the unsung hero of many a young Web site: open-source and free software. Without it, there'd be no Facebook. We use it, we love it, we are committed to its principles, we even make some of it ourselves.
What's open source? Typically it means two things: the software is available free of charge, and more importantly, so are the blueprints, or "source code." This means that anyone is free to make whatever changes they want to the software—maybe improving it or customizing it to make it better-suited to a particular purpose. If someone makes a useful change, they donate it back to the software project for everyone to use.
Here's how Facebook and open source go hand in hand:
Almost all our servers are running open-source software. Our Web servers use Linux and Apache and PHP. Our database servers run MySQL. We use memcached to help keep the site snappy. Some of our behind-the-scenes software is written in Python and Perl and Java, and we use gcc and Boost for the parts that aren't. Our developers use Subversion and git to keep track of their work. The list goes on—like many Web sites, we use it from top to bottom.
But we also make it a point to give back. Our highest-profile contribution to the open-source community is probably phpsh, an interactive PHP environment we use constantly when we work on the site. It was written in-house as a development tool and released to the world for anyone to use and improve. A close second to phpsh is our extensive contribution to the memcached code base; we've heavily modified it, more than doubling its performance and adding several important new features. Both of those are still actively being worked on here, and we will continue to release our updates to the world.
We contribute on a regular basis to the APC project, which just about every page on our site uses. We've contributed code to APD and Xdebug. Finally, we encourage developers everywhere to release code using the Facebook API as open source, and we've released some of our own such as the Facebook Firefox Toolbar.
Share and share alike and the whole world benefits. It was true in kindergarten, and it's still true on the Internet!
Steven, one of Facebook's infrastructure engineers, is probably making yet another change to memcached as you read this.
Feeds
2493 items (0 unread) in 19 feeds
«
Expand/Collapse
-
19:47
Mystic Statistics Heuristics
» FeedBurnerJust in time for the holidays, here's another post about our statistics, and this time we'll describe how we deal with metrics issues, how we think we can improve the kinds of statistics we provide, and admit that despite all this number crunching, we still don't know how many dribs are in a drab (but we know that the answer involves Planck's constant).
With over 500,000 feeds now managed, we deal with statistics anomalies like spiked/tanked subscriber counts, podcast counts, and click counts on a weekly, if not daily basis. Some of these are larger issues than others, obviously. We're sure that the good people at ComScore, HitWise, and other CamelCase-named statistics companies would agree that there are always issues and anomalies popping up that have to be beaten back with gusto like so many zombies in Dawn (or Shawn) of the Dead.
The goal we always set for ourselves is to try to maintain apples-to-apples comparisons across all types of counting and aggregator/client treatment. In other words, we try to say that regardless of what bucket some metric goes in, it should always result in the ability to look at a couple different pieces of the data (feeds, aggregators, podcatchers, etc.) and say "these make sense relative to one another." You set up some heuristics and algorithms that you then try to apply those as universally as possible and take your lumps. It's like the never-ending "uniques" debate that the web stats community has — you try to plant some stakes in the ground that get you to reasonable conclusions when you consider all the data, and then jump off the next bridge when you come to it.
Some of the metrics issues that we are continually addressing include:
- Automated aggregator clicks: There are some niche aggregators and feed-reading clients that will occasionally auto-click every link in a feed, presumably for offline caching or in order to perform some contextual analysis. So you have to come up with mechanisms to discount those clicks in publisher dashboards as not counting toward subscriber click totals.
- Bots as aggregators: Sometimes obvious attempts to cloak some bot, and sometimes just a hard-to-categorize service will emerge that polls a feed from loads of desktops. Now that there are many thousands of feed clients, we sometimes don't see these bots or stats until they appear on a threshold report we create internally. Publishers can see a set of "subscribers" from something that end up falling off the end of the world a month later. What happened? Sometimes the bot just goes away, sometimes it's combination of bot behavior within an otherwise valid client, and then other times after we've learned more about the bot or its behavior, we've concluded that it's not really polling a feed for the purpose of notifying a subscriber or delivering content to a subscriber.
- Default feeds: Some aggregators default subscribe users to a feed in some cases. For example, perhaps you create a new account with an aggregator and announce "I'm interested in technology feeds", and you're auto-subscribed to a list of feeds. What's the right thing to do here when those numbers are reported as subscribers? We've decided to count those as subscribers...the content is being updated for that subscriber and as long as the subscriber doesn't remove it, we generally say that it's not our place to say those aren't "subscribers". Now, we also provide Total Stats publishers with a metric called "Reach," and reach does a good job of helping pro stats customers understand "how much of my total subscriber base is actually opening my feed and looking at it on a day-to-day basis". This helps publishers with large aggregator counts to understand how many of those aggregator subscribers are "active" from day to day. There are a few aggregators that report subscriber counts purely based on "active" users, not cumulative over time, which obviously provides a more accurate running metric.
- Lack of visibility: There are a number of aggregators that provide no insight in their user-agents into the number of subscribers on behalf of whom they are requesting the feed. Obviously, these end up representing some undercounted number of subscribers for any publisher distributed to that aggregator, and this makes it harder for a publisher to understand their true distribution. We work with as many of these aggregators as we can in order to provide publishers with more information.
…to say nothing of the partial podcasts downloads and podcast download bots and other fun with podcast stats.Across the board, we're seeing more and more distinct kinds of user-agents requesting feeds. Here's a quick chart of the growth in unique user-agents we've seen polling feeds just in the last six months.
Caveat Emptor: These chart numbers don't include user-agents with spammy identifiers that are obviously just long random strings, and hundreds of agents like "Shmucky-bot/1.0" and "Shmucky-bot/2.0" are only counted as one distinct user-agent. All of this data excludes the millions of requests a day we capture from clients with completely blank identifiers. Still, you can see the current count is well over 8,000 different kinds of feed reading entities. Everything from aggregators and search crawlers to thousands of mobile feed readers, hundreds of podcatchers, loads of language specific agents, specialty browser toolbars and more.
One of the questions we bounce around here is "what can we do to help people get more information about their statistics in order to better understand how their content is being distributed?" (although we don't speak to ourselves so eloquently). There are a few things we're always working on in this department:
- Provide more statistics. When publishers have more dots to connect, they can draw a more distinct picture of their content distribution traffic. +2 points for the well-executed "dots - picture" metaphor. We'll be rolling out blog stats very very soon (remember the BlogBeat acquisition a ways back?), so publishers can get a nicer picture of their "total readership" across feed and site. This will also help publishers better make sense of anomalies in one area; e.g., did I see a traffic spike to my site the day before I saw a big spike in subscribers? Was I seeing more search traffic to my site during these periods of sustained subscriber growth? etc. We've got more surprises in this stats department as well.
- Be transparent. We wrote up the peek inside TechCrunch's subscriber numbers a couple months ago as a way to help people understand what's behind the numbers. We can do more in this arena like describe the kinds of things we discuss with various publishers about traffic anomalies and other grey areas where the right metric isn't obvious.
- Be Creative. When the market has trouble with some metric or approach or perceives a lack of information, there's an obvious opportunity to step in and provide that data.
-
15:46
九种机会（续）
» 江南春关键词三：娱乐
在未来世界的行销当中大家需要考虑如何把广告植入到娱乐当中，有几个方向可以看到，第一是在音乐行销方面，比如说最明显的案例，ASK FOR MORE，王菲唱的百事可乐的歌，当它在电台被反复播放的时候百事可乐的形象就得到了传播。这些广告和音乐娱乐的东西完全整合在一起，很难忽视它的存在，只要你热爱这个歌星影星就被卷入其中。第二是体育营销，三星也好、联想也好在体育行销中的表现和收获大家看得到，可以看到欧洲足球付费频道的存在，像华谊兄弟这种电视公司不断把广告卷入其中。第三，国外IN GAME的广告，在赛车当中有一块路牌是Intel的广告，在植入式游戏当中的体验更加认可，所以我想这个是未来大家可以看得到的方向。 关键词四：体验式行销
比如宜家，它有很多床、沙发，投影机打在屋顶上，大家可以躺在那边，一边体验宜家的舒适放松，一边获得宜家所要讲的感受。所以我相信像宜家这种体验式会议成为未来很多行销的主要导向。 关键词五：垂直
现在门户网站的市场在继续上升当中，以新浪为代表每年的广告收入依旧呈现高速度的增长。同时也看到垂直网站的崛起，类似东方财富网，作为中国最大的财经门户网站，从流量角度来说，我上次上去看到一篇博客九万人读，专业人员的这种杀伤力会越来越强。这种垂直的网站不单是网站，它可以做得更加深入和深刻，把上下产业链打通。不仅成为最专业的网站，把它延伸到了操盘密码的股票软件，这种上万块一个的软件，可能最后开发出来的成本已经几乎为零了，一天如果可以卖出100套的话，这个我觉得收入是非常恐怖的。所以我想类似像这种垂直性的网站是垂直打通它所在的社群和专业领域，收入是多元化的，以后会有超越于以前一代网站的机会。 （未完）
TOP
RSS
Atom
Powered by Gregarius
Design by eDWARD
© 2008 京ICP备6047014
Last Update: Fri 16 May 2008 01:02:06 PM HKT