本人为一枚小小的数据产品从业者，3年数据分析及数据产品经验，本文将以笔者实际工作为基础，以需求的口径问题为角度，讲解拿到数据需求后，该如何从0到1的过程。
数据从业者大多体会过，需求方提出的数据需求，有时候简单明了，但是实则遍地是坑，有数不尽的定义，口径需要我们要能够提前想到，并给出建议和解决方案。
所以本文也只是从我的小角度，小案例出发，来探讨如何做数据的需求分析，抛砖引玉。
本文涉及以下关键词： 需求分析，用户行为，SQL
需求背景
现在我们的app有h5页面版本，h5页面的入口来源也有众多，其中最主要的便是我们公司的主要app，入口分布在主要app的各个位置，比如搜索框，播放器页面，首页推荐卡片。
需求目的
本需求方为部门的流量产品经理，其目前负责h5的渠道入口的流量管理，她需要对这些入口质量进行评估，方便做对比，后续优化做abtest。
数据需求
获取通过每个渠道入口进入h5页面的pv，并统计这些用户在后续是否在h5的下载提示点击量，最后得到点击率
数据逻辑
本文的数据逻辑是指将使用的表逻辑，目前有2张埋点表记录了用户在h5的行为，分别名为web_show,web_click，展现在文中的表已经是经过了数据清洗，去除了无用字段
web_show
| http_refer | buvid | timestamp |
|---|---|---|
| http://xxx.com?from=a | sdfasd | 1559148871742 |
| http://xxx.com?from=b | sdfasd | 1559149871742 |
| http://xxx.com | sdfasd | 1559148875134 |
字段释义
- http_refer，用户浏览了h5页面时，会携带from=，在来源页面进行埋点后，可在url中携带跳转来源
- buvid，我司定义的用户唯一身份识别，不同公司情况不同
- timestamp，触发的时间戳
web_click
| buvid | timestamp |
|---|---|
| sdfasd | 1559148890000 |
字段与web_show表一致，该表数据记录了在某时刻点击了下载提示
分析思路
以下分析思路仅供参考，不一定百分百正确，方法可以有多种，所以希望读者能有所收获或者给出更好的方案
明确口径
拿到需求，确认了方案的可行性后，要对结果的口径进行探究，需求方提出的需求是否已经完整地明确了定义，根据其需求，我们可以初步判定：
由于表中没有识别用户的会话id，我们只知道用户经历了a页面—b页面，b页面—c页面，无法得知用户是否在同一会话中从主app的入口进入页面后，在页面点击了下载提示，也即a页面—b页面—c页面 or c事件。所以需要定义用户如何操作才会被算为有效的渠道来源并点击。
页面路径可能性
可以发现，用户从主app的渠道进入h5页面后，在页面路径上有非常多的可能性，例如：
- 离开
- 进入h5页面的另一个页面，产生了不带from的浏览记录，也就是上文web_show的第三条记录
- 点击了下载提示
- 点击了下载提示后，返回h5页面 或 时隔几小时后 点击了下载提示
- 浏览了部分页面，因为有事关闭屏幕，时隔6小时继续浏览并点击下载
- 点击下载，时隔5小时，从主app的另一个渠道进入h5页面，点击下载
- 未点击下载，时隔5小时，从主app的另一个渠道进入h5页面，点击下载
抛出疑问
根据上述情况，需要解决以下问题：
- 用户多次下载是否需要去重？
- 多次下载如果去重，选择用户的哪次下载作为计算其渠道来源的基础？判断的依据是什么？
- 选择好有效下载后，如何确定本次下载的有效入口？
- 如果从渠道进入的时机与下载时机间隔长达5小时，是否算同一次会话?
问题解决
上述问题无标准答案，我只提出本人见解：
用户的多次下载需要去重，找到其在当日的首次下载，其有效来源入口如果有多个不同来源记录，选择时间最近的记录。
而对于时间间隔的选择，我倾向于选择在1天内都算，如果4小时，那上文提到的，时隔5小时下载，难道认定不算有效下载？
时间导致的误差解决
因为数据的计算都是t+1，所以按每日的维度来计算，会产生如下问题：如果在23点50分用户从渠道入口进入，隔日0点5分下载，在本计算方案中无法被判定为有效下载，该问题无法绕过。
所以我们可以结合实际业务数据来将数据的准确性提高到最大，本人给出的方案是：
用户在24小时内，在每个时间点上有使用分布，根据数据表现得出用户在每日的24点左右活跃数非常高，但在每日的5点活跃数最小，所以我们可以将数据的计算周期不再固定为每天，而是在每天凌晨4点后的任意时间点开始自动化跑报表，时间范围为：昨日凌晨4点到当日凌晨4点，这样可以将误差的数量降到最低
SQL
由于笔者所面临的表，往往是复杂，量级大，使用的查询引擎也是hive，试错成本高，所以通常选择建立中间表，筛选后所需数据后再进行数据的统一及汇总。
具体sql的思路为
- 筛选掉show表的所有不带from的记录，并建中间表
- 清洗click表，找出每个buvid的min(timestamp)
- 将click表作为左表，join show中间表，on click.buvid=show.buvid and click.timestamp>show.timestamp
- 用窗口函数给show的timestamp降序排序，找出排名等于1的，该记录即为其有效渠道入口
- 使用聚合函数求出每日不同渠道的有效下载数
- 最后调度，形成自动化报表
总结
数据分析往往面临的业务需求，看似简单，问题颇多，口径问题首先确定，在初期的数据探索过程中，不停抛出疑问，作出假设，并用数据验证，成为自己完成业务数据需求的依据。也要与需求方多沟通，在不断的磨合中，碰撞出新的思路与解题方案。
