多渠道用户问题：多渠道用户一般包括两场景，一是互联网产品的第三方登录，二是多系统集成。接下来我们分别分析面对这两种场景的共同问题。

　　第三方登录

　　当一款互联网产品投放市场时，注册流程被看作是否能吸引用户关注产品的门槛。早先得注册流程，不论网站还是手机APP，都需要繁琐的信息录入，比如用户名、密码、性别、手机号码、电子邮箱等。

　　注册完成以后，还需要进行邮箱激活认证。如此繁琐的过程往往使人望而止步，很多人就是在注册的过程中放弃了对产品的关注，现如今，随着第三方登录注册盛行，开发者实现了通过第三方登录注册流程，这个过程常常被称之为OAuth2.简单来说就是通过第三方应用程序的接口，调用认证服务器对用户进行身份验证，验证通过后将用户带入到系统中，使之成为注册用户。一旦用户通过验证，与用户中相关的属性都可以被系统获得，例如用户别名、生日、性别、关注点等。这样的流程需要更复杂的开发任务，但是随之而来的好处显而易见。用户只需要点击“确认”按钮，就基本完成了注册流程。下次登录时也不需要再次输入用户密码，直接把认证的任务交给第三方来处理，相比传统的注册方式更加方便快捷。在国内市场中国，常见的第三方登录有微信、QQ、微博等。如果你的用户来自以上提到的多种渠道，如何识别哪些用户是同一个人？可以设想，如果一个用户通过微信、微博登录了系统，你在进行用户统计时会出现重复记录情况，这对于分析用户量，用户行为产生了不必要的干扰。数量都不准何谈用户行为分析呢？

　　多系统集成

　　在企业级系统应用中，存在很多系统集成问题，在企业被重新整合或者IT重构的过程中，常常需要处理如何把多个系统整合在一起。对于每一个系统，或多或少都会储存一定量的用户数，当多个不同的系统整合在一起时，我们如何判断用户个数，以及如何解决相同用户出现在多个系统中的情况。最常见的问题就是如何判断系统A中张三和系统B中李四是同一个人。以上两种情况，我们并没有统一的标志来识别用户。更麻烦的是，当用户在原先的系统中录入信息时，有些可能会出现错误输入，姓名、年龄、出生年月、身份ID、手机号等不一定都是 正确的。那么我们应当如何做才能识别呢？这里我给大家分享在项目中用到的方法。

　　用户识别

　　3个系统，分别使用SQLServer、MySQL以及MongoDB作为产品数据库。每个系统中存在一个用户，比较特别的是这个用户看起来都一样，只不过在MySQL中，用户的名字是ZhaogSan，而其他两个系统都是ZhangSan；另外，用户出生日期的格式在三个系统中也是不一样的，分别是1991/12/31、19911231和3112/19.在仔细观察会发现，数据库的字段也不同，有生日、出生日期、姓名、名字、ID和pid等。

　　通过人为观察，我们可以人为这三条记录实际上属于同一个人，姓名的不同可能是拼写错误导致，其他问题都可以归结为数据库格式或者字段，命名上的差别。为了解决数据整合问题，我们先要选对存储方案。

　　传统关系型数据库的解决方法

　　如果应用系统采用关系型数据库存储结构，在处理上述问题时有些捉襟见肘。这也是大部分切页目前面临的问题。我们的任务是要存储来自不同数据源的用户数据，首先一点需要确定数据需求，哪些数据需要存储，哪些可以舍弃。从业务角度讲，业务人员需要了解不同数据源的用户分布情况，为了回答来自哪个数据源的用户多、哪个少的问题，我们需要把用户数据的来源全部存储进来。舍弃无效、重复数据，关于这方面内容我会在后文讨论，现在先来看一下关系型数据库中表结构的关系，为了达到上面的要求，我们需要两张表，一张用户表，一张用户来源表。他们之间是一对多的关系，一个用户可能来自多个系统，所以用户表中的主键是来源表中的外键。表关系建立好以后，下面需要处理的是数据存储和查询。在这样的结构下，如果一个用户来自四个不同系统，在用户表中会有一个用户记录，另外在来源表中会有四条相关联记录、如果用户数量在百万级，其中20%的用户来自多个系统，那么我们的来源表存储记录个数会在千万级左右，而实际上，百万级的用户量在目前互联网产品中并不算很多。在进行数据迁移时，对于百万个用户要进行上千万次插入操作，这也会是个耗时的任务，另外，由于关系型数据库系统在存储不同表格数据时都是分布在磁盘不同的位置，一次查询操作可能会要多吃访问磁盘这也会导致读取数据性能问题。由于这些问题的存在，在整合来自多数据源的数据时，我们不建议大家采用关系型数据库存储，而NoSQL是比较推荐的方案，其中MongoDB又是表现比较突出的NoSQL产品，接下来我们看看如何在MongoDB中解决上述问题。

