精华内容
下载资源
问答
  • 系统性能衡量维度、指标

    千次阅读 2019-03-25 16:00:39
    一、性能问题简介 应用性能是产品用户体验的基石,性能优化的终极目标是优化用户体验。当我们谈及性能,最直观能想到的一个词...二、性能指标 性能优化是个系统性工程,涉及到后端、前端、移动端、系统网络及各...

    一、性能问题简介

           应用性能是产品用户体验的基石,性能优化的终极目标是优化用户体验。当我们谈及性能,最直观能想到的一个词是“快”,Strangeloop在对众多的网站做性能分析之后得出了一个著名的3s定律页面加载速度超过3s,57%的访客会离开”,可见页面加载速度对于互联网产品的重要性。

    二、性能指标

           性能优化是个系统性工程,涉及到后端、前端、移动端、系统网络及各种基础设施,每一块都需要做各自的性能优化。当我们系统的分析性能问题时,可以通过以下指标来衡量:

    1、Web端首屏时间、白屏时间、可交互时间、完全加载时间

           首屏时间是指从用户打开网页开始到浏览器第一屏渲染完成的时间,是最直接的用户感知体验指标,也是性能领域公认的最重要的核心指标。
           首屏时间 = DNS时间 + 建立连接时间 + 后端响应时间 + 网络传输时间 + 首屏页面渲染时间

    2、移动端Crash率、内存使用率、FPS(Frames Per Second, 每秒传输帧数)、端到端响应时间
           Native相比于H5在交互体验方面有更多的优势,FPS是体现页面顺畅程度的一个重要指标,另外移动端开发同学还需要关注App进程的CPU使用率、内存使用率等系统性能指标。端到端响应时间是衡量一个API性能的关键指标,比纯后端响应时间更全面,它会受到DNS、网络带宽、网络链路、HTTP Payload等多个因素的影响。
           端到端响应时间=DNS解析时间+网络传输时间+后端响应时间

    3、后端响应时间(RT)、吞吐量(TPS)、并发数

           QPS: 每秒钟处理完请求的次数;注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter,每处理一个请求加1,1秒后counter=QPS。
           TPS:每秒钟处理完的事务次数,一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理,一个事务在分布式处理中,可能会对应多个请求,对于衡量单个接口服务的处理能力,用QPS比较多。
           并发量:系统能同时处理的请求数
           RT:响应时间,处理一次请求所需要的平均处理时间。后端系统响应时间是指系统对请求做出响应的时间(应用延迟时间),对于面向用户的Web服务,响应时间能很好度量应用性能,会受到数据库查询、RPC调用、网络IO、逻辑计算复杂度、JVM垃圾回收等多方面因素影响。
           对于高并发的应用和系统,吞吐量(TPS)是个非常重要的指标,与CPU、内存资源的消、调用的外部接口及IO等紧密关联
    计算关系:
           QPS = 并发量 / 平均响应时间
           并发量 = QPS * 平均响应时间

    三、影响性能的因素

           互联网产品是创意、设计、研发、系统、网络、硬件、运维等众多资源相互交织的集合体,性能受多方面因素影响,犹如一只木桶,木桶能盛多少水,取决于最短的那块木板,也可称之为短板效应。影响产品性能的因素有:

    1、产品逻辑与用户行为

           产品逻辑过于复杂、功能交互过于丰富、产品设计过于绚丽、页面元素素材过多等都会影响产品性能。

    2、基础网络

           中国的基础网络是世界上最复杂的基础网络,国内的网络运营商众多且各自为政,互联互通成本很高。对于境外业务来说更是要面对国内国际网络交互的情况,再加上GFW的存在,网络延迟、丢包现象非常严重。

    3、代码及应用

           开发语言瓶颈、代码质量及系统架构等都会影响系统性能,常见的代码及应用问题有:
           (1)、架构不合理。业务发展超越架构支撑能力而导致系统负荷过载,进而导致出现系统奔溃、响应超时等现象。另外不合理的架构如:单点、无cache、应用混部署、没有考虑分布式、集群化等也都会影响性能。
           (2)、研发功底和经验不足。开发的App、Server效率和性能较低、不稳定也是常见的事情。
           (3)、没有性能意识,只实现了业务功能不注意代码性能,新功能上线后整体性能下降,或当业务上量后系统出现连锁反应,导致性能问题叠加,直接影响用户体验。
           (4)、多数的性能问题发生在数据库上。由慢SQL过多查询等原因造成的数据库瓶颈,没有做读写分离、分库分表等。

    4、移动端环境

           移动互联网时代,移动端环境的复杂性对产品的性能影响也很大,比如用户的设备类型、设备性能、操作系统类型、系统版本及网络类型等。
    5. 硬件及云环境

           硬件的发展遵循着摩尔定律,生命周期一般都很短,服务器老化或其他硬件问题经常会导致应用故障。IDC、机架、服务器、内存、磁盘、网卡等不同硬件和操作系统上运行的应用性能差距可以达到数十倍之多。

    展开全文
  • 用户体验衡量指标分析

    千次阅读 2019-08-23 16:59:59
    本篇主要在分享一些使用体验横标指标上的一些迷思,与介绍工作中常用的一些指标,至于如何透过这些指标帮助UX Designer 在工作中提升重要性,来自证UX 工作能带来的价值部分,可以看一下Nathan 以前写过的一篇古早文...

    出处:UXRen社区

    今天给大家分享一篇衡量用户体验指标的工具好文,希望对大家有帮助~

    本篇主要在分享一些使用体验横标指标上的一些迷思,与介绍工作中常用的一些指标,至于如何透过这些指标帮助UX Designer 在工作中提升重要性,来自证UX 工作能带来的价值部分,可以看一下Nathan 以前写过的一篇古早文。

    1、关于数据指标与衡量的常见迷思
    01 数据指标的使用,不符合GSM 原则
    当有一定的用户后,结合常见的数据分析工具或内部团队自建的数据埋点,网站和应用马上就能出现许多可供分析的数据,似乎只要有这些数据,令人惊喜的洞察就会自动浮出水面。

    GSM(Goal-Signal-Metrics)是Google 提出的目标导向衡量模型,用来拆解用户使用产品时的设计目标-行为信号-衡量指标的一种模式。
    在这里插入图片描述
    Google GSM Framework, Goal-Signal-Metrics

    在商业场景中,所有的数据衡量必定带有明确的目标,比如:透过观察宽口转化和窄口转化,分析广告投放效益以及GMV 成本。甚至,如果仅基于这些观察数据进行动作性的优化,没有配合中长期的决策时,变化仅会流于短期效益。

    02 显而易见的数据指标,不代表就是有帮助的
    一个数据指标容易监测与计算,并不意味着它对你的产品来说就是重要的。透过现在大部分的分析工具,可以很容易就监测跟踪成百上千的各种指标,而且分析的工具也层出不穷。新产品团队往往因为能获取大量的数据,然后就期望洞察自动出现,但往往不遂人意。

    例如,网页或App 的PV 数据很容易收集,但如果你的网页或产品是属于内容消费类型的,它就无法呈现用户是否在你的网站消费内容(有效时长更具代表性)。高的PV 或许是由市场广告转化过来的用户,但对内容消费类的产品目标,肯定不是确定每个用户到底浏览了多少页面,PV 可能是衡量广告效果的重要度量,但它并不是监测用户参与度的良好方式。

    如果你不确定你正在用的数据指标,是否有正向帮助的话。可以参考AARRR 的转化模型,来帮助自己梳理清楚核心的转化链路。

    03 单一的数据指标,对于效果衡量可能是模糊的
    如上面所说相较于PV、UV、DAU,用户在网站或应用中的有效停留时长,可能更适合用来衡量用户在产品中的参与度。

    但停留时间越长可能是正面的,也可能是负面的。在电商产品类的转化过程中,如果在关键的转化节点用户停留较久,可能意味着用户因困惑、分心或挫败而花费了大量时间。即便同时监测网站或应用的停留时长和转化率,你可能仍然不清楚为什么用户参与度如此高,对于最后的成交却没有太大帮助。

    这时就需要透过配合更细致的数据指标组合,慢慢的定位用户在操作步骤中的关键问题,并尝试透过A/B Testing 来解决。

    04 正确的衡量指标,要依产品、企业本身而制定
    大家常用的数据指标,并不一定适合自己当前产品阶段或企业目标。

    正常而言企业的主力产品,正是代表着企业主要的商业营利模式,因此在发布产品后要监测的各种衡量指标,通常在产品准备进入市场前,都已依照商业模式进行拆分。但在产品的冷启动时期,这些依商业模式拆分的指标,很多时候无法反映出,企业的产品是否正在往好的方向成长。

    比如Saas服务类型的产品,通常都会使用净收入留存NDRR (Net Dollar Retention Rate)作为主要的商业模式指标,但在前期用户量少时,搭配NPS或PSAT等类型的指标,才能够好的回归到Saas产品的服务体验本质。了解企业目前提供的服务,对用户来说是否是正向的,并且能持续增长。

    05 大多时候,衡量指标并不会纯粹与设计相关
    在产品开发迭代中发布新功能后,数据可能会开始上升。产品团队可能认为这是新功能的发布造成的,但销售部分却可能会将它与一项新的促销活动联系起来,而UX 团队则可能认为这与他们的新设计相关。

    这种场景在产品的数据到达一定规模时十分常见。真实情况是只能透过控制一些固定因子,来做更细部的A/B Testing 拆分。但大多时候产品的迭代时间与开发资源,很难真正做到能明确确认是因为什么原因。

    因此结合前面所说的,各团队在主要的数据指标中,配合其他辅助指标,甚至提取更与团队紧密相关的个别指标,来了解在产品的迭代过程中,各自团队做的决策是否是正向的。

    用户体验指标,跟易用性和商业指标目的不同

    下面就会介绍几种工作中常用的,与体验相关的衡量指标,部分指标在订定的一开始,本身即包涵了商业与体验维度。

    2、工作中可能用到的几种体验衡量指标
    大部分的体验衡量指标,都会基于三个主要价值观,结合其他用户态度类型作为衡量基准。

    可用性
    参与度
    转化率+ User Attitude
    下面介绍几种,在工作中可能常用到的通用型,与不同业务场景型的体验衡量指标。

    2.1 通用型
    01 传统网站服务使用的PULSE

    PULSE 是基于商业和技术的衡量模型,被很多组织和公司广泛应用于跟踪产品的整体表现。包含:

    Page view 页面浏览量
    Uptime 响应时间
    Latency 延迟
    Seven days active user 7天活跃用户数
    Earning 收益
    但不难看出PULSE 指标仅覆盖了UX 设计中最最基础的可用性部分,和衡量用户体验的直接关系不大,难以评估设计工作到来的影响,毕竟这个指标创建之初是用来衡量产品的技术与商业效果。

    因此为了弥补PULSE 指标中存在的问题,Google 提出了HEART 指标模型。HEART 是“以用户为中心度量的指标体系,以及把产品目标与创建指标体系相互关联的过程”

    02 以使用者为中心的HEART

    HEART其实也是业界使用的老黄历了,尤其常用GA ( Google Analytics ) / Adobe Omniture的人一定都对他不陌生。

    早期产品开发上线的阶段,大多是订定业务KPI 作为衡量项目产出的价值,但在用户体验的部份,却很难有可视化以可及量化的衡量指标。因此Google 尝试把产品目标以及体验指标相互结合,建立以用户为中心的HEART 度量体系。
    在这里插入图片描述
    Heart 体验衡量指标模型

    2.2 Saas 服务型
    01 NPS( Net Promoter Score净推荐值)

    净推荐值最早是由贝恩咨询的创始人Fred Reichheld 在2003 提出,通过测量用户的推荐意愿,从而了解用户之于产品或服务的忠诚态度。

    NPS 算是近几年用户体验领域上的当红指标(甚至业内还有所谓的NPS 教派XD),基本上互联网类产品都可以使用。其基本核心理念是,一个企业的用户可被划分为三类:推荐者、中立者和批评者。

    推荐者是投入且重复使用产品的用户,他们会热情地向其他人推荐你的产品或服务。
    被动者是对产品满意,但缺乏热情和忠诚度的用户,他们很容易转而投向使用竞争者的产品或服务。
    批评者是那些明显对企业的产品或服务不满意的那部分用户
    相较于其他的指标,NPS 询问的是意愿而不是情感,对用户来说更容易回答,且直接反应了客户对企业的忠诚度和购买意愿,在一定程度上可以看到企业当前和未来一段时间的发展趋势和持续盈利能力。

    02 CES( Customer Effort Score用户费力度)

    CES 指的是你的产品或服务,会需要用户花费多少力气才能满足自身需求。

    根据Oracle 的一项研究,82%的人把他们的购买经历描述为“花费太多的努力”,CES背后的理论就是,应该想办法减少客户为了解决问题而付出的努力。CES可以帮助你找出可优化的方向,更容易理解在哪里进行改善,较低的费力度也与客户留存直接相关,从而增加客户的生命周期价值。

    一般情况下,大多会先利用CSAT、PSAT这类的指标来衡量客户对产品或服务的体验反馈,当这套标准的价值到达临界点时,就应该尝试CES作为满意度指标的扩充,更充分的评估Saas产品的用户体验情况。

    03 FCR( First contact resolution一次性解决率)

    作为Saas类服务型产品,在获取新客或帮助旧客时,大多是通过客户服务,在许多的互联网公司Customer Service团队也是重点投入资源的。而「FCR一次解决率」即是用来衡量这类客户服务的指标。

    FCR 是指客户的服务需求在第一次客户服务中完全解决的占比率。

    测量一次性解决率是相当简单的。通过单次交互(电子邮件响应,电话,聊天会话等)解决你收到的客户请求数量,并除以同一时期收到的请求总数。

    一次性解决率不仅对Saas 产品的客户至为重要,也能体现客户服务的绩效和表现,甚至深入到每个员工的层面上。

    2.3 系统性评估型
    01 SUS( System Usability Scale系统可用性量表)、QUIS(Questionnaire for User Interface Satisfaction用户交互满意度)

    SUS 应该也算是用来评估单个用户使用某个产品的可用性时,最常见的指标了。SUS 是一种用来量化定性数据的方法,并不仅仅依靠数据统计,需要结合用户具体参与来进行调研,通常作为可用性测试的组成部分。

    SUS 通常用来作为改版效果的整体评估,在使用时可以对题目的主词产品进行替换,这些替换对最后的测量结果都没有影响。

    而QUIS 则可以说是SUS 的进阶版,会更注重具体页面或操作节点的易用性,通常作为SUS 的延伸使用。比较简单的QUIS 版本包括27 个问题,分为5个类别:

    Overall Reaction 总体反应、Screen 屏幕、Terminology/System Information 术语/系统信息、Learning 学习、System Capability 系统能力

    02 CSAT( Customer Satisfaction客户满意度)、PSAT( Purchase Satisfaction购买满意度)

    客户满意度也算是经典的衡量指标之一了,随着商业竞争的激烈,各类型的产品与企业都对客户满意度更加重视,很多时候你所熟悉的电话满意调研、电子邮件调研,甚至直接在消费后的星级评分,其实都是关于这类问题的问券。

    PSAT 则是在CSAT 的基础上,针对消费类型产品进行细化,强调售后使用体验的部分。这类问卷的好处是简单且扩展性强,可大至系统小至任务。

    但缺点就是用户容易在中等范​​围内回答问题,无法给企业带来真实的反馈。而且,即使在客户满意度很高的情况下,依然有可能遭遇留存流失问题。

    因为满意度并不直接与客户忠诚度相关联。

    其他相关的系统性可用型指标当然还有许多,不过在工作流程中一般来说都较少会使用到,主要还是更具专业性的用研User Researcher 角色较常使用,包含:

    SUMI(Software Usability Measurement Inventory 软件可用性测试)
    CSUQ(Computer System questionnaire 计算机系统可用性测试
    USE (Usefulness, Satisfaction, and Ease of Use 有用性、满意度、易用性)

    2.4 电商产品型
    01 PSM(Price Sensitivity Measurement 价格敏感度测试)

    PSM 衡量目标用户对不同价格的满意及接受程度,了解其认为合适的产品价格,从而得到产品价格的可接受范围。

    PSM 考虑了消费者的主观意愿,又兼顾了企业追求最大利益的需求。但测试过程主要基于目标对象的自然反应,没有涉及到任何竞争产品的信息。所以在横向拉通上显得较为薄弱。

    也正因为缺少对于竞争产品的分析,所以PSM 目前主要集中在自成体系的产品链路中,用来配合Saas 服务或虚拟产品的定价,在实体产品中已经较少被使用。

    02 DSR(店铺质量评分)

    DSR 算是电子商务类产品中的特殊指标,初期是在在阿里巴巴的电商生态中大规模使用,目前也慢慢变成电商场景的通用指标。

    DSR 是指买家在电商平台上购物成功后,针对本次购物给出的评价分数。买家可以评分的项目包括「描述相符、服务态度、发货速度、物流速度」4 项。

    DSR 评分计算方法:每项店铺评分取连续6个月内买家给与该项评分的总和/连续6个月内买家给与该项评分的次数,统计最近180天

    DSR 评分直接影响卖家在电商平台中,商品搜索曝光权重的高低,从而影响商品与店铺的排名。因此对于平台类的UX Design Team 来说,建立类似DSR 的曝光评分机制,也是间接影响服务提供商的产品体验,进而提升整体平台中的用户体验质量。

    03 ZMOT(Zero Moment Of Truth第零关键时刻)、FMOT(First Moment Of Truth第一关键时刻)、SMOT(Second Moment Of Truth第二关键时刻)

    FMOT & SMOT 是目前新零售场景常会提到的指标模型,但其实在传统的零售行业早就是一个通用的衡量指标,FMOT 指的是消费者在接触到对应商品货价的关键3~7 秒,所有的商品售价、包装、摆设都是在这关键3~7 影响消费者拿取商品甚至购买的关键因素。

    而SMOT 则是指这类实体产品,在消费者购买回家后的首次体验,是否符合这个商品的广告语,对于一个品牌来说,即是是否成功地履行了它的承诺还是令人感到失望,这也是消费者是否会成为一个品牌的粉丝,甚至在线上或线下渠道分享的关键(是否很像NPS 的精神?)。

    延伸出的ZMOT,即是线上线下结合的新零售关键指标,让消费者在「尚未接触」到特定商品前,就透过线上向消费者进行行销,当消费者主动进行相似活动、搜索时,就能接收到产品的正面讯息来影响消费意向。

    2.5 主观评估型
    用户体验的主观评估,大多是偏观察式的方法,也是大家比较耳熟能详的用定性调研法,比如眼动仪、观察法、品牌问卷… etc.。

    当然如果要尽可能尝试量化这类User Attitude 主观评估数据时,前提都是把用户体验理解成两种维度,一种维度是实用性(Pragmatic)偏向常说的可用性,另一种是享乐性(Hedonic)也就是常说的舒适性,享乐性维度还会被拆分成了几种属性,例如Stimulation和Identification。

    01 UEQ(User Experience Questionnaire 用户体验调查表)

    UEQ 是SAP 开发的一套定量分析用户体验的工具。用户在问卷上表达出他们在使用产品和服务中的感受,印象和态度,然后生成一个包含用户体验数个方面的量化表。包括传统的易用性方面的指标:

    Efficiency 高效
    Perspicuity 易懂
    Dependability 可信任
    也包括三个体验方便的指标:

    Attractiveness 吸引度
    Stimulation 激励性
    Novelty 新鲜度
    02 HQ(Hedonic Quality享受性质量)、PQ(Pragmatic Quality实用性质量)& AttrakDiff

    HQ 主要是用来消费型产品的情感衡量指标,较常使用消费者对于消费类型产品的评价。而PQ 则主要是在易用性层面上加入主观因素的评分,如果要针对性地对HQ & PQ 进行系统性评分,AttrakDiff 则是一个较常使用的工具。

    AttrakDiff 包含了28 项题目,每一项都是一个7 分制量表,最低分和最高分代表一对具有评价性质的反义词,用户需要根据使用产品过程中的某一方面的体验从低到高进行评分,比如“混乱的— — 清晰的”,分数越高,表明产品的某一方面设计得越清晰。

    3、写在最后
    在产品或业务中导入体验数据衡量指标,不是新入行的设计师想像的这么简单。真正的实务过程绝不是将文章中的指标,直接导入自己对接的产品中,每一个数据指标都有其目的,且不同的人即便看到的数据相同,也都会有自己的解读方式。

    过于依赖指标,如果不随时依据市场动态与公司策略进行调整,不仅容易因为短期的良好数据忽视了中长期的产品成长,也会慢慢的丧失设计师的感性创意能力。

    所以,清楚的认知到哪个指标可以帮助我进行什么样的设计策略。才是真正的使用方式。千万别让设计师变成动作导向的工作职位,

    Value-Driven 价值导向的工作模式,才是设计师的生存法则

    展开全文
  • 软件体系结构期末复习总结

    千次阅读 多人点赞 2020-08-18 21:14:41
    什么是软件体系结构? 软件体系结构是具有一定形式的结构化元素,抽象的讲,软件体系结构包括构成系统的设计元素的描述,设计元素的交互,设计元素组合的模式,以及在这些模式中的约束。具体的讲,体系结构 = 组件+...

    什么是软件体系结构?

    软件体系结构是具有一定形式的结构化元素,抽象的讲,软件体系结构包括构成系统的设计元素的描述,设计元素的交互,设计元素组合的模式,以及在这些模式中的约束。具体的讲,体系结构 = 组件+连接件+约束

    组件:具有某种功能的可重用的软件模块单元,表示了系统中主要的计算单元和数据存储

    连接件:表示了组件之间的交互,简单的连接件有:管道,过程调用,事件广播等,复杂的连接件有:客户-服务器通信协议,数据库和应用之间SQL连接等。

    约束:表示了组件和连接件的拓扑逻辑和约束

    七种经典的软件体系结构风格

    在这里插入图片描述

    能够回答以下四个问题:
    1. define (定义和特性)
    2. component & connectors (组件和连接件)
    3. usage examples (应用示例)
    4. advantages and disadvantages (优点和缺点)

    pipe and filter(管道-过滤器)

    在这里插入图片描述

    组件和连接件

    组件: filters -->处理数据流,一个过滤器封装了一个处理步骤。

    连接件:pipes --> 连接一个源和一个目的过滤器。

    定义和特性

    每个过滤器都有一组输入集和输出集。过滤器从管道中读入数据流,对输入流进行内部转换和增量计算(丰富,精炼,转换,融合,分解),然后产生输出数据流并写入管道中。

    特点:

    • 每个过滤器必须是一个独立的实体:过滤器之间无需共享状态,即filter无需知道其输入管道和输出管道所连接的其他过滤器的存在,更不必关注相邻过滤器的实现细节。他仅仅需要对输入数据流进行特定的内部転换和增量计算,筛选出合适的数据。
    • 数据到来是便被处理,不是收集然后处理,即在输入被完全消费之前,输出便产生了。
    • **管道是将数据从一个过滤器的输出端移动到另一个过滤器的输入端,是一个单向流。**不同的管道中流动的数据流,可能具有不同的数据格式。
    应用示例

    编译器、Unix管道、图像处理,信号处理,声音与图像处理

    优点和缺点

    优点

    • 良好的隐蔽性和高内聚、低耦合:可以将整个系统的输入输出行为看成多个过滤器功能的简单合成
    • 支持功能模块的重用:任意两个过滤器只要相互间所传输的数据格式上达成一致,就可以连接在一起
    • 系统容易维护和拓展:新的过滤器容易加入到系统中,旧的过滤器也可被改进的过滤器替换
    • 允许对一些如吞吐量,死锁 等属性进行分析
    • 支持并行执行:每一个过滤器既可以独立运行,也可与其他过滤器并发执行。

    缺点:

    • 不适合处理交互的应用
    • 系统性能不高,并增加了编写过滤器的复杂性:数据传输缺乏通用标准,每个过滤器绝大部分时间消耗在数据格式的解析,转换,合成上。同样也不适用于大量共享数据的应用设置。

    调用-返回风格

    主程序/子程序风格

    在这里插入图片描述

    组件和连接件

    组件:过程和明确可见的数据

    连接件:过程调用和显式的共享数据

    控制结构:单线程

    特点

    调用和定义层次结构,子系统通常通过模块化来定义。

    系统通常会被组织成一个主程序和一系列子程序的集合。主程序担当子程序的驱动器,为子程序提供一个人控制环路,使子程序以某种次序顺序执行。

    ADT & OO

    在这里插入图片描述

    组件和连接件

    组件:对象(抽象数据类型的实例)

    连接件:过程调用

    特点

    在基于面向对象的模式中,操作和数据绑定在一起,隐藏实现和其他秘密。对象通过过程调用来实现交互。有两个重要方面:

    • 对象维护自身表示的完整性
    • 这种表示对其他对象是隐藏的
    优点和缺点

    优点:

    • 面向对象易维护,易复用
    • 对象反映现实世界,容易分解一个系统
    • 对象对客户实现了隐藏细节,所有可以在不影响其客户的情况下改变对象的实现 。

    缺点:

    • 对象的管理比较复杂,当一个对象和其他对象交互,必须知道其他对象的标识。每当一个对象的标识改变的时候,必须修改那些显示调用它的对象。

    分层系统

    在这里插入图片描述

    组件和连接件

    组件: 在某些层中实现虚拟机

    连接件: 协议, 规定了层次之间的交互方式

    拓扑结构: 限制相邻层之间的交互

    特点
    • 一个分成系统是按照层次结构组织的,每一层向它的上层提供服务,同时它又是下层的客户。
    • 上层必须知道下层的身份,不能调整层次之间的顺序。
    • 大的问题分解成若干渐进的小问题,逐步解决,隐藏了很多复杂度。
    • 内层只对其相邻的层和某些用于输出的函数是可见的,对其他外部的层是隐藏的
    • 修改一层,最多影响两层, 通常只会影响上层。若层之间接口稳固,则不会造成其他影响
    • 层层相调,影响性能。
    优点和缺点

    优点:

    • 支持基于逐级抽象的系统设计,这允许设计者将一个复杂的问题分解成一系列递增的步骤。
    • 支持扩展,由于分层系统每一层最多和上下两层交互,对于任意一层功能的交互最多只影响其他两层。
    • 支持重用,如果能保证为相邻的层提供一致的接口,他允许系统中同一层的不同实现相互交换使用。(即给同一接口建立不同实现

    缺点

    • 定义一个合适的抽象层次可能会非常困难。比如,实际的通信协议体就很难映射到ISO框架中,因为其中许多协议跨多个层

    客户端/服务器风格

    在这里插入图片描述

    两层C/S架构
    特点

    服务器(后台)负责数据管理,客户机(前台)完成与用户的交互任务。“胖客户机,瘦服务器”

    缺点

    – 对客户端软硬件配置要求较高,客户端臃肿
    客户端程序设计复杂
    数据安全性不好。客户端程序可以直接访问数据库服务器。
    – 信息内容和形式单一
    – 用户界面风格不一,使用繁杂,不利用推广使用
    软件维护与升级困难。每个客户机上的软件都需要维护

    三层C/S架构

    二层C/S结构相比,增加了一个应用服务器

    应用功能分为表示层、功能层、数据层三层。

    表示层是应用的用户接口部分。通常使用图形用户界面
    功能层是应用的主体,实现具体的业务处理逻辑
    数据层数据库管理系统
    – 以上三层逻辑上独立

    整个应用逻辑驻留在应用服务器上,只有表示层存在于客户机上:“瘦客户机”

    浏览器/服务器风格

    B/S架构

    B/S体系结构是三层C/S体系结构的特例,客户端有http浏览器即可

    只能“拉”,不能“推”
    • 客户之间的通信只能通过服务器中转
    • 对客户机资源和其他网络资源的利用受限
    • B/S结构的安全性较难控制(SQL注入攻击…)
    • B/S结构的应用系统在
    数据查询等相应速度
    上,要远远低于C/S体系结构
    服务器的负荷大,客户机的资源浪费

    数据为中心的体系结构风格

    定义

    Data-centered style architectures involve a shared
    data source approach to information passing.

    以数据为中心的风格架构涉及到信息传递的共享数据源方法。

    典例: 注册表 剪切板

    仓库体系结构风格

    仓库是存储和维护数据的中心场所。

    组件: 中心数据结构,表示当前数据的状态

    连接件:仓库与独立构件之间的交互

    应用场合:数据库、仓库形式的编译器结构、仓库形式的编译器结构
    在这里插入图片描述

    黑板体系结构风格

    在这里插入图片描述
    在这里插入图片描述

    事件系统体系结构风格

    在这里插入图片描述

    主要特点

    ✓ 事件的触发者并不知道哪些构件会被这些事件影响,相互保持独立。
    ✓ 不能假定构件的处理顺序,甚至不知道哪些过程会被调用。
    ✓ 各个构件之间彼此之间无连接关系,各自独立存在,通过对事件的发布和注册实现关联。

    在这里插入图片描述

    A component(Event Source) can annonce (or broadcast) one or more events. 一个组件可以广播一些事件。
    Other components(Event Handlers) in the system can register an interest in an event by associating a procedure with it. 系统中的其它构件可以注册自己感兴趣的事件,并将自己的某个过程与相应的事件进行关联。
    When the event is announced the system (Event Manager) itself invokes all of the procedures that have been registered for the event. 当一个事件被发布,系统自动调用在该事件中注册的所有过程。

    应用示例

    调试器中的断点处理

    在这里插入图片描述

    Event Source:debugger (调试器)
    Event Handler:editor and variable monitor (编辑器与变量监视器)
    Event Manager:IDE (集成开发环境)

    ✓ 编辑器与变量监视器向调试器注册,接收“断点事件”;
    ✓ 遇到断点,调试器发布事件,从而触发“编辑器”与“变量监测器”
    ✓ 编辑器将源代码滚动到断点处;
    ✓ 变量监测器则更新当前变量值并显示出来。

    美团平台

    在这里插入图片描述

    事件系统派遣机制

    在这里插入图片描述

    无独立调度模块的事件系统

    This module is usually called Observable/Observer (被观察者/观察者).

    Each module allows other modules to declare interest in events that they are sending. (每一个模块都允许其他模块向自己所能发送的某些消息表明兴趣)

    Whenever a module sends an event, it sends that event toexactly those modules that registered interest in that event.

    (当某一模块发出某一事件时,它自动将这些事件发布给那些曾经向自己注册过此事件的模块)
    在这里插入图片描述

    有独立事件派遣模块的事件系统

    事件派遣模块是负责接收到来的事件并派遣它们到其它模块。

    全广播式(All broadcasting) :派遣模块将事件广播到所有的模块,但只有感兴趣的模块才去取出事件并触发自身的行为;
    选择广播式(Selected broadcasting) :派遣模块将事件送到那些已经注册的模块中。

    在这里插入图片描述
    在这里插入图片描述

    选择广播式的两种策略:基于事件被执行的方式

    Point-to-Point (message queue)(点对点模式:基于消息队列)

    Publish-Subscribe(发布-订阅模式)

    在这里插入图片描述

    在这里插入图片描述

    软件体系结构描述

    文档建立的原则

    ◆ 1.从读者的角度写。
    ◆ 2.避免不必要的重复。
    ◆ 3.避免歧义。
    ◆ 4.使用标准组织结构。
    ◆ 5.记录理由。
    ◆ 6.保持文档时效性但不是频繁更新(有限的稳定性)。
    ◆ 7.审查文档是否符合需求

    软件体系结构建模

    在这里插入图片描述

    “4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图
    来描述软件体系结构。每一个视图只关心系统的一个侧面,只有5个视图结合在一起才能反映系统的软件体系结构的全部内容。

    用例视图 (场景)
    ◼ 从外部世界的角度描述正在建模的系统的功能。
    ◼ 需要使用此视图来描述系统应该执行的操作。 所有
    其他视图都依靠用例视图(场景)来指导它们,这
    就是将模型称为4 + 1的原因。
    ◼ 该视图通常包含用例图,描述和概述图。

    用例图

    在这里插入图片描述

    理解系统功能需求,系统提供的功能的描述。

    用于显示若干角色以及这些角色与系统提供的用例之间的连接关系。

    重要的是记住用例代表了系统的外部视图。因此,不要期望用例与系统内部的类之间存在任何关联。

    逻辑视图
    ◼ 描述系统各部分的抽象描述。用于建模系统的组成部分以及各组成部分之间的交互方式。
    ◼ 通常包括类图,对象图,状态图和协作图。

    类图

    在这里插入图片描述
    类图表示系统中的类和类与类之间的关系,它是对系统静态结构的描述。

    对象图

    在这里插入图片描述
    对象图是某个时间点系统中对象的快照,因为它显示的是实例而不是类,所以通常称为实例图。

    状态图

    在这里插入图片描述
    状态图是描述类的对象所有可能的状态以及事件发生时状态的转移条件。

    协作图

    在这里插入图片描述
    协作图是一种交互图,强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象及对象之间的联系以及对象间发送和接收的消息。

    过程视图
    ◼ 描述系统中的进程。 当 可视化系统中一定会发生的事情时,此视图特别有用。
    ◼ 该视图通常包含活动图。

    活动图

    在这里插入图片描述
    描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动

    开发视图
    ◼ 描述系统的各部分如何被组织为模块和组件。管理系统体系结构中的层非常有用。
    ◼ 该视图通常包含包图和组件图。

    包图

    在这里插入图片描述
    包是在UML中用类似于文件夹的符号表示的模型元素的组合,允许从UML中获取任何结构,并将其元素分组到更高级别的单元中。

    组件图

    在这里插入图片描述
    组件图描述代码构件的物理结构及各构件之间的依赖关系。将系统划分为组件并希望通过接口或组件细分为较低级别的结构来显示其相互关系

    物理视图
    ◼ 描述如何将前三个视图中所述的系统设计实现为一组现实世界的实体。该视图中的图表展示了抽象部分如何映射到最终部署的系统中。
    ◼ 该视图通常包含部署图。

    部署图

    在这里插入图片描述
    部署图定义系统中软硬件的物理体系结构。描述了一个运行时的硬件结点,以及在这些结点上运行的软件组件的静态视图。 显示了系统的硬件,安装在硬件上的软件,以及用于连接异构的机器之间的中间件。

    质量属性场景

    六个组成部分

    ➢ 刺激源(source):谁造成的刺激
    ➢ 刺激(stimulus):一个影响系统的情况
    ➢ 制品(artifact):系统被影响的部分
    ➢ 环境(environment):刺激发生时系统所处的状态
    ➢ 响应(response):刺激所产生的结果
    ➢ 响应衡量指标(response measure):如何评估响应

    生活案例在这里插入图片描述

    可用性

    关注点

    ✓ 是否发生了故障(无法提供正常的服务,被外界发现)
    ✓ 故障的后果

    衡量指标

    ✓ 可用(或故障)时间百分比
    ✓ 修复故障所需的时间
    ✓ 平均无故障时间
    在这里插入图片描述

    刺激源
    ✓ 故障的迹象(来自内部或外部)
    刺激
    ✓ 系统出错
    ✓ 系统崩溃(反复出错)
    ✓ 给出结果不准时(早或晚)
    ✓ 给出错误结果

    制品
    ✓ 计算 or 存储 or 网络传输
    环境
    ✓ 正常状态 or “亚健康”状态

    响应
    ✓ 记录日志(错误报告),回传给厂家
    ✓ 通知管理员或其他系统
    ✓ 关闭系统,系统在维修期间不可用
    响应衡量指标
    ✓ 故障时间百分比、修复故障所需时间、平均无故障时间……

    提升可用性的策略

    ➢ 方向1:故障检测

    • Ping/echo

    监控组件不定期向被监控组件发出ping消息,并根据收到的echo消息(是否收到、延时)做出响应

    • Heartbeat(心跳)

    被监控组件定期向监控组件发出心跳消息
    在节点间保持周期性的心跳信号以检测各个节点的状态。若连续未收到的心跳信号到了一定的数目,就认为相应的系统已经出现故障。

    • Exceptions(异常)

    抛出 + 捕获 + 处理
    需要编程语言支持

    ➢ 方向2:故障恢复

    • 投票

      1. 多个冗余的组件,用统一或不同的算法来完成同一个任务。如果计算结

      果不同,则少数服从多数

      1. 为降低同时出错的概率,多个组件可以由不同的开发团队在不同的软、

      硬件平台上开发

    • 主动冗余

      1. A、B服务器完成同样的运算(A和B的状态时刻保持一致),平时只取

      A算出的结果

      1. 当A出现故障时,系统可以极快地切换到B
    • 被动冗余

      1. A服务器完成运算后的一定时间内把自身状态告知B,B再把自身状态更

      新为A的状态。

      1. 当A出现故障时,首先需要确认B的状态是最新的.
    • 内测

      开发人员修正bug,并在内部进行测试,确认无误后再发布补丁

    • 检查点/回滚

      定期保存,便于恢复

    ➢ 方向3:故障避免

    • 服务下线
      1. 惹不起,躲得起
      2. 如果明确知道即将遭到毁灭性攻击,不如主动下线
    • 事务
      1. 多个操作必须全部完成(银行转账)
    • 进程监控
      1. Windows任务管理器

    可修改性

    关注点

    ✓修改的成本
    ✓系统的哪些部分被修改
    ✓修改发生的时间
    ✓修改由谁来进行
    在这里插入图片描述

    提升可修改性策略

    目标:降低修改的时间和成本

    限制修改范围:让修改所影响的软件范围尽可能的小

    • 模块高内聚、低耦合:尽量把对程序的修改控制在一个模块内,可以借助框架、中间件

    • 考虑到可能会发生的修改

    ➢有助于评估模块间责任的划分
    ➢ 让一个点的修改只影响一个模块
    ➢ 避免完全无关的多个修改会影响同一个模块

    • 让模块通用:“解释器”风格的思路

    • 隐藏信息:面向对象机制中的可访问性(public/private)

    • 维持接口不变:在接口不变的情况下,接口连接的双方可以独立变化

    • 限制通信路径:设计模式中的Façade模式

    • 使用中介

    ➢ 数据中介:共享数据的风格
    ➢ 服务中介:设计模式中的bridge、factory method等模式

    • 命名服务器(name server):查询所需资源 / 对象的位置,解决位置依赖

    • 按需创建实例:借助设计模式中的创建型模式

    延迟绑定时间:让软件在运行期间仍可进行灵活修改

    • 配置文件:修改配置文件,而不用修改代码

    • 发布-订阅模式

    ➢ 软件体系风格部分已有介绍(事件系统)
    ➢ 设计模式中的“观察者模式”

    • 多态:用不同的子类,实现不同的功能

    性能

    关注点

    ✓ 系统响应事件的速度

    ✓ 和事件的数量和到达模式有关

    响应衡量指标

    ✓ 处理事件所花的时间
    ✓ 单位时间内处理事件的数目
    ✓ 处理的错误率/丢失率
    在这里插入图片描述

    提升性能的策略

    方向1:资源的需求

    1. 在要处理的数据量不变的情况下,提高计算效率

    ➢ 使用更高效率的算法
    ➢ 减少处理事件时对资源的占用

    1. 减少要处理的数据总量

    ➢ 控制事件到来的速率
    ➢ 只抽取一部分请求来处理

    1. 限制执行时间

    ➢ 在规定时间内得到近似解

    1. 限制待处理事件队列长度

    ➢ 直接放弃处理一部分事件

    方向2:资源的管理

    利用并发机制:多线程、多进程、多核、多机……

    增加可用资源: 计算资源、存储资源、带宽资源……

    方向3:资源的仲裁

    ➢ 先来先服务
    ➢ 固定优先级调度

    ➢ 动态优先级

    安全性

    关注点

    ✓ 在保证合法用户使用系统的前提下,抵抗对系统的攻击

    提升安全性的策略
    在这里插入图片描述
    方向1:抵抗攻击

    1. 用户的证实:密码、验证码、生物识别……
    2. 用户的授权: 确认用户的操作是在其权限范围
    3. 维持数据的保密性:给数据和传输过程加密
    4. 维持数据的完整性:MD5码校验
    5. 减少暴露:关闭无用端口、自启动的服务、无线路由SSID等
    6. 限制访问:白名单、黑名单

    方向2:检测攻击

    软件和人结合:入侵检测系统、安全专家

    方向3:从攻击中恢复

    恢复状态:使用“可用性”中的相关策略

    攻击者的识别:也能震慑潜在的攻击者

    可测试性

    关注点

    ✓ 让软件的bug容易被测试出来
    ✓ 验证软件产品与它的需求规格是否匹配(存在不符或缺失)
    ✓ 使用最小的成本和工作量来验证软件的质量
    在这里插入图片描述

    提升可测试性的策略

    黑盒测试

    记录 / 回放: 自动化/半自动化测试
    把接口和实现分离开:不同的排序算法,使用相同的接口

    提供专用的测试路径

    白盒测试

    内部监控:IDE提供的断点等调试工具、WinDbg等工具

    Appium(APP UI测试)

    Selenium(Web UI测试)

    JMeter(接口测试、性能测试)

    易用性

    关注点

    ✓ 让用户使用软件的难度降低
    在这里插入图片描述

    提升易用性的策略

    方向1:运行时策略

    1. 系统猜测用户要完成的任务:输入法联想、搜索引擎联想
    2. 系统给用户适当的反馈:提示拷贝文件所需的剩余时间、浏览器打开页面的进度
    3. 系统给用户提供一致的体验:鼠标提供DPI调整,适应不同的分辨率
    4. 支持撤销操作:减少误操作的影响

    方向2:设计时策略

    把用户界面和系统其它部分隔离开:MVC模式,支持用户界面的独立修改(甚至用户可以自行修改用户界面)

    体系结构评估ATAM(Architecture Trade-off Analysis Method )

    utility tree

    在这里插入图片描述

    效用是树的根结点,代表系统的整体质量。质量属性构成树的二级节点。在每个质量属性下对该质量属性做了进一步的说明。所设置的优先级是用高(H)、中(M)、低(L)的形式。

    (M,L)优先级解释

    • 第一个字母代表:每个场景对系统成功的重要影响程度
    • 第二个字母代表:体系结构设计师所估计的实现这种场景的难度

    risks, non-risks, sensitivity points, and tradeoffs

    sensitivity points

    A sensitivity point is a property of one or more components (and/or component relationships) that is critical for achieving a particular quality attribute response.
    “The level of confidentiality in a virtual private network might be sensitive to the number of bits of encryption. ”

    敏感点是一个或多个组件(和/或组件关系)的属性,对于实现特定的质量属性响应至关重要。

    e.g. 虚拟专用网络的保密级别可能对加密的位数很敏感。

    tradeoff

    A tradeoff point is a property that affects more than one attribute and is a sensitivity point for more than one attribute.
    “Changing the level of encryption could have a significant impact on both security and performance.”

    权衡点是影响多个属性和的属性,是多个属性的敏感点。

    e.g.“改变加密级别可能会对安全性和性能产生重大影响。

    risks

    A risk is a potentially problematic architectural decision.
    “The level of confidentiality in a virtual private network might be sensitive to the number of bits of encryption. ”

    风险是一个潜在的有问题的架构决策。

    e.g.“虚拟专用网络的机密程度可能对加密的比特数很敏感。”

    non-risks

    Non-risks are good architectural decisions that are deemed safe upon
    analysis.
    “Assuming message arrival rates of once per second, a processing
    time of less than 30 ms, and the existence of one higher priority
    process, a 1 second soft deadline seems reasonable.”

    无风险是被认为是安全的良好架构决策分析。

    e.g.假定消息的到达速率是每秒一次,一次处理的时间小于30ms。如果对一个更高优先级的处理的响应时间要求是1秒钟,此系统可行

    期末考试

    客观题(30分)

    两道简答题(5*2 = 10)

    1. 什么是软件体系结构?
    2. 描述“虚拟机风格”体系结构,并举出一个典型例子

    十道选择题(2*10 = 20)

    1. 六种质量属性的提升策略

    2. 看图片中所给的是哪种体系结构风格

    3. UML各种图的功能和结构

    三道大题(70分)

    1. 场景题:
      • 涉及到什么质量属性
      • 画出每一种质量属性的场景(六要素:刺激源,刺激,制品,环境,响应,响应衡量指标)
      • 针对每种质量属性,至少写出两种提升策略
      • 该系统最适合用什么体系结构风格,说明原因,并阐述该种体系风格的优点和缺点
    2. 画效应树
    3. 写风险点,非风险点,敏感点,权衡点的概念,并将下面的陈述句归类到这四种里。

    刚考完试,发波笔记攒人品,过过过! 2020/8/18

    参考

    《软件体系结构》 Mary Shaw David garlan著

    课件

    展开全文
  • 数据分析-如何搭建业务指标体系

    千次阅读 2019-04-14 21:23:24
    转自数极客简述文章,感谢作者! 如何搭建指标体系 ...因此,搭建系统的指标体系,才能全面衡量业务发展情况,促进业务有序增长。 二)明确结果型指标和过程型指标的关系 完整的指标体系,能够帮...

    转自数极客简述文章,感谢作者!

     

    如何搭建指标体系

    一、为什么要搭建指标体系

    一)对业务质量提出衡量标准

    没有指标对业务进行系统衡量,我们就无法把控业务发展,无法对业务质量进行衡量,尤其现在很多企业多项业务并行,单一数据指标衡量很可能片面化。因此,搭建系统的指标体系,才能全面衡量业务发展情况,促进业务有序增长。

     

    二)明确结果型指标和过程型指标的关系

    完整的指标体系,能够帮我们明确结果型指标和过程型指标的关系。不仅能分析结果,更能分析过程。通过结果指标回溯到和用户行为相关的过程指标,找到解决问题的核心原因。如结果型指标转化率,但影响它的多为浏览行为、停留时间等过程型指标,通过指标体系,能清晰明确转化率和和浏览次数、停留时间的关联关系。

    三)指导内部产品、营销、运营的工作

    产品、营销、运营等部门都是促进公司发展的重要组成部分,通过完成的指标体系和数据分析,可以有效指导各部门成员的工作,以数据驱动,找到不足,提升业绩。

     

    四)指导数据采集

    完善的指标体系可以让采集更有目的性,避免分析时的指标数据遗漏或缺失。虽然我们有些数据分析软件可以对数据缺失值进行处理,但如果连指标都没有,这种缺失肯定是软件无法处理的,尤其是关键指标的缺失,将会造成分析结果的可信度下降。

     

     

    二、如何搭建指标体系

    一)指标类型

    指标类型可以按照多种标准划分:

    1.按计算方法,分为单一指标和复合指标(由单一指标通过加、减、乘、除四则运算生成),如浏览人数和注册转化率

    2.按指标的正负意义,可分为正向指标(如转化率、购买率,越高越好)和负向指标(如跳出率、错误率,越低越好)

    3.按业务范围,可分为行为指标如浏览次数、关键事件次数、转化率等;成本指标新访客成本、CPC、CPM等;营收指标客单价、重复购买率、ROI等

    一个完整的指标体系会包含多种类型的指标。

     

    二)确定OMTM

    OMTM:唯一关键指标(one metric that matters, OMTM).在数据分析时,可以抓取许许多多的数据,但必须聚焦在最关键的事情上。根据分析目的,只关注驱动的核心,唯一关键指标,根据OMTM搭建指标体系。

    这里我们需要提一下选择OMTM指标遵循的三个“好指标原则”

    好指标一定是可比较、可理解并且是会可指导的。

    围绕这三个原则确定OMTM。

     

    三)为什么OMTM是驱动的核心?

    聚焦OMTM让你和整个团队集中力量解决重要且紧急的问题,并进行“假设-验证”的精益实验。

    首先,会帮你弄清楚当前最重要的问题,然后强制你拟定一个清晰明确的目标,接下来整个团队都会充分聚焦,围绕核心问题打好关键战役。且OMTM会更有利于执行“假设-验证”的精益实验。

    四)分析影响指标的关键因素

    我们最常关注的指标多为最终结果指标,比如评估一个电商平台,我们最关注的是销售额(常被称为虚荣指标或表面指标),在业务人员分析销售额增长或下降的原因时,就需要对指标进行拆分,找到影响指标的最小因素,即明确指标。

    虚荣指标是表面指标。它们往往比较大而泛,可以给人留下印象,比如销售额。可以用这些指标来谋求建立合作关系并赢得一些关注。

    明确指标是运营性指标,比如产品每日实际使用时长,用户访问服务所需时长等。这些是推动增长的隐形引擎。要用这些指标来巩固你的竞争优势。

     

    五)杜邦拆解-最小可优化单元

    杜邦拆解:基本思想是将核心指标逐级分解为多项指标,直至最小可优化单元,这样有助于深入分析比较。

    我们以电商销售额为例,从两个角度进行拆解,一个是购买用户量,一个是单客户销售额。先看购买用户量,它可以拆解为下单用户*购买转化率,下单用户等于加入购物车用户*订单转化率,这样一层一层向下拆分。

    六)指标体系的构成

    指标体系由指标+维度构成,事件、参数、属性配置完成后,形成相应指标体系,可针对唯一关键指标OMTM按多个维度多个时间进行多维细分分析。

    数极客提供9大行业指标体系搭建模板,感兴趣的同学可以扫描文章底部的微信领取。

     

    三、数据采集和验证

    一)数据采集

    数极采集一般有三种方式,代码埋点、可视化埋点和后端埋点。

    代码埋点可以采集任意业务指标、维度丰富,但需由技术人员完成代码部署。

    可视化埋点操作简单,直接点选完成,可视化埋点适合单一指标,不能采集维度数据。

    后端埋点可将前端数据和后端系统数据融合统计,对接更多数据源,但需技术深度参与。

    我们在进行数据采集时要根据不同指标选择最适合的采集方式。

    下面看下每种采集方式都是怎么完成的。

     

    1.可视化埋点

    可视化埋点的优点是操作方便、效率高,缺点是数据类型单一。

    可视化埋点通过数极客分析系统进入埋点编辑页面,用鼠标点击想要埋点的按钮,出现数据柱形图后命名保存即可。

    2.代码埋点

    代码埋点的优点是数据丰富,精准性高,缺点是步骤较多、需技术参与。

    代码埋点需要先在后台配置事件和属性,一键生成统计代码,由技术人员添加到埋点位置。

    3.后端埋点

    后端埋点的优点是可前后端数据融合,缺点是对技术要求较高,普通运营人员无法实现。

    后端埋点和代码埋点相似,在配置事件和属性后,截取已有代码中的关键元素,按后端代码统计格式生成新的代码后部署埋点。

    我们提到在代码埋点和后端埋点时,需要先配置事件和属性。

     

    事件、参数和属性说明:

    先给大家解释三个概念,事件、参数和属性。

    事件可以理解为用户的某个行为,比如登录、注册、购买,都统称为事件;

    事件和参数结合起来就是指标,比如登录次数、注册人数、购买金额这些我们称为指标,而次数、人数、金额就是事件的参数。

    事件属性可以从某个维度对事件进行拆分分析,比如登录方式就是登录的属性,分析不同登录方式的登录次数。

     

    首先看下如何创建事件,在后台进入自定义设置-事件界面,添加事件字段后保存即可。

    重要的是创建事件时各字段的含义和填写方法,很多客户在这一步较为迷惑,不知如何填写。

    事件方法:事件名称的英文翻译,如登录的英文login

    事件名称:表示用户的具体行为,如登录

    事件类型:统一全部选为“自定义事件”

     

    事件参数(和事件一起构成指标)

    参数名称:指标名称的英文翻译

    指标名称:如金额(人数、次数、用户数系统自动统计,无需添加,如无特定的参数,就把指标名称写为事件,参数名称对应event)

    计算:对参数的计算方法。数值型进行求和,如金额,最后显示的的累加和;字符型为计数计算,最后累计个数。

     

     

    属性在创建时,分为两块儿,用户属性和事件属性,每一块儿独立的创建,互不影响。

     

    先说用户属性,也叫全局属性,用来描述用户的属性体征,可理解为用户的一个标签,无需和某一事件绑定,可以对全部事件进行拆分。

    事件属性可以从某个维度对这个属性进行拆分分析,需和某一事件对应绑定,对绑定的事件事件进行拆分分析。

    事件属性参数名:为事件属性名称的英文翻译

    事件属性名称:和事件相对应,如登录方式

    所属事件:属性所对应的事件,可一对一,也可一对多;如登录方式只对应登录,而商品名称可能对应浏览商品、加入购物车、购买成功等事件。

    事件属性添加好后,会在维度-事件属性下显示:

     

    二)数据验证

    数据采集后一定要对数据进行验证,准确性、完整性、及时性都是必须考虑的,缺失的不准确的数据我们无法应用于实际分析,这也是我们在选择适合的采集方法应评估的重要因素。

     

    四、数据应用

    一)驱动闭环

    搭建指标体系后的最后一步就是数据应用,在采集的数据验证无误后应用于实际业务中,驱动业务增长。

     

    二)应用举例

    下面给大家举两个数据应用的例子,

    第一个偏重于体系搭建,第二个偏重于业务分析。

    1.案例一:推广成本优化

     

    当前各种推广渠道层出不容,那如何分析推广渠道,优化推广成本?

    首先确定渠道的质量指标和数量指标,如下图中各渠道的人数、次数指标我们归为数量指标,其余指标为质量指标,然后按照五个维度对渠道拆分分析。

    把所有渠道按质量指标和数量指标生成散点图,按照质量高低、流量大小的划分标准分为四象限(即我们常用的四象限分析法)。

    找到不同渠道对应的位置,按照策略优化即可。

    2.案例二:注册转化率的优化

     

    某电商平台APP端,新访客注册转化率为20%左右,某日该指标出现异常数据2.81% ,如何通过数据分析解决注册转化率降低的问题?

    首先确定OMTM指标

    注册转化率:新访客注册人数/新用户数

    新访客数、新访客注册人数 通过数极客采集

    分析思路:

    用户从访问到注册有一定的操作路径,一般分为:浏览页面、开始注册、获取验证码、注册成功几个步骤。注册转化率突然降低,用户一定是在操作路径的某一步流失掉了。这时可以设计基于以上操作的路径漏斗,查看每一步的转化率。

    分析结果:

    按照时间维度对比漏斗发现,转化在前三个环节和前一天差别不大,只在获取验证码到注册成功环节转化率相差很多,按照以上步骤进行测试,发现在发送短信验证码出现问题,很多点击收不到验证码,马上和运营商取得联系及时解决问题。

    视频课件地址:http://v.qq.com/x/page/j0646w8ovlx.html

     

    展开全文
  • 网站数据分析指标体系

    千次阅读 2017-08-27 12:26:17
    本文整理自网友分享的一份 Word 文档,主要介绍了网站分析的 KPI 指标、数据分析方法、网站分析工具介绍和对比等。 一、总论 1. 概念  网站流量统计,是指对网站访问的相关指标进行统计。网站访问分析...
  • 衡量区块链性能的关键指标包括:1) 区块链节点指标(生产的区块数,已处理的交易数,处理时间,完成时间等) 2) P2P 子系统指标(命中 / 未命中请求的数量,活跃用户的数量,P2P 流量的数量和结构等) 3) 系统...
  • 软件体系结构复习

    千次阅读 2017-06-27 14:54:07
    第一章 软件危机的表现: 1、软件成本日益增长 2、开发进度难以控制 3、软件质量差 4、软件维护困难 ...软件危机的原因: ...要提高软件开发效率,提高软件产品质量,必须采用工程化的开发方法与
  • 本文首先介绍了衡量计算机的三个重要指标,分别是性能、价格与功耗,随后分别从这 三个角度入手,介绍了各个指标的定义、意义与评价方法,最后从整机性能的角度出发,讲解了计 算机体系结构的性能评价标准,并补充了...
  • 指标是量化衡量标准、衡量目标的单位或方法,例如对电商数据分析来说,最常见的指标就是UV和PV,而针对APP来说,最常见的就是DAU,MAU。 有了指标也就知道应该从哪些角度入手开始数据分析,数据驱动已经是我们在做...
  • 软件研发管理体系建设

    千次阅读 2019-09-11 23:30:51
    最近一段时间,我一直在反复思考一个问题:我们的软件研发管理体系应该是怎样的?...本Chat讨论的软件研发管理体系建设主要包括以下内容: 1、对软件研发管理体系的一些概念认知 2、什么样的软件研发管理...
  • 如何将软件质量进行定量度量,目前已经有很多成熟理论。  (1) McCall软件质量模型    McCall等认为,特性是软件质量的反映,软件属性可用做评价准则,定量化地度量软件属性可知软件质量的优劣。  提出了...
  • 软件体系结构

    万次阅读 2013-06-18 00:50:25
    架构定义:某个软件或计算系统的软件构架是该系统的一个或多个结构,它由软件元素、这些元素的外部可见属性以及这些元素之间的关系组成。 2.含义: •首先,构架定义了软件元素。构架必须省略元素中与其交互无关的...
  • 软件测试度量指标

    千次阅读 2010-07-30 09:32:00
    在CMMI体系的测试过程中定义了四个度量指标:测试覆盖率、测试执行率、测试执行通过率、测试缺陷解决率。为了使专/兼职测试人员理解这四个度量指标,了解如何利用现有资源收集度量数据,本文介绍这四个指标的含义及...
  • 近期由于工作需要,重新把以前丢掉的IT服务管理的报表体系指标体系捡起来想了想,原来有过一个想法根据指标去设计一个服务管理系统,后面各种原因未能成行。现在的管理软件越来越多,越来越复杂,也越来越灵活,但...
  • 浅谈软件研发管理体系建设

    万次阅读 多人点赞 2018-12-08 21:40:52
    最近一段时间,我一直在反复思考一个问题:我们的软件研发管理体系应该是怎样的?在不断思考的过程中,逐步有一些粗浅的认识,在此将这些认识记录成文字,并期待能够与更多的伙伴碰撞,进一步完善这种认识,并逐步...
  • 7.1.1 评估关注的质量属性 软件体系结构的设计是整个软件开发过程中关键的一步。对于当今世界上庞大而复杂的系统来说,如果没有一个合适的体系结构而要有一个成功的软件设计几乎是不可想象的。 不同类型的系统需要...
  • 数据埋点前,你需要搭建指标体系

    千次阅读 2019-07-02 15:51:57
    指标是量化衡量标准、衡量目标的单位或方法,Web、APP、小程序上的指标分为: 类型说明用户级指标以用户进行分类,包含用户数量,触发某事件的用户数量等访问级指标以访问进行分类,包含访问量,访问次数,访问时...
  • 软件构件技术和软件体系结构 1[单项选择题]( )不是活动历时估算依据。 A项目范围说明书 B活动资源需求 C组织过程资产 D项目进度计划 【参考答案】D 【题目解析】活动历时估算的依据有:活动清单、活动清单属性、...
  • 经典软件架构指标

    千次阅读 2020-08-30 22:49:25
    性能具有以下指标: 延迟 :表示获得响应之前经过的时间间隔。 吞吐量:是指在固定时间间隔内获得的响应数。 可用容量:以上度量的结合体。 可调度的利用率:利用率是资源繁忙时间的百分比,而可调度的利用率是满足...
  • 软件体系结构复习整理

    千次阅读 2018-11-06 23:18:39
    一、 认识软件架构 本书的主旨: 阐明企业目标、产品需求、设计师的经验、构架和最终系统之间的关系——它们构成带有回路的、可由开发组织实施管理的周期 架构商业周期(ABC): 软件架构是技术、商业和社会等诸多...
  • 防火墙主要参考以下3种性能指标: 整机吞吐量:指防火墙在状态检测机制下...该指标主要用来衡量防火墙在处理过程中对报文连接的处理速度,如果该指标低会造成用户明显感觉上网速度慢,在用户量较大的情况下容易造成防
  • 基于AARRR模型的抖音基本指标体系 抖音APP实质上还是属于一个免费的移动短视频应用,针对抖音获取新用户这方面,我们需要关注的指标主要还是从下载量(分渠道),客户获取成本,新用户注册等 如果监控用户活跃,我们...
  • 1.软件质量 质量:质量是一个实体的所有特性,基于这些特性可以满足明显或者隐含的需求,而质量就是实体基于这些特征满足需求的程度。 软件质量的三个层次 符合需求规格(RS):符合开发者明确定义的目标,即产品...
  • 软件体系结构 的笔记 怎么写 应该 哦 原来,表哥是这么写的,牛逼啊 大佛普拉斯 的故乡是泰国 首先 其次 最后 升华 这里是来自伟大程序员江旭晖同志的光荣与梦想!!!奥里给,兄弟们! ...
  • 系统可用性衡量指标MTTR|MTTF|MTBF

    万次阅读 2015-09-04 18:00:46
    MTTR、MTTF、MTBF是体现系统可靠性的重要指标,但是三者容易混淆,下文使用图解方式解释三者之间的区别,希望能起到解惑的效用。 MTTF (Mean Time To Failure,平均无故障时间),指系统无故障运行的平均时间,取...
  • 来源:简书转自:中国统计网我会从构建数据指标体系、数据分析方法两部分来总结自己学到的一些知识。首先从构建数据指标体系说起,一个成熟项目的指标体系往往经过前人的构建和完善后,已经非常成熟,...
  • 指标体系的设计是一个业务数据化的过程。好的指标设计能够抽象目标具体化,具有直接实践意义。 1)什么是指标 通常我们讲述的指标是指将业务单元精分后量化的度量值,譬如:DAU、订单数、金额等。当然,原子指标还...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,150
精华内容 4,860
关键字:

衡量软件体系主要指标