answersy.com Blog

这一篇先用中文写。

互联网是什么？互联网是一个计算机联结成的网络。计算机背后坐着形形色色的人。一开始，互联网纯粹是技术驱动的，但是随着它的普及和应用的不断创新，互联网络正在逐步和现实世界的人际网络纠缠得越来越密切。所以，要谈互联网的盈利模式，必须先说线下世界的盈利模式。

什么是盈利？盈利就是产出减去投入。 盈利是一切商业活动最原始、最持久的动力和目的。这是一个再简单不过的道理。我们也知道，所谓“大风险，高回报”。为什么如此？让我们先回到现实世界中，对一些基本的盈利模式作一些分析。

（0）开工厂生产商品。这是基础，规则也很简单：原材料+技术+设备+劳动力=商品。盈利=销售额-成本。
（1）开店做买卖。商店是商品交换场所。开店需要一定的资金投入，行业知识，和对顾客需求的把握。然后，进货、铺货、推广、销售，赚取进出之间的差价。商店分专业店和百货店，前者服务特定人群的特定需求，后者面向大众，以量取胜。

（2）连锁经营。 当商店的口碑和规模发展发展到一定水平之后这是一个很自然的选择。连锁的目的在于用“品牌”对市场进行圈地。经营者玩的是资本和品牌价值。虽然各加盟店内部的经营管理仍很重要，但是连锁经营的关键是资本的运作和圈地的规模。能开出第一家麦当劳的人很多，可能把餐饮业变成道琼斯成分股的就凤毛麟角了。

（3）开市场招商。 这实际上已经脱离了商品的经营，投入是场地的建设和对商家的服务，收的是“租金”或者“过路费”。做市场有一个特点，无论商家买卖是亏是盈，只要有交易，就有盈利。经营市场的风险与宏观经济的健康程度联系在一起，这是“高门槛，低风险”的典型。市场也有专业和普通之分，前者服务特定商家，后者以全取胜。当然，市场也可以跨地域国家连锁经营，进一步增加门槛的高度，更高的门槛往往意味着更有保障的收入流。

（4）开展金融服务。货币是交换的中介，是一种极其特殊的商品。从整个流程上而言，融资总是一个生意的最开始，因此有人说金融业是商业活动的最上游。但是，从整个商业社会的资金归宿而言，金融业又像是万条小溪汇聚成的大河的出海口。承载着最重要的发源地和最庞大的汇聚地这样的双重地位，金融业的“高门槛、高回报”也就是无可厚非了。金融产品可以进一步衍生交易，这又产生了对金融交易市场的需求。

（5）掌握政权。 这个比较赤裸裸，但细细想来却非常靠谱。你才能明白为什么古往今来，争夺政权的斗争会那么残酷和持久。有了权力，就有了驱动众人的可能。掌握了政权，就可以发行货币，征收税赋，甚至以暴力剥夺他人的财务。在力度和广度上，政治对社会的影响力都是普通商业活动难以比拟的。当然，要获得政权，门槛之高可能是要付出很多人的生命，因此，巨额的回报也是可以理解和预期的。

盈利是一个商业模式可以持续发展的前提。因为只有盈利，才能有资本的增值和再投入。现代商业活动还引进了融资的环节，使得某些商业活动可以在一定的时间之内承受亏损的风险，以亏损来交换市场份额和商业壁垒，从而在更长远的时间范围内获得更高的盈利回报。

从上面所列举的盈利模式来看，大回报往往取决于市场占有率和他人进入市场竞争的成本，政策、规模、技术、客户的忠诚度都可以成为竞争对手无法染指利润的壁垒。这一点，互联网上的盈利模式也毫不例外。互联网的一些特殊性，我们将在下一篇仔细分析。

The answer is a big Yes.

A lot of people don't feel this way, but I do. Why? This is the spirit of capitalism: capital will only go after growth, not stable.

