Cá nhân hóa ở quy mô lớn chủ yếu là bài toán vận hành. Năm quy tắc thì một người vẫn nhớ được. Năm mươi quy tắc do bốn người viết trong một năm thì không. Nếu không có cấu trúc, bạn sẽ có những quy tắc không ai sở hữu, hai quy tắc tranh nhau cùng một tiêu đề trên trang bảng giá, và một mức giá cũ vẫn hiển thị cho một phân khúc vì không ai nhớ biến thể đó tồn tại.
Bài viết này trình bày cấu trúc giúp bộ quy tắc ngày càng lớn vẫn quản lý được: đặt tên, sổ đăng ký, thứ tự ưu tiên rõ ràng khi xung đột, mẫu dựa trên vị trí thay vì trang tùy chỉnh, kiểm tra hiệu suất và ai phụ trách việc gì. Không có gì phức tạp. Chỉ cần nó tồn tại trước khi số lượng quy tắc tăng lên, không phải sau đó.
Dấu hiệu cho thấy bạn đã vượt quá thiết lập hiện tại
- Không ai nói được một khách truy cập cụ thể thấy gì. Ai đó hỏi “khách truy cập enterprise ngành y tế thấy gì trên trang chủ?” và để trả lời phải mở nhiều quy tắc, có khi trên nhiều công cụ.
- Xung đột được giải quyết một cách ngẫu nhiên. Hai quy tắc nhắm vào cùng một thành phần cho các phân khúc chồng lấn, và quy tắc nào thắng phụ thuộc vào thứ tự tải hoặc ngày tạo thay vì một quyết định có chủ đích.
- Thay đổi nội dung biến thành cuộc tìm kiếm. Đổi giá hoặc tên sản phẩm nghĩa là phải lục tung mọi biến thể để tìm chỗ còn câu chữ cũ.
- Trang chậm hơn hoặc bắt đầu nhấp nháy khi thêm quy tắc, và không ai để ý từ khi nào.
- Ngừng thử nghiệm vì việc duy trì các quy tắc hiện có chiếm hết thời gian.
Cắt bớt số quy tắc đôi khi là câu trả lời đúng, nhất là khi nhiều quy tắc chưa từng được đo lường. Nhưng thường thì các quy tắc vẫn ổn, và thứ còn thiếu là cách để nhìn thấy và quản trị chúng.
Đặt tên quy tắc sao cho tên đã giải thích được quy tắc
Chọn một mẫu và dùng ở mọi nơi. Một mẫu hiệu quả: cấp, phân khúc, trang, yếu tố và phiên bản, nối bằng dấu gạch ngang theo thứ tự đó:
tier-segment-page-element-version
T1-acme-corp-homepage-hero-v2T2-enterprise-healthcare-pricing-proof-v1T3-returning-visitor-blog-cta-v3
Tiền tố cấp độ gắn với thứ tự xử lý xung đột được mô tả bên dưới. Phần còn lại giúp bất kỳ ai đọc danh sách quy tắc đều thấy mỗi quy tắc làm gì mà không cần mở ra. Lọc theo trang, bạn có mọi quy tắc có thể tác động đến trang đó; lọc theo phân khúc, bạn có mọi thứ mà phân khúc đó nhìn thấy.
Duy trì một sổ đăng ký
Một bảng tính là đủ. Mỗi quy tắc đang hoạt động một dòng, với các cột sau:
| Cột | Lý do có mặt |
|---|---|
| Tên quy tắc | Khớp chính xác với tên trong công cụ |
| Mục đích | Một câu: “Hiển thị case study ngành y tế cho khách truy cập ngành y tế để tăng yêu cầu demo” |
| Người phụ trách | Người cần hỏi, và người cập nhật nó |
| Định nghĩa phân khúc | Các điều kiện thực tế, để thấy rõ chỗ chồng chéo |
| Trang và phần tử | Nơi nó thay đổi nội dung |
| Thông tin chứa trong đó | Giá, tên gói, tên khách hàng, tên sản phẩm; đây là cột bạn tìm kiếm khi bất kỳ thông tin nào trong số đó thay đổi |
| Trạng thái holdout / thử nghiệm | Đã đo, đang đo hoặc chưa bao giờ đo |
| Lần rà soát gần nhất | Ngày |
Hãy thêm hai thói quen xung quanh nó. Quy tắc mới phải qua một yêu cầu ngắn gửi đến người quản lý sổ đăng ký (một tin nhắn Slack là đủ), giúp phát hiện trùng lặp trước khi triển khai. Và mỗi quý, hãy rà soát danh sách: loại bỏ các quy tắc không cho thấy hiệu quả sau một thử nghiệm đầy đủ, cập nhật nội dung lỗi thời, và gộp các quy tắc làm cùng một việc cho các phân khúc chồng lấn. Mẫu cẩm nang cá nhân hóa của chúng tôi có thể dùng làm sổ đăng ký nếu bạn không muốn tự xây dựng; nó có một cột cho thứ tự ưu tiên khi chồng lấn.
Quyết định cách xử lý xung đột trước khi chúng xảy ra
Một khách quay lại từ một công ty y tế lớn nằm trong danh sách tài khoản mục tiêu có thể cùng lúc khớp quy tắc tài khoản, quy tắc ngành kết hợp quy mô, quy tắc ngành và quy tắc khách quay lại. Nếu tất cả đều nhắm vào hero, phải có thứ quyết định. Hãy đặt một thứ tự rõ ràng:
- Cấp 1: quy tắc theo tài khoản được chỉ định. Mọi thứ xây dựng cho một tài khoản hoặc danh sách tài khoản cụ thể sẽ được ưu tiên. Đây là các quy tắc cụ thể nhất và thường gắn với một cuộc trao đổi bán hàng đang diễn ra.
- Tier 2: phân khúc kết hợp. Quy tắc kết hợp hai thuộc tính trở lên (enterprise + y tế) được ưu tiên hơn quy tắc một thuộc tính, vì ai đó đã quyết định tổ hợp đó xứng đáng có thông điệp riêng.
- Tier 3: quy tắc một thuộc tính. “Mọi khách truy cập doanh nghiệp lớn”, “mọi khách truy cập từ Mỹ”. Phương án dự phòng.
- Trang mặc định. Những gì mọi người khác nhìn thấy, và cũng là những gì trình thu thập dữ liệu nhìn thấy.
Trong cùng một tầng, đừng để “cập nhật gần nhất” hay thứ tự tải quyết định. Hãy gán cho mỗi quy tắc trong tầng một số thứ hạng rõ ràng trong sổ đăng ký, hoặc tốt hơn, ngay từ đầu tránh để các quy tắc cùng tầng tác động lên cùng một thành phần cho các phân khúc chồng lấn. Cơ chế phân định ngầm chính là cách một khách truy cập cuối cùng thấy một biến thể không ai định cho họ thấy.
Xung đột cũng có thể tránh được theo từng thành phần. Nếu quy tắc theo tài khoản quản phần hero và quy tắc theo ngành quản khối bằng chứng, một khách truy cập khớp cả hai sẽ nhận cả hai mà không xung đột. Đây là cách xử lý đơn giản nhất và đáng thử trước tiên.
Dùng mẫu và vị trí nội dung thay vì trang tùy chỉnh
Mô hình giúp một bộ quy tắc lớn vẫn khả thi: cố định bố cục trang và định nghĩa một vài vị trí có thể cá nhân hóa. Quy tắc điền vào các vị trí; nó không thiết kế lại trang.
Ví dụ các vùng nội dung cho trang chủ B2B:
- Tiêu đề hero (có giới hạn ký tự để các biến thể vừa trên điện thoại)
- Tiêu đề phụ hero
- Khối bằng chứng: một hàng logo và một trích dẫn
- Nhãn và đích đến của CTA chính
- Case study nổi bật
Khi đó, tạo một biến thể chỉ là viết nội dung cho năm trường và chọn một case study, việc mà marketer tự làm được mà không cần đến thời gian của designer hay kỹ sư. Nó cũng làm cho danh mục quản lý trở nên hữu ích: bạn biết chính xác quy tắc nào được phép thay đổi trường nào.
Sự đánh đổi là có thật. Biến thể cho y tế và biến thể cho fintech sẽ trông giống nhau vì dùng chung bố cục. Với hầu hết website B2B, điều đó chấp nhận được, vì thông điệp mới là thứ thay đổi theo phân khúc. Hãy dành cách xử lý hoàn toàn tùy chỉnh cho một danh sách ngắn các tài khoản được chỉ định mà quy mô hợp đồng xứng đáng với công sức thêm, và chấp nhận rằng những trang đó cần được bảo trì riêng.
Theo dõi hiệu năng khi thêm quy tắc
Một bộ quy tắc tốn bao nhiêu về tốc độ phụ thuộc vào nơi quyết định được đưa ra. Quyết định phía máy chủ hoặc edge thêm việc trước khi trang được gửi đi; script phía client thêm việc sau khi trang hiển thị và có thể gây nhấp nháy. Dù thế nào, hãy đo đạc thay vì giả định:
- Largest Contentful Paint và hiện tượng nhấp nháy trên trang cá nhân hóa. So sánh một biến thể cá nhân hóa với trang mặc định trong PageSpeed Insights hoặc thử nghiệm lab, với cấu hình di động bị giới hạn tốc độ. Nếu hero cá nhân hóa là thành phần LCP và xuất hiện muộn hơn phiên bản mặc định, quyết định đang được đưa ra quá muộn.
- Thời gian ra quyết định từ công cụ cá nhân hóa. Hầu hết công cụ ghi lại thời gian để ra một quyết định. Theo dõi nó theo thời gian, và xem điều gì đã thay đổi mỗi khi nó tăng vọt.
- Tỷ lệ dự phòng. Tần suất một quy tắc thất bại và phiên bản mặc định hiển thị thay thế. Dự phòng âm thầm tốt hơn trang bị lỗi, nhưng tỷ lệ cao nghĩa là khách truy cập không nhận được những gì sổ đăng ký ghi.
Ghi lại mức cơ sở trước khi mỗi đợt quy tắc mới được đưa lên, để có thể gắn một sự suy giảm với thay đổi gây ra nó. Giám sát Core Web Vitals trong công cụ RUM hoặc Search Console sẽ cảnh báo các vấn đề kéo dài, nhưng chỉ sau khi đủ lưu lượng thực tế đã bị ảnh hưởng.
Ai phụ trách việc gì
| Vai trò | Trách nhiệm | Thường do ai nắm giữ |
|---|---|---|
| Người phụ trách cá nhân hóa | Danh mục quy tắc, cách đặt tên, thứ tự xử lý xung đột, rà soát hằng quý, quyết định cuối cùng về quy tắc mới | Trưởng nhóm marketing ops hoặc growth |
| Người sản xuất nội dung | Viết nội dung cho từng vị trí theo phân khúc, cập nhật thông tin thường xuyên | Product marketing, đội nội dung |
| Người triển khai kỹ thuật | Thiết lập quy tắc, gỡ lỗi xung đột, kiểm tra hiệu năng | Lập trình viên web hoặc marketer kỹ thuật, tùy công cụ |
| Chuyên viên phân tích | Nhóm đối chứng, kết quả theo từng quy tắc, đánh dấu các quy tắc cần loại bỏ | Chuyên viên phân tích marketing (xem nghề phân tích marketing để biết công việc đó gồm những gì) |
Ở đội nhỏ, một hoặc hai người nắm cả bốn vai trò, điều đó không sao miễn là có sổ đăng ký, vì khi đó người thứ hai có thể tiếp quản công việc. Vai trò người phụ trách là vai trò không thể chia sẻ một cách mơ hồ: nếu ai cũng sở hữu bộ quy tắc, sẽ không ai loại bỏ thứ gì. Để xem RACI, các giai đoạn triển khai và quản trị trong tổ chức lớn hơn, hãy đọc cẩm nang triển khai cá nhân hóa cho doanh nghiệp lớn.
Đo lường từng quy tắc, không chỉ toàn chương trình
Holdout ở cấp chương trình cho bạn biết cá nhân hóa nói chung có đáng giữ lại hay không. Nó không cho biết quy tắc nào trong năm mươi quy tắc đang thực sự tạo ra kết quả. Hãy cho mỗi quy tắc cấp 2 và cấp 3 một holdout hoặc A/B test riêng khi lưu lượng cho phép, và đánh dấu những quy tắc không thể đạt cỡ mẫu đọc được là “chưa đo lường” trong sổ đăng ký thay vì mặc định rằng chúng có ích. Bài viết về đo lường ROI của cá nhân hóa của chúng tôi trình bày cách xác định quy mô holdout và hệ thống thứ bậc chỉ số.
Checklist trước khi số lượng quy tắc tăng lên
- Một quy ước đặt tên mà mọi người đều dùng
- Sổ đăng ký ghi người phụ trách, mục đích, phân khúc, dữ kiện và trạng thái kiểm thử cho mọi quy tắc
- Thứ tự ưu tiên khi xung đột được ghi thành văn bản, cùng quyền sở hữu thành phần theo cấp
- Mẫu vị trí nội dung cho ít nhất trang chủ và trang bảng giá
- Mốc hiệu năng cơ sở và một lần kiểm tra sau mỗi đợt quy tắc
- Một người phụ trách có tên và ngày cho đợt rà soát quý tiếp theo
Bước đầu thực tế: xuất mọi quy tắc đang chạy từ công cụ của bạn sang định dạng danh mục ở trên. Quy tắc nào bạn không điền được (không rõ người phụ trách, không nêu mục đích, không biết có hiệu quả không) sẽ vào danh sách cho lần rà soát đầu tiên. Nếu bạn thiết lập trong Markettailor, tính năng phân khúc lưu định nghĩa phân khúc ở một nơi, giúp dễ phát hiện sự chồng lấn giữa các quy tắc.