LIFF 是什麼？讓客人在 LINE 對話框內預約、查會員、看訂單

TL;DR

• LIFF（LINE Front-end Framework）是 LINE 平台提供的網頁應用嵌入框架，讓網頁能在 LINE 對話框內直接顯示與運行，省去客戶跳出 LINE 開瀏覽器的動線斷層。
• LIFF 與一般網頁的關鍵差異有三個：身份識別來源、物理顯示空間、與 LINE 原生功能的互動能力。技術上是同一份 HTML，但這三點決定了 LIFF 體驗能不能比一般網頁更順。
• 客戶在 LIFF 內可完成多數短行程操作：預約、查會員、看訂單、瀏覽菜單、領優惠券、活動報名等；但長表單、列印、深度搜尋這類場景，仍適合留在一般網頁完成。
• LIFF 整合的體驗差異來自設計，不來自技術。商家若沒為「對話框內單手滑動」的使用情境優化介面，即使技術上嵌進 LINE 了，客戶感受與一般網頁差異不大。

一、LIFF 是什麼？為什麼 LINE 需要這個技術框架？

核心觀點： LIFF 是 LINE 平台提供的「網頁應用嵌入框架」，目的是讓網頁能在 LINE 對話框內直接顯示與運行，免去客戶跳出 LINE 開瀏覽器的動線斷層。它不是 LINE 的某個新功能，而是讓既有網頁應用「以 LINE 為入口」的標準介面層。

LIFF 全名 LINE Front-end Framework，是 LINE 平台從 2018 年起推出的網頁應用嵌入框架。它的角色不是另一個 LINE 功能，而是一層介面標準——讓商家原本就有的網頁應用（網站、預約頁、會員系統）經過設定之後，能在 LINE 對話框內直接顯示與運行。

會需要這樣一層框架，是因為 LINE 兩端各有一個摩擦點。

從消費端來看，摩擦在於客戶不想離開 LINE 去開瀏覽器。原本要點連結跳出 LINE、開瀏覽器、進入網站、操作完成的流程，透過 LIFF 被壓縮成在對話框內一站式完成。

從商家端來看，摩擦則是成本。商家原本就有官網或預約系統，如果為了在 LINE 內呈現而重新開發一套原生 app，代價太高。LIFF 的做法是讓既有網頁加上 LIFF SDK（一段 JavaScript 引用）與 LINE Login channel 設定就能沿用，不必重寫。

技術上，LIFF 有三個前提條件：第一，必須掛載在 LINE Login channel 下，所以商家需要先在 LINE Developers 後台建立一個 channel 並取得 channel ID。第二，網頁必須以 HTTPS 提供。第三，網頁載入 LIFF SDK 之後，啟動時可呼叫 liff.init() 取得對應的 LIFF context（包含 userId、displayName 等資訊）。

如果拿它跟「直接把網頁網址貼進 LINE 訊息」相比，差別在於 LIFF 啟動時可以取得 LINE userId、可以呼叫 LINE 原生功能（傳訊息、開好友選擇器、關閉視窗返回對話），而且結束後客戶能無痕回到對話框繼續對話。這三點就是兩者的本質區別。

二、客人在 LINE 對話框內，可以完成哪些網站操作？

核心觀點： LIFF 內可承擔多數「短行程、單一目的」的客戶操作——預約、會員查詢、訂單追蹤、菜單瀏覽、點數查看、活動報名；不適合放進 LIFF 的，是長表單填寫、需要列印或下載的內容、需要橫向比較多項目的深度瀏覽。

判斷一個操作適不適合放進 LIFF，最簡單的標準是看「行程長度」與「目的單一性」。因為 LIFF 是在對話框內顯示，物理空間有限，客戶通常也是邊聊邊操作，所以短行程、單一目的、結果可以口頭回報的場景最適合。

適合放進 LIFF 的場景：