As a company, even now, Yahoo is still doing OK, but its growth has slowed down and capital turned to somewhere else. Why Yahoo's growth is halted? People might think Google's competitions is the reason. In my opinion, it is the capital's push. There were a lot of search engines out there when Google was still in its early stage. Capital picked Google to replace Yahoo's directory+banner ads model because Google looked sexy among the infoseeks and altavistas. When the second internet generation grows up, people's nature bond to Yahoo is gone, and Google's dominance became inevitable.

However, Google certainly is not the last stop! As we can see, there are lots of Web 2.0 now, and there will be Web 3.0 for sure. Once a new money-generating model is figured out, Google will become less and less sexy to users and capital. Technology is only a symbol, the money behind it runs it to make more money. Whenever a technology or business model reaches its saturate point, capital will head for new heroes. And the fall of the old stars is going to happen. :-)

It there any way to avoid it? As of now, I don't see any sign in the near future.

Everybody agrees that relevance is vital to information retrieval or a search engine. Hence, I would like to talk a little more on ranking here.

First of all, as an old Chinese saying says, “a brilliant housewife cannot prepare wonderful dinner without rice.” Content quality is absolutely a precondition to search relevance. The whole infrastructure must guarantee that statistically important high-quality documents are so arranged that they will be selected as the “rice” for the housewife to cook. :-)

Second, the housewife actually runs a team to do the job. Ranking function is a set of logics and models. (See figure 1 below)

If the set of all the possible queries is denoted as input space Q, usually, we need to slice Q into smaller sub-regions to handle them separately. Many have dreamed of having one single unified ranking module to handle all the queries, but soon or later, this will hit some bottleneck. The idea is to have a number of individual ranking modules which performance well in a sub-region of Q. The branching logic can be based on length, language, intention or other classification of the queries or user profiles.

Third, we need a merging logic to combine the outputs of different ranking modules. Sometimes we trust one ranking module so much that others won’t even be called. Sometimes we might want to run more than one ranking modules in parallel and blend their results. In general, the merging logic should be based upon the following heuristic: if ranking module i performs better than module j in a sub-domain of Q, for a given query q in this sub-domain, i’s output should have higher weight than j’s. This is to trust the experts’ domain knowledge. The final weights also need to be tuned either manually or by some statistical modeling procedure.

To summarize, content quality + committee of special ranking modules = solution.

1. Life cycle of an internet service

• To understand user needs by studying and aggregating existing user behaviors
• By adding creative ideas, to come up with a wish list of projects
• To study technical feasibility
• To make business decision on projects priority and time lines
• To develop and build the service
  • Data acquisition/analysis/processing
  • Service logic should be a combination of human logic and data-driven models
    
  • System architecture
  • Detailed work flow and user interface
  • To define and implement metrics to measure the quality of the service
  • To define and implement process to monitor clients' behaviors
• To operate the service based upon metrics
  • to monitor users' behaviors and the quality of the service
  • To analysis operational data by
    • monitoring and analyzing the metrics
    • bucket testing to understand different configuration's impact
  • To come up with ideas to improve the service
  • To directly feed (aggregated) operational data to the service work flow
  • marketing/business development

2. The success of any internet service lies in the following factors

• Creative ideas to solve some real life problem
• Right timing to enter the market
• Constant interactions with the clients
• Incorporate aggregated users behavior data into the service itself
• Customizable to fit individual needs

3. Execution

• Data warehouse to collect user - access - click - transaction data
• Multi-dimensional data storage to support data analysis and aggregation
• Aggregation on different-level with different time-granularity
• Graphic presentation of the key metrics
• Feedback loop

A lot of web services talk about Personalization.

As we may know, matching contents with audiences' intention is the key value of any publishing site, especially web search.

Usually, web services use aggregated features to improve relevance. For example, Google's famous PageRank: if a lot of pages link to this one, it is important! Another example would be recommended posts on a BBS site or Blog RSS engagement service like feedburner.com. Usually, they are based on popularity: if a lot of people click on this, it is good; if a lot of people subscribe to this, it is cool!
In general, this aggregation approach will achieve "much-better-than-random-pick" results. However, for a given individual, this is NOT good enough: a lot of people like ipod, but I prefer zune. Hence, when searching for "mp3 player," I might want to see more zune results ;-)

