随着互联网的发展 估计大多数的产品都会遇到推荐机制的策划，作为互联网产品人员也需要研究一下推荐机制的核心算法，这篇文章是我看到的言简意赅讲了一些基础的推荐机制的文章，转过来分享给大家

信息发现

如今已经进入了一个数据爆炸的时代，随着 Web 2.0 的发展， Web 已经变成数据分享的平台，那么，如何让人们在海量的数据中想要找到他们需要的信息将变得越来越难。

在这样的情形下，搜索引擎（Google，Bing，百度等等）成为大家快速找到目标信息的最好途径。在用户对自己需求相对明确的时候，用搜索引擎很方便的通过关键字搜索很快的找到自己需要的信息。但搜索引擎并不能完全满足用户对信息发现的需求，那是因为在很多情况下，用户其实并不明确自己的需要，或者他们的需求很难用简单的关键字来表述。又或者他们需要更加符合他们个人口味和喜好的结果，因此出现了推荐系统，与搜索引擎对应，大家也习惯称它为推荐引擎。

随着推荐引擎的出现，用户获取信息的方式从简单的目标明确的数据的搜索转换到更高级更符合人们使用习惯的信息发现。

如今，随着推荐技术的不断发展，推荐引擎已经在电子商务 (E-commerce，例如 Amazon，当当网 ) 和一些基于 social 的社会化站点 ( 包括音乐，电影和图书分享，例如豆瓣，Mtime 等 ) 都取得很大的成功。这也进一步的说明了，Web2.0 环境下，在面对海量的数据，用户需要这种更加智能的，更加了解他们需求，口味和喜好的信息发现机制。

推荐引擎

前面介绍了推荐引擎对于现在的 Web2.0 站点的重要意义，这一章我们将讲讲推荐引擎到底是怎么工作的。推荐引擎利用特殊的信息过滤技术，将不同的物品或内容推荐给可能对它们感兴趣的用户。

推荐引擎的分类

图 1 给出了推荐引擎的工作原理图，这里先将推荐引擎看作黑盒，它接受的输入是推荐的数据源，一般情况下，推荐引擎所需要的数据源包括：

• 要推荐物品或内容的元数据，例如关键字，基因描述等；
• 系统用户的基本信息，例如性别，年龄等
• 用户对物品或者信息的偏好，根据应用本身的不同，可能包括用户对物品的评分，用户查看物品的记录，用户的购买记录等。其实这些用户的偏好信息可以分为两类：

• 显式的用户反馈：这类是用户在网站上自然浏览或者使用网站以外，显式的提供反馈信息，例如用户对物品的评分，或者对物品的评论。
• 隐式的用户反馈：这类是用户在使用网站是产生的数据，隐式的反应了用户对物品的喜好，例如用户购买了某物品，用户查看了某物品的信息等等。

显式的用户反馈能准确的反应用户对物品的真实喜好，但需要用户付出额外的代价，而隐式的用户行为，通过一些分析和处理，也能反映用户的喜好，只是数据不是很精确，有些行为的分析存在较大的噪音。但只要选择正确的行为特征，隐式的用户反馈也能得到很好的效果，只是行为特征的选择可能在不同的应用中有很大的不同，例如在电子商务的网站上，购买行为其实就是一个能很好表现用户喜好的隐式反馈。

推荐引擎根据不同的推荐机制可能用到数据源中的一部分，然后根据这些数据，分析出一定的规则或者直接对用户对其他物品的喜好进行预测计算。这样推荐引擎可以在用户进入的时候给他推荐他可能感兴趣的物品。

推荐引擎

推荐引擎的分类可以根据很多指标，下面我们一一介绍一下：

1. 推荐引擎是不是为不同的用户推荐不同的数据根据这个指标，推荐引擎可以分为基于大众行为的推荐引擎和个性化推荐引擎
   • 根据大众行为的推荐引擎，对每个用户都给出同样的推荐，这些推荐可以是静态的由系统管理员人工设定的，或者基于系统所有用户的反馈统计计算出的当下比较流行的物品。
   • 个性化推荐引擎，对不同的用户，根据他们的口味和喜好给出更加精确的推荐，这时，系统需要了解需推荐内容和用户的特质，或者基于社会化网络，通过找到与当前用户相同喜好的用户，实现推荐。

   这是一个最基本的推荐引擎分类，其实大部分人们讨论的推荐引擎都是将个性化的推荐引擎，因为从根本上说，只有个性化的推荐引擎才是更加智能的信息发现过程。

2. 根据推荐引擎的数据源其实这里讲的是如何发现数据的相关性，因为大部分推荐引擎的工作原理还是基于物品或者用户的相似集进行推荐。那么参考图 1 给出的推荐系统原理图，根据不同的数据源发现数据相关性的方法可以分为以下几种：
   • 根据系统用户的基本信息发现用户的相关程度，这种被称为基于人口统计学的推荐（Demographic-based Recommendation）
   • 根据推荐物品或内容的元数据，发现物品或者内容的相关性，这种被称为基于内容的推荐（Content-based Recommendation）
   • 根据用户对物品或者信息的偏好，发现物品或者内容本身的相关性，或者是发现用户的相关性，这种被称为基于协同过滤的推荐（Collaborative Filtering-based Recommendation）。
3. 根据推荐模型的建立方式可以想象在海量物品和用户的系统中，推荐引擎的计算量是相当大的，要实现实时的推荐务必需要建立一个推荐模型，关于推荐模型的建立方式可以分为以下几种：
   • 基于物品和用户本身的，这种推荐引擎将每个用户和每个物品都当作独立的实体，预测每个用户对于每个物品的喜好程度，这些信息往往是用一个二维矩阵描述的。由于用户感兴趣的物品远远小于总物品的数目，这样的模型导致大量的数据空置，即我们得到的二维矩阵往往是一个很大的稀疏矩阵。同时为了减小计算量，我们可以对物品和用户进行聚类， 然后记录和计算一类用户对一类物品的喜好程度，但这样的模型又会在推荐的准确性上有损失。
   • 基于关联规则的推荐（Rule-based Recommendation）：关联规则的挖掘已经是数据挖掘中的一个经典的问题，主要是挖掘一些数据的依赖关系，典型的场景就是“购物篮问题”，通过关联规则的挖掘，我们可以找到哪些物品经常被同时购买，或者用户购买了一些物品后通常会购买哪些其他的物品，当我们挖掘出这些关联规则之后，我们可以基于这些规则给用户进行推荐。
   • 基于模型的推荐（Model-based Recommendation）：这是一个典型的机器学习的问题，可以将已有的用户喜好信息作为训练样本，训练出一个预测用户喜好的模型，这样以后用户在进入系统，可以基于此模型计算推荐。这种方法的问题在于如何将用户实时或者近期的喜好信息反馈给训练好的模型，从而提高推荐的准确度。

