Mười ngàn từ thông tin thực tế về những điều cốt yếu của hoạt động tinh vi trong thương mại điện tử - công cụ ra quyết định thực địa (Phần 2)

Trong hoạt động tinh vi của thương mại điện tử, công cụ quyết định thực địa là công cụ quan trọng để đạt được hoạt động tiếp thị chính xác và hiệu quả. Là bài viết thứ hai trong loạt bài viết dài 10.000 từ thiết yếu cho hoạt động thương mại điện tử tinh vi, bài viết này phân tích sâu các mô-đun cốt lõi của công cụ ra quyết định thực địa và cung cấp giải pháp cho các vấn đề thường gặp để bạn tham khảo.

Bài viết trên mô tả kiến ​​trúc hệ thống, quy trình kinh doanh và thiết kế mô-đun nhãn của các công cụ vận hành tinh vi của thương mại điện tử, công cụ hỗ trợ ra quyết định thực địa. Bài viết này tiếp tục phân tích, mô tả hệ thống quy tắc, hệ thống chiến lược, hệ thống thể hiện, cây chiến lược và các vấn đề thường gặp.

6. Hệ thống quy tắc

1. Vòng đời của quy tắc

Các quy tắc, giống như nhãn, có vòng đời.

Khi một quy tắc được tạo, nó sẽ ở trạng thái bản nháp. Sau khi vượt qua bài kiểm tra và được phát hành trực tuyến, nó sẽ có hiệu lực. Nhưng khi được công bố trực tuyến, có hai phiên bản quy tắc, một bản dự thảo và một bản trực tuyến.

Để chuẩn hóa việc quản lý phiên bản quy tắc, nếu các quy tắc tiếp theo cần được chỉnh sửa, phiên bản dự thảo sẽ được chỉnh sửa, sau đó được thử nghiệm và phát hành trực tuyến, phiên bản trực tuyến sẽ được cập nhật, v.v. Điều này cũng đảm bảo rằng các quy tắc sẽ không ảnh hưởng đến việc thực hiện trực tuyến trong quá trình chỉnh sửa.

Do đó, sau khi các quy tắc được công bố và đưa lên trực tuyến, sẽ có hai phiên bản được tạo ra - phiên bản dự thảo và phiên bản trực tuyến. Mỗi lần chỉnh sửa là một lần chỉnh sửa bản nháp và mỗi lần chạy là một lần thực thi phiên bản trực tuyến.

Sau khi các quy tắc được đưa lên mạng, nếu chúng tôi phát hiện ra vấn đề với các quy tắc, chúng tôi có thể vô hiệu hóa các quy tắc đó.

Tại sao lại vô hiệu hóa thay vì xóa?

Trước hết, dựa trên các cân nhắc về bảo mật hệ thống, về cơ bản chúng tôi không sử dụng các hoạt động có rủi ro cao như xóa. Ngay cả khi chúng ta xóa thì đó cũng chỉ là xóa theo logic chứ không phải xóa theo nghĩa vật lý.

Thứ hai, một số quy tắc đã được sử dụng trong các chiến lược và các chiến lược đã được đưa vào quy trình của người dùng. Nếu các quy định bị xóa bỏ một cách vội vàng, tác động sẽ khó đánh giá và rủi ro sẽ lớn hơn.

Do đó, nếu bạn thấy một quy tắc có lỗi, bạn có thể vô hiệu hóa quy tắc đó. Vô hiệu hóa một quy tắc có nghĩa là bạn không thể sử dụng quy tắc đó khi tạo chính sách sau này. Tuy nhiên, nếu quy tắc đã được sử dụng và có hiệu lực, bạn vẫn có thể sử dụng quy tắc đó để thi hành phán quyết và nó sẽ không bị ảnh hưởng. Nếu bạn muốn áp dụng hoàn toàn các quy tắc ngoại tuyến, bạn có thể áp dụng tất cả các chiến lược tương ứng ngoại tuyến.

Nếu có vô hiệu hóa thì phải có kích hoạt. Bật có nghĩa là quy tắc khả dụng. Bạn có thể chọn sử dụng quy tắc này khi tạo chính sách.

2. Loại quy tắc

Tương ứng với loại thẻ, quy tắc cũng có loại quy tắc.

Các loại quy tắc khác nhau có yêu cầu đầu vào khác nhau khi đưa ra quyết định. Ví dụ, quy tắc người dùng đưa ra quyết định dựa trên uid, trong khi quy tắc sản phẩm đưa ra quyết định dựa trên skuid, nghĩa là có sự khác biệt về tham số đầu vào và quyết định.

Các loại quy tắc tương ứng với các loại thẻ từng cái một

• Quy tắc người dùng: Bạn có thể chọn thẻ người dùng để cấu hình và đưa ra quyết định dựa trên uid
• Quy tắc sản phẩm: Bạn có thể chọn thẻ sản phẩm để cấu hình và đưa ra quyết định dựa trên skuid
• Quy tắc đặt hàng: Bạn có thể chọn thẻ đặt hàng để cấu hình và đưa ra quyết định dựa trên orderid
• Quy tắc tùy chỉnh: Bạn có thể chọn thẻ tùy chỉnh để cấu hình và cấu hình các quy tắc quyết định dựa trên các trường thẻ trong suốt

Khi cấu hình quy tắc, thực chất bạn đang cấu hình một biểu thức: nhãn + toán tử + giá trị.

Ví dụ, tuổi của người dùng lớn hơn 29. Tuổi của người dùng là nhãn, toán tử lớn hơn và giá trị là 29. Logic quyết định là trích xuất giá trị nhãn tuổi thực của người dùng thông qua uid. Ví dụ, có một người dùng 1 có tuổi là 30. Nếu 30 lớn hơn 29, trả về true, nếu không trả về false.