• 預約服務：客戶選日期、選時段、確認、完成，整個流程通常 3-5 步內結束，結果可立即收到 LINE 推播通知。
• 查會員資料、套票餘額、點數紀錄：單一目的的查詢操作，客戶看完即可關閉，不需要長時間停留。
• 查訂單與歷史紀錄：性質類似會員查詢，重點在「快速看一眼」而不是深度操作。
• 瀏覽菜單、服務列表、作品集：適合卡片式 UI、單手滑動瀏覽，客戶可隨時切回對話與商家確認細節。
• 領取優惠券、活動報名：點擊即完成的操作，配合 LIFF 內的「一鍵分享給好友」，可以做出一般網頁做不到的傳播效果。
• 商家公告與即時訊息：商家發佈新訊息時，附上 LIFF 連結讓客戶直接進入詳細頁面。

不適合放進 LIFF 的場景：

• 長表單填寫：婚禮報名、合約簽署、保險投保等需要 10 個欄位以上的填寫，在對話框的有限空間內，體驗會明顯弱於一般網頁。
• 需要列印或下載的內容：發票列印、合約 PDF 下載、購買憑證列印，這些操作在 LIFF 內雖然可行，但體驗仍不如瀏覽器。
• 需要橫向比較多項目的電商瀏覽：像是逛 50 件商品做比較的場景，LIFF 的顯示空間會限制比較的效率。

換句話說，LIFF 不是「網站的縮小版」，而是把網站功能中最高頻、最簡單的那一部分搬到 LINE 對話框內。也因此，商家在規劃 LIFF 整合時，第一個要決定的其實不是技術，而是哪些客戶操作要進 LIFF、哪些保留在一般網頁。

三、LIFF 跟一般網頁差在哪？三個關鍵差異

核心觀點： LIFF 與一般網頁的差異集中在三個地方——身份識別來源、物理顯示空間、與 LINE 原生功能的互動能力。技術上是同一份 HTML，但這三點決定了 LIFF 體驗能不能比一般網頁更順。

對商家來說，理解 LIFF 與一般網頁的差異，是判斷「值不值得做 LIFF 整合」的基礎。兩者雖然都是網頁，但下面三個差異會在客戶體驗上產生明顯落差。

差異一：身份識別來源

一般網頁要識別客戶，需要客戶輸入帳號密碼，或透過 Google、Facebook 等第三方 OAuth 登入。流程上一定會出現一段「客戶要先做動作才能被認出來」的時間。

LIFF 則是在開啟瞬間就能透過 liff.getProfile() 取得 LINE userId、displayName 與頭像 URL。也就是說，客戶從 LINE 進入時，會員辨識可以無感完成，不需要輸入任何東西，網頁就知道這個人是誰。

對商家的意義是，預約頁、會員頁、優惠券頁都可以省去登入步驟，直接顯示「您好，王小美，這是您的會員資料」，登入這一段摩擦就不存在了。

差異二：物理顯示空間

一般網頁佔據整個瀏覽器 viewport，桌面版可以放寬版表格與多欄佈局，手機版也至少有完整的螢幕高度可用。

LIFF 則是在 LINE 對話框內以 modal 或 full size 顯示，同時受到對話框 UI 的影響——頂部有 LINE 的標題列、底部可能有對話輸入框，實際可用的顯示高度會比一般網頁少一截。

對商家的意義是，直接套用桌面版網頁設計通常會出問題：字級太小、按鈕間距太擠、複雜的下拉選單在小螢幕上難以操作。LIFF 的 UI 需要專為「對話框內單手滑動」重新調整。

差異三：與 LINE 原生功能的互動

一般網頁沒辦法主動觸發 LINE 內的動作，既不能讓客戶用一個按鈕把內容分享給 LINE 好友，也不能在客戶完成操作後自動關閉視窗返回對話。

LIFF 則透過 SDK 提供這些能力。例如 liff.shareTargetPicker() 可以開啟好友選擇器讓客戶分享內容；liff.sendMessages() 可以代客戶在當前對話發送訊息；liff.closeWindow() 則能在客戶完成操作後關閉 LIFF、回到對話。

