[ 01 · 品牌 ]
OWL 场馆赛事数据的长期记录者
猫头鹰体育从 2016 年在石家庄记录第一场区域联赛的赛果起步，做的一直是同一件事：把场馆里的比赛变成能长期查、能导出复用、能传下去的赛事档案。今天这份档案覆盖 28 个省级行政区，服务 260 余家合作场馆与 1,900 余支业余球队。
- 2016起步于石家庄
- 28个省级行政区
- 260+家合作场馆
- 1,900+支业余球队
[ 02 · 呼号 ]
OWL 不是缩写，它是夜班同事互相叫的名字
2016 年，我们只有三个人守着一个场馆的数据终端。赛程大多排在晚上，值班表上用 OWL 指代那一段盯着屏幕、核对比分的时间。后来它成了我们对外报出自己身份的方式。
今天 OWL 呼号出现在三个位置：会员身份、测试版关注列表的进入标识，以及关注列表中保存的球队与球员。它由 4 至 12 位字母数字组成，注册后不可重复，也不能与已有呼号重复使用。
[ 03 · 业务 ]
三条业务线，都围着场馆转
场馆里的一场比赛，从现场记录到你能查到的榜单，中间要经过采集、校验、入库和呈现四步。三条业务线分别负责这条链路上的一段，各有明确的服务对象和交付物。
-
L1
场馆数据采集
为场馆运营方与赛事主办机构整理场馆资料库，覆盖场馆坐标、座位分区、灯光条件与场地规格四类字段，每赛季集中更新两次，交付格式可直接导入贵方系统。
服务对象 · 场馆运营方 / 赛事主办机构
-
L2
赛事统计
赛后为教练、领队与数据记录员提供比分、射手榜与球员动态。桌面端射手榜可按场馆、赛季、球员位置三个维度筛选，结果支持导出为 CSV 文件，赛季结束可直接归档。
服务对象 · 球队教练 / 领队 / 数据记录员
-
L3
会员服务
会员体系分 OWL 呼号会员、看台会员与场馆合作方账户三档。权益覆盖赛事数据权限扩展、专属呼号标识与关注列表容量提升三部分，v6.2 起集中收进会员中心入口。
服务对象 · 长期使用数据的个人与机构
[ 04 · 历程 ]
每一个节点，都是当时没解决的问题
-
2016
石家庄，第一支场馆统计小组
区域篮球与足球联赛的场馆侧赛果统计，由三个人轮班完成。当时最头疼的问题是赛后两小时内拿不到一份完整的比分与球员记录。
当年成果 · 那个赛季全部场馆赛果一场未落。
-
2018
首版赛事数据服务上线
此前不同场馆各写各的记录格式，跨场馆比对几乎不可能。我们把场馆赛果的字段结构统一下来，跨场馆查询第一次变得可行。
当年成果 · 场馆赛果字段结构统一，跨场馆查询上线。
-
2021
会员体系与 OWL 呼号
用数据的球队越来越多，权限和身份需要一条清晰的线。OWL 呼号会员、看台会员与场馆合作方账户三档并行，呼号开始同时承担身份与权益识别。
当年成果 · 三档账户体系成型，呼号成为会员标识。
-
2023
跨端接口统一
安卓端与桌面端各走一套数据，用户在两处看到的榜单经常对不上。v6.0 统一了移动端与桌面端的数据接口，v6.1 补上场馆维度筛选，两端终于指向同一份记录。
当年成果 · 安卓赛事板块与桌面端射手榜共用一套场馆数据源。
-
v6.2
会员权益入口补齐
权益此前散落在多个位置，找起来费劲。v6.2 把赛事数据权限、专属标识与关注列表容量集中到会员中心的一处入口，安卓端与桌面端同步上线。
本次成果 · 权益入口收进会员中心，从首页两次点击可达。
[ 05 · 团队 ]
46 个人，把一场比赛的数据从看台送到屏幕上
猫头鹰体育的技术团队现有 46 人，分成四个组，各自负责这条链路上的一段。一场比赛的数据从现场采集到最终上线，至少要经过四个人的手。
- 数据工程 18
- 客户端 14
- 赛事运营 9
- 客户支持 5
数据工程负责场馆字段的采集、校验与入库；客户端负责安卓赛事板块与桌面端射手榜的呈现；赛事运营对接场馆与主办方，安排现场记录节奏；客户支持处理会员权益、呼号与关注列表相关的问题。
[ 06 · 合作 ]
三类伙伴，三种合作方式
-
12
场馆运营方
场馆提供现场记录与场地信息，我们负责数据结构化与对外呈现。共同产出是持续更新的场馆资料库，覆盖坐标、座位分区、灯光条件与场地规格，每赛季集中更新两次。
-
6
赛事主办机构
赛事期间由主办方提供赛程与报名名单，我们承接赛果统计与榜单发布。共同产出是完整赛季的赛事记录与射手榜数据，赛后可整季导出。
-
3
体育院校
面向教学与研究场景，提供场馆与赛事统计的标准化字段。双方每赛季共同产出两份场馆数据观察报告，分别覆盖赛季中期与收官阶段。