Do đó, khi cấu hình quy tắc, trước tiên bạn phải chọn thẻ bạn muốn sử dụng. Các loại quy tắc khác nhau hỗ trợ việc lựa chọn các loại thẻ khác nhau. Ví dụ: quy tắc người dùng chỉ có thể chọn thẻ người dùng.

Sau khi chọn nhãn, bạn có thể xác định loại trường, chẳng hạn như liệt kê, văn bản, số, v.v. Loại trường xác định các toán tử tùy chọn và tương tác nhập giá trị. Ví dụ, phép liệt kê có thể chọn bao gồm/không bao gồm, văn bản có thể chọn bằng/không bằng và số có thể chọn lớn hơn/nhỏ hơn.

Do đó, bước tiếp theo là chọn toán tử và nhập giá trị tương ứng.

Tuy nhiên, trong một số trường hợp, biểu thức của quy tắc phức tạp hơn và cần bao gồm nhiều biểu thức, các biểu thức này cũng cần được kết nối bằng các toán tử. Các toán tử phổ biến nhất là và và hoặc. Và điều đó có nghĩa là biểu thức 1 và biểu thức 2 cần phải được thỏa mãn cùng một lúc. Hoặc có nghĩa là bất kỳ biểu thức nào trong số 1 và 2 đều có thể được thỏa mãn.

Chúng ta đều đã học các biểu thức logic cơ bản trong môn toán ở trường trung học cơ sở và trung học phổ thông. Phần đối lập của A và B không phải là A hoặc không phải là B, nghĩa là bạn có thể chọn (nhãn 1 chứa a) và (nhãn 2 chứa b). Nếu bạn muốn ngược lại, đó sẽ là cấu hình (nhãn 1 không chứa a) hoặc (nhãn 2 không chứa b).

Do đó, và và hoặc có thể giải quyết hơn 99% các cấu hình quan hệ đa biểu thức hàng ngày.

3. Kiểm tra quy tắc

Sau khi quy tắc được tạo, nó cũng cần phải vượt qua bài kiểm tra trước khi có thể trực tuyến. Điều này nhằm đảm bảo tính chính xác của cấu hình quy tắc và tránh lỗi cấu hình khi trực tuyến, có thể khiến nhân viên kinh doanh sử dụng sai các quy tắc khi tạo chính sách. Hơn nữa, thẩm quyền lập ra các quy tắc được mở cho nhân viên kinh doanh. Mọi nhân viên kinh doanh đều có thể tạo ra các quy tắc, do đó rủi ro sẽ cao hơn.

Kiểm tra chủ yếu là nhập các tham số đầu vào và quan sát xem các tham số đầu ra có đáp ứng được kỳ vọng hay không.

Ví dụ, đối với quy tắc yêu cầu độ tuổi của người dùng lớn hơn 29, bạn cần nhập uid và quan sát giá trị đầu ra của quy tắc. Giá trị đầu ra của quy tắc chỉ có có và không. Giả sử tuổi của người dùng là 30, thì giá trị đầu ra của quy tắc cần phải là "có", phù hợp với kỳ vọng. Nếu câu trả lời là “không” thì nó không đáp ứng được kỳ vọng.

Lưu ý rằng đối với các quy tắc tùy chỉnh, vì giá trị nhãn được truyền đi một cách minh bạch nên tham số đầu vào là nhãn tùy chỉnh được quy tắc chọn.

Đồng thời, như đã đề cập ở trên, sau khi các quy tắc được ban hành và triển khai, tất cả nhân viên kinh doanh đều có thể sử dụng các quy tắc đó để cấu hình chính sách, đây là cách tiếp cận có rủi ro cao. Để tránh rủi ro này, chúng ta cũng có thể thực hiện kiểm soát quyền ở cấp quy tắc.

Nếu là quy tắc công khai, thì sau khi người dùng tạo ra, tất cả nhân viên kinh doanh có thể chọn cấu hình chính sách; nhưng nếu đó là quy tắc riêng tư, thì sau khi người dùng tạo ra, nó chỉ có thể được sử dụng khi người dùng tự cấu hình chính sách.

Chúng ta chỉ cần kiểm soát quyền cấu hình của các quy tắc công khai, điều này có thể giảm hiệu quả tác động của các lỗi cấu hình quy tắc thường gặp.

4. Áp dụng các quy tắc

Khi một quy tắc được tạo và phát hành trực tuyến, nó có thể được lựa chọn và sử dụng bởi bất kỳ chiến lược nào. Theo quan điểm quy tắc, anh ta cần biết mình đang sử dụng chiến lược nào.

Như đã đề cập ở trên, sau khi một quy tắc bị vô hiệu hóa, chính sách đã sử dụng quy tắc đó sẽ không tự động ngoại tuyến và cần được xử lý thủ công. Vì vậy, ở đây chúng ta cần biết quy tắc này liên quan đến trường hợp nào để biết phải xử lý như thế nào.

Do đó, việc biết các quy tắc được áp dụng trong chính sách nào sẽ tạo điều kiện thuận lợi cho các lần kiểm tra tiếp theo sau khi điều chỉnh các quy tắc. Nếu các quy tắc thay đổi, phạm vi của các chính sách bị ảnh hưởng có thể được xác nhận và các chính sách cần điều chỉnh có thể được điều chỉnh nhanh chóng.

7. Hệ thống chiến lược

1. Vòng đời chính sách

Chính sách, giống như thẻ và quy tắc, đều có vòng đời.

