简单的用户登录流程 

简单的代码

if(用户名和密码不为空&& 用户名为注册过和密码正确){执行登录操作}
else if（用户名错误||用户名不符合规格）{执行提示账户输入有误}

else if（用户名正确&&密码错误）{执行提示密码错误且清空密码输入框}

else if（用户名和密码为空）{执行提示请输入用户名}

else{提示网络异常，稍后重试}

复杂的用户登录流程还需要考虑到

1、联合登录，绑定等

2、二次打开是否录入密码登录

产品思维：

1）使用场景：用户在浏览UGC或PGC内容时，感兴趣或有价值的东西，进行【点赞】

2）用户价值：传播个人价值观，对信息以及信息发布者的认可

3）商业价值：收集【点赞】用户个人信息，划分用户群体。发掘用户潜在需求，对留存转化提供参考价值

4）业务闭环：内容具有关键词，标签信息。精细化管理，个性化内容推荐，适当增加该类内容推送

技术思维：

1.【点赞】

1）用户打开该信息页面，通过API接口到数据库提取该信息被点赞数量，并在前端显示【已点赞】数据

2）用户点击【点赞icon】，前端根据交互操作，并更新icon状态。并根据状态通过服务器从数据库提取该信息数据

3）数据库读取该信息数据，并在在该列表原有的数据+1，再传回前端显示

2【取消点赞】

1）根据前端用户交互操作，前端判断icon状态，并将该状态通过服务器提取数据库信息

2）数据库提取数据，并在该数据-1，再传回前端显示

3.【关于点赞刷新】：【点赞或取消点赞】后，当前用户页面更新点赞状态，其他好友则需要在刷新页面后，更新【点赞/被点赞状态】

【产品思维】

① 点赞能引起用户的主人翁思维，让用户有很强烈的参与感；

② 点赞是一种心理认同，点赞过程中，用户自认为得到了好的观点、最新消息、美感图片，身心得到满足；而对于信息发布者来说，得到赞是一种关注和认同，有时也似乎是一种心理满足或期待。点赞背后的发信、收信双方存在着支持、欣赏、赞同等主观感情色彩，正因为如此，微信的点赞设置或功能才得到发挥；

③ 点赞是一种优秀的获客渠道，加强人与人之间的互动，从陌生到熟悉，从提防到产生好感，点赞能让更容易地打开人的心理防线；

④ 站在商业的角度，点赞不仅能获客，也能促活，以朋友圈为例，广告的点赞量不仅能直观反应这个广告在市场中的认可度，也能反映哪一类型的产品更为市场所接受（多条广告点赞横向纵向对比，做数据分析），以便公司及时调整业务策略及方向；

⑤ 点赞还能促使被赞用户生产更高质量的内容，带动整个圈子的活跃度；

【技术思维】

① 点赞功能简单，含义清晰，不需要用户过多思考；

② 点赞功能需支持取消点赞，避免有的时候手滑造成的不必要误会；

③ 点击按钮时，若已点赞，则发起取消点赞指令，否则发起点赞指令，接口将用户id、内容id传到后端，后端接受信息，更新对应内容的点赞数、点赞用户id，并在用户信息表中插入点赞文章id和时间，数据库执行后端发出的更新指令，后端通过接口将处理结果返回给前端，前端变更展示页面；

作为互联网从业人员，无论什么岗位，我认为都应该有一个产品实现运作的技术全局观。

1，客户端-服务端-客户端，这样的请求相应模型。

2，在请求相应模型中，客户端和服务端的通信内容是按照双方约定的格式进行打包，传输，接收，解析，返回等操作。这样的格式叫做接口。常见的接口有两种：JSON和XML。

3，了解编程语言的种类和使用场景，了解数据结构，数据类型，算法，方法，程序等大概是怎么回事。

4，了解客户端的基本知识，例如：Native和H5的实现方式及其各自特点。了解Android与iOS使用的技术语言不同，前者是JAVA, 后者是Objective-C or Swift。了解其基本的布局规则，了解其各自原生控件以及叫法，了解自定义控件。了解其适配问题，和各自采取的适配方法。

