隐式挖掘网站用户行为 -转载，出处不明 　　如何了解用户和需求 　　如何了解用户需求？根据用户是否主动参与分为显式与隐式两种挖掘模式，因为显式的动静比较大，有很大局限性，所以为了保证结果准确性以及提高用户接受度，一般都采用隐式。 　　用户的日常交互行为会产生四类关键数据：鼠标移动轨迹、链接点击分布、页面浏览流、页面停留时间。通过用户的行为能反映用户的观点，同时利用访问的网页次序可以找出网页之间的隐性关系。 　　收集数据 　　Web服务器的日志（用户会话记录） 　　Web trends或类似的第三方共享软件（客户端分析，流量分析，可用性分析） 　　自己开发的第三方软件/插件（需求自定义） 　　大型网站通常会把以上三种方法组合应用，大致原理就是给进入网站的用户赋予身份识别，每次产生交互动作就向服务器发回请求，通过时间和页面判断连接各个请求点并且记录下来。（算法不讨论） 　　过滤数据 　　明确目标，定义核心数据。 　　界定用户行为，利用多数人的行为来消除个人行为的主观性。 　　对用户进行归类，确定数据类别。 　　大型网站每天所产生的数据量是惊人的，所以常规需求一般都是定时或定量的分析。另外，额外的数据处理会减慢网站的速度，搜集的数据越多，潜在的负面影响越大。 　　习惯分析 　　对用户浏览过的页面进行内容分析，根据信息主题对页面进行聚类。 　　聚类过程中除了考虑页面内容相近程度，还应该考虑页面路径。 　　把用户浏览行为对其兴趣的作用列入聚类结果，得到综合评估模型。 　　用户兴趣分偶然和稳定两种情况，其中偶然可以认为是随机变化的，稳定的挖掘又有基于内容和行为两种方式，在内容上表现有重复度、相似度等，在行为上表现有停留时长、点此次数、拉动滚动条次数等。 　　实际案例 　　类似系统、浏览器、分辨率的客户端分析，常见而且简单，略过。 　　关于鼠标轨迹、点击分布的可用性例子： 　　跟踪用户在进行检索时的鼠标移动轨迹，可以获取用户操作的先后顺序、热点功能、动作曲线等一手数据，这些都是改善或简化表单的重要参考。 在重要的页面进行详细的点击分布监控统计，主要检查信息呈现的易用性，看看有没有偏离设计初衷，经常更新，找到规律。 　　处理特定用户行为、用户群、用户来路的任务流例子： 　　监控分布式注册流程，能够看到有多少用户填了表单、填完了表单，或者在某个步骤有异常流失。   　　监控不同模块入口过来的注册用户，能够统计出各模块导入的有效注册量、百分比、成功率，以便合理调配资源。   　　监控投放广告过来的注册量、注册成功率、转换付费用户成功率，以便明确广告的投入产出比。     监控用户的纵深浏览行为，是测试导航可用性很好的办法，也就是说用户会不会在你的网站内迷路。