Khi chính sách được tạo ra, nó sẽ ở trạng thái dự thảo. Sau khi lưu, một bản nháp sẽ được tạo ra. Vào thời điểm này, chiến lược có thể dần được đưa lên mạng.

Tuy nhiên, để xác minh tốt hơn tính chính xác của việc thực hiện chính sách, chính sách cũng phân biệt giữa các phiên bản trước khi phát hành và phiên bản thang độ xám. Chúng tương ứng với môi trường trước khi phát hành và môi trường thang độ xám.

Khi một chính sách được công bố lên phiên bản tiền phát hành, bạn có thể trải nghiệm chính sách đó trong môi trường tiền phát hành để xác minh tính chính xác của chính sách.

Cuối cùng, chiến lược này đã được công bố trực tuyến và có phiên bản trực tuyến. Trong quá trình này, tổng cộng đã có phiên bản dự thảo, phiên bản tiền phát hành, phiên bản thang độ xám và phiên bản trực tuyến được tạo ra.

Để chuẩn hóa việc quản lý phiên bản chiến lược, nếu chiến lược cần được chỉnh sửa sau này, phiên bản dự thảo sẽ được chỉnh sửa, sau đó phát hành trước khi phát hành, phát hành thành dạng xám, phát hành trực tuyến, ghi đè lên phiên bản đã cập nhật, v.v. Điều này cũng đảm bảo rằng chính sách sẽ không ảnh hưởng đến việc thực hiện trực tuyến trong quá trình biên tập và xuất bản.

Sau khi chính sách được công bố trực tuyến, nó sẽ được kích hoạt. Nếu bạn cần đưa chính sách ngoại tuyến, bạn có thể trực tiếp vô hiệu hóa chính sách đó, tương đương với việc khiến chính sách đó không hợp lệ trong mọi môi trường.

Điều quan trọng cần lưu ý là chính sách khác với quy tắc và nhãn ở chỗ chúng có thời hạn hiệu lực. Vì nhãn và quy tắc tồn tại và được sử dụng trong thời gian dài nên không cần thiết phải đặt thời hạn hiệu lực. Các chiến lược được thực hiện theo từng giai đoạn. Bạn có thể muốn hoạt động theo cách này vào tháng 1 và tiếp thị theo cách khác vào tháng 2. Do đó, chiến lược phải có ngày hết hạn.

Nếu chính sách còn trong thời hạn hiệu lực, nó sẽ ở trạng thái trực tuyến và bạn cũng có thể trực tiếp thao tác để vô hiệu hóa nó khi ngoại tuyến. Tuy nhiên, khi chính sách hết hạn, nó sẽ tự động bị vô hiệu hóa và không thể vận hành trực tuyến nữa.

2. Cấu hình chính sách

Cấu hình của chính sách bao gồm thời hạn hiệu lực, quy tắc lựa chọn và nội dung quyết định.

Nói một cách đơn giản, khi tạo chính sách, trước tiên bạn cần điền thông tin cơ bản, bao gồm tên chính sách, thời hạn hiệu lực của chính sách, v.v.

Tiếp theo, bạn cần chọn các quy tắc, bao gồm quy tắc người dùng, quy tắc sản phẩm, v.v. Các loại quy tắc có thể được chọn ở đây phụ thuộc vào các loại quy tắc được hỗ trợ bởi phiên bản kịch bản. Đây không phải là nơi bạn có thể lựa chọn hoặc ủng hộ bất cứ điều gì một cách ngẫu nhiên. Nếu trường hợp kịch bản hỗ trợ loại quy tắc này, nó phải có các tham số đầu vào tương ứng khi được kết nối với công cụ quyết định trường. Ví dụ, khi bạn muốn cấu hình chiến lược trong một tình huống cụ thể, bạn có thể chọn quy tắc sản phẩm, nhưng nếu không có SKUid sản phẩm nào để nhập để ra quyết định, thì chắc chắn chiến lược sẽ không hiệu quả.

Sau khi chọn quy tắc, bạn cần điền nội dung quyết định cuối cùng. Mỗi trường hợp kịch bản khác nhau có nội dung quyết định khác nhau. Ví dụ, nội dung quyết định của một kịch bản khuyến mại có thể là một ưu đãi khuyến mại cụ thể và nội dung quyết định của một kịch bản thanh toán theo đợt có thể là một phạm vi danh sách các số đợt thanh toán.

Nếu chiến lược này vẫn cần được thử nghiệm thì cần phải sử dụng khả năng thử nghiệm AB.

Sau khi cấu hình các quy tắc cơ bản và nội dung quyết định, để tiến hành thử nghiệm AB, bạn cần cấu hình một thí nghiệm AB, bao gồm thời hạn hiệu lực của thí nghiệm, tỷ lệ giữa nhóm đối chứng và nhóm thực nghiệm, cũng như nội dung quyết định tương ứng của nhóm đối chứng và nhóm thực nghiệm.

Các mục nội dung quyết định có thể cấu hình và phạm vi cho nhóm kiểm soát và nhóm thử nghiệm phải phù hợp với các mục nội dung quyết định và phạm vi của chính chiến lược.

Điều này cũng tương đương với sự đảm bảo kép. Nếu có vấn đề với thí nghiệm, chiến lược vẫn có thể đưa ra nội dung quyết định cơ bản. Nếu thí nghiệm được thực hiện bình thường, nhóm do người dùng - nhóm kiểm soát/nhóm thử nghiệm thực hiện và nội dung mục quyết định tương ứng có thể được đưa ra.