5，了解机房的组成，包括关键设备，支撑设备和装置，以及什么工程师用哪种技术做什么工作来保障。 也要了解云服务器的概念，以及当下的意义。

6，了解关系型数据库与非关系型数据库，尤其前者。表和表关系。表名，字段名，字段类型，主键，关系。了解操作数据库的语言SQL，用其对数据库进行相应的建表，增，删，改，查等操作。

7，了解从技术的角度拆解产品，理解产品的实现。理解工程师的工作难点，重点及其工作量。

8，自己要保持主动学习技术思维的热情，请教工程师，阅读数据库设计文档，API接口文档等。在产品升级的关键点，也是了解技术细节，了解兼容性的好机会。

现在对技术有了更加宏观的了解，知道怎么回事，知道某个技术处于整个实现体系中的哪一层，哪一列，有了更加立体的认知。

首先感谢起点学院这个课程，实话说真的挺不错的，虽然短了一点哈哈。

在学习课程之前，大致对技术架构这块是有一个了解的，但是都是工作中零零散散学到的，是不系统的。

通过这次技术课程，相当于梳理了一遍整个技术部分的知识，让我对全局观有了很大的改善。

跟IT大佬们沟通也顺畅了许多，毕竟接口文档我也能看懂了哈哈哈！

其实，当你对技术部分也有所了解了之后，与开发沟通也会更有底气，解释需求也就更加全面一些。

还是非常赞同没有学过技术的产品朋友来看一看这个课程！

再次感谢！

抱着以后在工作中不被研发的兄弟或忽悠、或鄙视等影响工作和谐的因素，这节课是非常基础的课程。

课程中我们了解到程序员平常是如何写代码的、不同端口对应的语言也不同，不过，现实中所有程序都会写的程序员基本不存在。因此，每一家企业中如果有需要基本都是不同端口对应不同的程序员。

程序员写代码时，非常注重功能流程，其逻辑思维严谨，因此，产品在跟研发沟通时，要尽量把每个功能点在各种条件下有可能发生的情况都穷举清楚。

其次，不同的客户端其对应的布局规则、控件特点、硬件适配往往不同，产品需根据实际应用场景在设计产品时，把不同端口的情况都考虑进去。比如IOS、APP、桌面应用、和WEB端就都具有不同的应用特性和使用场景。

另外，客户端数据往往都是通过服务器端的数据库获取的，客户端发起请求的机制和服务器端响应、反馈请求的机制，在产品设计时就要注明清楚，避免研发人员自由发挥后与原设计不符。

最后，在实际开发过程中，研发通常都是使用原生控件，少有自己开发，这种情况往往导致很多功能无法实现。因此在产品设计之前一定要跟研发商谈清楚哪些能做哪些不能做，避免需求、设计反复。

最后的最后，就像视频中老师说的，技术思维的持续提升几种办法：日常与研发沟通、需求/设计评审会上研发提出的问题、阅读数据库设计文档及API接口文档、产品迭代时的技术细节……其实总结来讲，应该就是在实践中慢慢积累经验吧。

愿，所有奔跑在产品这条线上的战友都能踏出自己的一条路。

共勉，谢谢~

一、用户名加密码登录

产品思维：

1、需要用户注册才能使用的登录方式，首次使用增加用户的使用成本

2、再次登录时，需回想该网站或客户端的账号和密码，增加用户记忆成本

3、用户名+密码的登录方式相比手机+验证码和第三方授权登录更为安全

4、用户名+密码的登录方式需要设计注册页面的必填字段和非必填字段

5、需要设计“忘记密码”的找回方式

技术思维：

1、建一张“用户表”，表里的字段包含“username”，“password”等

2、密码存入数据库中的加密方式

3、前端提交到后端的方式

4、输入特殊字符是前端验证还是后端验证，如何验证

二、手机号加短信验证码登录

产品思维：

1、省去注册环节，登录便捷

2、免去记忆用户名的烦恼，降低记忆成本

3、存在手机丢失或被盗，他人登录账号的风险

4、每次登录，系统发送验证码，成本较高

