反馈已提交

网络繁忙

支撑看板需求

  • 文档创建者:RosieY
  • 编辑次数:2次
  • 最近更新:Roxy 于 2022-08-29
  • 1. 概述

    作为一名数据分析师,你日常一个重要的工作就是根据业务需求,设计和制作看板,为业务方提供数据指引。

    需求处理阶段包括三阶段:发现问题、需求确认、需求处理。

    实际工作中,「问题」可以是领导或者业务方直接抛出,也可以是自己主动发现。但不管哪方发起,思考问题均离不开数据分析思维的支撑。

    2. 发现问题

    数据分析的核心目的就是发现问题和解决问题。

    有时候业务提出的分析需求,可能只是一个个人的设想,作为分析师,需要有独立判断的能力,帮助提出问题的人梳理清楚问题,从而更好的进行问题解决。

    有效问题的5个特点:

    1)是否有价值

    此“价值”是建立在公司利益之上的。有价值的问题并不是说角度新颖、前所未有,而是触及到了公司的重要层面。

    该“问题”是否与公司、部门的OKR相关,是否有跟着公司的整体方向走。比如某个产品已经流量见顶了,公司整体策略由之前的拉新获客变更为提升活跃留存、维护老客,那么即使产品的用户体量趋势即使逐渐趋于平稳,孛离公司整体策略,也不需要再在这上面过于下功夫研究探索。

    2)是否涉及核心指标

    首先需要熟悉公司有哪些指标,尤其是核心指标具体是哪些。其次,需要继续了解这个问题是否涉及核心指标,且涉及了哪些核心指标。

    3)是否影响面广

    是否关系到公司的整体策略?这个问题如果不解决的话,会产生多大的影响?如果解决了的话,会有多大的利好?

    4)是否可规避

    受宏观影响还是微观影响?无法避免还是本可避免?

    若这个问题受宏观政策的影响,比如疫情原因导致的线下门店销售下滑,再比如国家出台政策规定篇p2p年化利率最高36%,这是宏观因素,不可避免;宏观因素下,公司业绩指标变化较大,原因众所周知,且无法规避。此时单纯研究这个问题则意义不大。

    若这个问题未受宏观影响,比如,某个产品的最近复购率下降,宏观上并未有任何政策影响,就莫名其妙的复购下降了,此时需要深入探索是不是产品本身存在了问题,还是竞品导致,或是其他。这个问题可以说是本可规避但未规避。

    5)是否有时效

    时效性的理解就是,如果这个问题现在不解决,对业务后续发展会产生一定的影响。

    比如,研究前年10月销售下跌的原因则没必要,要保证数据与时俱进,避免数据过于陈旧;再比如,当前时间节点若是处于市场竞争激烈的态势,则需实时把握产品的数据变化,及时发现问题并解决,当前的问题延期到未来作用性衰减。

    2.1 通过什么方式发现问题

    与历史对比:是否符合历史惯例趋势,比如数据一直平稳波动还是突增or突降?

    与同期对比:如周同期、月同期,年同期。比如2020年双11期间销售额较去年同期是涨了还是跌了?

    与总体对比:比如某个sku盈利情况与所在品类盈利情况的对比,该sku对总体的的贡献率如何?

    与竞品对比:与有相同应用场景、相同用户群体、存在竞争关系的产品进行对比,寻找差异点。

    与目标对比:与公司目标、部门目标相匹配的可衡量指标进行对比,是否有跟着公司战略方向走?

    与经验对比:以经验第一时间迅速洞察问题,比如双11某门店营收不升反降。经验不需要数据支持,但需要敏感的数据思维以及数据分析经验支撑。

    与预测对比: 与预测数据的差距是否在正常范围内?

    2.2 问题拆解与归类

    常见的问题归类方式有:

    按照四象限法则进行归类:紧急不重要、紧急且重要、不紧急不重要、不紧急重要

    按照问题类型进行归类:交易相关、流量相关、用户体验相关、数据安全相关、财务数据相关……

    有时候我们遇到的问题很棘手,大且复杂。一片迷茫,思维混乱。如何着手去解决?这时候,我们需要将复杂的问题进行拆解,而非将焦点浮在问题表面,把大问题围绕核心点拆解成可以行动的小问题,找到切入点。

    打个比方,某个线上产品营收下降了10%,将10%拆解到各个子产品线、各个地区维度等,拆解出下降由哪方面带来,再针对性的逐个分析。

    2.3 站在业务角度想问题

    做分析,很容易陷入一个圈:为了分析而分析。

    看到一个问题,会想可以用xx模型、xx技巧、xx模板来分析了。使用了一圈的技能,复杂的过程,密密麻麻的公式等,感动了自己,迷茫了需求方。

    而对于需求方,在实际业务中其实并没有办法使用。

    因此,从实际业务需求想问题,哪怕只是做了一些很基础的分析和计算,也可能会给业务带来很大的便利。

    发现问题之后,有了初步的方向,下一步就是需求确认。

    3. 需求确认与梳理

    3.1 确认需求背景

    了解清楚需求背景,才能明白这个需求的意义,是为了解决什么问题而出发的,不至于迷茫的做分析。需求背景就是需求产生的原因以及想要达成的目标。

    需求产生的原因:为什么会有这样的需求?

    需求要达到的目标:此需求期望在什么时间通过什么样的方式达到什么样的目标?

    3.2 确认指标口径

    需要确认清楚这个需求涉及什么指标,哪些是核心指标哪些不是核心指标。每个指标的口径是什么,最近有没有更改口径。

    比如客单价,即使大家都知道客单价=GMV/用户数,但是不能想当然以为需求方肯定知道,需求方也以为你肯定也知道,双方未核对口径直接开工干活。这样会存在两波客单价口径不一致的风险。分子什么维度、分母什么维度,都需要对清楚。

    因为分析角色是干活的一方,需求方是发布需求的一方,所以面对需求,自身需要想的更多些,有些点需求方可能没想到,此时分析师需要具备更多的主动性。引导沟通、多方核对。毕竟,不沟通清楚需求直接干,容易背锅且被投诉,也竹篮打水一场空,浪费了时间。

    3.3 确认数据维度

    数据维度可以理解为研究数据的角度,比如地区、城市、用户名等。

    需要向需求方了解清楚:

    • 需要什么维度的数据?

    • 此维度按照什么方式聚合?

    • 去重还是非去重?

    • 直接聚合还是累积聚合?

    • ……

    3.4 确认底层逻辑

    需求方提需求,一般只会讨论需求详情,但是需求怎么做,数据从哪里获取,他们不需要关心。

    比如,需要看某个商品的七日复购率,数据库表中有七日复购率指标么?若有指标口径是否和需求方的口径一致?若无,需要从哪些数据库表进行关联得到所需数据?自己关联计算的逻辑需要数仓落表还是直接应用?

    3.5 确认需求排期

    在了解好需求后,需要根据当前的人力进行需求排期,确定完成需求的时间。

    3.6 确认数据安全

    分析师可以接触到很多底层数据,所以需要有数据安全意识。有的公司划分比较严格,某个模块的需求专门安排某个分析来一一对接。但有的公司没这么严格,所以需要判别下需求方是否可以查看该数据。

    1)需求方是否可查看该数据

    即使是同一个公司的人,各自的数据权限也并不一样,一般不允许非必要性情况下获取本职工作以外的数据。比如,两个部门做着类似的产品,有着类似的用户群体,也背负着各自绩效,数据不能相通。

    但对方都是希望可以获取另一方数据来做对比,这种情况有的公司不被允许。分析师自然也要判别这种情况,该给给,不该给则果断拒绝这个需求。

    2)明细数据是否涉及数据安全

    另一方面,需求方有时候需要明细数据,即数据粒度较细的非聚合数据,比如ods层、dwd层的数据,还需要判别下是否能够提供明细数据。有的公司明细数据会受到公司安全部门的监管。毕竟,明细在手,各种角度的分析都能搞。

    3. 看板设计和制作

    制作看板方面,可以从核心指标、维度拓展、页面布局三方面来进行设计。

    详情参见数据可视化最佳实践



    附件列表


    主题: 数据分析方法
    已经是第一篇
    已经是最后一篇
    • 有帮助
    • 没帮助
    • 只是浏览

    售前咨询电话

    400-811-8890转1

    在线技术支持

    在线QQ:800049425

    热线电话:400-811-8890转2

    总裁办24H投诉

    热线电话:173-1278-1526

    文 档反 馈

    鼠标选中内容,快速反馈问题

    鼠标选中存在疑惑的内容,即可快速反馈问题,我们将会跟进处理。

    不再提示

    10s后关闭