产品笔试后不会知识点总结
PGC(Professional Generate Content)即专业产生内容，具体就是指文字编辑人员撰写的内容。
UGC(User Generate Content)即用户产生的内容，通过筛选，从用户那里得到优质的内容。
OGC(Occupationally-generated Content,职业生产内容)通过具有一定知识和专业背景的行业人士生产内容,并领取相应报酬.
DAU(Daily Active User)日活跃用户数量。
曾经需要写产品相关的文档时总是不知道从哪里下手需要表达出什么，主要还是商业需求文档和市场需求文档，
根据情况，总结一下：
|
文档类型 |
需要做的工作 |
提纲如下 |
要达到的目标 |
|
BRD阶段 |
一、 市场分析； 二、 销售策略； 三、 盈利预测； 四、 （注：不出现产品细节） |
一、客户价值； 1、我要服务哪些客户？这些客户是什么样子的？ 二、商业价值； 1、我可以为企业创造什么样的价值？ 三、路线规划； 1、我先满足什么需求？再满足什么需求？为什么？ 四、历史回顾； 1、客户价值和商业价值是否发生了变化？ 五、成本估算； 1、整合各类资源所需要的运营成本、营销成本。 六、评估方法 1、为什么指定这个目标？这个目标是如何显现出来的？ |
向公司申请需要的费用、资源得到各级领导支持； |
|
MRD阶段 |
一、 更细致的市场与竞争对手分析； 二、 通过哪些功能来实现商业目的； 三、 功能/非功能需求分哪几块； 四、 功能的优先级； ——可能产出物有Mind Manager的思维图，Excel的Feature List |
一、产品介绍； 二、用户描述； 1. 用户/市场统计； 2. 用户剖析； 3. 关键用户需求； 4. 替代品和竞争品 三、产品轮廓； 1. 产品前景； 2. 产品定位 四、功能需求； 五、非功能需求； 六、 附件：用户需求调查报告 |
收集、分析、定义主要的用户需求和产品特性 ——不用考虑系统如何满足这些需求以及需求的技术和资源局限 |
|
PRD阶段 |
一、 功能使用的具体描述； 二、 Visio版功能点业务流程； 三、 界面的说明； 四、 Demo (注：可是dreamweaver、ps、画图板的简单版，有时也会有UI/UE支持) |
一、项目边界； 二、验收标准； 三、业务流程图； 四、用例说明； 1. 用例总图； 2. 单个用例说明 五、性能需求； 1. 响应时间； 2. 空间使用量等 六、维护性需求； 七、质量需求； 1. 安全性； 2. 可操作性； 3. 可靠性； 4. 兼容性； 5. 移植性 八、接口需求 外部接口需求； 内部接口需求 |
对MRD中的内容进行指标化和技术化；明确产品的功能和性能 |
|
FSD阶段（类似概要设计） |
产品UI确定; 业务逻辑的细节确定; 表结构设计 |
DMP(Data Management Platform)数据管理平台
7.0
Android 7.0Nougat（牛轧糖）：2016年8月22日 [10] [12]
Android Oreo （8.0）：2017 年 8 月 21 日
仓库流程分为入库，生产，出库，入库包括，收货组，复核组，上架组，理货组，订单问题处理组，退货组，还有个高值组和内配组，生产包括，拣货，复核，打包，出库包括分拣和发货。
SKU=Stock Keeping Unit（库存量单位）。即库存进出计量的基本单元，SKU是物理上不可分割的最小存货单元
RDC：分拨中心，用作物流运输节点上，汇集货物，然后按照合理的运力再次分配；
FDC：转运中心，二级仓库类似，用做暂存货物，用以拼整车、正线路发运；只是为了攒货用。
PCB是一块空的板子，在板子的表面什么东西都没有；而PCBA是在空的PCB上加工，安装电阻、电容、芯片等元器件，形成有一定功能的板子，所有电子产品的核心部分都是由PCBA组成的。
一般先有BRD，决定是否要开发一个新产品；其次是MRD，决策如何开发这个产品；最后是PRD，决定这个产品开发成什么样子。
软件开发中的完成测试环境所包括的环节包括：UT、IT、ST、UAT
IT = System Integration Test 集成测试
ST = System Test 系统测试
UAT = User Acceptance Test 用户接受测试(俗称:验收测试)
1.1 需求分析
测试从需求分析开始介入，测试人员参与需求的分析活动，确定测试的需求。需要了解测试需求及测试进度，即需要验证什么功能需求点，采用什么测试策略，描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、压力测试等）。详细阅读分析需求文档，进行逻辑梳理并勾勒出功能的大概流程图；与产品经理等相关人员探讨表述不清楚的地方，细化业务流程；考虑正常流程中的测试难点；考虑与其他功能的关联；考虑非正常流程；考虑版本数据兼容。
目标：
（1） 理解产品的设计意图和设计思路。
（2） 功能确认，充分理解个功能的细节。
（3） 根据功能的大小、复杂预估测试需要的工具、环境、时间
1.2 项目整体计划及评审
测试计划在需求分析完成后，程序修改完毕前准备。测试计划要描述测试活动的范围、方法、资源和进度。
目标：
（1） 为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。
（2） 为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。
（3） 开发有效的测试模型，能正确地验证正在开发的软件系统。
（4） 确定测试所需要的时间和资源，以保证其可获得性、有效性。
（5） 确立每个测试阶段测试完成以及测试成功的标准、要实现的目标。
（6） 识别出测试活动中各种风险，并消除可能存在的风险，降低由不可能消除的风险所带来的损失。
输入：
项目计划和测试需求
输出：
《项目测试计划》
《项目测试计划评审会议纪要》
1.3 测试用例设计及评审
内容：使用各种测试用例设计方法进行用例设计。测试用例的基本要素包括测试用例编号、测试标题、重要基本、测试输入、操作步骤、预期结果等。
测试用例文档是“活的”，测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。
目标：
（1） 使测试用例反映不同的场景、条件或经由产品的事件流
（2） 测试用例必须要能完整覆盖测试需求
输入：
测试计划
输出：
《项目测试用例》
《项目测试用例评审会议纪要》
1.4 测试执行
当测试用例编写完成通过评审后，并已提交的可测试的系统， 然后按照测试计划和测试用例搭建测试环境，开始测试执行。对修改的bug进行回归测试。
测试的具体步骤：
（1） 建立测试系统，搭建测试环境
（2） 准备测试材料、测试工具
（3） 执行测试
（4） 验证预期结果，测试不通过，反馈回给编码人员修改。代码修改重新提交后，返回2继续
（5） 记录缺陷
（6） 评估测试需求的覆盖率
（7） 分析缺陷
测试开始标准：
（1） 测试计划评审通过；
（2） 测试用例已编写完成，并已通过评审；
（3） 存在已提交的可测试的系统；
（4） 测试环境已搭建完毕。
测试退出标准：
（1） 测试用例全部通过；
（2） 存在的问题已得到合理的处理。
测试停止标准：
（1） 近半数以上测试用例无法执行；
（2） 测试环境与要求不符；
（3） 开发中需求频繁变动。
目标：
（1） 所有的测试用例都被执行，并每条用例至少被执行一遍。
（2） 存在的问题已得到合理的处理。
输入：
测试用例
测试环境
测试脚本
输出：
《测试执行记录》
《系统bug清单》
1.5 测试评估
测试报告是对测试过程和测试结果进行分析和评估，确认测试计划是否得到完整履行、测试覆盖率是否达到预定要求并最终在报告中给出测试和产品质量的评估结论。
输入：
《测试执行记录》
《系统bug清单》
输出：
《测试报告》
1.6 产品试用及客户培训
软件部署后，给客户提供产品试用，给客户做相关培训。
输出：
《用户手册》
《客户培训PPT》
2 软件测试阶段
软件V模型结构图如：
2.1 单元测试
主要是测试程序代码，为的是确保各单元模块被正常编译。有具体到模块的测试，也有具体到类、函数的测试等。——一般是由开发来完成
2.2 集成测试
单元测试后，将各单元组成完整的体系，测试软件单位之间的接口是否正确，数据能否正常传递。——比如注册和充值这两个功能能否连通
2.3 系统测试
把软件系统搭建起来，按照《软件规格说明书》中的要求对各项功能进行测试，看是否符合需求、在系统运行是否存在漏洞等——根据测试用例，进行完整的系统测试
系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。
2.4 验收测试
按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统——用户对软件进行验收
2.5 回归测试
回归测试是指重复以前的全部或部分的相同测试。新加入测试的模组，可能对其他模组产生副作用，故须进行某些程度的回归测试。
3 附录
3.1 测试文档清单
|
阶段 |
活动 |
产出物 |
模板 |
|
设计 |
系统设计 |
测试计划 |
|
|
测试计划评审会议纪要 |
无 |
||
|
开发 |
测试用例设计 |
测试用例 |
|
|
测试用例评审记录 |
无 |
||
|
需求跟踪表 |
无 |
||
|
测试 |
测试执行 |
测试用例执行记录 |
无 |
|
测试工作阶段报告 |
无 |
||
|
测试日报 |
|||
|
缺陷管理 |
缺陷bug清单 |
无 |
|
|
验收 |
系统验收 |
验收测试报告 |
|
|
系统发布 |
用户手册 |
无 |
3.2 缺陷管理流程
缺陷状态一般分为：新建、打开、已分配、已修复、关闭、重新打开
中间会有：延期、重复、拒绝等状态
缺陷管理流程：
3.3 缺陷等级划分
A类--严重错误，包括以下各种错误：
1、由于程序所引起的死机，非法退出
2、死循环
3、数据库发生死锁
4、因错误操作导致的程序中断
5、功能错误
6、与数据库链接错误
7、数据库通讯错误
B类--较严重错误，包括以下错误：
1、程序错误
2、程序接口错误
3、数据库的表、业务规则、缺省值未加完整性等约束条件
C类--一般性错误，包括以下各种错误：
1、操作界面错误(包括数据窗口内列名定义、含义是否一致)
2、打印内容、格式错误
3、简单的输入显示未放在前台进行控制
4、删除操作未给出提示
5、数据库表中有过多的空字段
D类--较小错误，包括以下各种错误：
1、界面不规范
2、辅助说明描述不清楚
3、输入输出不规范
4、长操作未给用户提示
5、提示窗口文字未采用行业术语
6、可输入区域和只读区域没有明显的区分标志
E类--测试建议
艾瑞APP指数提供海量数据实时查询
阿里指数是定位于”观市场”的数据分析平台,旨在为中小企业用户、业界媒体、市场研究人员,了解市场行情、查看热门行业、分析用户群体、研究产业基地等
腾讯移动分析|免费移动应用APP统计| H5统计|渠道统计|用户画像
Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of
角色
产品负责人 Product Owner： 负责维护产品订单的人，代表利益相关者的利益。
Scrum主管 Scrum Master： 为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。一般不翻译。
开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。
答案是需要思考的。但从概率角度来讲，传统方法论较为低了一些。
下面从最流行的方法论Scrum说起，一句话描述，就是3个角色、3个工件、做5个活动。（还有5个价值观，参考以上就好）
3个工具即得产品待办事项清单、迭代待办事项清单、可交付的产品增量。
5个活动即迭代执行、迭代计划会、每日站会、迭代评审会、迭代回顾会。
（这条是加戏，不在正式的Scrum方法论里面，各类实践都假设团队已成立）
备注：用户故事也分颗粒度大小，排序就是优先级越高的故事越具体。
迭代周期：根据交付要求进行评估后产出产品迭代周期，一般为15天-30天不等。周期太长不灵活。
目的：保证整体团队每天高频的沟通，了解每个任务的进展及大家进度情况。
整体团队每天花15分钟快速的勾兑昨天做了什么、今天准备做什么，需要什么问题。
每个人主动在To do（准备做）一栏中的选取今日要完成的任务放入Doing一栏并且开工，第二天立会继续按此勾兑，同时将已完成的任务放入Done（完成）一栏
备注：只有PO、SM、开发Team能发言，其他人旁观，有事儿单独聊。
评审会是邀请客户等利益攸关者一起针对本次迭代的成果进行评审（可交付的产品增量）。团队进行演示，PO来讲解整体产品情况。
回顾会是团队内部针对本次迭代内发生的各类做的好的、可以改进的、存在问题的输出改进项， 改进项作为单独的任务为下一轮迭代做输出，也就是持续改进。
SM需要确保开发Team不受外界干扰，作为敏捷教练更多的是确保会议执行、确保大家理解方法、遵循时间盒规则。
PO把控整体方向及对接外部需求，只有PO可调整产品待办列表优先级，另有权中途取消迭代。
开发Team负责任务的同时还需要遵循敏捷的核心方法，同时按需运用如持续集成、自动化测试、结对编程等组件级方法。
始终认为，敏捷只是达成目标所使用的方法，而Scrum、XP等诸多实践只是提供了一种验证过的可行的参考，而是否适用于本团队，以及团队里每个人具备的技能和方法认知，还需要管理者自行斟酌和思考。
永远不是为了敏捷而敏捷，而是为了更高效的交付更高质量的可用产品。通往罗马之路放眼望去遍布脚下，选择以及实践出最适合自己的为好。
以上为自我学习及结合实践的总结，如有不当之处还请指教，相互进步。最后也印证了一句话，适合自己的才是最胖的。
- 业务背景
- 产品功能概述
- 产品前景分析
- 产品功能整体流程
- 产品逻辑关系
- 面向对象
- 应用对象
- 名词解释
- 参考文档
业务背景描述：
这里，你必须将业务提出方描写出来，并且细致到业务方为什么将这个需求提出来！为什么？一方面，你要告诉研发人员，你为什么设计这个产品或功能，这个需求从来源到设计是有原因的。另一方面，拉上相关业务部门，你至少不是一个人在战斗。
产品功能描述：
对当前功能进行概述，所设计的产品或功能的功能模块，新增、完善、优化那些产品功能；
产品前景描述：
本产品或功能，希望对那些转化率指标或实现那些目的；
产品的整体流程：
Visio、Axure（Axure画的流程图好丑）。
通过而言，简单的需求将主业务流与逻辑关系流表达出来便可以；但涉及复杂的业务，便将产品或功能涉及的主要流程绘制出来；而流程目的，主要是清晰的将前后台的逻辑关系与数据结构表达出来；一方面方便开发理解业务与数据流，另一方面也方便产品人员梳理自身需求的业务逻辑；利于后续与研发进行沟通。
具体的流程数量，根据业务的复杂程度决定，一般只需要将核心的流程绘制出来便可；
前台：主要是交互、数据流程；
后台：主要是业务逻辑判断、数据流；
前后台的流程凑在一起，能清晰的看到前后台的模块之间，是如何进行耦合的，数据储存、提取、处理、分析。
功能框架：
Mindjet Minmanager、Xmind画的框架图好丑。
框架图的意义在于，能让查看或了解业务的人，全方位的了解功能之间的功能点的逻辑关系。同时，一份优秀的框架图，能让PM站在全局的基本面上，对个人所负责的产品进行全局的规划，对前后台的功能进行把握，达到支撑平台业务。
产品架构：
对前后台的各个系统与管理模块的逻辑关系，一般是对业务极其熟悉的业务构架师与资深的产品总监搭建，里面涉及每个接口如何进行对接耦合。
功能架构：
所负责的产品或功能的前后台功能的逻辑关系，简单点的就是一个产品或功能的前后台，大一点就是一个系统涉及的功能点之间的耦合。
功能框架：
功能点所涉及的逻辑关系。
功能结构：
功能点所涉及的逻辑关系。
而“架构、框架、结构”区分在于，所负责的业务究竟有多大。但不论如何，它们的表现的原理是一致的。将分解的功能点，之间是如何联系的功能结构关系清晰、简练的表达即可。
关于架构，包含“功能分解、面向用户”就够用了。若再深入，可将分为：“应用对象、BI分析（BI需求也写上去）、系统集成….”。后续可根据BI数据，对产品进行版本迭代与优化。
面向对象
表达产品或功能主要是为那类用户服务的。将面向用户是谁，拥有哪些权限清晰的表达出来即可，对个人进行功能设计也有很大的帮助。
应用对象
本功能需要在那些应用端或版本进行上线，清晰的描绘出来，方便后续进行业务交接。
名词解释
将本次文档涉及一些奇葩的明词进行解释，这点很重要！有些PM喜欢将一些非常简单的内容包装成非常牛逼，让人看起来很难懂，而事实上也就做哪些一件简单事，但是看的人会很痛苦：看PRD时会想：“这玩意，究竟想表达什么。
参考文档
将所做的本次功能，所参考的那些文档，附属上来；目的的在于，方便后续的业务方、研发方进行查看。
三、功能描述功能描述能否描写清晰，描写清晰，开发找茬都不怕了。如何才能完整的对功能点进行描述呢？围绕三个点“功能是谁？功能来自哪里？功能要到哪里去？
同时，功能需求主要分为核心功能、其它功能。不论是核心功能还是其它功能，都可以由以下元素构成：
功能名称
面向用户
用例图（Axure、mocking（适合移动端进行敏捷性开发）)
前置条件
后置条件
功能简述
详情描述
而具体的功能描述内容，则根据业务（功能点）的复杂程度，进行筛选描写。可以全写，也可以不全写。但务必记住：不论何种方式，目的在于将业务价值完整、清晰、有条理的传递给查看文档的参与角色。
功能名称
（我是谁）
本功能在系统里的命名。
面向用户
本功能的使用对象。（在前台，功能的参与者是少数的；但后台与企业级应用里，功能的参与者是多个的）
用例图
表达功能在表现层的逻辑图；可以是传统意义上的用例图，或者是简化版的原型图、流程图；
前置条件
（我来自哪里）
使用该功能的前提、逻辑关系说明；公司大了后，每个开发都只写个人所负责的业务，所以一定要将每个模块来源都清清楚楚的表达出来，方便开发之间的衔接。
后置条件
（我要到那里去）
使用该功能后，对业务、数据功能，产生的影响与结果；
功能简述
描写本功能需要实现的商业价值或目的；
详情描述
将功能”我怎么来，我怎么去“清清楚楚的表达出来。变成计算机逻辑便是，页面布局、操作逻辑进行详细的说明。常规而言：
前台：
主要是字段、交互逻辑组成；
后台：
主要是判断逻辑、列表表单、查询条件、交互逻辑组成；
四、其它功能其它功能目的在于，功能描述针对于本次产品功能的核心业务，而其它功能针对于触发或需要其它功能变动的业务。功能描述清晰的让开发了解核心，而其它功能便让开发清晰的了解非核心。
而其它功能，主要由以下内容组成
其他接口
对其它系统产生“字段、业务流程”进行说明；本次产品或业务，对前后台那些非主流程模块产生影响；
系统风险评估
当前设计的功能存在哪些缺陷、注意事项与后期的功能拓展如何解决这些问题；
其它需求
对一些非核心的功能点进行详情描述。如：一些需过滤的关键字、新增某个栏目字段。
五、综述通过上述内容，能以通用版的形式，清晰的将所负责产品与功能表达出来，而业务描述、功能描述、其它功能。是产品需求文档重要的组成部份，将产品需求较为全面、有效的描述出来。
同时，能训练PM逻辑思维，提升文字表达能力、业务理解能力，从整体上让PM在需求管理上，明显更加专业，所负责功能的逻辑关系、数据流的来与去都能很好的把控。
六、附语不论是什么格式，倒爷坚持一个观点，适合团队才是好的模板。当前很多的公司在进行MVP迭代的时候会使用Axure 内容描述的形式。虽然，这种形式，是很难将逻辑关系表达清晰，同时会有非常多的思维漏洞。在进行文档归档时，也很难对根据关键字进行检索。但，确实挺适合进行MVP迭代，出现问题修改起来也方便，这种方式比较适合项目流程完善的企业平台使用。
而在敏捷性开发汇总，倒爷习惯流程图 功能框架（功能点） Axure（原型图绘制），从核心的业务流开始，逐渐迭代至功能完善，这个过程也将文档补齐。
但有些公司会在EXCEL里进行需求文档撰写，进行版本管理（这个也不错）。
但，作为新人，需要记住：你能写复杂的东西，简单的东西也能能写；但当然一开始只写简单的东西，那你一辈子只能做简单的东西。
大道至简，简难而繁易；经历过复杂的训练与要求，才能简化再简化。
产品需求文档是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然，这个定义针对的是一个全新的产品。广义上来讲，产品需求的描述，应该包含有产品的战略和战术，战略是指：产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等 PRD的主要使用对象有：开发、测试、项目经理、交互设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前，必须要通过评审确定的最重要文档。
OKR是Objective & Key Results的缩写。中文意思是目标与关键结果。
OKR是在一定周期内为企业和团队设定的战略和目标。在每一个周期结束的时候，OKR能够帮你评估团队目标的执行和完成情况。
高绩效的OKR系统一般有3个共同点：
- 目标和结果可以被量化。
- 个人或者团队的OKR必须在每一天、每一周、每一个月都有露脸的机会。说白了就是持续性，OKR的使用者必须时刻将目标和结果铭记于心，这样才会时刻将自己的行动与之匹配
- 目标要设置的有野心，最好超出能力范围。一个百分百被完成的OKR几乎没有任何推动作用，而一个70%完成度的OKR却近乎完美——它能让你知道你这一阶段你和你的团队的极限在哪里，这样你才有更多的上升空间
—-广告指标—-
不同时期产品的宣传必要要选择合适的投放媒体和渠道，这就需要我们了解基本的广告相关数据指标。
CPM
cost per impression，按千次展示付费，指通过某一媒体投放广告，听到或看到此广告的人达到一千人平均所要花费的广告费用。
CPM=（广告费用/到达人数）×1000，比如投入广告费用200元，有10000人浏览过此广告，则CPM=（200/10000）×1000=20元
CPM取决于产品的印象，不是评价广告效果的单一指标，是对不同媒体进行衡量而制定的一个相对指标，通过比较不同渠道的广告收入找出效果最好的渠道。
CPA
cost per action，按行为付费，通过广告使用户产生一定行为而计费，不限广告投放量。对于用户行为的定义依产品而定，包括形成一次交易、获得一个注册用户、下载一次软件，或是填写一次有效问卷等，这些统称为用户行为转化。
CPA=广告费用/有效转化次数
转化次数的统计较为困难，另外由于广告被点击后会触发用户的后续行为（如注册或消费行为），在网站中不大受欢迎。
CPC
cost per click，按点击量付费，对某一广告点击所产生的广告费用，统计点击量可以设定一定标准，比如对于同一个IP，在一个时间段内重复点击，统计为一次，也可忽略IP的限制，直接统计总点击量。
CPC=广告费用/点击量
CPC为网络广告投放效果的重要参考数据，但也有其缺陷，比如虽然用户没有点击广告，但他已经看到了广告。
CPS
cost per sales，按销售付费，按照广告点击之后产生的实际销售笔数来计算广告费用，
CPS=广告费用/有效销售量
适合购物类、导购类、网址导航类网站，需要精准的流量才能带来转化。
CPT
cost per try，按试用次数付费，主要是移动应用渠道营销平台以试玩或试用为付费标准。
CPT=广告费用/有效试用次数
这种方式的特点是按用户使用时长或使用周期计费，可以从根本上杜绝刷流量，是最真实有效快捷的营销方式之一。
—-网页指标—-
PV
page view，即页面浏览量，用户每1次对网站中的每个网页访问均被记录1次。用户对同一页面的多次访问，访问量累计。在一定统计周期内用户每次刷新网页一次也被计算一次。
可通过后台运营获得数据；也可通过相关统计工具获得，如Alexa、百度统计、Google Analysis等。日均 IP/PV 访问量约为 600/2400的意思是今天访问首页次数为2400次，访问IP为600个，也就是说这600个IP一共访问网站2400次。
一般来说PV与来访者数量成正比，但是PV并不直接决定页面的真实来访者数量，例如，同一个来访者通过不断的刷新页面，也可以制造出非常高的PV。
UV
unique visitor，即独立访客，访问网站的一台电脑客户端为一个访客。
00:00-24:00内相同的客户端只被计算一次。
使用独立用户作为统计量，可以更加准确的了解单位时间内实际上有多少个访问者来到了相应的页面。
PR
pagerank，即网页的级别
安装Google Analytics等统计工具
一个PR值为1的网站表明这个网站不太具有流行度，而PR值为7到10则表明这个网站非常受欢迎(或者说极其重要)。
跳出率
指用户到达你的网站上并在你的网站上仅浏览了一个页面就离开的访问次数与所有访问次数的百分比。这里的访问次数其实就是指PV。
浏览单页即退出的次数/访问次数。比如，在一个统计时间内，一个网站有1000个不同访客从某一链接进入，并且其中有50个人没有二次浏览行为，是直接退出网站的，则针对这个链接的网站跳出率为50/1000=5%。然而有些退出的行为不能作为退出考虑，比如页面上刻意添加的导出链接，如合作伙伴的网站等，还有联系我们，付款页面等，都不算是负面的跳出，所以要根据不同情况统计有效的数据才能得出可靠的跳出率。
是评价一个网站性能的重要指标，跳出率高，说明网站用户体验做得不好，用户进去就跳出去了，网站没有满足用户的期望与需求或是人群定位不精准，反之如果跳出率较低，说明网站用户体验做得不错，用户能够找到自己需要的内容。而且以后他可能还会再来光顾你的网站，提高了用户粘性。慢慢的可以积累大量的网站用户。
退出率
对某一个特定的页面而言，从这个页面离开网站的访问数占所有浏览到这个页面的访问数的百分比。
从该页退出的的页面访问数/进入该页的页面访问数，可采用访问统计工具如Google Analytics进行统计
从某方面反映了网站对于访客的吸引力，如果退出百分比很高，说明访客仅浏览少量的页面便离开了，因此当你的网站退出百分比很高的时候就要想办法改善你网站的内容来吸引访客了。
跳出率与退出率
跳出率适用于访问的着陆页 （即用户访问的第一个页面），而退出率则适用于任何访问退出的页面（用户访问过程中在你的网站上访问的最后一个页面 ）。退出率是对于特定的页面来说的，对于网站整体来说并无意义，因为来到网站的访问必然最终都会离开网站，对于网站整体来说其退出率必然是100%。而跳出率则可以适用于着陆页面，也可适用于网站整体。
跳出率只能衡量该页做为着陆页面的访问， 跳出率分母等于Landing Page的visits ，分子也是指跳出的visits。
退出率则是针对全部的访问页面不限于着陆页面（Landing Page），任何页面都有退出率。
退出率的分子=退出的次数（包括一次访问过程中用户浏览单页即跳出的次数，也包括浏览多页后从该页面退出的次数。）
平均访问时长
指在一定统计时间内，浏览网站的一个页面或整个网站时用户所逗留的总时间与该页面或整个网站的访问次数的比。
访问总时长/访问次数，如一个网站在一定时间内总的逗留时间为1000秒，在这段时间内，总的访问次数是100次，那么这个页面或网站的平均访问时长就是1000秒/100 = 10秒。
是体现被统计对象的用户黏性的重要指标之一，进而可以评估网站的用户体验，指导改善页面。平均访问时长越短，说明网站对用户的吸引力越差，可用的有用信息越少，也说明网站需要优化或都添加有用信息了。
转化率
指在一个统计周期内，完成转化行为的次数占推广信息总点击次数的比率。
转化率=（转化次数/点击量）×100%。
以用户登录为例，如果每100次访问中，就有10个登录网站，那么此网站的登录转化率就为10%，而最后有2个用户订阅，则订阅转化率为2%，有一个用户下订单购买，则购买转化率为1%。
转化率反映了网站的盈利能力，重视和研究网站转化率，可以针对性的分析网站在哪些方面做的不足，哪些广告投放效果比较好，可以迅速的提升用户体验、节约广告成本，提升网络转化过程。
重复购买率
指消费者对该品牌产品或者服务的重复购买次数。
重复购买率有两种计算方法：一种是所有购买过产品的顾客，以每个人人为独立单位重复购买产品的次数，比如有10个客户购买了产品，5个产生了重复购买，则重复购买率为50%；第二种算法是，单位时间内，重复购买的总次数占比，比如10个客户购买了产品，中间有3个人有了二次购买，这3人中的1个人又有了三次购买，则重复购买次数为4次，重复购买率为40%。直与复推荐企业采取第一种算法。
重复购买率越多，则反应出消费者对品牌的忠诚度就越高，反之则越低。
—-用户指标—-
ARPU
Average Revenue Per User，即每用户平均收入
在一定时间内，ARPU=总收入/用户数，一般是计算长期的ARPU比较有意义，如平均每月每用户收入。
而用户数可以是总平均在线用户数、付费用户数或是活跃用户数，不同产品标准可能存在差别。
ARPU注重的是一个时间段内从每个用户所得到的收入，衡量互联网公司业务收入的指标。ARPU值高说明平均每个用户贡献的收入高，但高未必说明利润高，因为利润还需要考虑成本。ARPU的高低没有绝对的好坏之分，分析的时候需要有一定的标准。
用户流失率
是指那些曾经使用过产品或服务，由于对产品失去兴趣等种种原因，不再使用产品或服务的用户。
用户流失率=总流失用户数/总用户数，流失用户数依产品而定，并且有各自的不同标准。
分析用户的流失情况可以找到流失的原因，针对产品所处的时期再找到解决办法。一般流失用户都是对于那些需要注册、提供应用服务的网站而言的，比如微博、邮箱、电子商务类网站等。对于流失用户的界定依照产品服务的不同而标准不同，对于微博和邮箱这类用户几乎每天登录查看的网站而言，可能用户未登录超过1个月，我们就可以认为用户可能已经流失了；而对于电子商务而言，可能3个月未登录或者半年内没有任何购买行为的用户可以被认定是流失用户。因此这里有个流失期限。
活跃用户
是相对于“流失用户”的一个概念，是指那些会时不时地光顾网站，并为网站带来一些价值的用户。
活跃用户用于衡量网站的运营现状，而流失用户则用于分析网站是否存在被淘汰的风险，以及网站是否有能力留住新用户。
每个产品活跃的定义千差万别，如果是有帐号的客户端产品，例如IM、端游等，通常以帐号登录作为活跃标识。如果是某些工具软件，有的以启动作为活跃，例如看天气的。有些需要进行一些核心操作，例如拍照软件，至少是完成一张照片拍摄，才能算活跃吧。
日活跃用户
DAU，Daily Active User，指某个自然日内启动过应用的用户，该日内的多次启动只记一个活跃用户。
月活跃用户
MAU，Monthly Active User，指某个自然月内启动过应用的用户，该月内的多次启动只记一个活跃用户。
这两个指标一般出现在在线服务的分析统计指标中，比如在线文档，或者是网页邮箱服务，网络游戏，SNS游戏等等。一般用来衡量服务的用户粘性以及服务的衰退周期。
DAU/MAU比例是SNS游戏的重要参数，一般最低极限是0.2，这保证游戏能够达到临界规模的病毒式传播和用户粘性。
周活跃用户
WAU，Weekly Active User，指某个自然周内启动过应用的用户，该周内的多次启动只记一个活跃用户。这个指标是为了查看用户的类型结构，如轻度用户、中度用户、重度用户等。
用户保有率
用户保有率指在单位时间内符合有效用户条件的用户数在实际产生用户量的比率，也叫用户留存。
保有率=保有量/实际量
次日留存率：（当天新增的用户中，在第2天还登录的用户数）/第一天新增总用户数。因为都是新用户，所以结合产品的新手引导设计和新用户转化路径来分析用户的流失原因，通过不断的修改和调整来降低用户流失，提升次日留存率，通常这个数字如果达到了40%就表示产品非常优秀了。
第3日留存率：（第一天新增用户中，在往后的第3天还有登录的用户数）/第一天新增总用户数。
周留存率：（第一天新增的用户中，在往后的第7天还有登录的用户数）/第一天新增总用户数。在这个时间段里，用户通常会经历一个完整的使用和体验周期，如果在这个阶段用户能够留下来，就有可能成为忠诚度较高的用户。
月留存率：（第一天新增的用户中，在往后的第30天还有登录的用户数）/第一天新增总用户数。通常移动APP的迭代周期为2-4周一个版本，所以月留存是能够反映出一个版本的用户留存情况，一个版本的更新，总是会或多或少的影响用户的体验，所以通过比较月留存率能够判断出每个版本更新是否对用户有影响。
渠道留存：因为渠道来源不一，用户质量也会有差别，所以有必要针对渠道用户进行留存率分析。而且排除用户差别的因素以后，再去比较次日，周留存，可以更准确的判断产品上的问题。
留存用户和留存率通常反映了不同时期获得的用户流失的情况，表现不同时期用户对产品的适应性和黏性，分析这个结果往往是为了找到用户流失的具体原因。
如果老板问你「我们应该提升销量还是提高利润？」一定要记得，无论你怎么回答，都是错的。
因为，企业利润最大化并不在于「卖的贵」或者「卖的多」，而是尽量“榨干”消费者剩余（消费者剩余=消费者愿意支付的最高价格-实际成交价）。要怎么“榨干”呢？这就需要引入经济学概念：价格歧视。
价格歧视：同样的产品，针对不同的消费者收取不同的价钱。
案例：有三位想吃冰淇淋的顾客。土豪出价10元；白领出价8元；而小学生零花钱只剩6元。如果你是老板，冰激凌成本5元，怎么定价合适呢？
如果追求利润卖10元，只有土豪买得起（损失客户：白领、小学生），你能赚5元。
如果追求销量卖6元，三人都会买，但利润太低只赚3元。
如果定中间价8元，能赚6元（损失客户：小学生）。
难道最多只能赚6元吗?
当然不是，其实可以赚最高利润9元。具体做法是：分别卖土豪10元，卖白领8元，卖学生6元，
可是问题来了，不会有人主动把他愿意支付的最高价告诉你。那怎么办呢？
答案就是：给优惠设置重重障碍。企业通过区分消费者是否愿意付出时间成本或被限制选择权，窥视其支付意愿。
1.优惠活动：用时间成本区分消费者
电商网站上充斥着各种优惠信息：积分返现、买2免1、满199减20、满399减50、优惠券、定金立减……
消费者想要获得最低价，不仅要通晓所有优惠规则，还要知道“满减和积分能不能同时使用？”、“特价商品是否参加买2送1”等复杂信息。甚至网上还会流传每年双11的优惠攻略。
既然降价可以提升销量，为什么企业不简化流程直接打折呢？
这是因为，企业需要通过规则复杂的活动来区分愿意付出时间研究优惠信息的「穷人」和不在乎优惠信息直接下单的「富人」，让他们都支付了他们愿意支付的最高价格。
例如，大晚上不睡觉抱着手机抢秒杀，就为了便宜20块的「穷人」和宁愿多花钱也懒得搜集优惠券的「富人」相比，前者就能以更低的价格买到同样的商品。（PS：本文的「穷人」与「富人」是指消费者对待某件商品的支付意愿，并非单指经济状况。虽然经济状况会影响支付意愿，但并非唯一因素。）
除了占用消费者的时间，还有其他方法吗？
2.限制购买：通过限制主动权区分消费者
买打折的衣服可能要等到换季，为什么不能想要的时候立刻拥有？为什么iphone一样的配置，土豪金要贵一些？为什么买一送一往往都是赠送指定商品？
这可能也是一种商家区分「富人」和「穷人」的手段。通过限制消费者主动权（限制下单时间、限制购买品类），从而达到区分消费者支付意愿的目的。想要低价，「穷人」只能在双十一下单；想要低价，「穷人」只能在参加活动的几款商品中选择。而「富人」更有可能情愿不参加活动，随心在任何时候买自己想要的任何商品。
小结
需要说明的是，我们不应该把价格歧视看做是不良商家“欺骗”消费者的恶劣手段。从某种意义上说，正是因为价格歧视，才让一些收入偏低的人群也能享受到更高品质的商品。例如文章开头的小学生，虽然只有6元，却能和土豪一样尝到美味的冰激凌。
企业降价促销的原因有很多，价格歧视只是其中一种。但无论基于何种原因的的促销活动，客观上都可会引发价格歧视现象。
一、什么是产品定位
官方说法：产品定位就是对产品目标、范围、特征等内容的约束条件。
我的理解：就是让你的产品“从宇宙具体到地球”、“从食物具体到米饭”、“从单位具体到厘米”，简单来说就是让产品从“大”到“小”的一个过程。
举个例子：假如你在做一个关于电子邮件的产品，如果你只用电子邮件来描述你的产品，那是没有任何价值的，因为你说的太泛了，这时候产品定位就能够告诉你，你是在做一个什么样子的电子邮件，比如说“给白领移动办公的高效快捷的电子邮件”。
但其实产品定位还远远不止这些内容，那它到底由哪些内容组成呢？
二、产品定位的组成内容
我们先看一遍产品定位的组成结构，内容如下图：
产品定义
产品定义是我们工作中经常会提到的内容，也就是一句话描述你的产品，它包括三个内容，使用人群、主要功能、产品特色。
举个例子：一款为单身男女更容易成功约会的即时通讯工具。这其中
使用人群：单身男女
主要功能：即时通讯
产品特色：更容易约会成功
用户需求
用户需求一般都是基于产品定义的基础上提炼出来的。包括目标用户、使用场景与用户目标。
目标用户：在“使用人群”的基础上进行细分。比如还是上面那个例子，使用人群是单身男女，我们将使用人群细分为：18-25岁、25-35岁、35-45岁和45岁以上的单身男女。最后将目标用户定为25-35岁的单身男女，当然为什么选取这部分人群需要一些理由，比如这部分群体的经济比较独立，年龄更适合步入婚姻的殿堂等等。
使用场景：在“主要功能”的基础上进行延展。比如我们的主要功能是即时通讯，那即时通讯会分为很多使用场景，比如上下班的路上、睡觉前，起床后等等。
用户目标：在“产品特色”的基础上展开分析。比如产品的特色是“更容易约会成功”，那为了达成这个大的产品目标，我们需要细化，将其分解成多个小的用户目标，如快速看到周围单身异性的信息状态、快速了解周围哪些异性对自己有兴趣等等。
综合上面三点，我们可以清晰得得出多个用户需求，例如：让25-35岁的单身男女在睡觉前快速了解周围哪些异性对自己有兴趣等等。
总结
以上就是产品定位的组成内容，在这里需要强调以下两点：
1.目标用户、产品特色、主要功能是产品定位中最核心的内容。
2.不同的产品进行内容细分时的维度会有所不同，例如，在对使用人群进行细分时，可以利用年龄进行细分，也可以利用职位、性格等等。千万不要被案例和规则限制死。
三、产品定位对交互、视觉设计师的作用
说了这么多，那到底产品定位对我们交互和视觉有什么用处呢？
首先可以帮助我们对整个产品有个大局观，至少清楚我们到底在做什么。但这一点可能听着有点虚，那我们来举几个简单的例子。
1.使用人群对我们有什么作用？
如果我们的产品使用人群是50岁以上的老人，而你设计的界面字体大小是下面这样的那或许你还应该给用户再配一个下面这样的东西：再比如一个产品的使用人群是高端商务人士，而你却采用五彩缤纷的颜色，是不是有些不搭调呢
当然上面这些例子可能有些夸张，目的是为了让大家有一个更好的记忆点，希望大家在做交互、视觉的时候可以在产品定位的基础上去进行创意延展，而不是天马行空的乱作一通，不然及时你做的再好，都没不会产生太大的商业价值。
2.使用场景对我们有什么作用？
如果产品的主要使用场景是在晚上，那我们是不是可以提供一个夜间模式并将其设置为默认模式呢？
当然以上只是简单的举几个例子，其实产品定位对于我们的帮助还远不止这些，比如还有思维上的帮助等等，大家平时可以多多思考，希望这些例子可以对你有一些启发。
对于交互、视觉设计师来说，短期内了解基础的知识点就够了，研究的太深反倒会本末倒置，我个人觉得以上这些知识点只要你能够理解透彻，在实际工作中完全够用了，后面如果你真的觉得这些都是小儿科，再继续深造也完全ok。
产品笔试后不会知识点总结相关推荐
- 【博学谷学习记录】超强总结，用心分享 | 产品经理内容项目的知识点回顾与梳理
[博学谷学习记录]超强总结,用心分享 | 产品经理内容项目的知识点回归与梳理 前言 学习过内容产品的相关内容后,一些学习总结. 一.内容产品模型 内容生产 PGC:专业用户生产内容: UGC:普通用户 ...
- 2016年腾讯产品笔试真题
2016年腾讯产品笔试真题 [尊重原创,转载请注明出处]http://blog.csdn.net/guyuealian/article/details/51154308
- 面试题，你是如何评判产品改版后的效果的？
有个小伙伴在微信上问我这个问题,说他在面试中被问到如何评判产品改版后的效果这个问题,问我该如何回答,今天就来给大家拆解这道题. 题目分析 这道题主要考察求职者的数据分析能力,那些对数据不关注,只埋头画 ...
- PM at Google —— 最全产品经理常用术语及知识点，建议收藏！
产品经理闯关入门小手册~ 本文来自知乎网友 AnNo PM Product Manager,产品经理 UI UI设计师简称UID(User Interface Designer),指从事对软件的人机交 ...
- 产品上架后，亚马逊运营应该做什么
当一个亚马逊产品上架后,运营成熟以后,每天运营应该做些什么呢?下面海熹跨境人才网就来给大家说说亚马逊运营每天的工作,一起来了解一下吧. 1. 分析后台数据 数据的分析工作一般我会放在上午进行,这个时候 ...
- 前端实习生笔试_阿里巴巴前端实习生在线笔试后经验分享
导读:还是太年轻,第一次在线笔试有些紧张了, 一.2015题目 我遇到的题目:6个选择其中3个多选,1个填空,6个大题.客服姐姐说题目是随机给的(因为给了一个时段考试,而不是统一时间点开考),不过题型 ...
- 一篇充满碎碎念的短期自我总结（三）【tencent产品笔试+游戏群面总结】
今天主要记录一下腾讯的笔试面试过程吧,这是最近收获最大的地方. 文中疑似面经内容多来源于个人推论,不具有科学性[别相信,没拿到offer,看看就好] 刚投腾讯的时候,腾讯的校招官网是没有显示状态的(后 ...
- 发现网络产品漏洞后，应立即通知上游开发者，并及时通知下游用户
[网络产品安全漏洞管理规定·第七条] 网络产品提供者应当履行下列网络产品安全漏洞管理义务,确保其产品安全漏洞得到及时修补和合理发布,并指导支持产品用户采取防范措施: (一)发现或者获知所提供网络产品存 ...
- 模压硅胶产品成型后加工工艺
引言 原始的模压硅胶制品颜色单一.不光滑.缺乏美感,这极大的限制了硅胶这个优秀材料的适用场景.通过不同工艺的加工处理,硅胶的手感.颜色.视觉效果.形状等会变得更加吸引人,从而有了更广的适用范围. 工艺 ...
- 网易有道产品笔试及个人解答（小部分题目）
1. 1/4 1/3 1/2 27/35 () 找到一个规律但是没有答案: 2/8 5/15 12/24 27/35 也就是每一项的分子(第一项除外)等于前一项分子乘以2+1或2或3···一直递增 而 ...
最新文章
- Mysql判断工作日函数_MySQL函数查找两个日期之间的工作日数
- CentOS下SVN服务的启动与关闭
- 检验Xcode是否被改动过的简单方法，不妨试试！！！
- python小课骗局-python小课值吗
- python导入txt为dataframe-Python提取TXT数据转化为DataFrame
- ubuntu 安装 phpstorm
- ubuntu1604安装tensorflow
- Android开发笔记（一百三十八）文本输入布局TextInputLayout
- 机器学习基础学习笔记
- WPS2000系列之二样式管理(转)
- CSS 幻术 | 抗锯齿
- python程序设计与算法基础第二版课后答案_python算法与程序设计基础答案
- GPG Overview
- 五金机电行业供应商智慧管理平台解决方案：优化供应链管理，带动企业业绩增长
- 织梦模板下载：环保设计公司织梦模板
- mysql mmm切换_Mysql-MMM slave无法切换change master的解决方案
- 蓝桥杯 算法提高 阮小二买彩票 Python
- 【智能商业】看十年·曾鸣书院公开课：未来的商业是智能商业
- 科研经验002：如何礼貌地要代码的邮件模板
- gataway 组件的健权、限流、过滤等功能分析（三十一）