5、遇短信验证码发送失败等特殊情况将无法登录，有可能引起客户流失

6、可掌握用户手机号码真实信息，增加销售类机会

技术思维：

1、需要验证手机号码的正确性，如：全部为数字型，且为11位

2、考虑短信发送的接口

3、如何验证手机号和短信验证码的正确性

4、如何防止同一手机号在短时间内连续请求接口

5、在数据库中如何将此“手机号”匹配用户信息

三、第三方平台账号授权登录

产品思维：

1、无需注册，登录便捷

2、无需记忆用户名，降低记忆成本

3、针对该产品需要考虑哪些第三方平台账号可以登录本系统

4、可将本产品分享到原第三方平台中，增加产品曝光率，提高产品使用人数

技术思维：

1、需要获取第三方的接口，且要对方授权

2、如何在第三方返回的信息中匹配该客户信息

选择作业（1）

刚开始进公司，对公司架构系统人员都不清楚，突然接了个紧急需求。是做数据回传的，那时候不懂接口到底是什么意思，不知道接口文档对于数据回传的重要性，不知道看接口文档字段定义是否和业务要的数据相同，etc.跟别的公司对接一个产品的时候很多应该确认的问题没有确认，而且对接的对方公司的开发还经常换人，导致整个需求沟通过程非常混乱。做完数据回传以后还要给业务做数据采集也不清楚是联系运维的人进行数据采集

这个过程挨了很多骂，但是知道了json,xml等术语，还有加密的一些术语，虽然现在看来不是产品经理应该管的。虽然中间出现了很多不愉快，但是最终搞清楚了弄清楚用户想要的是什么，是需求的根本，从这点出发，完成需求，能否实现是后续产品经理需要持续沟通和确认的过程，接口文档也是需求编写数据回传的一个重要依据，两者相结合才是用户+技术的结晶体。

数据采集还是向别的同事请教，然后了解了是运维的工作。

一、背景

设计一个积分中心，有一个做任务领积分的模块，积分中心以h5的形式呈现，需要搭建一个积分后台。

二、遇到问题

数据从哪里来？实时性如何保证？

一开始对标了市面上的积分中心的设计，基本都是实时获取到数据，用户能够完成任务后马上可以领取到积分的。但是技术同事说，这个取数是从大数据分析平台来的，是T+1的，如果是客户端取数，有数据不准等问题。因为不懂技术的原因，也没有问清楚为什么不准，所以在跟领导汇报方案的时候就挨批了。

后来是领导（技术出身的）要求技术同事评估，基于客户端实时取数有什么问题，罗列出相关问题后再汇报，这些问题都是可以在接受范围内的，所以采用客户端取数的方案。

三、总结

这件事情上，没有起太大作用，是靠领导推动。反思虽然技术同事说不准，但是作为产品经理应该了解清楚为什么不准，能否有办法解决。不能只有一个结论，应该要了解为什么有这个结论。

（1）产品与技术沟通时，你遇到过什么因为不懂技术而棘手的问题吗？你是如何解决的？（建议已经接手产品工作的同学完成）

第一次设计一个后台系统的时候，遇到不少问题：

1、功能基本确定的时候便开始开发工作，但是一些细节方面的问题并没有认真考虑，比如如何搭建一个会员体系，如何将订单同步到公司的财务系统，如果订单状态同步到公司其他后台管理系统时发生异常时采用哪种方式解决，如何对外输出给第三方等等。导致正式开工后仍然用了很长的时间来确认需求及实现方法。

2、第一版开发中，补充了一些一开始没有想到或者没有确定的需求，导致加长了开发周期，并且需要对原来的结构进行调整，开发量较大。

解决方案：一边总结一边改善，尽量思考全面可能会发生的问题，并寻求解决方案。

总结经验：产品需求必须确认各个细节，不仅要满足用户需求，也要结合各方人员，比如公司其他会使用到的人员及公司合作方的角度思考需求合理性，并且需要结合对产品的运营发展规划做考虑，从整体需求到各个功能到每个页面细节都要安排合理。然后跟开发人员确认开发难度及优先级再开始开发工作，并且需要确保需求表达无误。

