核心觀念

本題考查 Google Analytics（GA）的資料蒐集與流量分析機制，重點包括：

1. GA 如何蒐集網站訪客資料。
2. 網站伺服器如何取得 IP address。
3. GA 如何利用 Cookie 判斷新訪客與回訪訪客。
4. 不同公司之間的廣告平台，如何透過網址參數與來源資訊進行成效追蹤。

以下以命題當年（民國 110 年）常見的 Universal Analytics（UA）運作方式說明。

---

解題方法

回答本題可依照「資料產生 → 資料傳送 → GA 分析」的順序說明：

1. 使用者進入網站。
2. 網站內嵌的 GA JavaScript 追蹤碼執行。
3. 追蹤碼讀取瀏覽器資訊、Cookie、目前網址及來源網址。
4. 追蹤資料傳送至 Google Analytics 伺服器。
5. GA 將資料整理為使用者、工作階段、頁面瀏覽、來源媒介等報表。

因此，GA 所稱的「流量」並非直接知道整個網路有多少人，而是透過網站上的追蹤碼，蒐集實際造訪該網站的瀏覽行為，再加以統計分析。

---

（一）Google Analytics 的主要運作原理，以及為什麼可以知道網路流量【10 分】

1. 網站嵌入追蹤碼

網站管理者會在網頁中加入 Google Analytics 提供的 JavaScript 追蹤碼。當使用者開啟網頁時，瀏覽器會執行此段程式，產生與此次瀏覽有關的資料。

常見蒐集資料包括：

• 瀏覽頁面與頁面標題。
• 造訪時間。
• 瀏覽器、作業系統及裝置類型。
• 螢幕解析度。
• 使用者所在國家或地區。
• 來源網站、搜尋引擎及廣告活動。
• Cookie 中的識別資訊。
• 事件、轉換及交易資料。

2. 將資料傳送至 GA 伺服器

追蹤碼會將資料包裝成請求，傳送至 Google Analytics 的資料蒐集伺服器。這些請求可透過圖片請求、HTTP 請求等方式完成，傳送內容包含追蹤 ID、頁面網址、來源資訊、瀏覽器資訊及識別資料。

3. GA 進行整理與分析

Google Analytics 收到資料後，會依使用者、工作階段、頁面及事件等維度進行整理，形成報表，例如：

• 使用者數。
• 新使用者數。
• 工作階段數。
• 工作階段來源與媒介。
• 頁面瀏覽量。
• 跳出率。
• 平均工作階段時間。
• 目標完成數及電子商務交易數。

4. GA 為何可以知道網站流量

只要網站頁面安裝 GA 追蹤碼，使用者瀏覽頁面時，追蹤碼便會將瀏覽行為回傳給 GA。GA 將所有回傳資料加以累計，即可計算網站流量。

例如，若某一日有 1,000 次頁面瀏覽請求傳送至 GA，GA 便可依其識別規則統計頁面瀏覽量、工作階段數及使用者數。

應注意：

• 「使用者數」不等於現實世界中的實際人數。
• 同一人使用不同瀏覽器、裝置，可能被計為不同使用者。
• 使用者刪除 Cookie、封鎖追蹤碼、停用 JavaScript，可能造成資料遺失。
• GA 是對已安裝追蹤碼網站的訪問進行測量，不是測量整個網際網路的總流量。

---

（二）GA 如何得知瀏覽者的 IP address，以及判斷初次到訪或再次到訪【10 分】

1. IP address 的取得方式

使用者瀏覽網站時，瀏覽器必須向網站伺服器提出 HTTP 或 HTTPS 請求。網路封包傳送過程中，伺服器可由連線資訊取得請求來源的 IP address。

基本流程如下：

$$\text{瀏覽器請求網頁} \rightarrow \text{網站伺服器接收請求} \rightarrow \text{取得來源 IP} \rightarrow \text{追蹤資料傳送至 GA}$$

在傳統 UA 架構下，GA 追蹤請求本身也會經過網路傳送至 Google 的資料蒐集伺服器，因此系統可由網路連線資訊取得 IP，並利用 IP 推估使用者的地理位置，例如國家、地區或城市。

不過，IP address 只能作為網路連線識別資訊，不能直接等同於特定自然人的身分。公司、學校、公共 Wi-Fi 或行動網路常有多位使用者共用同一個對外 IP。

