Arthur's Blog

无论是对产品、运营还是设计来说，理解用户需求是关键的一步也是最重要的一步。而关于如何理解用户需求的文章不少，读过后你是否能真正理解呢？还是似懂非懂，但到了落地环节又不知道如何入手？如果你又这样的遭遇与疑惑，那么本文会告诉你一些实操性更强的理解方法。

一、为什么要理解“用户需求”

对产品经理、设计师、互联网从业人员来说，用户需求的重要性毋庸置疑。

但在我过往的经历中，遇到过一些营销、运营以及其他职能人员，他们做事情的出发点更多是靠自己的经验或者看竞品在做什么，而不是先考虑目标用户是什么样的人，有什么样的功能和情感需求，应该如何打动他们。

很多时候他们只是在复制自己或别人过往的套路，这样虽然思考成本低而且快，但是做跟风者，上限总是有限的。

用户需求其实是个挺玄的词。很多专业人士即使态度上重视用户需求，但是也会被一些因素误导或者自己在挖掘用户需求时犯错，最终搞砸产品或者项目。

80年代，可口可乐听用户说我们要尝点新口味，费了半天劲推出了New coke，结果一上市差点被愤怒的消费者把店砸了…..

每个人都会把这句话挂在嘴边“我们要满足顾客/用户/客户需求”，但是究竟什么是用户需求？其实很多时候，需求不是用户讲出来的，而埋藏在用户的话语和行为背后，需要一些方法或者模型工具，才能洞察真相。

我们今天就来一起探讨如何真正理解用户需求。

二、克里斯坦森：用户目标理论

克莱顿·克里斯坦森（Clayton M. Christensen)在提出颠覆性创新理论之后，遇到了一些麻烦：理论很好很受欢迎，但是这个理论只是指出了问题，而没有告诉你该去哪里找到新机会。

所以在很长一段时间里，他边实践边提炼方法论，最终在自己的理论基础上演化出了“用户目标达成理论”——以用户目标（Jobs to be done）这个概念代替了传统的“用户需求”，来更深入的分析挖掘用户究竟想要什么。

克里斯坦森认为传统定义的“用户需求”太空泛了，像“我要吃饱”或者“我想走路时省点力”之类的需求其实说了和没说一样。

很多企业又是有了一个笼统的需求方向，老板就开始拍板做产品/方案，而各级人员为了已经投入的成本和给老板汇报时许下的承诺，找来各种看起来是证据的数据和材料来支持这个方向必须是对的，等到产品/方案真上市了，被友商锤得满地找牙，又回来开始互相指责……

嗯，跑题了。

克老师举的例子是赛格威（Segway），产品看起来很酷，刚上市时也是受到媒体热捧，

由于产品对象与场景的不同，所以C端产品需求与B端产品需求是截然不同的，如果以C端产品思维去做B端产品，那结果可能是相当“难以言喻”的。那细化到B端产品，怎么去规划B端产品的需求，怎么去判定产品需求的优先级呢？本文将告诉你答案。

世上本没有优先级，资源紧了，计划多了，自然就有了。

前篇文章，《需求太多？1个思考流程，轻松规划C端产品需求优先级》对C端需求优先级规划做了一个系统的梳理和决策思路。

根据规划层级的逻辑去思考，将需求关联到具体频道、模块下，结合整个核心模块流程来思考需求的价值，这种方法是相对完整和客观的，既避免了因需求评估维度单一导致错过真实需求，又可以通过层层思考，抽丝剥茧筛选出真正符合产品当下规划的需求，还可以锻炼产品经理的抽象能力和系统思考能力。

一、C端需求和B端需求的管理差异

因为笔者目前所在公司的两款核心产品，正好一个是面向个体用户的用户端产品，一个是面向组织、团体的协同OA产品，因此在工作中经常接触C端和B端的产品需求，最近在做需求规划的时候，也总结了两者的相同点和不同之处。

1. 相同点

1）需求管理的目的相同

都是为了集中当下优势资源为服务对象提供有客户价值的需求，对内提高资源利用率，保证产品开发团队良性运营；对外通过提供切实的服务，满足市场和用户需求，从而为公司创收，因此任何形式的产品，需求管理的本质是相通的。

2）需求规划的方法类似

在实际工作中，很多从C端转行到B端的产品经理，经常会用C端的工作思路去做B端的需求规划，虽然产品类型不同，但需求规划、分析的方法确实有相同之处；

