中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

導語：對網游的設計來說，往往需要進行設計商城系統這一步驟，在《以組件化思維為出海游戲設計商城系統——規劃篇》中，作者提到了針對公司游戲產品現狀進行優化的三個方案。這三個方案并不是割裂的，可以同時進行。但是，方案三落地難度過大，因此實際上作者本人也沒有實操經驗。本篇作者對方案一和方案二的落地實操經驗進行復盤，供大家一起參考。

總結方案一與方案二，最終的用戶交易流程應當為：

1. 游戲客戶端內提供商城組件入口
2. 用戶通過該入口跳轉至商城進行商品（虛擬商品、實物商品）瀏覽、挑選
3. 提交訂單后，跳轉至游戲幣支付組件完成游戲幣支付

從實現層考慮，需要引入分發層、游服SDK等其他節點進行配合。實現層邏輯圖如下：

特別需要注意的是：游戲幣的充值和數據存儲對于游戲項目業務來說過于核心敏感，建議各游戲業務方自行保留處理，不交付給服務提供方——游戲幣支付組件

也就是說，用戶在游戲幣支付組件內的賬戶僅可做余額的顯示，最終的扣減、充值指令需要交給游戲服務端完成。

接下來根據實操經驗，作者列舉一下實現上述流程，功能端和表現端需滿足的能力、需特別注意的點。

01 商城組件能力清單

（本文僅列舉相對于其他跨國電商需特別注意的點）

1. 后端

（1）商品發布

• 需支持為商品設定“限定供貨地區”
• 在實際業務中，實體商品通常在各地區就近采購、就近發貨，由于同一個商品在不同地區的采購價不同，因此需支持為不同地區用戶設定不同的價格，包括普通價、活動價

（2）訂單管理

• 支持用2種貨幣單位展示訂單

（3）物流管理

• 出海業務下，若物流外包給各國經銷商，則物流管理端需能夠獲取各經銷商信息
• 若商品支持游戲幣購買，則運費也需要支持游戲幣支付

2. 前端

（1）商品展示

• 特別注意需支持同一個商品的2種標價方式（游戲幣、現金貨幣）
• 由于同一個商品的標價貨幣類型不同，因此商品的按價格排序、價格區間搜索、搜索結果排序邏輯需加入貨幣類型因素。

• 考慮到體驗上的統一、?數據安全兩個因素，游戲客戶端內的商城通常以內嵌頁的形式呈現，然而內嵌頁的尺寸小于客戶端尺寸。若商城支持交易實物商品，那么，小尺寸的頁面對商城的前端表現（UI\交互）有非常高的要求。 ps.作者在實操時，被限定的商城內嵌頁分辨率為980*630，這個規格下，整個頁面只能排2排商品，體驗起來遠遜于網頁商城，產品上線后都沒有得到較好的解決，只能后續專門優化。
• 為了規避法務風險，實物商品僅支持特定地區用戶購買。因此，用戶在瀏覽商品、下訂單時，系統都需要根據收貨地址或IP進行篩選，對不符合條件的用戶進行提醒、阻斷。

• e?在實際業務中，實體商品通常在各地區就近采購、就近發貨，由于同一個商品在不同地區的采購價不同，因此需支持為不同地區用戶顯示不同的購買價格，包括普通價、活動價

（2）物流

需支持郵寄、自提兩種收貨方式：支持“游戲幣購買實體商品”的海外地區絕大多數為發展中國家，部分國家基礎設施建設落后、政治不穩定，導致物流條件差。因此，支持貨物自提尤其重要。用戶購買時，需允許自由選擇收貨方式。貨物自提意味著公司在當地需要有業務處，這個建議通過外包解決。

（3）客服

由于業務涉及不同國家、地區，因此前端客服需提供多種通用渠道，例如Facebook、郵箱、跨國電話、在線IM

02 游戲幣支付組件能力清單

1. 運維端

（1）游戲注冊

• 若某個游戲計劃接入商城組件和游戲幣支付組件，最終實現“在游戲商城內以現金、游戲幣購買實體、虛擬商品”，則需提前進行游戲注冊。注冊時需提供該游戲的名稱、編碼、APPID、游戲幣名稱、游戲幣ID等必要信息
• 游戲管理：可對具體游戲做停用處理

（2）商戶注冊

• 商戶一般主要為錢包、UC（方便租戶隔離），依據具體的業務流程來定
• 注冊時提供該商戶的名稱、ID、秘鑰

2. 運營后臺

（1）區服注冊

