Threads 帶來的詢問要看多久？先定義比較期間
先訂定點擊到詢問的觀察窗口、來源口徑與納入規則，再解讀 Threads 帶來的詢問，避免把相關變化說成確定歸因。
要衡量 Threads 帶來的詢問，先決定觀察多久、怎麼判定來源，再看數字。把窗口和計算口徑寫在報表前，才能分清可歸因的詢問與僅供參考的相關變化。核心不是替 Threads 找一個通用答案，而是讓每筆詢問都依同一規則判定：從哪個可辨認的點擊開始、等待多久、哪些證據足以連結來源。窗口要在讀取成果前先訂好；證據不足時保留未知，避免把推測寫成因果。
從點擊到詢問通常隔多久？
沒有一個適用所有帳號的固定天數。從看見貼文、點開外連，到整理需求或提出問題，中間可能隔著多次閱讀與比較；也可能沒有留下能辨認來源的點擊紀錄。因此，先問這份資料能回答什麼：你是否同時記下外連點擊時間、詢問時間，以及能把兩者合理連起來的線索？如果只有每週詢問總數，就能看同期變化，不能推算每個人從點擊到詢問花了幾天。
先定義「詢問」：例如收到表單、明確私訊或可辨認的商業聯絡；按讚、追蹤、一般留言另列，別和詢問混為一談。再依你的決策用途選窗口：比較貼文、安排後續追蹤，或檢視一輪活動，等待時間可能不同。假設你在評估是否值得持續追蹤某篇貼文，可以先選一個便於執行的觀察期，逐筆記錄連結成功的點擊與詢問間隔；這是工作口徑，不是市場平均。資料累積後，再看詢問是否集中在窗口前段，或仍持續出現。樣本很少時，先檢視每筆記錄和缺漏，比單看平均天數更有用；不要因為某個數字看起來漂亮，事後才挑窗口。
實作時可建立一列一筆的追蹤表，欄位包含貼文識別、點擊時間、詢問時間、來源證據、是否在窗口內及判定理由。先想清楚窗口要支援哪個決策，例如一輪追蹤結束後是否繼續發布同類內容，再照團隊實際的檢視節奏設定期限。不要拿某次個案最快回覆的時間當通則。每次檢視先列出已走完窗口的筆數，再看時間間隔；若要改窗口，就另記版本和生效日，避免只保留看起來較好的算法。
比較期間的起訖怎麼定？
把「收集點擊的期間」和「每次點擊後等待詢問的窗口」分開記。前者說明納入哪段時間發生的點擊，後者說明每筆點擊要追蹤多久。起點可採可辨認的外連點擊時間，終點採詢問實際收到的時間；再明訂時區、邊界是否包含，以及窗口用連續時數還是日曆日。不同口徑會讓同一筆詢問落入不同區間，所以比較貼文或月份時都要沿用同一套定義。遇到缺少時間戳記的資料，先標出缺值，不要用匯出日期代替事件時間。
假設窗口設定為點擊後七乘二十四小時內，且包含剛好到期的時刻：六月一日上午九點點擊，六月八日上午九點收到詢問，就列入窗口；六月八日上午九點之後收到，則超出窗口。若報告在六月五日就結算，六月四日的點擊尚未完整走完七天，不能直接和已觀察滿七天的點擊比較。可採作法是只比較已滿窗口的點擊批次，或另列「追蹤未完成」數量，等窗口走完再更新。月報也應註明點擊批次的起訖，而不只寫詢問發生月份，否則期末點擊會被低估。每次改窗口，保留新舊口徑與生效日期；不要回頭混算後仍稱為同一期間。
操作上可把點擊批次視為一組，先記錄該組最晚點擊的時間，再加上完整窗口，作為資料可結算的日期。報表需要提早產出時，將尚未成熟的批次獨立列出，並在更新時用相同起訖規則補齊。若跨越月份或不同時區，先選定報表使用的時區，將點擊和詢問時間統一換算後再判斷邊界；不要一邊用平台顯示的日期、一邊用表單所在地時間。這樣能避免月底點擊被錯放到下個月，也讓不同人重算時得到相同分類。
重複造訪要怎麼處理？
先決定報表的計算單位是點擊、造訪、詢問，還是可辨認的聯絡對象。這幾種單位回答不同問題：多次造訪代表互動次數，不等於多位潛在客戶；同一人提出兩個不同需求，也未必應合併成一筆。若同一個可用識別線索能連起多次點擊，可採首次符合條件的點擊作為主要來源，並把後續點擊另記為再次造訪。若要研究最後一次接觸，可另做一欄，但不要同時把同一詢問完整歸給首次和末次點擊，造成來源合計超過詢問總數。
假設同一位已識別訪客週一點擊貼文、週三再次點擊，週五送出一份詢問：以「每筆詢問只計一次」為原則，可把週一列為主要接觸、週三列為輔助接觸；這是報表規則，不代表週一單獨造成詢問。若系統沒有可靠識別方式，就把兩次點擊列為兩次點擊，不自行推定是同一人。詢問端也可用案件編號、表單紀錄或其他實際存在的欄位去重；只有內容相似，未必足以合併。對於重新整理頁面、重複提交或同一人補充原問題，依事先訂好的規則核對並保留更正紀錄。跨裝置或匿名紀錄無法可靠合併時，標為未知，不為了讓數字整齊而拼接身分。
去重規則可以寫成簡單的判定順序：先檢查是否有相同案件編號，再看是否有可核對的聯絡資料和相近的提交時間；若要合併，記下合併依據，並保留原始紀錄以便回查。若只有匿名造訪或無法確認的相似內容，就維持分開計數，不以猜測補上身分。報表也要明示主要統計的是「詢問件數」還是「聯絡對象數」；需要時兩者並列，讀者才不會把重複接觸次數誤認為新增客戶數。規則變更後，舊資料要按新規則重算才能比較，或清楚註明兩段數字採用不同口徑。
直接流量能否算入來源？
直接流量通常只能描述一次造訪沒有帶來可辨認的來源資訊；這本身不能證明訪客是從 Threads 來。來源資訊可能因分享方式、瀏覽器或連結轉傳而缺失，因此不要只因為詢問時間接近某篇貼文，就把它歸到該貼文。可把來源分成「可辨認的 Threads 外連」、「明確記錄的其他來源」和「來源未明」等類別，並在表單或接洽紀錄中保留當事人實際提供的來源說法。對方提到 Threads，是有用的線索，但和系統記錄到某一篇貼文的點擊仍是兩種證據。
未來若能管理外連，可使用一致的活動標記或來源欄位，並先確認點擊紀錄和詢問紀錄實際有被接收、保存；不要只因網址加了參數，就假設歸因資料已完整。假設一位訪客直接進站並留下詢問，之後在回訪時說曾從 Threads 看見你：可記為「自述與 Threads 相關，點擊未確認」，不要改成已追蹤點擊。若另有可連結的點擊記錄，則按既定窗口和去重規則判定。每月固定抽查少量原始紀錄，確認來源欄位的含義沒有被改寫；若採用分析工具，事件接收與轉換設定也要實際核對。無法確認的直接流量仍保留在總詢問數中，但不列入已確認的 Threads 歸因數。
建立標記時，先為每個活動約定固定的來源、媒介和活動名稱，避免同一個連結出現多種拼法，導致報表被拆成不同來源。發布前用實際連結走一次流程，確認頁面能開啟、參數仍保留，並檢查點擊和詢問紀錄是否出現在預期位置。這只是檢查資料路徑，不代表每次造訪都能識別個人；轉傳、匿名瀏覽或裝置切換仍可能讓連結中斷。遇到這些情況，保留「未能連結」的分類，比把直接流量全部分給最近發布的內容更能維持口徑一致。
哪些情況只列為相關觀察？
遇到無法連起點擊與詢問的情形，仍可保留訊號，但要另放在「相關觀察」或「來源未明」欄，不併入可確認歸因。常見情形包括：當事人說曾看過 Threads 貼文、同週貼文互動增加但沒有個別點擊資料、直接流量恰好在發文後上升，或有人從朋友轉傳的截圖得知你。這些資訊可以提示團隊要追問什麼、下次該補記哪些欄位；它們單獨不能證明哪一則貼文帶來哪一筆詢問。
也要將不同限制分開寫。詢問超出觀察窗口，可列為「窗口外的後續詢問」；窗口尚未走完，列為「追蹤未完成」；點擊有記錄但無法連結詢問，列為「點擊已知、結果未連結」；只有對方自述，列為「自述來源」。假設某週發文後詢問總數增加，但沒有連結層級的點擊與來源紀錄，報告可以說兩者同期出現，並附上待補的紀錄方式，不能說 Threads 造成增長。若同時有其他活動或聯絡管道，也應列出為可能背景，不要把整段期間的變化全部分給單一貼文。這種分類能留下可行動的線索，又不把推測包裝成已確認的結果。
如果同一期間有電子郵件、活動、轉介或其他社群內容，也把它們列在背景欄位，記下日期和已知接觸資訊。報告可以呈現詢問總量如何變化，也可以指出與 Threads 發布同時發生；但若缺乏能連結個別詢問的證據，就不把總變化分配給某一管道。這些觀察仍有用途：例如提醒團隊在表單中加入來源提問，或下次為不同活動準備可辨認的連結。記錄時分開寫「看到了什麼」和「目前能判定什麼」，後續補到證據再更新分類，不必刪除原先的觀察紀錄。
報告如何註明限制？
報告至少寫明觀察期間、點擊批次起訖、點擊後窗口長度、時區、詢問定義、去重單位與來源分類；再交代哪些紀錄可以相連、哪些欄位缺漏，以及仍未滿窗口的批次怎麼處理。分開報出已確認的 Threads 詢問、相關但未確認的詢問、來源未明的詢問和總詢問數，讀者就能知道每個數字的範圍。若使用比率，寫清楚分子和分母，例如「窗口內可連結詢問數 ÷ 已追蹤完成且可辨認的外連點擊數」；不能把總詢問直接除以不完整的點擊資料後，稱為貼文轉換率。
假設某次報告有四十次已追蹤完成的可辨認點擊，其中四筆詢問符合窗口、連結與去重規則，則該口徑下比率為四除以四十，即百分之十；這只是說明算法的假設例子，不是成效基準。另列窗口未滿的點擊和來源未明的詢問，避免把它們默默當成零。不同月份要沿用同一口徑；若曾更改窗口或事件定義，就註明變更並避免直接比較。下一步先挑一篇貼文，建立記錄點擊時間、詢問時間與來源判定的表格，等窗口走完再讀結果。若要整理 Threads 相關貼文與關鍵字、每日佇列及三則回覆草稿，草稿可由你編輯、選擇並手動發布；可從 ThreadScout 查看。