2. IP 與隱私處理

Google Analytics 可對 IP 進行匿名化或截短處理，使完整 IP 不直接保存於分析資料中。即使如此，GA 仍可依其他資訊進行地理區域推估及流量統計。

因此，答題時應區分：

• IP 的取得：來自瀏覽器與伺服器間的網路連線資訊。
• IP 的用途：推估地理位置、協助分析來源及流量。
• IP 的限制：不能單獨精確識別實際使用者。
• IP 的隱私處理：可透過 IP 匿名化降低個人識別風險。

3. 判斷初次到訪或再次到訪

GA 主要透過瀏覽器 Cookie 判斷訪客是否曾經到訪。

第一次造訪網站時，GA 會在使用者瀏覽器中建立識別 Cookie，並產生一組 Client ID。其概念可表示為：

$$\text{瀏覽器} \rightarrow \text{建立 Cookie} \rightarrow \text{產生 Client ID}$$

之後使用者再次以相同瀏覽器、相同 Cookie 狀態造訪網站時，GA 會讀取原有的 Client ID，判定為回訪訪客。

判斷邏輯可簡化如下：

• 找不到原有 GA Cookie：視為新訪客。
• 找得到原有 GA Cookie：視為回訪訪客。

核心觀念

本題分為兩部分：

1. 說明電子商務零售網站的常見付款方式。
2. 區分「行動支付、第三方支付、電子票證、電子支付帳戶」的法律性質、使用方式與服務範圍。

涉及法規部分，以命題當年（民國 110 年）法規為準。電子支付機構相關規定主要依《電子支付機構管理條例》判斷；電子票證則主要涉及《電子票證發行管理條例》。現行法已修正，實際作答仍應依命題年度規定說明。

---

解題方法

本題可採「先列舉、再分類、後比較」的方式作答：

• 第一小題先從付款工具與付款管道列出常見方式。
• 第二小題針對四個名詞，分別說明：

1. 定義與核心功能；
2. 資金是否經過中介保管或移轉；
3. 使用載具；
4. 法規定位；
5. 代表性例子。

• 最後以比較方式指出四者並非同一層次：
• 行動支付偏重「使用手機付款的方式」；
• 第三方支付偏重「交易款項由中介業者代收代付的商業模式」；
• 電子票證偏重「可儲值、可扣款的支付工具」；
• 電子支付帳戶偏重「依法開立的帳戶及其支付機制」。

---

（一）電子商務零售網站常見的付款方式

1. 貨到付款

消費者下單後，由物流業者將商品送達，再由消費者支付貨款。付款方式包括現金、刷卡或行動付款。

優點是消費者不必事先提供付款資料，容易建立信任；缺點是物流業者需處理代收款，商家也會承擔拒收、退貨及現金管理成本。

2. 信用卡付款

消費者於網站輸入信用卡卡號、有效期限及安全碼，經發卡銀行、收單銀行與信用卡組織授權後完成交易。

信用卡付款通常具有即時授權、交易便利及分期付款等特點。網站必須重視信用卡資料加密、身分驗證及防止盜刷。

常見形式包括：

• 一次付清；
• 分期付款；
• 定期定額扣款；
• 透過第三方金流服務處理信用卡交易。

3. 金融卡、簽帳金融卡或網路銀行付款

消費者使用金融卡、簽帳金融卡或網路銀行帳戶完成付款。部分服務會透過網路銀行轉帳、晶片金融卡或銀行授權機制扣款。

此類方式通常直接連結消費者的銀行存款帳戶，商家須與銀行或金流服務商串接。

4. ATM 轉帳或銀行轉帳

網站產生虛擬帳號，消費者利用 ATM、網路銀行或行動銀行將款項轉入該帳號。

優點是使用普遍、交易成本相對低；缺點是消費者必須自行完成轉帳，且轉帳後可能需要等待系統確認，付款流程較不即時。

5. 超商代收或超商繳費

消費者下單後取得繳費代碼，再至便利商店櫃檯或多媒體資訊機付款。

此方式適合沒有信用卡、銀行帳戶，或偏好使用現金的消費者。缺點是付款與訂單成立之間可能存在時間差。