其实在现在的推荐系统中，很少有只使用了一个推荐策略的推荐引擎，一般都是在不同的场景下使用不同的推荐策略从而达到最好的推荐效果，例如 Amazon 的推荐，它将基于用户本身历史购买数据的推荐，和基于用户当前浏览的物品的推荐，以及基于大众喜好的当下比较流行的物品都在不同的区域推荐给用户，让用户可以从全方位的推荐中找到自己真正感兴趣的物品。

这一章的篇幅，将详细介绍各个推荐机制的工作原理，它们的优缺点以及应用场景。

基于人口统计学的推荐

基于人口统计学的推荐机制（Demographic-based Recommendation）是一种最易于实现的推荐方法，它只是简单的根据系统用户的基本信息发现用户的相关程度，然后将相似用户喜爱的其他物品推荐给当前用户，图 2 给出了这种推荐的工作原理。
图 2. 基于人口统计学的推荐机制的工作原理

从图中可以很清楚的看到，首先，系统对每个用户都有一个用户 Profile 的建模，其中包括用户的基本信息，例如用户的年龄，性别等等；然后，系统会根据用户的 Profile 计算用户的相似度，可以看到用户 A 的 Profile 和用户 C 一样，那么系统会认为用户 A 和 C 是相似用户，在推荐引擎中，可以称他们是“邻居”；最后，基于“邻居”用户群的喜好推荐给当前用户一些物品，图中将用户 A 喜欢的物品 A 推荐给用户 C。

这种基于人口统计学的推荐机制的好处在于：

1. 因为不使用当前用户对物品的喜好历史数据，所以对于新用户来讲没有“冷启动（Cold Start）”的问题。
2. 这个方法不依赖于物品本身的数据，所以这个方法在不同物品的领域都可以使用，它是领域独立的（domain-independent）。

那么这个方法的缺点和问题是什么呢？这种基于用户的基本信息对用户进行分类的方法过于粗糙，尤其是对品味要求较高的领域，比如图书，电影和音乐等领域，无法得到很好的推荐效果。可能在一些电子商务的网站中，这个方法可以给出一些简单的推荐。另外一个局限是，这个方法可能涉及到一些与信息发现问题本身无关却比较敏感的信息，比如用户的年龄等，这些用户信息不是很好获取。

基于内容的推荐

基于内容的推荐是在推荐引擎出现之初应用最为广泛的推荐机制，它的核心思想是根据推荐物品或内容的元数据，发现物品或者内容的相关性，然后基于用户以往的喜好记录，推荐给用户相似的物品。图 3 给出了基于内容推荐的基本原理。
图 3. 基于内容推荐机制的基本原理

图 3 中给出了基于内容推荐的一个典型的例子，电影推荐系统，首先我们需要对电影的元数据有一个建模，这里只简单的描述了一下电影的类型；然后通过电影的元数据发现电影间的相似度，因为类型都是“爱情，浪漫”电影 A 和 C 被认为是相似的电影（当然，只根据类型是不够的，要得到更好的推荐，我们还可以考虑电影的导演，演员等等）；最后实现推荐，对于用户 A，他喜欢看电影 A，那么系统就可以给他推荐类似的电影 C。

这种基于内容的推荐机制的好处在于它能很好的建模用户的口味，能提供更加精确的推荐。但它也存在以下几个问题：

1. 需要对物品进行分析和建模，推荐的质量依赖于对物品模型的完整和全面程度。在现在的应用中我们可以观察到关键词和标签（Tag）被认为是描述物品元数据的一种简单有效的方法。
2. 物品相似度的分析仅仅依赖于物品本身的特征，这里没有考虑人对物品的态度。
3. 因为需要基于用户以往的喜好历史做出推荐，所以对于新用户有“冷启动”的问题。

虽然这个方法有很多不足和问题，但他还是成功的应用在一些电影，音乐，图书的社交站点，有些站点还请专业的人员对物品进行基因编码，比如潘多拉，在一份报告中说道，在潘多拉的推荐引擎中，每首歌有超过 100 个元数据特征，包括歌曲的风格，年份，演唱者等等。

基于协同过滤的推荐

随着 Web2.0 的发展，Web 站点更加提倡用户参与和用户贡献，因此基于协同过滤的推荐机制因运而生。它的原理很简单，就是根据用户对物品或者信息的偏好，发现物品或者内容本身的相关性，或者是发现用户的相关性，然后再基于这些关联性进行推荐。基于协同过滤的推荐可以分为三个子类：基于用户的推荐（User-based Recommendation），基于项目的推荐（Item-based Recommendation）和基于模型的推荐（Model-based Recommendation）。下面我们一个一个详细的介绍着三种协同过滤的推荐机制。

基于用户的协同过滤推荐

基于用户的协同过滤推荐的基本原理是，根据所有用户对物品或者信息的偏好，发现与当前用户口味和偏好相似的“邻居”用户群，在一般的应用中是采用计算“K- 邻居”的算法；然后，基于这 K 个邻居的历史偏好信息，为当前用户进行推荐。下图 4 给出了原理图。
图 4. 基于用户的协同过滤推荐机制的基本原理

上图示意出基于用户的协同过滤推荐机制的基本原理，假设用户 A 喜欢物品 A，物品 C，用户 B 喜欢物品 B，用户 C 喜欢物品 A ，物品 C 和物品 D；从这些用户的历史喜好信息中，我们可以发现用户 A 和用户 C 的口味和偏好是比较类似的，同时用户 C 还喜欢物品 D，那么我们可以推断用户 A 可能也喜欢物品 D，因此可以将物品 D 推荐给用户 A。

基于用户的协同过滤推荐机制和基于人口统计学的推荐机制都是计算用户的相似度，并基于“邻居”用户群计算推荐，但它们所不同的是如何计算用户的相似度，基于人口统计学的机制只考虑用户本身的特征，而基于用户的协同过滤机制可是在用户的历史偏好的数据上计算用户的相似度，它的基本假设是，喜欢类似物品的用户可能有相同或者相似的口味和偏好。

基于项目的协同过滤推荐

基于项目的协同过滤推荐的基本原理也是类似的，只是说它使用所有用户对物品或者信息的偏好，发现物品和物品之间的相似度，然后根据用户的历史偏好信息，将类似的物品推荐给用户，图 5 很好的诠释了它的基本原理。

