Data model in CDP
CDP (Customer Data Platform) cần một data model vững mạnh vì bản chất của CDP không chỉ là lưu trữ dữ liệu khách hàng, mà còn phải tổ chức, kết nối và kích hoạt dữ liệu này ở nhiều kênh khác nhau, theo thời gian thực (real-time) hoặc gần thời gian thực (near real-time).
Thực trạng hiện tại
Đúng là ở nhiều CDP hiện nay (đặc biệt các nền tảng SaaS CDP phổ biến như Segment, mParticle, Rudderstack…), data model vẫn bị giới hạn mạnh ở hai khối chính:
- User Profile (thông tin khách hàng) – thuộc tính tĩnh hoặc bán tĩnh (name, email, phone, segment, loyalty tier…).
- User Event (hành vi khách hàng) – các event time-series như purchase, page view, login, product search…
Và đây chính là lý do khiến nhiều doanh nghiệp thấy “stuck” khi muốn mô hình hóa dữ liệu phức tạp hơn, hệ quả là:
- Không mô hình hóa tốt các dữ liệu khác như sản phẩm (Product), chuyến bay (Booking), tài khoản ngân hàng (Banking Account), thể tín dụng (Card)…
- Khó track các dữ liệu không liên quan trực tiếp đến người dùng, ví dụ: trạng thái chuyến bay, inventory, trạng thái máy móc…
- Không biểu diễn được các tình huống như: một booking chứa nhiều hành khách, một khách hàng sở hữu nhiều tài khoản ngân hàng hoặc nhiều thẻ tín dụng, một khách hàng có nhiều hợp đồng bảo hiểm…
- Dữ liệu vận hành (operational data) không được tích hợp mượt mà, phải đẩy vào data warehouse
Vì sao lại như thế
Lịch sử thiết kế CDP: Phải nói rằng CDP là nền tảng được initialize từ Marketing Platform chứ không phải từ Data Platform, các CDP đời đầu (BlueConic, Segment…) xuất phát từ web/app analytics → tập trung vào tracking user và hành vi, không phải mô hình dữ liệu nghiệp vụ.
Ưu tiên real-time marketing hơn là data modeling: Việc xử lý segmentation, personalization real-time dễ hơn khi schema đơn giản (user + event).
Khó đồng bộ với nguồn dữ liệu quan hệ – relational database: CRM/ERP/Data Warehouse thường có schema phức tạp, trong khi CDP tối ưu cho schema phẳng, sử dụng một bảng dữ liệu để lưu trữ toàn bộ dữ liệu cho user.
Hạn chế chi phí và performance: Lưu multi-entity & relation phức tạp tốn tài nguyên, tăng độ trễ.
Khả năng mở rộng hiện nay
Một số CDP mới hoặc CDP có xu hướng hybrid đang cố gắng thoát khỏi “user + event lock-in”:
- Hỗ trợ thuộc tính phức tạp: cụ thể là vẫn chỉ có một bảng dữ liệu khách hàng dạng phẳng, tuy nhiên hỗ trợ việc thêm thuộc tính khách hàng dạng đối tượng (object) hoặc mảng đối tượng (array of object). Nhưng việc sử dụng dữ liệu này để tạo phân khúc khách hàng hoặc để cá nhân hóa trong nội dung tin nhắn gửi ra vẫn còn là vấn đề vì cách thức cập nhật và lấy đúng dữ liệu trong đối tượng hoặc trong mảng đối tượng không đơn giản.
- Hỗ trợ các bảng dữ liệu cố định: Hỗ trợ tạo trước các bảng dữ liệu(Product, Order) và xây dựng sẳn mối quan hệ giữa chúng và bảng thông tin khách hàng. Và giới hạn những bảng dữ liệu này thôi.
- Hỗ trợ tạo bảng dữ liệu mới: Hỗ trợ tạo được bảng dữ liệu mới (custom object) để lưu thông tin khác có liên quan đến khách hàng. Tuy nhiên rất ít nền tảng làm được điều này và số lượng có thể nói là trên đầu ngón tay (Enteprise CDP như Salesforce Data Cloud, Oracle Unity)
- Hỗ trợ kết nối và sync với cloud data warehouse: Đây là cách làm dễ hơn, phù hợp với xu hướng và chiến lược zero-copy data hiện nay, cho phép truy vấn dữ liệu khác từ cloud data warehouse khi cần thiết phục vụ khi có nhu cầu (Hybrid CDP). Tuy nhiên bạn phải lưu ý đến vấn đề hiệu suất truy vấn và thời gian truy vấn dữ liệu cũng như là tính tức thời của dữ liệu.
Data Model trong Unito
Việc đi theo xu hướng để đáp ứng như cầu thực tiển là không thể tránh khỏi, với việc sử dụng Unito thì chúng tôi đề xuất các giải pháp:
- Nhu cầu dữ liệu đơn giản: sử dụng một bảng dữ liệu khách hàng và tạo thêm các thuộc tính tùy chọn là có thể đáp ứng được nghiệp vụ.
- Khách hàng phức tạp: Có thể sử dụng phương pháp tạo thuộc tính đối tượng hoặc mảng đối tượng nếu như không cần quá phức tạp. Hoặc thậm chí có thể tạo bảng dữ liệu mới để lưu trữ thông tin khác mà có mối quan hệ với khách hàng. Tuy nhiên việc sử dụng các dữ liệu này cho việc phân khúc khách hàng (segmentation) và cá nhân hóa dữ liệu (personalization) đều được hỗ trợ thông qua Journey Builder có xây dựng sẳn phương thức lấy dữ liệu một cách dễ dàng.