111 年 國立政治大學資訊管理學系碩士班資管組《管理資訊系統》

這組題目主要探討社群媒體平台（以 Meta 為例）在數據應用、資訊傳播、新興科技（元宇宙）及市場競爭等管理資訊系統（MIS）相關議題。

核心觀念：數據分析與使用者體驗、資訊傳播的演算法責任、元宇宙的商業應用與挑戰、企業策略與市場預測。

(a) 社群媒體平台監控使用者個人資訊與使用資訊以改善使用者體驗，從 MIS 的角度來看，這主要涉及數據採集 (Data Collection)、數據分析 (Data Analytics)、個人化推薦 (Personalization) 以及使用者體驗設計 (User Experience Design)。

• 數據採集：平台會收集使用者的點擊、瀏覽、停留時間、按讚、分享、評論、搜尋紀錄、地理位置、裝置資訊等。這些資訊能描繪出使用者的行為模式、興趣偏好、社交網絡等。
• 數據分析：透過大數據分析、機器學習等技術，平台可以從海量數據中挖掘出有價值的洞察，例如哪些內容最受歡迎、用戶在使用流程中遇到哪些瓶頸、哪些功能使用率低等。
• 個人化推薦：基於數據分析結果，平台能夠為每位使用者提供個人化的內容推薦（如新聞、影片、廣告）、好友建議、產品推薦等，以提高使用者的參與度和黏著度。
• 使用者體驗設計：分析使用者行為數據，可以幫助平台識別使用者介面 (UI) 或使用者流程 (UX) 中的痛點，進而優化設計，使平台更易用、更直觀，從而提升整體使用者體驗。

然而，這也伴隨著隱私權 (Privacy) 和數據安全 (Data Security) 的挑戰，平台必須在利用數據改善體驗與保護用戶隱私之間取得平衡。

【答案】是，社群媒體平台可以透過監控使用者個人資訊與使用資訊來改善使用者體驗。從 MIS 角度，這涉及數據採集、數據分析、個人化推薦及使用者體驗設計。平台透過收集使用者的行為數據（點擊、瀏覽、互動等），並運用數據分析技術，能深入了解使用者偏好與行為模式，進而提供個人化的內容與服務，優化使用者介面與流程，提升整體使用體驗。但需注意平衡數據利用與用戶隱私保護。

(b) 探討社群媒體是否應使用自身標準或演算法來控制錯誤資訊的傳播，並運用社會技術系統觀點 (Sociotechnical Approach)。

社會技術系統觀點認為，一個系統的設計與運作，是技術（如演算法）與社會（如使用者、組織、規範、文化）相互影響、相互塑造的結果。

• 技術層面：社群媒體可以開發或調整演算法，以偵測、標記、降低或移除明顯的錯誤資訊。例如，透過自然語言處理 (NLP) 技術識別虛假新聞的模式、利用人工智慧辨識可疑帳號或連結、限制內容的擴散範圍。
• 社會層面：
  • 使用者：使用者本身是資訊的生產者、傳播者和消費者。演算法的介入可能影響使用者的資訊獲取自由，引發「過濾氣泡」(Filter Bubble) 或「回聲室效應」(Echo Chamber) 的擔憂。使用者也可能因演算法的不當介入而感到被審查。
  • 組織（社群媒體公司）：公司在決定演算法的規則時，面臨商業利益（吸引更多用戶、增加廣告收入）與社會責任（防止錯誤資訊危害）的衝突。誰來定義「錯誤資訊」？標準是否公平？如何確保演算法不會帶有偏見？
  • 規範與文化：社會對於言論自由、資訊真實性的界線、平台的角色定位等，存在不同的價值觀和期待。演算法的控制機制需要考量這些社會規範和文化背景。

我的觀點：社群媒體確實有責任採取措施來減緩錯誤資訊的傳播，以保護公眾利益。然而，完全依賴單一的「自身標準或演算法」來進行控制，存在高度風險，可能導致過度審查、偏見擴散或技術濫用。更理想的做法是：