　　MongoDB解决方案

　　如何进行用户识别呢？假定我们要把数据整合进MongoDB中，分几步来完成。我们对现有三个系统中的用户进行了两步操作，首先将用户的字段和格式改成统一标准，字段包括source-id、姓名、出生日期，在source-id中标记了用户来自A、B、C三个系统。之后，再按照一定算法对统一的用户进行合并从而得到图中最上面的记录。在合并好数据以后，出于记录可追溯性方面的考虑，我们还需要记录用户是从哪个系统导入进来的。下面是整合后的json数据，也就是最终要储存在数据库中的格式。可以看到，除了用户基本数据以外，还对用户来源进行了存储，他们被存储在一个json数组中。得益于MongoDB灵活的数据结构，我们可以随意的扩展用户来源个数。随着系统不断的集成，这个数组会越来越大。将相关数据组成一个文档并插入到MongoDB中是一种比较常见的做法，相比上面关系型数据库的存储方案，MongoDB展现了更敏捷灵活的特点。我们可以一下子查询到所有关于用户的信息，避免了多次磁盘读取也避免了多张表之间的JOIN操作。当用户来源不断增加时，我们不需要插入新的记录，只要在内嵌文档中插入一条数据就好，总的文档个数也没有发生变化。

　　用户匹配算法

　　在解释算法之前，我先列出一些设计上的考虑。我们的算法允许一定程度上的错误率；在进行用户匹配时，算法不会百分之百准确，只能做到在一定程度上的匹配。算法不会匹配所有用户之间的关系：在匹配的过程中，我们不会对所有用户进行一对一的对比，这样算法工作量会以指数趋势增长。比如系统中存在一百万个用户，如果一对一对比相当于要进行一百万次方次比较，再算上每个用户还包括若干个字段，比较的过程会明显变慢，这并不是解决问题的思路。

　　下面我来解释算法的过程。先把用户按照一个字段分类，比如：出生日期；在每一个类别内，计算每两个用户之间的距离，然后将距离相近的用户组织在一起；距离是指一个在0到1之间的数字；

　　0.0代表两个用户的所有字段完全一致；1.0表示两个用户之间的属性完全不同；选择一个距离阔植，在这个阔植范围内的用户被看作成相同的用户， 对这些用户进行重组。

　　用户出生日期不会发生变化（偷该年龄的情况暂不考虑）；该字段分布比较均匀，不会出现某一天存在大量用户的情况，这样分组时没组的成员个数相对平均。在这个例子中，我们看到第二组用户LiShu和LiSi被算法认为是相同的两个用户，有些人可能会认为他们实际应当时两个不同的用户才对，那么问题出在哪里呢？我们看到在每次比较匹配的时候最小距离起到了关键作用，到底多小才能被称之为相同用户根据不同情况会有所不同。算法需要一个合理的阈值才能得到正确的结果。这里所说的“正确”指的是相对正确，我们允许书籍出现一些误差。只要误差在合理的范围之内就能够接受。这个阈值和上面用来分组的年龄字段是很相关的概念。根据分组字段的不同我们设计的阈值应当相对变化。比如，如果把用户所在地的邮*编码作为分组条件，大家想想会是什么样的结果。由于某些地段人口密度比较稠密，会出现某些分组成员个数远远大于其他人口密度较小的地区，这种情况下如果用相同的阈值可能会出现很大的误差，所以应当选择较小的阈值。

　　训练算法