The difficulty of personalization lies in two major factors: (1) huge possible combinations of different profiles (2) how to get and store users' profile.
So, how to address this issue?

I have to say, there is no out-of-package solution out there yet. But, the more you address this, the better position you are in the future competition! Hence, if you want to provide a serious web service to general audience, you want to think about personalization from the beginning of the system design.

Here are some preliminary thinkings:

(1) keep track of all the links a user clicks on your site

(2) have all the links classified based on some criteria
(3) aggregate over user, links classes, and time-frame, and keep the summarized data in user's cookie

(4) deliver contents using the summarized data as parameters

For example, if a search engine finds a user (cookie) clicks commercial links very often recently, it should really start to push more ads to him. If a user clicks sports links very often, showing sport-related ads will achieve better results.

Remember, Personalization is not about being perfect, it is about achieving competitive advance!

Let's consider ranking.

What is ranking? In information retrieval, ranking is to order "matched documents."

We need to define matching first. If user queries "mp3," can "ipod" in a document be considered as matched? In general, I feel so. But usually, most search engines will be very conservative in doing so.

Besides whether query terms match the document or not, we also need to consider where the matchings happen. They can happen at the title, header or body section, sometimes at anchor text or other meta information like "url" or "tag" sections. Of course, matching proximity is another important consideration. These are all standard information retrieval issues.

In my opinion, understanding query intention is the key to improve ranking. There is NO "general ranking algorithm" for all type of queries and it does not make sense to try to build one. As a result, overall, a good ranking function should be the combination of heuristic logics with data-trained logics. Namely, we can slice data into different categories to train special ranking models for each category, while at the same time develop algorithms to make decision on how to pick ranking modules for a given query.

From example, for English query, if the url string or host name matches the query terms, it can be a very strong indicator of "good matching", this may not be applicable at all for Asian languages. So we need a language detection module before applying ranking modules.

Query -> Language Detection -> English Logic, Chinese Logic ...
The key is how many manually maintained logic forks we can keep so that the data trained ranking module at the leaf can perform well enough. We also need to balance the cost of maintaining a list of such modules with the performance gain by going specialty.

Content language: English, Chinese, Russian, …

Geography: Country, City, Zip-code, Neighborhood, …

Information type: Products, Events, People, Blogs, News, …

Content type: Text, Image, Video, Audio, …

Subject type: Finance, Business, Jobs, Housing, Cooking, …

User type: Profession, Culture, Education, Gender, Age, …

Medium: Desktop, PDA, Voice, Cell Phone…

Content source: Web, Feeds, Submits, …
In general, a vertical should and will do much better than someone who wants to cover everything. Specialty is the way to go! On the other hand, when vertical contents are focused, much narrowed audience will be there. As a result, you can see Google and Yahoo have a number of vertical tabs on their search page, but very few people actually use these vertical search products. This is also why Google rolls out "Universal Search" while ask.com heads towards federated search result page, or combo search if you will. They want the vertical searches to be more visible and contribute to their whole page relevance.
In my view, the key is to understand user intentions. If we are very confident that a user is looking for an image, why not show image search results directly to them?

If a user is looking for commercial or sales information, why not show advertisements to them?

How to be sure of users' intention? We need data, and algorithms to analysis the data, models to handle them. But sometimes, we also need some simple UI designs to help users to tell us their intentions.

For example, if a user search for "Mushroom Image," we can show image search results to them directly, with one sentence added:

Hint: I think you are looking for images, if not, I can show you Web Search or Video result :-)

If the users are trained to look at this hint, he will find this very helpful.

There are two other ways to improve upon this.

(1) Keep track of all users' aggregated reaction to the results we present

(2) Keep track of individual user's reaction history

If we can feed back the tracking data to the algorithm that delivers the results to users as parameters, they can improve users experience a lot!