这篇文章我找了下没找到原出处，不过被摘录的挺多，我也引用一下吧。尤其关注一下数据库黏度的挖掘，是否可以更好的用在B2B类站点上。 （又偶尔找到了原出处，应该是这个作者：http://yokanta.blog.techweb.com.cn/index.shtml，研究的内容都很好，推荐一下。） 　　黏度同粘度、粘着度、黏着度。广义之黏度指之是用户对网站之重复使用度(依赖度、忠诚度)，和用户迁移成本基本成正比。通常黏度越高之网站越体现价值，因此如何提高用户之迁移成本也是各网站运营之首要任务之一。但在我看来黏度这个概念还是过于宽泛了，以用户迁移成本来源之不同可以将黏度分为3种类型，以下一一分析: 　　1、技术黏度:这个最好理解，哪个网站速度最快、服务最稳定、价格最低、功能最强用户就选择哪个，比之完全是技术定量数据。最明显之例子应该算是用户关于Email服务商之选择，当年谁家新推出一个更大容量之邮箱就会拉走一大批用户，谁家对垃圾邮件之处理更好就又拉过去一大批，用户在迁移时对前一家服务商几乎没有留恋。因此技术黏度对服务商之要求非常高同时用户忠诚度是最低之，要保持技术领先还要保证服务稳定，随便在哪一点上有竞争对手超过了你都有可能造成用户之大面积流失。当然从另一个角度来看不管你之竞争对手是苦心经营多少年之老字号，只要你在技术定量数据上超过了它，都可以从它那里迅速抢走大量用户，甚至可能一举击溃它。这在前些日子迅雷华军案中可见一斑。 　　所以单纯以技术黏度为方向之网站有几个特点:用户迁移成本低、用户忠诚度低、技术创新意识强、覆盖面广、发展速度高。典型代表:Google。 　　2、社交黏度:我们常说之社区就是靠这种黏度维系之，我个人之前文章中谈到之黏度也特指这种黏度，我称其为狭义黏度。在“社区研究之SNS和烧汤”一文中我对社交黏度做了一个基本之阐述:黏度是指个体用户对于社区内某个或某些特定之人之交互之依赖性，而不是对某个社区产品或者功能应用之依赖性。同时也做出了几个判断:1、以强化社交黏度为目标之才是社区;2、社交黏度之基础是固定之ID(变相实名制);3、做社区就是做SNS(广义SNS)。 　　正因为社交黏度是建立在人与人之间之关系上之，所以相互之了解和信任需要时间来培养。反过来看，一旦了解和信任得以建立，也就不会轻易丧失。从用户迁移成本之角度看，有了社交黏度后迁移成本明显提高，因为此时用户不是自己换个之盘就可以，而是要带着他之人际关系一起走，否则他就必须重新花时间在新之之盘与新之对象培养相互之了解和信任，这个成本是相当大之，也是关键之。 　　所以单纯以社交黏度为方向之网站有几个特点:用户迁移成本高、用户忠诚度高、技术创新意识弱、覆盖面窄、发展速度慢。典型代表:QQ。 　　3、数据库黏度:这可以算是一种新之黏度，实践还不多，成功案例几乎没有，但个人认为是未来网络之一大发展方向。数据库黏度建立在对个体用户之数据跟踪分析上，并比照该个体用户与其他用户之异同，综合分析其中之关联，最终推荐提交给个体用户一套个性化之解决方案。这种黏度之基础是积累了大量之个体用户数据，同时还须掌握科学有效之比照分析方法。虽然现在还很不成熟，但可以肯定之是，当数据库黏度发生作用时，个体用户之迁移成本必然会越来越高。 　　目前在数据库黏度初露端倪之实践应该是豆瓣，豆瓣有一个功能是“豆瓣猜你会喜欢”，说心里话这是我最喜欢也最看好之豆瓣功能，虽然现在这个功能还很弱，推荐也不算准确。这个功能是完全个性化之，其后台是个体用户提交之数据与其他用户提交之庞大数据库之间之比照分析，再反馈给个体用户一个独一无二之、只适合于你之推荐。可以想象随着豆瓣数据库越来越庞大，算法越来越精妙，最终之结果也会越来越准确。但目前豆瓣之数据还是割裂之，它不能从我喜欢之电影推测出我喜欢哪些书和音乐，而在我之想象之中，未来会有网站可以从我喜欢之音乐准确之推荐给我一辆适合我之汽车或者新到货之服装。 　　所以单纯以数据库黏度为方向之网站特点现在还不好说，只能推断:用户迁移成本高(数据库导出成本高)、用户忠诚度高(数据跟踪终身化)、创新意识强(算法不断革命或优化)、覆盖面广、发展速度慢。典型代表:目前没有。

