1. 从“看数”到“用数”新能源汽车行业对数据产品的真实诉求先说个我自己的观察。前几年聊大数据大家开口闭口都是平台、集群、数仓聊的是技术栈有多新、并发有多高这两年风向明显变了尤其在新能源汽车这个赛道甲方真正关心的问题是——你能不能让我的业务直接用起来。这里说的“用”不是给你一堆报表让自己看而是数据产品能不能嵌入到业务决策、用户运营、车辆运维的每一个具体环节里。新能源汽车行业有几个先天特质决定了它是数据产品最好的试验田。第一车是高度数字化的终端一辆智能电动车每天产生的数据量非常可观车控、电池、智驾、座舱、充电、用户行为每一条都带着时间戳和位置信息。第二这个行业的业务链路极长从研发、生产、销售到售后、能源补给、用户运营每个环节都有数据需求而且需求高度垂直通用的报表工具根本喂不饱。第三行业的竞争已经从“拼参数”进入“拼体验”阶段而体验的优化离不开数据闭环发现痛点、定位原因、推送方案、验证效果这一整条链路都需要数据产品去承载。但这里有一个常见的认知误区很多团队把“数据产品”等同于BI看板觉得把指标可视化就是做了数据产品。实际上数据产品是一个比BI宽泛得多的概念。按我在项目里的习惯会把数据产品分成三类一是分析决策类就是传统意义上的报表、多维分析、经营驾驶舱二是策略执行类比如用户分群、推荐策略、风控规则这类产品不只是“看数”而是直接输出决策依据甚至自动执行动作三是能力开放类比如数据API、标签查询、算法服务让业务系统按需调用数据能力。新能源汽车行业里的数据产品往往是三类混合存在这也是它最有意思的地方。我在跟车企客户打交道时最深的一个感触是汽车行业的领导层非常在意“数据产品能否讲清楚业务语言”。技术团队辛辛苦苦搭了一套指标系统业务方打开一看字段名全是内部技术命名指标口径跟业务理解对不上那这套产品大概率会被弃用。这不是技术问题是产品设计问题。数据产品的核心不是把数据“做出来”而是把数据“翻译”成业务听得懂、用得上的东西——这件事在新能源汽车行业里尤其关键。2. 新能源车企的数据资产盘点哪些数据真正值得做成产品在动手做任何数据产品之前先得想清楚一个问题新能源汽车行业到底有哪些数据是可用的、有价值的我这几年接触过的车企数据团队资产盘点阶段做得好的项目后面基本都顺盘点做得糊里糊涂的做到一半必然推倒重来。2.1 车辆运行数据数据产品的“基本盘”车辆运行数据是新能源汽车最核心的数据资产也是数据产品最容易出彩的领域。这类数据主要来自车端T-Box车载远程通信终端按一定频率采集并上传到云端包括整车状态、三电系统状态、驾驶行为、充电行为等。以我参与过的某个头部新能源品牌的项目为例车端上报的数据经过清洗后大致可以分为几类车速、电机转速、踏板开度、方向盘转角这一类是驾驶状态类电池电压、电流、温度、SOC荷电状态、SOH电池健康度这一类是三电状态类还有充电过程的详细记录包含充电桩类型、充电功率曲线、充电起止SOC等。这些数据的价值在于它们是从物理世界实时映射过来的真实度极高不像用户填报的调查问卷那样有主观偏差。车辆运行数据的采集频次很关键。日常状态可能是每10秒一条但发生告警事件时会上频到每秒一条甚至更快。这个设计对数据产品的影响非常大日常数据量大而稳定适合做趋势分析和画像构建事件数据稀疏但极重要适合做故障定位和告警分析。在做数据产品规划时两类数据必须分开设计存储和计算逻辑否则会互相拖累性能。2.2 用户行为数据被严重低估的金矿很多车企在做数据资产盘点时精力全扑在车辆数据上用户行为数据往往被忽略。这是一个很大的失误。新能源汽车的用户行为数据覆盖了从App浏览、试驾预约、下单配置、订单支付、交付预约到用车期间的远程控制、服务预约、社区互动、积分消费等全生命周期触点。这类数据跟车辆数据一结合能产生巨大的化学反应。举个例子通过App端埋点数据可以知道用户是否经常查看充电地图、是否使用过路线规划功能再结合车辆的实际充电记录就能判断哪些用户有长途出行需求哪些用户主要在城区通勤。基于这个判断可以向前者推送补能权益包向后者推送家充桩安装服务。这种精准运营完全依赖行为数据单看车辆数据是做不到的。我自己的经验是用户行为数据的价值密度跟埋点质量强相关。很多车厂的埋点方案是供应商做的字段命名混乱、事件触点漏埋、版本迭代后埋点失效这些问题层出不穷。做数据产品之前必须先做一轮埋点健康度盘点把“数据可信度”这个基础问题解决掉。2.3 外部与场景化数据破圈的关键拼图车辆数据和用户行为数据是车企“自家后院”的资产而真正让数据产品变得聪明起来的往往是外部数据和场景化数据的融合。这里包括充电桩的位置、形态、功率、空闲状态等基础设施数据也包括地图路况、天气、交通事件等时空关联数据。在碳中和背景下未来还有一类数据会变得很重要就是车辆参与能源互动的数据比如V2G车辆到电网放电记录、参与需求响应的调度指令等。这类数据当前在很多车企的数据资产清单里还没有一席之地但头部企业已经开始了前瞻布局。数据产品经理在规划资产地图时一定要为这类数据预留位置否则后面想拓展业务场景时数据模型和产品架构都会受限。提示做资产盘点时不要只列“数据域—数据表—字段”这种清单那是给工程师看的。我建议额外做一份“业务价值标注”逐项回答“这份数据能支撑什么业务动作”这样后续产品规划和项目立项才会顺畅得多。3. 四大典型应用场景拆解数据产品怎么在业务里真正落地资产盘点清楚之后就要进入最核心的部分到底做成什么产品给谁用解决什么问题。我从实际项目中挑出四个典型场景每一个都是新能源汽车行业高频复用的做了不亏做精了能形成明显的能力壁垒。3.1 场景一智能补能与充电服务推荐新能源汽车绕不开补能这个话题。充电体验不好用户一定流失。但充电体验的提升不是靠多建桩就能解决的更需要数据产品来优化资源调度和用户触达。这个场景的数据产品核心逻辑分三步。第一步构建用户补能画像综合车辆电量状态、历史充电偏好、常用充电时段、出行规律等信息给每个用户打上标签比如“家充为主”“快充依赖型”“长途常客”“错峰充电型”。第二步做充电资源动态感知聚合各充电运营商的实时状态数据包括充电桩在线率、空闲率、排队时长、设备故障率、价格波动。第三步做个性化推荐与路径规划在用户电量低于阈值时主动推送合适的充电方案推荐的依据不是“距离最近”而是综合距离、价格、预计等待时间、沿途便利设施后的最优解。有一个容易被忽略的细节充电推荐产品如果做成App里的一个“页面”或“列表”转化率通常不理想。效果好的做法是做成“消息触达一键导航”的联动能力。数据产品计算出推荐方案后直接通过App推送触达用户点一下就能无损拉起导航。这种从“被动查询”到“主动服务”的转变是新能源数据产品设计的一个重要分水岭。3.2 场景二电池健康度监测与预测性维护电池是新能源汽车的心脏也是成本最高的零部件。电池数据产品的目标很简单提前发现问题避免用户在路上趴窝同时为电池梯次利用和二手车评估提供量化依据。实现路径是基于车端上报的电压、电流、温度、SOC等数据做电池健康度的实时评估和趋势预测。基础层需要做三件事一是单体电压一致性分析电池包内单体电芯的压差能反映不一致性压差过大就是隐患二是温度场分析重点关注充电过程中电芯温升是否异常局部高温往往是热失控的前兆三是容量衰减建模通过充放电曲线估算SOH跟踪电池实际可用容量的衰减趋势。这里我想多说一句电池数据产品最容易出现的错误是“重离线分析、轻实时告警”。很多团队把精力花在离线训练容量衰减模型上忽略了实时数据的监控价值。真正在用户端产生口碑的往往是那个“实时异常提醒”——比如充电时检测到温升速率异常系统主动降低充电功率并提醒用户检查。这个功能的数据逻辑不复杂但产品价值极高关键时刻真的能避免安全事故。再往后走一步电池数据还可以跟二手车业务打通。检测时读取车辆的SOH数据和历史充电行为数据自动生成电池体检报告这个报告可以直接作为二手车定价依据。在我接触的项目里能做这一步的车企少之又少但做出来的基本都能形成差异化的品牌信任感。3.3 场景三用户全生命周期运营与精准营销新能源汽车的用户生命周期比传统燃油车长得多从潜客获取、试驾体验、大定锁单、等待交付、新车交付、日常使用、增换购到老带新传播至少有七八个关键阶段。每个阶段的用户焦虑点不同需要的数据产品支持也不同。我把这个场景的数据产品拆成三层。底层是用户标签体系把用户画像标签化包括基础属性、兴趣偏好、行为特征、设备属性、购车意向等级等标签不是一次性建完就完事需要持续回流新数据来修正。中间是分群引擎通过规则或算法把用户分成不同的细群比如“高意向待试驾”“已锁单未排产”“提车三个月内新手”“低频使用可能流失”等。上层是策略编排不同用户群在不同生命周期阶段匹配不同的营销触达策略。这里有一个非常典型的踩坑点也是我在多个项目里反复遇到的很多车企业务团队在活动上线前一天临时要求“今天从库里拉一下所有EC6车主的家庭住址在浦东新区的准备做地推”。这种需求本身没有技术难度但对数据产品的要求是——标签即查不能等到要用了再跑数仓。做好这个场景的核心是把用户标签做成高实时性的服务化能力让业务方能自助圈选、自助导出、自助评估效果。另一个值得关注的点是首任车主和增换购车主的差异化运营。首任车主更关注充电权益、新手教学、车主社区融入增换购车主更关注政策补贴、老车置换评估、新车升级亮点。这些差异只有通过数据产品把标签、分群、触达串成一条完整链路才能实现靠业务感觉拍脑袋是走不远的。3.4 场景四自动驾驶相关的数据闭环最后这个场景稍微前沿一些但已经是头部新能源车企的兵家必争之地——自动驾驶数据闭环。一辆搭载辅助驾驶功能的车辆在行驶中感知系统会产生大量的推理结果但这些结果是否正确需要与真实路况进行比对验证。数据产品在这个场景里的角色有几个方面。第一影子模式的数据收集车辆在用户正常驾驶时后台会运行检测算法当发现“系统判断与真实路测差异较大”的场景时自动打点并回传该路段的传感器数据。第二场景库的构建与检索把回传的数据按场景打标签比如“城市拥堵蠕行”“雨天夜间匝道”“无保护左转”“施工改道路段”等构建成结构化场景库供算法团队按需检索。第三仿真测试的数据供给从真实数据中提取关键场景生成仿真测试用例反复验证算法迭代效果。做这一类数据产品最大的难点在于数据量级的处理能力。自动驾驶的数据不是按GB算的是按TB甚至PB算的。一套完整的场景库可能包括数万段数十秒级别的原始数据包每个包展开之后都是多个传感器的同步数据。“存得下、找得快、取得出”这九个字是自动驾驶数据闭环最朴素也最苛刻的要求。4. 数据产品落地的工程实践架构选型与关键配置讲完业务场景一定要聊聊工程实现。因为不管业务蓝图画得多漂亮最终都要落到数据产品能不能稳定跑起来。这个环节我主要讲三件事总体架构怎么搭、技术栈怎么选、数据治理怎么做。4.1 总体架构离线、实时、服务三层解耦新能源汽车数据产品的总体架构我习惯拆成离线数仓、实时计算、数据服务三层来设计。这个拆分不是追求技术上的“高级感”而是因为三类计算负载的特性差异太大了硬塞在一起只会互相拖累。离线数仓承担的是T1的批量加工负责用户画像、经营分析、指标报表、历史趋势等场景。这一层的数据量最大作业调度最复杂但对实时性没有要求。实时计算承担的是秒级到分钟级的流式处理负责车辆告警、充电状态感知、用户实时位置触达等场景。这一层的核心诉求是低延迟和高可用计算链路不能断。数据服务层则是统一对外的出口封装查询API、标签服务、指标服务让业务系统按标准协议取数不需要关心底层是离线还是实时。这个架构里最重要的一个设计原则是业务系统不能直接查数仓或Kafka必须统一走数据服务层。这样做的好处太多了一是可以统一权限管控避免数据越权访问二是在底层表结构变动时不影响业务方三是可以加缓存和限流防止业务流量直接把数仓打挂。我在项目里见过太多“业务方直连Hive查数”的案例最后都付出了血的代价。4.2 技术选型没有银弹只有适配技术栈的选择没有标准答案但我可以给一个经过验证的参考组合。存储方面明细层和汇总层用ClickHouse它的列式存储和向量化执行引擎在聚合查询场景下非常能打标签服务和高并发查询场景用StarRocks或Doris它们对高并发点查的支持比ClickHouse更好实时消息链路用Kafka事务和数据一致性要求高的核心链路用Pulsar。计算方面离线调度用DolphinScheduler实时计算用Flink这两个方向基本是行业主流。值得一提的是很多刚做数据产品的团队会陷入“为了用某个技术而用某个技术”的误区。比如一上来就搞数据湖业务场景其实连Hive都还没用好或者一定要上Flink CDC结果业务对实时性的要求根本没到秒级。选型的核心逻辑是先看业务对时效性、并发量、数据量的真实要求再反推技术栈。技术是为业务服务的这句话在数据产品领域尤其适用。还有一个我强烈建议的建议在初期架构中预留好“数据服务层”的标准化接口设计哪怕先用简单的Restful API实现也行但一定要把接口协议和数据格式约定好。后面一旦业务量上来服务化改造的成本就会非常高。预先定义好规范是性价比最高的投入。4.3 数据治理决定数据产品生死的基础工程数据产品做得越多我越觉得数据治理不是“锦上添花”而是“生死存亡”。一个指标叫“用户数”运营部门说按注册口径算产品部门说按活跃口径算市场部门说按线索口径算最后数据产品给出来的数永远是“对不上”。这种问题在新能源车企里尤其常见因为业务链条太长部门墙太厚。我的实操经验是不要试图一次性把数据治理的全部问题解决掉那是做不完的。正确策略是“先定标准再建机制最后做工具”。第一步先把指标体系里的核心业务指标理清楚输出指标定义文档明确口径、统计周期、维度归属、责任人第二步建立变更审核机制任何指标口径的调整都需要走评审流程不能随随便便改第三步用工具将指标管理固化下来形成指标字典和血缘关系图让数据的来龙去脉可追溯。举一个充电场景下的真实案例。团队一开始把“充电订单数”定义为“用户在App上成功发起充电预约并完成支付”的次数后来发现被充电运营商接口的“充电启动记录”给带偏了两个口径差了将近30%。这种问题不靠治理机制约束靠口头沟通是永远理不清的。注意数据治理容易陷入“为了治理而治理”的泥潭。我见过一个项目团队花了三个月建数据资产平台业务侧实际使用的核心指标只有十几个。如果指标数量不大直接用一个在线文档维护指标字典就够等指标规模上来了再上工具。先跑起来、再优化远比憋大招靠谱。5. 上线之后产品迭代、效果评估与常见踩坑避雷数据产品跟普通App产品最大的不同是它对“数据本身的正确性”极其敏感。功能做出来了算法跑了但底层数据某一天出错了用户不会关心原因是“埋点丢失”还是“上游解析故障”他只会觉得“你们的数据产品不靠谱”。所以上线之后的工作一点都不比开发阶段轻松。5.1 效果评估数据产品也要看ROI数据产品的价值度量一直是个难题。我见过很多团队做完一个数据产品交付了就当成项目结束没有定义任何效果指标这是很可惜的。数据产品也应该像业务产品一样明确自己的“北极星指标”和“辅助指标”。以充电推荐产品为例北极星指标可以是“推荐内容的点击—导航转化率”辅助指标包括“人均充电等待时间下降”“低电量求助呼叫下降”“充电桩利用率提升”。以电池健康度产品为例北极星指标可以是“热失控事件预警准确率”辅助指标包括“维修工单响应时长”“电池续保率”。这些指标在需求阶段就应该定义清楚而不是等产品上线才补。我也要提醒一句也不能把业务结果的改善全部归因到数据产品身上。充电转化率的提升可能来自新上线的充电优惠活动电池维修效率的提升可能来自售后服务流程的流程再造。做效果评估时最好能做简单的实验组/对照组对比或者至少做一个“产品上线前后”的对比分析并尽量剔除其他业务动作的干扰。5.2 常见避坑点那些“不做不知道做了吓一跳”的坑第一个坑是“历史数据转换不彻底”。很多数据产品上线时需要依赖历史一年甚至更久的数据做模型训练但历史数据往往是残缺的。供应商数据丢失、车端时间异常跳变、单位不统一比如有的软件版本上报车速是km/h有的是m/s这些问题在历史数据里俯拾皆是。建议在数据产品上线前专门做一个历史数据的完整性检查和清洗否则模型效果一定会让你怀疑人生。第二个坑是“车端数据上报的延迟和乱序”。实际业务中车辆在地下车库或偏远地区长时间断网后重新联网会把断网期间缓存的数据集中补报上来。这种数据一旦进入实时链路会导致短时间内的数据堆积和计算延迟。处理办法是在实时计算链路中加上“事件时间”窗口按数据的实际发生时间计算而不是按到达时间计算。这算是一个经典的实时计算问题。第三个坑是“多租户数据权限边界不清”。做面向内部多部门的数据产品时需要明确哪些数据部门间可以共享哪些是由特定团队独有。比如用户手机号是敏感信息运营团队可以用但外部合作方不能看车辆的精确位置数据也有合规要求需要做区域粒度脱敏。权限设计一定要在需求阶段做而不是等出了安全事故再做。第四个坑是“产品做出来没人用”。这是最尴尬也最常见的情况。原因往往是产品经理闭门造车没有真正理解业务方的使用场景。我的解决思路是做数据产品必须“跟着业务走”至少三个月。每个迭代版本产品经理要和一线业务团队一起看数据、一起复盘这样才能真正捕捉到业务方没说出口的需求。数据产品做得越久我越觉得“同理心”比“模型能力”更重要。6. 未来演进方向数据产品在新能源汽车领域还能走向哪里写完这些我还是想聊几句未来。做数据产品最迷人的地方就是它永远有增量空间。新能源汽车行业的技术迭代速度非常快数据产品也必须跟上节奏才能不掉队。我判断未来三到五年新能源汽车行业的数据产品会在几个方向出现明显升级。一是从“单车型数据产品”走向“全车队数据产品”车辆数据不再孤立而是纳入整个车队网络统一调度比如充电调度要考虑到多辆车的电量需求和充电资源分布做协同优化。二是从“被动响应”走向“主动干预”数据产品不只做告警和分析还会直接联动车控和能源系统在发现潜在风险时自动采取措施比如提前调整电池热管理策略。三是数据产品的“外部化”车企的数据能力会通过API等方式向出行服务商、保险公司、二手车平台等第三方生态开放从内部能力变成行业基础设施这会带来全新的商业想象空间。再一个值得关注的趋势是数据产品与大模型能力的融合。比如用大模型来做自然语言查数用户直接问“上个月华东区的充电订单量环比变化了多少”系统自动拆解指标、生成查询、输出结论。我在一些团队里已经看到了原型探索效果相当惊艳。这意味着数据产品的使用门槛会进一步降低业务决策的效率会更高。我自己在实际项目里最深的一个体会是数据产品在新能源汽车行业的本质不是技术竞赛而是“数据思维”和“业务思维”的深度耦合。技术只是载体真正难的是用数据的方式去理解和重构每一个业务动作。深谙业务的数据产品经理会在未来几年成为这个行业里最抢手的复合型人才。而把这件事做扎实的团队也一定会在这个赛道上形成非常强的数据壁垒。