1. 透明度：公開演算法如何運作、判斷錯誤資訊的標準和流程。
2. 多方協作：與獨立的事實查核機構、學術界、政府及使用者社群合作，共同建立判斷機制。
3. 使用者賦權：提供使用者檢舉、標記錯誤資訊的功能，並讓使用者有更多控制自己看到的內容的權力。
4. 教育：加強使用者的媒體素養和批判性思維能力，使其能自行辨別資訊真偽。

社會技術系統觀點強調，技術的解決方案必須與社會結構、組織行為和使用者互動緊密結合，才能有效且負責任地應對錯誤資訊的挑戰。

【答案】從社會技術系統觀點來看，社群媒體應審慎使用自身標準或演算法控制錯誤資訊。技術層面可透過 AI 偵測，但社會層面涉及使用者（自由、偏見）、組織（商業利益、責任）及社會規範（言論自由、公平性）。完全依賴演算法風險高，建議採透明化、多方協作、使用者賦權及媒體素養教育等綜合策略。

(c) 元宇宙 (Metaverse) 的商業影響、潛在問題與支付方式：

這組題目主要探討餐飲業（以 MOS Burger 為例）的數位轉型策略，包含外包與自建的優劣分析、數位服務的未來發展，以及 CRM 系統在 O2O 行銷中的應用與夥伴關係的轉變。

核心觀念：資訊外包與自建的決策、數位策略規劃、客戶關係管理 (CRM) 系統、數據分析與 O2O 行銷、供應鏈夥伴關係管理。

(a) MOS Burger 在台灣的數位策略，從現行外包模式轉向未來成立新公司自建數位服務，其優缺點分析與建議。

現行外包模式：

• 優點 (Pros)：
  • 降低初期投資與營運成本：無需投入大量資金建置基礎設施、聘僱專業團隊，也減少固定人事成本。
  • 彈性與敏捷性：可快速調整服務規模，依賴外部專業公司快速導入新技術或服務。
  • 專注核心業務：公司可將資源與精力集中在餐飲本業的產品開發、營運管理上。
  • 獲取外部專業知識：利用外包夥伴在特定領域（如 App 開發、社群媒體管理）的專業能力。
• 缺點 (Cons)：
  • 控制權與客製化程度較低：對服務內容、品質、開發時程的掌握度較弱，客製化需求可能難以完全滿足。
  • 潛在的資訊安全風險：將數據與系統交由第三方處理，可能存在數據洩露或濫用的風險。
  • 溝通與協調成本：需花費時間與精力管理外包夥伴，協調不同團隊的合作。
  • 長期成本可能較高：若服務需求穩定且長期，外包總成本可能高於自建。
  • 依賴性：對外包夥伴的依賴性高，若夥伴服務中斷或變動，影響較大。

未來自建服務模式（成立新公司）：

• 優點 (Pros)：
  • 完全控制權與高度客製化：能完全掌控數位服務的發展方向、功能設計、品質標準，滿足獨特業務需求。
  • 數據安全與隱私保護：數據掌握在自己手中，有助於提升資訊安全與用戶隱私保護。
  • 整合性與協同效應：能將數位服務與核心業務更緊密地整合，創造更大的協同效應。
  • 長期成本效益：若規模擴大且營運穩定，長期來看可能比外包更具成本效益。
  • 建立核心競爭力：將數位能力內化為企業的核心競爭力，掌握未來發展主導權。
• 缺點 (Cons)：
  • 高昂的初期投資：需投入大量資金建置團隊、技術平台、基礎設施。
  • 人才招募與管理挑戰：需要招募、培訓和留住具備數位專業技能的人才，管理難度增加。
  • 營運風險：自建團隊可能面臨技術瓶頸、專案延遲、市場變化等營運風險。
  • 市場反應速度：相較於外包的彈性，自建團隊在快速市場變化下，反應速度可能較慢。
  • 可能分散對核心業務的注意力：過度專注於數位服務的建置與營運，可能影響餐飲本業。

給 MOS Burger 的建議：