6. 電子錢包、電子支付帳戶及行動支付

消費者先將資金儲值於電子錢包或電子支付帳戶，交易時以帳戶餘額扣款；也可以透過手機 App 綁定信用卡、金融卡或銀行帳戶付款。

此類方式具有付款速度快、使用便利及適合小額高頻交易等特色。

7. 電子票證付款

消費者使用具有儲值及扣款功能的電子票證，例如悠遊卡、一卡通等，於支援該票證的網站、平台或相關服務完成付款。

電子票證通常具有實體卡片、虛擬卡片或其他可感應載具。

8. 第三方支付

消費者先將款項交由第三方支付業者代收，業者於交易條件成立後，再將款項撥付給商家。

此方式可降低消費者直接將付款資料交給個別商家的疑慮，也能提供付款、退款、對帳及交易爭議處理等服務。

---

（二）四種付款名詞的差異與例子

1. 行動支付

定義

行動支付是指利用手機、平板等行動裝置，透過 App、NFC、QR Code、條碼或網路連線完成付款的方式。

它的重點在於「使用什麼載具及操作介面付款」，不一定代表背後使用哪一種資金來源。

可能使用的付款來源

行動支付可以連結：

• 信用卡；
• 簽帳金融卡；
• 銀行帳戶；
• 電子支付帳戶；
• 電子票證餘額；
• 預付儲值金。

因此，行動支付是一種較上位的付款使用方式，與電子支付帳戶、電子票證並非互斥關係。

例子

消費者使用手機開啟行動支付 App，掃描商店 QR Code，再以綁定的信用卡付款，這是行動支付；若以手機中的電子支付帳戶餘額扣款，也同時涉及電子支付帳戶。

判斷重點

行動支付回答的是：

「消費者透過什麼裝置及介面付款？」

它不必然回答：

「款項由哪一種法律性質的帳戶或工具支付？」

---

2. 第三方支付

定義

第三方支付是由商家與消費者以外的獨立業者，提供交易款項代收、保管、代付或相關金流服務。

基本流程如下：

$$消費者付款 \rightarrow 第三方支付業者代收款項 \rightarrow 業者撥款給商家$$

第三方支付業者通常還會提供付款通知、退款、交易紀錄、對帳及爭議處理等功能。

核心功能

第三方支付的核心在於「交易款項由第三方中介處理」，藉以降低買賣雙方的不信任及金流處理成本。

例如，消費者付款後，平台先暫時保管款項，待商家出貨或交易條件完成後，再將款項撥給商家。

法律定位

「第三方支付」主要是商業模式及服務概念，並非當然等同於《電子支付機構管理條例》中的電子支付帳戶。

若業者從事收受儲值款項、電子支付帳戶間款項移轉或代理收付實質交易款項等業務，且符合電子支付機構的法律要件，便須依相關規定取得許可並接受監管。

例子

核心觀念

本題考查電子商務履約流程中的三項瓶頸：

1. 庫存準確性：訂單系統（Order Management System, OMS）與庫存系統、倉儲系統（Warehouse Management System, WMS）是否即時同步，避免超賣。
2. 倉儲處理能力：接單量是否受到每日揀貨、包裝與出貨能力限制，避免訂單量超過倉儲產能。
3. 物流協同能力：電商資訊系統與物流業者資訊系統是否能即時交換訂單、包裹、配送量能與異常狀態。

完整流程可表示為：

$$\text{下單} \rightarrow \text{庫存保留} \rightarrow \text{揀貨} \rightarrow \text{包裝出貨} \rightarrow \text{物流配送}$$

其中任一階段的資訊不正確或處理能力不足，都會造成交貨延誤。

本題為申論題，沒有選項，因此無選項逐一分析問題。題目未涉及特定法條，以下以電子商務、OMS、WMS及物流資訊整合的標準管理觀念作答。

---

（一）庫存不足：訂單系統與庫存系統的問題及改善【10分】

1. 問題一：庫存資料未即時同步

電商前台顯示的庫存數量，若未與實體倉庫的庫存即時同步，就會產生「網站有貨、倉庫無貨」的情況。例如：

• 商品已被其他通路售出，但電商網站尚未扣除庫存。
• 訂單成立後，庫存系統未即時扣減。
• 退貨、報損、盤點差異未即時更新。
• 同一商品同時在官網、平台、門市及批發通路銷售，但各通路各自管理庫存。