• 游戲在運維端注冊后，運營人員在運營后臺自主決定本游戲哪些區服接入商城組件和游戲幣支付組件。新增區服時，需提供該區服的名稱、ID、服務器IP、機器碼、私鑰等信息
• 區服管理：可對具體區服做停用禁用操作，方便配合游戲進行合服、關服

（2）賬戶管理

• 在此查看、管理用戶在游戲內的游戲幣余額、交易情況
• 賬戶安全相關操作，包括賬號凍結、找回

（3）訂單管理

• 在此查看、管理前端發生的所有支付訂單

（4）支付安全設置

• 包括支付密碼錯誤次數設置、自動鎖定時長

（5）區服匯率設置

由于同一個游戲，基于歷史因素，不同區服內已發放的游戲幣總額不同，那么單位游戲幣的購買力也不同（游戲幣多的區游戲幣貶值）。這種購買力的差異是以“區服”為分隔單位的。

又由于同一商品在發布時，定價不受區服影響，不同區服共用同一個價格。

那么，需要引入“區服匯率”的概念，對各個區服內的商品游戲幣定價做干預，使得不同區服內的商品價值與貨幣購買力一致。

最終同一個商品在不同區服內的最終游戲幣定價計算公式為：商品基礎定價（商品發布時價格）*區服匯率

舉例來說：榮耀筆記本在游戲內發布時定價為6000鉆石，區服A的區服匯率為1.1，區服B的區服匯率為0.9，則區服A內商城展示的價格為6600金幣，區服B內商城展示的價格為5400鉆石

3. 前端

1. 賬戶管理：支持用戶賬戶、支付密碼的注冊、修改等基礎操作
2. 支付能力：查詢賬戶余額、輸入支付密碼、安全驗證等

03 其他能力

上述游戲支付組件和商城組件能力理論上已能夠完成整個業務邏輯流程，但是一個商業系統的建立必須有一些超脫于具體組件的基礎能力：

1. 對賬

用戶的整個交易流程橫跨游戲客戶端、商城組件、游戲幣支付組件3個系統（實際技術實現時，還會有額外的分發層、游服SDK層等進行配合），

在數據流轉過程中，任何外部攻擊、數據丟包都會導致鏈條出錯。因此需要設計對賬系統進行核查。此外，由于商城組件、游戲幣支付組件是服務提供方，不對具體業務結果負責，因此建議有獨立的第三方對賬系統實現跨組件對賬。

對賬系統的設計需要特別注意各系統的時間延遲處理、壞賬預警、自動報警、數據凍結、異常訂單揪出

2. 日志

一旦對賬出現問題，日志系統就會成為問題定位及后續處理方式的唯一依據。

（1）功能日志

記錄整個后臺發生的所有功能點使用情況。功能日志主要是記錄運營人員在操作系統時發生的錯誤。

（2）通道日志

異常原因排查：記錄各業務節點收到的支付訂單數據。若某節點開始與其他節點出現數據沖突，則說明該節點為問題節點。開發人員憑借支付訂單號到此節點進行詳細排查，即可摸清異常訂單的產生原因。

平賬功能：通過通道日志定位出異常訂單及產生原因后，運營人員需要對異常訂單做出平賬處理，否則該異常訂單會導致賬對不上。

舉例來說：若排查發現，在游服扣款節點從用戶的賬戶內多扣了10個金幣，那么平賬時需要向用戶賬戶內返還10個金幣，同時將該筆異常訂單標記為“已平賬”。平賬后，該筆異常訂單將不再被對賬系統重復統計。

（3）平賬日志

記錄所有已被執行的平賬操作及訂單詳情，方便后續二次核查。

3. 隱私保護

數據隱私：在當今的保守主義浪潮下，數據的跨國傳輸、用戶隱私數據保護越來越受到各國重視，而電商系統和支付系統不可避免地需要采集用戶個人數據（地址、聯系方式等）。為了規避法律風險，從產品設計方面考慮，需要注意以下方面：

1. 后臺數據脫敏：所有管理后臺，涉及用戶賬戶部分都需要做脫敏處理。
2. 管理員權限分級：查看數據的權限、使用功能的權限
3. 協議告知：需設計協議告知系統，在用戶初次進行個人隱私數據上傳時（例如注冊賬戶時）做提示，要求用戶進行授權。

特別注意協議內容需根據用戶所在地區做自適應顯示。

#相關閱讀#

《以組件化思維為出海游戲設計商城系統——規劃篇》

本文由 @十萬號子手 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議。