前言...或說，筆記的開始
嗯...最近很多人在問 LINE Bot 串 Google 表單這件事。老實說，這算是個很常見的需求，不管是做個簡單的問卷、活動報名，或是只是想自動收集點資料，都會碰到。
但網路上教學很多，有點雜。我想整理一下思路，大概有幾種做法，各有優缺點。這篇不像教學，比較像我自己的思考筆記，邊想邊寫下來。
為什麼要串？先想一下使用情境
在想「怎麼做」之前，我會先想「為什麼」。直接丟一個 Google 表單連結給使用者填，不是不行，但體驗上...你知道的，就是很「表單」。 有時候會希望對話感強一點，讓人感覺是在跟一個助理聊天，而不是在填寫一份制式的問卷。
所以，情境很重要：
- 簡單回饋或投票：可能只是想問「今天活動滿意嗎？ (A)滿意 (B)普通 (C)不滿意」。這種的，殺雞焉用牛刀，不用搞得太複雜。
- 活動報名：需要收集姓名、電話、Email。這就需要比較完整的資料寫入流程，而且最好能防呆。
- 客服初步篩選：先用 Bot 問幾個基本問題，像「您想問的是產品問題還是訂單問題？」，然後把初步結果記錄下來，再轉給真人。
不同的情境，適合的方法完全不同。先想清楚這個，才不會白費工。
實作方法...我想到的有這三種
好了，進入正題。我把方法分成三類：最簡單的、最標準的、還有最無腦（稱讚意味）的。
方法一：作弊的捷徑－預填表單 URL (Pre-filled URL)
這個方法最簡單，也最受限。Google 表單其實有個隱藏功能，可以產生一個「預先填好答案」的連結。
怎麼做呢？
- 去你的 Google 表單，右上角點「...」，選「取得預先填入的連結」。
- 在表單裡隨便填個範例答案，然後點擊最下面的「取得連結」。
- 你會拿到一串很長的 URL。注意看，URL 後面帶了很多 `&entry.xxxx=答案` 這樣的參數。
嗯，接下來你知道了吧？在你的 LINE Bot 裡，當使用者回答問題時，你就用程式把他的答案組合進這串 URL，最後把這個組合好的連結用按鈕的方式回傳給使用者，跟他說「點我完成最後一步」。
使用者點了之後，會看到一個已經幫他填好答案的 Google 表單，他只要確認一下，按下「提交」就好。
優點是超快，完全不用寫什麼複雜的 API 串接。缺點是...使用者還是要多跳轉一次畫面、多按一次提交，體驗不是最好的。
方法二：最正統的作法－Google Apps Script (GAS)
這個是最多人用的方法，因為...免費，而且彈性最大。 簡單說，就是用 Google 自己出的雲端 JavaScript 平台 (Google Apps Script, GAS) 來當作 LINE Bot 的 Webhook 伺服器。
流程大概是這樣：
- 使用者傳訊息給 LINE Bot。
- LINE Platform 把這個訊息（一個 JSON 資料包）用 POST 的方式，丟到你指定的 Webhook URL。
- 這個 Webhook URL 就是你用 GAS 部署出來的一支網路應用程式。
- GAS 裡面會有一個叫 `doPost(e)` 的函式，專門用來接收 LINE 丟過來的資料。
- 你在 `doPost(e)` 裡面寫程式，解析收到的 JSON，把需要的資料（例如使用者 ID、訊息內容）拿出來。
- 然後，用 `SpreadsheetApp` 這個 GAS 內建的服務，打開你的 Google 試算表，把資料用 `appendRow()` 的方式寫進去。
聽起來很順，對吧？大部分教學也是這樣寫的。 關鍵就是那個 `doPost(e)` 函式，所有的魔法都在裡面發生。 還有，你的 GAS 專案要「部署為網路應用程式」，並且權限要設定成「任何人，甚至匿名使用者」都可以存取，LINE 的伺服器才能把資料丟給你。
方法三：花錢省事的選擇－無程式碼平台 (No-Code)
如果你不想寫程式，或是專案很急，那就可以考慮用 Make (以前叫 Integromat) 或 Zapier 這種自動化平台。 這些平台上面有數千個 App 的連接器，包括 LINE 和 Google Sheets。
用 Make 來舉例，整個過程就像在畫流程圖：
- 在 Make 裡面開一個新的情境 (Scenario)。
- 第一個模組，選擇 LINE，觸發條件選「Watch Events」(監聽事件)。它會給你一個 Webhook URL，把它貼到 LINE Developers 後台的 Webhook 設定裡。
- 第二個模組，選擇 Google Sheets，動作選「Add a Row」(新增一列)。
- 然後，把 LINE 模組收到的資料，像是 `message.text`、`source.userId`，直接用滑鼠拖曳對應到 Google Sheets 模組的欄位裡。
- 打開情境，完成。有人傳訊息，資料就會自動新增到試算表裡。
這方法的好處是超級快，幾乎不用寫程式碼，而且很穩定。 缺點就是要錢，雖然它們都有免費方案，但通常會有執行次數的限制。
對了，說到這裡，國外的 Make 或 Zapier 是主流，但在台灣的開發者社群裡，大家還是很習慣自己動手用 GAS，這點蠻有趣的。 可能是因為彈性高，而且...省錢吧。
三種方法的比較...我來整理個表
講了這麼多，用個表格來總結一下我的看法，可能會更清楚。
| 評估項目 | 方法一：預填 URL | 方法二：Google Apps Script | 方法三：無程式碼平台 (Make) |
|---|---|---|---|
| 建置難度 | 超低。大概國中生都會，只要會複製貼上。 | 中等。需要懂一點 JavaScript 和 API 的基本概念。 | 低。基本上就是用滑鼠點一點、拖一拖。 |
| 開發時間 | 很快，大概 15 分鐘吧。 | 不好說。順的話一兩個小時，卡住的話...可能要一兩天。 | 也很快，熟悉的話大概 20-30 分鐘可以搞定。 |
| 維運成本 | 零。就是一個 Google 表單。 | 幾乎是零。但程式是你自己寫的，出錯要自己查 (debug)。 | 看用量。免費方案有上限，超過就要付月費。 |
| 使用體驗 | 普通。使用者還要跳轉頁面再按一次提交，有點煩。 | 最好。可以在 LINE 裡面完成所有對話，無縫接軌。 | 也很好。跟 GAS 一樣，可以在 LINE 裡完成所有事。 |
| 彈性與擴充 | 極低。基本上沒啥好擴充的。 | 最高。你想串什麼奇怪的服務，只要 Google Apps Script 支援，你寫得出來就行。 | 高。Make 支援超多服務，但如果遇到它不支援的，就沒輒了。 |
一些坑...或說限制
每種方法都有它的問題，實作前最好先知道。
- GAS 的坑：
- 版本問題： 每次修改完程式碼，都要「重新部署」成「新的版本」，不然你線上跑的還是舊的 code。這點新手超容易忘記。
- 權限地獄： 有時候會遇到 Google Sheets API 權限沒開，或是 Script 存取試算表的權限跑掉，都要花時間去 Google Cloud Platform 或專案設定裡檢查。
- 執行時間限制： GAS 的每次執行有 6 分鐘的上限。如果你在 `doPost` 裡做了太多複雜運算，可能會超時。
- 無程式碼平台的坑：
- 執行頻率： 免費方案通常不能即時觸發，可能是每 5 分鐘或 15 分鐘才檢查一次。 如果你需要即時回覆，就得上付費方案。
- 客製化限制： 雖然方便，但你只能用它提供的功能。如果想做一個很特別的驗證邏輯，可能會卡關。
- 預填 URL 的坑：
- URL 長度： 如果你的表單題目很多、答案很長，URL 可能會變得超級長，有極小的機率會超過某些裝置或瀏覽器的限制。
- 資料驗證： 它沒辦法在 LINE 端就先驗證使用者輸入的格式對不對（例如 Email 格式），只能等使用者跳到表單頁面後，由 Google 表單自己去驗證。
結論...該選哪個？
嗯，思考到這裡，結論好像也蠻明顯的。
我的建議是：
- 只是想玩玩、做個超簡單的內部小調查：用「預填 URL」吧，最快。
- 你是工程師、或想認真做一個產品、而且不想花錢：那毫無疑問選「Google Apps Script」。雖然麻煩一點，但學會了就是你的。 網路上有很多範例可以參考，像是 iT 邦幫忙或一些開發者的部落格。
- 你是行銷人員、老闆叫你明天就要上線、或你覺得時間比金錢重要：用「Make」之類的平台，花點小錢解決問題，把時間拿去做更重要的事。
沒有最好的方法，只有最適合你現在情境的方法。先想清楚需求，再動手吧。
好啦，筆記就先到這裡。你正在考慮用哪種方式呢？還是有踩過什麼我沒提到的坑？可以在下面留言分享一下。
