效能預算
依代表性裝置、頁型與真實使用者資料設定效能預算；目標、量測工具與例外要在範圍中寫清楚。
再換模板之前
先定義商品頁要幫顧客完成的決策
把商品故事、規格選擇、證據、優惠、信任、履約與量測，接成同一套商品頁系統。
Shopify 主題客製和 Headless 該怎麼選？
佈景主題（Online Store 2.0）適合需求相對標準、重視營運自主性的品牌，區段架構讓行銷團隊能在既定元件內組頁。當模板無法支撐關鍵體驗、效能目標或多系統聚合時，再評估 Headless。實際時程與成本要依客製範圍確認。
主題適不適合，要看頁型、營運方式、整合與長期維護責任。
現成主題和真實內容不合
示範頁的圖片與欄位不一定符合品牌商品；採用前要用真實內容測試代表頁型。
App 成本沒有整體盤點
App 可能增加腳本、資料處理、費用與供應商相依，需要逐項量測和記錄責任。
營運不能自理
每次調整版位都要找工程師，行銷檔期經常受開發排程限制。
01 · OS 2.0
Sections 架構把組頁還給行銷
Shopify 官方文件說明，Online Store 2.0 可用區段組裝頁面模板，並搭配應用程式區塊與 Metafields。營運團隊可在已定義的元件和權限內調整排版。
可重用的 Sections
商品頁、集合頁與內容頁可依模板設定使用區段組裝（Shopify 官方文件），既有元件內的檔期調整可較少依賴工程排程。
Metafields 擴充欄位
Metafields 可承載規格、成分與尺寸指南等結構化欄位（Shopify 官方文件），讓商品資料與描述內容分開管理。
App blocks 乾淨掛載
第三方功能可透過應用程式區塊與嵌入方式接入主題（Shopify 官方文件）；移除時仍需核對殘留程式碼、資料與前台效能。
02 · 效能守門
主題也要有自己的效能預算
Google／SOASTA 2017 年行動速度研究曾回報：頁面載入從 1 秒變 3 秒時，預估跳出機率增加 32%。研究年代、樣本與模型都有適用限制；實際效能優先順序仍應以現有商店的 Core Web Vitals 與使用者資料判斷。
我們怎麼做
客製 Sections
依內容角色與編輯權限設計組頁元件，並說明可調整與不可調整的邊界。
效能預算
以代表頁面檢查腳本、圖片、字型與 App 成本，不用單一分數代替真實使用者資料。
在地整合
逐項確認金流、物流、發票與 LINE 相關服務的當期能力、責任與失敗處理。
好維運
清楚的程式碼結構與文件，降低未來交接與修改成本。
合作流程
01
需求定義
版型規劃與功能範圍確認
02
設計
品牌視覺與關鍵頁面設計
03
開發
主題開發與 App/金物流整合
04
上線培訓
營運後台教學與交付文件
可在範圍中確認的交付
01
主題原始碼
依 Shopify 建議方式組織程式碼與文件，降低後續團隊理解與接手的成本。
02
Sections 使用手冊
記錄納入範圍的組頁元件、欄位、限制與組合方式，供內容團隊與工程團隊共同使用。
03
效能報告
若範圍包含效能驗收，記錄量測環境、代表頁面、基準與發布後觀測方式。
04
營運培訓
依角色與納入範圍安排後台操作、常見情境與交接文件。
工程品質
把效能、無障礙、權限與搜尋條件寫進驗收
可及性
在專案中確認採用的 WCAG 版本與等級，並把語意、鍵盤操作、焦點與 reduced-motion 納入關鍵旅程驗收。
平台級資安
平台合規不會取代應用層責任；前端、整合與營運權限仍需採最小權限、依賴審查與存取紀錄。
SEO 與 GEO 就緒
把可抓取內容、結構化資料、具名來源與索引檢查納入發布流程；這些工作改善可讀性，但不保證排名或引用。
選擇符合現況的架構，往往比追求規格更能控制長期成本。
常見問題
現成主題以授權費為主，客製主題還包含設計、開發、測試、串接與培訓。實際差額要依頁型、功能與內容範圍估算，也可以先用現成主題做必要客製。
時程取決於頁型、客製功能、第三方串接、內容準備與審核節奏。盤點後我們會列出里程碑、相依條件與驗收範圍。
不一定。若設計系統、內容模型與資料介面在主題階段就有清楚定義，部分成果可沿用；但模板、應用程式整合與互動程式碼仍需逐項評估。
交付範圍會列明原始碼、設定、文件、帳號權限與第三方服務。後續團隊仍需要熟悉 Shopify 與專案技術棧，我們會以交接會議和驗收清單降低轉換成本。