假设用户 A 喜欢物品 A 和物品 C，用户 B 喜欢物品 A，物品 B 和物品 C，用户 C 喜欢物品 A，从这些用户的历史喜好可以分析出物品 A 和物品 C 时比较类似的，喜欢物品 A 的人都喜欢物品 C，基于这个数据可以推断用户 C 很有可能也喜欢物品 C，所以系统会将物品 C 推荐给用户 C。

与上面讲的类似，基于项目的协同过滤推荐和基于内容的推荐其实都是基于物品相似度预测推荐，只是相似度计算的方法不一样，前者是从用户历史的偏好推断，而后者是基于物品本身的属性特征信息。
图 5. 基于项目的协同过滤推荐机制的基本原理

同时协同过滤，在基于用户和基于项目两个策略中应该如何选择呢？其实基于项目的协同过滤推荐机制是 Amazon 在基于用户的机制上改良的一种策略，因为在大部分的 Web 站点中，物品的个数是远远小于用户的数量的，而且物品的个数和相似度相对比较稳定，同时基于项目的机制比基于用户的实时性更好一些。但也不是所有的场景都是这样的情况，可以设想一下在一些新闻推荐系统中，也许物品，也就是新闻的个数可能大于用户的个数，而且新闻的更新程度也有很快，所以它的形似度依然不稳定。所以，其实可以看出，推荐策略的选择其实和具体的应用场景有很大的关系。

基于模型的协同过滤推荐

基于模型的协同过滤推荐就是基于样本的用户喜好信息，训练一个推荐模型，然后根据实时的用户喜好的信息进行预测，计算推荐。

基于协同过滤的推荐机制是现今应用最为广泛的推荐机制，它有以下几个显著的优点：

1. 它不需要对物品或者用户进行严格的建模，而且不要求物品的描述是机器可理解的，所以这种方法也是领域无关的。
2. 这种方法计算出来的推荐是开放的，可以共用他人的经验，很好的支持用户发现潜在的兴趣偏好

而它也存在以下几个问题：

1. 方法的核心是基于历史数据，所以对新物品和新用户都有“冷启动”的问题。
2. 推荐的效果依赖于用户历史偏好数据的多少和准确性。
3. 在大部分的实现中，用户历史偏好是用稀疏矩阵进行存储的，而稀疏矩阵上的计算有些明显的问题，包括可能少部分人的错误偏好会对推荐的准确度有很大的影响等等。
4. 对于一些特殊品味的用户不能给予很好的推荐。
5. 由于以历史数据为基础，抓取和建模用户的偏好后，很难修改或者根据用户的使用演变，从而导致这个方法不够灵活。

混合的推荐机制

在现行的 Web 站点上的推荐往往都不是单纯只采用了某一种推荐的机制和策略，他们往往是将多个方法混合在一起，从而达到更好的推荐效果。关于如何组合各个推荐机制，这里讲几种比较流行的组合方法。

1. 加权的混合（Weighted Hybridization）: 用线性公式（linear formula）将几种不同的推荐按照一定权重组合起来，具体权重的值需要在测试数据集上反复实验，从而达到最好的推荐效果。
2. 切换的混合（Switching Hybridization）：前面也讲到，其实对于不同的情况（数据量，系统运行状况，用户和物品的数目等），推荐策略可能有很大的不同，那么切换的混合方式，就是允许在不同的情况下，选择最为合适的推荐机制计算推荐。
3. 分区的混合（Mixed Hybridization）：采用多种推荐机制，并将不同的推荐结果分不同的区显示给用户。其实，Amazon，当当网等很多电子商务网站都是采用这样的方式，用户可以得到很全面的推荐，也更容易找到他们想要的东西。
4. 分层的混合（Meta-Level Hybridization）: 采用多种推荐机制，并将一个推荐机制的结果作为另一个的输入，从而综合各个推荐机制的优缺点，得到更加准确的推荐。

推荐引擎应用

介绍完推荐引擎的基本原理，基本推荐机制，下面简要分析几个有代表性的推荐引擎的应用，这里选择两个领域：Amazon 作为电子商务的代表，豆瓣作为社交网络的代表。

推荐在电子商务中的应用 – Amazon

Amazon 作为推荐引擎的鼻祖，它已经将推荐的思想渗透在应用的各个角落。Amazon 推荐的核心是通过数据挖掘算法和比较用户的消费偏好于其他用户进行对比，借以预测用户可能感兴趣的商品。对应于上面介绍的各种推荐机制，Amazon 采用的是分区的混合的机制，并将不同的推荐结果分不同的区显示给用户，图 6 和图 7 展示了用户在 Amazon 上能得到的推荐。
图 6. Amazon 的推荐机制 – 首页

图 7. Amazon 的推荐机制 – 浏览物品

Amazon 利用可以记录的所有用户在站点上的行为，根据不同数据的特点对它们进行处理，并分成不同区为用户推送推荐：

• 今日推荐 (Today’s Recommendation For You): 通常是根据用户的近期的历史购买或者查看记录，并结合时下流行的物品给出一个折中的推荐。
• 新产品的推荐 (New For You): 采用了基于内容的推荐机制 (Content-based Recommendation)，将一些新到物品推荐给用户。在方法选择上由于新物品没有大量的用户喜好信息，所以基于内容的推荐能很好的解决这个“冷启动”的问题。
• 捆绑销售 (Frequently Bought Together): 采用数据挖掘技术对用户的购买行为进行分析，找到经常被一起或同一个人购买的物品集，进行捆绑销售，这是一种典型的基于项目的协同过滤推荐机制。
• 别人购买 / 浏览的商品 (Customers Who Bought/See This Item Also Bought/See): 这也是一个典型的基于项目的协同过滤推荐的应用，通过社会化机制用户能更快更方便的找到自己感兴趣的物品。

值得一提的是，Amazon 在做推荐时，设计和用户体验也做得特别独到：

Amazon 利用有它大量历史数据的优势，量化推荐原因。

• 基于社会化的推荐，Amazon 会给你事实的数据，让用户信服，例如：购买此物品的用户百分之多少也购买了那个物品；
• 基于物品本身的推荐，Amazon 也会列出推荐的理由，例如：因为你的购物框中有 ***，或者因为你购买过 ***，所以给你推荐类似的 ***。

另外，Amazon 很多推荐是基于用户的 profile 计算出来的，用户的 profile 中记录了用户在 Amazon 上的行为，包括看了那些物品，买了那些物品，收藏夹和 wish list 里的物品等等，当然 Amazon 里还集成了评分等其他的用户反馈的方式，它们都是 profile 的一部分，同时，Amazon 提供了让用户自主管理自己 profile 的功能，通过这种方式用户可以更明确的告诉推荐引擎他的品味和意图是什么。