Khi thời hạn hiệu lực của thử nghiệm kết thúc, thử nghiệm sẽ tự động kết thúc, thử nghiệm sẽ không còn được thực hiện khi chiến lược được thực hiện và nội dung quyết định sao lưu trong chiến lược sẽ tự động được đưa ra.

Nếu bạn muốn kết thúc thử nghiệm sớm trong thời gian hiệu lực của chiến lược, bạn cũng có thể đóng thử nghiệm theo cách thủ công hoặc tạo thử nghiệm mới. Tuy nhiên, các thí nghiệm tác động theo chiến lược, nghĩa là việc đưa ra các thí nghiệm được tích hợp với các chiến lược. Nếu thử nghiệm được cập nhật, chiến lược cần phải được phát hành đồng bộ để có hiệu lực.

3. Logic thực hiện chiến lược

• Logic thực thi của thẻ là nhập tham số và trả về giá trị tương ứng với thẻ.
• Logic thực thi của quy tắc là nhập tham số và trả về có hoặc không, nghĩa là quy tắc có được đáp ứng hay không.
• Logic thực hiện của chiến lược này là nhập tham số và trả về nội dung quyết định cụ thể.

Nói cách khác, trong trường hợp này, chiến lược sẽ trả về nội dung quyết định dựa trên kết quả quyết định quy tắc, chẳng hạn như uid, skuid, orderid và các trường trong suốt cần thiết cho tham số đầu vào.

Khi đó sẽ có một tình huống xảy ra. Nếu có nhiều chiến lược trong một trường hợp kịch bản, sau khi nhập các tham số, dựa trên phán đoán quy tắc, nhiều chiến lược sẽ được khớp và nội dung quyết định sẽ được đưa ra. Cần phải làm gì?

Có ba phương pháp xử lý phổ biến: lấy hợp, lấy giao và xuất theo thứ tự ưu tiên.

1. Lấy hợp: Lấy hợp của nhiều nội dung quyết định chính sách, nghĩa là hợp nhất tất cả chúng lại và xuất chúng ra cùng nhau.
2. Lấy giao điểm: Lấy giao điểm của nhiều nội dung quyết định chiến lược, nghĩa là chỉ những nội dung trong mỗi quyết định chiến lược mới được đưa ra. Phương pháp này dễ dẫn đến tình huống giao điểm trống và nội dung quyết định đầu ra trống.
3. Đầu ra theo mức độ ưu tiên: Sắp xếp theo mức độ ưu tiên của chính chiến lược và đưa ra nội dung quyết định tương ứng với chiến lược trúng đích đầu tiên theo mức độ ưu tiên. Nói cách khác, kết quả thực hiện của chiến lược có mức độ ưu tiên cao hơn sẽ được ưu tiên.

Đối với hệ thống ra quyết định tại hiện trường, cấu hình khả năng đưa ra quyết định này có thể được hỗ trợ trong cấu hình phiên bản hiện trường. Mỗi bối cảnh khác nhau chắc chắn sẽ có những yêu cầu khác nhau. Điều này có thể giảm chi phí xử lý của bên truy cập.

Tất nhiên là vẫn còn cách khác. Quyết định trường trả về tất cả kết quả theo thứ tự cho bên truy cập và mỗi bên truy cập đưa ra quyết định riêng về kết quả đầu ra cuối cùng.

8. Hệ thống trường hợp cảnh

1. Kiểu truy cập kịch bản

Nếu một kịch bản kinh doanh muốn sử dụng khả năng của công cụ ra quyết định tại hiện trường, nó phải được kết nối với hệ thống ra quyết định tại hiện trường.

Về mặt tương tác hệ thống, có hai phương pháp truy cập: một là vòng lặp khép kín của hệ thống quyết định tại hiện trường và phương pháp còn lại là nhúng hệ thống quyết định tại hiện trường vào hệ thống kinh doanh.

Vòng lặp khép kín của hệ thống quyết định tại hiện trường có nghĩa là người dùng chọn các kịch bản, trường hợp, tạo chính sách, chọn quy tắc, chọn quyết định, công bố trường hợp và đưa chúng trực tuyến để có hiệu lực trong hệ thống quyết định tại hiện trường.

Bộ quy trình này là quy trình hướng tới tương lai được thiết kế dựa trên hệ thống quyết định thực địa. Người dùng sẽ biết được từng lớp của hệ thống và từng bước thực hiện trong quá trình cấu hình. Theo góc độ hiểu biết của người dùng về logic quyết định tại hiện trường thì chi phí thấp nhưng chi phí vận hành lại cao.

Đồng thời, giải pháp này cho phép các bên kinh doanh sử dụng trực tiếp hệ thống quyết định thực địa như chi phí quản lý riêng của mình mà không cần phải duy trì quy trình vận hành hệ thống quản lý riêng, điều này cũng có thể tiết kiệm chi phí phát triển.

Việc nhúng hệ thống quyết định thực địa vào hệ thống kinh doanh có nghĩa là người dùng không cần phải biết về hệ thống quyết định thực địa. Người đó có thể hoàn thiện cấu hình doanh nghiệp của riêng mình trong hệ thống doanh nghiệp, chẳng hạn như hệ thống phân phối lưu lượng truy cập hoặc hệ thống khuyến mại và chỉ chọn một quy tắc người dùng hoặc quy tắc sản phẩm để chỉ ra rằng hoạt động kinh doanh chỉ có hiệu quả đối với người dùng và sản phẩm được chỉ định.

