Khi chuyển đổi sang Cafe24, thay đổi không chỉ nằm ở nơi bản ghi được lưu. Products, cách thiết kế storefront, tài khoản Customers, lịch sử đơn hàng, thông tin thanh toán, quy trình vận chuyển, redirects, app và các luồng kết nối qua API phải tiếp tục phối hợp được với nhau trong mô hình vận hành mới.
Cửa hàng nguồn có thể tổ chức dữ liệu thương mại quanh một catalog đơn giản, extension marketplace, cơ sở dữ liệu tùy chỉnh, storefront theo khu vực, quy trình tồn kho do ERP quản lý hoặc checkout đã được tùy chỉnh sâu. Cafe24 lại có cấu trúc riêng cho Products, options, variants, inventories, Categories, cấp Customers, Orders, thanh toán, shipment, hoàn tiền, return, redirect, webhook, tài nguyên thiết kế storefront và app. Vì vậy, câu hỏi không phải là có thể sao chép từng trường nguồn vào đâu đó trên Cafe24 hay không. Cần xác định mỗi bản ghi phải tiếp tục mang ý nghĩa kinh doanh gì khi Cafe24 trở thành storefront vận hành chính.
Kế hoạch dữ liệu cho Cafe24 nên tách rõ việc di chuyển bản ghi khỏi việc chuyển ý nghĩa kinh doanh sang mô hình đích. Dữ liệu Products phải tiếp tục hỗ trợ quyết định mua. Dữ liệu Customers phải phục vụ nhận diện tài khoản, phân nhóm và chăm sóc khách hàng. Dữ liệu Orders phải hỗ trợ tra cứu sau launch, đối chiếu thanh toán, vận chuyển, hoàn tiền, return và báo cáo. Dữ liệu storefront và SEO phải duy trì khả năng khách hàng tìm thấy nội dung quan trọng. Dữ liệu app và API phải được giao cho đúng hệ thống tiếp tục quản lý thay vì bị coi như các trường dữ liệu thông thường.
Tổng quan cách dữ liệu cần được biểu diễn trên Cafe24
Cafe24 có bề mặt dữ liệu rộng: Products, Categories, Customers, Orders, thanh toán, shipment, hoàn tiền, return, redirects và webhooks đều có thể ảnh hưởng đến kế hoạch chuyển đổi. Điều đó không có nghĩa mọi bản ghi nguồn đều thuộc một phạm vi di chuyển dữ liệu phẳng. Mỗi nhóm dữ liệu phải được hiểu theo vai trò mà nhóm đó sẽ đảm nhiệm trên Cafe24.
| Nhóm dữ liệu | Nội dung có thể tồn tại ở Cửa hàng nguồn | Câu hỏi cần trả lời trên Cafe24 |
|---|---|---|
| Định danh Products | Tên, SKU, brand, model, vendor, mã nhà cung cấp, ID nội bộ | Mã nào cần tiếp tục hiển thị cho khách hàng, dùng trong quản trị hoặc phục vụ tích hợp? |
| Cấu trúc Products | Options, variants, bundles, thuộc tính tùy chỉnh, nhóm Products | Thành phần nào trở thành options, variants, thuộc tính Products hoặc được xử lý bởi app/quy tắc riêng? |
| Tồn kho | Số lượng, tồn kho kho hàng, safety stock, lượng đã phân bổ, quy tắc khả dụng | Giá trị nào cần di chuyển, cấu hình, đồng bộ hoặc loại khỏi dữ liệu lịch sử? |
| Categories và merchandising | Cây Categories, vị trí menu, quy tắc collections, nhóm chiến dịch, khu vực nổi bật | Nhóm nào thực sự là cấu trúc catalog, nhóm nào chỉ phục vụ trình bày storefront hoặc khuyến mãi? |
| Dữ liệu Customers | Tài khoản, cấp/nhóm Customers, địa chỉ, memos, tham chiếu social login, trạng thái đồng ý | Trường nào cần cho tài khoản, phân khúc, hỗ trợ và marketing trên đích? |
| Lịch sử đơn hàng | Orders, mặt hàng đã mua, options, thanh toán, shipment, hoàn tiền, return, mã giảm giá, memos | Chi tiết nào phải còn hữu ích cho chăm sóc khách hàng và báo cáo thay vì bị hiểu là cấu hình xử lý đơn hàng đang hoạt động? |
| Storefront và nội dung | Menu, boards, pages, trường trang chi tiết Products, SEO, redirects, quy tắc theme | Thành phần nào là dữ liệu, thành phần nào thuộc cấu hình storefront và thành phần nào cần thiết kế/phát triển riêng? |
| App và tích hợp | Dữ liệu do app sở hữu, webhooks, analytics, nhà cung cấp thanh toán, mã định danh ERP/CRM/WMS | Hệ thống nào sẽ tiếp tục sở hữu quy trình sau chuyển đổi? |
Cùng một trường nguồn có thể cần đi vào những tài nguyên Cafe24 khác nhau tùy trường đó mô tả lựa chọn mua hàng, thông tin catalog, quy tắc vận hành, thông tin giao dịch trước đây hay mối liên kết với hệ thống bên ngoài. Mô hình đích phải giữ đúng vai trò đó, không chỉ giữ tên trường.
Dữ liệu Products không chỉ là một danh sách sản phẩm
Khi xác định cách đưa Products vào Cafe24, trước hết cần hiểu vai trò thương mại của từng thông tin: khách hàng nhìn thấy gì, đội ngũ quản trị cần quản lý gì và hệ thống kết nối đang dựa vào dữ liệu nào. Cửa hàng nguồn có thể lưu thuộc tính Products dưới dạng variants, trường tùy chỉnh, metafields, bảng thông số, nhãn Categories, dữ liệu app hoặc khối nội dung. Cafe24 có thể cần phân tách rõ hơn giữa tài nguyên Products, options, variants, hình ảnh, trường SEO, tags, Categories, thuộc tính tùy chỉnh và bản ghi tồn kho.
Ba vai trò cần được phân biệt là lựa chọn mua, thông tin mô tả và dữ liệu vận hành. Màu sắc, kích thước, số lượng trong gói hoặc cấu hình có thể là lựa chọn khách hàng phải chọn. Chất liệu, ghi chú tương thích, kích thước vật lý hoặc chứng nhận có thể là nội dung mô tả. Mã nhà cung cấp, vị trí trong kho, giá trị hải quan hoặc khóa ERP lại có thể chỉ phục vụ vận hành. Gộp cả ba loại thành cùng một kiểu trường thường khiến catalog Cafe24 khó sử dụng hơn.
| Thành phần Products ở nguồn | Ý nghĩa thường gặp | Điều cần xác định trên Cafe24 |
|---|---|---|
| SKU | Mã định danh cho mặt hàng bán được hoặc vận hành | Xác định SKU thuộc Products chính, variant hay hệ thống bên ngoài. |
| Tên và giá trị option | Cách khách hàng lựa chọn | Xác định option có tạo ra variant có thể mua hay chỉ cung cấp thông tin. |
| Bộ hình ảnh Products | Hỗ trợ quyết định mua và merchandising | Xác định hình ảnh thuộc Products chính, variant hay phần trình bày landing page. |
| Bảng thông số | Hỗ trợ so sánh Products | Quyết định giữ ở dạng thông tin có cấu trúc, thuộc tính tùy chỉnh hay khối nội dung. |
| Nhãn khuyến mãi | Phục vụ chiến dịch hoặc merchandising | Xác định nên dùng tags, cấu hình hiển thị, app hay thiết lập chiến dịch khi launch. |
| Trường SEO | Duy trì khả năng tìm thấy từ công cụ tìm kiếm | Giữ metadata và đường dẫn có giá trị khi chúng vẫn phục vụ mục đích tìm kiếm. |
| Trường tùy chỉnh | Chưa thể kết luận chỉ từ tên trường | Xác định ý nghĩa kinh doanh trước khi quyết định trường đích. |
Một kế hoạch chất lượng không ép mọi thông tin Products vào trường gần giống nhất trên Cafe24. Cần xác định thông tin nào phải tiếp tục có cấu trúc, thông tin nào nên trở thành nội dung Products, thông tin nào thuộc app/thiết kế và thông tin nào nên tiếp tục nằm trong hệ thống kết nối bên ngoài.
Options, variants và tồn kho cần được hiểu theo đúng chức năng
Cafe24 hỗ trợ options của Products, variants và tài nguyên tồn kho theo variants. Vì vậy, cách biểu diễn options ở Cửa hàng nguồn là một quyết định quan trọng về quan hệ dữ liệu. Nền tảng nguồn có thể dùng các khái niệm khác nhau như options, variants, child products, configurable products, combinations, attributes, bundled items hoặc modifiers để mô tả lựa chọn mà khách hàng có thể mua.
Kế hoạch cần tránh hai thái cực. Một là làm phẳng variants thành nội dung mô tả thông thường. Hai là cố giữ nguyên mọi cấu hình nguồn dù Cafe24 cần biểu diễn chúng theo cách khác. Thay vào đó, hãy xác định khách hàng phải chọn gì, đội ngũ merchant cần quản lý gì và hệ thống tồn kho/xử lý đơn hàng cần nhận diện gì.
| Mẫu cần kiểm tra | Vì sao quan trọng | Cách xác định |
|---|---|---|
| Option làm thay đổi giá | Lựa chọn của khách hàng thay đổi giá trị thương mại | Xác định giá theo variant của Cafe24 hoặc cấu hình phù hợp khác. |
| Option làm thay đổi tồn kho | Lựa chọn ảnh hưởng khả năng bán | Xác định tồn kho được quản lý ở cấp variant nào. |
| Option làm thay đổi hình ảnh | Lựa chọn thay đổi cách trình bày | Xác định hình ảnh gắn theo variant hay theo gallery của Products. |
| Option chỉ mang tính mô tả | Lựa chọn không ảnh hưởng đến quá trình xử lý đơn hàng | Cân nhắc nội dung Products, trường thông số hoặc dữ liệu phục vụ filter thay vì tạo variant. |
| Nguồn dùng bundle/kit | Một mặt hàng trên storefront đại diện cho nhiều mặt hàng vận hành | Xác định Cafe24, app hay một phương án tái cấu trúc riêng sẽ sở hữu quan hệ này. |
Tồn kho cũng cần được phân loại kỹ. Một con số có thể là lượng có sẵn, lượng trong kho, lượng có thể bán, lượng đã phân bổ, quy tắc backorder hoặc giá trị được đồng bộ từ hệ thống ngoài. Nếu tồn kho của Cửa hàng nguồn do ERP, POS, marketplace hoặc WMS quản lý, không nên mặc định Cafe24 sẽ trở thành nguồn dữ liệu duy nhất trước khi mô hình vận hành tương lai được xác nhận.
Categories, menu và khả năng khách hàng tìm thấy Products phục vụ những mục đích khác nhau
Cửa hàng nguồn thường trộn Categories, menus, collections, landing pages và nhóm chiến dịch. Khi chuyển sang Cafe24, cần tách ý nghĩa của từng cấu trúc. Cấu trúc Categories có thể tổ chức catalog; menu dẫn đường cho khách hàng; landing page phục vụ merchandising; redirect duy trì traffic tìm kiếm; filter giúp khách hàng thu hẹp lựa chọn. Các mục đích có liên quan nhưng không đồng nhất.
Nếu chỉ chuyển Categories mà không phân biệt các vai trò trên, catalog đích có thể đủ Products nhưng khách hàng khó tìm. URL có thể tồn tại nhưng internal linking kém hiệu quả. Landing page có thể được dựng lại về hình ảnh nhưng mất liên kết với Products phù hợp.
| Cấu trúc nguồn | Vai trò có thể có trên Cafe24 | Điều cần xử lý |
|---|---|---|
| Cây Categories chính | Tổ chức catalog | Chỉ giữ khi còn phù hợp với cách khách hàng sẽ điều hướng trên đích. |
| Nhãn menu | Đường điều hướng storefront | Chủ động dựng lại nếu menu không trùng với cấu trúc Categories. |
| Collection nổi bật | Quy tắc merchandising | Quyết định dùng Categories, nội dung, app hay curation thủ công. |
| Landing page chiến dịch | Đường chuyển đổi khách hàng | Giữ nội dung và bối cảnh Products khi trang vẫn phục vụ paid traffic hoặc SEO. |
| URL cũ | Tài sản traffic | Redirect hoặc chủ động ngừng sử dụng dựa trên giá trị còn lại. |
| Bộ lọc Products | Hỗ trợ khách hàng tìm lựa chọn phù hợp | Xác định filter dựa vào trường dữ liệu có cấu trúc hay chức năng của theme/app. |
Vì vậy, mô hình dữ liệu Cafe24 phải xét đến khả năng khách hàng tìm Products, không chỉ các trường trong cơ sở dữ liệu. Cấu trúc Categories và URL ảnh hưởng trực tiếp đến quá trình từ nhu cầu của khách hàng đến việc tìm được Products phù hợp.
Dữ liệu Customers cần giữ đúng bối cảnh tài khoản và phân nhóm
Dữ liệu Customers trên Cafe24 có thể liên quan đến tài khoản, cấp/nhóm, thuộc tính Customers, memos, tài khoản social, tài nguyên thanh toán, trường đăng ký và thông tin phục vụ marketing hoặc chăm sóc khách hàng. Cửa hàng nguồn có thể không tách những nội dung này rõ. Một số thuộc trường tiêu chuẩn; số khác có thể đến từ loyalty app, B2B app, CRM, nền tảng marketing hoặc biểu mẫu đăng ký tùy chỉnh.
Câu hỏi trọng tâm là dữ liệu Customers phải phục vụ được việc gì sau di chuyển dữ liệu. Bản ghi có thể cần cho nhận diện tài khoản, tra cứu lịch sử đơn hàng, phân tier Customers, áp dụng giá B2B, chăm sóc khách hàng, phân khúc marketing, dùng lại địa chỉ hoặc rà soát gian lận. Chỉ có tên và email không đủ để duy trì những kết quả này.
| Thành phần Customers | Ý nghĩa khi chuyển đổi | Hệ quả nếu xử lý sai quan hệ |
|---|---|---|
| Định danh tài khoản | Nhận diện khách hàng trong Cafe24 | Tạo tài khoản trùng hoặc mất liên kết với Orders. |
| Tier/nhóm Customers | Phục vụ giá, quyền lợi, phân khúc hoặc chăm sóc | Nhãn nhóm được chuyển nhưng quy tắc đi kèm không còn. |
| Địa chỉ | Phục vụ checkout và hỗ trợ | Định dạng không phù hợp với yêu cầu thị trường/vận chuyển. |
| Trường đăng ký | Ghi nhận thông tin riêng của doanh nghiệp | Trường quan trọng bị bỏ qua chỉ vì ở nguồn là trường tùy chỉnh. |
| Memos Customers | Hỗ trợ nội bộ và chăm sóc khách hàng | Ghi chú được chuyển nhưng mất ý nghĩa hoặc bị mất hoàn toàn. |
| Tham chiếu social/thanh toán | Liên kết với định danh hoặc nhà cung cấp bên ngoài | Dữ liệu nhạy cảm hoặc dữ liệu do nhà cung cấp sở hữu bị giả định là có thể di chuyển dữ liệu. |
Cũng cần phân biệt giá trị lịch sử của bản ghi với cách tài khoản hoạt động trực tiếp. Dữ liệu Customers trước đây có thể hữu ích cho hỗ trợ, nhưng login, passwords, phương thức thanh toán và quyền lợi đang hoạt động có thể cần thiết lập riêng theo cơ chế của Cafe24 hoặc cần thông báo cho Customers.
Lịch sử đơn hàng phải giữ đủ thông tin để tra cứu và đối chiếu
Cafe24 có tài nguyên Orders cùng các phần liên quan đến mặt hàng đã mua, thông tin người mua, dòng thời gian thanh toán, người nhận, shipment, hoàn tiền, return, mã giảm giá, memos, hủy, đổi, sales channels và dữ liệu Orders đã được chuyển. Bề mặt rộng này hữu ích nhưng cũng đòi hỏi phải hiểu đúng ý nghĩa của lịch sử đơn hàng.
Một đơn hàng trước đây không có ý nghĩa chỉ nhờ số đơn. Các bản ghi liên quan phải tiếp tục cho biết khách hàng đã mua gì, ai mua, thanh toán và giao hàng theo cách nào, discount nào đã được áp dụng, có hoàn tiền/return hay không và thông tin chăm sóc khách hàng nào thuộc giao dịch đó.
| Chi tiết Orders | Ý nghĩa cần giữ | Hệ quả đối với mô hình dữ liệu |
|---|---|---|
| Số và ngày Orders | Nhận diện giao dịch trước đây | Giữ nhất quán để hỗ trợ và báo cáo. |
| Mặt hàng và options đã mua | Cho biết chính xác khách hàng đã mua gì | Giữ variants/options ở dạng nhân viên và Customers có thể hiểu. |
| Trạng thái và dòng thời gian thanh toán | Hỗ trợ đối chiếu giao dịch | Không coi đây là cấu hình đang hoạt động của nhà cung cấp thanh toán cũ. |
| Shipment và người nhận | Phục vụ lịch sử xử lý và giao hàng | Xác nhận địa chỉ và bối cảnh vận chuyển vẫn hữu ích. |
| Mã giảm giá và quyền lợi | Giải thích kết quả discount | Tách thông tin giao dịch trước đây khỏi cấu hình promotion đang hoạt động. |
| Hoàn tiền, return, đổi hàng | Phục vụ chăm sóc và đối chiếu tài chính | Giữ đủ thông tin để hỗ trợ sau launch. |
| Memos/nhãn Orders | Phục vụ thao tác nội bộ | Xác định ghi chú nào còn hữu ích, nhạy cảm hoặc đã lỗi thời. |
| Sales channel | Cho biết Orders phát sinh từ đâu | Giữ khi nguồn đơn ảnh hưởng đến báo cáo hoặc cách hỗ trợ. |
Mục tiêu không phải biến lịch sử đơn hàng thành các quy trình vận hành đang chạy. Mục tiêu là giữ lại thông tin cần thiết để chăm sóc Customers, duy trì hoạt động hỗ trợ và báo cáo sau khi Cafe24 trở thành môi trường thương mại chính.
Storefront, thiết kế và nội dung cần có ranh giới sở hữu rõ
Cafe24 có Smart Design, Smart Themes, modules, components, Web Components và các tính năng kết nối app. Cửa hàng nguồn có thể chứa Trang Hệ thống quản lý nội dung, nội dung dạng blog, banners, menus, scripts, bố cục trang chi tiết Products và trang khuyến mãi không thể coi như các bản ghi Products hoặc Orders thông thường.
Nội dung phải được phân loại theo người/hệ thống sở hữu và mục đích sử dụng. Một số nội dung có thể được đưa sang dưới dạng Trang Hệ thống quản lý nội dung. Một số nên được dựng lại trong hệ thống thiết kế storefront của Cafe24. Những cách trình bày ở nguồn chỉ tồn tại để khắc phục hạn chế của nền tảng cũ có thể nên được loại bỏ. Scripts và đoạn mã nhúng cần được giao cho một chủ sở hữu rõ trên đích thay vì tự động chèn lại.
| Thành phần nội dung/thiết kế | Cách hiểu khi chuyển đổi | Hướng xử lý phù hợp |
|---|---|---|
| Trang Hệ thống quản lý nội dung | Trang thông tin có giá trị kinh doanh hoặc SEO | Giữ hoặc dựng lại theo chiến lược nội dung hiện tại. |
| Bố cục trang chi tiết Products | Cách trình bày giúp khách hàng ra quyết định mua | Dựng lại có chủ đích nếu phụ thuộc theme/module. |
| Banners và landing pages | Bối cảnh chiến dịch và merchandising | Giữ nội dung có giá trị; không sao chép chiến dịch đã hết mục đích. |
| Menus và điều hướng | Hành trình khách hàng | Xây lại theo kế hoạch điều hướng Cafe24 tương lai. |
| Scripts hoặc embeds | Chức năng tùy chỉnh hoặc tracking | Rà soát tính tương thích, quyền riêng tư và nhu cầu vận hành. |
| Redirects | Duy trì traffic tìm kiếm và chiến dịch | Giữ hoặc redirect những route còn giá trị cho tìm kiếm, chiến dịch hoặc Customers. |
Như vậy, mô hình dữ liệu cũng phải bao gồm ranh giới trình bày. Một file, page hoặc script có thể rất quan trọng nhưng không nhất thiết thuộc phạm vi di chuyển dữ liệu theo cùng cách với Products hay Customers.
App, API, webhooks và hệ thống ngoài quyết định nơi dữ liệu tiếp tục được quản lý
Cafe24 có thể hoạt động cùng app, API, webhooks, analytics, Data Bridge, nhà cung cấp thanh toán, dịch vụ vận chuyển, marketplace và các hệ thống kinh doanh bên ngoài. Những kết nối này quyết định ai/hệ thống nào sở hữu kết quả dữ liệu sau di chuyển dữ liệu. Một bản ghi có thể xuất hiện trong Cafe24 nhưng việc cập nhật, tính giá, xử lý đơn hàng, báo cáo hoặc hiển thị lại do hệ thống khác kiểm soát.
| Thành phần kết nối | Cần xác định | Vì sao làm thay đổi ý nghĩa dữ liệu |
|---|---|---|
| ERP hoặc hệ thống tồn kho | ID Products, nơi quản lý tồn kho, quy tắc kho | Cafe24 có thể hiển thị tồn kho trong khi hệ thống khác mới là nơi cập nhật chính. |
| CRM hoặc marketing | ID Customers, consent, segments, dữ liệu vòng đời | Trường Customers có thể cần đồng bộ liên tục thay vì chỉ di chuyển dữ liệu một lần. |
| Nhà cung cấp thanh toán | Mã giao dịch, trạng thái thanh toán, hoàn tiền | Thông tin thanh toán trước đây khác với cấu hình thanh toán đang hoạt động. |
| Nhà cung cấp vận chuyển | Phí, tracking, xử lý người nhận, trạng thái xử lý đơn hàng | Bản ghi shipment không tái tạo quy trình của nhà cung cấp. |
| Marketplace hoặc sales channel | ID theo channel, quy tắc tồn kho, nguồn Orders | Bối cảnh channel ảnh hưởng đến báo cáo và vận hành. |
| App hoặc webhook tùy chỉnh | Điều kiện kích hoạt, payload sự kiện, ID bên ngoài | Có thể cần phương án tái cấu trúc riêng khi chức năng phải thay đổi cách biểu diễn. |
Bản đồ sở hữu này giúp tránh lỗi phổ biến: đưa giá trị sang đích nhưng bỏ qua hệ thống làm cho giá trị đó luôn chính xác. Một mô hình Cafe24 ổn định phải xác định hệ thống nào chịu trách nhiệm cho từng kết quả dữ liệu quan trọng sau launch.
Ngôn ngữ, thị trường và storefront có thể làm thay đổi ý nghĩa dữ liệu
Cafe24 thường được cân nhắc bởi doanh nghiệp có nhu cầu bán hàng theo khu vực, mục tiêu cross-border, yêu cầu riêng tại Hàn Quốc hoặc mô hình storefront cần phối hợp Products, nội dung, thanh toán, vận chuyển và marketplace. Vì vậy, bối cảnh thị trường là một phần của mô hình dữ liệu. Tên Products, nhãn Categories, trường Customers hoặc trạng thái Orders có thể mang ý nghĩa khác nhau khi được dùng cho bán nội địa, quốc tế, wholesale, đồng bộ marketplace hoặc chăm sóc khách hàng.
Nếu Cửa hàng nguồn có nhiều ngôn ngữ, nhiều thị trường hoặc cách trình bày riêng theo quốc gia, không nên gộp tất cả vào một mô tả Products chung. Một số nội dung phải tiếp tục hiển thị cho khách hàng. Một số chỉ phục vụ vận hành. Một số cần được dựng lại qua cấu hình storefront Cafe24, app, quy trình localization bên ngoài hoặc cấu hình riêng theo từng thị trường.
| Dữ liệu phụ thuộc thị trường | Vì sao cần xử lý kỹ | Dấu hiệu cần xác định trên Cafe24 |
|---|---|---|
| Tên Products bản địa hóa | Ảnh hưởng khả năng tìm kiếm, nhận diện và so sánh Products | Xác định nội dung dịch nằm trong dữ liệu Cafe24, cấu hình storefront hay quy trình localization riêng. |
| Mô tả theo thị trường | Có thể chứa thông tin pháp lý, vận chuyển hoặc nội dung giúp khách hàng ra quyết định | Tách nội dung cần tiếp tục hiển thị khỏi nội dung cũ nên loại bỏ. |
| Tiền tệ hoặc bối cảnh giá | Giá có thể phụ thuộc thị trường, promotion hoặc kênh thanh toán | Xác định hệ thống nào quản lý giá trong mô hình tương lai trước khi đưa các trường liên quan sang. |
| Ghi chú vận chuyển theo khu vực | Khả năng giao hàng không nhất thiết là nội dung Products thông thường | Xác định ghi chú thuộc trang Products, cấu hình vận chuyển hay nội dung chính sách dịch vụ. |
| ID marketplace | ID theo channel có thể rất quan trọng cho vận hành | Chỉ giữ khi còn phục vụ báo cáo, đồng bộ hoặc quy trình dịch vụ trong tương lai. |
Do đó, mô hình dữ liệu Cafe24 phải được đánh giá theo cách cửa hàng tương lai sẽ vận hành. Cùng một trường có thể có giá trị khác nhau tùy trường đó phục vụ Customers, đội ngũ quản trị, tích hợp, đồng bộ marketplace hay báo cáo sau launch.
Thuộc tính tùy chỉnh và ghi chú quản trị phải được hiểu theo mục đích sử dụng
Cafe24 có các tài nguyên liên quan đến thuộc tính tùy chỉnh Products, thuộc tính Customers, memos, labels, nội dung board và thiết lập quản trị. Những vùng dữ liệu này hữu ích khi cửa hàng cần giữ thêm bối cảnh vận hành, nhưng cũng dễ trở thành nơi chứa mọi trường nguồn nếu dữ liệu chưa được phân loại.
Thông tin tùy chỉnh nên được phân loại theo chức năng kinh doanh. Thông số kỹ thuật có thể giúp khách hàng so sánh Products. Trường đăng ký Customers có thể phục vụ đánh giá B2B. Memo Products có thể hữu ích cho nhân viên nhưng không nên hiển thị cho khách hàng. ID cơ sở dữ liệu nguồn có thể chỉ cần thiết khi ERP hoặc CRM vẫn tham chiếu đến ID đó. Trường của một app không còn sử dụng có thể không cần di chuyển dữ liệu.
| Loại dữ liệu tùy chỉnh | Câu hỏi phân loại phù hợp hơn | Hướng xử lý có thể chọn |
|---|---|---|
| Chi tiết Products hiển thị cho khách hàng | Có giúp khách hàng lựa chọn không? | Giữ dưới dạng thông tin Products có cấu trúc hoặc nội dung trang. |
| Ghi chú vận hành chỉ dành cho quản trị | Có giúp nhân viên hỗ trợ, xử lý đơn hàng hoặc báo cáo không? | Chỉ giữ khi còn hữu ích và an toàn. |
| Mã định danh tích hợp | Hệ thống khác còn tham chiếu đến giá trị này không? | Giữ trong trường được kiểm soát hoặc đưa sang bằng phương án tái cấu trúc phù hợp. |
| Cờ dữ liệu của app cũ | Có app/hệ thống nào trên đích tiếp tục sử dụng giá trị không? | Giao cho app/tích hợp tiếp tục sử dụng, chuyển đổi cấu trúc hoặc loại bỏ. |
| Trường đăng ký tùy chỉnh | Có ảnh hưởng tier, phê duyệt hoặc cách phục vụ Customers không? | Đưa sang thuộc tính tài khoản/Customers hoặc rà soát bằng phương án tái cấu trúc riêng. |
Mục tiêu không phải di chuyển dữ liệu được càng nhiều trường càng tốt. Mục tiêu là giữ những thông tin vẫn tạo giá trị kinh doanh trong Cafe24.
Kết luận
Cafe24 làm thay đổi cách dữ liệu cần được hiểu khi Products phụ thuộc vào options và variants, tồn kho do nhiều hệ thống cùng tham gia quản lý, Customers mang bối cảnh tier và đăng ký, Orders chứa thông tin thanh toán và xử lý đơn hàng, các cửa hàng theo ngôn ngữ giữ giá trị khác nhau và app/API sở hữu một phần hoạt động vận hành.
Vì vậy, quyết định trọng tâm không phải số lượng trường nguồn có thể sao chép. Cần xác định tài nguyên nào trong Cafe24 sẽ sở hữu từng giá trị, quan hệ nào phải tiếp tục chính xác, bản ghi nào thực chất thuộc thiết kế storefront hoặc chức năng app và ID nào phải tiếp tục liên kết Cafe24 với hệ thống bên ngoài. Mô hình sở hữu rõ giúp Cửa hàng đích sạch hơn và tránh biến workaround của nền tảng cũ thành dữ liệu tồn tại lâu dài trên hệ thống mới.
Câu hỏi thường gặp
Options và variants của Cafe24 có luôn giống cấu trúc ở Cửa hàng nguồn không?
Không phải lúc nào cũng giống. Cửa hàng nguồn có thể biểu diễn options, variants, attributes, bundled Products và modifiers theo cách khác. Khi lập kế hoạch Cafe24, cần quyết định thành phần nào là lựa chọn có thể mua, thông tin Products có cấu trúc, variant có tồn kho, chức năng app hoặc yêu cầu tái cấu trúc riêng.
Có nên đưa tất cả trường tùy chỉnh ở Cửa hàng nguồn sang Cafe24 không?
Không nên quyết định chỉ dựa trên việc trường đó tồn tại. Cần hiểu chức năng trước: có trường hiển thị cho khách hàng, có trường chỉ phục vụ quản trị, có trường là ID tích hợp và có trường chỉ là workaround cũ không còn giá trị.
Thông tin nào trong Orders quan trọng nhất khi chuyển sang Cafe24?
Cần giữ những thông tin còn cần cho hỗ trợ và báo cáo: mặt hàng đã mua, ý nghĩa options, liên kết Customers, trạng thái thanh toán, bối cảnh vận chuyển, discounts, hoàn tiền, return, đổi hàng và ghi chú nội bộ còn hữu ích.
Dữ liệu thiết kế storefront có thể được xử lý giống dữ liệu di chuyển dữ liệu thông thường không?
Không nên xử lý dữ liệu thiết kế storefront giống dữ liệu di chuyển dữ liệu thông thường. Nội dung storefront, modules thiết kế, scripts, menus, landing pages và cách theme hoạt động cần được tách khỏi Products, Customers và Orders. Một số nội dung có thể di chuyển dữ liệu; phần khác cần thiết kế lại, cấu hình lại hoặc phát triển riêng.
Khi nào dữ liệu Cafe24 cần một quyết định riêng về nơi tiếp tục được quản lý?
Cần quyết định riêng khi giá trị nguồn thuộc app, marketplace, ERP, CRM, WMS, bảng tùy chỉnh hoặc script storefront thay vì bản ghi Products, Customers, Orders hay nội dung thông thường. Chỉ nên giữ giá trị khi có hệ thống đích rõ và mối quan hệ kinh doanh vẫn tiếp tục.
Vì sao ngôn ngữ và thị trường cần được rà soát riêng trong Cafe24?
Cùng một bản ghi Products hoặc cùng một nội dung có thể có tên, giá, trạng thái hiển thị, URL hoặc ý nghĩa vận hành khác theo storefront, ngôn ngữ và thị trường. Việc rà soát từng phạm vi giúp tránh ghi đè nội dung bản địa hóa hoặc dữ liệu theo khu vực bằng một giá trị mặc định duy nhất.