技術與數據優化

A collection of 38 posts

技術與數據優化

PHP 與 Node.js 同一天緊急修補、日本零售接連停單：不懂程式的經營者也看得懂的網站風險

2026 年 10 月 21 日，PHP 與 Node.js 同一天發布緊急安全更新，日本則接連傳出雲端業者遭勒索、外送與便利商店會員資料外洩。本文用引擎、保固、換零件三層比喻，讓不懂程式的經營者看懂網站漏洞為什麼會一再出現、日本這一波事件暴露了哪些管理風險，並整理出可以直接拿去問工程師與廠商的問題，以及品牌這個月就能動手的五件事。

91APP CDMP

購物車放棄率怎麼降？先找出客人在官網哪一步離開：從首屏到結帳的頁面動線診斷表

購物車放棄率是頁面動線的綜合症狀。把進站到付款拆成首屏、導覽與搜尋、商品頁互動、購物車、登入與結帳、付款與物流六步，用「症狀、可能原因、先查什麼」的診斷表找出掉人的那一步，再針對運費揭露時機、訪客結帳、結帳欄位數、付款與取貨方式、行動版速度逐一修正。

91APP CDMP

商品轉換率怎麼算、怎麼用？流量進來不買，先把商品頁分成該推、該修、該下架

商品轉換率是看過某支商品頁的人裡最後買了它的比例，和全站轉換率分開算才找得到問題商品。這篇說明怎麼用 GA4 與 91APP 商品報表算出它、用瀏覽量與轉換率把商品分成該推、該修、該下架，逐項檢查商品頁的主圖、尺寸圖、評價、可售狀態與七天鑑賞期揭露，並附一張症狀對原因的自我診斷表與台灣品牌可照做的行動清單。

OMO 全通路洞察分析

叫貨、出清、調撥總是喬不攏？先訂服務水準政策與核准規則，KPI 才訂得下去

採購多備被說庫存太高，少備被說缺貨；出清該誰提、調撥該誰核，每個部門說法都不同。這篇從後勤會議上最常見的僵局談起，說明為什麼缺貨率和庫存健康度會互相打架，以及要先寫下哪幾條規則：常態品、活動品、新品各自的服務水準政策，叫貨、出清、調撥、報廢的提出與核准分工，可以放手的核准範圍，從發現需要做決定起算的時效，以及統一的判斷門檻。最後提供一套用決策問卷與虛擬商品情境題找出分歧的做法。

OMO 全通路洞察分析

補貨建議為什麼沒人照做？從活動行事曆到決策紀錄，後勤決策工具這樣選

系統算出的補貨建議，採購常常還是打開自己的試算表重算一次。從資訊晚到、太晚發現、整理資料與協調意見三個卡點出發，說明共用活動行事曆、例外提醒、附計算過程的建議清單、決策紀錄與工時抽樣表各自的選型條件，並把導入期的採用成本算進人力規劃。

AI Agent

叫貨、出清、調撥交給 AI agent 之前：誰接哪一段，人在哪裡簽名

叫貨、出清、調撥如果交給 AI agent，要拆成哪幾種 agent、各接哪一段、人在哪裡簽名？這篇用本文提出的六種後勤 agent（檔期情報、決策包、補貨與出清建議、例外監看、核准路由、決策紀錄）說明分工，並解釋為什麼服務水準政策與責任分配表（RACI）沒訂好就上 agent，只會把喬不攏的狀態自動化。文中對照 Capgemini 研究院的信任調查、NIST AI 風險管理框架與 OWASP 對過度授權的提醒，整理權限分級、可回溯紀錄與導入順序。

OMO 全通路洞察分析

採購物流人力盤點：人手夠不夠，別再用「每人管幾個品牌」來算

採購與物流人力夠不夠，用「每人負責幾個品牌」算不出來。品牌數不是工作量，工作量低也不等於人力過多。把工作說明表拆成工作量、工作品質、營運成果三類資料，搭配 4 到 8 週工時紀錄與過去 12 到 24 個月的業務量基準，主管才能判斷後勤人力是否吃緊、分工是否失衡，以及成果不好時該先查流程還是先補人。

技術與數據優化

呆滯庫存是採購的錯嗎？用庫存健康度拆出預測、採購、供應商各自的責任

倉庫裡賣不掉的貨，不一定是採購買錯。同樣是庫存暴增，Target 2022 年的病因是非必需品類需求轉向，Nike 同年則是供應鏈在途時間差。這篇拆解如何把超量、呆滯、短效庫存換算成金額與占比，把缺貨、延遲、品質異常分成採購可控、品牌預測、供應商因素三類，並提出一組採購 KPI：供應商準時足量交貨率、採購可控缺貨率、庫存健康度，以及扣掉運費、急單與品質損失後、經財務確認的總成本改善。