一、不懂技术而棘手的问题

成为产品是一个非常阴差阳错的过程，18年毕业季，本以为回归到本专业相关的岗位-金融，最后不知怎的又当回了求职初期最想做的产品。那时候专业是金融，每天上着银行保险证券相关课程的我来说，对于产品的理解也仅限于网络上的资料，大部分都不懂，更别说技术和方法论了。入职初期，大致了解了PM的日常工作内容和流程，后面开始自己写需求，因为对技术一窍不通，不知道什么事“写死”，不知道什么是“富文本”，技术口中一堆tab还有各种专业名词经常让我一脸懵，后来适应了，却陷入了不跟技术沟通，后续需求评审出现实现不了的情况，再跟进开发，测试，上线，让我一度怀疑人生。记得当时公司活动开展比较频繁，希望后台能够自定义弹窗挂件等广告位而无需每次都重新开发，这里涉及次数，端口，是否登录等，不但要推翻以往的架构重来，还要增加非常多的限制，对于技术来说，工作量很大吧，当时不了解技术的我认为技术都是可以实现的而不肯退步，所以经常往返部门沟通，结果是直至上线那个问题也确实没有解决。

二、解决方法

那一次之后，我知道了技术是有边界的，由于当时不懂，而没有去和技术一起探讨planB，也懂得了非技术出身的PM学习一些技术知识是非常有必要的，能够极大的减少双方的沟通成本。针对于此，我明白了自己在技术模块的不足，以往我都是通过技术耐心的解释，百度，前辈指导来进行碎片化的学习然后运用在工作上，但这是远远不够的，因此买了相关书籍，报名线上课程，希望学习完之后，在以后的工作中，和技术小伙伴的合作更加顺畅愉快。

以解决小孩在家生病发烧的问题为例，我理解的技术能力与技术思维的区别如下图所示：

产品思维：

    几种登陆方式的区别如下表：

    为方便用户，一般采用以上多种方式复合来进行登陆，B端产品可用1、2两种方式复核，C端产品可用2、3，或者1、2、3几种方式复核，让客户去选择自己最喜欢的登陆方式。

    另外，如为移动端产品在同一个设备上的非首次登陆，还可以根据设备支持的功能来使用指纹、虹膜、手势、面部识别等方式来进行登陆。

技术思维：

    几种登陆方式的流程简图如下图，因时间原因未遍历登陆过程中可能遇到的各种问题及对应需要反馈给客户的信息。

    手机号+验证码的方式不管是登陆还是注册都比较简单；

    第三方验证码有与第三方接口进行交互的过程。

    注册过程中的邮箱链接确认也需要通过接口获取信息来进行校验。

【产品视角】三种登录方式优劣势比较

1、用户名+密码登录

优势：用户名基本不泄露用户隐私

劣势：1）容易忘记用户名和密码；2）输入操作复杂，移动端操作不方便；3）创建账号成本低，产品里的一些福利容易被刷

总结：不建议让用户在注册时创建用户名，并且以此作为登录的唯一凭证

2、手机号+短信验证码登录

优势：1）不需要记住密码；2）手机全民都有，使用方便；3）产品流程简单，注册和登录放在一起搞定，也不需要找回密码功能

劣势：1）PC端不方便，用户需要到手机端找到验证码后回到PC端填写，场景是割裂的；2）存在用户手机号更换的情况，需要修改手机号；3）用户可能会担心隐私泄露问题

总结：手机号作为日常快捷登录方式，在移动端体验更好；同时要防止用户手机丢失/换手机号的情况，最好结合其他登录方式一起，登录后可修改绑定的手机号

3、第三方平台账号授权登录

优势：1）点击授权即可，不需要输入操作，快捷登录较方便；2）共享第三方应用的用户关系链；3）直接获取第三方应用的用户头像、昵称，减少用户操作成本

劣势：1）用户需要下载第三方应用并保持登录状态，否则登录流程复杂度会大大增加；2）自身账号体系不能过分依赖第三方，通常需要和上面两种登录方式组合使用，首次登录后绑定手机号/用户名

