数据产品-如何搭建分析型数据产品

怎么去做一个分析型数据产品

1.首先得明确是在什么样子的业务场景之下，面向什么样子的业务命题方向，做拉新、提频、做拉收、做拉活等
2.用什么样子的分析框架去剖析该场景做得好与坏
3.然后才是如何将分析框架抽象化，再去实现产品化
4.最后是如何做好一个分析型产品的长期迭代运营，因为业务在变化、在增长，一套分析模式没法解决永久的事情，需要长期不断的迭代运营

一、怎么去理解一个业务场景

首先需要明确是在什么样子的业务场景之下，前提就是需要学会去理解一个业务场景，大到进入一个新的行业、小到进入一个新业务场景的情况下，我们怎么如何快速去理解这个业务场景for什么样子的目标、在做什么样子的事情、各模块之间是怎么相互配合推进的。

1.方法论

OSM模型（目标-Objective、策略-Strategy、度量-Measurement）

2.步骤

①明确当前业务的核心KPI指标是什么，比如以前我们做长视频业务的，核心就是视频所带来的GMV流水、业务的DAU增长、视频的播放量，再者就是长期层面内容对业务生态的影响，比如内容的拉新量、市占率等

②基于业务体系下的目标，到底是有哪些团队组成，他们分别都在做什么样子的事情、执行什么样子的策略。比如围绕着步骤①中的KPI目标
A、会有产品团队-功能产品负责整个场景功能的搭建，就是用户所看到的一系列剧集视频对应的承载APP以及背后需要的一系列B端后台、策略产品付费整个算法推荐的迭代优化（我们所感知到的类似抖音短视频给你推的内容的类型越来越符合你的预期，其本质是对推荐策略的不断迭代优化的过程）
B、会有运营团队-内容运营负责整体内容的排播布局，通过运营活动等手段实现内容的供给与消费的良性循环，流量运营负责整体的渠道投放策略和优化
C、除了上述最常见的团队之外，还有很的支撑团队，比如研发团队，资管管控团队等，基于业务的特性可能还会有更多的重要的组成for重要的目标。比如有类似总编室的角色，负责整体流量资源的分配，for流量资源分配效率最大化的目标，有内宣外宣，负责站内外热度的把控和承接，for公域流量和私域流量的运营已达到拉新拉活内容宣发等各种目标

③明确了KPI是什么，明确了会有哪些团队、在做什么样子的事情来促成KPI的完成之后，下一步则是怎么去量化评估这些事情到底做的怎么样，包括核心的效果指标和过程指标，明确常见的分析维度，构建成一套基础的指标体系
A、首先明确分析实体，比如步骤②中涉及的有，人群、场景、渠道、内容、宣发等，在明确每个方向核心关注的结果指标，比较常规的如下：
人群上：看DAU、看留存、看GMV、看MAU、播放量、播放时长
场景上：看用户粘性，比如用户留存相关的
渠道上：看渠道效率，比如CTR、CVR等
内容上：看内容的付费、内容的消费深度
宣发上：看引流效果，比如拉新、拉活等
B、再者是明确常见的拆解方式和维度分析角度，比如用“杜邦分析法”做指标拆解，维度分析正常是从“人货场”角度去拆解，比如从人的角度-用户的活跃价值分层、用户的生命周期、用户的画像偏好等去做维度下钻，从货的角度-内容的分层、内容的风格、内容的评级等，从场的角度-场景的分类、场景的触发方式比如主动渠道or被动渠道等
C、最后可以结合现有的一些报表体系帮助自己去进一步理解自己所处的业务场景。正常报表体系下的每一个报表其实本质从业务视角出发所搭建的一个小场景，核心区别是场景的深度和广度会因提需求的人的分析思维和业务理解的情况而有所不同，但其多多少少是可以帮助我们看清楚业务在做的一些内容、核心关注的指标和常见的维度分析角度。

