拍一拍自己的小桌面

#21天打卡产品经理的日常思考# 如果涉及的内容需要后台开发单独的内容，那么也要跟前台一样的逻辑，画出原型，写说明文档。并且在后台的说明文档中文案最好与前台一致，这样开发可以很清楚的知道后台上传的内容在前台对应的内容。如果文案不能保持统一，那么一定要单独在后台说明文档中，写清楚对应的前台展示。

#21天打卡产品经理的日常思考# 算法和计算公式一般是后端必要的。产品有时对后台数据库不是很熟悉，这是必须先熟悉，才能知道你想得到的结果是如何实现的。尤其对于新项目，所有人都不清楚数据有哪些，要如何计算这些数据才能得到想要的结果。这是产品就需要通过自己的验证方法来得到一个合适的计算公式，然后写在文档中，告知开发。计算公式有太多种方式，找到能得到自己目标的方式即可。

#21天打卡产品经理的日常思考# 在互联网公司中，针对这类风险点的风控体系搭建通常分为两个阶段。第一个阶段是通过运营人员的经验，在业务系统内设定合适的规则策略，根据经验和现状不断调整阈值，同时增加人工审核人员，通过人力去判断遭受风险的状况和损失。这种策略制定的正确性在上线初期相当高，效果显著，但随着黑灰产不断地尝试，阈值地范围能够被测试出来，若最终采用一刀切的策略对社交平台而言是非常不利的，会出现大量的误杀情况。此外，还有一个隐患是大量的规则策略若始终存在业务系统内必然会出现业务系统反应延迟的情况。一般来说，公司所自研的风控引擎分为两个模块，在线同步模块和离线异步模块，如果对在线同步这块的风控规则进行了加强和优化，会导致整个业务接口的执行链路更长，最终带来TPS和QPS这两个关键指标下降，很多公司在每次碰上风险损失后都会配置不同的策略放在风控系统，互联网公司员工流动性又相对较大，前人配置的策略逐步累加，却没有后人进行删减，有的公司在进行风控自查的时候甚至发现了针对同一活动风险场景配置了2000条策略。策略、规则的堆积和风控引擎嵌入业务系统的方式，只会让性能急剧下降，除了不断买服务器这个方法，绝大多数公司会选择进入第二阶段。第二个阶段是通过前端用户设备维度的设备指纹识别用户操作环境，通过旁路设置的风控引擎和配置好的专家规则配合，这个阶段能大大减轻人力成本的付出，同时减轻业务系统的负担，在保持整体响应速度的前提下，减少性能的损耗。这种模式需要在用户端设置设备指纹，生成设备唯一标识，对用户的操作环境进行风险评分，识别用户操作环境是否存在多开、ROOT、HOOK、模拟器等，后端风控引擎根据前端设备指纹信息和专家策略规则在极短时间内完成策略的输出，处理风险点。此外，旁路设置的风控引擎能够和业务系统保持各自的独立性，在业务系统宕机时主动发起提醒，帮助运营及运维人员审查。

#21天打卡产品经理的日常思考# 通常来说，在商业化变现阶段会遭遇的风险点根据商业化变现模式的不同有一定的差别。以最近特别热门的电商带货的模式为例，各个社区内所谓的达人对社区内用户和群体有一定的影响力，品牌方和社交平台以及平台内达人合作，通过达人输出广告和购买链接。和刷单一样，达人如果想获得更多平台方的补贴，会雇佣一些黑灰产刷单、刷量，在刷单之后退款或者转售，获取大量订单，以骗取平台和品牌方的补贴，这也是常见的商业化作弊方式之一。

