最近有个朋友来找我说要做十个互联网医院平台的横向对比。他一开始的打算是把官网首页、功能清单和收费标准截图排成一张大表最后按有/没有打钩。我听完直接摇头如果对比只做到这个颗粒度报告不仅没法指导采购决策还会在第一次集体评审时被业务方问住因为每个平台的数据并不是在同一个口径、同一个时间段里拿到的。后面我帮他重新搭了一套做法核心就围绕三件事指标、采样频次、代码骨架。这套思路不限于十个平台做采购选型、竞品分析、产品规划或者例行巡检的朋友都可以直接参考。下面我会把可量化的指标定义、采样时间窗的处理方式以及一个能跑起来的小骨架代码一起说清楚。1. 一次横向对比为什么拖了两周1.1 从功能列表打分到可量化指标的转变第一次整理指标表时我列出的内容还是是否支持在线问诊是否支持预约挂号是否有电子病历这类布尔型字段。功能列表确实能说明部分问题但没法回答体验差距有多大。比如用户点击在线问诊入口5秒打开和25秒打开在功能列表里都显示为支持在线问诊实际感受差了一个量级。后来我把指标改成首页首屏完成时间问诊入口点击到病情描述页加载完成的耗时支付结果回调成功率等才有可比性。可量化的数值是横向对比的地基布尔字段只能作为门槛条件不能作为排序依据。选可量化指标时我不会做一个特别庞大的指标池而是先把用户核心任务画出来浏览首页、搜索医生或科室、发起在线问诊、上传资料、等待医生接入、查看回复或处方、在线支付、查看报告。每个任务对应一到三个关键指标整个指标控制在20到30个左右避免最后数据收集成本过高。这个环节需要业务和技术同事一起开会因为只有业务才能解释问诊完成到底要走到哪一步只有技术才能判断采集方式是否可行。然后要把指标定义写死。同样叫问诊响应时间有的人统计的是用户提交问题到AI自动回复的时间有的人统计的是人工医生首次回复的时间如果不定义清楚后面比对全是噪音。到这一步拖了快一周时间主要花在统一口径上。1.2 采样时间窗不一致是结论被推翻的根源第一版数据其实已经跑出来了但我拿到底层记录一看发现平台A的数据是上午9点采集的平台B是下午3点平台C是晚上10点。而互联网医院平台的服务依赖真实医生在线状态、客服值班时段和系统负载不同时段差异非常大。比如晚上10点在线问诊入口依然可以点进去但医生接入时间可能是白天的几倍。用不同时间窗的数据直接做横向对比等于用一把不准的尺子量所有东西。所以方案里必须规定采样频次和轮巡顺序。同一轮对比要在一个尽可能短的时间窗口内完成理想情况下控制在20分钟以内如果十个平台逐个跑完需要更久就把一次轮巡拆成多轮随机抽样。轮巡实现起来不复杂但要在数据模型里给每条记录打上轮次标识后面才能正确地分组对比。时间窗和采样频次这个问题后面第3章会专门展开。1.3 写代码骨架的目的不是自动化全部而是固定口径还有一个容易被误解的点用代码做横向对比目的不是为了每天自动跑几十次而是为了把采样口径和执行过程固定下来让任何人都能用同一套逻辑复现。比如对于首屏时间不同平台入口可能是App、小程序或H5跑法都不一样但每次记录的字段、时间戳、失败原因都要统一。先写出一个可扩展的代码骨架后续每接入一个平台只需要补一个配置和适配探针不用重写整套框架。我现在做横向对比项目第一步永远是写指标定义表和采样调度文档第二步才写代码骨架。代码骨架不是部署一个监控系统而是用代码把用什么时间、测哪个入口、记录哪几个字段固化下来。只要口径在代码里保持一致报告本身就会稳定很多。2. 对比指标怎么定按患者就医旅程拆解而不是官网功能列表2.1 四层指标稳定性、核心路径、功能覆盖、服务体验在新增平台到调查矩阵时我把指标拆成四层基础可用性指标、核心业务路径指标、功能覆盖指标和服务体验指标。第一层是基础可用性包括各平台首页、登录页、搜索页的HTTP状态码、首屏时间、错误率、DNS解析耗时等。这一层直奔能不能打开打开快不快。第二层是核心业务路径围绕完整就医流程设计比如从首页进入在线问诊、选择科室、选择医生、填写病情、等待回复、查看处方、支付、查询报告这一条链路在每一步记录成功率和耗时。第三层是功能覆盖记录是否支持特定科室、检验检查预约、电子发票、健康档案等这部分可以用布尔字段但只作为横评里的门槛指标。第四层是服务体验包括医生首次回复时间、客服接通时间、退款到账时间、页面崩溃率等这些指标最能反映真实体验也最难稳定测量。2.2 指标的可操作定义首页首屏成功到底怎么算很多人写指标定义时只写首页打开时间识别度很低。需要明确从哪个动作开始计时到哪个事件结束计时成功和失败怎么判定。对于H5页面一般从发起URL请求开始到浏览器首次绘制完成是首屏时间如果页面出现白屏超过阈值但HTTP 200也要记录一个业务性失败。对于小程序和App需要从点击入口开始计时通过页面生命周期事件标记完成。我在实践中会把每个指标公式化写成类似下面这样指标名称开始计时点结束计时点成功判定备注首页首屏时间发起入口URL请求首屏内容渲染完成页面出现目标元素排除网络断连问诊路径成功率点击问诊入口到达等待医生回复页目标页面元素出现过滤自动跳转医生首次回复耗时用户提交病情描述医生发出第一条有效回复回复文本非系统话术无法采集时标记缺失在线支付成功率点击支付按钮支付结果回调成功后端状态为成功仅测测试订单只有这样的定义才不会在整理报告时出现同一个名字、两套口径的问题。我觉得一个很实用的方法每条指标都写一句如果采集不到要记录哪些原因。例如登录墙、验证码、需要实名认证、需要绑卡这些都是合理的缺失原因。凡是缺失原因不同的数据在横评时都不能简单归为不支持。2.3 容易被忽略的异常旅程指标退费、改约、客服接通做横向对比时大家常把注意力放在正常路径上真正让用户流失的却往往是异常路径。比如预约了门诊但需要改约平台是否支持在线取消和改签支付后需要退费退费是原路返回还是需要联系人工遇到问题想找客服客服入口深浅、接通速度如何。这些路径平时流量不大但一旦发生直接影响信任感。我第一次对比就漏了退费指标结果在一次试挂号的测评中某平台钱付了但找不到退费按钮最后只能打客服电话确认整体体验评价立刻下降。所以在第二层指标里我给每个平台至少设计了两条非主流路径一条是取消或改约一条是退费或申诉。这类指标采样频次不需要很高一个月跑一次也可以但必须纳入横评维度。2.4 指标字典让口径变动有迹可循如果团队规模超过两个人建议维护一份指标字典文档里面记录指标名、定义、采集方式、采样频次、负责人和变更历史。很多时候口径变化不是因为故意而是因为平台改版、探针升级、网络环境变化。只要指标字典更新不及时后面统计分析的人就很容易把新旧口径的数据混在一起。我做指标字典时会给每个指标一个英文标识例如first_screen_time、consult_path_success_rate在代码、数据库字段和报告里都用同一个标识。这样避免中文名在多个场景里出现歧义也方便代码骨架直接引用。指标字典不是一次性的每次横向对比结束都要复盘一次把这个指标到底有没有区分度记录下来。没有区分度的指标直接删掉不要为了凑数保留它。3. 采样频次设计十个平台到底多久测一轮才算公平3.1 轮巡采样同一时段内跑完十家而不是各测各的横向对比最忌讳的就是今天测A明天测B。要让十个平台处在可比状态就要在尽可能短的时间窗口里把它们全部采集一遍。时间窗口的选择取决于平台数量的多少。如果只有5个轻量H5页面一轮十几分钟能完成如果包含小程序、App可能一轮超过50分钟。这时需要把巡检脚本设计成轮巡模式每整点或半点触发一次跑完平台列表后进入等待下一轮按随机顺序重新开始。随机顺序是为了避免固定顺序导致某些平台总是处于被测环境的冷状态或热状态。时间分配上我习惯用一个轮次ID把每次触发产生的一组记录串起来后面做报表时按轮次分组而不是按平台分组。这样能看到在同一个轮次内哪家平台慢、哪家快长时间积累后又能看到每家平台在不同时段的变化曲线。轮巡不追求同时这个绝对概念只要保证单轮窗口可控横向对比的置信度就够了。3.2 波峰波谷怎么处理早中晚三窗口 持续监测医疗服务有自己的流量节奏白天上午有挂号问诊高峰工作日晚间有图文咨询高峰周末上午儿科和慢病咨询频繁。因此每轮巡检之外我还设计了固定三个主窗口早间巡检、午后巡检、晚间巡检。每个主窗口跑两到三轮每轮覆盖全部平台。连续监测的探针则只盯少数关键页面每10分钟跑一次用于观察单平台在长周期里的抖动不参与横向对比。对于需要模拟真实用户操作的探针比如填写病情描述、发起问诊我建议频次不要太密避免给被测平台带来压力也让账号状态更稳定。“高频探针”放到可匿名访问的公开页面“低频业务探针”每天最多跑五轮。如果你只是想一次性选型建议至少连续跑五到七天且每天都有早、中、晚窗口这样数据才能覆盖工作日和周末的差异。3.3 样本量不够时的聚合策略中位数、P90和离群值几天采样下来每个平台同一个指标往往有几十到几百个样本。整理数据时不能直接把所有值求平均因为偶发性超时或CDN回源抖动会把平均值拉偏。我一般这样聚合先按轮次ID去重再对同一平台、同一指标、同一窗口内的数据计算中位数、P90和样本数同时保留最大最小值用于排查异常。报告里展示的排序优先看中位数P90作为判断稳定性的辅助。如果一个平台的中位数很漂亮但P90翻了好几倍说明它的服务质量波动大这个平台要谨慎推荐。如果某个平台在某轮采样中因为登录失效、验证码拦截导致数据缺失我不会用上一轮数据补填而是标记为本轮缺失在报表里留空。这样虽然排名时该平台样本量少但比较关系仍然可解释。缺失次数超过总轮次30%的平台建议直接红色告警因为连测评环境都进不去真实用户遇到的概率大概率更高。3.4 环境基线手机型号、浏览器版本、网络类型都要固定采样频次之外还有一个很容易被忽略的因素环境基线。同一个平台在WiFi、4G、5G网络下测出来的首屏时间可能差好几倍在最新版Chrome和旧版Safari里的表现也不一样。所以每轮采样记录里必须同时记录被测环境的浏览器版本、操作系统、网络类型、地域节点。如果是一组人手动采样还要规定大家统一使用某个测试网络和测试设备。我在代码骨架里会把环境信息写到每一条结果里作为固定字段。这样即使在对比过程中换了网络环境也可以在分析时先筛选环境基线一致的数据再判断平台之间的差异。没有环境基线的数据很难判断问题出在平台还是出在测试端。4. 代码骨架一个可以由0到1的对比巡检脚本4.1 模块划分与平台配置分离代码骨架不是什么复杂框架核心是三层结构调度层、探针层、存储与报表层。调度层负责轮巡时间与并发调度探针层负责具体采集动作比如HTTP请求、小程序自动化操作、App自动化存储与报表层把结果写到本地数据库或文件再生成对比表。为了让平台接入成本尽可能低我把平台信息放到YAML配置里每个平台只需要配置入口URL、登录方式、需要执行的探针列表等。探针则通过注册表按名称创建新增平台时写一个适配器类即可不修改调度层代码。4.2 最小骨架代码Runner、Probe、ResultStore下面给出一段能跑通思路的最小骨架示例使用Python依赖只用到标准库和requests。实际工程中建议结合Playwright做浏览器自动化原理是一样的。import time import json from pathlib import Path from dataclasses import dataclass, asdict dataclass class ProbeResult: platform_id: str probe_name: str round_id: str ok: bool metric_value: float status_code: int error: str raw_snippet: str class BaseProbe: def __init__(self, platform_id: str, config: dict): self.platform_id platform_id self.config config def run_once(self, round_id: str) - ProbeResult: raise NotImplementedError class HttpOpenProbe(BaseProbe): def run_once(self, round_id: str): import requests start time.perf_counter() try: resp requests.get(self.config[url], timeout15) cost_ms (time.perf_counter() - start) * 1000 return ProbeResult( platform_idself.platform_id, probe_namehttp_open, round_idround_id, okresp.status_code 200, metric_valuecost_ms, status_coderesp.status_code, ) except Exception as exc: return ProbeResult( platform_idself.platform_id, probe_namehttp_open, round_idround_id, okFalse, metric_value-1, status_code0, errorstr(exc), ) class ResultStore: def __init__(self, output_dir: Path): self.path output_dir / results.jsonl self.path.parent.mkdir(parentsTrue, exist_okTrue) def save(self, result: ProbeResult): with self.path.open(a, encodingutf-8) as f: f.write(json.dumps(asdict(result), ensure_asciiFalse) \n) class CompareRunner: def __init__(self, platforms: list, store: ResultStore): self.platforms platforms self.store store self.probe_registry {http_open: HttpOpenProbe} def run_round(self, round_id: str): for p in self.platforms: for probe_cfg in p[probes]: probe_cls self.probe_registry[probe_cfg[type]] probe probe_cls(p[id], probe_cfg) result probe.run_once(round_id) self.store.save(result) if __name__ __main__: platforms [ {id: A, probes: [{type: http_open, url: https://sample-a.example}]}, {id: B, probes: [{type: http_open, url: https://sample-b.example}]}, ] store ResultStore(Path(./data)) runner CompareRunner(platforms, store) runner.run_round(20250101-1200)这段代码把探针存储控制层分开了。实际项目里你只需要把probe_registry替换成你的探针类把平台配置改成名单就能跑起来。关键不在于代码量而在于每条记录都带有round_id、platform_id和probe_name没有这三个字段的数据是没法做横向对比的。4.3 用round_id把同一轮数据对齐round_id是采样调度设计里最重要的字段。它的取值建议用固定格式比如YYYYMMDD-HHMM-时段类型因为只从时间戳就能判断这是哪一轮的数据。在报表聚合时先按round_id分组再在组内按平台对比。这样能避免平台A的记录对应的是上午平台B的却是下午。这个细节在人工采集时很容易被忽略但在代码骨架里从数据模型上就做了限制。如果某个探针一轮中需要跑多次比如为了采集P90那么在round_id后面可以再加一个sample_index。举例20250101-1200-04表示这一轮里第四次采样。这样既保留了轮次对齐能力又不会丢掉样本明细。4.4 报告生成与异常标记当数据积累几天后就可以写聚合逻辑了。通常按round_id和窗口类型聚合输出一张宽表行为平台列为指标值为中位数或P90。我给报告增加一项异常标记规则很简单当前平台某指标的中位数超过所有平台中位数的1.5倍或P90超过设定的硬阈值就标记为黄色如果连续三轮都是黄色标记为红色。在选型报告里红色项不允许直接通过除非业务方给出明确的接受理由。平台首屏中位数(ms)首屏P90(ms)问诊路径成功率异常标记平台A1832284098.2%无平台B2104521096.5%稳定性波动平台C3560684088.1%黄色不过这里要强调代码骨架不等于全部自动化。一些需要真人账号和业务动作的采集必须加上人工复核步骤否则很容易把技术不可达和业务不可用混淆。4.5 从最小骨架到十平台适配随机巡检与登录态管理把最小骨架扩展到十个平台时我一般会再加两个能力。第一个是随机顺序平台列表在每轮开始时用random.shuffle打乱避免固定顺序影响结果。第二个是登录态管理需要登录的探针统一维护一个会话池每个平台最多同时两个账号在线执行完业务动作后主动登出防止账号被风控。登录态管理最好的方式是通过平台提供的接口获取临时凭证而不是在代码里硬编码密码。代码骨架本身就是一个活文档。新同事接手横向对比项目时不用去翻过去十几个Excel表只需要看探针代码和指标字典就能知道每个指标是怎么测出来的。这也是我认为代码骨架比一次性脚本更有价值的原因。5. 实际跑完十个平台后我总结出的几个反直觉经验5.1 多端形态不一致怎么办把入口形态变成维度十个平台里有的主打App有的依托小程序有的只有H5页面。直接把不同端的首屏指标放在一起对比本身就是不公平的。这时候不建议强行统一技术形态而是先把主入口形态记录成维度再分组比较。报告中至少要有三张表H5组、小程序组、App组。如果某平台两种端都有用户就分别测、分别列最后选型时看真实用户主要使用哪一种端。另一种做法是选定一个公共入口比如都通过微信内置浏览器打开官网链接但这样测出来的结果只能代表H5体验不代表App体验。实际给选型建议时我会优先看业务的主流入口再在报告里单独说明本对比未包含X平台App端因为其App需要额外的实名认证流程。5.2 自动化探针被风控拦截的常见原因我第一版脚本跑了几天后突然发现平台C的成功率掉到60%排查后发现是请求频率太高被风控识别为异常流量。这个问题不是换一个入口就能简单解决的。解决办法是在轮巡里加随机延时把每轮开始时间摊开同时严格控制同一个账号的操作频率。对于需要登录的探针用真实测试账号前要通过平台提供的测试通道或与商务、技术支持沟通不要直接拿公开账号去高频测试。如果你发现某个平台已经返回验证码第一时间不要继续重试而是把原始响应片段保存下来然后暂停该平台的探针人工确认原因。重试次数越多账号越容易被限制。实测下来大多数平台允许低频匿名访问但高频业务操作必须要走正规测试通道。5.3 错误码不是一切业务断言必须放在HTTP之上我见过很多探针只判断HTTP 200就想当然认为成功但实际页面可能返回了一个系统繁忙请稍后再试的文字。因此每个业务探针都应该加一个断言函数判断当前页面是否包含预期业务元素比如医生列表病情描述提交成功支付结果页等关键文本或DOM节点。在代码里我通常会加一个assert_page_contains参数在保存结果时同时保存原始响应片段这样即使断言失败也能快速回溯是被验证码拦了、页面改版了还是后端真的出了问题。做横评的时候错误码只能作为第一道粗筛。真正要看的是用户能不能完成目标动作。HTTP层通了、业务层没通这是横向对比里最容易被数据美化掩盖的事实。5.4 指标权重不能固定门槛指标和加分指标分开最后一次整理报告时我意识到指标权重不能预设成固定值。不同决策方关注点完全不同运营方更看重客服接通时长和退款体验技术方更看重接口时延和稳定性管理层则更关注功能完整度和品牌调性。所以我建议把指标分为门槛指标和加分指标门槛指标是必须满足的硬性要求一旦不达标直接一票否决加分指标按不同选型场景临时打分。最终报告不做总分排名而是输出候选平台画像让评审会基于自己的业务优先级去加权。这比给十个平台排一个名次更能经得起追问。比如某个平台首屏时间略慢但在医生资源覆盖上显著领先另一个平台速度很快但退款体验极差。如果给一个固定总分前者可能会被速度拖累后者则会掩盖退款风险。分开门槛和加分项之后决策者才能看到真实取舍。5.5 数据复盘时的团队配合横向对比不是一个人闷头跑数据就能完成的事。指标设计、采样频次和代码骨架只是基础真正让报告有价值的是复盘环节。我会把每个平台的异常记录打印出来和业务同事一起逐条看确认哪些是平台问题哪些是测试方法问题哪些是网络波动。这样迭代两三轮之后指标字典会越来越稳代码骨架也会越来越贴近真实业务。如果现在让我重新做这个项目我会先花两天把指标定义表和采样调度写清楚而不是急着写探针。指标口径不确定的时候所有采集都是在给错误做堆料。跑数据本身不难难的是每次采样都能回答同一个问题这个数字到底说明什么。