一、现状：三个数字看懂问题移动端口径
23.68%
行情渗透率
（查看行情 ÷ 租屋活跃）
（查看行情 ÷ 租屋活跃）
30.7%
低分率（2–4 分）
6.46
平均分（满分 10）
246
有文字反馈（12.9%）
63.3%
会员身份缺失
（无法分群归因）
（无法分群归因）
两个必须知道的结构性事实：
- 写文字的人显著更不满：有文字者低分率 40.2%，仅评分者 29.3%，相差 10.9pp。因此 246 条文本只能说明「说什么的人最痛」，不能推算多少人痛。
- Touch（手机网页版）是满意度洼地：低分率 34.8%、均分 6.21（最差），iOS 为 28.5%/6.66（最好）。任何改动应优先看 Touch 是否改善。
月度趋势：10 月出现分化——10/1–14 低分率 38.1%，10/15–25 降至 21.1%。但最新期仅 4 条文本，只能说明恶化趋势止住，不足以确认老问题已解决。
左：写文字的人显著更不满（差 10.9pp）→ 定性结论只能定位痛点性质，不能推算多少人痛。右：各端满意度差异，Touch 是洼地，应作为首要试验场。
二、根因：一条找房链上的三次断裂不是三个孤立问题
1
进入时被打断
行情被强插进找房流程，用户失去操作控制权
“卡在畫面上面會一直點到”“給我分析做什麼，干擾搜尋”
▶
2
比较时条件不一致
费用 / 面积 / 车位 / 区位混在一个均价里，无法换算成自己要付的钱
“近期房源都將管理費另算…當然會變便宜”
▶
3
看完后仍不能找房
给了数字，但没给「下一步能租什么」，条件也不保留
“又不是知道均價就能讓屋主降價”
因此验收标准要改：不只看「有多少人点了行情」，而要看「有多少人因为行情更快租到房」。把行情当找房决策的一步，而不是当被查看的内容。
三、方案：一个内核 + 三处挂载不新建入口
大白话：用户找房时九成时间在看房源，很少专门去「查行情」。所以我们不做新入口让人去找，而是在用户已经在看的地方直接给答案。
挂载 ①
房源详情页
用户看某套房时，直接告诉他「这套比同条件行情贵还是便宜」，自动带入坪数／车位／楼层
解决「这套贵不贵」· 场景 2 + 6
挂载 ②
列表筛选后
筛完一批房后告诉他「你筛的这批中位价多少、你的预算够不够」
解决「预算够不够」· 场景 5 + 2 · 零新增入口
挂载 ③
既有行情页
主动查行情时告诉他「这个数字基于多少样本、什么范围、能不能信」，查不到时给降级路径
解决「数字能信吗」· 场景 4 + 3
「内核」是什么：一个同条件比价计算器——传入条件（地点、型態、坪数、车位、楼层），返回可比价格结论 + 可信度。三处挂载共用它，只建一次，因此不会出现「三个页面三种价格」。
四、为什么不直接做「3 秒定制」行情地图排除替代方案
前面方案是从零开始建能力；另有一个更激进的提案——直接做一个「3 秒定制」行情地图重构查询体验。经评估：方向对，但不足以替代上面的方案，理由如下。
A · 修链路（本方案，先做）
- 解决「行情有没有用」——用户是否信任并据此行动
- 不新增入口，不产生打扰
- 覆盖 P1 五个场景中的四个半
- 共用内核，一次建设多处复用
B · 新入口（后置，不先行）
- 只解决「行情好不好找」——服务已想用的人
- 不修既有链路；新增曝光可能重演「干擾搜尋」抱怨
- 对 P1 五场景仅 2 强 1 半 2 弱
- 约六成能力在既有模式已存在，不应重复立项
关键判断：没有 A 就做 B，等于让更多人更快地拿到一个不可比、不可信的数字——正是「又不是知道均價就能讓屋主降價」与管理费口径投诉的成因。二者可融合：B 是挂载③成熟之后的交互升级，不是竞争路线。
五、执行：六个任务项（T0–T5）先做不用赌的，再并行，最后才做新入口
T0
能力核验
零成本先行；若已支持则不立项
T1
内核
共用；可独立先做
T2
挂载①详情
可并行
T3
挂载②列表
可并行
T4
挂载③行情页
与 T5 互斥
T5
3 秒定制
后置，依赖 T1+T4
| 优先级 | 内容 | 说明 |
|---|---|---|
| P0 | 止损：入口遮挡误触复现 · 反馈入口分流 · 内核含管总价数据层 | 不做会持续污染指标与口碑；不应被方案评审卡住 |
| P1 | 修链路：三处挂载（T2／T3／T4）+ 口径统一 + 可信度呈现 | 构成「查得到 → 看得懂 → 用得上」；复用已有能力为主 |
| P2 | 增量：3 秒定制交互（T5）· 保存提醒 · 供给端高级分析 | 需等 T1／T4 验证；易与 P0／P1 争资源 |
验收看什么（不看什么）：
- 看任务：房源落地率、预算校准率、条件一致率、解释理解率、无结果率下降。
- 看护栏：误触率、非行情咨询率、列表／详情页停留与返回率——任一恶化即回滚。
- 不看：地图曝光量、点击次数、提醒点击——曝光不等于查询成功。
六、风险：不能承诺的三件事一旦承诺必被证伪，请一并知悉
不能承诺的三件事：
- 不能用议价率系数逆推成交价——挂牌与实价申报时间差 ≠ 议价幅度，全局系数会系统性偏差。
- 不能估算并显示电费溢价金额——能耗依用量而定，只能做标志位与情景估算。例：房东分表每度 $5–6（夏季 $6.5–7.9）对台电 $1.63，月用 200 度每月多付约 $874，差距真实但不可计入价格。
- 不能宣称「热度图绝不失真」——细粒度样本本就薄，应呈现样本量与降级解释。
若维持现状：渗透率停在 23.68%，P0 的入口遮挡与求助错配持续污染指标与口碑；行情继续被当作「打断找房的多余功能」（用户原话：“給我分析做什麼，干擾搜尋”），曝光投得越多、反感越强。
数据边界（供严谨性备查，详见完整报告第八章）：10/15–25 仅 4 条文本，不足以确认老问题已解决；246 条定性反馈只代表最痛的那批人，不可推算普遍率；现状能力核验仅覆盖 Touch 端，APP 与小程序待补；方案价值须由 A/B 实测给出，不能用反馈条数证明。
七、请决策的三件事
- 是否同意「先修链路、新入口后置」的路线——即 P0 止损与 T1 内核先行，T5 等 T1／T4 验证后再启动。
- 是否批准把「房源详情 → 行情条件承接」作为第一个 A/B 单元——它同时服务覆盖最低的两个场景，且主要是参数传递而非能力新建，成本最低、收益最高。
- 是否同意 P0 独立于本方案先行动——入口遮挡复现与反馈入口分流属止损性质，不应被本方案评审卡住。
执行细节无需决策，由团队按附录 B 的并行规则推进：以 Touch（低分率 34.8%，满意度洼地）为主要试验场，预先随机分组，T4 与 T5 互斥。
附录 A · 八类场景速查现场追问时翻查，主线阅读不需要看
| 编号 | 场景 | 优先级 | 一句话痛点 |
|---|---|---|---|
| 1 | 正在筛选/浏览房源，被行情入口遮挡或误触 | P0 | 遮挡、误点、打断找房主任务。 |
| 2 | 看中一套房，想判断贵不贵，却无法统一比较口径 | P1 | 费用、面积、车位、区位等可比条件不足，导致「不准」的主观判断。 |
| 3 | 用学校、路名、社区或通勤点找房，分析区域太粗或不清楚 | P1 | 地理对象不匹配、范围不透明、查不到。 |
| 4 | 已看到一个价格，但不知道能信到什么程度 | P1 | 覆盖、样本代表性和可信度遭质疑。 |
| 5 | 想快速得到判断，却被复杂界面和重复操作拖慢 | P1 | 认知负担和操作成本过高。 |
| 6 | 查完行情仍要找房，希望保留条件并继续行动 | P1 | 查询条件不保留、查完无下一步承接，行情与找房任务断裂。 |
| 7 | 向平台求助：真假房源、联系失败、宠物/租补条件或价格太贵 | P0 | 平台供给可信度、联系与匹配任务问题。 |
| 8 | 房东/仲介用行情做定价、成交周期和经营判断 | P2 | 供给端需要经营决策与刊登操作支持。 |
附录 B · 五个任务项速查（T1–T5）T0 为零成本前置核验，不计入正式任务项
| 任务 | 名称 | 做什么 | 依赖 | 验收指标 |
|---|---|---|---|---|
| T1 | 内核 | 含管总价数据层（月固定总成本）+ 样本量元数据 + 支持传入条件 | 无（可独立先做） | 字段覆盖率、口径一致率 |
| T2 | 挂载① 房源详情 | 房源详情 → 行情的条件承接，回答「这套贵不贵」 | T1 | 房源落地率、条件一致率 |
| T3 | 挂载② 列表筛选后 | 筛选后的中位价与预算落差提示，回答「预算够不够」 | T1 | 预算校准率、筛选重置率 |
| T4 | 挂载③ 既有行情页 | 补可信度条（样本量／期／来源）与无结果降级 | T1 | 解释理解率、无结果率下降 |
| T5 | 3 秒定制（新入口） | 预算驱动的行情查询交互重构 | T1 + T4 | 主动查询成功率 |
T0（前置核验）：核验现有地图模式是否已支持「预算 + 型态」叠加、预算字段各端覆盖率——零成本。若已支持，则缺口只是可发现性，不立项。
并行规则：T2／T3 作用于不同页面，可并行（需正交分层）；T4 与 T5 必须互斥（同在行情页，同时上线无法归因）；T5 不得早于 T1。
并行规则：T2／T3 作用于不同页面，可并行（需正交分层）；T4 与 T5 必须互斥（同在行情页，同时上线无法归因）；T5 不得早于 T1。
附录 C · 台湾租屋成本结构为什么「含管总价」必须重新定义
用户比较的是「自己实际要付的钱」，但平台上租金口径并不统一（有的含管理费、有的另计）。这张表说明我们把哪些费用算进比价、哪些不算。
| 层 | 项目 | 常见金额（台湾市场） | 处理规则 |
|---|---|---|---|
| 固定层 并入可比价 | 挂牌纯租金 | — | 比较基准 |
| 大楼管理费 | 每月 $500–3,000（电梯大楼） | 「含管理費」＝已含；「另計」且给额 → 并入；未给额 → 未知，不补估 | |
| 公共清洁费／垃圾代收 | 每月 $300–500（传统公寓） | 已知 → 并入；大楼已含管理费时勿重复计 | |
| 变动层 只做标志，永不并入价 | 独立电费（最核心变量） | 台电 $1.63／度起；房东分表 $5–6、夏季 $6.5–7.9 | 标志位 + 假设明示的情景估算 |
| 独立水费 | 台水账单或人头 $100–200 | 标志位 | |
| 瓦斯费 | 天然气／桶装 $700–900 | 标志位 | |
| 网络／第四台 | 常见「含網路」或另计 | 标志位 |
核心原则：比较、排序、中位数只用「月固定总成本」＝挂牌租金 + 管理费 + 清洁费；能耗类永远只做标志，不并入价格。
为什么电费不能算进价格：房东私设分表每度 $5–6（夏季 $6.5–7.9），对台电非夏日 $1.63。以月用 200 度计，每月约多付 $874，夏季差距更大。
差距真实存在，但它取决于用量与个人行为——一旦算进价格就变成假精确。这正是用户既抱怨「价格刺客」、又要求「数据要准」的两难所在；我们的处理是只提示、不计算。
差距真实存在，但它取决于用量与个人行为——一旦算进价格就变成假精确。这正是用户既抱怨「价格刺客」、又要求「数据要准」的两难所在；我们的处理是只提示、不计算。
两条铁律：
- 缺字段＝显示「未知」，禁止用市场中位数补估。补估就是在制造新的「数据不准」——而「不准」是本报告中唯一 100% 引发低分的痛点。
- 「含管理費」与「管理費另計」是两种口径，混算会直接摧毁信任。用户原话：“近期房源都將管理費另算，與先前含管理費的房價相比當然會變便宜”。