1. 階段性推進：不必一步到位。可以先從關鍵的數位功能（如會員系統、較複雜的點餐流程優化）開始自建，逐步將核心的數位能力內化，同時維持部分非核心的數位服務（如基礎的社群媒體發布）外包，降低初期風險。
2. 策略性外包與合作：成立新公司不代表完全放棄與外部夥伴的合作。可以尋找能提供更深入、更具策略性合作的夥伴，例如共同開發特定創新技術，或在特定市場進行合作。
3. 數據驅動決策：無論是自建或外包，都應以數據為核心。建立強大的數據分析能力，持續監控用戶行為、市場趨勢，並據此調整數位策略。
4. 人才發展：重視數位人才的培養與留任，建立良好的企業文化和激勵機制。
5. 關注 OMO (Online-Merge-Offline)：MOS Burger 已有 O2O 基礎，未來應更強化線上線下融合，提供無縫的消費體驗，例如線上預訂、線下體驗升級，或線下掃碼獲取線上優惠等。
6. 創新應用：可探索更多數位創新，例如利用 AI 提供個人化餐點推薦、導入智慧點餐系統、優化外送路線規劃、甚至是結合 AR/VR 的新式用餐體驗。

【答案】現行外包優點為成本低、彈性高；缺點為控制弱、風險高。未來自建優點為控制強、客製化高；缺點為投資高、風險大。建議 MOS Burger 階段性推進自建，策略性外包，並以數據驅動決策、重視人才發展，強化 OMO 體驗與創新應用。

(b) MOS Burger 夥伴公司利用 CRM 系統進行 O2O 行銷，以及未來變革下的解決方案。

現行合作模式說明：
MOS Burger 的長期外包夥伴，透過「營運型 CRM (Operational CRM)」與「分析型 CRM (Analytical CRM)」系統，結合「資料探勘 (Data Mining)」

這組題目涵蓋了 Dcard 的多元化策略、電子商務的數據分析（SQL 查詢）、軟體開發流程與工程文化，以及國際化網站的搜尋引擎優化 (SEO)。

核心觀念：企業多元化策略、永續發展目標、SQL 查詢（進階）、軟體開發流程、工程師文化、國際化 SEO。

(a) Dcard 採納多元化策略的原因，以及 Dcard Video 團隊與「好物研究室」如何達成永續目標。

Dcard 採納多元化策略的原因：

1. 降低對單一業務的依賴 (Risk Diversification)：Dcard 最初以論壇形式的社群平台起家，若僅依賴此單一業務，容易受市場變化、競爭加劇或用戶習慣改變的影響。透過拓展影音內容（Dcard Video）和電子商務（好物研究室），可以分散營運風險。
2. 開拓新的營收來源 (Revenue Streams)：論壇廣告收入可能有限，而影音內容可透過廣告、業配、品牌合作等方式獲利；電子商務則直接透過商品銷售獲利。多元化有助於提升整體營收與獲利能力。
3. 擴大用戶接觸點與用戶價值 (Customer Touchpoints & Value)：
   • Dcard Video：吸引不喜歡閱讀長篇文章的用戶，或提供更生動的內容，增加用戶在 Dcard 生態系統內的停留時間與互動。
   • 好物研究室：將社群平台的用戶流量轉化為電商購買力，滿足用戶在平台內一站式購物的需求，提升用戶的整體價值。
4. 強化品牌形象與市場領導地位：從單純的論壇轉型為一個更全面的內容與服務平台，有助於鞏固其在台灣年輕族群中的影響力，並展現其創新與成長的企圖心。
5. 實現「與所有人產生共鳴」(To strike a chord with everyone) 的永續目標：多元化的內容和服務，能觸及更廣泛的用戶群體，滿足不同用戶的需求和興趣，從而實現更廣泛的連結與影響力。

Dcard Video 團隊與「好物研究室」如何達成永續目標：

• Dcard Video 團隊：
  • 內容創新與品質提升：持續產出符合目標受眾（年輕族群）興趣、高品質、具原創性的影音內容，例如結合時下話題、生活風格、知識分享等，吸引並留住觀眾。
  • 社群互動與粉絲經營：積極與觀眾互動（回覆留言、舉辦線上活動），建立忠誠的粉絲社群，增強用戶黏著度。
  • 跨平台整合：將 YouTube 影音內容與 Dcard 平台本身進行導流與整合，例如在影片中提及相關討論串，或在 Dcard 貼文中嵌入影片，形成內容生態循環。
  • 變現模式多元化：除了 YouTube 廣告，積極開發品牌業配、內容授權、與電商平台聯動等商業模式，確保營收穩定。
