在我有限的两年多工作经验中，只接触过一次比较大型系统的用户模型：一年前在支付宝时和用研的同事一起做一个关于生活费用类的需求。当时还通过用研同事之口得知了淘宝的用户模型库，也上去看了看，被其系统和细节所折服。一年之后在我自己去卖力做用户模型和数据的时候，却发现一个庞大和系统的用户模型的弊病，无论是对小项目还是大项目来说，它都显得太过庞大了。

    先以一个假象中的简单的例子开头(无任何影射)。一般用户模型基本都会有这几个因子：年龄、性别、职业(收入)、用产品的时间，但是在具体使用过程中，我发现这样做其实是蛮难满足具体需求(来自产品和运营的需求)。譬如假设要优化支付宝的快捷支付，最近我老是在这里使用受挫。在这个需求场景里会需要使用支付宝产品的时间和频度、持有银行卡的类型、支付宝余额功能的使用情况、经常购物的类型、职业(收入)等这几个主要因子，显然已经细化到了相当一个程度。那么这个需求用户模型能满足么？

    尽管理论上说用户模型是在不断充实和修补的，但无论是大项目还是小项目，由于互联网行业的本身特性，需求就是多量和多变的。这么复杂的情况下，一个庞大的用户模型是难以控制好因子的粒度和可伸缩性的。在我脑海中除非有这么一个系统，首先它可以持续地添加因子，且产品的所用用户都会按照添加的因子填入属性，然后系统支持正式使用的时候选取不同的因子，然后列出过滤因子后的海量用户情况，这个系统才能在实践中满足各种各样的需求。显然这么个系统实在坑爹，跟人口普查还麻烦。

实践中我们需要的是大量的灵活小巧的用户模型

    灵活小巧的用户模型，就是去满足单个特定需求的。因为实际的情况往往是这样，一个产品和用户群可以剥离出很多因子，但在具体某个需求的时候，往往只是需要其中几个因子。而如果在用户模型建立的时候去考虑到所有的因子并获取所有因子的用户资料，如上面所说是坑爹的。莫如实际一些的做法：先从产品和运营的需求中抽离出因子，然后产品、运营、用研综合考虑后选取抽样，依靠一个比较强大的BI支持你跑出数据，然后就可以开始分析了。这么做大概一个晚上就可以从需求到最后分析得出结论给搞定。对一些特定的因子BI无法跑出数据的，可以通过和一些典型用户详细聊天来达到。

    这个方法其实是基于一个考虑，用研的目的是什么？在我看来是：通过尽可能科学及有保证的方法，去分析分析分析特定情况的用户行为，得出结论后指导特定情况下的产品发展。在项目实际过程中，真的很少见到那种比较宽泛的用户调研需求，而不断累积的用户模型库，实在是跟不上业务和产品发展的速度。而我一直认为项目的中心始终是人，只要人的脑袋能跟上，是足够相出各种办法来满足用户调研需求的。只是千万不要被体制和流程僵化掉。

一个实践中的例子

    在我的摄影社区的项目中，前人并没有一套比较完整的用户模型文档。当然，99%的产品都没有这么一个文档，但我认为这是很有必要的，因为一个产品的owner不可能永远都是一个人，owner在健康情况下都是最了解产品和用户的人，如果能形成一个用户模型文档，则能帮助后来的owner尽快熟悉产品和用户，同时启发后续的思考。在做完这批调研需求后，我正在做这份文档。稍微扯远了点，正题是我在项目中做用户模型的经验。

    首先一个门户公司下面的摄影社区，什么样的人都有。从事做摄影社区行业的人会发现没有任何两个较好的摄影社区的用户群是大部分相同的。在网易摄影中，按照用户群的真实需要分，大概可以划分成这么几档(左边是用户群，右边是他们的需要)：

    这个模型是同伴和我长期泡在社区，并和各色人等打交道后总结出来的。像他们的需要这种，基本上不可能通过跑数据跑出来，问卷调查我认为也很难做(因为问题会模糊)，唯一的办法就是之前提到的和用户聊天，注意是聊天而不是焦点小组等等。就是说坚持一段时间(3个月或半年)高频度地和社区中的用户闲聊，只有闲聊你才能挖出他们内心深层次的想法，只言片语中见真章。而这个模型只有“真实的需要”和用户专业水平这两个因子，因为这是一次大规模的定性，并且真实的需要这个因子划分出来的几种属性都是很概括的，比如各种虚名里面包括了显摆、装逼等，有能和自己同等对话的人包括了纯净的社区氛围、牛逼的小团体等等，并且“钱”这个属性，任何一种类型的人都想要，只不过只有特高水平的职业摄影师才是“直接”想要钱。这是第一个模型例子，有了这个模型，我们就可以按照我们能给出的资源，来大致圈定社区的目标用户以及重点目标用户。

    第二个模型是我们想知道到底每天来访问网站的是些什么样的人。之前的认识都比较感性，没有一个强有力的支撑，导致产品在持续优化时显得方向很杂，也导致产品做出来之后并不知道对不同的人群效果如何。于是我和运营一起做了一次深入的用户模型，这次是依靠数据分析。首先提取了10天内访问landing页面的用户ID，然后根据我们对上面那个模型的理解，提出了第一批若干因子，例如：在社区里第一次发作品的时间、用户等级、作品数量、优秀作品数量、加入小团体的个数、近10天访问的次数等，然后根据这些因子跑了一份详细的数据表出来。这份表出来以后，迷雾立马就清晰了。马上形成了一个用户模型，按照这几个因子各种组合归纳之后，除了基本的活跃用户占比之外，还得出了很多有用的结论：比如用户等级和近10天访问次数的关系、优秀作品数量/作品数量和加入小团体个数的关系等等。值得一提的是，在这个过程中，我们发现还需要挖掘更多一些的因子，比如用户的各种互动情况，对我们这个用户模型会是很好的补充。同时也会去抓更多的数据，建立各种复合需要的用户模型。

    做完这一套后我发现，其实这个过程和敏捷开发类似。互联网产品行业发展的时间还太短，像产品经理、用户研究、交互设计这些职业沉淀的时间也太短(传统软件行业除外)，很难有一套持续指导的方法论。而唯一能保证的就是人本身和实践。在实践中最可靠的还是产品owner的想法以及驱动，因为如果owner不提出或者不理睬建立用户模型的需求，那用研同事招得再多也无济于事。最悲催的情况就是用研同事辛苦做了一个庞大的用户模型，要么无人问津，要么在实践中无法起到和付出的代价相匹配的效果。