摘要
新能源汽车的客户反馈分布在试驾预约、订单确认、交付、充电和维修保养等场景。离开具体情境后再询问总体感受，往往难以还原问题发生的位置。体验家 XMPlus 通过 App 与小程序等嵌入式问卷能力，结合业务事件、身份参数、全局免打扰和发送 ID 换卷机制，将反馈采集放到关键服务触点。本文从接入链路和配置边界出发，说明如何让车主回答携带可分析的业务上下文。
一、采集设计先回答三个问题
车主打开 App，不一定刚完成充电；点击试驾预约按钮，不等于预约已经成功；收到 OTA 消息，也不意味着使用过新功能。
因此，采集设计需要先确认：用户完成了什么业务动作，当前适合评价什么，以及回答应关联哪一次记录。仅以打开页面为依据展示问卷，容易让未经历相应服务的用户参与评价。
体验家 SDK 的场景应用，需要与车企业务端配合。业务系统确认实际状态，接入层提供场景与身份，问卷采集层执行已配置的展示和免打扰规则。各环节职责明确，后续分析才能分清预约体验、试驾体验和用车体验。
二、极狐实践：按业务结果安排反馈入口
体验家在服务极狐的过程中，将问卷触达覆盖到小程序与极狐 App，围绕试驾、购买、车辆交付、车主使用和维修保养组织全旅程反馈。
项目中的触达设计包含意向金支付后的订单页、定金订单确认、新车交付确认，以及维保体验结束后的 App 场景。试乘试驾也设置了相应问卷与触达位置。
这些场景的共同点，是问卷与已发生的服务结果对应。车主评价交付服务时，系统需要有交付确认这一业务依据；评价维保时，则需要知道对应的服务已经结束。
体验家将问卷放回业务触点，使品牌能够分别理解潜客、购买客户和车主的体验。具体触发方式和时间应按各项目业务配置，不能把一个项目的触达安排当作所有车企的默认设置。
三、技术链路：事件、身份与回答如何关联
一个可实施的反馈采集链路，可以概括为：
业务状态确认 → 身份与场景参数准备 → 选择问卷及展示方式 → 免打扰判断 → 提交回答与上下文。
新能源汽车项目可以按以下方式组织参数，实际接口、字段名称和回传方式应根据各端接入文档确认。
| 信息 | 作用 | 实施要求 |
| 客户标识 | 识别同一用户及关联反馈历史 | 使用稳定且一致的标识 |
| 场景标识 | 区分试驾、交付、充电或维保 | 对应实际业务结果 |
| 服务记录标识 | 区分同一用户的多次服务 | 与本次反馈一一对应或明确关联 |
| 门店或区域 | 支持服务组织分析 | 与管理口径一致 |
| 车型、版本等属性 | 支持产品与版本分析 | 由实际数据来源提供 |
上述信息是实施设计，不是 SDK 自动产生的全套车企字段。接入时，应优先保留足以识别场景和记录的信息，再评估补充属性的方式。
对于充电与 OTA 等场景，评价对象尤其重要。可以先确认用户是否经历本次服务或使用新功能，再进入对应问题，避免把不同对象的回答混入同一指标。
四、多端接入：问卷配置需要匹配展示能力
体验家 App 嵌入支持弹窗与页面内置，并支持单选、多选、文本、表情评价、打分评价及 NPS 等题型。小程序通过 SDK 嵌入问卷，当前支持弹窗，题型范围包含单选、多选、量表、文本等；不支持的题型会被屏蔽。
因此，一份问卷在后台能够设计完成，并不意味着在每个 SDK 端都会完整呈现。实施时需要检查实际题型与渠道能力，尤其是涉及文件上传等内容的问卷，应选择适配的采集方式。
| 业务触点 | 展示设计示例 | 接入关注点 |
| 小程序试驾预约完成 | 简短弹窗 | 预约成功状态、预约记录关联 |
| App 交付服务评价 | 弹窗或页面内置 | 交付确认、服务对象与门店信息 |
| App 充电体验入口 | 与服务结束关联的评价入口 | 本次充电记录与评价范围 |
| App 新功能体验评价 | 在满足使用条件后邀请 | 功能与版本识别、问卷题型 |
这是一组应用设计示例。触发时机应兼顾业务完成与用户操作，展示频率也需要与体验监测目标配合。
五、全局免打扰：用统一身份控制重复邀请
同一车主可能从小程序预约，随后进入 App 查看订单，并在不同页面遇到不同问卷。各触点如果独立邀请，会增加重复打扰。
体验家的全局免打扰支持对单问卷多渠道或多问卷配置规则。在规则周期内，同一用户发生配置的弹出、显示、关闭或提交等行为后，可以限制其他相关问卷再次弹出。
这一机制需要在问卷中传入externalUserId，用于识别是否为同一用户。跨端一致性应在接入阶段明确：不能在小程序使用一个标识、App 使用另一个无映射标识，却期待规则自动把两者识别为同一车主。
免打扰策略可以按业务设计，例如统筹交付评价与常规使用问卷的邀请周期。具体周期及纳入问卷由项目确定，同时区分重复邀请与后续服务中有必要的新反馈。
体验家提供规则能力，车企提供稳定身份与合理的监测策略。两者配合，反馈采集才容易长期运行。
六、发送 ID：保留业务入口，调整问卷配置
产品迭代后，车企可能需要调整新功能评价问卷；交付流程变化后，也可能更换服务问卷。若每次换卷都修改业务埋点，维护成本会不断增加。
体验家的发送管理提供页面嵌入能力，可将发送 ID 嵌入接入位置，实现后续在产品内更换问卷，而不更换原有问卷埋点。它让稳定的业务入口与可调整的问卷配置分开管理。
换卷与新增场景是两类工作。在已有交付评价入口更换问卷，可以利用已接入的发送 ID；新增充电触点、增加服务结果判断或回传新的版本字段，仍需业务端完成相应接入。
问卷更新还应保留版本与指标口径。改变问题表达或选项后，不能把前后分值差异直接解释为服务改善。
七、验收从“能弹出”扩展到“回答可用”
新能源汽车 SDK 接入可以从四方面验收：业务未完成时是否误触发，同一用户的身份是否一致，回答是否关联正确服务记录，不同渠道及题型是否完整呈现。
还需要验证免打扰行为与换卷结果，并区分展示、关闭、提交和有效回答。某个入口回收率提高，只说明采集变化；是否帮助业务改善，还取决于反馈能否被定位、分析与处理。
体验家 SDK 的价值，是把车主声音与具体业务过程连接起来。当试驾、交付和用车反馈拥有清楚的场景与身份，新能源汽车企业才能持续积累能够支持产品和服务改善的数据。
FAQ
体验家 SDK 会自动知道充电或交付完成了吗？
业务系统需要提供相应结果或触发条件。页面打开和业务完成不是同一状态，问卷应与实际评价对象对应。
App 和小程序可以使用完全相同的问卷吗？
需要检查各端题型和展示支持。小程序当前支持弹窗，不支持的题型会被屏蔽，上线前应逐端验证。
多端免打扰如何识别同一车主？
需要按接入要求传入externalUserId，并保持相应身份的一致性。规则周期与纳入问卷、渠道由项目配置。