OMO 全通路洞察分析

品牌電商物流 KPI 怎麼定：從準時出貨率到單位物流成本

出貨的每個環節都做到 95 分，顧客收到的完美訂單可能只剩八成。物流 KPI 要先寫清楚定義、公式、資料來源與責任人，再依電商、寄銷倉、門市、直播、外銷各通路分開算。這篇整理準時出貨率、出貨正確率、異常結案時效、帳實準確率、逆物流時效、單位物流成本與客服查貨回覆時效的算法與分母陷阱，說明 3PL 與承運商履約怎麼對帳，以及為什麼第一輪該先收基準、再訂目標。

技術與數據優化

商品安全庫存與補貨點怎麼算？用覆蓋天數看懂缺貨和積壓為什麼同時發生

總庫存看起來很充足，南部的客人卻快要買不到貨，北部倉庫另一款商品還夠賣一百多天。用一間虛構的三倉水杯店，說明缺貨與積壓為什麼會同時出現，再一步步示範庫存覆蓋天數、安全庫存、補貨點、建議下單量與周轉天數怎麼算，最後用四象限與 SKU 乘倉庫的熱力表，找出同一個商品這倉快缺、那倉壓著的「雙高」位置。

OMO 全通路洞察分析

商品庫存缺貨先調撥還是先補貨？從庫存診斷到有人負責的行動流程

報表亮紅燈之後，庫存問題才剛開始。用一間虛構水杯店示範四層診斷，比較補、調、停、清四種處方，說明調撥量為什麼要先模擬、補貨量為什麼要和調撥一起算，再把建議寫成有負責人、截止日與狀態的任務。

技術與數據優化

SKU 管理怎麼做？從品類地圖揪出拖累業績的商品，再決定誰來接手

全店營收在漲，某個品類卻悄悄少了一成。我們用一間虛構水杯店，示範 SKU 管理怎麼從品類、子類一路鑽到單一商品：用矩形樹狀圖找出面積大又在掉的區塊，用多項指標找出優先查核的商品並拆出它拖累的是營收、利潤還是庫存，依功能、價格與改購紀錄找替代品，再用同時購買率與提升度篩選搭配候選，最後把這套判斷做成看得懂、接得到動作的商品報表。

技術與數據優化

轉換追蹤怎麼重建：第三方 Cookie 留下來了，瀏覽器端的官方衡量方案卻收了

很多品牌在等 Chrome 淘汰第三方 Cookie，等到的卻是 Google 把 Attribution Reporting API 一起退役。瀏覽器不會再代勞衡量，廣告轉換要被算得回來，得自己把事件定義、採集、送達、身分匹配、去重五個環節逐項驗收。這篇拆開每個環節各補哪一段流失、裝錯會看到什麼症狀，以及怎麼驗。

MCP

MCP 是什麼？它讓 AI 接進你的系統有了共同規格，開多大仍是你的決定

MCP（Model Context Protocol，模型上下文協定）是一套讓 AI 應用連接外部系統的開放標準，2024 年 11 月由 Anthropic 發布，2026 年 7 月完成改版。這篇從台灣零售品牌行銷主管的角度回答 MCP 是什麼：它的三個角色對應到你公司裡的什麼、伺服器掛出去的三類東西怎麼分、品牌會在哪些地方真的撞到它，以及哪些事情協定不會替你決定。

91APP CDMP

客服工單分流怎麼設計：把訊息拆成三種，退換貨尖峰的人力才排得出來

客服訊息回不完的時候，加人往往解不了問題，真正的瓶頸在於三種本質不同的工單擠在同一條隊伍裡。本文提出以決策成本分流的做法，並拆解退換貨尖峰為什麼跟促銷尖峰對不上，讓品牌把 SLA 和排班一起重排。

91APP CDMP

缺貨與超賣的代價，多數品牌只算到取消那一單為止

缺貨的損失被普遍低估，因為多數品牌用「少賣的件數乘上售價」在估，這等於預設顧客只是延後購買。跨國研究量到的行為並非如此。本文拆解缺貨與超賣的三段代價：當下那一單、台灣網路交易法規下的契約義務、以及後續行為的變化，並說明可售量為什麼在系統之間對不齊。

技術與數據優化

退貨率怎麼算才看得出問題：分母是訂單、件數還是金額，決定了你看到的答案