在做需求规划时，通常都会优先思考与公司战略和规划相匹配的需求，其次是可以直接或间接为公司带来业务发展和收入增长的相关需求。

而且下图所示的一些思考层级和工具，在B端也同样可以使用，比如可以使用SWOT分析优劣势、KANO模型进行需求分类等等。

C端产品需求规划

2. 不同点

1）因为产品面向的服务对象和场景的性质不同，因此需求本质也就不同。

按照C端产品围绕核心路径打造极致体验的思路，作为产品经理们，可以按照自己的需求认知，将不利于核心场景的需求拒之门外，也可以义正言辞的说：此类需求严重影响产品核心体验，不予采纳；而B端产品需求规划的思路，是围绕核心业务场景完善业务闭环。B端需求基本来自真实的业务场景，1个需求可能来自10个业务方的反馈，10个需求可能满足100个业务场景，因此B端的需求基本都有

近些年来，生鲜电商概念一直很火，入局者也不在少数，但是在发展过程中，那些一味依赖“烧钱模式”的入局者纷纷倒下，而活着的也还在曲折前行，尚未看见黎明的曙光。很多人都会疑惑生鲜电商的春天到底在何处？而此次疫情，似乎向我们透露了答案，并引发我们进行更多的思考。

生鲜电商起步于2009年，在2016年面临大败退。而在随后的几年里，生鲜电商打碎、重组、涅槃，诞生了一些更有生命力的新模式，如：前置仓模式、线上线下一体化模式、社区团购模式等。本文希望回答以下几个问题：

生鲜电商为什么难做，为什么绝大部分的生鲜电商企业都在亏损；生鲜电商发展脉络的内在逻辑是什么；疫情之后，生鲜电商是不是迎来了真正的爆发机遇，往若当年非典之于淘宝。

一、生鲜电商难在哪

生鲜电商并未脱离零售的基本面，而零售的内核是将商品高效率的从一个地方（上游如产地等）转移至另一个地方（消费者手中），在这里谁能做到更好的货源、更低的转移成本、更高的获客能力以及更强的消费者洞察力就能获胜。

所以我们看到零售的比拼将是全链条效率的比拼。

生鲜电商如果想获得消费者的青睐，本质上是需要相比过往的生鲜销售模式创造了新的价值，比如更低的价格、更好的品质、更丰富的商品。

因此生鲜电商要做好同样也离不开几个核心问题：供应链、仓储物流配送、损耗管控以及消费者需求管理，这里为了便于分析，将问题简化为供应链端及零售端，我们从这两端来看生鲜电商所面临的问题。

1. 供应链

受40年前包产到户政策影响，目前生鲜行业尤其是蔬菜品类在生产环节极度分散，且供应链链条非常长，目前典型的供应链链条是：农户（合作社）-农产品代办-产地批发商（可能存在多级）-销地批发商（可能存在多级）-农贸市场。

从最上游的生产环节，到消费者的手中，最少要经历4-5个环节。

最上游的生产环节，当前仍是以果农、菜农等个体户种植为主，虽然各级政府可能把当地农民组织在一起进行统一的种植生产，但是在经营环节，仍没有出现一个强大的主体将分散的果农、菜农进行整合。

现存的合作社，大部分规模较小，缺少现代市场化经营的能力，因此在与下游的采购人员对接时，仍是以分散化的个体或者小规模的合作社为主体。

同时，当前生鲜流通环节的关键节点，如农产品代办、批发商也是以个体为主，普遍缺少规模化运作的能力，造成批发商亦分散且链条长。

而生鲜电商也是在这一基本面下开展业务，如果缺乏强大的供应链整合能力，其在供应链端无任何优势存在，也

本文就从上瘾模型来分析，这几款APP都是怎样让用户逐渐“上瘾”的，而作为产品的我们，在设计产品的时候，又应该怎样设计，把拉新-留存-促活-转化的过程做好。

每天晚上抱着手机从朋友圈到抖音，从微博到今日头条，刷到凌晨还不舍得睡觉，很多人称之为“报复性熬夜”。但是如果细心分析会发现睡觉前刷的都是这些APP，这似乎已经成为了一种习惯。

那为什么会是这几款APP呢？其实这就是走进了产品设计的上瘾模型了。

本文就从上瘾模型来分析，这几款APP都是怎样让用户逐渐“上瘾”的，而作为产品的我们，在设计产品的时候，又应该怎样设计，把拉新-留存-促活-转化的过程做好。

