查詢租盤已讀不回？用 ricacorp-scraper 嘅 price_changes／updated_at 排程追蹤，自己拆解幾耐先算代理棄咗你

一句話： 查詢租盤畀齊資料之後代理已讀不回，唔係個別經歷；但單次核對放盤資訊得出嘅係「呢個盤啱唔啱」，答唔到「仲要唔要繼續等」。用 ricacorp-scraper 排程重複抓同一批放盤，追蹤 updated_at同price_changes 呢兩個欄位跨次 run 嘅變化，先睇得出個盤源仲有冇人打理。

問完晒要求嘅資料，然後就冇晒回音

有人喺 Threads 公開分享 一次查租盤嘅經歷：揾咗幾個地產代理查詢租盤，每一個都問完佢哋要求嘅資料（例如入息證明、上樓時間）之後就冇再覆，連一句「而家冇合適盤源」都冇講，令佢懷疑係自己漏咗做啲咩，定係盤源本身有問題。

呢種「畀齊資料換嚟一片靜默」嘅經歷，本身已經好難搵到客觀答案——你冇辦法直接查到代理個人有冇睇你個訊息。但有一件事係查得到嘅：呢個盤源本身，喺呢段靜默期間，仲有冇被人打理更新。現有《「有放盤」定「得出租」？地產代理話術一戳就穿》一文處理嘅係「代理帖出嚟嘅放盤資訊同官方資料啱唔啱」（deal_type 買定租、叫價對唔對得上）——嗰篇答嘅係查詢之前嘅問題；呢篇處理嘅係查詢之後嘅問題：等緊回覆期間，點樣客觀判斷仲要唔要繼續等。

單次核對 vs 排程追蹤，答緊唔同問題

點樣用 ricacorp-scraper 排程追蹤一個盤

ricacorp-scraper 目前只有 search 一種模式，冇按盤源編號直接攞單一筆嘅 detail 模式，亦冇關鍵字／屋苑搜尋參數——可用嘅篩選淨係得 regions（港島／九龍／新界東／新界西）同 rooms。要追蹤某一個特定盤，做法係將同一組條件排程重複跑，每次攞返成批結果，自己喺輸出入面用 post_no（或 listing_url）搵返你想追蹤嗰筆。

Step 1 — 建立第一次基準快照

{ "mode": "search", "dealType": "rent", "regions": ["九龍"], "maxItems": 200 }

dealType: "rent" 對應出租盤（利嘉閣出租盤約 5,924 筆，見 input schema 說明）。留意 maxItems 係全部 regions 合計嘅上限，唔係每區——如果你想追蹤嘅盤源所屬地區放盤量大，maxItems 設太細有機會漏抓咗嗰一筆，之後誤判成「落架」。

跑完之後，喺結果入面用你查詢嗰個盤嘅 post_no（代理發嘅連結通常都會有，格式例如 CU88487564）搵返對應嗰一筆，記低佢嘅 updated_at 同 price_changes（有冇改價紀錄）當做基準。

Step 2 — 用 Apify Schedule 排程重複執行

喺 Apify Console 嗰隻 actor 頁用 Schedule 功能，填 cron 表達式（例如每日一次）就會自動幫你用同一組 input 定時重跑，唔使自己寫排程邏輯或者長開伺服器。

Step 3 — 跨次比對，分辨「落架」定係「冇更新」

每次排程 run 完之後，同一套邏輯再搵一次同一個 post_no：

• 搵唔返：呢筆盤源已經唔喺利嘉閣現時仍在放嘅名單度——可能已成交、已落架，或者代理主動落咗盤。
• 搵到但 updated_at 同 price_changes 都冇變：盤源仲喺度，但呢段期間冇被打理更新。連續幾次排程都係咁，代表呢個盤同呢個代理喺呢段時間都幾靜止。
• price_changes 多咗新一筆（見 changed_at 時間戳）：代表代理有喺打理呢個盤、有實際改緊叫價，仲喺度活躍緊。

呢個方法做唔到嘅事——updated_at／price_changes 反映嘅係盤源資料本身有冇被更新，唔係代理有冇睇你個人訊息，更加證明唔到係咪刻意已讀不回。但如果連盤源都靜止咗一段時間，起碼可以幫你判斷係「成個盤都冇人理」定係「淨係冧咗我」，作為決定要唔要繼續等落去嘅其中一個客觀參考。

想進一步核對：呢個地區係咪真係靜市