【技术视角】三种登录方式实现方式对比

1、用户名+密码登录

2、手机号+短信验证码登录

3、第三方平台账号授权登录

【总结】在不同的场景中，具体该如何选择登录方式？

场景一：新产品研发，时间比较紧，只能选择一种注册登录方式做，以便快速上线验证。

选择：手机号+验证码的方式

理由：比用户名+密码实现成本更低，前端登录和注册同一个页面，用户使用便捷，也不需要做找回密码的功能；同时又比第三方登录安全。

场景二：已经有了手机号验证码的注册方式，但渐渐发现不够用了，经常有用户需要更换手机号。

选择：增加用户名+密码/手机号+密码的登录方式，首选还是手机号+密码；

理由：密码登录不需要依赖手机，是对手机+验证码登录的一个补充，且手机号比用户名好记和简单。

场景三：目前产品的登录体系较完善了，希望简化用户操作，提升安装→注册/登录环节的转化。

选择：第三方登录，优先选择微信、QQ、支付宝这样的全民产品；

理由：在产品登录体系较完善的情况下做第三方登录，既不至于过分依赖第三方，也简化了用户操作。

当然，设计登录注册体系的时候还需要考虑产品本身的因素，比如公司内某兄弟产品是用邮箱注册的，后续会需要做账号打通，那么可能就需要优先预留邮箱的字段。

  一、基于产品思维的分析

 1. 用户价值（需求分析） 分析场景之前，首先需要明确需求背景和要解决的问题或者痛点。用户登录一般和用户 注册作为一体化功能进行设计，注册/登录的需求痛点是，在注册/登录之前，用户和服务方之间处于数据无关联的状态。而注册/登录的功能，则是服务方为用户建立身份标识，从而使用户和服务方之间的数据达成关联，所实现的用户价值就是可以基于用户身份标识，针对不同的用户给予不同的权益。

 2. 几种登录方式介绍和简单分析 

 用户在完成注册后，之后访问服务方数据的方式就是通过登录环节了。每次登录时，都 需要通过某种验证方式对用户的身份进行校验，从而确认对应关系是否正确。 

 （1）用户名加密码 用户名加密码最常见的一种登录方式。该方式的优势在于：①用户学习成本较低。②相 比第三方账号登录，注册登录的数据掌握在自己手中，获取用户的数据；③ 账号体系外部依赖少，安全性较强。该方式的缺点：①字符串的标识性不够强，很多人会设置相同的密码；② 安全性不够高，简单密码非常容易被破解③当通过提高字符串的复杂程度来提升密码安全性时，用户的记忆成本也随之提高，给用户会带来一定的问题，比如忘记密码等。 

 （2）手机号加短信验证码 随着手机号的实名制，手机号和个人的关系越发紧密，通过手机号作为个人的账号标识 也就顺理成章。该方式的优势主要是便捷，以及基于手机通信的相对安全性。缺点是需要考虑短信成本的问题，发送短信验证法是一项需要收费的服务。 

 （3）第三方平台账号授权登录 属于增加用户多端登录便捷性的行为，本质上不属于验证方式。一般流程是：点击第三 方账号快捷登录按钮、进入第三方账号登录授权页，如果已经绑定该第三方账号则直接登录，若无绑定账号则一般直接创建新账号并绑定登录。优点是：流程短，登录速度快，注册转化率高，背靠第三方丰富的用户信息，有利于快速推广等。缺点是对外部的依赖性较强。

 3. 产品使用场景 

 以下是针对不同的场景做出了不同的登录方式的选择分析。 

 （1）以获取新用户为目的 

 如果以获取新用户为目的，既然是拉新希望留住用户，就需要尽可能在用户首次体验产 品的时候留下一些好的印象。因此在登录的环节不应该让用户抱有抵触的情绪，建议优先使用手机号以方便快捷登录从而快速体验。 如果此时产品和第三方平台有连通，也可以通过第三方账号登录，可以凭借第三方账号作为产品的背书，进而进行后续的产品推广等。

 （2）以收集用户信息为目的     

 如果是希望能够通过收集用户信息，针对用户的浏览习惯和偏好等对用户进行个性化推荐等，建议使用自有账户体系，比如用户名加密码的方式，此时就不建议使用第三方平台账号的授权登录，因为还要依赖第三方平台。 

 （3）需要针对不同用户分配不同权限      