很多人都听说过上瘾模型的四个阶段，但是在实际设计产品的时候却利用不上，使用一个理论为指导的前提是你足够清楚明白该理论。本文会以具体产品作为案例，一起看看在上瘾模型的四个阶段中一些产品的场景及设计。

一、上瘾模型介绍

笔者是在《上瘾：让用户养成使用习惯的四大产品逻辑》的书中了解到上瘾模型，上瘾模型是培养用户使用习惯的一套标准化模型方法，它由四个阶段构成，分别是：触发、行动、多变的筹赏、投入。

上瘾模型看似相对单一的阶段，但又是相互辅助影响的综合效果。从前期的用户触发开始，下载了我们的APP，到用户基于某种动机，开始第一次使用我们的APP，再到我们通过多种的酬赏，让用户成为了我们的活跃用户，最终投入了时间及精力去使用，让产品从非必需品成为了必需品，养成使用习惯。

下面本文将结合理论详细介绍在这些过程中，有哪些产品的设计是值得我们学习的，它在哪些地方做得好。

二、触发

神经系统科学家指出，人脑中存在一个负责无意识行为的底层神经节，那些无意识产生的条件反射会以习惯的形式存储在基地神经节中，从而使人可以腾出精力去做其他的事。这意味着，当面对类似问题和环境时，大脑会触发这种无意识的行为，这就是习惯。而每一个习惯形成的背后都是始于某个触发，触发分为两种：外部触发和内部触发。

外部触发的主要目标是获取新用户，常规操作有付费型、回馈型、人际型和自主型四种：

（1）付费型

做广告或是通过搜索引擎做推广，价格较高。

付费型触发是通过各种渠道各种渠道的广告、搜索引擎优化（SEO）、应用市场搜索优化（ASO）等付费的方式吸引用户下载该APP，瓜子二手车为赶集网内部孵化的项目之一。

早在PC时代，赶集网与58同城就在SEO领域获取了大量的流量，脱胎于赶集的瓜子。其广告风格和广告

聊了那么久的中台概念，本篇文章我们来看一个中台MVP的实战案例，以底层数据中心为例的实战案例。在前几篇文章《中台实战0、1、2》中我们已经详细描述了中台战略的建设目标与演化方式，抽象来看我们可以将其总结为这三个关键词：复用、提效、一次开发。

一、中台化前的产品现状

在项目早期我们公司提供的服务就是在线酒店预订，这种业务模式的整个流程也不复杂，主要分为这几个环节：

BD进行拓店->邀请酒店入驻平台->平台上架->用户下单->分佣

重点来看第一个环节，BD拓店实际就是将线下的酒店住宿服务当做商品“进货”至公司的后台中，从而为后面整个服务奠定基础，这里也是整个业务的核心与数据唯一进口。

在这个环节中公司由BD与商务团队维护并积累的大量底层“商品”数据，而初期这些底层数据在数据库中，就是简单的以“Key=Value”形式进行存储。

存储字段截取

当经过一段时间的积累后，这种数据存储方式由于维度简单导致的结果，就是整个数据库的数据量在很短时间内出现猛增。

但是虽然看着每天都有“商品”数据入库，慢慢的我们却发现这些数据很多都是没有办法进行二次使用的，只能供特定的业务方进行独立使用。

具体来说，在公司内部我们通常会有多个业务团队，每个业务团队往往都会根据自己的业务需求在数据库中建立一张属于自己的数据库表（这里为了行文方便我们视作一个表），这些表的业务数据字段与定义方式都是按照业务方定制化进行的。

例如在当时，我们的酒店预订就分为两个业务团队：

非标住宿预定，也就是民宿；标准酒店预定；所以此时在后台我们有了两套业务数据体系，这些数据都是这两个业务方进行自主定义的。

二、挑战：业务线

这样的数据看似很寻常，目前很多企业也是这样对内部团队管理的。但是对于这种我称之为依托于前端统一团队的业务来说（两个业务方由统一的一群BD去进行扫街），我们实际上去做的就是将已经标准化了的数据（酒店录入数据）再次人为进行了割裂，变成了两个独立的业务数据库，如下图所示。

我们要知道很多企业平时日常所做的工作大多数都是在进行数据的迁移与整合，如：将用户行为数据与用户唯一标识数据结合，从而唯一确定分析这个用户的喜好。

