Mô hình dữ liệu Customers và phân khúc khách hàng trên các nền tảng

Dữ liệu Customers không chỉ là danh sách tên và địa chỉ email. Trong cửa hàng thương mại điện tử, dữ liệu này tạo thành hệ thống nhận diện tài khoản, kết nối danh tính, địa chỉ, lịch sử đơn hàng, điều kiện hưởng giá, cách xử lý thuế, trạng thái marketing, thông tin phục vụ hỗ trợ, quan hệ B2B và các quy tắc phân nhóm khách hàng.

Hồ sơ Customers có thể trông đơn giản trong trang quản trị nhưng lại mang nhiều ý nghĩa vận hành. Nền tảng này có thể phân loại Customers bằng nhóm cố định; nền tảng khác dùng tags, thuộc tính Customers, tài khoản công ty, bảng giá, phân khúc, extensions hoặc CRM bên ngoài. Vì vậy, hồ sơ hiển thị đầy đủ chưa đủ để bảo đảm Customers vẫn được nhận diện và áp dụng đúng quyền lợi sau khi chuyển sang nền tảng mới.

Việc rà soát kỹ thuật cần bắt đầu bằng cách xác định mô hình Customers được tổ chức ra sao, doanh nghiệp dùng từng trường cho mục đích gì và hành vi nào do nền tảng trực tiếp xử lý, chức năng nào phụ thuộc vào app, plugin, module hoặc hệ thống bên ngoài.

Dữ liệu Customers giúp cửa hàng nhận diện tài khoản và kết nối thông tin liên quan

Hồ sơ là nơi hiển thị thông tin chính của Customers, nhưng hiếm khi chứa toàn bộ mô hình. Hồ sơ thường xác định cá nhân hoặc tổ chức; các bản ghi liên quan mới quyết định Customers có thể mua hàng như thế nào, nhận Orders ở đâu, được hưởng mức giá nào, nhận thông tin gì và được ghi nhận ra sao trong báo cáo.

Một mô hình Customers thường gồm:

Do đó, chuyển đúng bản ghi hồ sơ mới chỉ hoàn thành một phần. Customers vẫn có thể gặp lỗi đăng nhập, mất quyền hưởng giá, không được phân vào đúng nhóm hoặc không còn liên kết với hệ thống bên ngoài nếu những cấu trúc liên quan chưa được thể hiện đúng trên Nền tảng đích.

Thông tin hồ sơ và dữ liệu đăng nhập là hai cấu trúc khác nhau

Tên, email, điện thoại và địa chỉ có thể được nhập vào nền tảng mới, nhưng mật khẩu, mã băm mật khẩu, trạng thái kích hoạt và phiên đăng nhập thường chịu quy tắc bảo mật riêng. Vì vậy, việc chuyển hồ sơ không đồng nghĩa với việc Customers có thể tiếp tục đăng nhập theo cách cũ.

Các cấu trúc liên quan đến xác thực thường gồm:

• email hoặc tên người dùng dùng để đăng nhập;
• mã băm mật khẩu, salt hoặc định dạng mật khẩu riêng của nền tảng;
• trạng thái kích hoạt tài khoản;
• trạng thái lời mời;
• yêu cầu đặt lại mật khẩu;
• liên kết đăng nhập bằng tài khoản mạng xã hội;
• trạng thái xác thực đa yếu tố;
• trạng thái phê duyệt tài khoản B2B;
• trạng thái bị vô hiệu hóa, khóa hoặc đình chỉ.

Những thông tin này không thể được xử lý như trường hồ sơ thông thường. Dữ liệu mật khẩu thường bị giới hạn bởi quy tắc bảo mật và nhiều nền tảng không cung cấp định dạng có thể tái sử dụng. Vì vậy, ngay cả khi bản ghi Customers được chuyển đầy đủ, Customers cũ vẫn có thể cần nhận lời mời, đặt lại mật khẩu hoặc hoàn tất bước đăng nhập đầu tiên.

Địa chỉ là bản ghi phụ thuộc và ảnh hưởng trực tiếp đến checkout

Địa chỉ thường là các bản ghi gắn với tài khoản Customers. Nền tảng có thể lưu một địa chỉ mặc định, nhiều địa chỉ trong sổ địa chỉ, tách riêng địa chỉ thanh toán và giao hàng hoặc lưu ảnh chụp địa chỉ tại thời điểm tạo Orders.