推荐在社交网站中的应用 – 豆瓣

豆瓣是国内做的比较成功的社交网站，它以图书，电影，音乐和同城活动为中心，形成一个多元化的社交网络平台，自然推荐的功能是必不可少的，下面我们看看豆瓣是如何推荐的。
图 8 . 豆瓣的推荐机制 – 豆瓣电影

当你在豆瓣电影中将一些你看过的或是感兴趣的电影加入你看过和想看的列表里，并为它们做相应的评分，这时豆瓣的推荐引擎已经拿到你的一些偏好信息，那么它将给你展示如图 8 的电影推荐。
图 9 . 豆瓣的推荐机制 – 基于用户品味的推荐

豆瓣的推荐是通过“豆瓣猜”，为了让用户清楚这些推荐是如何来的，豆瓣还给出了“豆瓣猜”的一个简要的介绍。

“你的个人推荐是根据你的收藏和评价自动得出的，每个人的推荐清单都不同。你的收藏和评价越多，豆瓣给你的推荐会越准确和丰富。
每天推荐的内容可能会有变化。随着豆瓣的长大，给你推荐的内容也会越来越准。”

这一点让我们可以清晰明了的知道，豆瓣必然是基于社会化的协同过滤的推荐，这样用户越多，用户的反馈越多，那么推荐的效果会越来越准确。

相对于 Amazon 的用户行为模型，豆瓣电影的模型更加简单，就是“看过”和“想看”，这也让他们的推荐更加专注于用户的品味，毕竟买东西和看电影的动机还是有很大不同的。

另外，豆瓣也有基于物品本身的推荐，当你查看一些电影的详细信息的时候，他会给你推荐出“喜欢这个电影的人也喜欢的电影”， 如图 10，这是一个基于协同过滤的应用。

总结

在网络数据爆炸的年代，如何让用户更快的找到想要的数据，如何让用户发现自己潜在的兴趣和需求，无论是对于电子商务还是社会网络的应用都是至关重要的。推荐引擎的出现，使得这个问题越来越被大家关注。但对大多数人来讲，也许还在惊叹它为什么总是能猜到你到底想要些什么。推荐引擎的魔力在于你不清楚在这个推荐背后，引擎到底记录和推理了些什么。

通过这篇综述性的文章，你可以了解，其实推荐引擎只是默默的记录和观察你的一举一动，然后再借由所有用户产生的海量数据分析和发现其中的规律，进而慢慢的了解你，你的需求，你的习惯，并默默的无声息的帮助你快速的解决你的问题，找到你想要的东西。

其实，回头想想，很多时候，推荐引擎比你更了解你自己。

通过第一篇文章，相信大家对推荐引擎有一个清晰的第一印象，本系列的下一篇文章将深入介绍基于协同过滤的推荐策略。在现今的推荐技术和算法中，最被大家广泛认可和采用的就是基于协同过滤的推荐方法。它以其方法模型简单，数据依赖性低，数据方便采集，推荐效果较优等多个优点成为大众眼里的推荐算法“No.1”。本文将带你深入了解协同过滤的秘密，并给出基于 Apache Mahout 的协同过滤算法的高效实现。Apache Mahout 是 ASF 的一个较新的开源项目，它源于 Lucene，构建在 Hadoop 之上，关注海量数据上的机器学习经典算法的高效实现。

图 10 . 豆瓣的推荐机制 – 基于电影本身的推荐

在网络数据爆炸的年代，如何让用户更快的找到想要的数据，如何让用户发现自己潜在的兴趣和需求，无论是对于电子商务还是社会网络的应用都是至关重要的。推荐引擎的出现，使得这个问题越来越被大家关注。但对大多数人来讲，也许还在惊叹它为什么总是能猜到你到底想要些什么。推荐引擎的魔力在于你不清楚在这个推荐背后，引擎到底记录和推理了些什么。

通过这篇综述性的文章，你可以了解，其实推荐引擎只是默默的记录和观察你的一举一动，然后再借由所有用户产生的海量数据分析和发现其中的规律，进而慢慢的了解你，你的需求，你的习惯，并默默的无声息的帮助你快速的解决你的问题，找到你想要的东西。

其实，回头想想，很多时候，推荐引擎比你更了解你自己。

通过第一篇文章，相信大家对推荐引擎有一个清晰的第一印象，本系列的下一篇文章将深入介绍基于协同过滤的推荐策略。在现今的推荐技术和算法中，最被大家广泛认可和采用的就是基于协同过滤的推荐方法。它以其方法模型简单，数据依赖性低，数据方便采集，推荐效果较优等多个优点成为大众眼里的推荐算法“No.1”。本文将带你深入了解协同过滤的秘密，并给出基于 Apache Mahout 的协同过滤算法的高效实现。Apache Mahout 是 ASF 的一个较新的开源项目，它源于 Lucene，构建在 Hadoop 之上，关注海量数据上的机器学习经典算法的高效实现。

转自：http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy1/index.html

这次改版所耗费的时间不算短,尤其在互联网产品里,不过整体也不是简单view层的一些变化

搜课网在去年10月正式推出了 电话咨询服务业务,随之带来的也是将KPI进行了升级,电话咨询量成为了很重要的指标之一

这次转型式的改版也是将这项服务更加突出,去访问看看?http://www.sooker.com

具体改版内容先卖个关子吧,等有数据后再来继续水~

也欢迎有兴趣的朋友与我共同沟通

2010年11月22日，Axure公司释出了最新的Axure RP 6.0.0.2826测试版。

Axure RP 6是一次重大版本升级，全新的架构。
PC版本与Mac版本达到了风格统一。这次同时放出了它们的测试版。
PC版安装过程中会自动更新.NET Framework4.0。

Axure RP 6.0.0.2826备用下载：
英文PC版下载地址：http://u.115.com/file/f9d967ce12
汉化包下载地址：http://www.webppd.com/thread-2143-1-1.html
(先安装英文原型，再把汉化包文件覆盖到axure安装目录，英文原版与汉化包的版本要对应。)

英文Mac版下载地址：
http://maxure.s3.amazonaws.com/AxureRP-Pro-Beta-Setup.dmg

此次Axure RP 6 Beta版新增功能下面一一道来：

1. 可以设置页面背景图片、颜色以及相对于浏览器整体居中了。

2. 可以设置整体在线框边缘变为手绘风格的，以及是否彩色输出。

3. 因为是全新的架构，不再存在某些输入法中文无法输入的问题。

4. 可以设置文本行间距了，同时个性化字体可以输出到Html。

5. 更加易用的事件编辑器，再也不会像之前版本那样，编辑器窗口自动变大了。