btw：比较体系化的报表体系建设方式，也是我们去理解和看报表的一种方式
①首先，体系化的报表体系情况是以KPI作为核心支点，以场景作为类目体系开始搭建，其本质是对业务进行场景还原，通过报表的类目体系我们能清晰的看清楚业务关注什么，会从哪些场景进行分析，场景之间的相关性是什么样子的
②再者，体系化的报表体系不是简单的解决数据呈现的问题，其实需要以解决业务问题为目标而去构建，对此才有接下来的报表设计步骤
③明确上面的两部分，才是真正到报表的设计环节。对于一个报表的设计
步骤1：报表需求分析，明确报表所服务的业务对象是什么（for老板、for中层管理、for业务执行者，对于不同对象所关注的点、报表的粒度等都会有很大的区别），解决的是什么场景的问题（做好报表类目体系的划分和报表里面的模块划分）
步骤2：确定场景归类和内容限制。如果是for业务KPI完成的，核心关注的是完成度和核心问题的定位（常见是放结果指标同比、环比等）；如果是for过程拆解，主要是各业务模块的负责人（常见是放核心指标和核心指标的公式拆解过程，并给出benchmark帮助判断问题点）；如果是for一线具体的执行同学（常见是放更为明细的数据，能够结合到具体的动作的数据，比如投放过程中的每一条投放效果数据分析）

二、怎么去拆解一个分析框架

当我们理解了一个场景之后，对于场景下的特定的命题的分析就相对比较有概念。那如何去拆解一个命题的分析思路并结合业务的动作给出一些业务建议呢（如果有分析师的协助会更好，能够更多的给出一些框架性的东西）

1.方法论

目标拆解-找benchmark辅助判断-多维分析圈定范围-明确落地动作

2.步骤

①拆解目标：当面对一个场景下的一个命题，可能会有很多需要分析的目标，比如会有GMV、会有播放量、会有拉新等不同的核心目标。我们可以以其中一个指标作为案例来做问题拆解，比如以GMV为例，对于这样的一个结果指标，我们是无法定位出其问题点的，所以优先需要做指标的拆解，比如对于视频行业中，GMV=登录用户数播放转化率付费转化率*arpu，面对这样一个拆解后的公式，我们能更清楚的知道是哪个因子出了问题，可能是由什么样子的业务动作导致的。比如arpu有问题，是不是我们的付费套餐策略的问题。这里就引出了我们的下一步分析，每个因子是否有问题

②找benchmark：对于指标拆解过后的每个指标表现，如果没有对照物，我们是很难评估该指标当前表现的好坏，因为其会因内容本身的特性带来天然的不同，比如有些内容天然就具有吸金属性，有些内容本身就是做生态的（就有点像一家企业的不同业务，比如微信生态下，微信本身的业务是公司的护城河，而像衍生出来的视频号业务，其更多的是防守业务，避免流量都流转至抖音快手等平台），业务随时间的波动带来天然的波动，比如假期天然是流量高峰，所以很多时候我们通过看同比环比变化也很难帮助我们去判断因子的好坏。因此，为了能够评估因子本身的好坏，我们需要引入对照物。对照物的选取原则更多的是基于经验沉淀结合水平相当原则，比如我们的内容 or 游戏，在前期会对其进行评级（S/A/B/C）等，我们可以基于历史不同评级去算出对应的均值、最大值、最小值、4分位、8分位等等统计分布指标，来划定不同评级的不同因子的正常波动范围来作为我们对照物；同时我们可以选择单内容来作为对照，比如同期上线的内容、同评级等多维度相似性较高的内容作为对照物帮助判断。有了对照物之后，我们能很清楚的知道，当前KPI指标的异动是因什么因子的表现不及预期所引起。