要求：有互联网的从业经验，对网站运营、或产品策划、或搜索引擎优化、或网络营销有自己的见解，并有浓厚的兴趣。有大型站点的具体作品或项目经验者尤佳。 工作内容：大型电子商务网站的线上内容运营、互联网产品策划、或网络营销、搜索引擎优化方向，可按照自己擅长的方向选择，我们都需要。 工作地点：大连地区 联系方式：在此主题下留言，或E-mail给我 sunbo@jctrans.net

1: Markus Frind: PlentyOfFish.com – $300,000 per month Markus Frind the founder of the up and coming free dating site Plentyoffish.com is the biggest free dating site on the Internet. Plentyoffish.com. The site reportedly has traffic up to 500 million page views per month. This translates into over $10,000 per day. Here is a check [...]

当需要撰写项目计划书的时候，我开始怀念以前在专业的论坛上大家提供的那些成形的方案架构，以及那些成功的例子，下面这个是我找到的一个简单的样式，比较通用。  项目计划书的格式、模块 1. 项目名称：____________ 2. 执行时间：____________ 3. 内容简介：  4. 项目意义： 5. 预期目标： 6. 项目资金预算: 7. 申请人资料:姓名: 联系电话、E-MAIL: 项目申请人签名：_________________ 日期： ________________

