谛听是地藏菩萨经案下伏着的通灵神兽 ，可以通过听来辨认世间万物，尤其善于听人的心
# 谛听的功能介绍
# 定义
谛听是一款支持业务在经营管理时，做监控数据二次加工的报表工具，旨在帮助用户提升数据获取和处理效率。
# 名词解释
| Term | Translation | Definition |
|---|---|---|
| 业务前线（一线） | Frontline Sales Manager | BD/BDM/CM等角色统称 |
| BA | Business Analyst | 商业分析师 |
| BD | Business Developer | 销售专员，负责根据公司发展战略，负责餐饮及本地生活综合品类的商家合作，达成公司销售目标 |
| BDM | Business Developer Manager | 销售主管，负责拆解业务指标，带领团队熟悉公司相关业务流程和行业知识，分析市场动态，结合公司策略优化市场供给 |
| CM | City Manager | 城市经理，负责了解行业政策，结合部门中长期目标，分析拆解业务指标，制定区域城市策略，提升城市门店覆盖率 |
| 业务线 | Sales Department | 根据目标用户(target audience)不同，分为直营（自营）、合作商、KA/CKA（大连锁，例如KFC）、拼好饭、校园、白领等多种不同的业务线 |
| 跑数 | ETL(Extract, transform, and load) | 跑数是数据仓库和数据分析系统中的重要环节，用于整合分散的数据，为企业提供可靠的数据基础，支持数据驱动的业务决策和运营优化。跑数包括三个步骤： 数据抽取（Extract） 数据转换（Transform） 数据加载（Load） |
| 多租户架构 | Multi-Tenant Architecture | A multi-tenant application is customized for every group of users (so-called tenants) while the entire architecture and core functionality remain the same. |
# 背景
# 为什么要做数据中台
打造数据中台(Middle Platform)的愿景是打造数据驱动的智能企业。
“业务中台就是在产生数据，数据中台是做数据的二次加工，并将结果再服务于业务，为业务进行数据和智能的赋能。” —— 阿里巴巴技术方案总监谢纯良在一次InfoQ采访中提到
平台化思想 Platform Thinking 鼓励企业不断抽象沉淀自己核心的底层能力，通过平台化包装，得以更好地赋能前台业务，用底层的确定性来帮助企业应对前台业务以及最终用户需求的不确定性。
中台化是平台化的下一站，是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台业务赋能，真正为前台而生。
对前、后台的定义
前台：由各类前台系统组成的前端业务平台。每个前台系统都是一个用户触点，大多是企业最终用户直接使用的系统，是企业与最终用户的交点。例如用户直接使用的网站、手机App、微信公众号、小程序等都属于前台范畴。
后台：由后台系统组成的后端支撑平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台。
数据中台与传统数仓和数据平台的区别
对于数据中台与传统数仓和数据平台的区别，关键在于数据中台相对于数仓、大数据平台，向前台、向业务又迈出了一步，不再只是关心技术层面大数据底座的打造，同时开始更多地关注企业层面的数据治理以及数据资产化的内容。
在IT圈有一句老话，“任何软件工程遇到的问题都可以通过增加一个中间层来解决”。
而在企业层面，中台这个新的中间层的产生，就是为了调和这个“灵活”与“经济”的矛盾。
前台纵向，承载了企业的灵活性；中台横向，承载的是企业的经济性；而前台与中台的分离、博弈与平衡，本质上就是企业作为一个整体灵活性与经济性的分离、博弈与平衡。
# 为什么要做谛听
谛听对于商业分析的价值
对比友商（elem）做的监控型商业分析，美团做是策略型商业分析，在保证业务健康的同时帮助业务成长。策略型商业分析包括了业务链条中若干个关键的环节：作战规划，目标设定，目标拆解，资源分配，过程监测，问题诊断，效果评估，最后做绩效认定。
2021年 Quarter2（第二季度），产品组业务数据策略组首次上线了一款新的数据产品工具—— 谛听自助监控工具 （以下简称谛听）。作为数据产品在工具方向上的尝试，谛听主要瞄准了业务一线（Frontline sales managers，以下简称一线）日常做数据加工的场景，希望以更高效的方式支持一线日常的数据监控过程。有了这款产品，一线不用再饱受数据制作麻烦和就绪延迟的困扰，不用再在数据加工上做一些重复劳动。而这样一款省力省心的工具也仅仅只是需要一些低门槛的操作就能达到理想效果。
A frontline worker is any individual—regardless of education or industry—who works directly with customers, clients, or other recipients of services
据了解，外卖业务前线的管理层1000多人，其中直营BDM-DM约901人，代理渠道经理及以上约210人，超过90%的人在日常需要对现有产品数据做二次加工，从而形成业务独有的日常监控报表。超过70%的人日常需要维护1~2张excel汇总表，而每个excel表内又包含10~20个sheet，十分复杂。
例如一个CM（City Manager，城市经理）想要对本月的策略执行过程及效果做一个监控，初始建模时要先从10-20个数据源中导出原始数据，再耗费0.5-4h在excel中做公式加工，最后再每天耗费15-30min对这个excel进行手动更新……如果不幸遇上数据源就绪延迟个一天半载，又会导致整个做数过程再往后移，进而导致其团队无法在每日晨会及时指导当日行动。
如今，有了谛听工具，上述灵活度和时效性的问题均能得到极大程度地解决。用户只需要在谛听工具里筛选需要加工的基础数据，再通过谛听的指标加工&分享功能就能实现个性化报表配置及应用。同时谛听还有一些自动化的功能比如自动生成指标释义以及每日9点前自动更新数据，用以缓解用户做数、对数和等数的压力。
深圳一区CM李德彬是最早一批加入试点的用户，目前已成为用户标杆。他率先在8月PK赛期间使用谛听做数据监控，在非试点用户都在为魔数跑不出数而叫苦不迭的时候用谛听顺利跑出了结果，并通过在一线群里“炫耀”而成功为谛听转化了一批新用户。在他的带动下深圳七区CM彭婷于2021年9月正式加入试点，在体验到谛听的好处后迅速成长为谛听活跃用户，在短短一周内就用谛听配置了19张报表，并强要求下属BDM也用谛听做日常监控。这种真实存在的例子还有很多，成为谛听不断优化不断迭代的安慰和动力。
谛听解决的问题
在后台产品2020年H2满意度调研中，和数据产品相关的问题，有93%（130/140）的人吐槽了日常数据监控的痛点，其中有29%的人更是直接吐槽了在数据加工上做重复劳动的问题。除了因为调研而被动发声，还有不少人实在不堪其扰而主动发声，寻求帮助。例如某CM在内网发帖吐槽在日常做数时需要反复大量导数，失误概率大，成本高。又如某BDM在社区吐槽PK赛期间用的数据看板整天刷不出数从而严重影响正常工作……
前后对比
在没有谛听时，一线是怎么满足自己的需求的？
一线主要通过两种途径来解决：
看板：在区域或大区层级相对通用的需求统一提给业务中后线，申请BI专人通过SQL定制化搭建看板（原本业务运营组通过SQL语句为前线搭建临时报表，前线在门户上查看报表结果）。
通用报表：相对零散的需求由一线自行导出源数据，再在线下用excel加工。整体加工步骤分为：1.取数 2.excel加工制作 3.每日更新excel数据 4.查看结果
他们这么做有多痛苦？
对于中低阶管理层线下做数，几乎每一步都感到痛苦：
取数，入口分散。现有数据源有10-20个，每次都需要从这些入口分别导数再拼接。
制作，费时费力。基于下载数据，通过函数制作出相应的模板。这个制作包括用vlookup、if、sumif等各种函数公式，对线上导出的10-20个原始表进行组合加工，一般要耗费0.5-4h。而实际上一线无论是数据分析能力上，还是工作环境上（外出陪访以及开会沟通，在数据分析上无法投入较多时间）都决定了他们其实并不擅长这方面工作。
更新，重复劳动。为了每日看到最新的数据，用户需要每日重复从这10-20个数据源导出、筛选、粘贴进模板，从而更新报表数据，一般耗时 15-30 min/day。更新过程中哪怕有一个模板列或一个数据源发生变化，又要花额外的精力来校准甚至重建，可能超过半小时。
查看，看数滞后。前线每天有早9点晨会机制，需要在晨会前将制定好的个性化数据进行手动数据更新。但经常遇上数据源就绪延迟，轻则半小时，重则一整天，导致一线无法在每日晨会及时指导当日行动。
对数，不明口径。日常更新完数据向上汇报时，由于线下不同城市各自为营，指标口径不透明，导致在向上汇报或横向对标的时候需要花费大量时间对齐口径。比如同样叫“重点商家红包覆盖率”，不同城市重点商家的定义就可能不同，对红包类型、档位、在线天数等细节要求也不同，覆盖率是指商家、交易额、订单还是其他也不相同。
对于高阶管理层，痛点主要在于：
生产周期长，从业务侧提需求到最终报表上线一般要1-2周的时间。
口径不明朗，指标细节口径通常被包装在SQL语句内部，难以外化给大众用户，每次为了弄清口径还得现查SQL。
月底查数慢，月底大批量高并发查询，由于SQL性能限制导致跑数慢。
谛听的出现有效应对了上述取数成本高、周期长、对数难、不安全等问题。它以拖拽式配置的方式，帮助一线业务团队实现自助取数和加工整合，满足不同场景的个性化数据监控需求。用户只需要在谛听工具里筛选需要加工的基础数据，再通过谛听的指标加工和分享功能，即可实现个性化报表配置及应用。
# 我的工作
实施、维护和重构了谛听自助监控平台，该数据产品工具使一线业务分析师能够通过拖放手势进行自助数据检索和集成，从而获得良好的用户反馈。
Implemented, maintained and refactored Crm-Diting Monitoring Platform, a data product tool that enables frontline business analysts to perform self-service data retrieval and integration in drag-and-drop gestures, resulting in good user feedbacks.(我的简历内容)
# 问题背景
谛听试点成功后，亟需扩大其涵盖的业务领域和使用场景，提升BD数据使用率，服务于更多的团队，将谛听的能力输出给其它产品。
# 目标
应对数据激增带来的问题：扩展支撑业务诉求，提升指标丰富度和业务线、数据实体类型的扩展能力；
重构和治理系统：在保证系统性能和稳定性的前提下，提升新业务线、新数据实体类型的接入效率。
# 我的贡献
多租户架构
采用多租户架构，将不同业务线映射到不同的路由上，实现权限隔离
功能配置化，简化数据模型和业务模型，使系统具备高度的灵活性和可扩展性
重构和治理系统
过去，谛听在技术设计上过于依赖前端判断逻辑，导致增加或修改的成本、风险较高（导致大范围的功能受到影响），因而需要花费较长时间进行测试，以排除故障。为降低业务扩张的开发成本，为决定用单例模式、适配器等设计模式来承载部分复杂的业务逻辑，将数据源存储在状态管理器进行集中管理，提高其状态变化的可预测性；以函数形式封装对数据的访问，使业务线数据得以独立存在，在不修改原有业务逻辑的情况下，增强代码的灵活性和可扩展性
遵循了“营地法则”（保证你离开时的代码库一定比来时更健康），在支持业务需求迭代的同时，以较小的步伐重构代码，逐步将逻辑与数据解耦，将业务线和报表实体类型作为函数输入而非过程变量，减少函数副作用，从而在不过多提升代码复杂度的情况下，使报表支持兼容本地草稿、服务器备份、复制报表切换子业务线三种数据处理逻辑分支等复杂业务诉求。
精简交互
- 对用户隐藏数据结构复杂度，尽量沿用并保持与已有功能一致的交互模式和设计风格，这样，用户无需关注底层实现细节，从而减少了用户学习成本和适应时间，使他们更能够更专注地使用功能。
美团数据
今年8月8日（立秋），美团即时配送单量峰值超过8000万单，创造出了新的历史记录
美团发布2023年Q2财报：营收680亿元，同比增长33.4%