C端反馈深度拆解 · 痛点 · 场景 · 因应方案
如何阅读本文档
第一次看这份报告的人，建议先扫一遍「术语速查」（下一节），否则「内核」「挂载」「月固定总成本」「開價／實價」这几个词会卡住阅读。
| 如果你是… | 重点读 | 你要带走的东西 |
|---|---|---|
| 产品负责人 / 决策者 | 结论速览 → 第四章 → 第五章 → 6.6 任务项 → 第八章 | 优先级排序、该建什么、不该承诺什么 |
| 产品经理 | 第三章 → 第四章 → 五章三处挂载路径 → 6.6 任务项 | 八类场景的痛点/需求/方案，以及每处挂载的五段路径与设计纪律 |
| 数据 / 算法 | 第一章 → 第二章 → 《台湾租屋成本字段规范》→ 第八章 | 样本偏差、定性不可外推、成本双层模型与「未知不补估」铁律 |
| 运营 | 第一章 → 第三章场景 1/7 → 第七章 | 短期可做的动作、反馈字段与分流、周更口径 |
| 设计 | 第三章场景 1/5 → 五章三处挂载的输出与纪律 → 6.6 | 不遮挡、先结论后条件、条件可见可改 |
- 「事实」与「推断」分开写——凡标注「推断」「可能」的，都未获数据证实，不可当结论引用。
- 定性结论不可推算普遍率——写文字的人显著更不满，246 条文本只能说明「说什么的人最痛」。
- 出现 Fnnn 编号＝可追溯证据，全部收录在附录，编号与记录 ID 一一对应。
术语速查（首次查阅请先扫这一页）
本报告用了少量专有说法。第一次看的人花一分钟扫过下表，后面就顺畅了。
| 说法 | 它是什么意思 |
|---|---|
| 行情渗透率 | 查看行情的人数 ÷ 租屋活跃人数，是本项目的北极星指标。当前移动端 23.68%（含 PC 则仅 16.68%） |
| 月固定总成本 | 挂牌租金 + 管理费 + 清洁费。本报告规定：比较、排序、中位数只用这个口径；电费、水费等按用量计费的项目永不并入价格，只做标志 |
| 開價 / 實價 | 開價＝房东刊登的要价；實價＝实际成交申报价。两者不可混用，其差值也不等于议价空间 |
| 内核 | 本报告提出的一个共用计算层：传入条件 → 输出可比价格结论 + 可信度。三处挂载都调它，所以不会出现三个页面三种价格 |
| 挂载 | 把行情能力嵌进用户已经在用的页面（房源详情／列表／行情页），不新建入口。这是本方案与「3 秒定制」的根本差别 |
| P0 / P1 / P2 | P0＝止损（不做会持续恶化）／P1＝修复任务链（查得到→看得懂→用得上）／P2＝增量。详见第四章 |
| Fnnn | 用户反馈的证据编号（如 F128）。所有引用可在附录按记录 ID 追溯原文，已做脱敏 |
| Touch / iOS / Android / MINIAPP | 四个移动端。Touch＝手机网页版（满意度最低的洼地）；MINIAPP＝小程序（渗透率最低，行情功能 6/10 才上线） |
| 低分率 | 打 2–4 分的人数占比。注意：写文字的人低分率显著更高，所以定性结论只能说明「说什么的人最痛」，不能推算多少人痛 |
| 推断 / 事实 | 凡标注「推断」「可能」「待确认」的，都未获数据证实，不可当结论引用 |
结论速览
- 反馈揭示三层阻力：① 进入时被打断（入口遮挡/误触）；② 比较时条件不一致或看不懂（费用、面积、车位、区位口径混乱）；③ 看完后仍不能完成找房（条件不保留、无承接）。
- 经营顺序应为：先修复妨碍找房及错误承接 → 再验证同条件价格判断与房源承接 → 最后评估收藏提醒与供给端高级分析。
- 该排序依据是问题严重性、与当前目标的关联、已有能力与验证成本，不是「未经量化的全体用户需求排名」。
- 关键正反证据对比（决定验证方向）：
“太方便了…還有跟據附近區域一樣是公寓之類的行情跟價格可以參考” → 明确认可「同区域同类型」比较
“沒意義的功能 影響點擊查詢選項 又不是讓租客知道平均價格 就能讓屋主降價出租” → 既有入口遮挡，也有使用价值质疑
“我要的是找房子找租屋，給我分析做什麼，干擾搜尋” → 明确把分析视为主任务的打断
一页速览
| 维度 | 结论 |
|---|---|
| 样本基础 | 清洗后移动端 1,909 条，仅 246 条（12.9%）有文字；低分率 30.7%、均分 6.46。写文字者显著更不满（差 10.9pp） |
| 用户要什么 | 不是「一个租金数字」，而是这个地点、这类房子、这些费用下，我的预算能选什么 |
| 三层阻力 | ① 进入时被打断 → ② 比较时条件不一致 → ③ 看完后仍不能完成找房 |
| 八类场景 | P0：入口遮挡误触 · 平台求助错配 ｜ P1：口径 · 地域 · 可信度 · 认知负担 · 查完无承接 ｜ P2：供给端高级分析 |
| 主线方案 | 一个内核 + 三处挂载：内核建一次；挂载①房源详情（这套贵不贵）②列表筛选后（预算够不够）③既有行情页（数字能信吗） |
| 方案判断 | 「3 秒定制」方向对但不足以覆盖 P1——2 强（地域、认知负担）、1 半（口径）、2 弱（可信度、回房源承接）；它是新入口，而 P1 要修的是链路 |
| 第一步 | 房源详情 → 行情的条件承接：同时服务覆盖最低的两个场景，且主要工作是参数传递而非能力新建 |
| 不要做 | ① 用议价率系数逆推成交价 ② 估算并显示电费溢价金额 ③ 宣称「绝不失真」 ④ 拿地图曝光量当查询成功 ⑤ 用「投诉减少」单独证明准确性提高 |
| 必读边界 | 见第八章：最新期样本极薄、定性不可外推、现状核验仅覆盖 Touch 端、概念评估不可替代 A/B |
一、数据基础与分析边界
本章回答：数据可信到什么程度？哪些结论不能外推？
核心结论：清洗后移动端样本 1,909 条，仅 246 条（12.9%）有文字。写文字的人显著更不满（低分率差 10.9pp），所以全部定性结论只能「定位痛点性质」，不能「推算痛点普遍率」。
清洗过程：原始堆叠 2,492 行 → 按记录 ID 去重 502 行 → 合并后 1,990 条 → 剔除移动端可疑样本 7 条 → 排除非移动端 20 条 → 最终 1,909 条。评分区间 2–10 分，无异常值。
测算结论：剔除后全样本均分与低分率完全不变（6.46 / 30.7%），文本口径低分率仅由 40.2% 升至 40.5%（+0.3pp），均分不变。因此它对本报告任何结论均无实质影响，保留在基数中不影响判断。
正确做法（建议落地）：将其标为第 9 类「非行情／求房咨询」，排除出行情满意度分母，同时作为「反馈入口缺少问题对象分流」的运营信号单独计数——这正是场景 7 要修的问题。
- 定性样本天然偏负面：有文字者低分率 40.2%（n=246），仅评分者 29.3%（n=1,663），差 10.9pp。因此 246 条文本只能说明「说什么的人最痛」，不能推断「多少人痛」。
- Touch 是满意度洼地：Touch 低分率 34.8%、均分 6.21（最差），iOS 为 28.5%/6.66（最好）。任何改动应优先看 Touch 是否改善。
- 身份缺失 63.3%（1,208/1,909）：无法分群归因。已填身份中屋主/代理人最满意（均分 7.56、低分率仅 17.2%），房客 6.50/28.5%，仲介最低 6.07/33.3%——当前行情更贴合供给端，而非租客决策端。
二、痛点全景：从症状到根因
本章回答：用户嘴里的症状，背后的根因是什么？
核心结论：把用户嘴里的「症状」翻译成产品可修的「根因」，三者不是并列关系，而是一条找房任务链上的三段断裂。
| 用户说的（症状） | 表层归类 | 深层痛点（根因） | 对应场景 |
|---|---|---|---|
| “卡在畫面上面會一直點到”“蓋掉一些內容”“干擾搜尋” | 入口体验 | 主任务被打断：行情被强插进找房流程，用户失去操作控制权 | 场景 1 |
| “數據不準”“不符實際現狀”“管理費另算” | 数据质量 | 比较口径不可比：费用/面积/车位/区位混在一个均价里，用户无法换算成自己要付的钱 | 场景 2、4 |
| “找不到”“沒有游泳路的資料”“太粗糙” | 功能缺失 | 地理心智模型不匹配：用户按学校/路段/社区/通勤点思考，产品按行政区/捷运线组织 | 场景 3 |
| “頁面繁索”“說明難懂”“字小”“不能複選” | 界面复杂度 | 认知负担过高：信息没分层，结论被埋在条件和说明里 | 场景 5 |
| “給我分析做什麼”“又不是知道均價就能降價” | 价值质疑 | 行情与找房任务断裂：给了数字，但没给「下一步能租什么」 | 场景 6 |
| “已售出應該下架”“太多詐騙”“電話打不通” | 平台供给 | 问题对象错配：用户在行情入口投诉房源/刊登问题，说明反馈出口缺少分流 | 场景 7 |
| “看三年五年數據”“多久租出去” | 供给端需求 | 另一类用户群：房东/仲介要的是经营决策，不是租客比价 | 场景 8 |
三、八类场景逐条拆解
本章回答：每一类场景的痛点、需求、方案、验收分别是什么？
核心结论：以下 8 类场景由逐条审读 246 条有文本反馈归纳。每类给出证据 → 痛点 → 本质需求 → 短期运营 → 产品方案 → 验收指标，并明确区分「事实」与「推断」。
场景1 正在筛选/浏览房源，被行情入口遮挡或误触 P0
典型证据：
“會蓋掉一些內容”
“卡在畫面上面會一直點到”
“麻煩你不要一直掛上面”
“我要的是找房子找租屋，給我分析做什麼，干擾搜尋”
明确痛点：遮挡、误点、打断找房主任务。
推断与边界：被迫进入的查看会带来统计覆盖，却损害主动使用意愿；不能从这些留言测算误触流量规模。
本质需求：保持找房操作控制权，在需要时才查价格。
短期运营（可立即做）：先复现反馈端、版本和入口；排查通知与新手引导是否同时出现；对已上线入口采用低干扰文案「看本區同類租金參考」，明确可关闭。历史反馈不能证明当前所有版本仍有问题。
产品方案：优先测试不遮挡筛选和房源的列表内嵌卡；关闭状态有合理记忆和频控；通知后置到成功查询后；不要用大面积可点击区域制造点击。
验收指标：全体实验活跃用户的同口径行情渗透率；另看主动查询成功率、快速返回且未操作比例、误触/遮挡反馈。找房列表→详情与全体活跃咨询率为护栏。快速返回只能是误触代理，需抽样复核。
场景2 看中一套房，想判断贵不贵，却无法统一比较口径 P1
典型证据：
“近期房源都將管理費另算 與先前含管理費的房價相比當然會變便宜”
“希望能把附加費用拆出來…電費、水網路費、管理費，這三項其實都已經到了每月各 1000 的水準”
“請將有無車位的選項加入，以利正確分析”
“我是屋主，數據都亂打根本不是這樣，明明含車位出租，租金也不符合”
“請以坪數換算租金價格及是否真為正市中心”
明确痛点：费用、面积、车位、区位等可比条件不足，导致「不准」的主观判断。
推断与边界：部分「不准」可能是口径不一致，而非算法错误；不能据此断言算法错误或均价全部错误。
本质需求：比较自己实际要支付的租住成本，不被混合样本误导。
短期运营（可立即做）：用真实但去标识的样本演示「租金／管理费／车位」比较口径；FAQ 将「不准」拆为原字段错误、费用不同、区域/房型不同、样本时间不同；已知费用与未知费用明确分开。
产品方案：在价格结论旁展示比较条件摘要、含/不含费用与面积定义；固定费用按下方《台湾租屋成本字段规范》并入「月固定总成本」，缺失显示「未知」不补估；能耗依用量计费只能做标志与假设明示的情景估算，禁止并入价格；从房源详情承接条件。实价当前已有车位、坪数、楼层筛选，应先修可发现性和条件承接，不重复立项。
验收指标：真实任务的正确比较率、费用理解率、条件一致率、查后房源返回成功率；单独监控费用字段覆盖及纠错闭环。
| 层 | 字段 | 常见值域（台湾市场） | 处理规则 |
|---|---|---|---|
| 固定层 （并入可比价） | 挂牌纯租金 | 刊登最显眼处的原始价格 | 可比价的基准 |
| 大楼管理费（电梯大楼专有） | 每月 $500–3,000，或依坪数计 | 「含管理費」＝已含；「另計」且给额→并入；另計未给额→未知，不补估 | |
| 公共清洁费／垃圾代收费 | 每月 $300–500（传统公寓） | 已知→并入；大楼已含管理费时勿重复计 | |
| 变动层 （只做标志， 永不并入价） | 独立电费（最核心变量） | 台电独立表：非夏日 $1.63/度起；房东私设分表：全年 $5–6、夏季 $6.5–7.9 | 标志位＋假设明示的情景估算 |
| 独立水费 | 台水账单（每人约 $100–200）／人头定额 $100–200 | 标志位 | |
| 瓦斯费 | 天然气账单（整层）／桶装 $700–900/桶（老公寓、中南部） | 标志位 | |
| 网络／第四台 | 常见「含網路」或另计 | 标志位（F079 点名） |
四条铁律：① 热度图／排序／中位数只用「月固定总成本」＝挂牌租金＋管理费＋清洁费；② 能耗永不并入价格，只做标志＋情景估算——例：月用 200 度、房东订 $6/度 vs 台电非夏日 $1.63，每月约多付 $874，夏季差距更大（房东分表每度 $5–7.9 对台电 $1.63 的「价格刺客」，即 F079 的原话痛点）；③ 缺字段＝「未知」，禁止用市场中位数补估，否则就是制造新的「数据不准」；④「含管理費」与「管理費另計」是两种口径，混算等于复刻 F234 的投诉。
场景3 用学校、路名、社区或通勤点找房，分析区域太粗或不清楚 P1
典型证据：
“如何在台中北區下劃分出一中商圈、中國醫…是否另有地圖？另中國醫是指學士路的，還是指新校區水湳的？”
“我希望591能提供單一社區的租金比較”
“不能夠用地址搜尋這樣子的話，租金行情太粗糙”
“竟然沒有游泳路的資料”
“地圖能直接查詢行情價格”
明确痛点：地理对象不匹配、范围不透明、查不到。
推断与边界：可能包含功能难发现、模式不匹配、区域覆盖不足三种不同原因；不可合并为「需要开发地图」。
本质需求：用我脑子里那个地点（学校/路段/社区/通勤点）查到对应行情。
短期运营（可立即做）：补常见地点与同名地标提示；用具体任务指导挂牌/实价选择；无结果时解释是哪一范围和模式没有结果。
产品方案：复用既有地图、社区搜索及实价地址搜索；清楚展示搜索范围和地标识别；返回/切换地图保留条件；无结果时逐步扩大范围并告知比较范围发生变化。不能暗示存在任意地址成交数据。
验收指标：按查询意图和模式分的成功结果率、无结果率、范围误选率、条件保留率。地图曝光量不作为查询成功。
场景4 已看到一个价格，但不知道能信到什么程度 P1
典型证据：
“數據過少，未來應加強數據與房間內數等！才可以比較少誤差及精準的判別！”
“租金統計不符實際現狀”
“數據不準”
“都寫的比真實行情還要低…（10分却质疑偏低）”
明确痛点：覆盖、样本代表性和可信度遭质疑。
推断与边界：F042 给 10 分却写「比真實行情還低」，说明评分与文本态度可能不一致；没有对应查询条件、样本清单、模式、版本，无法判断各次质疑是否成立。
本质需求：知道这个数字基于什么、能信到什么程度。
短期运营（可立即做）：建立案例核查单，要求问题地点、房型、模式、日期与可比对象；给出核查进度及结论。已有来源和更新日期说明，应测能否被看懂，而非简单加一段小字。
产品方案：价格旁呈现样本量、样本期、来源、范围；少样本提供降级解释和扩大范围选项；经核实字段错误进入纠错链；区分挂牌和实价申报时间，不直接用两者差值当议价幅度。
验收指标：样本不足发生率、解释理解率、核实数据问题数/有效核查单、纠正时长。不要以「投诉减少」单独证明准确性提高。
场景5 想快速得到判断，却被复杂界面和重复操作拖慢 P1
典型证据：
“頁面繁索”
“說明難懂”
“全部不能複選，浪費很多時間”
“周圍生活圈對比的 UI 太小不好操作”
“很雜亂，字小”
“希望有更細部的分析…最後做一個快速的決策，講重點關鍵部分為主的分析最好”
明确痛点：认知负担和操作成本过高。
推断与边界：部分评价可能指 591 主找房界面而非行情页，需重现具体页面后才能定性。
本质需求：一眼得到结论，并知道下一步做什么。
短期运营（可立即做）：用一句话解释当前比较对象、价格范围及下一步；不默认叠加教育弹层。任务测试记录用户理解、完成耗时及误操作。
产品方案：分层展示「结论—条件—说明」；改善小点击区和文本可读性；承接筛选以减少重复输入；复选须先验证具体字段适用性，不以「全部字段复选」为方案。
验收指标：首次成功查询率、真实任务完成时间、价格解释理解率。点击次数下降不自动等于成功，需完成正确任务。
场景6 查完行情仍要找房，希望保留条件并继续行动 P1
典型证据：
“可以有儲存功能，好方便下次也可選擇用這種方式找房子…再加進篩選一些基本條件、租金、電梯”
“可以提供某些條件租屋物件推出時的提醒”
“針對個人需求，給予推薦”
“又不是讓租客知道平均價格 就能讓屋主降價出租”
明确痛点：查询条件不保留、查完无下一步承接，行情与找房任务断裂。
推断与边界：F072 反向说明：只给数字本身不够；大量直接求房/预约留言提示任务导流需核查，但不能一概认定行情缺少联系按钮。
本质需求：带着这次的结论和条件，继续把房租找下去。
短期运营（可立即做）：在现有回房源入口测试任务文案「看符合這些條件的在租房源」；告诉用户预算对应的可选区域/房型，不承诺房东降价；普通求房咨询导向房源列表或客服。
产品方案：复用已存在的高/低于中位数跳转，保留区域房型预算；测试保存查询条件；提醒仅在用户明确选择且有相关内容后评估，避免为复访增加干扰。
验收指标：有效房源落地/行情查看、条件保持率、7 日自然复访（排除尚未成熟的队列）、匹配条件房源咨询；整体实验活跃咨询为护栏。
场景7 向平台求助：真假房源、联系失败、宠物/租补条件或价格太贵 P0
典型证据：
“針對一些已出租的房子做核實，太多詐騙，詢問的時候都說沒了要給別的物件”
“已售出應該要下架”
明确痛点：平台供给可信度、联系与匹配任务问题。
推断与边界：不能据单条指控确认诈骗；不能将「价格高」直接定义为行情功能错误；不能把全部「租补」纳入行情需求。此类多为服务端/房源侧问题。
本质需求：遇到具体问题时，能被正确分流并得到处理。
短期运营（可立即做）：反馈入口增加自选问题对象（行情、房源、刊登、账户等）；保留低分记录并路由处理，不从评分中删去以美化分数；隐私投诉/疑似未授权刊登按现有客服流程核实；求房引导到已有筛选。
产品方案：在行情反馈出口提供对应问题处理入口，带上允许使用的页面上下文；供给真实性由负责团队核验；不承诺新增大量无关功能。
验收指标：问题分流准确率、解决率、首次有效回应时间、重复投诉。这些是服务指标，不计为行情渗透增量。
场景8 房东/仲介用行情做定价、成交周期和经营判断 P2
典型证据：
“希望能讓我們可以看三個月六個月，一年五年的數據”
“成交資訊與上架到成交多久時間”
“多久租出去的資訊”
“請幫我改租金20000元…（刊登修改类，非行情分析）”
明确痛点：供给端需要经营决策与刊登操作支持。
推断与边界：这是愿意持续使用的数据任务，但不是本期全体租客需求；部分高分用户仍提出改进。
本质需求：用行情支撑定价与去化决策。
短期运营（可立即做）：按任务路由到现有刊登定价及客服；访谈定价目标、样本要求和使用频次。
产品方案：复用 7/20 已上线房东定价参考；历史走势、出租周期只有在数据口径和增量需求被验证后排期；刊登采纳统计单位是物件，不能纳入 C 端人数渗透。
验收指标：定价参考有效使用、相关任务完成率，另行定义采纳。不得将价格恰落范围自动解释为被建议说服。
四、因应方案总表（按优先级）
本章回答：先做什么、后做什么，为什么是这个顺序？
核心结论：P0 是止损（复现遮挡、分流错误对象）；P1 是修复任务链（口径、地域、可信度、界面、承接）；P2 是增量（保存提醒、供给端高级分析）。不要拿 P2 的需求去争 P0/P1 的入口与承接资源。
| 优先级 | 场景 | 核心动作 | 为什么是这个顺序 |
|---|---|---|---|
| P0 | 场景 1 复现与止损 场景 7 紧急核实分流 | 复现反馈端/版本/入口并止损；反馈入口增加问题对象自选，低分记录路由处理不从评分删除 | 直接妨碍找房主任务、且有服务/合规风险，属止损性质，不做会持续污染指标与口碑 |
| P1 | 场景 2 口径统一 场景 3 地域承接 场景 4 可信度解释 场景 5 可复现阻塞 场景 6 回房源承接 | 展示比较条件摘要（费用/面积/车位）；复用既有地图与地址搜索并补无结果解释；呈现样本量/样本期/来源；分层展示结论—条件—说明；复用高/低于中位数跳转并保留条件 | 共同构成「查得到 → 看得懂 → 用得上」的任务链；复用已有能力为主，验证成本可控 |
| P2 | 场景 8 供给端分析 场景 6 保存/提醒 大规模视觉重做 | 历史走势/出租周期待口径验证后排期；保存查询条件与匹配提醒先做原型验证；视觉重做不阻塞功能修复 | 与 C 端人数覆盖仅间接相关；且易与 P0/P1 争用入口与承接修复资源 |
- 第五章给出主线方案——修链路（一个内核 + 三处挂载），并把本章 P1 的核心动作逐一映射到可执行的功能路径。
- 第六章评估另一个提案——「3 秒定制」新入口是否成立，并给出两条路线的融合方式与任务项拆分（T0–T5）。
- 注意：P0（场景 1 入口遮挡、场景 7 求助错配）不在第五、六章范围内。它们是止损性质，不是形态问题，不应等方案评审，应并行推进。
五、推荐方案：修复任务链（一个内核 + 三处挂载）
本章回答：主线方案是什么？三处挂载各自的前后路径、设计纪律与验收指标？
用户找房时，九成时间在看房源，只有很少时间会专门去「查行情」。所以我们的做法不是做一个新的行情入口让人去找，而是在用户已经在看的地方，直接把答案给他：
- 他在看某一套房 → 直接告诉他「这套比同条件行情贵还是便宜」（挂载①）
- 他刚筛完一批房 → 直接告诉他「你筛的这批中位价多少、你的预算够不够」（挂载②）
- 他主动查行情 → 告诉他「这个数字基于多少样本、什么范围、能不能信」（挂载③）
承上：第四章把 P1 定为「修复任务链」，但留了一个问题没回答：用什么产品形态承载这些修复？本章直接回答——不新建入口，而是建一个共用内核、挂到用户已经在用的三处页面。另一个提案（「3 秒定制」新入口）放在第六章单独评估，并给出两者的融合方式。
5.1 根本选择：修链路，还是新入口？
这是第四章之后必须做的第一层选择，两条路线不在同一层级：
| 路线 | 主张 | 它解决的是 | 风险 |
|---|---|---|---|
| A · 修链路 本章主线 | 不新增入口：把行情挂进用户正在用的页面（房源详情、列表、行情页），共用同一个内核 | 行情有没有用——用户是否信任并据此行动 | 改动分散在三个页面，必须靠内核统一口径，否则各做一套 |
| B · 新入口 见第六章 | 做一个「3 秒定制」行情地图，让用户更快主动查询 | 行情好不好找——已经想用的人能否更快用上 | 不修既有链路；新增曝光可能重演 F207「給我分析做什麼，干擾搜尋」 |
5.2 主线方案：一个内核 + 三处挂载
推荐路径：与其新建一个入口，不如把行情送到用户已经在做决定的地方——建一个「同条件比价内核」，挂到三处既有页面上。
内核可以理解为一个「同条件比价计算器」：你把条件告诉它（地点、型態、坪数、车位、楼层），它回给你一个可比的价格结论，外加这个结论的可信度。具体输出四样：① 比较条件摘要 ② 月固定总成本（按《台湾租屋成本字段规范》）③ 样本量／样本期／来源／范围 ④ 样本不够时的降级解释。
它只建一次，三处挂载都调用它——这就是「一个内核」的全部意义：口径只有一个，不存在三个页面各算一套。
| 挂载点 | 用户看到什么 | 解决的场景 | 为什么优于新入口 |
|---|---|---|---|
| ① 房源详情 | 「这套房 vs 同条件行情」——自动带入该房源的坪数／车位／楼层／区位 | 场景 2 后半 + 场景 6 | 用户 90% 时间在找房而非查行情；直接命中「这套贵不贵」 |
| ② 列表筛选后 | 「你筛的这批的中位价」 | 场景 5 + 场景 2 | 零新增入口，不产生任何打扰 |
| ③ 既有行情页 | 补上样本量、比较范围、无结果时的降级解释 | 场景 4 + 场景 3 护栏 | 修的是信任，不是形态 |
5.3 挂载①展开：房源详情「这套房 vs 同条件行情」的功能路径
先想象一个场景：用户正在看某套房，心里的问题是「这套到底贵不贵」——这就是挂载①要回答的。
为什么先做它：它同时服务覆盖度最低的两块（场景 2 后半「从房源承接条件」+ 场景 6「查完回到房源」），且实价页已具备坪数／车位／楼层筛选，主要工作是参数传递，不是能力新建。更重要的是——用户 90% 的时间在找房，不在查行情，把行情放进详情页，才是把行情送进决策现场。
| 段 | 阶段 | 发生什么 | 设计要点 |
|---|---|---|---|
| ① | 前置 用户在找房 | 来自列表／搜索／地图／收藏 → 点进房源详情 A | 不要求用户「先想到要查行情」，这是它与独立入口的根本差别 |
| ② | 触发 详情页内静态区块 | 价格区块下方出现「同條件行情參考」，默认一行结论，可展开 | 非弹窗、非浮层、不遮挡、不自动弹出——F207「給我分析做什麼，干擾搜尋」的教训 |
| ③ | 内核 自动带入条件 | 抽取坪数／型態／車位／樓層／區位 → 归一化「月固定总成本」→ 取同條件開價樣本 → 样本量门槛判定 | 用户无感，但结果必须可见可改（见纪律④） |
| ④ | 输出 四层信息 | ① 结论（偏高／相近／偏低，给区间不给单点）② 比较条件摘要（可改）③ 样本量·样本期·来源·范围 ④ 变动费用标志位 | 顺序不可颠倒——先结论后条件，对应场景 5 的分层要求 |
| ⑤ | 后置 回到找房 | 「看同條件其他房源」（带条件回列表）·「返回原路径并保留条件」· 保存条件 · 条件有误可回报 | 这是全链路的落点。首选 CTA 必须是房源，不是「查看更多行情」——否则重蹈 F072 的价值质疑 |
- 同口径比较：详情页租金是挂牌价，必须与「開價租金」样本比，不能拿它去比實價中位。挂牌 vs 实价混算＝复刻 F234「管理費另算…當然會變便宜」的投诉。
- 不打扰：静态区块、默认收起、非弹窗非浮层。展开率可以低，但不能因遮挡产生新的负反馈。
- 样本不足必须降级并明示：n 不足时自动扩大范围，并明确告知「比较范围已扩大至…」，禁止给出细粒度的假精确值（F045「數據過少」）。
- 条件可见可改：自动带入但必须显示出来，允许修正——F168「數據都亂打…明明含車位出租」说明源数据本身可能错。用户修正行为同时是最有价值的纠错信号源。
- 终点必须是房源：首选 CTA 是「看同條件其他房源」并带条件回列表，不是「查看更多行情」。
- 主指标：详情页行情 → 房源列表的落地率；条件一致率（自动带入条件与房源实际条件相符比例）。
- 质量指标：条件被用户修正的比例（越低越好，且应逐条进入纠错链）；样本不足发生率。
- 护栏（任一恶化即回滚）：详情页停留时长与返回率不得变差；误触率；非行情咨询率；新增遮挡类负反馈。
5.4 挂载②展开：列表筛选后「你筛的这批的中位价」
先想象一个场景：用户刚筛完「台中北区、2 万以内、电梯大楼」，结果只有 3 套。他真正想知道的是「是房源太少，还是我的预算太低」——这就是挂载②要回答的。
它最大的优势：筛选条件本身就是比较条件——不存在「自动带入是否带对」的问题，条件一致率天生 100%。而且它零新增入口，是三处挂载里唯一完全不产生打扰的一个。
| 段 | 阶段 | 发生什么 | 设计要点 |
|---|---|---|---|
| ① | 前置 用户已筛选 | 在列表页设定区域／租金／型態／坪数等条件 → 得到结果列表 | 用户已用行为表达了「我要什么」，这是最真实的意图信号 |
| ② | 触发 列表头一行 | 结果列表顶部出现一行：「你篩的這批 · 中位價 XX（n=XX）」 | 非弹窗、不遮挡首条房源；它属于列表的一部分，不是插入的广告位 |
| ③ | 内核 复用筛选条件 | 直接以当前筛选条件为查询条件 → 归一化月固定总成本 → 取同條件開價樣本 → 样本量门槛 | 不需要「条件抽取」，省掉挂载①最易出错的一步 |
| ④ | 输出 中位价 + 落差 | ① 这批的中位价区间 ② 条件摘要（＝用户自己的筛选，天然可见）③ 样本量 ④ 预算落差提示：「你設的上限低於中位價 XX，結果偏少」 | 预算落差是它独有的价值——直接回答「我的预算能选什么」 |
| ⑤ | 后置 预算校准 | ① 一键把租金区间调至中位数附近 ② 看偏高／偏低的房源 ③ 返回原列表继续浏览 | 必须是「建议」不是「自动修改」——用户保留控制权，否则就是另一次打断 |
- 不打断列表浏览：仅占一行，非弹窗，不遮挡首条房源。列表是主任务现场，任何遮挡都会重演场景 1。
- 筛选条件即比较条件：不另起一套口径，不与用户心里的筛选打架。
- 预算落差只能建议，不能自动改：不得悄悄替用户调整筛选或排序——那会直接摧毁信任。
- 样本不足必须降级并明示：条件过窄导致 n 不足时，放宽范围并告知「已放宽至…」。
- 不改变结果排序：行情信息不得影响房源列表的自然顺序，避免用户怀疑「是不是被操纵」。
- 主指标：预算校准率（看到提示后调整筛选的比例）；列表 → 详情的落地率。
- 质量指标：样本不足发生率；筛选重置率（调整后是否又改回去，反映建议质量）。
- 护栏：列表页停留时长与滑动深度不得恶化；误触率；筛选被修改的投诉。
5.5 挂载③展开：既有行情页补「可信度与降级」
先想象一个场景：用户主动打开了行情页，看到「本区中位价 2.3 万」，心里的问题是「这数字能信吗」——这就是挂载③要回答的。
与另两处不同：它不是新增流程，而是在既有流程里补上缺失的两样东西——可信度元数据、无结果时的降级路径。对应场景 4（可信度）与场景 3 的护栏（不能暗示存在任意地址成交数据）。
| 段 | 阶段 | 发生什么 | 设计要点 |
|---|---|---|---|
| ① | 前置 用户主动查行情 | 进入行情页／region 页，选择城市・区域・商圈・捷运 | 这是唯一一处用户本就有行情意图的场景，所以要补的是信任而非触达 |
| ② | 触发 与结论同屏 | 价格结论显示时，同步显示可信度元数据，而非点击「说明」后才看 | F048「說明難懂」的教训：说明写得再多也没用，必须在决策现场可见 |
| ③ | 内核 补算元数据 | 计算样本量 n、样本期、来源、比较范围 → 门槛判定（足／不足） | 计算能力基本已有，缺的是把它输出出来 |
| ④ | 输出 结论 + 可信度条 | ① 价格结论（区间）② 可信度条：样本量 n=XX、样本期、来源、范围 ③ 不足时的降级解释 | 呈现样本量即可，绝不宣称「绝不失真」（见第六章 6.4） |
| ⑤ | 后置 降级与切换 | 有结果：看同條件房源。无结果／样本不足：一键扩大范围并明确标注「比较范围已扩大至…」 | 无结果绝不白屏——白屏是「太粗糙」（F218）与「数据不准」投诉的共同来源 |
- 元数据必须与结论同屏：不得折叠进「说明」或二级页面。
- 无结果必须给降级路径：不得白屏，不得只显示「查无资料」。
- 范围变化必须明示：自动扩大范围后要明确告知，否则用户会拿不同范围的数字互比——正是 F234 的机制。
- 只呈现样本量，不承诺精度：细粒度样本本来就薄（F045），承诺精准必被证伪。
- 不新增入口：改的是既有页面的信息完整度，不是形态。
- 主指标：解释理解率（用户能否正确说出「这个数字基于多少样本、什么范围」）；无结果率下降幅度。
- 质量指标：样本不足发生率；经核实的数据问题数／有效核查单；纠正时长。
- 护栏：行情页停留与返回率不得恶化；不得以「投诉减少」单独证明准确性提高（见第三章场景 4 与 6.4）。
六、新入口评估与两条路线的融合
本章回答：「3 秒定制」这个提案还成不成立？它与第五章主线能否融合？怎么拆成任务项并行测试？
承上：第五章给出主线（修链路）。本章评估另一个提案——「3 秒定制」行情地图：它的方向对不对、已有多少、哪些承诺要砍、对 P1 究竟覆盖多少；最后在 6.6 回答它与主线能否融合、怎么拆成任务项并行测试。
6.1 概念的四层结构与逐层判定
| 层级 | 概念主张 | 与本报告结论的关系 | 判定 |
|---|---|---|---|
| 动作层 输入预算/条件/地点 | 3 秒内用最少的输入完成一次个性化查询 | 直接对应场景 2（费用口径）、场景 3（地域心智）、场景 5（认知负担）的本质需求 | 成立 方向对，但需先核验既有筛选的覆盖度 |
| 数据层 抗噪清洗、费用归一化 | 把混杂样本清洗成可比的「同条件价格」 | 正是场景 2 的根因；已由《台湾租屋成本字段规范》给出可执行定义（固定层并入价／变动层只做标志） | 必建 普惠所有展示面，可独立推进 |
| 体验层 防坑看板、条件一致性提示 | 明确告知含什么、不含什么、样本够不够 | 对应场景 4（可信度）与场景 2 的验收指标「条件一致率」 | 成立 但不得宣称「绝不失真」 |
| 商业层 信任变现 | 以可信赖的比较换取留存与转化 | 与场景 6（查完无承接）直接相关：信任必须落在「下一步能租什么」 | 后置 先证明任务价值，再谈变现 |
6.2 证据对齐：概念不是凭空假设
“可以有儲存功能…如果能再加進篩選一些基本條件、租金、電梯、陽台非頂加，可租補等條件就更好了！” → 高分用户主动要求「预算 + 条件」驱动，是概念最强的正向证据
“希望能把附加費用拆出來…電費、水網路費、管理費，這三項附加費用其實都已經到了每月各 1000 的水準” → 费用必须拆分展示，且用户已知其为千元级变量
“近期房源都將管理費另算 與先前含管理費的房價相比當然會變便宜” → 口径混算会直接摧毁信任，是数据层必须先建的理由
“請以坪數換算租金價格及是否真為正市中心” → 单价比总价、区位真伪，是可比性缺失的两个具体维度
“不能夠用地址搜尋這樣子的話，租金行情太粗糙” → 粒度诉求，但须注意：细粒度 ≠ 样本充足
6.3 现状核验：六成能力已存在，不要重复立项
在 Touch 实价页核验结果（截图时间 2026-10-26）：既有模式已提供以下能力——
| 既有能力 | 对应概念主张 | 结论 |
|---|---|---|
| 社區／街道門牌／捷運 三种搜索框 | 动作层「地点输入」 | 已具备，问题是可发现性而非缺失 |
| 地圖按鈕 | 「行情地图」形态 | 已具备 |
| 開價租金／實價租金 双 Tab | 数据层「挂牌 vs 成交」区分 | 已具备，已优于单一均价 |
| 型態篩選（住宅大樓／公寓／透天厝／別墅／華廈） | 动作层「条件输入」 | 已具备，与 F020「一樣是公寓之類的行情」直接吻合 |
| 實價頁的车位、坪数、楼层筛选 | 可比条件 | 已具备（对应 F097、F242） |
6.4 三处过度承诺，必须砍掉
- 用「议价率系数」逆向修正成交价。挂牌价与实价申报时间的差值不等于议价幅度，全局系数会带来系统性偏差，等于用假设数字冒充成交事实——正是场景 4 要避免的错误。
- 估算并显示电费溢价金额。能耗依赖用量与个人行为，只能提取「電費另計」标志位并做假设明示的情景估算；直接给出金额会制造新的「数据不准」。
- 宣称「热度图绝不失真」。细粒度（路段／社区）样本本身就薄（参见 F045「數據過少」），承诺精准度必然被证伪。应改为呈现样本量与降级解释，而不是承诺不失真。
6.5 关键缺口：「3 秒定制」对 P1 五场景的覆盖度比对
把第四章 P1 的五个场景核心动作逐一对照，结论是2 强、1 半、2 弱——它并不是 P1 的替代方案，而是其中一部分。
| P1 场景 | P1 核心动作 | 「3 秒定制」是否覆盖 | 覆盖 |
|---|---|---|---|
| 场景 3 地域心智不匹配 | 复用既有地图/社区/地址搜索；展示搜索范围；保留条件；无结果逐步扩大并告知 | 强。地图形态与地点输入直接对口。但有一处反向风险：概念暗示「任意地点都能查」，而本场景明令不能暗示存在任意地址成交数据 | 85% |
| 场景 5 认知负担过高 | 分层展示「结论—条件—说明」；小点击区可读性；承接筛选减少重复输入 | 强。预算主导输入 = 减少重复输入；结论优先 = 分层展示。但只修新入口，老路径不动；且「全部字段复选」禁令同样适用于其输入面板 | 80% |
| 场景 2 比较口径不可比 | 比较条件摘要、含/不含费用、月固定总成本；从房源详情承接条件 | 半。数据层（含管总价）是共同底座；但「从房源详情承接条件」这一半方向相反——概念是主动输入，不解决「我在看这套房，它贵不贵」 | 50% |
| 场景 4 可信度未知 | 价格旁呈现样本量、样本期、来源、范围；少样本降级解释 | 弱，且目标冲突。本场景要求增加透明度，概念叙事是「3 秒」＝减少信息。5.4 已砍掉的「议价率系数」正是本场景明令禁止的动作 | 25% |
| 场景 6 查完无承接 | 复用高/低于中位数跳转并保留条件；验收「有效房源落地/行情查看」 | 弱，且是最致命缺口。概念的终点是「地图上的价格分布」，本场景的终点是「下一步能租什么」。F207「我要的是找房子…給我分析做什麼」与 F072「又不是知道均價就能讓屋主降價」指向的都是同一个问题——一个更漂亮的地图可能重蹈 F072 的价值质疑 | 15% |
6.6 融合：两条路线的关系与任务项拆分
大白话：把上面两条路线拆成 6 个能并行推进的任务项——先做两件不用赌的（T0 核验、T1 内核），再同时推进三处挂载（T2／T3／T4），最后才做必须等前面验证过的新入口（T5）。
结论：可以融合，而且应该融合。它们不是二选一，而是层级不同——修链路决定「用户会不会信」，新入口决定「想用的人用得多快」。更关键的一点：「3 秒定制」与挂载③作用在同一个页面对象（行情页）上，前者是后者成熟之后的交互重构阶段，不是另一个项目。
| 任务项 | 路线 | 内容 | 依赖 | 并行性 | 验证方式 |
|---|---|---|---|---|---|
| T0 能力核验 | 共用 | 核验 9/23 地图模式是否已支持「预算 + 型态」叠加；核验预算字段各端覆盖率 | 无 | 零成本先行 | 若已支持 → 只是可发现性问题，不立项 |
| T1 内核 | 共用 | 含管总价数据层（月固定总成本）+ 元数据（样本量／期／来源）+ 支持传入条件 | 无 | 可独立先做 | 离线评估：字段覆盖率、口径一致率 |
| T2 挂载① | 修链路 | 房源详情 → 行情的条件承接 | T1 | 独立，可并行 | A/B：房源落地率、条件一致率 |
| T3 挂载② | 修链路 | 列表筛选后的中位价与预算校准 | T1 | 独立，可并行 | A/B：预算校准率 |
| T4 挂载③ | 修链路 | 行情页补可信度条与无结果降级 | T1 | 与 T5 互斥（同一页面） | A/B：解释理解率、无结果率 |
| T5 3 秒定制 | 新入口 | 预算驱动的行情查询交互重构 | T1 + T4 | 后置 | A/B：主动查询成功率 |
- T2 与 T3 可并行：作用于不同页面（详情页 vs 列表页），可做分层实验；但同一用户可能同时命中，需正交分层或设置互斥域，否则无法归因。
- T4 与 T5 必须互斥：都在行情页，同时上线无法归因。正确顺序是先 T4 验证可信度信息有效，再 T5 重构交互。
- T5 不得早于 T1：没有内核就做新入口，等于让更多人更快地拿到不可比的数字——正是 F072 与 F234 的成因。
七、反馈运营闭环机制
本章回答：反馈怎样变成可核查、可执行的改进？
核心结论：当前反馈无法定位到「哪一端、哪个版本、哪个页面、什么查询条件」，导致大部分「不准」无法核查。先建字段与分流，再谈分析。
每条反馈应保留：日期、端/版本、页面/模式、进入来源、查询条件、评分、原文、问题对象（行情/房源/刊登/账户）、主/次主题、事实/推断标记、责任团队、处理状态、复验结果。对「数据不准」追加费用与样本范围字段，不要求用户理解内部指标。
| 时间 | 动作 |
|---|---|
| 第 1 周 | 建立标签边界与分流规则；复现遮挡/条件丢失/错误地域；抽查费用与车位争议 |
| 第 2 周 | 招募不同端的近期低分者、正向复访者及未用行情者，完成真实找房任务；不得只访问给差评者 |
| 第 3–4 周 | 分别测试入口低干扰、条件承接、价格解释，采用预先随机分组，避免同时改变多项后无法归因；保存/提醒先原型验证 |
| 周更 | 同时报告反馈量、评分分布、低分占比、文本率及端/版本结构；主题统计只能以已审阅文本为分母，保留「不可判定」类 |
八、分析限制与风险（必读）
本章回答：哪些结论不能用、不能用在哪里？
- 最新期样本极薄：10/15–25 仅 4 条非空文本（含招呼/乱码/求房咨询），不能证明老问题已解决，也不足以生成新的稳定痛点排名。
- 评分与文本需双轨保留：高分可含具体需求或负面表述（如 F042 给 10 分却质疑偏低），低分可配 “good/Ok” 等正面词。不用关键词校正评分，不把 8–10 分等同无痛点。
- 日期与产品模式必须联读：9/13 地图诉求早于 9/23 地图上线；9/23 地址诉求来自 iOS，而当前仅验证 Touch 实价地址入口，不能宣称 APP 同日已满足。
- 来源表缺少上下文：无反馈页面、曝光与版本字段，「复杂/不准/贵」等留言的对象可能不明，相关条目保持「待确认」状态。
- 反馈者偏向已进入用户：无法解释大量未使用者为何没进入；渗透率提升必须结合未使用者任务测试与入口实验，不能只靠反馈驱动。
- 混入「非行情」反馈（未剔除，已单列说明）：约 8–9 条为纯求租／求房咨询或政策咨询，并非评价行情功能，仍留在 1,909 与 246 条文本基数中。已测算剔除后全样本均分与低分率不变、文本低分率仅 +0.3pp，故不影响结论；但严格口径下应标为第 9 类并排除出行情满意度分母。
- 隐私：共享版不公开全量原文或可联系个人信息。F087/F088（Line ID）、F134/F140/F148（手机号）、F217（门牌）已脱敏或不引用。
- 第六章「现状能力核验」的边界：既有能力清单基于 2026-10-26 单次 Touch 实价页截图，未核验 APP（iOS/Android）与 MINIAPP 端。因此「六成能力已存在」的判断仅对 Touch 成立，不得外推为全端结论；STEP 0 应先补齐各端核验。
- 概念评估属方案论证，非需求量化：第六章判定的是「方向是否成立、缺口在哪里」，不能作为用户需求规模的证据；概念的用户价值必须由 STEP 2 的 A/B 实测给出，不能引用本报告的反馈条数来证明。
附录：关键证据索引
按场景编号汇总本报告引用的全部证据，供内部追溯。编号格式为 Fnnn（对应审读顺序）与 记录 ID。
| 场景 | 编号 / 记录ID | 日期 · 端 · 分数 · 身份 | 原文（已脱敏） |
|---|---|---|---|
| 1 | F070 / 10551 | 06-28 · iOS · 2分 · 仲介 | 會蓋掉一些內容 |
| 1 | F071 / 10552 | 06-28 · iOS · 2分 · 房客 | 卡在畫面上面會一直點到 |
| 1 | F207 / 15594 | 09-15 · Touch · 2分 · 缺失 | 我要的是找房子找租屋，給我分析做什麼，干擾搜尋 |
| 2 | F234 / 16649 | 10-03 · iOS · 2分 · 缺失 | 近期房源都將管理費另算 與先前含管理費的房價相比當然會變便宜 |
| 2 | F079 / 10819 | 07-02 · iOS · 8分 · 缺失 | 希望能把附加費用拆出來…電費、水網路費、管理費 |
| 2 | F097 / 11252 | 07-09 · Android · 8分 · 房客 | 請將有無車位的選項加入，以利正確分析 |
| 2 | F242 / 17264 | 10-13 · Touch · 2分 · 缺失 | 請以坪數換算租金價格及是否真為正市中心 |
| 2 | F168 / 14216 | 08-23 · Touch · 2分 · 自述屋主 | 我是屋主，數據都亂打根本不是這樣，明明含車位出租 |
| 3 | F028 / 9218 | 06-06 · Android · 6分 · 缺失 | 如何在台中北區下劃分出一中商圈、中國醫…是否另有地圖？ |
| 3 | F218 / 16006 | 09-23 · iOS · 2分 · 仲介 | 不能夠用地址搜尋這樣子的話，租金行情太粗糙 |
| 3 | F171 / 14472 | 08-27 · iOS · 2分 · 缺失 | 竟然沒有游泳路的資料 |
| 4 | F045 / 9875 | 06-17 · Android · 6分 · 缺失 | 數據過少，未來應加強數據與房間內數等 |
| 4 | F042 / 9765 | 06-15 · Touch · 10分 · 缺失 | 都寫的比真實行情還要低（高分但质疑偏低） |
| 5 | F086 / 11017 | 07-05 · Android · 2分 · 房客 | 全部不能複選，浪費很多時間 |
| 5 | F200 / 15366 | 09-11 · Android · 2分 · 缺失 | 很雜亂，字小 |
| 6 | F128 / 12540 | 07-29 · iOS · 10分 · 房客 | 可以有儲存功能…再加進篩選一些基本條件、租金、電梯 |
| 6 | F183 / 14976 | 09-04 · Android · 10分 · 房客 | 可以提供某些條件租屋物件推出時的提醒 |
| 7 | F043 / 9775 | 06-15 · Touch · 8分 · 房客 | 針對一些已出租的房子做核實，太多詐騙 |
| 7 | F186 / 15040 | 09-06 · iOS · 4分 · 房客 | 已售出應該要下架 |
| 7 | F217 / 15967 | 09-22 · Touch · 4分 · 自述屋主 | 我是新北市淡水區[門牌已遮蔽]的屋主…有人登二萬伍無裝潢在貴司廣告請徹消（已脱敏） |
| 8 | F090 / 11072 | 07-06 · iOS · 10分 · 屋主 | 希望能讓我們可以看三個月六個月，一年五年的數據 |
| 8 | F212 / 15839 | 09-19 · iOS · 8分 · 屋主 | 成交資訊與上架到成交多久時間 |