那么也就意味着我们每破坏一次数据之间的关联性就意味着，为后期增加了一次需要进行反向操作，也就是将数据进行合并的工作负担。特别是我们将酒店天然性以业务墙进行了阻拦，更是破坏了数据的强关联性（同类数据）。

同时这样的数据也使得对于既

AARRR漏斗模型是Dave McClure 在2007提出的客户生命周期模型，解释了实现用户增长的5个指标，分别是：Acquisition（获取）、Activation（激活）、Retention（留存）、Revenue（收入）、Referral（自传播），因其掠夺式的增长方式也被称为海盗模型，可以帮助我们更好地理解获客和维护客户的原理。

在上一篇文章中，我们系统地讲解了AARRR模型中用户激活的几种方法和需要关注的指标，在这篇文章中，我们对模型中的第一个R——留存进行一些简单的讨论。

现如今，随着互联网渗透率的增高，获客成本日益增高，流量红利不再已经成为了大家的基本共识，尽力减少留存用户的流失才是当前运营工作的重中之重，AARRR模型中的用户激活在本质上也是在为用户留存铺路。实际上即使市场上的流量红利尚在，用户留存对任何一家公司也都十分重要。

Fred Reichheld的研究表明：用户留存率每提高5个百分点，产品的利润就会提高25~95个百分点（Fred Reichheld, “Prescription for Cutting Costs,” Bain & Company report (n.d.)）。留住用户的时间越长，从他们身上获得更多收益的机会也就越大，即使产品本身无法依靠出售商品或服务获利，也可以通过大量的流量吸引广告商的投资。

另一方面，留存曲线也是衡量产品PMF（Product-Market Fit，产品-市场匹配）是否平衡的最好标准，如果无论团队怎样努力，产品的留存曲线依然持续走低。那么产品所解决的需求很可能是一个伪需求，需要改变产品方向甚至及时止损，趁早放弃这个产品，投入新的方向。

留下用户的根本在于提供可以持续满足用户需求或者令他们感到愉悦的优质产品或服务，让产品或服务对他们而言不可或缺。

相对而言，具有储值价值的公司在提升留存率方面有着天生的优势，因为储值本身就增加了用户的沉没成本，产品的实用性也会随着时间的推移而逐渐增强。这也就是为什么微信这类社交产品有如此之高的护城河，社交关系的沉淀就是用户在产品内的重要储值，在设计产品时也应该尝试结合产品核心价值增加用户在储值方面的功能。

一 、初期留存

初期留存对产品而言非常关键，它决定了用户是继续使用，购买产品或服务还是使用一两次之后就“沉睡”。留存初期在本质上其实是激活阶段的延伸，其核心就在于让新用户更快地体验

在消费互联网红利开始触达天花板的时候，B端产品开始成为资本与巨头的关注焦点，由此也造就了B端产品热度不断上涨，想转行做B端产品经理的人也不胜枚举，那么入局B端的产品经理都要注意什么呢？打造一款B端产品又有哪些要点呢？

一、互联网的C端产品时代

在过去的几年中，众多C端用户互联网平台纷纷涌现，涉及的领域包括社交、电商、团购、出行、内容等等，这些平台通过链接人&人、人&内容、人&商家产生了大规模流量，这一切的链接和流量都依托于C端互联网平台的核心优势

1. 低边际成本

在经济学和金融学中，「边际成本」指的是每一单位新增生产的产品（或者购买的产品）带来的总成本的增量。

在C端互联网平台中的核心业务是信息&服务，当平台已经搭建完毕后，每服务多一个用户的边际成本是很低的，每一个单独的用户个体对于成本的影响因素是非常小的。

2. 马太效应

很多C端平台都在业务发展成熟期，无论是借助资本还是借助先发优势，都逐渐形成了高集中度的规模壁垒。

而随着集中度越来越高，在相同业务模式下的C端用户越来越聚集在头部平台，而小平台的较难的获客也会逐渐抑制其平台业务边界的扩展，这就形成了互联网的马太效应，使得行业内的两极分化愈发严重。

3. 高技术杠杆

技术代码不涉及库存和资金流占用，对于C端平台来说属于非常轻的核心生产力，沉没成本极低。通过技术可以快速迭代产品体验满足用户需求、标准化产品流程、降低信息匹配撮合成本、提高交易效率等等。

优秀的产品和技术模型架构是各C端互联网平台竞争的核心。

举个例子，在滴滴打车平台中，当分派单引擎和司&乘两端搭建完毕后，服务100个用户和101个用户所带来的成本影响是极小的。