6. 输出Html时可以选择用哪个浏览器打开。

7. 增加了栅格系统，自带960宽的12栅和16栅。
在菜单栏：Wireframe-Grid and Guides-Create Guides…中

8. 增加了页面和模块的搜索功能。

9. 增加了快速隐藏网格的快捷键。Ctrl+’

10. 新的测试版本不能再输出Word2000格式的文档了，只能是Word2007格式。

11. 兼容性，用Axure6可以打开以前所有版本制作的RP源文件，但是如果是Axure6制作的RP源文件，将无法使用像Axure5.6这样的低版本打开。

12. 取消了原来的状态栏，改为拖放组件时直接在右下角显示组件的位置和大小。

13. 没有了原来的收起工具面板，不知是为何考虑的。如果能有像Photoshop那样的Tab隐藏工具面板的快捷键就方便了。

14. 条件判断，判断组件或变量值时增加了包含与不包含，这下可以判断输入框是不是包含@符号，用于判断是不是邮箱地址了。同时还增加了一个不是数字或字母的判断，原来版本只有“是”数字或字母的判断。

15. 增加了针对变量或组件值的公式计算，貌似可以加减乘除运算了，还可以插入当前日期或页面名称。具体怎么使用还不熟悉。

16. 可以创建临时中间变量，方便记录各输入组件的值，而不是设置全局变量。

17. 增加了三个可用于条件判断的类型：
1. text on focused widget 是判断当前光标所在的组件内容值。
2. drag cursor 拖动鼠标的判断（目前我还不知道是干吗用的）。
3. widget rectangle 可以判断两个矩形组件是不是叠放在了一起（不知道有何实用性）。

18. 增加了一个可被赋值的类型：
1. text on focused widget 给当前光标所在组件的文本赋值。

19. 矩形右键多了个分配给某个组，不知干什么用的。（可能和未来拖拽有关）

20. 右键有了特殊性粘贴，但试了试并不清楚怎么用。

转载自
http://www.webppd.com/thread-2121-1-1.html

首先，搞清楚商品与单品的区别。例如，iphone是一个单品，但是在淘宝上当很多商家同时出售这个产品的时候，iphone就是一个商品了。

商品：淘宝叫item，京东叫product，商品特指与商家有关的商品，每个商品有一个商家编码，每个商品下面有多个颜色，款式，可以有多个SKU。

SPU = Standard Product Unit （标准化产品单元）

SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。通俗点讲，属性值、特性相同的商品就可以称为一个SPU。

例如，iphone4就是一个SPU，N97也是一个SPU，这个与商家无关，与颜色、款式、套餐也无关。以化妆品为例，下图是拍拍商城给出的SPU信息：

在商品信息电子化过程中，商品的特性可以由多个“属性及对应的属性值对”进行描述。“属性及对应的属性值对”完全相同的商品，可以抽象成为一个SPU。同 时，这些“属性及对应的属性值对”也在SPU中固化下来，逐步标准化。基于SPU的商品信息结构，可以实现丰富的应用，比如商品信息与资讯、评论、以及其 它SPU的整合。

P.s：从这个意义上讲，我认为比较购物的产品库以SPU为标准来建立是最合适的。

SKU=stock keeping unit(库存量单位)

SKU即库存进出计量的单位， 可以是以件、盒、托盘等为单位。在服装、鞋类商品中使用最多最普遍。 例如纺织品中一个SKU通常表示：规格、颜色、款式。

也有人解释说SKU就是库存的最小单位，在服装行业，正常情况是“单款单色单码”，国内品牌有把“单款单色”当做一个SKU、也有把“单款”的几个色当一个SKU、也有把一块面料的几个个款式当一个SKU,这些都是误读。

同时，引申出另外一个概念：SKC：单款、单色。如果一定要打比方的话：SKC是一个桔子，SKU是一瓣桔子，但不管怎么说，一个桔子是桔子，一瓣桔子也是桔子。

不过，SKU是物理上不可分割的最小存货单元。在使用时要根据不同业态，不同管 理模式来处理。比如一香烟是50条，一条里有十盒，一盒中有20支，这些单位就要根据不同的需要来设定SKU。比如仓储批发式大卖场，一定是按照一箱来设 定的。普通大卖场一定是按照条来设定的。烟酒专卖店一定是按照盒来设定的。过去上海等地的街边小店一定是按一支来设定的。这样一支就是烟的最小零售单位。 但要根据自己的业态和服务模式来设定。

P.s:关于什么是SKU、SKC，可以参考阿福先生的这篇博客。

【总结一下】：SPU是标准化产品单元，区分品种；SKU是库存量单位，区分单品；商品特指与商家有关的商品，可对应多个SKU。

ARPU=Average Revenue Per User(每用户平均收入)

ARPU注重的是一个时间段内运营商从每个用户所得到的利润。因此，高端的用户越多，ARPU越高。在这个时间段里，从运营商的运营情况来看，ARPU值高说明利润高，这段时间效益好。
转自：http://www.ikent.me/blog/3017

信任度，本质上就是他人的行为结果是否符合你的预期，而预期来源于他的承诺，或他给你的感觉。
信任是一种结果，而建立信任的过程，就是诚信。诚信不是说出来，而是做出来，要让客户感觉到。越声张“网站值得信赖”，越容易失去用户信任。

信任度，是提升电子商务网站转化率的核心。比如，有个网站做得很烂，但如果你知道他是你一个高中同班同学在运营，你可能会优先选择它。

对于转化率，如果通过SEO，以前200用户产生1个有效订单，现在提高到2甚至4个订单。比起提升访问量，提高转化率更有效，员工更有成就感。

对于电子商务网站，信任是一种整体感觉。比如，内容大量抄袭同行，而把支付做得越便捷越糟糕(用户感觉是陷阱)。
信任贯穿了用户整个购买过程，从用户进入网站到最终离开。而在过程每一步，即在用户的每个行为意图产生时，呈现给他适合的元素。用设计的术语，就是用户体验。

在信任构成中，最核心是品牌，如公司品牌、产品品牌和网站品牌。品牌是一种性格，根源于领导者的性格。一个重销售或资本运营的公司，很难做出以品质和服务为形象的品牌。
品牌是一种美誉度，广告可以打知名度，但很难打品牌。
品牌是一种积累，这种积累往往需要若干年。
本文主要是网站的可操作性上建立的信任模型，所以把品牌建设排除在外。

另外，信任度有两个方面：用户信任度和搜索引擎信任度，对于后者，本文也没有涉及，我觉得，朴素的SEO和原创就可以达到。

大多数事物都满足80/20法则(Pareto Principle)，所以在信任度模型中，我主要介绍的是核心、可执行元素。