③多维分析：当我们明确了异动因子之后，同样以上面GMV的拆解公式为例，比如异动因子有两个，播放转化率和付费转化率两个不及预期。那下一步需要去拆解因子的结构，也就是导致该因子这样表现的缘由，到底是因为全局用户都是这样的表现，还是说部分用户不及预期导致整体不及预期，亦或者是某些渠道、某些内容等不同维度导致的结果。因此我们需要开始做维度下钻来拆解因子的结构，比如按用户分群去下钻，去看不同群体的表现（这里会前置引入我们怎么去划分群体，常见的划分群体方式有按用户的活跃度做分层，划分高中低活；按用户的付费能力做分层，划分付费分层；按用户的生命周期划分，划分新手期成长期成熟期和流失期；还有一种比较重要的基于对内容的认知程度高低划分，划分层核心、兴趣和泛用户）；也可按渠道去下钻，看不同渠道的表现。总而言之，维度的选择会基于我们前置对场景的理解和常见的分析框架的理解，更多时候还会做多维的叉乘分析。

btw：当我们明确了问题因子，确定了维度下钻的方式之后，我们可以将不同结构的组成划分到不同的象限下，帮助我们做下一步的策略制定，比如当我们按人群下钻之后，就会得到下面的分布图,就能很清楚的指标对于不用因子是由不同的用户导致

btw：由于不同群群体的占比不一样，对整体指标的影响程度不一样，因此统计上会引入贡献度的计算法方法-组内组件计算法
组内：随时间波动用户指标本身的波动变化 组间：随时间波动，结构本身的变化导致的波动 组内=（本周DAU渗透-上周DAU渗透）本周DAU占比
组间=（本周DAU占比-上周DAU占比）(上周渗透率-上周整体渗透率)

④明确业务动作：通过步骤③我们清楚了问题因子以及对应导致问题的结构群体之后，那下一步就是结合现有的能力对不同的人群 or 不同的渠道 or 不同内容做差异化的策略，以达到最终目标可达成的结果，比如：
【高播放转化率高付费转化率】核心人群，看看多少还没转化，使劲薅
【高播放转化率低付费转化率】羊毛党，分析不付费原因，活动策略引导付费
【低播放转化率高付费转化率】有钱人，短带长先用二创剪辑的视频引起兴趣
【低播放转化率低付费转化率】边缘人群最后处理，再想想有啥手段

自此，我们完成了一个场景下的一个命题的拆解和分析，但实际的命题拆解过程到能有业务执行动作，其实是一个经验+理论的探索结合过程，远不至文字描述的这样简单，在数据分析上，方法论的沉淀和迭代是漫漫前行的过程

三、怎么实现一个框架的数据产品化

通过对一个场景的理解，再到对一个场景分析框架的沉淀，并能够将其进行不断的复用之后，下一步我们就可以考虑通过数据产品化的方式进行承载，以提高数据分析师和相关业务人员的数据使用效率，并通过产品化的方式提供业务建议对接不同业务系统，实现策略触达的效果，以达到作为一个数据产品从只能提效向对业务指标带来增长的转变。那如何实现一个分析框架的产品化呢，和许多功能型产品有个比较大的不同就是体现在看数逻辑上，我们如何通过产品化的方式来引导业务怎么看数据、怎么得出业务建议。

1.方法论

一个核心（问题-解法-todo）+两个原则（看数顺序，主题分类）

2.步骤

①一个核心：在实现一个分析框架的数据产品化前，要牢固分析框架的核心，抛露现状问题是什么，通过分析的分析定位相关问题点，最后基于可落地的action提供数据建议，映射到产品功能层的设计则为，优先抛露指标表现的问题点，然后提供可分析拆解的问题的功能设计，最后基于用户在产品上的配置化选择结合动态的规则给出建议