對商家的意義是，可以設計出一般網頁做不到的互動：客戶在 LIFF 內領到優惠券，點一下就分享給 LINE 好友；客戶完成預約後 LIFF 自動關閉，商家的確認訊息隨即出現在對話裡。這些細節加起來，客戶感受到的會是「LINE 內的完整體驗」，而不是「跳出 LINE 操作然後再回來」。

四、商家設計 LIFF 體驗時，要考量什麼？

核心觀點： LIFF 整合的體驗差異來自設計、不來自技術。商家側若沒為「對話框內單手快速操作」優化介面，即使技術上嵌進 LINE 了，在客戶眼中與一般網頁無異。

LIFF 在技術上要做出來並不算難，多數架站平台或開發團隊都能完成 channel 設定、SDK 載入與頁面包裝。真正的落差發生在「能用」與「好用」之間，而這段落差幾乎都來自設計。下面四個考量，是商家在規劃 LIFF 整合時最常被忽略的部分。

考量一：UI 為「對話框內單手滑動」優化

LIFF 的使用情境是客戶單手拿著手機、在對話框內快速操作，介面設計要跟著這個情境調整：按鈕要比桌面版大、字級不要小於 16px、重要操作放在拇指可及的畫面下半部。相對地，複雜的下拉選單、hover 互動、需要精準點擊的小元素都應該避免。

實務上最常見的疏失，就是直接把桌面版網頁包成 LIFF。介面看起來確實「有 LIFF」，但客戶操作起來跟一般網頁沒兩樣，也就享受不到對話框內快速操作的便利。

考量二：流程要短

LIFF 場景的客戶多半是順手做一件事，而不是特地來辦完一整套任務。以預約來說，從點開到完成的理想步驟落在 3-5 步：選日期、選時段、確認、完成。一旦流程超過 5 步，客戶在對話框內的注意力很容易被打斷——朋友傳訊息、其他通知跳出來——完成率就會明顯下降。

如果原本的流程需要 10 步以上，建議拆開處理：核心步驟放 LIFF，進階設定留在一般網頁的會員後台。當然也可以直接判斷這個流程不適合 LIFF，改採「LINE 通知 + 一般網頁完成」的混合動線。

考量三：身份合併

LIFF 拿到 LINE userId 之後，還要與網站既有的會員身份對齊，否則兩邊會是各自獨立的資料。架站平台層面的會員資料合併已在另一篇 LINE 官方帳號該怎麼用 中討論過，這裡聚焦在拿到 userId 之後的實作層次。

具體做法是後台需要一張對應表，把 LINE userId 與會員 ID 綁定起來。客戶第一次從 LIFF 進入時，系統會請他留下 email 或手機號碼以建立綁定；之後不論從 LIFF 的哪個頁面進來，都能自動辨識為對應的會員。

少了這層綁定，LIFF 拿到的 userId 與網站會員資料就是兩套獨立系統，會員經營仍然會出現斷層。

考量四：fallback

LIFF 連結不會只在 LINE 內被點擊。客戶可能把連結轉發給朋友、貼到 Email、或加進瀏覽器書籤，所以在 LINE 之外的環境打開時，網頁必須能以一般網頁的形式正常呈現，不能直接報錯。

除此之外，舊版 LINE 或某些 webview 環境並不支援 LIFF SDK，網頁也要有降級處理：偵測到 LIFF 環境不可用時，自動切換為一般網頁模式，引導客戶完成操作，或提示客戶更新 LINE 版本。

對企業來說，fallback 不只是工程細節，更是品牌風險控制——客戶在任何環境點下連結，網頁都要能開，不該讓「LIFF 載入失敗」的錯誤頁出現在客戶面前。

延伸閱讀：

• AI 開始幫人預訂服務，你的網站準備好被它讀取了嗎
• LINE 官方帳號該怎麼用？把 LINE 變成你網站的對話入口
• 網站如何增加流量：多管道整合的企業官網設計哲學
• 線上預約系統完整指南
• 架站平台完整比較指南

AHHA 在這方面內建 LIFF 預約流程、LINE userId 與會員身份自動綁定，以及一般網頁 fallback 三個層次，可以當作「為對話框內單手操作優化」的實作參考。

立即試用 AHHA 30 天 →