信任度静态模型

上图提供了一种信任度建立的结构化思考方法及要素，沿着此图独立思考，比我解释更有效。

用户购买过程

上图一是从著名的AIDA模型演化而来的。针对虚拟的电子商务(购买前可能接触不到实体公司、产品和客服)，加入了Trust步骤，因为在下一步，也就是 Desire前，客户很可能打消购买念头。Trust步骤是用户和商家产生交易行为的开始，否则网站就只是给客人提供产品信息，而无商业价值。

另外，Trust还可以放在Desire后，因为用户采取Action时，很可能出现这种情况：在网站上了解产品，在当地实体店购买。

在信任构成中，比品牌更直接的的是口碑，也就是回头客的传播，如朋友间或网络社区，也就是我上图中的Satisfaction ，也就是用户购买后的真实体验，它和电子商务的电子无关。
据统计，获得一位老顾客的成本，是新顾客的5倍，而这，也由Satisfaction决定。

后面的四动模型，更通俗、易记。本质上和前一图一致，更适用于传统营销和销售。

信任度动态模型

此图可以结合上面的静态模型。此模型是从用户的视角来构建信任度，上模型是从网站建设、任务执行角度来分解信任度。

做电子商务网站，就像做服装店，顾客从店前路过，店外和店面的装修第一感觉，决定用户是否留下(除开品牌因素)，而真正购买那件衣服，还是决定于用户的仔 细观察，如该衣服本身的款式、质量和价格。网站也一样，如产品介绍和价格、辅助信息的质量和易读性(导购员专业知识和态度)。

信任度是一个整体客户体验，信任度建设也是一个整体，要求公司全体相关人员参与，如业务人员、技术人员、财务人员、甚至行政人员(公司介绍)。所以，管理，即如何整合这一批人，非常重要。

信任度建设，既要让客人感觉到信任，也要实际上可信任，否则就是骗子/奸商。除了网站提供售前售中服务来赢得客人信任，产生购买；客人交易后，业务运营人员就应该去实现网站的承诺。而这，与电子无关。

题后记：
本文特别参考了heidi的http://heidixie.blog.sohu.com/147027487.html
及其它相关文章(google “网站 信任度”)。

转自：http://zwchen.javaeye.com/blog/712739

第一步就吓了一跳 先让填手机号：（ 狂汗 紧接着更汗的就来了 认证要填写身份证 并上传真实相片

着实吓了一跳 当天群里的数据据说是 有50%的同学放弃注册 不知道是否真实

相比其他微博平台来讲 百度推出的时间确实是比较晚 但也确实算有一个差异化突破 ->实名制

包括说吧的LOGO上面也说明了百度的用意 实名社交平台

今天再次看了下百度说吧平台的用户 还是以互联网IT领域居多 并且呈现了男多女少的局面

从目前用户群来讲 还是以IT行业 体验产品为主 所以男多女少也并不为怪

百度这次打实名制的底牌 也算是引领互联网实名制的一个先锋挑战了

百度说吧第一个差异化功能是：通讯录

当双方相互关注后可以提出交换手机号的申请 （这也说明了注册为什么要手机认证）

百度说吧第二个差异化功能是：选号

百度说吧同腾讯微博一样采取邀请制，不同点在于百度说吧并不是以用户名作为地址的 而是采取数字，目前邀请注册的朋友可以从百度说吧提供的10个号码中自主挑选，不知道百度此举有何用意，是否只是一个噱头而已呢？

百度说吧第 三个差异化功能是：提供了认证申请 人人都是V

不同于其他微博平台 百度提供了认证申请，凡通过身份证及照片认证的用户 均成为认证用户 加V

如此的话 认证的概念在微博领域有了2种解释 1.身份证实名认证 2.名人认证（*名人的概念这里不计较）

目前还有几个疑问：

1.既然实名制了 昵称的作用是什么呢？难道是有些朋友昵称被广泛接受 而真实姓名却感到陌生 为了照顾这部分用户?

2.百度此举实名制 与GFW和中移动 是否有具体的内部联系呢？

3.实名制机制是否能得到网民认可？

最后AD下我的几个微博 欢迎大家关注收听

百度说吧：http://t.baidu.com/109222

腾讯微博：http://t.qq.com/richie

新浪微博：http://t.sina.com.cn/iamued

官方功能预览：

从拿到邀请到开通 几分钟就搞定了 体验做的还不错 设置起来也比较简单化 （仅需要验证域名所有权，和设置MX记录即可）

几个对企业比较有价值的功能 那就是组织结构设置，网盘，免费短信提醒

其他的基本都同QQ邮箱，腾讯企业邮箱的势必会对目前一些IDC提供的企业邮箱产生冲击

目前手里还有一些邀请，如有需要的 请在下面留下你的Email地址，名额有限 先到先得

]]> http://www.iamued.com/product/1674.html/feed 13 http://www.iamued.com/product/1562.html http://www.iamued.com/product/1562.html#comments Fri, 16 Jul 2010 11:39:50 +0000 RichieLiu http://www.iamued.com/?p=1562 19楼的一篇文章 ，深受感触http://blog.19ued.com/?p=962

一台F1赛车由发动机、变速器、变速器换档杆、消声器、后车翼、后轮毂支驾、轮毂、油箱、车手座椅、方向盘、后视镜、刹车盘、悬架三角支架、轮胎、底盘、散热器、前轮毂支架、安全螺母、前车翼等配件组成，在一个赛季的比赛中，这些配件不断的损耗、被替换，伴随车手完成赛季比赛。

我觉得产品上线运营就像赛车一个赛季，在赛前我们要做好充分的准备，在比赛中，要不断的超越对手才能取得胜利。

如果一台F1赛车在比赛前就漏洞百出，那在开赛后它只能是一台老爷车，在维修站呆上再长的时间，它也追不上呼啸而过的其他赛车。（当然无论多好的车子在比赛中也会出状况，在维修站里花最少的时间，抢先1秒，就会离胜利更近一些。）

开赛前的准备和测试，让赛车配备了最好、最合适的配件来达到最高的效率。那产品在上线前，它是否已经有了最好的配备？或者说它在配置过程中，是否已经有了损耗，这个损耗能否降到最低？

来看看我们的产品在上线前的流程吧。

产品经理需求调研、制作BRD——BRD评审——项目启动会——featurelist、DEMO——featurelist评审——交互、视觉设计——产品经理制作PRD——PRD评审——前端HTML——HTML评审——技术开发——预发布——上线运营——改进

