LINE Bot 如何取得 GPS 定位？位置分享功能串接步驟與實作要點

欸，最近在玩 LINE Bot，發現那個定位功能好像很多人有疑問

哈囉大家好，最近在公司群組跟一些開發者朋友聊天，發現一個蠻常被問到的問題：「那個…我的 LINE Bot 要怎麼知道客人在哪裡啊？可以主動抓他的 GPS 嗎？」🤔

這個問題真的超經典，因為很多人直覺會以為 Bot 就像 App 一樣，可以跳出一個「請問是否允許 XXX 存取您的位置？」的視窗。但…事情沒有這麼簡單！

一句話結論

老實說，LINE Bot **不能「主動」去要** 使用者的 GPS 定位。反過來說，是 **使用者必須「主動」透過一個特定的按鈕，把他的位置資訊「分享」給 Bot**。這是一個基於使用者同意、非常重要的隱私設計！所以開發的時候，思路要稍微轉個彎。

所以，這功能到底能幹嘛？實際應用場景有哪些？

雖然不能主動抓，但引導使用者分享位置後，玩法可多了！你想想看：

智慧找店服務 🏪：這應該是最常見的了！使用者喊一聲「我想找最近的門市」，Bot 就丟出一個「分享您的位置」按鈕，使用者點了之後，Bot 收到經緯度，馬上就能從資料庫撈出最近的 3 家分店資訊，順便附上地圖連結。
活動報到/打卡 📍：辦線下活動時超好用！參加者到現場後，在 Bot 介面點擊「我要報到」，分享當下位置。後台一比對，確認在活動範圍內，就自動完成報到手續，還能順便發一張電子優惠券。

天氣/在地資訊查詢 🌦️：

外送或物流回報 🛵：想像一下，外送員快到你家時，可以透過公司內部的 Bot 分享目前位置，讓你即時掌握他的動態，減少等待的焦慮感。（雖然這比較偏內部應用）

簡單說，只要是跟「距離」和「地點」有關的服務，幾乎都能派上用場。關鍵在於，你要設計一個讓使用者「願意」分享位置的流程。

好啦，那到底要怎麼做？串接步驟拆解

OK，來講重點了。要讓你的 LINE Bot 具備接收位置資訊的能力，主要會動到 LINE Messaging API 裡面的兩個東西：一個是**訊息本身**，另一個是**處理回傳資料**的地方 (Webhook)。

步驟一：設計一個「分享位置」的按鈕

首先，你不能只在對話框打一行「請告訴我你在哪」。這樣使用者只會一頭霧水，不知道怎麼給。最標準、體驗最好的做法，是使用「Quick Reply」按鈕。這種按鈕會浮在輸入框的上方，點完一次或傳送新訊息後就會消失，很適合用在這種一次性的指令。

在官方文件裡，這個功能叫做「Location action」。你只要在想發送的訊息物件底下，加上一個 `quickReply` 的屬性，然後在裡面定義一個 `type` 為 `action` 的按鈕，並且把 `action` 的 `type` 指定為 `location`。

聽起來有點繞口？直接看程式碼的感覺最準（這邊用 JSON 格式當範例）：

{
  "type": "text",
  "text": "點擊下方按鈕，分享你目前的位置喔！📍",
  "quickReply": {
    "items": [
      {
        "type": "action",
        "action": {
          "type": "location",
          "label": "分享我的位置"
        }
      }
    ]
  }
}

當你把這段 JSON 當作訊息內容發送給使用者時，他的 LINE 畫面上就會出現一段文字，底下跟著一顆寫著「分享我的位置」的按鈕。超級方便！

步驟二：處理 Webhook 收到的位置事件

當使用者真的點了那顆按鈕、並在跳出來的地圖上按下「分享」之後，LINE Platform 會把這個位置資訊，透過 Webhook 丟到你指定的伺服器 URL 上。

所以，你的後端程式就要準備好接收這個事件。你會收到一個 JSON 資料包，裡面最重要的就是 `message` 物件。當 `message.type` 是 `location` 的時候，就代表這是使用者傳來的位置資訊。

你會從這個物件中拿到幾個關鍵欄位：

`message.latitude`: 緯度 (一個浮點數)
`message.longitude`: 經度 (一個浮點數)
`message.address`: 地址 (一個字串，但不一定會有值！這點要注意)
`message.title`: 位置標題 (例如「台北車站」，但這也可能沒有)

嗯…對了，說到這個地址，我自己踩過坑。`address` 這個欄位，只有在使用者分享的地點剛好是 Google Maps 上的地標，或是有明確地址資訊時才會回傳。如果使用者是在一個空曠處或地圖上的任意一點分享，這個欄位很可能是空的。所以，**最可靠的永遠是經緯度**，絕對不要假設 `address` 一定會有值！