涉及到权限，需要账号体系的安全性更高。此时推荐手机号加验证码的方式，因为安全性相对较高，忘记密码可以通过手机号进行重置密码的操作。而用户名加密码则存在密码相对简单或者密码被破解的风险；使用第三方账号则也会对第三方账号有依赖。 

 （4）已有PC端产品现在新增手机端产品 在PC端已有一定数量用户的前提下，用户很多是通过邮箱进行注册，并没有进行手机 号码的绑定或者第三方账号的关联，所以如果采用手机号或者第三方登录的情况，可能导致老用户又创建了一个新账号，而这个新账号和老账号之间并没有任何关联，这时候将会给用户带来较多的困扰。

 二、基于技术思维角度的分析  

登录功能，用技术语言解释就是，提供给用户接口，让用户填入某些标识信息来与系统中已有的数据进行身份验证匹配并赋予用户某些特殊功能使用权限的过程。

 1. 实现方式 

 （1） 用户名加密码 

 客户端输入账号和密码→内容传到服务器→服务器接收发来的请求→服务器端程序 查询服务器端数据库→服务端程序根据数据库反馈的结果确定是否登录成功→服务器端程序将请求的结果返回给客户端→客户端根据结果进行接下来的操作。 

 该种方式涉及的交互只有客户端和服务器端，无须和第三方之间进行交互。 

 （2） 手机号加验证码 

 客户端输入手机号并且点击发送验证码的按钮→请求发送至运营商→运营商反馈验 证码的结果到用户手机→用户将验证码结果输入客户端并登录→登录请求传到服务器→服务器接收发来的请求→服务器端程序查询服务器端数据库→服务端程序根据数据库反馈的结果确定是否登录成功→服务器端程序将请求的结果返回给客户端→客户端根据结果进行接下来的操作。 

 该种方式需要与运营商之间进行交互。 

 （3） 第三方账号登录 客户端点击第三方账号快捷登录按钮→服务器接收发来的请求→服务端向第三方服务器发送授权登录的请求→第三方服务器接收请求→第三方服务器进行查询，确认是否经绑定该第三方账号→返回结果：如果绑定则跳转到第三方账号登录授权页，若无绑定账号则创建新账号。

 该种方式需要和第三方账号之间进行交互。

 2. 前后端开发任务 

 通用的功能都是需要用户登录页面、登录成功后的页面展示；都需要考虑的异常流是： 登录失败后的展示页面，忘记密码的设计，是否允许多端登录（最多允许几个设备在线），异地登录的提醒，设备环境异常的处理（比如网络连接失败等） 

 （1）用户名加密码     

前端：需要给出密码安全等级强弱的提醒、需要对密码不规范等作出提醒

后台：需要完善针对字符串复杂程度的校验 

 （2）手机号加验证码 

 前端：需要给出60s内收不到短信的提醒、需要给出频繁获取验证码的提醒等 

 后台：需要设计和运营商之间信息的交互；需要能够针对运营商通讯异常等情况作出处理。 

（3）第三方账号登录 

 前端：包括绑定了第三方账号登录后的页面和未绑定第三方账号登录后的页面

 后台：需要设计和第三方平台之间的交互，需要能够针对第三方平台出现的问题进行处理。

 三、登录方式的趋势 

 登录/注册会朝着交互方式越来越简单，认证方式越来越安全的趋势发展。基于人的生物 特征来进行。比如指纹登录、人脸识别等。

有如下的优势： ① 一方面，人的生物特征更加具有唯一识别性以及稳定性，可以长期进行使用； ② 另一方面，生物特征的识别并不需要用户进行过多的输入操作，非常便捷。     

一、 户名加密码登录

1.1 产品思维

优点：

• 安全性较高
• 当用户手机不在身边，或者手机没电的时候，是无法获取验证码信息的，这种情况下账号密码登录就会显得极为好用了。
  