在2014-2016年，滴滴凭借积累的运营&技术&产品经验以及几轮成功的融资，逐渐在出行行业中形成了「先发优势」，使得行业内业务规模第三名以后的玩家生存堪忧。

而到了2017-2018年凭借国际化的业务成功扩展，将业务收入和资本影响力持续扩大，直到2019年基本在出行行业内形成了「赢者通吃」的形势。

二、互联网的由 C TO B

2018年后，C端流量红利逐渐消耗殆尽并且新流量的获取成本上升，整体市场从增量市场变为存量市场，伴随着较为不利的经济形势，各C端互联网平台的业务边界也逐渐稳固，美团&携程打车、滴滴金融、阿里社交、腾讯短视频、头条搜索、百度feed、还有数不清的新上线的直播平台等等等等，各大公司的业务扩展也变得异常

作者分享一些App的令人印象深刻的交互体验，希望能够给同学们一些启发。

今天和大家聊一聊，我在日常体验不同App的时候发现的一些好的体验。

主要是想通过这些点给设计师一些启发，思考工作中可以从哪些纬度去打磨我们的产品。

01 美团标签提示

02 美团外卖下拉刷新

下拉刷新融入品牌logo和吉祥物是常见的方式，而美团则赋予更深的内涵。

用户下滑刷新时，小袋鼠在送外卖路上，会飞速地前行，寓意美团的送餐速度，遇到红灯就会停住，寓意美团的骑手遵守交通安全。小细节可以改善外界对美团外卖小哥飞速送外卖时，疯狂乱窜不守规矩的印象，

小细节，也可以装下很大的内涵。

03 美团外卖提交订单提示

如用户在提交订单时没有点主食，会提示用户是不是忘记点主食了。结合用户场景和常识，提供贴心的防错提示，设计上用底部动作栏的交互样式让用户快速添加，也防止了用户的外跳，可以在当前入口快速添加主食。

场景结合常识，提供防错机制。

04 美团金刚区引导

如用户所在城市未开通打车、单车服务时，会在首页icon上做视觉提示，用户点击会出现弹窗并带有详细说明和引导，同时用户也可选择“移除服务”移除无用的功能，与此同时移除时可以让其他功能入口得到更多曝光。

用户遇到消极状态或失败等情况时，应当给用户详细的说明以及引导。

05 支付宝输入框交互

用户在对话窗口输入数字后，会出现气泡提醒，提醒用户是否需要转账。在特定情况下为用户提供防错机制，同时又为用户提供快捷的转账入口，这一切都基于产品属性和对用户行为的预判。同样的功能

不仅要知道自家产品定位，还需要了解用户对自家产品的定义是怎样的。

06 支付宝输入框

聊天窗口，可以点击底部输入框内的转账，快速进行转账，根据产品属性为用户前置常用的操作。

结合用户常用操作，可以考虑前置用户常用的功能或操作。

07 微信安全提示

在“收付款”页截屏时，会提示用户保护好二维码，以防泄漏。

信息敏感相关页面，可以考虑提供安全保护提醒。

08 微信截屏引导

在“二维码收款”页截屏时，会出现弹窗并引导用户将收款二维码保存至手机。

用户在不同的页面截屏，可能会有不同的目的，不同的页面可以设置不同引导。

09 微信朋友圈设置权限

刷朋友圈时，朋友圈总是充斥着各种微商，或不想看到一些人的朋友状态，但又不好意思删除时，则可长按头像“设置权限”选择不看ta的动态。

充分考虑了用户在当前场景可能产生的情绪变化，分析用户情绪可能产生的潜在操作行为。

10

不懂技术的产品经理可能在遇上bug时都不知道去找谁，本文说明产品前后端如何划分，相关问题属于哪个“端”，适合初级产品人阅读。

产品汪在验自己产品时，经常遇上bug了，就去找测试小姐姐，测试小姐姐看了看，就说：“这个找后台的某某吧”，“这个找前端的某某吧”。

小汪就好奇了，那么多程序猿哥哥，他们的职责是怎么划分的呢？

产品经理眼里的“端”

在产品经理眼里，一般按业务的使用者对产品领域进行划分，例如淘宝的用户端、商家端，再例如滴滴的乘客端、司机端、运营后台；甚至会进一步细分，有网约车司机端、代价司机端等。

当然，也可能按照业务模块进行划分，例如物流系统、支付系统、订单系统等。