Bộ quy trình này được thiết kế theo góc nhìn của hệ thống kinh doanh và người dùng ít biết về cách hệ thống quyết định tại hiện trường hoạt động trong quá trình cấu hình. Theo góc độ hiểu biết của người dùng về logic quyết định tại hiện trường thì chi phí cao nhưng chi phí vận hành thấp. Trong nhiều trường hợp, nhân viên kinh doanh thực sự gặp khó khăn và họ không cần phải hiểu hệ thống quyết định tại hiện trường. Theo quan điểm của họ, họ chỉ tạo ra một chương trình khuyến mại chỉ có hiệu quả với người dùng mới và thế là hết. Trong trường hợp này, phương pháp truy cập nhúng hiệu quả hơn và tiết kiệm được nhiều chi phí hiểu biết và vận hành.

Tất nhiên, về cơ bản phương pháp truy cập nhúng sẽ không thay đổi. Nó chỉ tương đương với việc tùy chỉnh cảnh hoặc tạo cảnh và phiên bản theo thời gian thực thông qua giao diện theo mặc định khi truy cập cảnh. Khi các quy tắc lựa chọn doanh nghiệp được lưu và có hiệu lực, điều này tương đương với việc tự động tạo chính sách và thực hiện quy trình phát hành. Khung và logic cơ bản đằng sau nó vẫn không thay đổi.

Nhưng điều này cũng dẫn tới một vấn đề khác. Nếu mỗi hệ thống có hệ thống nhúng riêng thì sẽ khó khăn trong việc phát triển và truy cập hệ thống kinh doanh; và đối với hệ thống ra quyết định tại hiện trường, sẽ rất khó để duy trì nếu có những bản cập nhật tiếp theo.

Do đó, hệ thống quyết định thực địa có thể được đưa ra dưới dạng các thành phần chuẩn hóa. Nếu một hệ thống kinh doanh muốn sử dụng khả năng ra quyết định tại hiện trường, hệ thống đó cần truyền các tham số chính vào thành phần và sau đó chọn các quy tắc, nội dung quyết định, v.v. theo cùng một quy trình vận hành. Theo cách này, nếu có những bản cập nhật tiếp theo, tất cả các thành phần tối ưu hóa có thể được cập nhật đồng đều, hiệu quả hơn.

2. Quản lý phiên bản phiên bản

Như đã đề cập ở trên, khi người dùng công bố chính sách, thực tế là họ cần phải công bố các phiên bản.

Tại sao phải công bố trường hợp này?

Chúng tôi tin rằng một thể hiện là đơn vị thực thi mã nhỏ nhất, điều đó có nghĩa là các chiến lược này là kết quả của việc đưa ra quyết định tại nơi này. Nếu mọi chiến lược đều có thể được sửa đổi và phát hành trực tuyến tùy ý, điều đó có nghĩa là dữ liệu liên tục được cập nhật và ghi đè ở cùng một nơi, điều này có thể gây ra xung đột.

Do đó, vấn đề này có thể được giải quyết bằng cách xuất bản phiên bản. Tại cùng một vị trí, chỉ có thể chỉnh sửa một phiên bản tại cùng một thời điểm. Sau khi một phiên bản được phát hành, phiên bản tiếp theo có thể được mở. Loại quản lý phiên bản này an toàn hơn và cũng giúp khôi phục kịp thời khi có sự cố xảy ra.

Có bốn phiên bản phát hành: bản nháp, bản phát hành trước, bản thang độ xám và trực tuyến.

Có nghĩa là, mọi thay đổi đối với phiên bản, bao gồm thêm chính sách mới, hủy kích hoạt chính sách, chỉnh sửa chính sách, v.v., miễn là có thể tác động đến quyết định của phiên bản, chúng tôi sẽ coi đó là thay đổi phiên bản và sẽ thay đổi thông tin trong phiên bản dự thảo.

Sau khi bản nháp được cập nhật, nó cần được phát hành thành phiên bản tiền phát hành, phiên bản thang độ xám và sau đó là phiên bản trực tuyến. Phát hành và thực thi theo trình tự để đảm bảo dữ liệu của từng phiên bản được cập nhật theo thứ tự.

Nếu phiên bản hiện tại đang được người dùng sử dụng, thì những người khác chỉ có thể đợi người dùng hoàn tất việc phát hành hoặc đợi người dùng hoàn tác các chỉnh sửa, khôi phục trạng thái ban đầu và phát hành cho những người dùng khác. Ví dụ, người dùng A thêm chính sách mới, lưu lại và phát hành phiên bản trước khi phát hành. Lúc này, người dùng B muốn thêm chính sách mới nhưng không thể thực hiện được. Anh ta chỉ có thể đợi người dùng A công bố phiên bản của mình trực tuyến hoặc thu hồi phiên bản và khôi phục về phiên bản gốc.

Một trong những lợi ích lớn nhất của việc kiểm soát phiên bản chặt chẽ là bạn có thể quay lại bất kỳ lúc nào. Nếu người dùng thấy có vấn đề với phiên bản vừa phát hành, họ có thể xem các phiên bản lịch sử và chọn một phiên bản lịch sử để nhanh chóng khôi phục, tương đương với việc tạo một phiên bản mới và ghi đè nội dung bằng phiên bản lịch sử trước khi phát hành. Loại xử lý dự phòng này cực kỳ hiệu quả và có thể giảm thiểu rủi ro.

3. Bài kiểm tra mẫu

Kiểm tra nhãn và kiểm tra quy tắc đã đề cập ở trên nhưng không đề cập đến kiểm tra chiến lược. Không phải là các chiến lược không thể được thử nghiệm, mà là thử nghiệm theo trường hợp tiết kiệm chi phí hơn.

