被割裂的数据思维（古代战争中的应用）
2021-07-04数据分析与数据产品的区别，其实也是很久一段时间困扰我的问题，直到通过在大宇无限的不断反复探索，拨开了萦绕很久的迷雾，第一次感受到了拥抱数据的真谛。
简单的一幅图是否能够揭示这场战争的本质，接下来我们会以更多的类似视角与图形呈现不一样的数据思维。
数据问题的解决方法或者理论总是被冠以众多名词，例如：数据指标、数据埋点、数据仓库、数据中台等等，到底这些在这场无形的商业战争中扮演了何种角色，值得我们深思。
接下来，我将会以古代战争的视角，带领大家去了解，我们所认识的数据。
01 起义军的建立——商业创意思想的起点
当旧社会体系与制度无法适应新思想时，历史的车轮或快或慢地开始推进；推翻旧势力的浪潮总是由代表新时代的一个或几个英雄主义人物引领，他们从普通老百姓中脱颖而出，发现核心诉求，早期的用户洞察开始形成雏形；商业创意思想源点由此产生。
有了商业创意还远远不够，如何才能够吸引更多的优秀人才加入推翻旧势力的浪潮？早期的广告推广与运营增长开始诞生；广告产品与运营增长在商业战争前中后期都是核心因素，只有以持续性的资金投入，吸引人才、技术，才能够攻城略地，获得更多价值的回报。
02 制度的确立——数据流程的约束
通过持续性的广告推广与运营增长，何种制度可以严加约束，防止内部情报数据错乱；早期数据管理流程开始确立；良好的数据管理流程是上层向下传递指令或各军事集团沟通的基础；下图展示了数据管理流程的严格约束：
制度确立后，军队数量是军事实力的主要体现，武器库存是军事实力的潜在根本；构成一整套军事实力评价的体系开始初步形成，即数据指标出现。
03 智囊团的组建——数据中台
智囊团即帮助首领或者皇帝对信息进行处理，以三国为例：
诸葛亮作为军师，汇集了军事集团的所有信息协助刘备进行决策，承担了数据中台的作用，即数据为业务赋能，提升业务价值；在隆中对话中，为刘备清晰的描绘了各势力领导者性格、实时局势与战略构想，早期用户画像、数据可视化、数据分析开始形成。
隆中对原文：
自董卓已来，豪杰并起，跨州连郡者不可胜数。曹操比于袁绍，则名微而众寡。然操遂能克绍，以弱为强者，非惟天时，抑亦人谋也。今操已拥百万之众，挟天子而令诸侯，此诚不可与争锋。孙权据有江东，已历三世，国险而民附，贤能为之用，此可以为援而不可图也。荆州北据汉、沔，利尽南海，东连吴会，西通巴、蜀，此用武之国，而其主不能守，此殆天所以资将军，将军岂有意乎？益州险塞，沃野千里，天府之土，高祖因之以成帝业。刘璋暗弱，张鲁在北，民殷国富而不知存恤，智能之士思得明君。将军既帝室之胄，信义著于四海，总揽英雄，思贤如渴，若跨有荆、益，保其岩阻，西和诸戎，南抚夷越，外结好孙权，内修政理；天下有变，则命一上将将荆州之军以向宛、洛，将军身率益州之众出于秦川，百姓孰敢不箪食壶浆以迎将军者乎？诚如是，则霸业可成，汉室可兴矣。
04 战争中新帝国的崛起——数据应用
战争即 A/B，只有不断的试错，不断的尝试，才能够得到最终的答案，早期纯人工智能诞生。
失败并不可怕，可怕的是在失败中永远的跌倒。
不断的战争积累，类似《孙子兵法》的知识图谱才能够逐步建立，针对后人，才能够辅助制定战争策略，策略产品也孕育而出；
其实我们会发现，冠以新名词后，很多商业故事都是那么的陌生；如何才能更有效的进行甄别，就是数据人应该去深度思考的问题；被割裂后的数据思维很难让我们去从一个特定的立场思考问题，因为每个人都仅仅是商业机器上的小模组。
你是否为有过以下疑问：
1. 数据流程如何制定？
2. 数据日志如何设计？
3. 数据指标的意义是什么，如何才能制定有效的数据指标？
4．如何选取数据分析的切入点？
5. 广告投放如何做？
6. 归因模型是什么？
7. 广告背后的商业逻辑是什么？
8. 数据仓库如何设计？
9. 推荐系统到底在解决哪些问题？
10. 数据策略在干什么？
…
接下来几篇文章我们将会从数据个体切入，带领大家了解数据的全貌：【数据流程的制定】。
良好的数据流程制度是数据准确性的根本保障，极大的节省非必要沟通成本，以下是在大宇无线设计的数据流程规范/约束；
数据生产流程参与的业务方有四个：数据开发工程师、数据产品、前后端工程师、业务产品。
1. 撰写日志需求阶段 —> 日志需求校验阶段面对的问题以及解决方案：
通知不及时，导致短时间大量日志设计积压；工程实施评审结束后，数据上报需求同步提交大数据，如果上线前提交，存在逾期风险。
数据需求描述太过抽象或者与实际文档术语描述不符；撰写数据需求时尽量描述正确、规范、清楚、统一，大数据协助校验，避免耗费大量理解成本。
2. 日志需求校验阶段（包含：统计类需求、时序类需求、不可实现类需求）
将原子需求、统计需求、时序需求混合提交；日志只上报原子需求，对于其他需求建议如下：
a) 统计类需求会拆解成原子需求，已有上报的不再处理。
i. 平台可配置，大数据提供配置条件讲解；
ii. 平台不可配置，提工单到数据组，写 SQL 帮助实现数据洞察。
b) 时序类需求通过 SQL 实现，无法通过日志实现，建议业务产品提交工单处理。
c) 不可实现类需求为技术或者资源限制，暂时无法提供支持，沟通后建议业务产品重新评估。
3. 日志待设计阶段
提交的日志需求已存在；已有日志可以通过以下两种方式查询：
a) 通常处理时不会不理会这部分需求，会在《XXX 版本字段设计》中重新书写查询方式，并且用“——”标记；
b) 查询《XXX 数据字段与指标字典》，在对应模块下搜索或者全局搜索需要的条件；
4. 日志设计产品校验阶段
日志设计与产品期望不一致或者查询方式过于复杂。
a) 针对期望不一致问题：初版日志设计完成以后，通知产品侧进行复核，保证当前日志需求可以满足上线后的所有查询需求；
b) 针对查询方式过于复杂问题：设计日志需要满足的四个条件包含：
i. 系统可配或者 SQL 可实现；
ii. 漏斗分析便捷或者 SQL GROUP BY 减少代码量；
iii. 数据对业务集中，而不是对动作集中；例如没必要把所有的点击行为集中在 Click 事件，会造成 Click 过于沉重，后期配置极难维护；
iv. 满足AI 或者大数据计算；例如将歌曲收藏到“我喜欢的歌曲”，一方面得上报歌曲收藏，一方面得上报歌曲点赞，后者为默认行为。
5. 工程师开发阶段
工程师开发完未告知测试，直接上线日志，数据上报错误；将版本日志测试写入 Roadmap，大数据参加产品每个阶段 Warroom，对于 Warroom 前未能开发完的需求，及时告知，后续安排时间统一进行测试修正。
因为数据未录入，导致发版后至录入前的数据缺失；一般实际工程师开发与设计日志还存在一定的出入，为了保证数据准确性，一般是开发完成后通知大数据测试，已测试结果为最终日志设计方案。
6. 日志测试通过
产品侧未收到数据验收完成通知；日志在录入管理系统后，大数据在各产品群内通知数据验收完成状态；
流程的实施需要各方协助推动，也是考验我们与外部协作的第一道门槛，只有在这场商业战争中运用合适的机制，我们才能够获得正确的信息辅助决策。