前后端：谁前？谁后？

在大部分公司里，一个程序员的工作，可能会覆盖很多个产品端。例如一位前端的同事，可能既要做用户端的H5，也要做商家端的网页，还要做平台运营后台的网页。一个后端的同事，工作也可能覆盖多个业务模块。

那他们的工作是怎么划分的呢？

简单来说，对于程序猿哥哥来说，前端就是负责“用户看得见”的内容，将UI稿转换成网页、APP、电脑软件等，同时实现所有交互事件，例如用户点击、滑动、拖动等操作。

前端又会根据实现的形式进行细分，常见的有：

1）移动端APP

根据手机系统的不同，又细分为苹果iOS APP、谷歌Android（安卓） APP，甚至一些非常小众的手机系统APP，例如微软的Windows Phone（简称WP）的APP。

不同手机系统上APP开发需要用的编程语言差异较大，开发环境也有所差异，所以一个APP前端程序员，一般只会开发一个端，例如只负责安卓端，或者只负责苹果端。

另外，在移动端，大家经常能听到一个词，叫做“原生”。所谓原生就是使用系统指定的编程语言开发的软件，“非原生”，一般指套用一个网页浏览器，然后再在浏览器内用网页展示内容实现的软件。

2）PC端软件

例如我们常用的office系列软件Word、Excel、PowerPoint；电脑版的QQ、微信、QQ音乐；上网页用的Google Chrome浏览器、Firefox浏览器等，都是PC端的软件。PC端也因系统的差异，前端也会进一步的细分。

3）网页web

网页基于HTML（HyperText Markup Language，超文本标记性语言）实现，现在已经发展到了HTML5.0版本，也就是大家耳熟能详的H5。Web内容具有编程语言统一、与平台无关的特点，我

本文分析了为什么是音乐APP首先推出年度报告？现在的年度报告都是怎么做的？年度报告的作用是什么？怎样做好一份年度报告？

如果没记错，最开始做年度报告的APP应该是音乐类APP，听歌算是高频的事情，也是比较私人的事情，第一次看到年度歌单时觉得很惊喜，很有一种被关怀的感觉，仿佛APP真的变成了朋友，与我之间有了回忆。

现在年度报告已经变成了每个APP的必做运营事项，不由思考，为什么首先是音乐APP推出年度报告？现在的年度报告都是怎么做的？年度报告的作用是什么？怎样做好一份年度报告？

下面就依次聊一下我的思考结果，以及通过分析16个APP的年度报告H5发现的一些相似与不同。

一、为什么是音乐APP首先推出年度报告？

对于为什么首先是音乐APP推出年度报告，这个问题其实是在思考年度报告H5的来源以及作用，我认为年度报告H5的出现原因与音乐APP的以下四个特点密不可分，同时年度报告又为音乐APP的用户提供着使用APP的正向激励。

高频细碎，听歌早已成为一种不是刚需胜似刚需的存在，同时又是一件很细碎的事情，贯穿在我们生活中的各个场景下，匹配着我们每时每刻的心情，而这种与我们生活的紧密联系在每一天中看似波澜不惊，聚合起来必然会拥有强大的感染力。调动记忆，“歌曲”本身是感性的产物，我们听歌时所带的感受多和生活中大小事情有联系，歌曲就像用于回顾一件件事情一次次感受的关键词。千人千面，音乐类APP算是很早加入千人千面技术的一类APP了，每个人对于音乐的喜好是不同的，从APP的角度是千人千面从个人的角度就是独特性，独特的东西就有被了解的需求，包括被我们自己了解，而一年的周期还满恰当的。榜单原型，音乐类APP本身自有的榜单形式其实可以看作是年度报告的原型，转换收录的维度，再扩展收录的数据，就是一份份属于用户的年度专辑、榜单。

以上图展示的逻辑，很多APP中也可以或多或少的找出一些支撑年度报告的基础因素（左侧橙色框），当音乐APP的年度报告刷屏后，陆续各个APP也加入了发布年度报告的队伍中。

二、现在的年度报告都是怎么做的？

虽然做年度报告的APP变多了，但呈现的内容结构是相似的，都是以数据为核心梳理用户的使用情况，再匹配文案和设计（含交互），看起来有点像运营人的活动总结报告。

就本次覆盖的12种类型APP，共计16个年度报告H5来看，结构大多如下，或是缩减版：

启动动画（1~3页）：叙旧前的铺垫，铺垫整体H5的