同一份報告裡的兩個退貨率差了 3.5 個百分點，兩個都對，差別只在分母含不含門市。這篇拆開退貨率的三種算法分別回答客服、倉儲與財務的哪個問題、為什麼跨品類比大小量到的是商品屬性與法律條件、以及退貨率變高其實可能是新客變多的副作用。附台灣消保法七日猶豫期的條件式例外，以及品牌真正該追蹤的切分後退貨率。

技術與數據優化

退貨原因分析怎麼做：欄位設計決定你收到的是結案理由，還是商品頁修改單

退貨原因是顧客免費送上門的商品資訊改善清單，多數品牌卻讓它爛在客服工單裡。收不到有用資訊的原因通常同時有四個：欄位用途、填答設計、資料顆粒度、以及有沒有人負責接。這篇拆開可行動的原因分類要過哪三道篩選、怎麼把原因對回最小可行分析單位、以及哪些改商品頁、哪些該回頭改選品與備貨。

廣告平台操作實務

AI 廣告投放愈自動化，受眾名單愈是勝負手：排序看預期帶客數，不看倍數

兩大平台的官方文件都已寫明，你設定的受眾是建議不是圍欄，系統可以投給訊號以外的人。品牌手上仍有多個槓桿，其中最常被低估的一個是餵進去的那份名單。這篇拆解名單該怎麼排優先序：倍數只當入場門檻，候選排序看預期帶客數，也就是濃度差乘上可觸及人數。附平台官方規格對照、示意計算、防資料洩漏的護欄，以及名單保鮮期的管理方式。

技術與數據優化

AI 客服答不準怎麼辦？先盤點它讀不到的那幾張表

評估 AI 客服時，大部分品牌問的是哪家系統比較強，實際卡住的卻是它能不能讀到後台那幾張表。這篇把尺寸庫存、訂單狀態、多品牌設定、平台串接四類真實提問拆成資料需求清單，說明答錯的代價怎麼估、哪些問題該轉真人，以及對話紀錄怎麼回流成會員標籤。

技術與數據優化

商品推薦不準？別急著換模型，先檢查商品資料

站內推薦與搜尋推不準，團隊通常先調模型、版位與權重，很少打開被送進系統的商品資料。屬性空白、分類只服務後台、識別碼跨系統對不上，都會讓演算法失去可以比較的材料。這篇文章把「推不準」拆成可檢查的資料問題，說明公開研究能證明什麼、不能證明什麼，並給出先修資料還是先調模型的判斷條件與量測設計。

技術與數據優化

AI 搜尋能見度怎麼量？曝光不等於被引用，被引用不等於有生意

Google 開了生成式 AI 成效報告，打開只有曝光一個數字，沒有點擊、沒有排名、沒有查詢字。市面上的監測工具賣的是提及率，那也不是引用。本文把 AI 搜尋能見度拆成爬蟲來過、有曝光、被寫進答案、有人點進來四類訊號，說清楚每一類能證明什麼、不能證明什麼，以及不必先買工具就能開始的查核做法。

技術與數據優化

Agentic Enterprise Solution：企業 AI Agent 平台怎麼比？Gemini Enterprise、Agentforce、Bedrock AgentCore 官方文件對照

選企業 AI Agent 平台，判準不在誰的模型比較聰明，也不在這家有沒有台灣分公司。把 Google Gemini Enterprise、Salesforce Agentforce、AWS Bedrock AgentCore、Microsoft Copilot Studio 與 SAP Joule 的官方文件攤開對照，真正要量的是三件事：你的資料被存在哪、agent 能讀還是能做、它懂不懂台灣零售怎麼做生意。

91APP CDMP

CDP 與資料倉儲差在哪裡：導入前先確認你的資料能不能變成一個動作

資料都進了倉儲，行銷卻還是發不出那封信。CDP、資料倉儲、資料湖、CRM、DMP 各自負責什麼？本文用 CDP Institute 的七項認證要求當驗收清單，把「資料存得完整」和「資料能變成一個動作」之間的落差講清楚，並給出導入前該先確認的前置條件。

91APP CDMP

CRM、POS、ERP 和電商系統怎麼整合：客製開發不是唯一的路

電商平台、POS、ERP、CRM 都有了，要回答「上週在門市買過又在官網看過同一系列的人有誰」卻要三個部門各出一張 Excel。這篇把每套系統負責哪一筆紀錄講清楚，攤開接起來有哪幾條路可走、各自適合什麼情況，並回答那個最常被問的問題：一定要找廠商客製嗎。