产品逻辑之美 - 知乎专栏
{"debug":false,"apiRoot":"","paySDK":"/api/js","wechatConfigAPI":"/api/wechat/jssdkconfig","name":"production","instance":"column","tokens":{"X-XSRF-TOKEN":null,"X-UDID":null,"Authorization":"oauth c3cef7c66aa9e6a1e3160e20"}}
{"database":{"Post":{"":{"title":"【登录注册设计·下】注册登录功能大盘点","author":"pan-yiming-61","content":"0. 前言：一个产品该如何识别自己的用户？哪些场景要求用户登录或者注册？注册需要哪些信息？用户登录需要校验哪些信息？在互联网产品长期发展中，很多问题大家也基本总结出了标准化的方案。这期主要是围绕这些问题，盘点登录注册流程的各种功能以及其应用场景。1. 一个产品该如何识别自己的用户？这个问题比较宽泛，其实要识别用户主要分类为两种场景：登录前，登录后。登录前：大部分产品登录前是可以使用很多功能的，这里就存在一个用户识别的问题，解决方案主要是取决于用户使用的平台。如果使用的是浏览器，主要的方法是通过cookie。如果是移动设备，则可以使用设备ID，比如Android的device
ID,iOS的IDFA。当然，如果是微信平台，也可以使用微信的OpenID。登录后：登录后识别用户的方式也有多种，比如使用的第三方账号ID，比如使用注册手机号，比如使用注册的邮箱。但是，最一般也是最推崇的做法是，使用自己的一个user ID。同时，所有的产品功能如果需要识别用户身份，也都应该用user ID进行识别。同时，手机号，注册邮箱、第三方账号等其他关联信息，都应该可以和这个user ID进行关联。这样能最大程度保证账号体系的稳定性和扩展性。2. 哪些场景下要求用户登录或者注册？要求用户在使用产品前注册或者登录，是最简单粗暴的方法，但是这里可能对用户增长有很大的影响。所以对于用户认知没那么高的产品，一般而言，不会要求用户立即注册或者只是要求简单的注册。把注册流程或者补充注册信息的内容，后置到一些关键节点，是更明智的做法。比如：查看更多评论的时候查看其他用户个人主页的时候评论和点赞内容的时候商品结算的时候企图使用某些特权功能的时候典型的做法，比如电商，点击购物车结算才会要求用户登录注册，这样的方式更能留住用户，而不是在使用产品之前就流失。3. 注册需要哪些信息？3.1 可验证的外部账号验证比如手机号、邮箱这些个人通讯账号，或者有通讯账号属性的社交网络账号，比如QQ号，微信号，微博账号。一般而言，这些账号的特点是，可进行验证性。比如邮箱、手机的验证码，微信QQ、微博账号的授权登录。可验证性的本质有两点：可以验证用户身份的有效性可以在密码丢失的情况下找回密码当然，为了最大程度保证账号安全，这个外部账号最好可以是手机号。3.2 用户名和密码填写用户名和密码是用户注册一个传统的方式。但是这个方式目前也存在很多问题，比如被撞库。现在有些产品已经在尝试去掉这个环节。一方面是为了简化注册流程，增加注册转化。另一方面，移动时代，APP基本可以一次登录一直用，登录情况比较少，完全可以用手机号验证码登录，或者三方登录进行。3.3注册验证码注册验证码是为了防止机器大量刷注册量，尤其是部分注册不需要填写手机号的产品。可以使用图形验证码，也可以使用比较简单的用户行为验证码（需要了解验证码，可以查看上期内容）。4. 用户登录需要校验哪些信息？这个也是和用户使用的登录方式有关，根据用户登录的方式，一般分类为一下几种：账号密码登录：用户输入账号密码登录第三方账号登录：第三方账号授权校验手机验证码登录：用户属于关联手机号和手机验证码进行登录账号密码登录有极大的撞库风险。一般而言，用户只用一个手机号，使用这个手机号在各种产品上进行注册。而有大量的用户使用相同或者相似的密码，一旦有产品安全漏洞，密码泄露，其他平台则可以被撞库登录。第三方账号也存在相同的风险，一旦第三方账号密码被他人获取，则可以轻易登录网站。所以如果是账号密码登录，第三方账号登录，存在异常登录情况，则需要进行安全信息的验证。5. 异常登录判定和安全信息验证异常登录的判定也是一个相对比较复杂的过程，基本上对于大的公司，比如阿里，是一个大的团队在做。简单来说，收集用户登录的各种行为进行校验。包括但不限于：登录地点：如果一直在北京使用产品的用户，两个小时后出现在广东，则系统可能会判定为异常。登录设备：对于移动登录，如果更换了移动设备，则系统可能判定为异常。登录网络环境：IP变更，4G和wifi的变化，系统都需要判定是否为异常。校验既可以是简单粗暴的给策略，也可以是用大量的数据样本进行机器学习，进行判定。安全信息验证部分，如果用户绑定了手机号（手机号相关内容可以查看上篇），则可以直接要求用户进行手机验证。如果用户没有绑定手机或者用户暂时不方便使用手机，则可以使用图形验证码或者用户行为验证码验证。或者也可以使用产品的信息进行验证，包括但不限于：历史购买物品历史状态定位地点通讯录内容验证发送给通讯录好友进行验证当然，如果用户都不能通过自动流程，也可以进行人验证，提供一些无法格式化提供的信息进行验证。6. 小结登录注册流程是很多初级产品经理书籍里面经常提到的Case，比如交互的书就会说按钮怎么调整，注册率上升了多少个点之类。然而，这些流程其实只是一小部分。基本上，在之前产品设计不犯错的情况下，也不会有一个按钮调整上升多少个点之类的传奇。此篇文章没有讨论登录注册交互层的东西，更多的是对于登录注册逻辑的总结讨论。牵扯到很多异常的Case。产品经理的初级阶段可能只能看到几个简单页面的调整，其实合格的产品经理更应该是看到页面的逻辑，以及因为逻辑而派生出来的更多页面。登录注册流程正是这样看似简单，实则牵扯很多复杂逻辑和异常Case的流程。如果非要有什么拔高性的结尾，那么我想说的是：不要以为只沉迷在书上那些摆放按钮的故事中，就可以做好一个产品。------------------------------------下期预告：【推荐系统那些事儿·一】从余弦公式讲起","updated":"T16:52:45.000Z","canComment":false,"commentPermission":"anyone","commentCount":7,"likeCount":30,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T00:52:45+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-c6c53fc3fa551d5cec3354_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":7,"likesCount":30},"":{"title":"【推荐系统那些事儿·一】从天猫双11到余弦公式","author":"pan-yiming-61","content":"0.前言：电商的双十一结束了，天猫今年有了很大的变化。很多人都有这样的感受：“天猫的双十一会场，怎么都是我自己想买的。”在这背后，其实是天猫推荐系统巨大的改变革新，甚至对于其他电商而言，几乎是碾压级别的革新，即使是最为接近的京东。1. 天猫京东前端对比首先是简单的架构图，大家可以看一下，天猫和京东相比，架构层面差别不大，区别在于，天猫把秒杀商品单独列出来作为一个tab。从推荐质量而言，天猫和京东处理得都不错，比如我在天猫主要消费类型为服装，京东主要消费类型为书籍，可以看下效果（天猫主会场首屏&京东我的双十一·为你精选）：2.
淘宝京东推荐逻辑对比京东和天猫的组织结构除了常规的店铺和品牌维度，双十一的组织形式主要围绕两个商品组织形式展开：会场，清单。所以主要需要对比的点，也在于会场和清单的组织形式上。天猫和京东推荐的共性：在会场列表上，实现了个性化推荐在清单列表上，实现了个性化推荐在个性化推荐的单品排序上，实现了个性化推荐天猫比京东做的超前的地方：会场引导图上，淘宝实现了个性化推荐（你我都看到了男装专场，但是我们男装专场的引导图不同）清单引导单品上，淘宝实现了个性化推荐（你我都看到了XXXX必败清单，但是我们每个人的引导单品不同不同）会场内部的组织排序，实现了个性化推荐京东的清单是静态清单，运营手动或者工具生成。但是淘宝的清单是自动聚合生成，根据每个人的情况高度定制。天猫推荐更新时效很快，可感知到每逛一段时间，天猫会根据最新的用户行为，更新双十一会场。总而言之，从亚马逊“买过了人还买了”协同过滤推荐应用以来，推荐算法在电商的应用达到了一个新的高度。天猫引领的本次革新，会对互联网产品有很深远的影响。这也是在本次文章留出一半篇幅来简单总结天猫和京东双十一的原因。3.
推荐系统的核心是什么在线下导购时代，导购员会通过比较系统的话术，了解用户的情况，给用户推荐东西。以化妆品导购为例，导购员需要了解用户的肤质，品牌偏好，消费能力，使用习惯等等信息，然后给出最符合用户的商品推荐。仔细考虑下导购员的思维逻辑，我们可以做一下还原：了解用户的信息，知道用户的类型。同时导购员了解全部商品的信息，知道什么类型的用户适合什么类型的商品，并进行推荐。这其中最核心的是三点：将用户的信息转化为用户的类型了解全部商品应该归属的类型了解什么类型的用户，适合什么类型的商品而这也是推荐系统算法需要思考的三个核心问题。无论是要给用户推荐商品，还是新闻，还是音乐，核心逻辑都是相同的。4.
从余弦公式讲起先思考一个问题，我们怎么量化两个事物的相似度呢？当然，这也是推荐系统需要多次面临的问题。我们知道向量的概念，可以形象化地表示为带箭头的线段。二维空间向量表示方法为r\\left( x_{1} , x_{2} \\right) ,多维空间向量表示为r\\left( x_{1} , x_{2},\\cdot \\cdot \\cdot ,x_{n} \\right) ，向量是描述事物一种很好模型。比如，假设用户有5个维度对服装的喜欢程度（1~5分），对家居的喜欢程度（1~5分），对3C的喜欢程度（1~5分），对图书的喜欢程度（1~5分），对化妆品的喜欢程度（1~5分）。一个用户A：对服装的喜欢程度3，对家居的喜欢程度1，对3C的喜欢程度4，对图书的喜欢程度5，对化妆品的喜欢程度0，用户A可以用向量表示为r_{A} \\left(3 ,1,4,5,0 \\right) 一个用户B：对服装的喜欢程度3，对家居的喜欢程度4，对3C的喜欢程度5，对图书的喜欢程度0，对化妆品的喜欢程度2，用户B可以用向量表示为r_{B} \\left(3 ,4,5,0,2 \\right) 这两个用户的相似程度是多大呢？既然我们把这两个用户表示为向量，那么我们可以考虑向量怎么判断相似性。没错，看这两个向量的夹角。夹角约小，则相似度越大。对于向量r_{A} \\left(A_{1}
,A_{2} ,\\cdot \\cdot \\cdot ,A_{n}
\\right) 和r_{B} \\left(B_{1}
,B_{2} ,\\cdot \\cdot \\cdot ,B_{n}
\\right) 而言，他们的在多维空间的夹角可以用向量余弦公式计算：cos\\theta =\\frac{\\sum_{i=1}^{n}{A_{i}\\cdot B_{i} } }{\\sqrt{\\sum_{i=1}^{n}{A_{i}^{2}
} } \\cdot \\sqrt{\\sum_{i=1}^{n}{B_{i}^{2}
} }} 余弦相似度的值本身是一个0~1的值，0代表完全正交，1代表完全一致。就刚才用户A和用户B的例子而言，我们可以知道他们的相似度为：cos\\theta =\\frac{3\\cdot 3+ 1\\cdot 4+4\\cdot 5}{\\sqrt{3
^{2}} \\cdot \\sqrt{3
^{2} }} =0.64余弦公式本身应用范围很广，量化相似度在搜索推荐，商业策略中都是常见问题，余弦公式是很好的解决方案。就推荐本身而言，计算内容的相似度，计算用户的相似度，计算用户类型的相似度，计算内容类型的相似度，这些都是可以应用的场景。5. 总结本期简单总结了双十一天猫京东的活动会场推荐策略的使用。天猫的推荐模式，是非常有想象力的一次革新。同时本期作为推荐系统的开篇，简单介绍了余弦定理，这是一个衡量相似度简单实用的方法。其实很多看似复杂的问题，实现原理都比较简单，比较容易理解。思考问题，分解问题，构建合理的模型，量化问题，计算和解决问题。这是一个问题从提出到有策略化得解决方案，所要经历的步骤。双十一天猫告诉我们，推荐系统可以做到的事情有多神奇。将推荐问题量化，余弦定理只是最基础的一步。那么推荐都有哪些类型？余弦定理是怎么被应用在推荐系统中？欢迎关注专栏，阅读下期。------------------------------------下期预告：【推荐系统那些事儿·二】常用推荐策略介绍","updated":"T01:59:02.000Z","canComment":false,"commentPermission":"anyone","commentCount":23,"likeCount":103,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T09:59:02+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-b1e00a88_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":23,"likesCount":103},"":{"title":"【推荐系统那些事儿·二】常用推荐策略介绍","author":"pan-yiming-61","content":"0. 前言：在上一篇文章中，我们简单分析了双十一天猫和京东的推荐策略，同时也介绍了计算相似度的余弦公式。本期我们会介绍下常见的推荐策略，以及这些策略背后的逻辑。1. 推荐的本质是什么推荐和搜索本质有相似的地方。搜索满足用户从海量数据中迅速找到自己感兴趣内容的需求，属于用户主动获取。推荐则是系统从海量数据中根据获取到的用户数据，猜测用户感兴趣的内容并推荐给用户，属于系统推荐给用户。本质上都是为了在这个信息过载的时代，帮助用户找到自己感兴趣的东西。推荐系统有很多种形式。运营或者编辑筛选出自己认为最好的内容放在首页，广义上讲这也是一种推荐。不过这个不在我们本期文章的讨论范围，本期主要是讨论系统级别的推荐。这里主要介绍四类常见的推荐方法。基于内容的推荐基于内容的协同过滤基于用户的协同过滤基于标签的推荐2. 基于内容的推荐基于内容的推荐是基础的推荐策略。如果你浏览或购买过某种类型的内容，则给你推荐这种类型下的其他内容。以电影推荐为例。比如你之前看过《盗梦空间》，则系统会关联数据库中盗梦空间的信息。系统会推荐克里斯托弗·诺兰导演的其他作品，比如《致命魔术》；系统会推荐主演里昂纳多的其他作品，比如《第十一小时》。如果这个电影系统的数据被很好地分类，那么推荐系统也会给用户推荐这个分类下的其他作品。盗梦空间如果被归为科幻作品，那么可能会推荐其他科幻作品，比如《星际迷航》。基于内容的推荐好处在于易于理解，但是坏处是推荐方式比较依赖于完整的内容知识库的建立。如果内容格式化比较差，那么基于内容的推荐就无法实行。同时如果用户留下的数据比较少，则推荐效果很差，因为无法扩展。3. 基于内容的协同过滤协同过滤（Collaborative Filtering）与传统的基于内容过滤直接分析内容进行推荐不同，协同过滤会分析系统已有数据，并结合用户表现的数据，对该指定用户对此信息的喜好程度预测。基于内容的协同过滤（item-based CF），通过用户对不同内容的评分来评测内容之间的相似性，基于内容之间的相似性做出推荐；最典型的例子是著名的“啤酒加尿布”，就是通过分析知道啤酒和尿布经常被美国爸爸们一起购买，于是在尿布边上推荐啤酒，增加了啤酒销量。需要计算用户u对物品j的兴趣，公式如下：p_{uj} =\\sum_{i\\in{ N \\left( u \\right) } }{w_{ji} r_{ui} } 这里 N \\left( u \\right)表示用户有关联的商品的集合，w_{ji} 表示物品j和i的相似度，r_{ui} 表示用户u对物品i的打分，示例如下：这里还有两个问题没有仔细描述，如何打分，如何计算相似度。打分的话需要根据业务计算，如果有打分系统最好，没有打分系统，则需要根据用户对这个物品的行为得到一个分数。计算相似度除了之前我们提到的余弦公式，还可以根据其他的业务数据。比如对于网易云音乐而言，两首歌越多的被加入两个歌单，可以认为两首歌越相似。对于亚马逊而言，两个商品越多的被同时购买，则认为两个商品相似。这里其实是需要根据产品的具体情况进行调整。4. 基于用户的协同过滤基于用户的协同过滤（user-based CF），通过用户对不同内容的行为，来评测用户之间的相似性，基于用户之间的相似性做出推荐。这部分推荐本质上是给相似的用户推荐其他用户喜欢的内容，一句话概括就是：和你类似的人还喜欢下列内容。需要计算用户u对物品i的兴趣，公式如下（可以和基于物品的协同过滤仔细对比）：p_{ui} =\\sum_{v\\in{ N \\left( i \\right) } }{w_{uv} r_{vi} } 这里 N \\left( i \\right)表示对物品i有过行为的用户集合，w_{uv} 使用用户u和用户v的相似度，r_{vi} 表示用户v对物品i的打分，示例如下：同样的，这里也没有介绍如何计算相似度，但是在上一篇文章我们给出了一个例子，计算相似度如果用到余弦公式，其实最主要的是选好维度。对于音乐而言，可能是每首歌都作为一个维度，对于电商而言，也可以是每个商品都是一个维度。当然，用一些可理解的用户标签作为维度也是可以的。5. 基于标签的推荐标签系统相对于之前的用户维度和产品维度的推荐，从结构上讲，其实更易于理解一些，也更容易直接干预结果一些。关于tag和分类，基本上是互联网有信息架构以来就有的经典设计结构。内容有标签，用户也会因为用户行为被打上标签。通过标签去关联内容。需要计算用户u对物品i的兴趣，公式如下（可以和基于物品的协同过滤仔细对比）：p_{ui} =\\sum_{k\\in{ N \\left(u, i \\right) } }{w_{uk} r_{ki} } 这里 N \\left( u,i \\right)表示用户u和物品i共有的标签，w_{uk} 使用用户u和标签k的关联度，r_{ki} 表示标签k和物品i的关联性分数，示例如下：标签查找的方法这里有很大可以发挥的空间，比如，通过知识库进行处理，或者语义分析处理。而对于一些设计之初就有标签概念的网站， 就比较容易，比如豆瓣和知乎。对于知乎而言，公共编辑的标签是天然的标签内容，对于知乎的用户而言，浏览回答关注等行为则是天然的用户标签素材。6.总结对于推荐而言，这几种基本的方法彼此之前都有些应用场景的差别：比如基于知识的推荐，这是比较老旧的推荐方法，但是对于系统和结构比较好的内容，则低成本且高效。比如基于内容的协同过滤，就适用于内容比较有限，但是用户数特别多的情况，比如电商公司。比如基于用户的协同过滤，则比较容易根据用户的兴趣点，发觉热点内容，比如新闻门户。对于基于标签的推荐，有标签系统的很占便宜，它在灵活性和可控制性上都好一些，但是做好很难。本期主要是介绍了常见推荐算法的基本原理，那么在推荐系统策略设计的时候，有哪些需要特别注意的地方呢？我们怎么衡量一个推荐系统的优劣呢？推荐系统有哪些典型的应用场景呢？欢迎关注专栏，继续阅读下期。------------------------------------【推荐系统那些事儿·三】推荐策略设计的Notes参考文献和推荐阅读：项亮《推荐系统实践》","updated":"T15:53:28.000Z","canComment":false,"commentPermission":"anyone","commentCount":15,"likeCount":56,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T23:53:28+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-b1e00a88_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":15,"likesCount":56},"":{"title":"【推荐系统那些事儿·三】推荐策略设计的Notes","author":"pan-yiming-61","content":"推荐算法的基本原理表述起来比较简单，但是具体实施起来还是比较复杂。没有任何一个标准的推荐系统，可以适用全部的情形，在真正实现的过程中，需要对算法有融汇贯通的掌握，以及对业务本身有深刻的理解。本章会介绍一些碎片化的推荐系统notes。1. 要解决哪些bad case?这个问题是推荐系统被设计出来的根本，产品遇到了哪些bad case,无法通过现有的机制实现，而一定要通过推荐系统才能解决?以传统门户而言，之所以用推荐系统，是因为随着受众的增多，受众对于新闻的偏好越来越多样化，而针对全体人的推荐系统并不能满足所有人的需求。编辑默认只会推荐绝大多数人喜欢的内容，国内的情况就是“强奸新闻”和“奇闻异兽”，但是这显然不满足高端用户的需求。相反会降低门户产品的调性，造成高端用户的流失。推荐系统就可以根据不同人的需求推送不同的内容，解决这个问题。这里的要解决的case如下：如何让互联网新闻偏好者的首页主要是互联网新闻而非大众新闻。如果让女性用户首页不出现大量男权色彩重的新闻，比如“强奸新闻”。只有明确了bad case，才知道了解决问题的方向。2. 设计怎样的合理路径？推荐系统最终形态是基于机器学习的推荐系统，那么如果设计一个一个月就上线的推荐系统，怎样既保证有效性，同时也又保证最后的合理演化?举个例子，如果最终路径是无人驾驶电动车代步。有两种演化方案：方案一：电动滑板&&电动自行车&&电动摩托车&&无人驾驶电动车方案二：汽油动力汽车&&混合动力汽车&&电动汽车&&无人驾驶电动车方案一看似不断演进，其实每一次都是很大成本的重构。而第二个方案，则能看到清晰的技术演化路线，驾驶动力在演化，最终是无人驾驶系统的上线，而大的架构没有修改。我一直觉得一个产品经理的能力很大程度体现在架构思维和中间版本的设计。具体到推荐系统的设计，短期内要看到效果，一开始直接上CF，是不明智的，一开始直接上基于语义分析的推荐方法也是不明智的。而如果是利用现有内容信息进行人工干预的聚类，利用这个内容聚类去实现用户聚类，则更加明智一些。后续转为自动化聚类也更加合理。3.可调整性推荐系统最需要考虑的问题是，如果出现了问题，怎么可以快速调整来满足需求？措施无外乎三种：提权，降权，屏蔽。这里就要求，权重是否能够快速调整？召回策略是否能够快速调整？只有系统级别支持粒度较细的权重调整策略，以及灵活的召回策略，才能够保证策略的快速调整，保证推荐系统的可持续迭代。这也是不建议直接上线CF或者机器学习的原因，因为CF和机器学习等策略，一开始可调整性比较差，前期无法快递迭代，可能对于项目而言，就是死刑。4. 离线评估、 灰度上线和用户反馈离线评估是指在发布之前，需要去检验典型的bad case 是否解决。是否达成一开始的目标，如果没有，则需要继续调整对应算法，直到能够明显解决问题。灰度上线则也是稳妥的措施。一开始推荐系统一定是充满了各种问题，所以为了解决这个问题，刚开始上线一定不能直接全量上线。正确的做法是，灰度上线一段时间期间，快速的根据用户反馈迭代算法，再考虑全量上线。用户反馈的方案包括但不限于：用户问卷，负反馈操作入口。典型的负反馈入口如下（今日头条）：5.说服别人的数据所有改进工作效率的系统，都会触碰别人的利益。这句话话值得读三遍。推荐系统正是这样。如果没有推荐系统，运营或者编辑能确定所有的位置应该摆放什么内容。有了推荐系统，原来10个人做的事情可以3个人能做完。那么这个部门裁谁？没有推荐系统，可能有一些特定KPI完成的余地，甚至可能有利益输送的空间，现在交给推荐系统，这个损失怎么办？另一方面，并不是所有人都有技术信仰，觉得推荐系统能比运营或编辑的经验判断会比推荐系统差，如果领导本身对推荐系统有怀疑，这也会是一大阻力。推荐系统最开始的目标并不是要大范围的上线，并且证明自己能替代编辑或者运营，而是要能够说服别人，推荐系统是可用的。这样才会减少阻力。最常见的做法是在运营或编辑不会干预的地方，上线推荐策略。因为这些地方上线推荐，业务数据是绝对的增量。或者如果在重要运营位上线，一定不要改变运营或者编辑最好的位置，而是在相对次要的位置增加推荐模块儿。而只有在这些位置不断迭代系统，效果足够好之后，达到能够说服别人的时候，再考虑进一步推进推荐系统的覆盖率。6. AB test 之前在讲搜索的时候，我也是在最后强调了AB test的重要性。推荐和搜索一样，本身极大依赖参数的配置。而这些参数的配置并没有通用的法则，同时也依赖各个平台自身具体的情况，只能在了解其原理的基础上，不断迭代摸索。在算法迭代的过程中，能够测试其效果是算法迭代的核心。只有能同时在线上部署多套搜索算法，并且监控其效果，推荐的迭代和改进才能展开。而这一切的基础，正是一个看不见的功能：AB test机制。7. 总结 本期总结了推荐系统实现过程中一些需要特别注意的地方。结束之前，讨论另一个问题，推荐系统的产品经理需要懂算法么？答案也很简单，一定要懂。如果不懂算法，就只能是做简单的评估并提出改进，很难有系统性的优化方案。懂算法也不是要知道具体怎么实现，而是要知道实现的原理，这样才能更好地把产品需求转为推荐策略，并且和算法工程师商量出解决方案。By the way最近手上的几个项目都到了比较紧张的时期，所以更新会慢一下，也正在考虑更新一些组织难度没那么高的内容。本专栏的关注者我大致看了下，产品经理居多。对于入行比较短的，应该比较关注怎么系统地提高自己，对于老司机，也会有给自己手下新人推荐书的需求。下一期我会给出一份新人产品经理书单，希望能在偷懒的同时，也解决一些大家的问题，欢迎关注专栏并阅读下期。------------------------------------下期预告：【番外·一】给新人产品经理的一份书单推荐阅读：项亮《推荐系统实践》猜你喜欢：","updated":"T08:36:08.000Z","canComment":false,"commentPermission":"anyone","commentCount":3,"likeCount":45,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T16:36:08+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-b1e00a88_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":3,"likesCount":45},"":{"title":"【番外·一】给新人产品经理的一份书单","author":"pan-yiming-61","content":"0. 前言：在互联网时代，产品经理行业是毕业生扎堆最严重的行业，可能没有之一。仔细琢磨想来主要是因为三点：第一无专业背景等硬性要求，第二很多人喝多了改变世界的毒鸡汤，第三互联网浪潮下总有那么一些泡沫。总结而言，入行很容易，说话有条理有逻辑，提前准备一些面经，看个几篇文章，就可能入行。但是后续的提升，则没有什么速成的办法。有经验的PM很多也是不断摸索出来的，要说怎么教别人，大部分也没什么想法。前段时间，公司来了实习生，想想怎么也得有个培养性的方案，最后就偷懒，列了一份书单。现在想再偷个懒，把书单发在专栏上，也算是好长时间没码字的一个交代。1. 书单概览：设定书单的时候，想到了大学的必修+选修的模式，也做了必读和选读的区分，设定了3个月时间阅读值超过20阅读分的要求，规则也说明了，如果有其他想看的书或者正在看的书，可以沟通抵消一些阅读分。基础（必读）【2】结网【2】淘宝十年产品事数据相关（至少读一本）【3】精通Web analytics 2.0——用户中心科学与在线统计艺术【3】精益数据分析架构（必读）【5】Web信息架构设计（至少读一本）【2】简约至上——交互式设计四策略【2】移动设计【3】设计心理学【5】交互设计精髓提高（选读）【4】数学之美【3】思考，快与慢【2】游戏改变世界2. 基础书籍结网在我看过的初阶对产品经理工作进行介绍的书中，这本书目前是我看到相对比较好的一本，浅显易懂，而且讲的东西也比较实在。产品的工作是什么，如何在公司内部进行沟通，应该有怎样的心态，怎么做基础的项目管理，怎么做基础的数据分析，怎么做好产品设计。这些书里都有介绍。作者王坚深入浅出的务实风格，也是互联网书籍里难能可贵的。如果只推荐一本书作为产品经理的入门书，我会推荐《结网》。淘宝十年产品事平心而论，如果只讲有用的东西，淘宝十年产品事能压缩到现有篇幅的1/5。推荐这本书的原因也是因为毕竟是给电商公司的初级产品的书单。对于电商的一些基础逻辑，结构，还是有简单的描述的。至少读完能够在一开始工作的时候，不至于显得太外行。而无用的4/5，就当小说看吧，虽然文笔一般，但是对于快速进入互联网公司的工作状态，还是有帮助的。3、数据相关书籍精通Web analytics 2.0——用户中心科学与在线统计艺术这是一本好书，即使是几年前的书，即使现在已经从PC时代到了移动时代，原理和逻辑还是可以使用，对于具体的工作还是有启发性。这本书对于完整建立数据思维能力是非常有帮助的。需要什么样的数据，怎样收集数据，怎么分析数据，分析完数据怎么汇报处理，都有比较详细的说明。可以作为第一本数据分析的入门书。精益数据分析对几大典型的商业模式的数据分析都做了比较详细的描述，有很多从真实案例中得到的总结。案例翔实，内核简单，但是对于扩展性的讨论也非常多，可以很好地培养数据思维方式。如果说对比的话，上一本书是描述怎么赢得一场战斗，这一本数则是在描述如何全局统筹赢得一场战争。4. 架构书籍Web信息架构架构性的书籍，基本上没有写给产品经理看的，但是作为一个产品经理，如果缺少架构思维，只考虑局部最优，后果可能就非常严重。怎么组织用户流程，怎么系统地设置导航，标签系统如何搭建，搜索系统如何搭建，如何做好分类，如何通过优秀的设计架构去创造价值，这些在书中都有非常详细的介绍。当然，阅读难度应该也是这个书单里面最大的。毕竟这本书不是写给产品经理的书，大部分做业务的工程师可能也不需要了解这些内容。5. 设计书籍前端设计是最容易被挑战和质疑的地方，因为毕竟是个人就能说两句自己的想法。如果在设计的时候没有自己的思路，或者缺少一些自己的思考，很容易沦为上级和工程师口中的傻逼PM，所以还是要读书的。简约至上——交互式设计四策略作者口中的交互设计四策略分别是：删除、组织、隐藏、转移。如果简化设计，如何进行功能组合分块，功能应该怎样有层次的展示给用户，如果把正确的功能放在正确的位置上。实例丰富，语言流畅。可以引发读者的一些思考。移动设计对于移动设计面面俱到，从移动端交互的特点，再到怎么做导航，怎么做交互，怎么做动效这些细节内容，最后落到如何写一份好的交互文档。这本书是腾讯团队出品的，缺点是，有很多二手资料来自前人的的书，但是从实用性来讲，还是一本比较全面的入门书。设计心理学设计心理学更多是设计思想上的讨论。作者作为学术泰斗，书籍在系统性上堪称一流，难能可贵的是在阅读难度上，也相对没那么高。总结了很多设计的原理和实例，已经是PM和交互必看的一本书了。如果说有什么问题，基本上犯了美国教材的通病，在实例上，比较啰嗦。交互设计精髓每一种编程语言都有一本写的很全，东西很多，拿起来很厚，但是公认很好的书，About Face对于交互而言，就是这样一本书，面面俱到，全面系统地讲述了交互设计过程、原理和方法。定期看总能有新的思考。和设计心理学一样的经典之作。市面上很多国内所谓大神的新书，核心观点很多都是《交互设计精髓》和《设计心理学》的简单组合。6. 提高性书籍很多好书和产品经理可能没有直接关系，但是对于产品经理的成长绝对是正向作用。这里列举了三本：数学之美吴军博士作为Google中文和日文搜索的主要设计者，权威性和影响力都比较高，这些年保持了长期的写作习惯，产出很高。数学之美之外，吴军博士的其他“AB之C”也都值得阅读。在阅读过程中，才发现大学时学的数学知识，比如马尔可夫链、矩阵计算，甚至余弦函数都如此有用。很多看似复杂的计算机系统都有其背后可理解的逻辑。也是这本书的指引下，我才开有了写这个专栏来的打算。思考，快与慢作者丹尼尔o卡尼曼是历史上最有影响力的心理学家之一，也是现今在世的最重要的心理学家。《思考，快与慢》属于准专业书，从专业的角度讲解了人思考的原理和一些误区，以及在真实世界中的一些表现。和机场读物不同的是，这本书的结论是基于严谨事实、通过科学方法推导出来的，不管和“常识”是否相符，都不由你不相信。而了解人性，也是设计重要依据。游戏改变世界游戏是否能改变世界，作者作为游戏从业者的观点是有待商榷的。但是书中对游戏设计的相关细节和思路却是十分详细。游戏化思维对于产品设计而言确是值得借鉴的，怎么让用户的使用情形更加接近心流的状态，更加浸入式地使用产品，相信这本书多少会有一些启发。7.总结一个产品经理入门应该读怎么的书，可能不同人有不同的观点，“汝之蜜糖，彼之砒霜”，这个书单也不是适用于所有新人。但是阅读确实是快速成长的一个途径。14年校招的时候，一开始疏于准备，被拒了一圈，总结发现自己的系统的表达能力可能还是有问题。然后开始大量阅读互联网相关书籍，希望有所提升。书单里很多也都是当时看的书。（下图是部分的读书笔记）回头再看，当时建立的读书习惯，对我个人的成长是非常关键的。也希望选出来的这些书，可以对各位有一些帮助。最近在出差在做一些算法设计的事情，刚好有研发同事问我在设计公式和参数的时候有哪些方法论的东西，我想了下，这些东西，确实可以在接下来的文章中系统总结下。欢迎关注专栏并阅读下期。------------------------------------下期预告：【产品策略公式·一】·神奇的对数","updated":"T07:51:26.000Z","canComment":false,"commentPermission":"anyone","commentCount":25,"likeCount":80,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T15:51:26+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-4a2ead94eeceb_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":25,"likesCount":80},"":{"title":"【产品策略公式·一】·神奇的对数","author":"pan-yiming-61","content":"产品策略公式中，如果加减乘除实在搞不定，那么你可以试着用一下对数。——前言1.生活中的对数作为一个数学渣，实在无力从对数的起源开始一番复杂的推导然后再得出结论。直接给出一个判断吧——需要用对数处理才能很好计算的数据，基本上都是符合长尾分布的数据。长尾分布的特点是，少数的item集中了大量的份额，但是在数值上，尾部的item的数值下降非常缓慢，不会直接下降为零。这么说可能有点苍白，那么举几个例子好了。人的收入，年收入1万~10万的人是大多数，年收入10万~100万的比较少，年收入大于1000万的更少，但是年收入大于1000万的人却占据了社会财富的大多数份额。电商中，店铺销量最高的店铺占据了GMV的大多数，商品头部爆款占据了GMV的大多数。知乎中，头部的大V占据了大多数的关注，高票答案占据了知乎大多数的赞同。自然界，对于地震的衡量是使用对数的，地震等级每相差2级，能量增加1000倍。人的感觉上的强度，大约和刺激强度的对数成正比。比如，我们感觉声音大了一倍，不是因为声源功率增加了一倍，而是声源功率增加了一个数量级。2.一个几乎万能公式其实在之前的文章中，不止一次出现过对数的使用。比如： 中，介绍了一个来自Reddit的核心排序算法，在兼顾了Feed流中头部都是热门数据的基础上，能够自动完成数据的更新。score\\left( H,T \\right) =logH+ \\frac{T-T_{0} }{A} 中，最终给出的用户搜索排序算法，既保证了用户之间的关注关系得到了尊重，也保证了用户的搜索相关度得到了尊重，同时也保证了粉丝数和赞同数能起到作用。score=\\frac{\\alpha \\cdot name+\\beta sign+\\gamma log(fans)+\\delta
log(like)}{\\sqrt{ \\alpha ^2+\\beta ^2+\\gamma ^2+\\delta ^2} } +\\epsilon follow这些例子其实都是下面这个几乎万能的公式的变形：score\\left( M, X\\right) =aX+lg\\left(M+1\\right)其中a代表根据需求需要调整的参数，M代表业务数据，M之所以要+1，一方面是历史的进程，另一方面也是为了保证lg\\left(M+1\\right)为正值。这个公式是为了平衡长尾分布的业务数据与有界的关键性数据之间的关系。这个公式之所以说万能，是因为大部分产品数据都可以分为长尾分布的业务数据，或者有界的关键数据。比如搜索就是典型的例子，长尾的业务数据就是销量或者点击量，有界的关键性数据就是文本相关度。3. 策略公式的应用接下来就是举例子的时刻了。场景一：假如淘宝店铺，年末要搞一个最佳店铺排行榜。这个时候肯定是要用到GMV（销售额），也需要用到DSR（detail seller rating，就是宝贝描述，服务态度，发货速度这些）。上面我们已经讨论了，淘宝的销量是数量差别是非常大的。大店铺每月销售额10亿的数量级，小的精品店10万销售额也不错。如果单纯用销量去排列，很多精品店无法挖掘，如果单纯用DSR排列，则不考虑GMV，这无法体现大店铺的优势。这个问题中，DSR是有界性关键指标，GMV为长尾分布的业务数据。那么排序公式可以是：score =a\\cdot DSR+lg\\left(GMV+1\\right)假如a取1：一个GMV为1亿，DSR为4分内的店铺A分数为11。一个GMV为1000万，DSR为3分的店铺B分数为10。另一个GMV为100万，DSR为4.5分的店铺C分数为10.5。A&C&B，比较起来就比较公平，一个店铺的命运当然要考虑自己的努力（DSR），但是也好考虑历史的进程（GMV）。场景二：知乎要搞一个知乎最佳贡献者排行这个时候既要考虑这一年收获了多少赞，也需要考虑这个人的答案质量，假如粗暴地认为答案质量度为（阅读+5*点赞+15*收藏）/曝光次数，如果只考虑质量度，笔耕不辍的人怎么办？如果只考虑收货赞的数量，那么一些长期抖机灵没营养的人可能会占便宜。这个问题中，质量度是有界性关键指标，点赞数为长尾分布的业务数据。那么排序公式可以是：score =a\\frac{\\left(read+5like+15collection+1\\right)} {view} +lg\\left( like \\right)假如a取1：一个用户A答案质量度为5，赞同数为1万，则得分为9。一个用户B答案质量度为3.5，赞同数为10万，则得分为8.5。用户A排名大于B。场景三：如何帮三毛找对象？荷西问三毛：你想嫁个什么样的人？三毛说：看的顺眼，千万富翁也嫁。看的不顺眼，亿万富翁也嫁。荷西就说：那说来说去你还是想嫁个有钱的。三毛看了荷西一眼说：也有例外的时候。“那你要是嫁给我呢？”荷西问道，三毛叹了口气说：要是你的话那只要够吃饭的钱就够了。“那你吃的多吗？”荷西问道。“不多不多，以后还可以少吃一点。”三毛小心的说道。在这个例子中主观评分的是否顺眼为关键性指标（假设为1~5），财富值为重要的业务指标。那么排序公式为：score =a\\cdot match+lg\\left(
wealth+1 \\right) 因为三毛非常看重是否match（顺眼），所以a我们假设为2，那么：千万富翁A，顺眼指数为4，则得分15，亿万富翁B，顺眼指数为2，则得分12，荷西没钱，顺眼指数为5，则得分为10。这个时候我们发现这个公式没有解决问题，荷西不是最高的。三毛会选择千万富翁。hmmm，这就是为什么我说这个公式是一个几乎万能的公式，而不是万能的公式。因为总有些异常的case需要进一步处理。如果算法改为：if（name=“荷西”）{score=100；} else{score =a\\cdot match+lg\\left(
wealth+1 \\right) ；}这个问题就迎刃而解了。4. 总结score\\left( M, X\\right) =aX+lg\\left(M+1\\right)确实是一个几乎万能的公式，但是M值怎么选取，X值怎么选取，参数怎么制定，就需要产品经理对业务有自己的思考了。业务理解力是前提，公式的灵活运用，都是在业务理解力的前提下才能发挥作用。理解公式是一个层次，灵活运用公式是一个层次，而在灵活运用公式的同时，再加上对业务的思考，则又是另一个层次了。本文在使用的案例的都是比较理想案例，在真实案例中，数据往往不能直接比较，而是设置不同的参数，那么有什么常见的阐述设置情形呢？又有什么常见的参数设置方法呢？欢迎关注专栏，收看下期。------------------------------------下期预告：【产品策略公式·二】·参数的调整相关阅读：","updated":"T07:29:29.000Z","canComment":false,"commentPermission":"anyone","commentCount":7,"likeCount":63,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T15:29:29+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-49fb3bc73f_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":7,"likesCount":63},"":{"title":"【番外·二】关于2016的思考:产品经理的进阶","author":"pan-yiming-61","content":"0. 前言2016年，是工作后第一个完整年。行业在变化，自己也在不断思考。时间退回到2016年初，那个时候最困扰的问题就是职业该如何进阶。不断做需求，不断改来改去，但是好像总是在原地打转。经过一年的时间，关于职业进阶这个问题，好像多少有了些答案。简单写一些碎片化的思考结果，算是2016的总结。1. 快速做出产品功能，是产品最基础且最无关紧要的一步很多公司都崇尚快速复制热点产品或者热点功能，但是最终大多以失败告终。即时通讯，社区是两个已经被复制烂了的产品模式，但是没有听说哪家通过快速复制产品功能做成即时通讯或者社区。说到底，比之找准定位和内容积累，产品的快速迭代是最简单而基础的一步。没有资源跟进的产品，也只是无用功。2. 科技新闻不可信，所有的数字都可以是为公关而拿出来的片面真相科技新闻某种程度上像新闻联播一样，所有的事业都在欣欣向上，每个被报道的公司都做着创意十足的事业，有着漂亮的业务数据。如果真的像科技新闻那样，我们生活的世界远远不够互联网公司们去颠覆，然而事实是并没有什么颠覆。为了公关，可以只强调成交量而掩饰退货率，为了公关，可以让人数变大数百倍甚至超过中国人口数。丑闻背后，是普遍的数据造假，却偏有人拿个别案例当规律。3. 交互和样式不能大幅度改变产品数据，如果能，那只能说明之前的设计太烂了产品经理入门书上总有一些通过按钮调整而大幅度提高产品数据的案例，但是时间长了之后我们发现，这些东西都是都是不太值得去纠结的地方。2016年，行业没有涌现出来新的APP，几乎所有功能，都可以在线上找到热门产品作为参照物，都可找到大量的用户已经熟悉的操作模式。基本不需要去做交互或者样式上的创新，做好产品调研，复用其他产品的交互和样式，反而可以降低用户的学习成本。相比于互联网早期，现在所谓的没用过互联网产品的小白用户越来越少，所有的APP在交互和样式上也不断趋同，这是互联网发展的必然结果。如果现在还存在交互和样式修改大幅度改变产品数据的情况，只能说明之前的设计太烂了。4. 纯做交互的产品经理将越来越缺少市场，而懂策略和数据的产品则会越来越被重视2016，超级APP功能越来越全，非超级APP的Dau都在下降，当失去增长红利之后，精细化迭代和精细化运营将成为必然选择。而精细化运营和精细化迭代需要的不是交互设计，而是在有限的时间内抓住用户的视线，在数据中发现服务的短板，而这对产品经理的策略能力和数据能力有很高的要求。5. 不能快速进阶的产品经理必将被淘汰初阶产品经理，就像咨询和金融行业中拉EXCEL、做行研的新人一样，数量巨大，薪资待遇在毕业生中算比较高的，上升的机会少。而如果不能快速进阶，最终将被淘汰。至少，2~3年工作经历的初阶产品经理，并不在大公司招聘的list中。毕竟新人能做的事情，肯定不需要用更高的工资去招一个几年经验的人去做。而事实也确实如此，大量的未能进阶的初阶产品经理也确实逃离北上广或者转行业了。6. 需要不断反思自己的工作，需要不断反思自己的成长不断反思自己的工作，自己做的工作除了帮助自己获得工资之外，是否能对自己的能力提升有帮助，对自己的个人成长有帮助。在不断前行的时候，也需要经常停下来向远处看一看，自己是否在正确的路上，这条道路是否真的能让自己不断成长。7. 阅读二手资料不算学习，学习应该是阅读教材类书籍二手资料包括但不限于知乎回答、知乎文章、公众号、一些没什么积累的人写的书、有一些积累的人东拉西扯写的书。学习教材必然是个痛苦的过程，二手资料的书几个小时可以看一本，但是教材是需要反复思考，一天也许只能啃下来一个章节，但确实只有这样的教材，才能真正让人进步。总想看个所谓干货抄近路，是典型的投机行为。8. 结尾2017年，暂时也没有什么太明确的计划，倒是有2016年留下来的旧账。有两本书都是只看到一半畏难停了，《JavaScript高级程序设计》、《具体数学》，希望2017年可以静下心看完这两本书。这个专栏也有将近一半的内容没有更新，希望2017年有时间可以更新完。除了还债的内容，还打算在2017年重新学一遍统计学，上学期间没学透，回头看还挺有用的。最后，也祝大家新的一年，有所进步，有所收获。","updated":"T11:11:24.000Z","canComment":false,"commentPermission":"anyone","commentCount":5,"likeCount":25,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T19:11:24+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-fecdea89ed3eb820d108_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":5,"likesCount":25},"":{"title":"【产品策略公式·二】·参数的调整","author":"pan-yiming-61","content":"0. 前言：超级APP功能越来越全，非超级APP的DAU都在下降，当失去增长红利之后，精细化迭代和精细化运营将成为必然选择。产品的工作的重点也需要从前端和交互的修改，转移到策略的制定。而产品策略在实现层，最终是以算法公式的形式输出的。一个成熟的策略系统，会涉及多种重要的因素。如何保证这些策略公式在复杂的运算中发挥自己应有的作用，如何保证不同的数值能在同一纬度计算，这就涉及很多参数调整的策略技巧。1. 调整参数的目的首先在调整参数的时候，前提是明确调整参数的目的。针对具体的目的，使用对应的工具，然后才能达成具体的目的。对调整参数的目的简单做了一些总结，具体如下：归一化处理调整因素的影响力信息论处理：热门降权和时间衰减降权调整变化曲线设定变化界限2. 归一化处理归一化处理，通过处理让不同因素在一个范围内进行比较。举个例子，如果要比较专栏的影响力，需要综合考虑阅读量、点赞量、发表文章量这三个因素，直接相加显然是不可行，因为阅读量数量是点赞数的至少10倍，而点赞数也是发表文章数的几十倍。要让不同因素在一个变化范围内，这个时候就需要对进行归一化处理。最简单粗暴的归一化方式，就是直接除以数据中的最大值，那么所有值都在0~1之间，并保留原有的变化性质。即：x_{i} '=\\frac{x_{i} }{x_{max} } 当然这样的处理方法也会有问题，比如受到极值影响比较大。而且如果大部分分值比极值低很大的数量级，则低分值将没有区分度，以阅读量为例，如果最大阅读量为十万+，而大部分专栏文章阅读量集中在500左右。这样直接除以极大值显然是不明智的。这个时候最好在处理前对数值进行调整。在之前的文章中提到的对数处理是个比较好用的方法.x_{i} '=\\frac{lg(x_{i}+1) }{lg(x_{max}+1) } 这样既保证了所有的数值在0~1之间，同时极值对最终分值的决定性影响也没那么大。3. 调整因素的影响力调整影响力的比较通用的办法有两种，加数值，乘以数值。加数值能解决冷启动遇到的新内容权重过低的问题，比如，如果知乎答案完全按照赞同排序，则新发布的知乎答案，一开始在下面，不利于被更多人看见，如果新发布的内容自带20个赞参与排序，则能解决这一问题。乘以数值能解决数值重要性的问题，如果希望某一因素在总排序中占据更重要的位置，则可以用乘法处理，比如，还是知乎内容排序的例子，如果完全按照赞同排序，要提高文章的排序权重，可以直接乘以某个系数。4. 信息论处理：热门降权、时间衰减降权、置信度提权一个信息出现概率越小，信息量越大，如果一个信息越常见，包含的信息越小。这个在之前文章中提到的一个基础观点。在实际的策略公式中，从信息论的角度去考虑就能快速的理解策略，让最终结果更加符合预期。热门降权以经典的图书推荐为例进行介绍。在图书推荐中买了的人还买了的策略中，有一个著名的哈利波特问题，因为哈利波特销量过高，几乎所有的图书都和它有关系。怎么处理呢？一个办法是用销量做流行度处理,降低流行度特别高的商品在排序中的得分。score'=\\frac{score}{lg(GMV+1)} 时间衰减降权，顾名思义，让过去的信息权重更低，最近的信息权重更高。行为具有连续性，最新的行为包含了更大的信息量。在处理的时候也可以使用上面的数学形式，让更远的时间分数衰减更大。score'=\\frac{score}{lg(T_{now} -t+1)} 置信度提权，是基于数据量越大信息越靠谱，在处理平均值，打分等的参数时候有比较好的应用。比如，在计算一个电影的排序的时候，在考虑多个因素中包含了电影观众打分，这儿时候应该是打分的人越多，电影打分的权重越高。score'=score\\cdot (lg(N+1))5.调整变化的曲线一般而言未经加工的数值在策略中很难直接应用，比如：知乎点赞/阅读的比率。好的文章高一些，差的文章低一些。变化范围特别小。希望整体数值变化范围不变的情况下，怎么加大区分度？这个时候可以用一些曲线的性质。开方是个例子，0.25变为0.5,0.01变为0.1，而1处理后还是1。score'=\\sqrt{score} 同样的如果分值都集中在很高的情况下，为了加大区分度，也可以用开方的逆运算。0.8处理后变为0.64,0.5处理后变为0.25，1处理后还是1。score'=score^{2} 6. 设定变化的界限防止一些极值产生对于计算的影响，设定变化界限也是常用的方法。比较暴力的做法是设定最大值，比如：当在阅读量计算中，阅读量数值大于10万，只取十万，防止大值的影响。还有一些比较柔性的做法，比如用有界函数进行处理：score'=\\frac{1}{a+b*e^{-score} }或者直接用之前文章中提到的对数也是不错的做法，会让大值影响减少。score'=lg\\left( score+1 \\right) 7. 总结本章讲的东西是一些通用的数值处理技巧，可能在脱离具体情形下，不是那么好理解，也比较枯燥。下一章主要会讨论一些关于公式和模型的思考方法。欢迎大家关注专栏，并收看下期。------------------------------------下期预告：【产品策略公式·三】·产品策略模型的方法论","updated":"T22:16:39.000Z","canComment":false,"commentPermission":"anyone","commentCount":7,"likeCount":23,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T06:16:39+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-49fb3bc73f_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":7,"likesCount":23},"":{"title":"【产品策略公式·三】产品策略模型的方法论","author":"pan-yiming-61","content":"0. 前言：对于大多数人而言，产品策略模型是个黑箱。有的人觉得它无所不能，有的人觉得它华而不实。偏见的产生，大多是因为不了解。之前的文章比较偏细节，这篇文章会从大的方面入手，说明我的产品策略模型的方法论，表达我对产品策略模型的理解。1. 模型没有高下，只有是否合适一个模型，大到一个系统，小到一个公式，都没有对错之分，只有能否满足产品预期。好的模型能够在有限的计算量内，达到产品情景的要求。而差的产品模型也许在纸面上很精确，但是无法满足产品情景的要求。模型就像是个工具，不能说锤子是错的，扫把是对的，只能说锤子在砸钉子的情形下是满足预期的，是好的工具。锤子在扫地的情形下是不满足预期的，是不好的工具。“推荐系统一定要用协同过滤或者机器学习”，“搜索系统一定带语义分析模糊匹配”，“排序系统 一定要用edgerank”，这些都是先入为主地为算法划定的高下，缺没有考虑是否真正符合要求。2. 信息量！信息量！信息量！对模型做一下简化，可以更方便的理解信息量的重要性：把一个模型看做一个黑箱，只有输入和输出两端。输入的信息经过分析计算，然后输出最后的分析结果。在模型分析能力相同的情况下，输入的信息量越大，分析结果效果越好。这样能承载的信息量，成了一个模型的关键因素。当然，处理的信息越多不见得效果越好，但是随着模型的发展，能处理更多信息的模型最终一定结果很好。3. 指标！指标！指标！算法迭代需要目标值。比如对于AlphaGo 而言，目标是获胜。对于搜索而言，目标是是准确率、召回率，或者人工评估的nDCG值。（详细说明可以看之前的专栏），对于一个算法而言，一定是有一个目标值的，而这个目标值需要在算法模型迭代的过程中，可以随着模型的变化而变化，确定迭代方向的是否正确。一个比较通用的方法是，对数据需要划出测试集，用来验证算法的效果。比如知乎推荐分析每个人数据预测出了用户为了会喜欢的内容，可以在第二天使用用户真实的行为数据和之前的预测进行对比，来确认效果。有了指标的算法系统，除了本身迭代的好处，更多的是可以让不明白算法原理的人，能够在黑箱上看到一个表盘，知道每次迭代，算法有多大的提升。这对于项目管理和推进有很大的好处。4. 置信区间和精度算法结果够用就行，片面强调计算的准确性是没有必要的。比如要计算一个数据精度本身在+-1范围波动的值，而理论计算得到一个1.8的值本身就够用了，如果画费更大的力气计算出1.834，其实就是无效的。算法也一样，要预测未来的销售或者需求变化这些本身波动比较大的数据，花大量的经历计算一个足够精确的值本身就没有太大意义，因为太精确就超过了值本身的置信区间。总结而言，精度一定要和置信区间匹配，否则就是浪费。5. 多因素的涌现，失控的参数控制好的算法，不会受到输入参数的扰动，而极大影响结果准确性；也不会因为数据中的极值，让结果面目全非。现实情况下，一些异常数据无法避免，参数扰动也无法避免。要考虑多个因素的系统，不能因为一个小问题引起所有结果的失效。其实和《失控》里讲的思想有点像，应该是多个因素组合后涌现出结果，这个结果不能依赖很多参数有一个非常精确的值才能起作用一个想要完全精确控制算法参数起作用的模型，很有可能就是调整了一个bad case，又引起了一堆别的bad case。6. 模型的边界，是人对业务的理解模型是万能的么？当然不是。一个模型不可能把全部的信息作为入参。人能够有效的干预结果，并且根据业务经验调整算法模型非常关键。模型在淘汰掉很多简单机械工作的同时，对人的工作提出了更好的要求。比如，淘宝在个性化推荐遍布全站之前，淘宝的页面需要大量的运营去填写补充布局，这部分工作目前已经完全被个性化推荐替代。而且效率更高。但是双十一怎么运营，什么营销测流，怎么更好的利用个性化推荐引擎，还是需要产品运营去思考。同时，在个性化推荐的结果中，也夹杂了大量人工的智慧。大量人工的标注和边界策略保证了个性化推荐引擎的有效性。人对业务的理解让模型能够发挥更大的作用，也正是人对业务的理解形成的外围策略，构成了模型的边界。7.总结产品策略模型的构建，本身是一个复杂且需要在实践中不断打磨进步的过程。很多时候一番计算得到的参数，不如二分法试出来的参数好。很多看似没有严格数学证明和依据的简单策略，却能起到好的作用。产品策略模型不是一块儿难以理解的黑箱子，但也不是短期内能通过几篇文章就能快速了解的。既不是万能的，也绝非华而不实。重要的是先想明白产品遇到了什么样的情境，需要使用产品策略模型来解决什么问题。如果还有什么需要再最后强调的，那么就是产品策略模型一定不是完美的，永远有问题，永远有进步的空间，永远需要去思考和完善。“若有完美，必有谎言。”这也是产品经理工作最有趣的部分。------------------------------------下期预告：【番外三】产品经理，本就该是工匠","updated":"T13:09:41.000Z","canComment":false,"commentPermission":"anyone","commentCount":3,"likeCount":21,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T21:09:41+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-49fb3bc73f_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":3,"likesCount":21},"":{"title":"【番外三】产品经理，本就该是工匠","author":"pan-yiming-61","content":"修理工的价值和工作稳定性就在于他有一手的知识和经验。——马修·克劳福德产品经理是什么？产品经理是什么？入行第三个年头，还是给不出一个确切的定义。当年以《人人都是产品经理》带很多人入坑的苏杰老师，已经去做产品经理培训了，而市面上产品经理的培训课程也卖的火热。甚至还有几个专门的产品经理干货平台，养活了一批人。产品经理培训，想来也和UI培训以及程序员培训一样，随便学点基础东西，东拼西凑一些别人的东西作为自己的作品，编一些项目经历，然后大量的时间学习面试套路就行了。干货平台来来去去也就是产品分析那些最基础的东西，一个聪明点的产品新人，跟完一个项目就能全部知道。每个有泡沫的行业，行业外围都有一大批专家，他们能说出做好一个事情的99个方法，但是却没有低下身子做好哪怕一件事情。对事情的看法，呈现明显的羊群效应，网红完了说直播，直播完了说自行车。在这样的大背景下，产品经理是什么？就显得更加难以回答。产品专家眼中的核心技能？懂需求分析？太多人抄竞品不动脑，漏掉关键细节和case，事倍功半。懂用户？需求开头充斥着，我觉得，老板觉得，运营觉得，太多的产品只是一个偏执且有偏的用户，却把自己的偏执当做了追求细节。懂技术？能把技术方案听明白就不错了。懂设计？大概更多是以不专业的眼光在戳设计师的屏幕。最后产品专家们拿出了杀手锏，懂沟通。对产品负责，推进产品发展。汇总而言，大部分产品专家和产品课程总结的东西，更像是玄学——一套高深的不可证伪的理论。一个可能的答案，工匠“修理工的价值和工作稳定性就在于他有一手的知识和经验，”来自《摩托车修理店的未来工作哲学》。也许产品经理的工作性质便是如此，更像一个在修理间的工匠。多种型号的摩托车进入修理间，工匠们凭借自己的经验和知识去找问题，根据客户的需求制定方案，在这里系统的热力学知识并不能直接帮他做出判断，修理间也只有有限的几种材料。但是每辆开进来的摩托车都需要被快速的修复。在这里能帮工匠的只有一手的知识和经验，以及快速的学习能力和应变能力。能不能帮运营把想法变成方案？能不能在画图之前先搞明白交互设计有那些基本规范，分析清楚竞品设计的思路？能不能在技术局限的时候，提出创造性方案解决问题？能不能把对产品策略的想法落实为工程师可解决的问题？能不能对数据有清晰的分析思路，提前准备？掌握热力学定律和欧姆定律等理论成为不了工匠，毕竟物理学家是不修车的。产品经理也应该远离所谓产品培训课程和产品专家的理论干货。多想想怎么做好事情，怎么达到目标。整天沉溺干货中，只是一种可以缓解焦虑的自我安慰行为。一个工匠如果非要看什么东西，花足够的时间看别人的工作笔记是个选择，或者系统学习领域知识和工具书。从小处着手，毕竟这个世界没有那么多短时间就能学会的东西。（说话有点直，大概是这两天看多元统计学积累了太多负能量吧）------------------------------------下期预告：【数据分析·一】数据分析经典三板斧","updated":"T12:36:17.000Z","canComment":false,"commentPermission":"anyone","commentCount":10,"likeCount":25,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T20:36:17+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-fefbddae64beee19a4b094_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":10,"likesCount":25},"":{"title":"【数据分析·一】数据分析经典三板斧","author":"pan-yiming-61","content":"0.前言一个产品，如果你不能衡量它，你就不能了解它，自然而然，你就无法改进它。数据说到底，就是这样一个工具——通过数据，我们可以衡量产品，可以了解产品，可以在数据驱动下改进产品。数据分析和数据处理本身是一个非常大的领域，这里主要总结一些我个人觉得比较基础且实用的部分，在日常产品工作中可以发挥比较大作用。本期主要讨论一些数据分析的三个常用方法：数据趋势分析数据对比分析数据细分分析1. 数据趋势分析趋势分析一般而言，适用于产品核心指标的长期跟踪，比如，点击率，GMV，活跃用户数等。做出简单的数据趋势图，并不算是趋势分析，趋势分析更多的是需要明确数据的变化，以及对变化原因进行分析。趋势分析，最好的产出是比值。在趋势分析的时候需要明确几个概念：环比，同比，定基比。环比是指，是本期统计数据与上期比较，例如2017年2月份与2017年1月份相比较，环比可以知道最近的变化趋势，但是会有些季节性差异。为了消除季节差异，于是有了同比的概念，例如2017年2月份和2016年2月份进行比较。定基比更好理解，就是和某个基点进行比较，比如2016年1月作为基点，定基比则为2017年2月和2016年1月进行比较。比如：2017年2月份某APP月活跃用户数我2000万，相比1月份，环比增加2%，相比去年2月份，同比增长20%。趋势分析另一个核心目的则是对趋势做出解释，对于趋势线中明显的拐点，发生了什么事情要给出合理的解释，无论是外部原因还是内部原因。2.数据对比分析数据的趋势变化独立的看，其实很多情况下并不能说明问题，比如如果一个企业盈利增长10%，我们并无法判断这个企业的好坏，如果这个企业所处行业的其他企业普遍为负增长，则5%很多，如果行业其他企业增长平均为50%，则这是一个很差的数据。对比分析，就是给孤立的数据一个合理的参考系，否则孤立的数据毫无意义。一般而言，对比的数据是数据的基本面，比如行业的情况，全站的情况等。有的时候，在产品迭代测试的时候，为了增加说服力，会人为的设置对比的基准。也就是A/B test。比较试验最关键的是A/B两组只保持单一变量，其他条件保持一致。比如测试首页改版的效果，就需要保持A/B两组用户质量保持相同，上线时间保持相同，来源渠道相同等。只有这样才能得到比较有说服力的数据。3.数据细分分析在得到一些初步结论的时候，需要进一步地细拆，因为在一些综合指标的使用过程中，会抹杀一些关键的数据细节，而指标本身的变化，也需要分析变化产生的原因。这里的细分一定要进行多维度的细拆。常见的拆分方法包括：分时：不同时间短数据是否有变化。分渠道：不同来源的流量或者产品是否有变化。分用户：新注册用户和老用户相比是否有差异，高等级用户和低等级用户相比是否有差异。分地区：不同地区的数据是否有变化。组成拆分：比如搜索由搜索词组成，可以拆分不同搜索词；店铺流量由不用店铺产生，可以分拆不同的店铺。细分分析是一个非常重要的手段，多问一些为什么，才是得到结论的关键，而一步一步拆分，就是在不断问为什么的过程。4.小结趋势，对比，细分，基本包含了数据分析最基础的部分。无论是数据核实，还是数据分析，都需要不断地找趋势，做对比，做细分，才能得到最终有效的结论。那么，怎么使用这些数据分析技巧，形成一个完整的数据分析报告？欢迎关注专栏，并收看下期。------------------------------------参考资料，书籍推荐：王彦平 吴盛峰《网站分析实战：如何以数据驱动决策，提升网站价值》Avinash Kaushik 《精通Web analytics 2.0：用户中心科学与在线统计艺术》------------------------------------下期预告：【数据分析·二】数据分析报告指南","updated":"T07:23:42.000Z","canComment":false,"commentPermission":"anyone","commentCount":1,"likeCount":27,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T15:23:42+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-dde4eedf244a0ae8430346_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":1,"likesCount":27},"":{"title":"【数据分析·二】数据分析报告指南","author":"pan-yiming-61","content":"1. 前言：一个项目到了汇总的时候，免不了形成一份相对完整的数据分析报告。报告也需要多种情况。按照应用场合可以划分多种类型：有的需要向上邮件汇报，有的需要给项目组里一个交代，有的是需要直接进行展示汇报等。按照项目类型也可以划分多种类型：新项目上线效果评估，AB test结果，日常数据汇总，活动数据分析等。文本也好，PPT也罢，数据分析报告核心的思路都是相通的。2. 你要一个故事我自己有个想法，就是产品经理应该多学习相关领域的知识，比如学一些基础的设计规范、交互原则、营销知识，心理学知识，算法知识等等。除了一些明显的对工作的帮助，也能帮助自己扩展思路。其实做好报告，就应向咨询机构或者投资机构学习。一个报告核心不是包含很多内容，让听众或者读者去花时间理解，核心是讲好一个简单的故事。咨询和投资机构做BP之前，会先花时间理清楚storyline。其实各种报告都应该这样，先理清楚你要讲的故事。3.一个数据分析报告的框架这里列出一个我个人比较喜欢的报告框架，可能针对不同的报告场景需要有所调整（比如删除部分步骤，或者增加部分细节）：项目背景：简述项目相关背景，为什么做，目的是什么项目进度：综述项目的整体进程，以及目前的情况名词解释：关键性指标定义是什么，为什么这么定义数据获取方法：如何取样，怎么获取到的数据，会有哪些问题数据概览：重要指标的趋势，变化情况，重要拐点成因解释数据拆分：根据需要拆分不同的维度，作为细节补充结论汇总：汇总之前数据分析的主要结论，作为概览后续改进：分析目前存在的问题，并给出解决改进防范致谢附件：详细数据4. 项目背景&项目进度项目背景，需要简述项目相关背景，为什么做，目的是什么。项目进度，需要综述项目的整体进程，以及目前的情况。这两点其实没什么可说的，如果对象是项目成员，可以写简单一些，如果对象是对项目不了解的人，则需要多写 一些，但还是要尽量用最简单的话，跟别人讲明白。5. 名词解释&数据获取方法名词解释：关键性指标定义是什么，为什么这么定义。这点是很多人忽略的，其实很多时候数据的误解都是因为对指标没有统一的定义。举例而言，点击率可以是点击次数/浏览次数，也可以是点击人数/浏览人数。人数可能按访问去重，也可能按天去重。如果没有清晰的解释，不同人理解不同，对整个数据的可读性就大打折扣。数据获取方法：如何取样，怎么获取到的数据，会有哪些问题。原始数据往往有一些缺憾，要经过数据清洗剔除噪声，也需要部分假设进行数据补全。数据清洗和数据补全的方法需要跟汇报对象说明并且获得认可，让对方对于置信度有一个估计。6. 数据概览&数据拆分数据概览，需要有重要指标的趋势，变化情况，重要拐点成因解释。数据拆分，需要根据需要拆分不同的维度，作为细节补充。这里基本上就是之前说的数据分析方法了。如果需要对方知道对比或者趋势，则使用图，如果需要对方知道具体数据，则使用表。表格对需要强调的数字要做明显标识。需要注意的点是：核心指标要少而关键，拆分指标要有意义且详细。同时如果是PPT的话，每页说明白一个结论或者解释清楚一个趋势足以。关键性结论要用一句话能说清楚。7. 结论汇总&后续改进结论汇总，基本是对之前数据分析阶段的数据进行汇总，形成完整的结论。后续改进，需要在数据分析的结论和问题的基础上，对后续的迭代和改进措施作出方向性的说明。这部分其实很多时候也是分析的根本目的。8. 致谢&附件致谢是对项目组合相关协助部门的致谢，基本上对于项目组和相关协助部门而言，也希望自己的工作或者积极配合能看到有效的数据结果。在之后的合作中，也会更加融洽。附件是需要附赠更多没有必要在数据报告中体现但是仍然有价值的数据。对于PPT而言，这部分也可以放在PPT致谢之后，与会同事有疑问，可以随时翻到最后解释。9.总结一个产品，如果你不能衡量它，你就不能了解它，自然而然，你就无法改进它。这是说数据。而数据报告的意义也是类似，项目完成之后需要完整汇报，这样无论是对上汇报还是对团队而言，都是有重要意义。突然想到一个事情。去年的时候做了一个内部数据平台，到了取名字的时候，我用了dice。为什么叫dice呢？这得从物理说起（开启神棍模式）。物理学不断前行，之前人们认为物理学是决定论的，只要知道系统的初始值和足够细节，就能知道之后系统的演化路径。后来发现不是这样的，对于一个基本粒子而言，观测之前，粒子状态和位置是不可预测的。爱因斯坦说“上帝不会掷骰子”，然后后续的研究，更多的是支持上帝是掷骰子的。这也是dice的来源。即使是上帝视角，也不可能知道提前知道数据的结果。那么作为产品经理而言，尊重数据结果，并分析形成结论，远比相信一些所谓的方法论的条条框框好得多。关于数据，能讲的还有很多，之后再开新坑。————————————————书籍推荐：王彦平 吴盛峰《网站分析实战：如何以数据驱动决策，提升网站价值》Avinash Kaushik 《精通Web analytics 2.0：用户中心科学与在线统计艺术》阿利斯泰尔·克罗尔 /
本杰明·尤科维奇 《精益数据分析》","updated":"T08:36:00.000Z","canComment":false,"commentPermission":"anyone","commentCount":5,"likeCount":24,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T16:36:00+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-dde4eedf244a0ae8430346_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":5,"likesCount":24},"":{"title":"触及用户的消息系统","author":"pan-yiming-61","content":"0.前言：在PC时代，产品没有便捷送达用户消息的途径，用户只有主动打开电脑登录了产品，才能看到产品推送而用户的消息。移动时代，随着智能机的普及，这一状态得到了根本的改变。本文汇总了目前比较通用的消息机制，并做了简要的介绍：1常用的消息推送机制说明根据消息推送机制的使用场景分为两大类，产品外部的消息推送机制，内部的消息推送机制。外部推送机制有：邮件短信微信内部推送机制有：桌面红点push消息中心打点推送2. 邮件邮件比较流行于PC时代的互联网产品，但目前也有应用。推送的前提是用户用邮箱注册，或者用户账号绑定了邮箱账号。邮件可以方便的打开PC邮件，查收邮件的情景比较倾向于完成重要的事情，所以对非紧要的营销类邮件容易忽略。同时因为长期的营销邮件滥用，目前邮件作为通知的效果也越来越差。但是对于卸载了APP的用户而言，邮件仍然是召回流失用户相对有效的手段。3. 短信营销短信相比邮件，有更好的实时性，同时也方便用户通过短信打开APP查看相关内容。但是短信一方面形式比较单一，另一方面也有着不菲的成本。短信的问题是在发送的时候必须时刻记住短信有成本这个问题，对于效果特别差的短信，如果不能优化则不如不发。同时短信也是很好的保存凭证，对于票据，快递取单号等，短信是比较好的形式。4. 微信如果能让用户关注对应的产品的公众号，则微信消息用户的打开率甚至可以高于短信，而且支持图片文字混合的形式，更容易提高点击率。缺点在于微信在消息推送的时候有诸多限制，当然，熟悉规则的人总是可以有很多突破的，比如看看拼多多满满都是套路的公众号。5. 桌面红点桌面红点是个对强迫症很有用的消息设计。机制也很简单，每条push发送达到手机的时候可以去更新桌面红点，APP在前台的时候，也可以去设置消息红点。一般而言，消息红点能提醒用户打开APP。但同时也需要注意桌面红点要让用户能方便的消除，如果不能，强迫症关掉桌面红点提醒也不是不可能。6. pushpush几乎可以说是移动端APP最核心的通知方式。最核心的指标是到达率和点击率。消息往往不是100%能够送达用户的。受限于厂商，目前Android全量消息到达率达到50%算是比较好的水平，这基本还是建立在Android保活联盟的基础上。点击率则跟消息类型和内容息息相关，也是大家优化的重点。7. 消息中心目前成熟的APP，一般都会有消息中心。消息中心承载了产品所有觉得对用户有用的新消息，也是用户打开APP的理由，或者打开APP首先需要查看的地方。消息中心最主要的目的是需要向产品的其他位置分发流量。同时也需要尽可能提高流量效率。减少无效消息对用户造成的干扰。8. 打点提醒有需要用户点击查看的内容，会从首页开始一路打点，直到用户点击查看之后，红点才消失。打点提醒在游戏中比较常见，因为游戏一般而言结构比较复杂，且更新比较频繁，各种活动和运营策略缤纷复杂。打点提醒是最能让用户快速使用的方式。9 推送的趋势目前推送主要有三个大的趋势：拟人化，自动化，个性化。拟人化：内容推送方更愿意露出人格化的特征，以此来拉动和用户的距离，而实际情况往往也能证明，拟人化是非常有效的方式。自动化：推送内容从人工选取内容推送，更多的是依靠产品策略或者自动化的算法执行，用最科学的方式推送给用户消息。个性化：个性化顾名思义，针对用户的个人特征进行推送。关于推送消息打开率基本规律是：全量推送&分渠道分组推送&个性化推送。不断挖掘用户个性化需求是互联网精耕细作时代的必然要求，不管什么领域。10 结尾消息系统的设计，处理在上述的一些基本框架，最重要的一条，则是克制。不为了点击率透支用户的信任，不为了转化率而放弃产品价值观。这种行为在长期看来绝对是有害的。希望每一条消息发送的时候，都有个基础的ROI评估。不仅仅是带来了多少点击，多少日活，而是消费了用户多少信任，造成了多少卸载，让多少用户关闭了消息提醒。当然，理想也只是理想。","updated":"T16:54:36.000Z","canComment":false,"commentPermission":"anyone","commentCount":2,"likeCount":11,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T00:54:36+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-aab2a18dbc3582aaf32fd_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":2,"likesCount":11},"":{"title":"产品经理必备：客户端架构基础知识","author":"pan-yiming-61","content":"前言：市面上关于产品经理的书，基本是都是入门书。之前我一直在想，为什么没有产品经理进阶的书籍。过了一段时间之后，我感觉有了答案：其实产品经理进阶的书早就有了，只是没有一个产品经理进阶的tag。这些书，可能是营销的书，可能是项目管理的书， 可能是心理学的书，可能是统计的书，可能是设计的书，可能是架构的书，可能是算法的书。总而言之，需要广泛的涉猎。当然，这些书里面也有优先级，不同的人，需要根据自己的工作需要，去调整自己的阅读的优先级。如果说的更直白一些：工作中，你最不想被谁骂傻逼，那就看对方领域的书。言归正传，这一章节会汇总一些客户端基础架构的知识，同时也会举个具体的设计实例。1. 客户端的架构客户端页面被访问的时候，一些非固定的元素，需要去请求API。客户端的数据可能来自各个业务线，API请求各个业务线的接口，并组织成APP需要的格式返回给API。对于业务线的服务端而言，它的数据也来自于基础数据库，也需要根据基础数据库的变化进行更新。2. 举个例子我的专栏在客户端页面的展现：最顶部：返回按钮，标题栏，操作按钮；头部：logo，专栏名称，专栏关注人数；底部：文字卡片流。而卡片流包括：头像，昵称，文章图片，文章标题，文章导语部分，文章赞同数量，文章评论数量，文章发布时间。可能请求了两个接口：第一个API接口，专栏基本信息的接口。第二个API接口，卡片流接口。在文章基本信息的API接口里，需要返回标题，logo，关注人数。而API会请求对应的服务接口，这个服务接口可能是个通用接口，有更多专栏的基础信息，比如有专栏拥有者的昵称和头像。而API则根据客户端的应用场景进行处理。在卡片流的API接口里，需要返回头像，昵称，文章图片，文章标题，文章导语部分，文章赞同数量，文章评论数量，文章发布时间。同样的，可能请求的接口中数据更多，而请求到的时间则是UNIX时间，需要处理成客户端需要的时间格式。同时，服务端的数据在基础数据有更新的时候也会根据一定规则进行更新。3. 基础设计实例：当我们了解了基础原理了之后，在做产品设计的时候就可以考虑的更长远一些：比如，扩展性。简单来说，对于客户端而言，尽可能不要做太多逻辑处理，而是只展示API给的数据。如下图，客户端只负责划定显示区域，不做任何文字的展现，这样对于扩展性更好。比如：如果想在展示赞、评论，时间的展示栏，需求调整，希望增加收藏数的显示，则这种显示逻辑下，直接在API增加收藏数的显示即可。而如果客户端处理为：X赞·X评论·X天前（赞，评论，天前为客户端写死），则修改时间格式或者增加收藏数的显示，就需要发版本。4. 结语：为什么要了解客户端的架构知识？除了尽量避免不被工程师骂傻逼之外，也是在设计之初就可以往长远考虑。很多时候熟悉业务的产品经理更能前瞻性的预测到功能的后续发展方向，可以提前做好前瞻性设计。可以和研发共同讨论，避免实现方式过于死板，后续的一些突发的运营功能扩展需要发版解决；也可以避免研发在缺少对需要发展了解的基础上，做出不必要的冗余设计来猜测未来的需求。最后要说的是，懂一些基础的技术知识，来避免被骂傻逼其实作用比较有限。毕竟程序员骂产品经理，大多数情况句式是：“这个傻逼又改需求”，而不是“这个傻逼一点技术都不懂”。","updated":"T15:03:42.000Z","canComment":false,"commentPermission":"anyone","commentCount":22,"likeCount":134,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"T23:03:42+08:00","links":{"comments":"/api/posts//comments"},"url":"/p/","titleImage":"/v2-20a8a8ad2e95bba82c1997_r.jpg","summary":"","href":"/api/posts/","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":22,"likesCount":134},"":{"title":"Android vs iOS—大多数PM忽视的几个交互细节","author":"pan-yiming-61","content":"相信大部分产品经理使用的都是iOS设备，对Android设备的交互总是很不习惯，所以在做设计的时候，有的时候就会忽略Android和iOS的设计差异，而执意按照自己的使用习惯进行设计。其实这个问题也是产品经理需要突破自己的地方，作为一个产品经理而不是用户，一定要客观地看待产品设计，而非主观臆想。从产品逻辑触发，而不是从“我觉得”出发，是产品经理进阶的第一步。本文就简单介绍了5个Android和iOS设计不同的地方，可以说大部分PM都可能会忽视这些细节。不是大盘点，只是作为思考的引子。1. 标题位置标题的位置是最基础的一个，Android靠左，iOS 居中。这个是最基础的一个交互差异，但是也不是每家公司都在遵守。正面的例子，微信和淘宝，在Android设备上做了靠左的设计。但是仍然有例外，比如下面的例子（也是大厂）：然而，即使是微信和淘宝都遵守着的Android的设计规范，还是被大部分Android厂商自身系统UI抛弃。这也是安卓UI比较尴尬的地方：一方面安卓设计规范一直在不断大改，一方面各个厂商“致敬”iOS风气浓重，这也间接导致很多设计师干脆照搬了iOS的交互。2. 右滑和长按Android 对列表操作栏的处理为长按，iOS为左滑。这个交互其实是大家比较熟悉的一个，目前比较成熟的产品基本也会遵守这个交互习惯，这已经属于不遵守就会让用户很别扭的细节。3. 消息开关设计对于iOS系统而言，push是否能够发到主要取决于系统级的开关，而对于Android系统而言，push到达设备主要取决于各家是否能够保活。所以对于iOS而言，消息开关需要强调系统级的开关，而对于Android则可以直接打开或者关闭。如微信的设计：当然对于微信这种大厂而言，不太需要在乎消息开关打开率，如果再进一步考虑消息开关的打开情况的话，则可以对于开关做进一步处理：打开消息情况不做直接关闭引导，关闭情况则引导用户打开设置。比如当时重构功能时候我给的方案：4. 多筛选交互对于地址选择，iOS一般使用系统交互的滚筒控件，但是部分Android APP也用这个交互，则是不对的。对于Android交互而言，一般是用列表选择代替滚筒的设计。对于这点，有问题的APP倒还有一些。我们还是看一下淘宝的选择地址时的设计（请忽略淘宝这个贴边的按钮设计）：5. 搜索框交互关于搜索框，也是有标准交互的。Android交互为：返回，搜索框，搜索按钮。iOS交互为：搜索框，取消。如下可见（京东）：当然，也有反面的例子（某新闻客户端）：为什么要这么做呢？其实也是iOS和Android的系统决定的。对于iOS而言，系统搜索框本就是这样设计，而且在搜索模式下，底部确认按钮可以变为搜索按钮，这符合iOS用户的习惯操作。而对于Android系统而言，底部没有搜索按钮，虽然回车是可以起到相同的作用，但是对于用户而言，顶部没有搜索按钮还是会造成误解。（如下：为搜索调起时候我