如果想知道係咪淨係呢個盤靜，定係成個屋苑／地區近排都冇乜成交、代理都好難有新進展畀你，可以用 centaline-scraper 嘅 transactions 模式排程追蹤同一屋苑嘅實際成交（官方 store 頁示範）：

{ "mode": "transactions", "keywords": ["太古城"], "dealType": "rent", "dateFrom": "14d", "maxItems": 30 }

dateFrom 點揀，《「有放盤」定「得出租」？地產代理話術一戳就穿》嗰篇已經解釋過；呢度用嚟就知道呢段時間嗰個屋苑到底有冇租盤／買賣真正落成。留意中原同利嘉閣係兩間獨立代理，屋苑命名同物業編號都唔一定對得上，只可以用地區＋屋苑名做粗略比對，唔係逐盤對應。想再深入了解 transactions 模式點樣同 ccl 大盤指數一齊排程追蹤，可以睇返《CCL指數話全年樓價升12%，沙田第一城照樣蝕100萬沽》呢篇。

實際要花多少

兩隻 actor 都係 PPE（按實際抓到嘅筆數計費），同用 search-listing 事件，每筆 $0.002（ricacorp-scraper 定價、centaline-scraper 定價）：

排程每日跑一次 ricacorp-scraper 追蹤同一批放盤，一個月（約 30 次）大約 $12；如果只追蹤單一地區細範圍、maxItems 設低啲（例如 50），成本會再低好多。

三條路，挑一條開始

從最省事到最自由

我幫你跑 代管，每天送到你的表 你什麼都不用做。每月 US$299 起。 直接在這用 跑免費工具 即時、免設定、就在本站。 跑我的 actor 用你自己的 Apify 帳號 同一份資料，你自己跑、按筆計費。 自己動手建 免費註冊 Apify 開免費帳號，自己把管線建起來。

本文含 Apify 推薦連結（不影響你的費用）。文中的成本與比較都據實列出，包含 Apify 不划算的情況。

FAQ

ricacorp-scraper 冇 detail 模式，點樣追蹤單一個盤？ 呢隻 actor 目前得 search 一種模式，冇按盤源編號直接攞單一筆嘅 detail 模式。做法係將同一組 regions／dealType 排程重複跑 search，每次都攞返成批結果，再用你想追蹤嗰個盤嘅 post_no（或 listing_url）喺每次結果入面搵返同一筆，睇佢嘅 updated_at 同 price_changes 有冇變化。

updated_at 同 price_changes 有咩分別？ updated_at 係上游最後一次更新呢筆盤源嘅時間戳，任何欄位改動都可能令佢更新；price_changes 係專門記錄叫價變動嘅陣列，每次改價先會新增一筆，包含改價前後嘅金額同時間。冇改過價嘅盤 price_changes 係 null，但 updated_at 仍然可以因為其他欄位（例如標籤、相片）更新而變動——兩個訊號唔可以互相取代，要一齊睇。

點知道個盤係真係落架，定係淨係冇更新？ 如果你追蹤緊嘅 post_no 喺較後一次排程 run 嘅結果入面完全搵唔返，代表嗰筆盤源已經唔喺利嘉閣網站現時仍在放嘅名單度（可能已成交、已落架，或者代理主動落咗盤）。如果個盤仍然出現但 updated_at 同 price_changes 連續幾次排程都冇變，代表盤源仲喺度，但冇被打理更新。留意 maxItems 同你篩嘅 regions 要夠闊，唔係漏咗攞先誤判做「落架」。

點樣排程執行 Apify actor？ 喺 Apify Console 嗰隻 actor 頁用 Schedule 功能，填 cron 表達式（例如每日一次）就會自動幫你定時重跑同一組 input，唔使自己寫排程邏輯或者長開伺服器。

呢個方法可以證明代理刻意已讀不回？ 唔可以。呢個方法只可以話你知個盤源資料本身有冇被更新，答唔到代理有冇睇你個訊息、定係淨係冧咗你一個人。但如果個盤源連續耐都冇更新，可以幫你判斷「成個盤都冇人理」定係「淨係冧咗我」，作為要唔要再追落去嘅其中一個客觀參考，唔係唯一根據。

作者 Chad 實際經營 40+ 隻上架 Apify actor（含本文用到嘅 ricacorp-scraper、centaline-scraper），文中每個欄位定義同計費數字都對照返兩隻 actor 嘅 store 頁與 input schema，查不到來源嘅嘢呢篇唔會寫。