数据源：travelmgr_3（我们平台自己的库，校园直通车业务线） | 业务标识 businessType = campusTravel | 导出时间 —
本页回答一个问题：校园直通车的票，是谁在卖、卖给了谁、卖得动卖不动？
按老板要的口径，全篇只分两级：一级服务商（merchants 表，库注释就是"服务商信息表"）→
二级商户（mchunit 表，库注释是"商户表"，也就是各家下面的门店/校区主体）。
本页所有数字都只来自我们平台这一套库，不包含合作方或第三方渠道的平行数据，也不做没有数据支撑的推测。
—，校园直通车在我们平台上累计卖出 —单、—张票， 成交额 —，服务了 — 个真实买家； 盘子由 — 个一级服务商撑起来，其中 — 家订单过千。 但结构极不平均：前 5 家一级服务商就吃掉 — 的订单（前 10 家 —）， 后面 16 家加起来不到 —。 更值得说的是：订单量榜和成交额榜几乎不是同一个榜—— — 订单第一，成交额只占 —； — 订单只排第 —，成交额却占到 —。 原因是校园业务里同时跑着两类生意：单价十几块的短途摆渡和单价一百多的长途班线， 两类的量纲根本不能直接比。所以本页把"售票量"拆成订单量、票数、成交额三个口径分别看，谁强谁弱一目了然。
前 4 条是盘子和结构的事实，中间 3 条是二级商户层面的发现，后 3 条是需求侧、节奏与数据质量的问题。每条都标了数据出处。
口径：orderinfo 中 businessType = campusTravel 的全部订单，不受"是否已支付"影响（月度图里会分开画）。
蓝柱＝当月订单量（左轴）；橙线＝当月成交额（右轴，仅统计支付成功的订单）
蓝线＝当月出过单的一级服务商数；绿线＝当月出过单的二级商户数（右轴）
一级 = merchants（服务商），二级 = mchunit（商户/门店）。订单归属靠 orderinfo.MerchantNo 和 orderinfo.MchUnitId，两者在校园业务里都能 100% 对上主表。
按累计订单量降序，条长即订单量，右侧标注占总量的比例
按订单量降序，标注该服务商旗下出过单的二级商户数与明细
灰底加粗行＝一级服务商（老板签合作的那一层）；缩进行＝该服务商下的二级商户。两级都按订单量降序，表头和合计行滚动时固定。
二级商户 = mchunit.UnitName，是真正在系统里挂班次、收钱的那一层。
只列累计订单 ≥ 100 的商户，按订单量降序
按订单量降序累加，橙线为累计占比
客单价＝该服务商“支付成功”订单的成交额 ÷ 对应的票数。订单量第一和成交额第一经常不是同一家，对外报数必须先讲清用哪个口径。
按累计成交额降序，标注客单价与占总额比例
按一级服务商拆月度订单量。只画订单量前 10 的服务商，其余归入“其他”。
折线＝各一级服务商当月订单量
横轴＝时间，每条＝一个一级服务商，线段＝该服务商有订单的区间
数据来自 line_search_log，只取归属校园服务商名下（MerchantNo 命中校园服务商集合）的搜索记录。用户按 openId 去重。
蓝柱＝当月搜索次数，红柱＝其中无班次的次数，橙线＝无班次率（右轴）
蓝柱＝搜索次数；橙线＝搜索后成功下单比例（BuyTicketsResult = COMPLETED）
累计搜索 ≥ 2,000 次的方向，按搜索量降序（前 60 条）
发车日期与发车时刻取自班次表 travelinfo（订单通过 ProductId 关联班次，命中率 99.97%）。
按班次发车日的星期几汇总订单量；红柱＝高峰日（≥ 8 万单），蓝柱＝平日，灰柱＝最低日
按班次发车时刻的小时汇总订单量
每天的发车订单量，仅取实际有订单的日期
班次数与"允售票数"来自 travelinfo（仅取发车日 ≤ 今天的历史班次）；核销来自订单的 CheckNumber 字段。
蓝柱＝历史班次数（左轴）；橙线＝每班平均售票数（右轴）
橙柱＝该服务商支付成功票数，绿柱＝其中已完成检票的票数，标签为核销率
左边是"平台/我们"能自己做的，右边是需要服务商配合的。每条都对应上面某一节的数据。