#21天打卡产品经理的日常思考# 根据现阶段社交类APP的业务特性和预期实现的目标，需要社交APP的运营人员分产品阶段设置不同的活动形式，第一阶段需要通过各种具有吸引力的活动，例如一些注册有奖、邀请有奖等活动获得大量新注册用户，第二阶段是举办各种增加使用频次和使用时间类型的活动，类似于签到积分商城、APP内小游戏、登录一定时常给予奖励，培养用户使用APP的习惯。由于这些活动的特性，容易吸引到大批黑灰产。根据运营活动的不同阶段可以将黑灰产的攻击模式和攻击手段进行分类。第一阶段，这些黑灰产会通过一些技术手段模拟成真实用户，注册大量账号以获取新账户注册优惠。第二阶段，黑灰产在获得第一阶段的利益后通过养号生产大批量高价值账号活动，以机器化脚本的模式进行点赞、分享等活动，累计日活月活，获取活跃度奖励，或者直接对APP进行编译的方法破解积分商城，兑换奖品。最后一个阶段，黑灰产出售这些高价值账号以及大量通过撞库破解盗取的账号给一些店家，店家通过这些账号在平台发布广告，引导社交平台内部真实用户到其他平台购买产品，更有同业竞争者会通过账号买卖雇佣水军破坏平台内部的氛围，从而将竞对的用户群体吸引到自家。

#21天打卡产品经理的日常思考# 即时通讯社交产品，即时通讯类强调信息及时触达，微信、QQ在完成这一基础的条件上，完成了公众号、视频号、新闻资讯、UGC内容的传播，由于用户群体特有的社群属性，用户会自然地去进行内容地传播、分享，这而即时通讯平台只需要在用户应用场景下优化用户体验，减少用户参与信息传播的难度，鼓励社群内容运营人员进行创作，能大幅度的提高用户在即时通讯类APP的使用时间

#21天打卡产品经理的日常思考# Facebook的内容用了一个叫“边际排名算法”（Edge Rank Algorithm）。这个规则会计算每一个内容的重要性，重要性高则排在前面，而重要性E由三个因素决定，具体公式为——E = u*w*d:u：用户与内容发布者之间的亲密度分数，互动越多则关系分数越高w：不同的互动动作具有不同的权重，如评论、点赞等。比如评论动作的权重就会高于点赞。d：发布时间，发布越近的新消息重要性越高。很显然，Facebook会根据算法来计算哪个朋友对你而言更重要，点赞多评论多就是更重要，但这个算法也并不完美——比如我如果暗恋某个女生，我断然是不会给她点赞、评论的，但她的每一条朋友圈我一定要看。所以Facebook这种算法也剥夺了一种权力，我能看到什么不再由我决定，而由机器决定，我就失去了确定性，很多人会因此恐慌。

#21天打卡产品经理的日常思考# 微信一开始的逻辑是——人们发广告太多，就会有人把他删掉，而为了不被人删掉，人们会自动少发一些广告，多发一些有趣的内容，从而达到一个微妙的平衡！这个逻辑对吗？看起来没问题，但事实上并不凑效，微妙的平衡其实很难达到，为什么这么说呢？因为就连微信自己也发现依靠“删掉”这个如此重的功能根本起不到调节的作用，于是微信进行了自我改进——推出了“屏蔽某人朋友圈”这一功能。这时候逻辑变成——人们发太多广告，就会有人把他屏蔽掉，而为了不被人屏蔽掉，他会选择自动少发一些广告，多发一些有趣的内容。这回就完美了吗？答案是——不知道，我们只能说，效果肯定会比”删除“好一些，但屏蔽一个人这个操作真的就很轻么？且不说在操作层面我需要点5下才能屏蔽一个人，更重要的是从心理层面，屏蔽一个人意味着他发的一切我都看不到了，不到忍无可忍的某个临界点，很多人不会轻易这么做。那有木有更完美的解决方案呢？有人说有，系统自动算出这个人哪些是广告，哪些是有趣内容，只给人展示有趣内容而屏蔽广告！这个方案怎么样？看起来很完美，但有一个问题是，如果这个人的广告不会被看见，那他为什么要拼命发有趣内容呢？他闲的蛋疼么？所以，在产品层面其实没有完美的方案，有的只是不同的取舍。

#21天打卡产品经理的日常思考# 《失控——机器、社会与经济的新生物学》，这本书本质上是关于复杂科学的。书中一个非常核心的观点就是——从无机物到生物、从社会到机器都在向复杂方向进化，而在这个过程里，大多数时间是没有领导、没有组织、没有中心化布局的，这就是最自然的一个状态。《失控》本质上讲的并不是说失去控制，更准确地说是——无需控制，因此，很多人建议将这本书翻译成《无为》可能更加合适。