Từ việc quản lý phiên bản phiên bản, chúng ta có thể hiểu rằng phiên bản là đơn vị thực thi mã nhỏ nhất. Chúng tôi cấu hình một chính sách, nhưng về cơ bản chúng tôi không kiểm tra hiệu quả thực thi của một chính sách riêng lẻ, vì chúng tôi có thể biết sơ bộ câu trả lời thông qua việc kiểm tra quy tắc. Thay vào đó, tôi muốn kiểm tra xem khu vực của tôi sẽ được hiển thị như thế nào sau khi thêm chiến lược này.

Trường hợp này có thể có nhiều chính sách, liên quan đến logic thực thi chính sách; Trường hợp này có thể có nhiều tham số đầu vào, bao gồm uid, skuid, các trường trong suốt khác nhau, v.v.

Do đó, chỉ thông qua thử nghiệm cá thể, chúng ta mới có thể có được mô phỏng chính xác nhất về hiệu ứng thực thi phía người dùng.

Khi kiểm tra một trường hợp, bạn cần điền vào các trường theo yêu cầu của trường hợp đó trong tham số đầu vào, chẳng hạn như uid và skuid. Sau đó, phiên bản này sẽ trả về kết quả thực thi, tức là đưa ra giá trị quyết định sức mạnh cuối cùng, có thể là giá trị quyết định cuối cùng được đưa ra dựa trên logic thực thi chiến lược sau khi đạt được nhiều chiến lược.

9. Nâng cấp cây chiến lược

1. Giải quyết các điểm đau

Từ kiến ​​trúc hệ thống ở trên, chúng ta có thể thấy rằng góc nhìn hiện tại được kích hoạt từ bối cảnh cho đến quyết định cuối cùng.

Mặc dù logic này dễ hiểu nhưng có hai vấn đề:

1. Hoạt động này tương đối phức tạp. Nếu bạn cần thực thi các chính sách cho cùng một người dùng trong nhiều tình huống khác nhau, bạn cần phải chuyển đến nhiều trường hợp khác nhau để vận hành, điều này làm tăng chi phí vận hành.
2. Khó để trừu tượng hóa. Từ cấu trúc hiện tại, rất khó để nhanh chóng nhận thấy những chiến lược cải tiến nào đã được triển khai cho cùng một loại người dùng.

Do đó, chúng ta cần trừu tượng hóa toàn bộ chiến lược khỏi một chiều khác, chẳng hạn như chiều người dùng hoặc chiều sản phẩm, để hình thành nên cây chiến lược.

Một mặt, cây chiến lược này có thể nhanh chóng cải thiện hiệu quả. Ví dụ, bạn có thể chọn người dùng mà bạn muốn vận hành và nhanh chóng cấu hình các chiến lược bạn muốn thực hiện trong các tình huống khác nhau, điều này có thể cải thiện đáng kể hiệu quả hoạt động. Mặt khác, điều này phù hợp hơn với suy nghĩ của ông chủ. Nói chung, sếp chắc chắn muốn xem bạn đã triển khai những chiến lược nào cho một loại người dùng nhất định và những chiến lược nào cho một loại người dùng khác, thay vì bắt đầu từ góc độ chức năng hệ thống. Những chiến lược như vậy cũng có lợi hơn cho sự tích tụ và lượng mưa.

2. Cấu trúc cây

Trong cấu trúc hệ thống hiện tại, các kịch bản, trường hợp, chiến lược, quy tắc, nhãn và quyết định đều đầy đủ. Nhưng cần có một vật mang mới để kết nối chúng lại với nhau, và vật mang mới này chính là cây.

Do đó, trọng tâm là xây dựng cấu trúc cây.

Tương tự như sơ đồ trên, các hoạt động được thực hiện dựa trên người dùng thương mại điện tử mới. Đầu tiên, người dùng được chia thành ba lớp: người dùng chất lượng cao, người dùng bình thường và người dùng tăng trưởng theo giá trị của họ. Sau đó, người dùng nam và nữ được phân chia theo giới tính để tinh chỉnh hoạt động hơn nữa.

Không khó để nhận thấy rằng các nút khác nhau của một cây, từ nút gốc đến nút lá ở dưới cùng, được kết nối để tạo thành một quy tắc hoàn chỉnh. Lấy nhánh ngoài cùng bên trái làm ví dụ, ý nghĩa của nó là {vòng đời người dùng = người dùng thương mại điện tử mới và giá trị người dùng = người dùng chất lượng cao và giới tính người dùng = người dùng nam}

Do đó, đối với một cây, điều đầu tiên là ID, tên và trạng thái của cây đó.

Thứ hai, một cây có thể có nhiều nút và mỗi nút cây khác nhau cũng có ID, tên và trạng thái riêng.

Và mỗi nút tương ứng với một quy tắc. Các nút con cũng có thể kế thừa các quy tắc của các nút cha và kết nối chúng để tạo thành một bộ quy tắc.

3. Quá trình cấu hình cây

Logic cấu hình của cây là xây dựng cây bằng cách tạo các nút và sau đó cấu hình chiến lược trên mỗi nút.

Logic của việc tạo một nút là để chọn các quy tắc người dùng. Các nút khác nhau được xác định bởi các quy tắc người dùng khác nhau. Các nút ở các cấp độ khác nhau có mối quan hệ kế thừa, nghĩa là các quy tắc của các nút lá ở cấp độ tiếp theo sẽ kế thừa các quy tắc của các nút lá ở cấp độ trước đó.

Sau khi các nút cây được tạo, bạn có thể cấu hình chính sách trên mỗi nút. Khi cấu hình chính sách, bạn không cần phải chọn quy tắc vì nút đã xác định các quy tắc. Bạn chỉ cần chọn kịch bản, trường hợp và nội dung quyết định tương ứng.