因此，網站依照過時的庫存數量接單，倉庫實際執行時才發現缺貨。

2. 問題二：未設定庫存保留機制

顧客將商品放入購物車，不代表訂單已成立；訂單成立，也不代表付款已完成。若系統沒有清楚區分：

• 可用庫存（Available Stock）
• 已保留庫存（Reserved Stock）
• 已售出但尚未出貨庫存
• 瑕疵、報損或待盤點庫存
• 安全庫存（Safety Stock）

就會將同一批商品重複提供給多筆訂單。

可用庫存可表示為：

$$\text{可售庫存} = \text{實體庫存} - \text{已保留庫存} - \text{不可用庫存} - \text{安全庫存}$$

若系統只以實體庫存扣除已出貨數量，而沒有扣除已成立但尚未出貨的訂單，就會產生超賣。

3. 問題三：訂單成立與庫存扣減的交易不同步

訂單建立、付款確認及庫存扣減若分屬不同系統，且缺乏一致性控制，會發生下列情況：

• 兩位顧客同時購買最後一件商品，兩筆訂單都讀到「尚有一件」。
• 訂單已成立，但庫存扣減訊息傳送失敗。
• 付款成功，但庫存保留失敗。
• 庫存扣減成功，但訂單建立失敗，形成庫存遺失。

這屬於系統交易一致性及併發控制問題。

4. 改善方法

（1）建立單一庫存來源

所有銷售通路應集中連接同一套庫存主檔或庫存管理平台，由系統統一管理商品編號、倉別、數量及庫存狀態，避免每個通路各自維護庫存。

（2）採用即時庫存同步

訂單成立、取消、退貨、調撥、報損及出貨時，應透過 API、訊息佇列或其他整合機制，即時更新 OMS、ERP、WMS及電商前台。

若無法做到完全即時，也應設定短時間同步週期，並對高需求商品採用更嚴格的即時同步機制。

（3）下單時立即保留庫存

訂單進入成立或付款確認狀態時，系統應立即執行庫存保留：

$$\text{實體庫存} \rightarrow \text{已保留庫存}$$

付款失敗、逾時未付款或訂單取消時，系統再自動釋放保留量，避免庫存長期被占用。

（4）使用原子交易與併發控制

庫存檢查與庫存扣減應在同一個不可分割的交易中完成，並使用資料庫鎖定、版本號或條件更新，確保最後一件商品只會被一筆有效訂單取得。

基本邏輯可表示為：

$$\text{若可售庫存} \geq \text{訂購數量} \Rightarrow \text{建立訂單並保留庫存}$$ $$\text{若可售庫存} < \text{訂購數量} \Rightarrow \text{拒絕接單或顯示缺貨}$$

（5）建立庫存稽核與對帳機制

每日或定期比對：

• 電商訂單數量
• OMS保留數量
• WMS實際庫存
• ERP帳面庫存
• 物流已出貨數量
• 退貨及取消數量

若發生差異，系統應產生異常報表，並立即調整前台可售庫存。

（6）設定安全庫存與超賣控制

對於需求波動大、補貨時間長或疫情期間供應不穩定的商品，應保留安全庫存：

$$\text{可售庫存} = \text{實體庫存} - \text{保留庫存} - \text{安全庫存}$$

當可售庫存低於安全庫存時，系統自動停止接單、限制每位顧客購買數量，或改為預購模式。

5. 解題技巧

本小題的判斷重點是「網站顯示有貨」與「倉庫實際有貨」之間的落差。作答時應依序寫出：

資料不同步 → 未保留庫存 → 交易不一致 → 超賣 → 即時同步及庫存保留改善。

只寫「增加庫存」並不能解決系統超賣問題，因為題目重點在訂單系統與庫存系統的資訊及流程控制。

---

（二）揀貨不及：訂單系統、派工與揀貨能力的問題及改善【10分】

1. 問題一：訂單系統只依需求接單，未檢查倉儲產能

許多系統只判斷「是否有庫存」，卻未判斷「倉庫是否有能力在承諾時間內完成揀貨與出貨」。