缺点：

• 对用户有记录账号、密码的负担
• 方便账号的共享，可以把账号密码提高给别人使用。
  

1.2 技术思维

• 从系统本身的数据库进行遍历检核，无对接需要，技术实现相对容易
• 判断用户名&密码是否为空，判断用户名是否存于在用户中心、判断密码是否验证通过，各种场景下的错误提示方案。
  

1.3 适用场景

• 适用于用户量较大的产品
• 适用于对用户信息量要求较多的产品，后期开展运营活动的产品
• 适用于对账户安全性要求较高的产品  
  
• 匿名社交型APP，如陌陌，探探原因：匿名社交注重自己的私密性，许多人不希望在社交网络透露自己的隐私号码。因此在这类社交APP上，注册账号密码，能够让用户信息更加私密，可以选择不绑定手机号码和社交软件，对于用户的隐秘性做了保护。
  

二、手机号加短信验证码登录

2.1 产品思维

优点：

• 对用户无记忆账号和密码的负担，使用较为便捷
• 移动端基本采用的都是这一种方式，可以掌握用户的真实信息，搜集用户信息，有效增强用户管理，对以后的用户运营工作很有帮助， 可第一时间给用户发送短信，增加用户的参与度以及转化率：甚至对于一些较少上线的用户，也可以通过给用户发送短信吸引这些用户的回归
  

缺点：

• 安全性相对一般，一旦手机落入他人之手，可能造成安全事故
• 多次登录需多次获取验证码，有时也会造成不便。除非设置可长时间登录。但如果这样做，又会有安全隐患。

2.2 技术思维  

• 需要引入运营商
• 手机号&验证码是否为空，判断手机号是否存在于用户中心；短信提供商、短信触发机制，短信验证码下发成功及超时情况、验证是否通过，各种异常情况的提示方案。
  

2.3 适用场景

• 工具型APP：如顺丰物流APP，美团外卖APP。工具的使用，不是长时间在线的，可能只是完成某个任务，例如点个外卖，或者查询物流，这种工具随意性大，如果每次都需要输入账号密码会让用户觉得很麻烦。并且手机号码作为联系方式的通讯，方便用户和平台方。因此，手机验证码登录能解决用户快速登录的需求，并且不需要记录密码，方便操作。
  

三、第三方平台账号授权登录  

3.1 产品思维

优点：

• 第三方登录方式无疑是更加方便，最省用户时间的一种登录方式  
  
• 这种登录方式将有效性，安全性的问题交给第三方，不需要在这一块多花力气，有一种借力的感觉
• 方便了账户的统一性，不需要不同平台注册不同账户，只要授权API即可。
  

缺点：

• 无法获得有价值的用户信息，同时无法构建用户的管理体系，这种登录方式最多就是获取用户在第三方的用户名，头像，性别等等比较浅层的信息，至于像用户在第三方更深入的资料，一般都是获取不到的
• 这种登录方式很难共享给他人，因为需要本地授权。
  

3.2 技术思维    

• 第三方是否提供用户额外信息，登陆成功、登陆失败、登陆超时的各流程处理。
  

3.3 适用场景

• 游戏APP：游戏加入了社交元素，微信登录能方便的与好友互动，提高用户日活，同时提高用户的体验，用户可以要求朋友一起玩游戏
  
• 经常适用的工具：如有道云笔记。可使用qq登录。原因在于大部分人qq使用得比较频繁，利用已经登录的qq，实现登录，可减轻记忆账号密码的负担，并且qq的使用已经成为习惯，登录qq不是一种负担。
  

登录产品的方式，传统的有三种，用户名和密码登录、手机号加短信验证码登录、第三方平台授权登录，随着技术的发展，现已有根据生理信息登录，如指纹、面部、声音、视网膜等。

从产品思维、技术思维的角度，分别分析各种登录方式如下。

一、用户名和密码登录

1、特点

（1）简单高效。只需账号密码即可登录，无需提供个人隐私信息，账户可以是手机、邮箱、工号、身份证、用户名等。