②两个原则：原则之一是要有明确的看数顺序，即需要告知用户需要先看什么、后看什么，默认看什么、个性化看什么。通过第二部分我们在理解一个分析框架的时候，我们会清晰感受到其是层层探索下钻的过程，也就是说在看数据时是有一个明确的看数顺序的。以前面在分析一部剧集运营的好坏时，在功能层面的设计应该和分析框架拆解的顺序一致
A、首先第一模块的功能是需要告诉用户整体的KPI完成情况是什么样子
B、第二模块的功能是做KPI的拆解，比如对GMV的拆解并结合BM进行因子判断
C、第三模块的功能才是维度下钻，当然维度下钻的方式多种多样，是优先拆解人群 or 拆解渠道 or 拆解内容，需要看到指标也有很多，这时候就需要结合我们对该业务分析场景的理解，也就是说我们默认需要给用户看些什么样子的指标（如若能用尽可能少的指标能够讲清楚问题时，就不要给用户展现过多的指标，当指标量级超过一定量级，可能该模块的功能就相当于没有，因为用户从该模块得不出有效的结论），以渠道为例，我们默认应该是看渠道的效率指标，也就是ctr和cvr，当发现核心效率指标有异动时，这时候才会结合说ctr比较低，到底是曝光量级的问题、还是点击量级的问题。
原则之二是要有明确的功能主题，对于用户来说，正常会有周期性的观测需求，比如每天有需要盯盘的内容，每周有需要复盘的内容，每月、每个季度都有不同粒度、不同维度的观测需求，因此在功能设计时，我们需要明确给到用户的指引则是不同模块是在解决什么主题的问题，而不应该进行融合，这样会导致数据堆积而得不到获取有效结论的效果。同样的我们再一开始提出来的“人货场”的维度分析方式，在分析人群、分析渠道、分析内容等不同主题时，我们也需要理清楚不同主题的侧重点是什么，哪些部分是有交集的，有交集的部分是否可以进行叉乘分析，这些都是在做功能设计时需要考虑的东西。举例对于视频内容分析，按人群查看的时关注的是人群策略效果、用户的消费深度；按渠道进行查看时关注的是渠道的效率；按内容进行查看时关注的是内容的表现和用户粘性互动等相关

③除了在遵循对应的原则时，对于分析型的数据产品有几个比较核心的功能点需要体现，一是作为分析框架的载体，对于每一块的功能设计都需要有对应的summary，能够明确告知使用的人该模块的结论是什么；另外一个要点是能够提供参照物，很多时候的分析都是立足于问题本身，我们只有将问题放在某个对立面之后，才能够更好的看清楚问题的好坏

四、最后是怎么做好产品的迭代和产品的运营

业务场景一直在更新迭代，对应我们去分析场景的框架也需要逐步去做完善和迭代，以提供更好的业务建议，这就要求我们能够做好一个分析型数据产品的迭代运营。和日常的B端产品的运营会有一些差异性的点，分析型的数据产品更关注的是策略建议，基于我们产品所生产的策略建议是否对实际的业务指标有帮助可能是我们去做迭代最优先关注的，其更多就是我们用来评估我们做的产品好不好的一个最核心的方面。（在怎么评估一个产品好与不好，现在还是一个未解之谜，也是自己在持续探索怎么样才是好的一个命题，不同阶段答案肯定是不同的）

1.方法论

冷起期验跑通逻辑-推广期验策略覆盖-维护期验用户体验

2.步骤

①冷起期验跑通逻辑：和算法冷起相似，我们需要有流量反馈来快速验证我们模型的的有效性，通过我们产品所输出的策略能否直接指导到对应的业务应用是需要我们快速去验证的，有条件的话可以用AB测试的方式去验证有效性。在这个阶段我们核心要做的是种子用户的培养，能够用部分业务来验证跑通整个产品流程的逻辑，为下一步的产品推广提供成功案例

②推广期验策略覆盖：当我们明确产品功能逻辑能够解决特定场景之后，下一步则是实现产品的推广应用。随着业务人员的使用和业务场景的不断输入，我们会发现现有的功能设计一定会不满足一些特定场景，一方面可能是前置的分析框架所考虑的因素不全，另一方面也可能是有现有场景所引申出来更进一步的探索性场景。因为需要不断去总结业务场景的输入，配合分析师去不断的完善我们的分析框架，指导产品的迭代

③维护期验用户体验：当产品沉淀足够多的策略之后，很长一段周期内的看数体系相对固化之后，更多的迭代方向则是偏向于用户体验项上的迭代优化，当然这也是每个产品在每个阶段都需要考虑的点