• 「好物研究室」(Good Choice Taiwan)：
  • 精選商品與品質保證：嚴格挑選符合 Dcard 用戶品味和需求的商品，強調商品品質與獨特性，建立用戶對平台的信任。
  • 內容與電商結合：將 Dcard 平台的使用者洞察與內容創作能力，應用於商品推薦與內容行銷。例如，透過開箱影片、使用者心得分享、專題文章等方式，自然地導引至商品購買。
  • 用戶體驗優化：提供流暢的購物流程、安全的支付方式、可靠的物流配送與售後服務，確保用戶在「好物研究室」擁有良好的購物體驗。
  • 數據驅動決策：分析用戶的購買行為、瀏覽偏好，以優化商品推薦、庫存管理、行銷策略，提高轉換率與客單價。
  • 社群電商互動：鼓勵用戶在購買後分享開箱心得、評價，並與其他用戶互動，形成社群口碑，進一步推動銷售。

兩者共同目標是透過各自的業務，擴大 Dcard 的用戶基礎，深化用戶在 Dcard 生態系統中的參與度，並創造穩定的營收，最終實現「與所有人產生共鳴」的永續發展。

【答案】Dcard 採納多元化策略的原因是降低風險、開拓營收、擴大用戶接觸點與價值、強化品牌形象，並實現「與所有人產生共鳴」的目標。Dcard Video 透過內容創新、社群經營、跨平台整合及多元變現達成永續目標；好物研究室則透過精選商品、內容電商結合、優化用戶體驗、數據驅動決策及社群互動來達成。

(b) SQL 查詢，找出在 Good Choice Taiwan 進行第二次消費且兩次消費間隔在 7 天內（含）的回購活躍用戶 (returning active users) 的 dcard_id。

定義：

• 回購活躍用戶：指在 7 天內有兩次（含）以上購買紀錄的 Dcard 用戶。
• 第二次購買：指同一用戶的某筆購買紀錄，其時間點在其所有購買紀錄中的時間順序是第二筆（或之後，只要滿足間隔條件）。
• 7 天內：指兩筆購買紀錄的日期（created_at）差小於等於 7 天。

解題思路：

1. 對每個用戶 (dcard_id) 的每次購買進行排序：按照購買時間 (created_at) 升序排列。
2. 找出每個用戶的「前一次」購買紀錄：這可以通過自連接 (self-join) 或使用窗口函數 (window functions) 來實現。
3. 計算當前購買與前一次購買的時間差：使用日期差函數。
4. 篩選出時間差小於等於 7 天的紀錄：這代表是滿足條件的「第二次」（或後續）購買。
5. 提取這些紀錄對應的 dcard_id：並去重。

使用窗口函數（推薦）：
窗口函數 LAG() 可以輕鬆獲取前一行的值。

WITH RankedPurchases AS (
    -- 為每個用戶的購買紀錄按時間排序，並獲取前一次購買的時間
    SELECT
        dcard_id,
        created_at,
        -- LAG() 函數獲取前一行的 created_at 值，這裡的 PARTITION BY dcard_id 是關鍵
        -- ORDER BY created_at 是為了確保 LAG 函數能正確抓到前一筆購買紀錄
        LAG(created_at, 1) OVER (PARTITION BY dcard_id ORDER BY created_at) AS previous_purchase_at
    FROM
        dcard_transactions
    -- 這裡可以加上 WHERE 子句過濾，例如只看 Good Choice Taiwan 的交易，
    -- 但題目給的表格沒有來源欄位，假設此表格就是 Good Choice Taiwan 的交易。
    -- 如果有來源欄位，應加上: WHERE source = 'Good Choice Taiwan'
),
ConsecutivePurchases AS (
    -- 篩選出有前一次購買紀錄，且本次購買在上次購買後 7 天內的紀錄
    SELECT
        dcard_id,
        created_at,
        previous_purchase_at
    FROM
        RankedPurchases
    WHERE
        previous_purchase_at IS NOT NULL -- 確保有前一次購買紀錄
        AND JULIANDAY(created_at) - JULIANDAY(previous_purchase_at) <= 7 -- 計算日期差
        -- 注意：不同的 SQL 方言可能有不同的日期差函數，例如：
        -- MySQL: DATEDIFF(created_at, previous_purchase_at) <= 7
        -- PostgreSQL: (created_at::date - previous_purchase_at::date) <= 7
        -- SQL Server: DATEDIFF(day, previous_purchase_at, created_at) <= 7
        -- SQLite (如上面範例): JULIANDAY(created_at) - JULIANDAY(previous_purchase_at) <= 7
)
-- 最後，選出這些符合條件的 dcard_id，並去重
SELECT DISTINCT dcard_id
FROM ConsecutivePurchases;