（2）可多人使用。拥有账户和密码的人都可以登录，可以多人登录共享使用。

（3）产品重要程度高。此类产品需对用户非常重要，用户不得不记住账户密码。如果这个产品对用户可有可无，那么，用户大概率会因为记不住账户、密码而放弃该产品。

（4）技术实现简单。账户、密码类型，可自定义，与现有的库进行匹配即可。为了保证用户重要信息，需考虑登录账户的时效性。

2、适合的场景

（1）2B类产品

一般企业级系统、SAAS等产品，会以每位员工的工号作为账户、员工自定义密码的形式登录企业的各类系统。员工离职后，也便于交接注销等等。工号和密码，也是员工必须得记住得知识。

（2）金融类产品

保密性较高的各银行类金融产品，保密级别要求高，必须使用账户（一般是身份证）加密码登录。

（3）2C类硬件产品

如PC电脑、手机等开屏密码。

（3）部分私密的2C产品

部分2C的产品，用户并不想过多的提供自己的信息，追求私密感，比我日记类。早期的QQ，也只需账号和密码。当然，随着互联网监管越来越严，此类产品越来越少。

二、手机号加短信验证码登录

1、特点

（1）通用性强。手机是常见的账户，验证码是实时发送的，客户可实时登录。

（2）用户信息全面。根据用户手机，可获地区甚至个人实名信息，易绘制精准用户画像，精准营销。

（3）方便活动运营。可根据手机短信，推送活动信息，有利于做活动运营。

（4）推广拉新难。用户可能因担心隐私不愿泄露手机号而放弃产品。

（5）被盗用风险高。如手机被盗，或者通过其他途径得到验证码，易产生账户被盗用的风险。

（6）技术上较为复杂。需调用第三方SDK模块，实现发送短信请求、接收验证码、验证码有效时间控制、防止恶意调用服务等。

2、适合的场景

（1）2C类软件产品

如电商、社交等2C类产品，需尽可能多的获取用户的信息，进而针对用户做精细化运营和营销，进而实现增长。

（2）筛选高净值用户类产品

如电话销售类，需通过校验电话号码的真实性，提升拨打的接通率，进而提升转化率。

三、第三方平台账号授权登录

1、特点

（1）覆盖面广。常用的第三方有QQ、微信、微博等社交账户，覆盖全面。

（2）操作简单。无需注册、密码、验证码，仅需授权，就可快捷登录。

（3）不同账户数据难以统一。当户用户用不同第三方账户登录时，难以将多个账户统一到一个用户ID下。

（4）技术实现复杂，需调用第三方授权，且需适配多种场景。安卓端、iOS端，需调用终端上相对应的应用，PC端需适配不同观点浏览器。微信小程序中实现较为简单。

2、适合的场景

（1）微信小程序、公共号等

微信生态下，直接用微信号登录，简单快捷，也是目前最常用的第三方账户登录场景。其他各自应用内登录同理。

（2）平台服务型的产品

平台型的产品，只需大叔据，对精细化用户画像需求少。例如豆瓣、知乎等。

（3）部分2 C类产品

如社交、游戏、教育等广泛移动端产品。

现在大部分的规则，在用户使用第三方账户登录后，如发现是新用户，则仍然需要用户注册登记手机号及验证码。

四、 生理信息登录

1、特点

（1）智能高效。根据用户基本你的生理信息， 如指纹、面部、声音、视网膜等，代替用户账户，一步完成身份及密码验证。

（2）用户信息准确。每一个生理信息，即可确认唯一的用户，无需校验多种账户、设备。

（3）技术要求高。用户设备需支持生理信息识别，需调用第三方生理信息识别SDK，使用效果依赖于第三方识别的准确性。

2、 适合的场景

（1）2C类硬件产品

如电脑、手机的指纹识别解锁，手机的面部识别解锁

（2）金融、安全类产品

如公安系统人脸识别、银行人脸识别等

具体应用中，应从产品对与用户的重要性、安全性、使用频率、使用场景、技术成本、监管政策等各方面综合考虑，选择最合适的一种，或者多种混合的登录方式。