Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Mô hình cơ sở dữ liệu cho thương mại điện tử Phần 1:Bản tin

Nói chung, mọi người không thích nhận những e-mail không mong muốn. Tuy nhiên, đôi khi họ đăng ký nhận bản tin để được giảm giá hoặc để cập nhật các sản phẩm mới. Bài viết này sẽ trình bày một cách tiếp cận để thiết kế cơ sở dữ liệu bản tin.

Tại sao lại lo lắng về email bản tin?

Người đăng ký nhận bản tin đại diện cho một nhóm khách hàng cực kỳ có giá trị - họ quan tâm đến sản phẩm của chúng tôi, họ tin tưởng chúng tôi và họ dành thời gian xem xét các ưu đãi và khuyến mại của chúng tôi. Hơn nữa, gửi email cho khách hàng là một trong những công cụ rẻ nhất trong tiếp thị trực tuyến. Tuy nhiên, nó cần được thực hiện cẩn thận - dữ liệu phải được cập nhật hàng ngày (vì mọi người đăng ký và hủy đăng ký) và có chất lượng cao (chúng tôi không muốn gửi những email không mong muốn, vì nó ảnh hưởng tiêu cực đến hình ảnh thương hiệu).

Vì vậy, câu hỏi đặt ra là làm thế nào để quản lý quá trình lấy dữ liệu chất lượng và cập nhật nó hàng ngày. Có rất nhiều lựa chọn ...

Và người chiến thắng là ...

Phân tích khách hàng! Ngày nay, yếu tố quan trọng nhất để dẫn đầu đối thủ là tìm kiếm thông tin chi tiết từ dữ liệu và đưa ra quyết định kinh doanh trên cơ sở đó. Sẽ không tuyệt vời khi xem qua lịch sử của các lần gửi bản tin và phân tích cường độ và hiệu quả của chúng phải không? Đối với từng khách hàng? Và sau đó kết hợp nó với dữ liệu mua hàng, khám phá sở thích của khách hàng, chuẩn bị các đề xuất cá nhân và gửi những đề xuất này bằng cách sử dụng e-mail được cá nhân hóa?

Cách tiếp cận như vậy chắc chắn sẽ làm tăng tỷ lệ chuyển đổi (CR) của chúng tôi. Tỷ lệ chuyển đổi là một trong những chỉ số hiệu suất chính tiếp thị trực tuyến quan trọng nhất; nó cho biết có bao nhiêu người mua hàng sau khi xem một số tài liệu quảng cáo của chúng tôi (quảng cáo, bản tin, v.v.). CR cao đồng nghĩa với việc tăng hiệu quả kinh doanh.

Bây giờ chúng ta đã hiểu một số hoạt động tiếp thị liên quan, hãy đi vào mô hình dữ liệu!

Hãy bắt đầu tạo mô hình cơ sở dữ liệu bản tin!

Tìm hiểu kỹ hơn, chúng ta thấy rằng hai bảng chính trong mô hình là clientnewsletter bảng.

Vì chúng tôi chủ yếu quan tâm đến phân tích khách hàng, client bảng phải ở giữa mô hình. Trong bảng này, mỗi khách hàng có id duy nhất của riêng họ . Chúng tôi cũng sẽ lưu trữ thông tin như first_name của khách hàng và last_name , thông tin liên hệ (email , phone_number , địa chỉ đường phố), birthday , create_date (khi hồ sơ của khách hàng được nhập vào cơ sở dữ liệu) và source_id của họ - tức là họ đã đăng ký trên trang web của chúng tôi hay đối tác kinh doanh nào đó đã cung cấp cho chúng tôi dữ liệu của họ.

newsletter bảng lưu trữ dữ liệu liên quan đến mọi tạo bản tin. Bản tin có thể được xác định dựa trên id duy nhất của chúng . Mỗi cái được mô tả bằng một name (ví dụ:“Bộ sưu tập quần áo mới của phụ nữ - Thu 2016”), email subject (“Những bộ quần áo thời trang nhất cho cô ấy - hãy mua ngay!”), html_file (tệp chứa mã HTML cho bản tin cụ thể đó), loại bản tin type (ví dụ:“bộ sưu tập mới”, “bản tin sinh nhật”) và create_date .

Đồng ý tiếp thị