#21天打卡产品经理的日常思考# 外卖成为了 Uber 当下最亮眼的业务。根据 8 月中旬 Uber 发布的 2020 第二季度财报显示：Uber 的营收为 22.41 亿美元，与去年同期的 31.66 亿美元相比下降 29%。Uber 的主要营收来源于三方面：出行、外卖，以及货运；本季度，Uber 共享出行业务营收为 7.90 亿美元，与去年同期的 23.76 亿美元相比下降 67%；外卖业务营收为 12.11 亿美元，与去年同期的 5.95 亿美元相比增长 103%，如不计入汇率变动的影响，同比增长 110%。在 Uber 最大的市场，北美地区仍旧处于疫情不容忽视的时刻，人们尽量避免出行，因此 Uber 的出行业务还未恢复常态；相应地，居家隔离过程中极大催生了外卖需求，导致本季度 Uber 的「副业」反而超过主业，一举成为营收之最。虽然这个结果具备一定的偶然性，还不能下确定结论表示 Uber 已经是一家外卖公司。但是从 Uber 的发展道路来看，在网约车出行市场萎靡，自动驾驶商业化还有一定距离的时候，外卖业务的增长的确一定程度上提振了 Uber 的业绩表现。用 Uber CEO 达拉·科斯罗萨西（Dara Khosrowshahi）的话说：三年前我们的 UberEats 业务还刚起步，现在体量已经超过打车业务，我们用了三年时间，又在内部创建了第二个 Uber。

#21天打卡产品经理的日常思考# 周末，分享一些轻松点的。4种成功的产品经理：1、把产品经理做为谋生的手段，养活自己、承担责任，这是最基础的，也是社会对个人价值肯定。2、把握产品经理这个当红炸子鸡的岗位红利，让自己快速增值，这是更聪明、更有远见的方式。3、产品经理是自己的兴趣，兴趣和工作融为一体，绝对是命运宠儿。4、成为改变世界的产品经理，这需要天分和努力，也需要命运垂青。

#21天打卡产品经理的日常思考# Web产品是指在电脑上使用的各种产品。包括Web网页端产品、PC客户端产品(比如钉钉)、平台产品内第三方应用(比如钉钉)。这里咱们以“Web网页端产品”来顺着刚刚的逻辑，然后得到最终的原型尺寸。1.Web网页端产品，是放在浏览器这个容器里面的。2.原型尺寸可以采用浏览器的默认展示区域，此时接近于屏幕分辨率。3.为了保证自己的电脑可以查看完整的原型，所以我的Web产品原型尺寸需要小于我的电脑当前的分辨率1440*900px(可在电脑配置中进行调整)。4.为了保证项目的设计&开发&测试等童鞋可以查看完整的原型，所以我们需要考虑下他们的屏幕分辨率，比如有个1280*800px。5.当你的产品最终供所有用户查看，那么需要兼顾大部分用户的屏幕分辨率，通过查询当前电脑屏幕分辨率分布情况来查询出主流屏幕的最小宽度1280px。6.由于考虑到左右两侧可能还会放置广告位以及返回顶部等按钮，原型宽度最好小于1280px。综上所述，Web网页端产品的最佳原型尺寸可以采用宽度1200px，高度自适应。高度会根据页面内容多少而经常不同。对于首页等主要页面，PM最好考虑首屏内需要露出核心功能内容。此时还需要减掉菜单栏&标题栏&网址栏&书签栏等高度。

#21天打卡产品经理的日常思考# 原型尺寸，是指PM画产品原型的时候，页面该采用什么样的宽高px。即默认视图下的页面宽度是多少px，高度是多少px。由于我们的产品是在容器内部，所以容器的可展示区域(可以简单理解为webview容器大小)决定了我们产品的显示区域。1.默认状态下的可展示区域，就是PM经理需要遵循的原型尺寸。2.如果容器支持缩放大小，意味着需要考虑原型在不同大小展示区域下的布局效果。3.最大的展示区域，往往接近屏幕分辨率。4.最小的展示区域，往往是默认的原型尺寸。 部分产品可以缩放得更小，此时展示左上区域或者页面模块按一定规则缩小。