解釋 SQL 查詢：

1. RankedPurchases CTE (Common Table Expression):

   • 我們選取 dcard_transactions 表中的 dcard_id 和 created_at。
   • LAG(created_at, 1) OVER (PARTITION BY dcard_id ORDER BY created_at)：這是核心部分。
     • PARTITION BY dcard_id：表示我們為每個 dcard_id 分組計算。
     • ORDER BY created_at：在每個分組內，按照購買時間的先後順序進行排序。
     • LAG(created_at, 1)：獲取當前行「前一筆」記錄的 created_at 值。如果這是該用戶的第一筆購買，previous_purchase_at 將會是 NULL。
   • 這個 CTE 的結果是，每一筆購買紀錄都會帶上該用戶的「前一次」購買時間。

2. ConsecutivePurchases CTE:

   • 我們從 RankedPurchases 中選取資料。
   • WHERE previous_purchase_at IS NOT NULL：過濾掉第一筆購買的紀錄，因為它沒有前一次購買。
   • AND JULIANDAY(created_at) - JULIANDAY(previous_purchase_at) <= 7：這是關鍵的條件判斷。我們計算當前購買時間 (created_at) 與前一次購買時間 (previous_purchase_at) 的天數差。如果這個差值小於或等於 7，就代表這是一次在 7 天內的「第二次」（或後續）購買。
     • 請注意：日期的計算方式取決於您使用的具體 SQL 資料庫系統（如 MySQL, PostgreSQL, SQL Server, SQLite 等）。上述範例使用了 SQLite 的 JULIANDAY 函數。你需要根據實際環境調整日期計算函數。

3. 最終 SELECT DISTINCT dcard_id:

   • 從 ConsecutivePurchases 中選取所有符合條件的 dcard_id。
   • DISTINCT 關鍵字確保每個 dcard_id 只會出現一次，即使某個用戶有多組符合條件的購買（例如，一次購買後 3 天又一次，然後再隔 5 天又一次），我們只需要知道他是回購用戶即可。

測試表格數據：
讓我們手動驗證一下：

• dcard_id = 1377:
  • 購買 1 (2022-01-05)
  • 購買 2 (2022-01-08)
  • 日期差: 2022-01-08 - 2022-01-05 = 3 天。 3 <= 7。所以 1377 是回購用戶。
• dcard_id = 1501:
  • 購買 1 (2022-01-08)
  • 購買 2 (2022-01-12)
  • 日期差: 2022-01-12 - 2022-01-08 = 4 天。 4 <= 7。所以 1501 是回購用戶。
• dcard_id = 1490:
  • 購買 1 (2022-01-07)
  • 購買 2 (2022-01-24)
  • 日期差: 2022-01-24 - 2022-01-07 = 17 天。 17 > 7。所以這兩筆購買不構成回購。
• dcard_id = 1793:
  • 購買 1 (2022-01-16)
  • 購買 2 (2022-01-21)
  • 日期差: 2022-01-21 - 2022-01-16 = 5 天。 5 <= 7。所以 1793 是回購用戶。
• dcard_id = 1619:
  • 購買 1 (2022-01-05)
  • 購買 2 (2022-01-13)
  • 日期差: 2022-01-13 - 2022-01-05 = 8 天。 8 > 7。所以這兩筆購買不構成回購。