4. Quy trình thực hiện cây

Có hai cách để hiểu quá trình thực thi của một cây.

Một là giống như quy trình thực hiện hệ thống quyết định tại hiện trường trước đó, trong đó đọc chiến lược, đánh giá các quy tắc và xác định nội dung quyết định theo trường hợp kịch bản tương ứng. Bởi vì đối với cây chiến lược, như đã đề cập ở trên, về cơ bản nó là sự kết nối các quy tắc. Từ một quy tắc duy nhất, nó trở thành nhiều quy tắc được kết nối bằng "và", nhưng nó vẫn là một quy tắc. Do đó, toàn bộ hệ thống không thay đổi và logic thực hiện đương nhiên cũng sẽ không thay đổi.

Tất nhiên, vẫn còn một cách khác để hiểu, đó là hiểu theo góc nhìn của cây. Khi người dùng vào, trước tiên hãy xác định các quy tắc của người dùng, sau đó thông qua nút gốc, xác định cây nào mà người dùng sẽ chạm tới, rồi xác định từng lớp nút lá mà người dùng sẽ chạm tới và cuối cùng là thực thi các chiến lược của tất cả các nút mà người dùng chạm tới. Điều này nhằm mục đích hiểu logic thực thi theo hướng tích cực từ góc nhìn của cây.

10. Những câu hỏi thường gặp

1. Sự khác biệt giữa quy tắc người dùng và gói người dùng là gì?

Trong quy trình kinh doanh, câu hỏi thường gặp nhất là: Tôi có thể sử dụng các quy tắc của hệ thống quyết định thực địa để khoanh tròn một nhóm người dùng và gửi tin nhắn văn bản cho họ không?

Tôi đã cố gắng giải thích điều này với nhân viên kinh doanh nhiều lần, nhưng có vẻ như việc giải thích cặn kẽ luôn rất khó khăn.

Vì vậy, sau đó tôi đã thử giải thích theo một khái niệm khác, đó là sàng lọc và lựa chọn.

Việc sàng lọc giống như một cái phễu. Khi người dùng đến, chúng tôi sẽ xem liệu họ có thể đi qua được không. Nếu không bỏ sót thì anh ta đã bị loại. Tất cả những gì bạn có là một cái phễu không có gì cụ thể bên trong.

Việc lựa chọn hình tròn giống như chuồng cừu hơn. Có rất nhiều cừu trong chuồng và mỗi con cừu đều có mã số nhận dạng riêng. Bạn có thể kéo đàn cừu cụ thể này để sản xuất sữa. Ví dụ, hôm nay tôi đã chăn 83 con cừu để lấy sữa. Những gì bạn có là một tập hợp các thứ cụ thể trong một chuồng cừu và bạn có thể áp dụng các hành động cụ thể vào chúng.

Do đó, công cụ quy tắc trong hệ thống quyết định tại hiện trường giống như logic sàng lọc và các quy tắc là cái phễu. Khi mỗi người dùng đến, tôi chỉ có thể cho họ biết liệu họ có khớp với các quy tắc hay không (có bị lọc hay không), nhưng tôi không biết có bao nhiêu người dùng trong kênh này, vì bản thân kênh không phải là một vùng chứa và không chứa "người dùng".

Nếu bạn muốn chọn 300.000 người dùng này để gửi tin nhắn tiếp thị qua SMS, đây chính là logic lựa chọn. Bạn chọn và phân phối một gói 300.000 người dùng dựa trên các quy tắc nhất định. Gói này là thùng chứa chứa 300.000 "người dùng". Khi đã có mục tiêu cụ thể, bạn có thể thực hiện các hành động rõ ràng cho 300.000 người dùng này, chẳng hạn như gửi tiếp thị qua SMS.

Quy tắc người dùng mang tính sàng lọc, không có đối tượng cụ thể và chỉ được sử dụng để ra quyết định;

Các gói người dùng được khoanh tròn, có mục tiêu cụ thể và được sử dụng cho mục đích tiếp thị.

Đây là sự khác biệt lớn nhất giữa quy tắc người dùng và gói người dùng.

Tất nhiên, chúng có thể có cùng khả năng gắn thẻ như nhau làm cơ sở. Gói người dùng được hình thành bằng cách lắp ráp các biểu thức chính quy thông qua các thẻ và sau đó chạy lô biểu thức người dùng. Nói chung, phải mất thời gian để chạy một loạt các gói người dùng, do đó phải có thời gian cập nhật và không thể thực hiện theo thời gian thực. Quy tắc của người dùng có thể đưa ra quyết định theo thời gian thực.

2. Tại sao chúng ta cần phải công bố các trường hợp để chính sách có hiệu lực?

Khi người dùng công bố chính sách, thực tế là họ cần công bố một phiên bản. Tại sao phải công bố trường hợp này?

Chúng tôi tin rằng một thể hiện là đơn vị thực thi mã nhỏ nhất, điều đó có nghĩa là các chiến lược này là kết quả của việc đưa ra quyết định tại nơi này. Nếu mọi chiến lược đều có thể được sửa đổi và phát hành trực tuyến tùy ý, điều đó có nghĩa là dữ liệu liên tục được cập nhật và ghi đè ở cùng một nơi, điều này có thể gây ra xung đột.

Do đó, vấn đề này có thể được giải quyết bằng cách xuất bản phiên bản. Tại cùng một vị trí, chỉ có thể chỉnh sửa một phiên bản tại cùng một thời điểm. Sau khi một phiên bản được phát hành, phiên bản tiếp theo có thể được mở. Loại quản lý phiên bản này an toàn hơn và cũng giúp khôi phục kịp thời khi có sự cố xảy ra.