　　这个过程看起来比较简单，但真想达到产品级别的准确率还需要一定量的训练，如果根据真实数据恐怕很难训练出有效的算法，因为在真实环境用户的区别想对较大，不能体现算法的精确度，有可能经过几周的算法也没有找到一个相同用户。那么应当如何训练算法呢？首先要做的是虚拟一定量的用户作为训练数据。这个虚拟并不是完全随机生成。我建议的算法训练过程如下：虚拟一个用户；根据这个用户的属性衍生出三个相似的用户，衍生的方法比较随机，有可能是用户姓名很接近，或者用户出生日期的格式有区别，再或者是认为的生成一些错误数据、拼写错误等；将上面的过程重复十万次，这样就可以生成四十万个用户放进你定义的算法，运算得出需要合并的用户数；将这个用户数和25%进行对比，越接近说明算法的准确度越过；上面是一次测试的结构，我们在算法相对稳定以后，对算法进行每天测试；用户数据时一直累计的，每天生成四十万个用户放进算法；此时的算法计算的总量包括从开始到现在的所有用户数；不断运行找出算法的缺漏。如果算法始终不能达到一定量的准确度的话，可以适当调整你的分组条件；再有，还可以考虑多加几个字段作为组合分组条件。在对比用户距离的时候，也可以考虑多种条件的组合。当算法运行到一定规模的用户数时，可以说如果错误率在0.5%以下还可以接受。当然，具体情况还需要根据应用程序量身定制。

　　合并用户

　　算法可以找出相似的一组用户，接下来我们需要确实然后合并这些用户。由于这些用户大多不是百分之百相似，多少都会有一些差别，那么按照什么原则来合并他们呢？这里没有一个固定不变的算法，但是可以根据一些之前定义的规则来合并。我列出几点经常用到的规则供大家参考。为每个字段在不同系统赋一个权值：根据你的实际情况，对于不同系统的范畴也会不同，比如在系统A上用户的邮箱准确较高而在系统B上用户的姓名通常正确的。这样我们就可以把用户邮箱在系统A上设置一个比较高的权值。同理，在系统B上为姓名设置一个高权值。当进行用户合并，我们取权值高的作为最终结果。存储多个字段的值：有时病不是只有一个系统的值是正确的，有可能多个系统都存在正确的取值。以用户住址为例子，用户不会只住在一个地方，搬家会导致用户住址的变更。如用户注册到系统A时住在北京，而注册B时住在上海，那么我两个地址都应当时正确的输入，此时我们可以利用NoSOL数据库灵活的存储结构来将这个值存成一个数组。有时需要在此应用上面的匹配算法：当然，在存储用户地址或邮箱时也会出现用户输入错误致存在多个值。这种情况我们不想用上面的方法将他们存储成数组中的不同元素，解决办法还是回到了上面提出的匹配算法上。继续计算这些值之间的距离，如果距离小于一个

　　阈值就考虑合并他们。

　　小结

　　识别用户只是算法的一个应用场景，实际上可以将其拓展到更多的应用场合，实际上可以将其拓展到更多的应用场合。例如，如果一个产品由若干个供应商提供，你可以用此算法发现供应商之间的相似度，在选择数据库存储方面，我强烈建议大家选择NOSQL类型的数据库，其中MongoDB是一款非常适合作为现如今互联网产品的后台存储数据库。正确的数据库选择可以为以后的扩展平滑的过度方案。在外面进行用户识别和整合的过程中存在一些错误的观念，很多人会忽略用户的来源，其实这正是一款互联网产品要抓住的要点，这方面的数据对后期业务拓展起到了至关重要的作用。例如，你发现用户大部分来自微信关注，而很少来自Facebook或者其他社交产品，可能要做的是加大微信广告的投放力度，或者增加微信公众号的推广、也有一些应用会把用户平级插入到新的用户表中，这样做实际上重复了大量相同的用户数据，而这些多出来的用户对产品的分析没有任何价值。还有些人在产品中加入 关键词捆绑，比如，当用户登录系统以后需要用户进行手机号注册，然后以手机号来 标识用户，这样做会增加用户注册成本，导致一些潜在用户放弃使用我们的产品。

　　综上所述，完善你的用户，只有更好的分析他们才是产品走向成功的基石。

转载请注明：http://www.fenxiang1d.com//wlyx/rwyx/1185.html