因此，即使庫存充足，若短時間內訂單大量增加，倉儲仍會因人力、設備、走道及包裝能力不足而延遲出貨。

這是「庫存容量」與「履約處理容量」未分開管理的問題。

2. 問題二：未計算每日可揀貨訂單數

每日可揀貨數量不能直接以員工人數判斷，必須考慮工作時間、實際生產力及有效工作比例。

若：

• $W$：揀貨人員數
• $H$：每日可工作小時
• $E$：有效工作比例
• $P$：每人每小時可完成的訂單數
• $R$：每日既有待處理訂單數
• $S$：安全緩衝量

則每日揀貨能力為：

$$C_{\text{pick}}=W \times H \times E \times P$$

當日可接受的新訂單量約為：

$$C_{\text{new}} = C_{\text{pick}}-R-S$$

若當日新訂單量 $D$ 滿足：

$$D > C_{\text{new}}$$

就會形成揀貨積壓，延後的訂單會累積到隔日，造成延遲持續擴大。

例如，倉庫有 $20$ 名揀貨人員，每人每日有效工作 $7$ 小時，每人每小時平均揀貨 $12$ 張訂單，則：

$$C_{\text{pick}}=20 \times 7 \times 12=1,680$$

若已有 $300$ 張未完成訂單，並保留 $80$ 張安全緩衝量，當日實際可再承接的訂單數為：

$$C_{\text{new}}=1,680-300-80=1,300$$

超過 $1,300$ 張的新增訂單，就不能承諾一般出貨時效。

3. 問題三：派工未依訂單優先順序與截止時間安排

倉儲人員若只按照訂單進入順序逐筆處理，會造成揀貨路線重複、等待時間增加及急件延誤。

常見缺失包括：

一、核心觀念

本題主要考查三個觀念：

1. 社群商務的定義與常見活動類型。
2. Web 1.0 與 Web 2.0 的本質差異。
3. Facebook 網路代購與傳統電子商務網站在交易模式、互動方式及資訊呈現上的差異。

社群商務不是單純「利用網路賣東西」，而是將社群互動、使用者分享、口碑推薦、社交關係與電子交易結合，使消費者在社群環境中完成商品認知、評估、購買及分享等活動。

---

二、解題方法

本題採「定義—分類—比較」的方式作答：

• 第（一）題先界定社群商務，再列舉具體活動。
• 第（二）題從「資訊控制權」及「使用者參與程度」比較 Web 1.0 與 Web 2.0。
• 第（三）題以交易流程、互動關係、信任來源、網站功能及交易風險作比較。

作答時不能只寫「Web 2.0 比較新、Web 1.0 比較舊」，必須指出兩者在內容產製、互動性及社群參與上的結構性差異。

---

（一）社群商務活動及其範圍【10 分】

1. 社群商務的定義

社群商務是指利用社群媒體、社群網路及使用者互動機制，進行商品或服務之資訊交換、推薦、行銷、交易及售後活動的電子商務形式。

其核心特色包括：

• 社群互動：消費者可留言、討論、分享及回覆。
• 使用者參與：商品資訊不只由商家提供，也由使用者共同產製。
• 社交關係影響交易：朋友、社團成員、網紅及其他使用者的推薦會影響購買決策。
• 口碑與信任機制：評價、按讚、分享、推薦及使用心得形成交易信任。
• 交易與社群活動結合：消費者可能在瀏覽、聊天、參與社團活動的過程中完成交易。

因此，社群商務可視為「社群媒體功能」與「電子商務交易流程」的結合。

2. 算是社群商務的活動

（1）社群口碑行銷

商家透過 Facebook、Instagram、LINE 社群、討論區等平台發布商品資訊，並鼓勵消費者留言、分享或標註朋友。

例如：

• 商品開箱文。
• 使用心得分享。
• 消費者評價。
• 按讚、留言及分享活動。
• 朋友推薦商品。

這些活動雖不一定立即產生交易，但會影響商品曝光率、品牌形象及消費者購買意願，屬於社群商務的重要環節。

（2）社群團購與揪團購物

消費者透過社團、聊天室或群組共同購買商品，利用大量訂購取得較低價格。

例如：

• Facebook 團購社團。
• LINE 群組團購。
• 社群揪團購買餐券、食品或生活用品。
• 透過群組達到批量採購門檻。

