電子商務平台，資料搬遷經驗談

什麼時候需要搬遷資料？

工作上有處理過：協助廠商做「電商平台」的轉移。這類需求通常是廠商已經在原平台經營一段時間，因為想要更多功能，或是各種商業決策，決定搬遷平台。由於已經在原平台經營一段時間，也累積不少資料，以廠商的立場，一定會希望可以把資料帶走，而且通常廠商不會想繼續支付原平台的費用，因此最終一定會需要關閉原平台的後台。這時候，就會需要將原本放在原平台的資料，轉移到新平台。

這類資料通常分為三類：產品、顧客、訂單，以下就分別聊一聊我的經驗。

產品

產品基本上滿單純的，除了資料筆數相較之下通常比較少，而且就算搬遷了，通常也還會需要廠商自行排版、整理過。這邊比較會遇到的問題，通常是各平台的分類規則，或是後台的分類如何對應顯示在前台，會是各家有各家的做法，不過分類通常也是由廠商端做處理。

顧客

顧客資料，也可以搬，但搬完之後，顧客不見得會跟著你一起搬家 😹，工程面只能夠幫廠商把資料存到新平台，把聯絡資料、會員等級保存，頂多看平台是不是有支援「生成帳號啟用連結」，發通知信給消費者，廠商端要想辦法搭配辦活動，吸引消費者真的去新平台上啟用帳號。

訂單

訂單則是比較麻煩的部分。前幾次操作，我都是試著打來源平台的 API，拿到十幾筆資料，來跟目標平台的欄位做比對。覺得差不多轉換完、對齊完畢之後，開始往目標平台打 API 餵資料。送著送著，就會出現資料轉換失敗、沒有建立成功的筆數，這時候進去看原因，才發現，是特殊情況的訂單，可能退貨，可能取消…等等，於是，修改欄位對齊的規則，再次發送，然後又出現失敗筆數，實際查看，發現，咦，是回饋金的規則沒有寫對…於是再度修改、送出…就這樣來回幾次，把資料全部餵完。

前前後後陸續做了好幾次資料搬遷，神奇的是，從來都沒有被我遇過「來源平台」跟「目標平台」兩者剛好都一樣的案例，可見台灣的電商平台市場真的是百家爭鳴，從傳統到沒有提供 API，只能從店家後台下載訂單 excel 出來的(而且檔案超大，要打開都有困難的這種)，或是打 API 存資料到目標平台時，一直遇到問題，結果平台窗口說，這也是他們第一次遇到需要打 API 存這麼多資料進來的情況，都被我遇到 🤨。

從隨機撈資料，到有意識地挑案例

就這樣做了幾次之後，我嘗試了另一種做法：我不再被動拿到資料 ⭢ 解析 ⭢ 嘗試，而「主動去挑選我要的資料」。從之前的經驗得知，訂單基本上可以分成「正常訂單」和「特殊訂單」：正常訂單，顧客下單、付款、店家出貨、顧客順利收貨，雙方都開心。而「特殊訂單」：退貨、部分退貨、換貨、取消訂單、未結帳、給折扣、有回饋金…，這種訂單，光靠 API 撈回來的 JSON，是完全沒辦法判斷欄位的，絕對要搭配來源平台的電商後台介面，直接找出這種訂單的編號，實際比對畫面，看懂「拿到的欄位是什麼意思」。等於是，不再盲目打 API 拿到隨意的幾筆訂單資料，而是有意識地去後台挑出「我想要看的訂單長相」，然後再打 API 抓回資料，做欄位對齊。於是，改採用這種做法的結果，打 API 餵資料進目標平台，我發現順利多了，也還是有些失敗的筆數，不過一看詳細資料，果然，失敗的幾乎都是測試訂單 (通常看 email、備註等都會發現)。

這次經驗讓我蠻難忘的，我以前一直認為，做 ETL / 資料轉換，就是考慮資料的來源、去處，然後做中間的轉接器，把欄位對好、格式轉好，轉接器是中間的工程重點。但經過這次的做法調整，我發現，重要的是，先知道我面對的資料有哪些種類，有一個大局觀，並且抓大放小，先處理掉 70% 的正常案例，剩下的特殊案例另外處理。這種思維，讓我不再只有思考資料本身，而是真的把資料以及真實世界的場景搭配在一起看，只有將真實場景納入考慮，資料本身才有意義。