原作者简单翻译了一下的Jeff Lash和Chris Baum关于用户体验跟产品管理关系的文章，全文如下:第一章用户体验(User Experience, UE)专业人员正逐渐从商业角度对他们的工作感兴趣，在他们的核心观念中，UE的重点是理解用户需求并创建有用和易用的产品来表达这种需求。 UE人员常常在他们的研究、设计和创意没有得到相应的尊重时感到非常失落。差不多每个UE人员都有过与那些尽管缺少交互方面的需求和流程的知识，却根据他们的感觉或毫无道理的看法来驳回一个建立在研究基础上的设计的领导者打交道的糟糕经历。 很多UE人员逐渐意识到他们有经验和洞察力来运用权威性并在帮助构建的产品中发挥更大影响力，产品管理人员也对这些希望扩大影响以保证以用户为中心的产品开发顺利进行的交互设计师、信息架构师和易用性工程师等有了更多的兴趣。 对很多UE实践者而言，成为产品经理(Product Manager, PM)是一个合理的转换，因为两者往往需要类似的技能，特点和能力。此外产品管理是很多组织共有的角色，向这样一个已存在的角色过渡是较为容易的，只是信息架构师或交互设计师如果选择用这种直接方式来影响产品的话，他们还需要学会换位思考。 PM是什么? 传统意义上PM就是一个产品的主管，为了方便讨论，我们这里将产品定义为软件、网站、网络应用、局域网或技术产品。 作为一名领导者，PM将对整个产品的成功负责，这其中包括用户体验。对技术产品而言，用户体验是产品成功中非常重要的部分，当然还包括其他方面，像产品的销售、技术、法律、商业模式、定位、品牌和营销等。 PM应该扮演一个领导者而非独裁者的形象，才能保证产品的成功，并得到各方的支持。像总统会与负责防务、交通、农业等的官员共事一样，PM团队也包括营销、技术、财务和其他领域的人。与票选民主不同，PM对用户和客户负责，通过收入、利润、用途和其他市场驱动因素来实行决定民主。 产品管理中涉及的各项任务和领域使得PM必须精通业务的方方面面。 PM的职责PM的基本职责是理解市场并推动适应市场的产品开发，由于UE人员往往已经熟悉了设计的用户需求也具备相应市场知识，因此他们具有成为优秀PM的潜质。 PM还有如下一些较高层次的职责: • 建立产品策略，重点是对产品的未来有长远和有说服力的眼光。 • 将策略转化为产品路线，有了清晰的远景和策略后，PM就要与管理层一起确认并执行策略。 • 撰写支持商业策略和市场需要的需求书，确定主要路线，然后细化特定的可执行的需求。 • 确定以合适的顺序，在合适的时间提供合适的功能特性(features)，以客户价值和市场的关联程度来划分这些特性。 • 确定与市场间有适当的沟通渠道，以合适的方式向合适的人发送合适的消息，并确认客户已了解到他们的产品。 产品管理和用户体验的差异 尽管PM的职责很广也很有战略性，他们还需要负责在战术层面具化他们的战略。在一些细节上，PM可能存在与UE人员重叠的问题。正如Johathan Korman写道: 当我向那些不了解”交互设计”的人们描述我是做什么的时候，首先我说:”我观察用户的需要，确定哪类产品最适合他们，然后制定关于这个产品的行为规范，以此推动开发团队的工作。”人们常常回应说: 在我的组织里，我们管这个叫”PM”。 乍一看，用户体验的角色和产品管理惊人的相似。然而你仔细观察就会发现产品管理和用户体验在职责、重点和依赖度上是有区别的。 职责: PM负责整体成功，而UE人员负责界面设计使之满足用户需求并易于使用。UE人员同样应该像销售、营销、工程人员那样关注整体的成功，尽管并不负责这些方面。 重点: 当UE人员聚焦在界面与产品体验之时，PM会从市场整体反馈、特定市场规划、竞争力、技术、收益与损耗以及可调用的资源等方面来审视这些界面与产品体验。 依赖: 信息架构师(IA)、图形设计师、易用性专员等主要精力集中在界面上，他们需要依赖自身或类似角色的其他人一起来完成工作。PM则坚定地要求他人能执行其产品策略，他们更多地需要融合一些微妙的产品目标、策略、影响力、坚定和公平的决策等因素，这些要求多甚于UE人员。 或许Johathan Korman最好地诠释了PM与其他角色如UE之间的差异: PM负责产品应该做什么(What the product should do)，而其他角色负责产品怎么做(How the product does that)。 产品管理与用户体验的冲突 最常见的UE与PM间的冲突就发生在该产品应该做什么与产品该怎么做的讨论上，双方常常争论谁应该负责定义产品的特性与需求。PM感觉应该由他们负责，因为他们管理产品，但是UE人员感觉应该由他们负责，因为是他们在花时间直接与客户和用户打交道，研究用户需求。 最终由于PM对整个产品的成功负责，他们也就成了决定产品做什么的最后仲裁者。好的以市场为重点的PM应能理解市场背景和客户需求，并在第一手经验和已有研究的基础上决定合适的产品特性与功能。 然而UE人员常常对此非常光火，因为他们认为自己更贴近客户和用户，理应负责产品的需求收集和定义。 好的PM应该象UE人员那样贴近自己的用户，否则就会脱离用户，只知道坐在办公室里开大会，让UE人员来做此类研究。 [...]

最近我开始更多的关注起UE-User Experience (用户体验规划)和UI-User Interface(用户与界面的关系)方面的知识。从白帽SEO到UE&UI也会发现很多是共性的，最近也发现了很多UCD专家的博客，转载一篇做学习备份。 细心的读客应该会发现，在昨天 Making Life Easy – 使生活更容易 里提到一个英国的Flow Interactive 交互设计咨询公司，今天继续阅读了他们的网站，发现了他一些对UCD（User-centred Design 以用户为中心设计）的实施流程， 觉得很有代表性，也很清晰，所以简单整理了一下，给自己和大家学习备份： 他们大概把UCD的流程分为了下面几个阶段： * Research stage 调查研究阶段 * Concept stage 概念定义阶段 * Iterative design stage 迭代的设计阶段 * Implementation stage 执行阶段 * Launch stage 发布阶段 UCD flow 图片来自Flow Interactive 下面是图片内容的解析，连接都有相应的安例解析，很有帮助。 Research (调查研究) * Context studies(背景研究) * Focus groups 关注群体 * Competitor comparisons (竞争对手对比) [...]