其特徵是購買行為受到群體互動及成員號召影響。

（3）社群推薦與導購

社群成員、網紅、部落客或意見領袖在社群平台推薦商品，並透過商品連結、專屬折扣碼或聯盟行銷導引消費者購買。

此類活動的交易影響力來自推薦者與追蹤者之間的信任關係，而非單純依賴傳統廣告。

（4）社群購物與社交購物

平台將商品展示、留言討論、好友互動及購買功能整合在同一環境中，使消費者能邊社交、邊瀏覽商品、邊完成交易。

例如：

• 在社群貼文中直接標記商品。
• 直播展示商品並接受訂單。
• 消費者在留言區詢問規格、價格及使用方式。
• 在社群平台中直接導向購物頁面付款。

（5）網路代購與社群型賣場

代購者透過 Facebook 粉絲頁、社團、Instagram 帳號或 LINE 群組，發布海外商品、限量商品及預購商品資訊，並透過留言、私訊或表單收集訂單。

此類交易通常以社群關係、個人信用及即時互動作為主要信任來源。

（6）使用者共同創造內容

消費者自行產生商品評論、照片、影片、教學文章及使用經驗，形成使用者產製內容（User Generated Content, UGC）。

UGC 可協助其他消費者：

• 判斷商品品質。
• 比較不同品牌。
• 了解實際使用情形。
• 降低購買前的不確定性。

（7）社群集體議價及群眾協作

消費者透過社群力量共同向商家爭取折扣、客製化商品或服務條件，也可能參與商品設計、品牌活動及產品改良。

例如：

• 消費者集體議價。
• 共同票選商品款式。
• 參與新產品測試。
• 透過群眾意見協助商家改善服務。

3. 判斷標準

判斷一項活動是否屬於社群商務，可掌握以下原則：

若活動同時具有「社群互動或社交關係」及「商品、服務或交易目的」，通常即可歸入社群商務範圍。

單純在網站上放置商品目錄，只有展示功能而沒有社群互動，較接近傳統電子商務；若加入評論、分享、推薦、討論、直播或社團交易等功能，則具有社群商務特徵。

【答案】

社群商務是利用社群媒體及社群關係，結合使用者互動、資訊分享、口碑推薦與商品交易的電子商務活動。其範圍包括社群口碑行銷、商品評論與評價、朋友推薦、網紅導購、社群團購、揪團購物、直播購物、網路代購、社群賣場、集體議價、使用者共同創造內容，以及消費者參與商品設計或服務改善等活動。其核心在於社群互動及人際信任會直接或間接影響交易。

---

（二）Web 2.0 與 Web 1.0 的主要差別【10 分】

1. Web 1.0 的特性

Web 1.0 是早期網路的主要型態，內容多由網站經營者或專業出版者製作，使用者主要負責瀏覽及接收資訊。

其特徵包括：

• 內容由網站管理者單向發布。
• 網頁多為靜態內容。
• 使用者互動程度較低。
• 使用者通常是資訊接受者。
• 網站功能以資訊展示、搜尋及下載為主。
• 商業模式接近傳統媒體及電子型錄。

因此，Web 1.0 可概括為「以網站提供者為中心」及「以閱讀資訊為主」的網路型態。

2. Web 2.0 的特性

Web 2.0 並非單純指某一個軟體版本，而是代表一種強調互動、參與、分享及協作的網路使用模式。

其特徵包括：

• 使用者可自行建立及發布內容。
• 使用者可留言、評分、分享及回覆。
• 網站內容具有即時更新及動態互動性。
• 使用者同時是資訊接受者及內容生產者。
• 社群關係及網路效應更加重要。
• 平台會利用大量使用者參與改善內容及服務。
• 常見應用包括社群網站、部落格、Wiki、影音分享平台及社群購物平台。

Web 2.0 的重要概念是使用者產製內容（UGC）、群眾智慧、社群互動及平台協作。

3. 兩者的主要差別

比較項目	Web 1.0	Web 2.0
資訊流向	單向傳播	雙向或多向互動
內容來源	網站業者或專業出版者	業者與一般使用者共同產製
使用者角色	資訊接收者	使用者、參與者及內容生產者
網頁型態	靜態、固定	動態、即時更新