Bản ghi địa chỉ thường gồm:

• tên đầy đủ;
• tên công ty;
• các dòng địa chỉ;
• thành phố;
• bang, tỉnh hoặc khu vực;
• mã bưu chính;
• mã quốc gia;
• số điện thoại;
• trường địa chỉ liên quan đến thuế;
• trạng thái địa chỉ thanh toán hoặc giao hàng mặc định;
• ID địa chỉ do nền tảng hoặc hệ thống liên quan sử dụng.

Khó khăn nằm ở quy tắc xác thực. Nền tảng nguồn có thể cho phép nhập tên tỉnh tự do, trong khi Nền tảng đích yêu cầu mã tỉnh chuẩn. Nền tảng này bắt buộc số điện thoại để giao hàng, nền tảng khác thì không. Có hệ thống hỗ trợ nhiều địa chỉ đã lưu cho mỗi tài khoản, còn hệ thống khác xử lý địa chỉ checkout gần đây tách biệt với sổ địa chỉ.

Mô hình địa chỉ không chỉ ảnh hưởng đến cách hiển thị mà còn tác động đến tính phí vận chuyển, tính thuế, kiểm tra gian lận, lập hóa đơn, đồng bộ ERP và quy trình hỗ trợ Customers.

Phân khúc quyết định quyền lợi và quy tắc áp dụng cho Customers

Nhóm, tag, phân khúc, loại Customers, vai trò công ty hoặc cấp độ có thể quyết định Customers được xem nội dung nào, hưởng mức giá hoặc quyền lợi nào và nhận thông tin theo điều kiện nào khi duyệt cửa hàng hoặc checkout.

Phân khúc có thể kiểm soát:

• cách xử lý Customers bán lẻ và bán buôn;
• quyền truy cập B2B hoặc tài khoản công ty;
• bảng giá riêng theo Customers;
• giá theo nhóm Customers;
• quyền xem catalog hoặc collections;
• quyền truy cập Products bị hạn chế;
• miễn thuế hoặc xử lý VAT;
• điều kiện nhận khuyến mãi;
• phương thức vận chuyển được phép sử dụng;
• phương thức thanh toán được phép sử dụng;
• cấp độ khách hàng thân thiết hoặc trạng thái phần thưởng;
• trạng thái mua hàng định kỳ, thành viên hoặc phê duyệt;
• lựa chọn đối tượng cho chiến dịch marketing;
• mức ưu tiên hỗ trợ hoặc người phụ trách tài khoản.

Nhãn phân loại và các quyền lợi hoặc quy tắc mà nhãn kích hoạt là hai vấn đề khác nhau. Bản ghi Customers có thể giữ nhãn Wholesale, nhưng nhãn đó không tự tái tạo giá bán buôn, quyền xem catalog, điều khoản thanh toán, xử lý thuế hoặc trạng thái phê duyệt. Nhãn có thể được chuyển như một trường dữ liệu, còn các quyền lợi và quy tắc liên quan phải được xây dựng lại bằng hệ thống giá, catalog, B2B, khuyến mãi hoặc extensions trên Nền tảng đích.

Mỗi nền tảng phân loại Customers theo một mô hình khác nhau

Một số nền tảng dùng nhóm Customers cố định. Một số dùng tags linh hoạt. Một số tính phân khúc động từ quy tắc. Các nền tảng B2B có thể tổ chức Customers thành công ty và người liên hệ. Nhiều cửa hàng khác phụ thuộc vào extensions hoặc hệ thống bên ngoài.

Cần xác định Nền tảng nguồn đang dùng mô hình nào, Nền tảng đích hỗ trợ mô hình nào và trường nào chỉ là nhãn, trường nào đang trực tiếp điều khiển hành vi.

Dữ liệu B2B kết nối Customers với công ty, vai trò và quyền hạn

Dữ liệu B2B thường rộng hơn tài khoản cá nhân. Người mua có thể thuộc công ty, chi nhánh, địa điểm, phòng ban, vai trò, quy trình phê duyệt, quy trình báo giá, điều khoản thanh toán hoặc bảng giá riêng.

Mô hình B2B và bán buôn có thể gồm:

• tài khoản công ty;
• nhiều người mua dưới cùng một công ty;
• vai trò và quyền hạn của người mua;
• địa điểm công ty;
• tài khoản thanh toán;
• giới hạn mua;
• điều khoản thanh toán;
• trường miễn thuế;
• bảng giá đã đàm phán;
• quyền yêu cầu hoặc phê duyệt báo giá;
• trạng thái phê duyệt tài khoản;
• nhân viên bán hàng phụ trách;
• ID Customers trong ERP;
• catalog bị giới hạn hoặc danh mục riêng theo Customers.

Việc nhập một danh sách Customers phẳng không thể thể hiện đầy đủ mô hình này nếu Nền tảng đích yêu cầu bản ghi công ty, phân quyền theo vai trò hoặc quan hệ với bảng giá. Câu hỏi kỹ thuật không chỉ là hồ sơ có thể được nhập hay không, mà còn là các quan hệ B2B có thể được xây dựng lại trên nền tảng mới hay không.

Trạng thái đồng ý nhận thông tin cần được hiểu chính xác

Email, điện thoại và trạng thái đồng ý nhận thông tin không phải dữ liệu liên hệ thông thường. Chúng ảnh hưởng đến cách xây dựng tệp đối tượng, loại trừ khỏi chiến dịch, gửi thông báo giao dịch, đăng ký newsletter và niềm tin của Customers.

Các trường thường gặp gồm:

• địa chỉ email;
• số điện thoại;
• trạng thái đồng ý nhận marketing qua email;
• trạng thái đồng ý nhận SMS;
• trạng thái đăng ký newsletter;
• trạng thái hủy đăng ký hoặc bị loại khỏi danh sách gửi;
• thời điểm ghi nhận sự đồng ý;
• nguồn thu thập sự đồng ý;
• ngôn ngữ hoặc khu vực ưu tiên;
• tags Customers dùng để nhắm đối tượng chiến dịch;
• ID trong nền tảng marketing bên ngoài.

Các nền tảng và hệ thống marketing có thể định nghĩa những trường này khác nhau. Có hệ thống lưu trạng thái newsletter như thuộc tính Customers, hệ thống khác lưu trạng thái đồng ý trong nền tảng marketing. Một hệ thống có thể tách thông báo giao dịch khỏi sự đồng ý nhận nội dung quảng bá. Diễn giải sai có thể khiến chiến dịch nhắm sai đối tượng hoặc làm thay đổi trạng thái nhận thông tin ngoài ý muốn sau khi cửa hàng vận hành.

Lịch sử của Customers thường nằm trong nhiều loại dữ liệu và bản ghi liên quan

Lịch sử đơn hàng, hoàn tiền, trả hàng, Reviews, điểm thưởng, bản ghi mua định kỳ, yêu cầu hỗ trợ và ghi chú CRM có thể thuộc các loại dữ liệu hoặc bản ghi liên quan, tham chiếu đến Customers nhưng không nằm trong chính hồ sơ Customers.

Các quan hệ quan trọng gồm:

• Orders phải tiếp tục liên kết với đúng tài khoản Customers;
• Orders của khách mua không đăng nhập có thể không tự gắn với tài khoản;
• địa chỉ lịch sử có thể được lưu trong Orders thay vì sổ địa chỉ Customers;
• số dư khách hàng thân thiết có thể thuộc hệ thống phần thưởng thay vì bảng Customers của nền tảng;
• trạng thái mua định kỳ có thể do app hoặc nhà cung cấp thanh toán quản lý;
• yêu cầu hỗ trợ và hoạt động CRM có thể dùng ID Customers bên ngoài;
• Reviews có thể tham chiếu email, ID tài khoản, ID Products hoặc ID của hệ thống Reviews.

Vì vậy, hồ sơ Customers có thể được chuyển trong khi bối cảnh phục vụ hỗ trợ và vận hành vẫn bị phân mảnh. Cần xác định những bản ghi nào phải tiếp tục liên kết và những dữ liệu nào nằm ngoài phạm vi Customers tiêu chuẩn.

Phân khúc tĩnh và phân khúc động cần được xử lý khác nhau

Phân loại tĩnh được lưu trực tiếp trên bản ghi Customers bằng nhóm, tag, cấp độ hoặc giá trị trường. Phân khúc động được tính từ quy tắc như số Orders, tổng chi tiêu, vị trí, Products đã mua, ngày mua gần nhất hoặc hành vi marketing.