後端收到的資料大概會長這樣：

{
  "events": [
    {
      "type": "message",
      "replyToken": "xxxxxxxx",
      "source": { "userId": "Uxxxxxxxxxxxx" },
      "timestamp": 1678886400000,
      "message": {
        "type": "location",
        "id": "1234567890",
        "title": "台北101",
        "address": "110台北市信義區信義路五段7號",
        "latitude": 25.033961,
        "longitude": 121.564468
      }
    }
  ]
}

不同請求方式的比較，哪個比較好？

雖然用 Quick Reply 是主流，但也不是唯一的方法。來個簡單比較吧。

請求方式	優點	缺點	個人碎碎念
Quick Reply 按鈕	體驗最好，使用者一看就懂。點一下就搞定，超無腦。還有個官方 location icon，辨識度高。	按鈕會消失，如果使用者當下沒按，之後就找不到了。有時候會被其他訊息洗掉。	99% 的情況我都用這個啦！除非有什麼特殊需求，不然這個真的是最佳解。
純文字引導	自由度高，可以寫一長串說明，教使用者怎麼從「+」號去手動分享位置。	步驟超多，使用者大概看到一半就放棄了。容易失敗，而且感覺很笨…	說真的，除非你的用戶都是工程師，不然別這樣搞。使用者體驗直接-100分。
Flex Message 自訂按鈕	可以設計得超漂亮！跟其他資訊整合在同一個卡片裡，版面好看很多。	一樣是觸發 location action，但製作 Flex Message 的 JSON 比較複雜。	如果你的 Bot 本來就很常用 Flex Message，那整合在裡面是個不錯的選擇，視覺上一體感比較強。

跟網頁的 GPS 定位有什麼不一樣？(Localization Delta)

說到定位，很多人會直接聯想到網頁的 Geolocation API。這個東西跟 LINE Bot 的機制有什麼不同呢？

這點蠻有趣的。網頁的 Geolocation API 是一個全球通用的 Web 標準，你在任何現代瀏覽器（Chrome, Safari, Firefox...）上都能用。它會直接透過瀏覽器跟作業系統要權限，跳出那個大家都很熟悉的「`xxx.com` 想要知道您的位置」的授權視窗。

而 LINE Bot 的位置分享，是完全綁定在 LINE App 這個生態系裡面的功能。它的好處是體驗非常無縫，使用者不需要跳出 LINE App，一切都在熟悉的聊天室內完成。對於專門經營 LINE 官方帳號的商家來說，這當然是首選。

但缺點也很明顯，就是它只能在 LINE 裡面用。如果你的服務同時有網站、App 和 LINE Bot，那你就得針對不同平台做不同的定位功能。相較之下，Web Geolocation API 的通用性就高很多，做一次就能在各種瀏覽器上跑。

簡單來說：

LINE Messaging API： 深度整合 LINE 生態，使用者體驗流暢，但僅限於 LINE App 內。官方文件寫得很清楚。
Web Geolocation API： 全球網頁標準，通用性高，但需要使用者在瀏覽器環境下操作，且授權提示比較制式化。

實作上可能遇到的坑（常見錯誤與修正）

最後，分享幾個我自己在開發或看別人開發時，常常看到的幾個小問題：

問題：使用者反應按鈕沒出現！
- 可能原因： Quick Reply 按鈕只能附加在某些特定種類的訊息上，而且最多只能有 13 個按鈕。另外，使用者的 LINE App 版本如果太舊，也可能不支援。
- 修正方式： 檢查一下你的訊息 JSON 結構對不對，確保是合法的訊息格式。同時，可以溫馨提醒使用者更新他的 LINE App。
問題：收到經緯度了，但不知道怎麼用…
- 可能原因： 只有經緯度數字，如果沒有地圖 API 配合，其實沒太大用處。
- 修正方式： 你需要串接第三方地圖服務的 API，例如 Google Maps API。把經緯度丟給 Google Maps API，就可以做很多事，像是「反向地理編碼（Reverse Geocoding）」把座標換成地址，或是計算兩點之間的距離。但要注意，這些 API 大部分都需要申請金鑰，而且可能有費用。
問題：擔心使用者亂傳假定位。
- 可能原因： 確實有一些工具或方法可以傳送假的 GPS 位置。
- 修正方式： 老實說，這點很難從技術上 100% 防堵。你能做的，是在商業邏輯上做限制。例如，如果是線下活動報到，除了位置資訊，還可以加上現場工作人員掃 QR code 的步驟，做雙重驗證。對於非嚴肅的應用，或許就只能選擇相信使用者了。畢竟，防君子不防小人嘛！😅