，今天我们来看看数据产品经理如何将业务语言的需求转化为规范化标签数据需求，让研发能够真正”懂你”。
开始之前，我们还是看一下小王的案例：
通过上期的方法，小王明确了业务方最紧迫最重要的20个标签需求，并仔细填充《标签需求收集模板》中涉及的关键信息，力图在评审时让研发对需求一目了然。
完成表格后，他和研发同学约了第二天进行需求评审，万万没想到这次评审他又翻车了，评审会上，研发同学毫不留情地对他”开怼”：
1、 这几个标签用到的数据源我没接触过，去哪里拿？哪个数据库哪张表？数据能用吗？
2、 行为数据几个地方都有这个字段，我到底从哪张表去取？
3、 大部分用户注册时，根本不会填写性别信息，这样的标签做出来结果都是未知，有什么意义？
研发提的问题小王没能对答如流，评审结果以失败告终。小王自认为，需求已经非常明确，这些标签对业务都是有明确使用场景的，想要的就是这些，描述也非常清晰，为啥还是翻车，心里觉得特委屈。
为了避免遇到和小王一样场景，本文总结避坑指南流程如下：
1、明确数据源及数据口径
数据产品经理提需求时，必须对需求中涉及的数据了然于心。口头描述或仅仅用业务化的语言描述需求，只会让研发在心里给我们打上“不靠谱”的标签，且在后续项目过程中很有可能出现以下情况，对整体项目推进极为不利：
增加研发工作负担：对于不了解的数据源，研发需要反复和数据源方沟通确认规则，对于喜欢专注码代码的研发同学无疑大大增加了工作负担。
实现结果不是需求方想要的：在数据源对接过程中，大多数研发可能已经心力交瘁，当遇到复杂问题时，有些研发同学为了图省事进行自由发挥，或者因为信息获取不全面进行错误决策。
所以在此环节，数据产品经理可以和数据源方的产品、运营、研发同学重点明确以下信息：
数据采集入口：如用户在客户端某个位置，在何种场景下进行操作，能够获取到该数据
数据采集方式：如通过埋点获取，通过爬虫获取等
数据血缘关系：如是否依赖上游表清洗而来
上报机制：如实时上报、离线T+1上报、数据量达到20k上报等
数据清洗规则：如是否进行格式校验、转化、排重、填补，若依赖上游表，还需溯源各上游表明确处理逻辑
数据存储位置：通常明确库表名即可。
2、摸底数据质量
数据的质量直接影响着数据的使用价值，并且直接影响着后续需求方进行数据分析的结果以及以此做出的决策的质量。核心需把握以下四要素：
准确性：上报的数据是否出现异常或存在不正确信息，被记录的数据是否精确；
完整性：数据是否存在缺失；
一致性：数据流转过程中，前后是否一致；
及时性：按照既定规则，数据是否还存在延迟；
通常，我们可以先想一些用例，自己写SQL或者求助数据分析师、研发同学，导出批量数据，进行初步数据质量探查。数据导出后，结合对数据源的理解，发现数据中存在的问题。
不过仅仅发现问题远远不够，需要谨记我们的目标是实现标签需求，所以发现需要主动去思考解决问题的方式并推送问题的解决。
比如数据格式不正确，但为了实现该标签，是否可通过制定一定的清洗规则进行处理，再比如关键字段值大面积缺失，是否可从其他数据源进行回补，或者发现该字段在用户界面是非必填项，则需要推送业务方进行完整数据采集等。
3、确定标签规则
明确数据源、数据口径并摸底清楚数据质量后，数据产品经理已经建立起对数据的清晰认知，接下来就是制定明确的标签规则。一份清晰的规则说明，需包含以下内容：
标签类别
标签层级
标签名称
标签值：标签值具体名称，如性别标签下的”男””女””未知”，收入水平中的”高””中””低”；
数据源：库表名
统计时间周期：特别是规则类、统计类标签，需明确选用的时间范围，如用户活跃度标签，选取近90天的数据进行计算。
标签具体规则：选择数据表中的具体哪个字段，每个字段值与标签值的对应关系，涉及多个数据源时选取数据源的优先级、时间衰减规则等
异常数据处理逻辑：如数据源字段存在空值转化为“未知”，字段值出现多个不同格式需进行如何进行格式化等
标签实时性：实时更新还是离线T+1更新
发表评论 取消回复