Có bốn phiên bản phát hành: bản nháp, bản phát hành trước, bản thang độ xám và trực tuyến.

Có nghĩa là, mọi thay đổi đối với phiên bản, bao gồm thêm chính sách mới, hủy kích hoạt chính sách, chỉnh sửa chính sách, v.v., miễn là có thể tác động đến quyết định của phiên bản, chúng tôi sẽ coi đó là thay đổi phiên bản và sẽ thay đổi thông tin trong phiên bản dự thảo.

Sau khi bản nháp được cập nhật, nó cần được phát hành thành phiên bản tiền phát hành, phiên bản thang độ xám và sau đó là phiên bản trực tuyến. Phát hành và thực thi theo trình tự để đảm bảo dữ liệu của từng phiên bản được cập nhật theo thứ tự.

Nếu phiên bản hiện tại đang được người dùng sử dụng, thì những người khác chỉ có thể đợi người dùng hoàn tất việc phát hành hoặc đợi người dùng hoàn tác các chỉnh sửa, khôi phục trạng thái ban đầu và phát hành cho những người dùng khác. Ví dụ, người dùng A thêm chính sách mới, lưu lại và phát hành phiên bản trước khi phát hành. Lúc này, người dùng B muốn thêm chính sách mới nhưng không thể thực hiện được. Anh ta chỉ có thể đợi người dùng A công bố phiên bản của mình trực tuyến hoặc thu hồi phiên bản và khôi phục về phiên bản gốc.

Một trong những lợi ích lớn nhất của việc kiểm soát phiên bản chặt chẽ là bạn có thể quay lại bất kỳ lúc nào. Nếu người dùng thấy có vấn đề với phiên bản vừa phát hành, họ có thể xem các phiên bản lịch sử và chọn một phiên bản lịch sử để nhanh chóng khôi phục, tương đương với việc tạo một phiên bản mới và ghi đè nội dung bằng phiên bản lịch sử trước khi phát hành. Loại xử lý dự phòng này cực kỳ hiệu quả và có thể giảm thiểu rủi ro.

3. Tại sao cần phải xây dựng và tạo nhãn?

Tại sao các thẻ lại được thêm vào bởi bộ phận R&D thay vì do chính nhân viên kinh doanh tạo ra?

Một là tính chuyên nghiệp của nhãn hiệu. Nhiều thẻ yêu cầu các mục cấu hình chuyên nghiệp. Ví dụ, các thẻ được tạo thông qua giao diện yêu cầu cấu hình tên giao diện, tên phương thức, thời gian lưu trữ bộ đệm thẻ, v.v. Đây là những nội dung rất chuyên nghiệp. Ngay cả khi nhân viên kinh doanh tự xử lý, họ vẫn cần liên hệ với bộ phận R&D để có được thông tin có liên quan. Sẽ tốt hơn nếu R&D thêm nó trực tiếp, như vậy sẽ hiệu quả hơn.

Một là tầm quan trọng của nhãn. Nhãn là khả năng cơ bản và cốt lõi nhất của hệ thống ra quyết định tại hiện trường. Nếu nhãn sai thì quy tắc sẽ sai và quyết định sẽ sai. Đây là một vấn đề rất nghiêm trọng. Do đó, độ chính xác của nhãn là sự đảm bảo chính của hệ thống ra quyết định hiện trường. Cấu hình theo R & D và thử nghiệm sau khi cấu hình có thể tối đa hóa độ chính xác của các nhãn và chúng sẽ được cung cấp cho sử dụng kinh doanh chỉ sau khi xác nhận rằng không có vấn đề gì.

Logic bảo trì thẻ thông thường là doanh nghiệp tăng các yêu cầu, R & D bổ sung và kiểm tra, sau đó phát hành trực tuyến. Nếu có vấn đề sau khi lên mạng, R & D cũng có thể vô hiệu hóa hoặc sửa đổi nó.

4. Cách kiểm soát thẩm quyền của hệ thống ra quyết định hiện trường

Thông qua phần giới thiệu ở trên, mọi người dễ dàng cảm thấy rằng hệ thống ra quyết định thực địa là một hệ thống trung tâm rất quan trọng, giống như bộ não con người, chịu trách nhiệm xử lý các quyết định khác nhau. Sau đó, hệ thống chắc chắn cần kiểm soát sự cho phép hoàn hảo để ngăn chặn bộ não bị "xâm chiếm" và gây ra tai nạn ra quyết định.

Tại mỗi lớp của hệ thống ra quyết định hiện trường, các kịch bản, trường hợp, chính sách, quy tắc và nhãn hiệu đều yêu cầu kiểm soát quyền nghiêm ngặt.

Ngoài ra, các chính sách, quy tắc và nhãn hiệu có thể được kiểm soát bởi nhân viên được ủy quyền. Điều đó có nghĩa là, khi tạo ra một chính sách, bạn có thể điền vào các nhân viên có thẩm quyền sửa đổi chính sách và nhân sự cũng có thể xử lý nó sau. Rốt cuộc, công việc liên quan đến các kịch bản như bàn giao và phối hợp, và đôi khi các đồng nghiệp khác là cần thiết để giúp lấp đầy các khoảng trống.

Tất nhiên, hệ thống cũng yêu cầu vai trò siêu quản trị viên trong trường hợp khẩn cấp. Ví dụ, khi một đồng nghiệp đang đi nghỉ hoặc rời khỏi công ty, và không ai có quyền vận hành các chính sách, quy tắc và thẻ hiện có, siêu quản trị viên có thể đóng một vai trò.