Phân khúc động có thể phụ thuộc vào:

• lịch sử đơn hàng;
• quan hệ với Products và Categories;
• quốc gia hoặc khu vực trong địa chỉ;
• tags hoặc các trường tùy chỉnh của Customers;
• tổng giá trị mua hàng trong suốt thời gian gắn bó;
• tần suất mua hàng;
• hành vi bỏ giỏ hàng hoặc duyệt cửa hàng;
• trạng thái khách hàng thân thiết hoặc mua định kỳ;
• dữ liệu tương tác marketing.

Khi chuyển nền tảng, phân khúc động có thể không được nhập dưới dạng danh sách cố định. Quy tắc có thể phải được xây dựng lại trên Nền tảng đích hoặc trong hệ thống marketing, CRM hay analytics liên quan. Danh sách tĩnh chỉ giữ trạng thái thành viên tại một thời điểm, còn quy tắc động duy trì cách phân khúc tự cập nhật khi dữ liệu thay đổi.

ID bên ngoài giúp các hệ thống tiếp tục nhận diện đúng Customers

Nhiều cửa hàng dùng mã Customers có ý nghĩa ngoài nền tảng thương mại điện tử. Các mã này kết nối Customers với ERP, CRM, POS, help desk, nền tảng marketing, hệ thống thuế, khách hàng thân thiết hoặc mua định kỳ.

ID bên ngoài có thể gồm:

• mã Customers trong ERP;
• ID liên hệ trong CRM;
• ID Customers trong POS;
• số tài khoản khách hàng thân thiết;
• ID Customers trong hệ thống mua định kỳ;
• mã tham chiếu xác thực thuế hoặc VAT;
• ID người yêu cầu trong hệ thống hỗ trợ;
• ID tài khoản công ty;
• ID người mua trên marketplace;
• ID Customers trên nền tảng cũ.

Mất hoặc gắn sai các ID này có thể làm hỏng đối chiếu dữ liệu, tra cứu hỗ trợ, phân khúc tự động, báo cáo theo tài khoản và quy trình các tích hợp. Cần xác định ID đang được lưu ở đâu và Nền tảng đích có vị trí phù hợp để tiếp tục lưu và sử dụng các ID đó hay không.

Chất lượng dữ liệu Customers phải được kiểm chứng qua cách tài khoản hoạt động

Không thể chỉ dùng số lượng bản ghi để đánh giá kết quả. Câu hỏi quan trọng hơn là từng loại Customers có tiếp tục được xử lý đúng trên Nền tảng đích hay không.

Các tình huống ưu tiên gồm:

Dự án có thể cần liên kết trường nâng cao, chuyển đổi giá trị, điều chỉnh cấu hình hoặc phương án xử lý riêng khi kết quả Customers phụ thuộc vào cấu trúc ngoài tiêu chuẩn. Ví dụ gồm các trường tùy chỉnh, cấu trúc công ty, chức năng tài khoản do extensions quản lý, ID bên ngoài và cách phân khúc riêng. Trọng tâm là các chức năng kinh doanh phải tiếp tục hoạt động đúng, không chỉ là tên trường được chuyển.

Rà soát dữ liệu Customers trước khi di chuyển

Cần đánh giá riêng dữ liệu hồ sơ và cách tài khoản hoạt động.

Trước khi di chuyển, hãy kiểm tra:

• trường hồ sơ nào là bắt buộc trên Nền tảng đích;
• email có duy nhất, bị trùng, bị thiếu hoặc được nhiều người dùng chung hay không;
• điện thoại và địa chỉ có đáp ứng quy tắc xác thực của Nền tảng đích hay không;
• nhóm, tags, cấp độ hoặc phân khúc nào đang điều khiển hành vi;
• phân khúc được lưu cố định, tính từ quy tắc hay do extensions quản lý;
• Customers nào phụ thuộc vào cấu trúc công ty B2B hoặc quy tắc bán buôn;
• trường nào có sẵn trên nền tảng và trường nào là các trường tùy chỉnh hoặc do extensions quản lý;
• ID bên ngoài nào phải tiếp tục sử dụng sau khi chính thức vận hành;
• trường đồng ý nhận marketing đã có ý nghĩa rõ ràng hay chưa;
• Orders, Reviews, chương trình khách hàng thân thiết, mua định kỳ hoặc bản ghi hỗ trợ nào phải tiếp tục liên kết;
• loại Customers nào cần được đưa vào kiểm thử trên mẫu đại diện.