在这个流程中，损耗肯定存在，因为过程中不同的同事经手，产品经理往往注重需求是否被满足、页面大体效果及交互过程有没出现逻辑问题，可是真正涉及到页面中的布局、结构、视觉表现、对比、对齐、重复、亲密性等细节往往需要视觉设计师与前端设计师的紧密配合。

比如：

1、该模块在视觉稿中，默认2行显示，前端也实现了2行，同时在行间距、字体颜色都做到了和视觉稿的一致性。 可是真正到上线运营后，2行并不能够满足运营的需求。（这个情况我们该怎么办？ 对，很简单，做字数限制，超出的做截断，可是要改这个需要走一遍流程，而在这之前没人晓得这里会放多少文字，以为2行都有多了）

2、列表页也同样存在这样的问题，上线前产品经理到交互再到视觉，已经把标题长度留的够长了，结果上线后用户写的标题长度超出，导致标题2行显示，其他用户反映看着就觉得特别累。（该问题在于上线前我们没有考虑在这里做字数截断，类似这种问题很常见。）另外，在上线前，HTML给到技术部。技术部忙完，测试忙完，上线了。怎么背景的灰色没了，用户大喊白背景下看我们的列表眼睛很辛苦。（技术拿着前端稿子开工的时候，把背景色遗漏了，结果技术没发现。视觉设计师根本不晓得这页面啥时候就已经在线上了。）

3、页面中任何模块的存在，其实都是有对齐的，我觉得可以理解为，X轴和Y轴注定了这个模块的坐标。1个地方没对齐都会让页面变的错乱。前端在制作HTML过程中，有时候并不知道视觉设计师在考虑位置时是依据哪个模块做的对齐，结果HTML出了问题，但是前端并没看出来。（我觉得前端HTML出来后，视觉设计师还是非常有必要跟进每一个细节）

4、产品经理拿着HTML，到技术那边，突然发现漏了个啥小东西，技术一加，其他模块一套，产品经理手一挥，完事了。上线后设计师要哭了，连对齐都没有了。

……

各种情况都有可能发生，页面从视觉稿到线上的效果，就在这个过程中慢慢损耗了，所以视觉稿往往比线上效果好很多。

以上提到的问题有的已经改进，有的已经有了更好的解决方案。

写这篇文章并不是想把责任归给谁，而是让大家反思如何提高团队的默契度，降低损耗，让我们的F1离胜利更近一些呢？

最近也在研究关于电子商务网站的点评，看到此文受益颇多：）

前几天在robin club 上分享到电商产品评论的设计，感觉说的不过瘾，这里博客记录一下。

在开始进行后面的产品分析和对比之前，我们来看一下之目前对商品详细页评论影响比较大的两块产品形态，

一是信息交互始祖：bbs，论坛。我们已经习惯在一层一层的楼层中阅读信息和辨别精华，针对楼主表达的思想进行回顾和发表自己的看法，后续的人也会把之前的信息看成原本内容的一部分，所以也就有了后来更多的一楼决定楼向等评论互动。

一是淘宝,长期以来，我们可以看到，大把的淘宝卖家把用户的评论截图贴到商品介绍的显要位置，更有甚者ps一个，也要贴上。一眼望去，全是对商品的好评，全是对商品的认可。不可否认，越是这样的商品，在淘宝还是越卖的比较好。

然后我们再来看一下国外b2c网站对商品评论的处理。
1，商品详细页，短小，精悍，一页搞定。
国外的商品页，精简的信息，参数都在一个页面展示。

2，对评论的权重
无论是亚马逊的13个（5+7）评论，还是zappos的17个评论，都足够说明评论对电商的重要性和对评论的关注度。

3，着重介绍国内的京东
一直以来，都在留心京东在商品评论上的细节的变化，我相信在京东内部，商品的评论和展示，评论的运营，也是一个重要的项目。据说京东有100多人的运营团队，我想他们的kpi应该有一部分是评论数（个人瞎猜哈）
1，分析结构
我们来看一下京东的商品评论的结构。譬如这件商品。
a，商品属性区域的数量显示
在商品详细页的设计上，我一直坚持一个观点：b2c网站要沉淀自己的价值，沉淀购买用户的价值。这个细节的价值，不言而喻，点击的数量也是此页面的绝对第一点击位置。
b，商品评价
商品评论的基本元素，

• 1，好评率。
• 2，三个评论层次。（好中差评）
• 3，用户元素。（等级，名字，区域）
• 4，互动元素（有用，无用），

然后tab分层展示，和积分鼓励（后面会讲到）
（至于好评的颗粒度的设计就不在这个杂文里面写了，后期希望有精力在写更详细的产品方面的文章。）

c，商品咨询
京东是国内在商品的咨询上作的比较靠前的。也是做的比较好的。好在对商品咨询的分层分类。
京东按照商品咨询的属性进行了7个层面的划分。（其实只有3个层的真分，4个是帮助的假分层）

• 1，商品咨询
• 2，库存配送
• 3，支付
• 4，发票保修
• 5，支付帮助
• 6，支付帮助

d，晒单
晒单，这个东西原本是论坛的一种衍生物，07年在篱笆做产品的时候，内部的培训沟通了解到，运营的很大一部分工作量是和商家一起来引导用户的晒单和展示，论坛整理这些帖子，置顶等来拉动论坛的活跃度。京东也是我个人来说第一次见到把晒单做到商品详细展示页上面，而且做的比较好的。
就产品形态来说，简单的bbs发表，审核，发布模式，贴图，给与奖励，很好的拉动了这个互动。
对比之下，凡客的用户评论和晒图展示等，就做的不如京东，有兴趣的同学可以去对比一下。

2，总结一下商品评论的产品特点
a，所有的一切围绕“商品本身”
今天和同事分享产品设计的时候我说，任何一个页面也好，产品也好，一定有它自己的本质。而商品评论的本质是什么？是影响，是传递。影响什么？传递什么？影响用户购买，传递商品多层次的信息。一切的一切就像影帝访问阿里巴巴那样，内部有句话说“今天少崇拜马总，xx才是主角”。一切的一切围绕商品本身，围绕用户的行为，围绕用户购买的心理决策做突破和分解。
b，分类的技巧
上面提及，以及我们在京东的商品分类页上都可以看到，京东的分类怎么分的？为什么这么分。
我的理解是。分类是按照本身销售商品的属性来进行分解，围绕用户购买的关注的层次来进行分解。这个取决于商品和对顾客的理解。如果把握不准我建议可以多和市场部的同事聊聊，多去接触一些顾客聊聊。
c，运营思路
再谈谈运营的思路，运营商品，商品的运营和整理是个需要花费时间和精力的事情。怎么引导？引导什么样的舆论氛围？什么样的舆论格式？我分享一个心得：前期的商品评论，晒单，默认给出的评论样式等都要下功夫去琢磨，商品评论一期的引导，首批的格式，一定要公司出人力来人肉。后期逐步的来引导给客户看，然后再逐步的形成氛围。京东的好氛围，篱笆网每天的精华帖，也都不是一天换来的。