Để gửi thông tin tiếp thị (qua bưu điện, điện thoại, email hoặc SMS), một công ty cần được sự đồng ý của khách hàng. Trong mô hình của chúng tôi, sự đồng ý được lưu trữ trong một bảng riêng có tên marketing_consent . Nó lưu giữ thông tin về tập hợp các đồng ý tiếp thị hiện tại cho tất cả các khách hàng của chúng tôi. Sự đồng ý được mã hóa dưới dạng biến boolean - TRUE (đồng ý với truyền thông tiếp thị) hoặc FALSE (không đồng ý).

Việc lưu trữ thông tin về thời điểm khách hàng đồng ý nhận quảng cáo qua từng kênh truyền thông là rất quan trọng. Việc ghi lại cũng có lợi khi họ rút lại sự đồng ý đối với mỗi kênh. Đối với các mục đích như vậy, consent_change bảng đã được thiết kế.

Mỗi thay đổi có một id duy nhất và được chỉ định cho một ứng dụng khách cụ thể bởi client_id của họ . Khi khách hàng yêu cầu xóa khỏi email bản tin, bản tin id từ channel bảng cũng sẽ được lưu trữ trong consent_change channel_id của bảng thuộc tính. new_consent thuộc tính là một giá trị boolean (TRUE hoặc FALSE) và đại diện cho các đồng ý tiếp thị mới.

update_date cột ghi ngày khách hàng yêu cầu thay đổi. Cấu trúc này cho phép chúng tôi trích xuất một tập hợp các đồng ý cho tất cả các khách hàng vào một ngày nhất định. Nó cực kỳ hữu ích nếu khách hàng phàn nàn về việc nhận được e-mail sau khi họ đã hủy đăng ký nhận bản tin của chúng tôi. Với thông tin này trong hồ sơ, chúng tôi có thể kiểm tra thời điểm hủy đăng ký diễn ra và hy vọng xác nhận rằng việc này đã được thực hiện sau khi bản tin email được gửi.

Giữ trật tự gửi đi

Thiết kế một mô hình cơ sở dữ liệu hoàn hảo cho việc gửi bản tin không phải là một miếng bánh. Tại sao? Rõ ràng là chúng ta cần phải xác định được bất kỳ quá trình tạo bản tin đơn lẻ nào (nghĩa là bố cục, đồ họa, sản phẩm, liên kết, v.v.). Chúng tôi cũng biết rằng một sáng tạo có thể được gửi nhiều lần:người quản lý có thể quyết định rằng một nhóm e-mail sẽ được gửi vào buổi sáng cho một nửa khách hàng và vào buổi tối cho nửa còn lại. Vì vậy, điều quan trọng là phải ghi lại những khách hàng nào đã nhận được bản tin nào và khi nào. Đây là lý do tại sao phần này của mô hình bao gồm ba bảng:

  • newsletter bảng - mà chúng tôi đã mô tả trước đó.
  • newsletter_sendout bảng - xác định một lần gửi đi. Ví dụ:bản tin Giáng sinh ( id =“2512”) đã được gửi qua email vào 6 giờ chiều ngày 10 tháng 12 Việc lưu trữ hồ sơ này cho phép các nhà tiếp thị gửi cùng một bản tin đến các nhóm khách hàng riêng biệt vào những thời điểm khác nhau.
  • sendout_receivers bảng - thu thập dữ liệu về người nhận của mỗi lần gửi. Sẽ có một bản ghi cho mỗi email từ mỗi lần gửi đi. Mỗi hàng có ba cột:id (xác định sự kiện gửi email đến máy khách), client_id (xác định khách hàng từ cơ sở dữ liệu của chúng tôi) và nl_sendout_id (xác định một bản tin gửi đi).

Đây là Mô hình Bản tin Hoàn chỉnh:




Bất kỳ ý tưởng nào về cách cải thiện mô hình này?

Một cách khả thi là thêm response bàn. Điều này sẽ lưu trữ phản ứng của khách hàng - cho dù họ đã mở e-mail, nhấp vào quảng cáo hay không bao giờ nhìn thấy tin nhắn vì nó bị đánh dấu là spam. Chúng ta nên thêm response bảng cho mô hình của chúng tôi và mối quan hệ nào nên được áp dụng? Chia sẻ suy nghĩ của bạn trong phần bình luận bên dưới.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL GIỮA-Các mẹo thông minh để quét tìm một loạt các giá trị

  2. Cách di chuyển cơ sở dữ liệu vào máy chủ người bán lại của bạn

  3. Cách chọn hàng đầu tiên trong mỗi nhóm theo nhóm

  4. Cách đếm số hàng trong bảng trong SQL

  5. Cách nhóm theo năm trong SQL