Mẫu kiểm thử nên gồm tài khoản bán lẻ thông thường, Customers có nhiều địa chỉ, tài khoản bán buôn hoặc B2B, Customers được miễn thuế, người đã đăng ký nhận marketing, Customers có ID bên ngoài và tài khoản phụ thuộc vào app, plugin, module hoặc hệ thống bên ngoài.

Kết luận

Mô hình dữ liệu Customers quyết định cách nền tảng nhận diện cá nhân, công ty, quyền hạn, địa chỉ, lựa chọn liên lạc, điều kiện hưởng giá và các quan hệ khách hàng. Hồ sơ hiển thị chỉ là điểm bắt đầu. Công việc kỹ thuật quan trọng hơn là xác định trường nào lưu danh tính, trường nào điều khiển hành vi, phân loại nào được tính từ quy tắc và ý nghĩa nào thuộc về extensions hoặc hệ thống bên ngoài.

Việc rà soát phải xác nhận các tình huống tài khoản quan trọng vẫn hoạt động sau khi chuyển nền tảng. Các bản ghi Customers cũ cần được nhận diện; địa chỉ tiếp tục sử dụng được; quan hệ B2B hoặc bán buôn được thể hiện đúng; trạng thái đồng ý nhận thông tin được diễn giải cẩn thận; ID bên ngoài giữ đúng liên kết. Khi hành vi phụ thuộc vào các trường tùy chỉnh, quy tắc phân khúc, cấu trúc tài khoản công ty hoặc ID bên ngoài, cần xác định quan hệ trường trực tiếp đã đủ hay phải chuyển đổi dữ liệu, cấu hình Nền tảng đích hoặc thiết kế xử lý riêng.

Câu hỏi thường gặp

Chuyển hồ sơ Customers có đồng nghĩa với việc duy trì khả năng đăng nhập không?

Chuyển hồ sơ Customers không đồng nghĩa với việc duy trì khả năng đăng nhập. Hồ sơ và dữ liệu xác thực là hai cấu trúc khác nhau. Tên, email, điện thoại và địa chỉ có thể được chuyển, trong khi mật khẩu, trạng thái kích hoạt hoặc quy trình đăng nhập lần đầu phải tuân theo quy tắc bảo mật của Nền tảng đích.

Vì sao nhóm hoặc tags Customers đã được chuyển nhưng quyền lợi hoặc cách tài khoản hoạt động vẫn khác?

Nhóm hoặc tag thường chỉ là nhãn phân loại. Giá, quyền xem catalog, thuế, khuyến mãi và quyền truy cập B2B có thể do quy tắc nền tảng, bảng giá, app, plugin, module hoặc hệ thống bên ngoài xử lý.

Phân khúc tĩnh khác phân khúc động như thế nào?

Phân khúc tĩnh được lưu trực tiếp trên bản ghi Customers bằng nhóm, tag, cấp độ hoặc trường. Phân khúc động được tính từ quy tắc như lịch sử đơn hàng, mức chi tiêu, vị trí, Products đã mua hoặc hành vi marketing. Quy tắc động thường phải được xây dựng lại thay vì nhập như một danh sách thành viên cố định.

Vì sao ID Customers bên ngoài quan trọng?

ID bên ngoài kết nối Customers với ERP, CRM, POS, hệ thống khách hàng thân thiết, mua định kỳ, marketing, thuế và hỗ trợ. Nếu ID bị mất hoặc thay đổi không có kế hoạch, các hệ thống liên quan có thể không còn đối chiếu đúng Customers sau khi chuyển nền tảng.

Nên ưu tiên kiểm thử những Customers nào?

Hãy ưu tiên tài khoản mang nhiều ý nghĩa vận hành: người mua quay lại, Customers có nhiều địa chỉ, tài khoản bán buôn hoặc B2B, Customers được miễn thuế, người đăng ký nhận marketing, Customers có ID bên ngoài và tài khoản gắn với chương trình khách hàng thân thiết, mua định kỳ, thành viên hoặc quy trình phê duyệt.