3，接下来就目前在线我认为作的比较好的京东的商品评论，做一下我的点评，点评仅仅代表个人意见和观点。（譬如这件商品）
产品结构上：
我个人印象中，京东的商品评论的改版大约在4-5个月前，之前相对单一的功能，现在作了明显的3个模块的划分。

• a，商品评价做了3个模块的切分。
• b，评价模块的好评度的加强展示。
• c，评价模块对用户优先评论的引导（注意后面的运营规则）
• d，国外amazon等常用的ugc（用户创造内容）的“有用”“无用”–这个后期京东有没有对接算法应用我就不清楚了。
• e，对会员等级的展示
• f，会员等级延伸（会员的评论聚合页）
• g，商品的所有评论聚合
• h，对提问模块功能的升级（重中之重）
• i，提问模块的区分，分类的设计，分类的引导
• j，提问的全文检索
• k，提问的ugc
• l，提问问答的运营（我们做电商的估计都看过别人发给我们的京东的客服答一些比较另类问题的qq消息）
• m，真实的问题分类和购物的物流信息帮助的混合
• n，晒单的设计
• o，晒单的功能，上传，引导等的设计思路
• p，晒单的问答
• q，晒单问答和评论问答的区别？

……后面的就不详细介绍了。

简单罗列了一下，可以看出京东对用户评论体系的重视。建议大家多花一些时间研究分析，结合自己网站做改造，记得我上段文字，一切围绕“目的”“核心”和“本质”。

4，最后我来说说商品评论的价值，简单做一个汇总。

无容置疑，商品的评论对商品展示很重要，就其价值来说，我总结出如下几个方面。

a，影响力。

在给朋友的公司作培训的时候，讲到商品详细页的设置，我一直强调一个理念，“用户购买的过程，是用户说服自己的过程，是用户假想商品适合自己的过程，是一个斗志的过程”而商品详细页，商品展示，和商品评论作的就是用户信心的引导和加强，帮他说服自己。

b，购买帮助

购买的决策不仅仅取决于信息，更取决于辅助信息，所谓的辅助信息，就是第三方的信息。评论的加强能很有效的把第三方用户的使用评价情况反映出来，不同的纬度和观点。尤其是来自同类购买者的信息结果，对未购买者更是一个很好的帮助。

c，信息平衡，讲处理的技巧。

插一个话题，在robin club 上有朋友问到评论信息的平衡问题。就是说顾客对商品理解不同的差评怎么处理。信息的平衡需要技巧。切忌不要简单粗暴的删除。有两种解决方案，一种是产品上的：后台调整，提升有利信息的权重，采用信息噪音覆盖来削弱负面评论。一种是robin说的，seo处理，在差评前面加一段js代码，来屏蔽爬虫。尤其是大型b2c的商务网站，商品信息的处理一定建议专人负责，积累更多的处理经验。

d，seo的优化

一个电商创业的朋友，他说，他之前的网站很少作seo优化，可是百度搜索却很靠前，原因何在？是因为他的商品评论和用户提问都是单独模块，很多形式都是用户的疑问形式，原创的内容，更新的内容，用户提问模式的文字，这些自然的搜索引擎的权重比较高。

e，传播

这个价值就不用说了。从很早之前的京东客服的经典问答，到卖菜刀的问答，到买钻石送宝马用户问答送不送“马诺”。我相信京东从这块赚到了不少的流量和关注的眼球。

f，沉淀

时间不仅仅是感情的炼金石，更是信息沉淀的炼金石。我们经常去看淘宝的，一定对那些拙劣的ps，把之前客户购买的记录东拼西凑的一块一块的贴在商品描述里面的现象有印象。无论是购买数量还是客户评价都是他们炫耀商品质量的宝贝。（可惜杯具的淘宝规则他们不能沉淀，定期清空，这些反而更是b2c的优势，因为商品我们控制）

最后，来总结吧，看了一下也罗唆了不少。

在商品属性的表达上，我们总是习惯性的优先关注商品，图片，价格，因为这些最重要，可是随着时间的发展，品牌的沉淀，购买影响的评论模块也逐步的在网购的发展中日渐的凸显出了价值。（最后大胆的预测，电商未来一定是社区化的，无论是经久不衰的篱笆网还是新模式的groupon，还是新的以物为中心聚合的 京东论坛 都在呈现这个趋势，毕竟，人是一切的核心，聚合人的社区符合现实的映射）从现在开始，关注我们的评论吧，花些时间和精力来优化升级它吧。

出于产品经理的破职业习惯，最后分享一下关于评论的产品设计我的理解。
1，产品形态把握3个方面

• a，信息的输入和输出（信息的源）
• b，信息的展示
• c，信息的运营（有利自己的，和影响）状况，产品设计的考虑。

2，运营产品设计4个角度

• a，评价的导向
• b，评价如何来放大影响商品
• c，评价的传播和激励
• d，下一次的用户习惯

最后：分享几个有新意思的商品评论处理。

1，lightinthebox的评论入口前置，还有默认好评的是4星起点，有利于商品。呵呵。（页面请点击）

2，没有声音，再好的戏也出不了 。宝洁的b2c，干净到寡的页面。（页面请点击）

而我们在做的 实际上也是一个平台产品，至少希望它发展成一个平台产品

教育的市场真的很大，数以亿计的C类用户，数以万计的B类用户，真的没有我们存在的价值吗？

我觉得困难在于如果迈出第一步，第一步是什么？是第一个真实从你得产品中受益的用户，不怕小，但是要让你得用户记住你

所有的B2C都是一样的，B类用户和C类用户相互依赖，面临一个选择

先选择为谁而提供服务呢？

首先对于平台而言两方面的用户都需要付出相应的成本，例如B类用户可能需要花费时间来维护平台，对于C类可能需要消费等等

面对这样的需求我们该如何去选择，更多的小公司可能和我们一样 先期将B类的工作先自己都做了，等待订单量到达一定的量之后才能反客为主，和B类用户提要求

但事实可能不如所愿，C类用户的量确实取决于B类用户的信息质量，价格等因素，而起不了较大的量，B类也因此更不愿主动地发布有价值的信息和维护

如此一来，对于做平台的我们，进入两难境地

先发发牢骚，各位朋友有好的建议也可以随时和我联系 有重谢哦

QQ：76373