首页 / 21天打卡产品经理的日常思考
#

21天打卡产品经理的日常思考

#
5326次浏览 216人互动
此刻你想和大家分享什么
热门 最新
头像
#21天打卡产品经理的日常思考# 在互联网公司中,针对这类风险点的风控体系搭建通常分为两个阶段。第一个阶段是通过运营人员的经验,在业务系统内设定合适的规则策略,根据经验和现状不断调整阈值,同时增加人工审核人员,通过人力去判断遭受风险的状况和损失。这种策略制定的正确性在上线初期相当高,效果显著,但随着黑灰产不断地尝试,阈值地范围能够被测试出来,若最终采用一刀切的策略对社交平台而言是非常不利的,会出现大量的误杀情况。此外,还有一个隐患是大量的规则策略若始终存在业务系统内必然会出现业务系统反应延迟的情况。一般来说,公司所自研的风控引擎分为两个模块,在线同步模块和离线异步模块,如果对在线同步这块的风控规则进行了加强和优化,会导致整个业务接口的执行链路更长,最终带来TPS和QPS这两个关键指标下降,很多公司在每次碰上风险损失后都会配置不同的策略放在风控系统,互联网公司员工流动性又相对较大,前人配置的策略逐步累加,却没有后人进行删减,有的公司在进行风控自查的时候甚至发现了针对同一活动风险场景配置了2000条策略。策略、规则的堆积和风控引擎嵌入业务系统的方式,只会让性能急剧下降,除了不断买服务器这个方法,绝大多数公司会选择进入第二阶段。第二个阶段是通过前端用户设备维度的设备指纹识别用户操作环境,通过旁路设置的风控引擎和配置好的专家规则配合,这个阶段能大大减轻人力成本的付出,同时减轻业务系统的负担,在保持整体响应速度的前提下,减少性能的损耗。这种模式需要在用户端设置设备指纹,生成设备唯一标识,对用户的操作环境进行风险评分,识别用户操作环境是否存在多开、ROOT、HOOK、模拟器等,后端风控引擎根据前端设备指纹信息和专家策略规则在极短时间内完成策略的输出,处理风险点。此外,旁路设置的风控引擎能够和业务系统保持各自的独立性,在业务系统宕机时主动发起提醒,帮助运营及运维人员审查。
点赞 评论 收藏
转发
头像
9.18打卡 #21天打卡产品经理的日常思考# 产品经理完成业务流程图、产品原型图、产品需求文档后应组织项目相关人员参与需求评审会议确定最终需求,需求评审会议应以正式会议的形式开展。参与人员:项目组全体成员,技术开发负责人,产品部负责人(1)会议中,研发人员根据产品经理的描述发表疑义,产品经理进行解答;(2)对于产品设计过程中考虑不全面或存在更合理设计方式的点,产品经理需记录并在会后进行更改,更改完成后项目小组内部沟通确认需求。对于较大规模的变动,产品经理更改后需重新组织需求评审会议进行二次评审;(3)需求评审后,UI进行产品设计版本原型展示,确定产品整体外观样式,或提出更改意见,UI进行修改,修改后项目内部通过后方可使用此版本设计风格;(4)需求评审完成后,研发负责人会议对产品功能进行拆分,拆分后将各功能模块进行开发责任人划分,并评估工期。除此以外,产品与开发负责人应共同制定产品各个时间节点,包括:产品整体功能开发完成时间点,产品联调时间点,产品测试时间点(包括测试环境测试,预生产环境测试,生产环境测试),产品上线时间点。(5)产品需求评审通过后,项目小组成员需要签署需求确认书。需求评审其余具体内容:1、产品经理自己讲解产品原型图,详细阐述产品功能需求;2、需求讲解后,产品与开发人员共同确定产品数据库关键字段;3、研发人员需确定产品具体功能点的接口,并详细记录;
点赞 评论 收藏
转发
投递完美世界等公司10个岗位 产品经理的日常思考
点赞 评论 收藏
转发
头像
2020-10-31 15:21
产品经理
2020-10-31
在牛客打卡20天,今天也很努力鸭!
点赞 评论 收藏
转发
玩命加载中
牛客网
牛客企业服务