Một giờ gửi tốt nhất chung cho cả danh sách chỉ là giờ trung bình chẳng ai theo. Cách Brew hẹn giờ cho từng liên hệ, dùng dữ liệu gì và cách kiểm tra hiệu quả.
Tối ưu thời điểm gửi cho từng liên hệ là cách hẹn giờ để mỗi người nhận nhận được email vào khung giờ mà chính người đó từng mở hoặc nhấp email trước đây, thay vì dùng một giờ chung cho cả danh sách.
“Khi nào là thời điểm tốt nhất để gửi bản tin?” là câu hỏi về số trung bình. Các báo cáo benchmark trả lời bằng một khung giờ giữa buổi sáng vào một ngày làm việc, được tính trung bình trên hàng triệu người không có trong danh sách của bạn. Còn người đọc của bạn thì dọn hộp thư trên tàu lúc 7:00, vào giờ ăn trưa hoặc sau bữa tối. Lượt gửi lúc 10:00 hợp với những người quen đọc lúc 10:00, và bị vùi lấp với tất cả những người còn lại.
Trong Brew, tính năng này là Intelligent Send. Dưới đây là cách tính năng chọn giờ gửi, khi nào nó chuyển sang phương án dự phòng, và cách kiểm tra xem nó có thực sự hiệu quả không.
Một giờ gửi cố định so với một lượt gửi được trải theo khung giờ tương tác trước đây của từng liên hệ.
Trong hộp thoại gửi, mục Thời điểm gửi có các tùy chọn “Gửi ngay”, “Lên lịch”, “Intelligent Send” và “Gửi tăng dần”. Chọn Intelligent Send rồi chọn thời điểm bắt đầu, ngay bây giờ hoặc muộn hơn. Nút gửi sẽ đổi thành Bắt đầu Intelligent Send hoặc Lên lịch Intelligent Send. Tài liệu về các tùy chọn gửi mô tả đủ cả bốn chế độ.
Với mỗi liên hệ, Brew đưa cho một mô hình đánh giá AI 24 khung một giờ (giờ bắt đầu cùng 23 giờ tiếp theo) và lịch sử của liên hệ đó với thương hiệu của bạn, tối đa 200 lượt mở và 100 lượt nhấp gần nhất. Mô hình chọn khung giờ có khả năng cao nhất, dựa trên ba yếu tố:
Nếu khung giờ được chọn muộn hơn thời điểm bắt đầu, email sẽ được gửi khoảng 5 phút trước khung giờ đó, để nằm gần đầu hộp thư đúng lúc người nhận xem. Nếu đó là giờ bắt đầu, email được gửi ngay lập tức.
Bạn bắt đầu một lượt Intelligent Send vào thứ Ba lúc 09:00 UTC. Lịch sử dưới đây là giả định. Các quy tắc thì có thật.
Ana đã nhấp vào sáu email gần nhất của bạn, phần lớn trong khoảng 13:00 đến 14:00 vào các ngày làm việc, và mở vài email lúc 07:30. Lượt nhấp có trọng số cao hơn lượt mở, nên nhiều khả năng 13:00 sẽ được chọn và email của cô ấy được gửi vào khoảng 12:55.
Ben mở gần như mọi email trong khoảng 07:00 đến 08:00. Khung giờ đó đã qua, nhưng khung thời gian gửi kéo dài đến 08:59 thứ Tư, nên anh ấy nhận email khoảng 22 giờ sau thời điểm bắt đầu, ngay trước lúc anh thường đọc. Nhiều người bỏ sót điểm này. Bắt đầu sớm không có nghĩa là những người quen đọc sớm sẽ nhận được email ngay trong hôm nay.
Chloe mới tham gia tuần trước và chưa từng mở email nào, nên cô ấy nhận email lúc 09:00.
Dev có hai mươi lượt mở, tất cả đều chỉ vài giây sau khi email đến, ở mọi khung giờ. Điều đó trông giống một ứng dụng email đang tải nội dung, chứ không phải một người đang đọc. Brew chỉ tính những lượt mở và lượt nhấp được đánh giá là của người thật, nên nếu không lượt nào của Dev đạt yêu cầu, email của anh ấy sẽ được gửi lúc 09:00 như Chloe.
Mail Privacy Protection của Apple mặc định tải nội dung từ xa ở chế độ nền, dù người nhận có đọc email hay không. Một mô hình được nạp những lượt mở đó sẽ học được lúc nào máy chủ của Apple tải thư, rồi hẹn giờ gửi cho bạn vào lúc chẳng có ai xem.
Không dùng múi giờ hay vị trí. Các giờ đều tính theo UTC, và dữ liệu đầu vào duy nhất là dấu thời gian của những lượt mở và lượt nhấp trước đây của người thật.
Đó không phải thiếu sót lớn như nghe có vẻ. Múi giờ chỉ là phỏng đoán về thời điểm một người còn thức. Dấu thời gian của lượt mở ghi lại lúc họ thực sự đọc. Một người đã chuyển đến Berlin mà hồ sơ vẫn ghi New York sẽ được hẹn giờ theo thời điểm họ đọc email hiện nay.
Tính năng cũng không bao giờ tự đặt ra một “giờ tốt nhất cho toàn bộ đối tượng” cho những liên hệ chưa có dữ liệu. Khi không có lịch sử, Brew gửi vào thời điểm bắt đầu của bạn. Tôi cho rằng như vậy là đúng. Thời điểm bắt đầu là quyết định bạn đã đưa ra, và một con số trung bình vay mượn cũng chẳng tốt hơn.
Không có địa chỉ email hay thông tin định danh nào khác được gửi tới mô hình, và lượt gọi mô hình không bị tính phí cho bạn.
Một liên hệ có lịch sử vẫn có thể được gửi vào thời điểm bắt đầu nếu:
Những trường hợp này được đếm riêng là “không hẹn giờ được”. Nếu con số này lớn, hãy nắm rõ điều đó trước khi rút ra kết luận.
Trang phân tích của lượt gửi tóm tắt kết quả trong ba dòng:
Khung Thời điểm gửi theo liên hệ bên dưới liệt kê các liên hệ theo thứ tự đã lên kế hoạch, có thể tìm theo email, mỗi liên hệ kèm một lý do như “Được hẹn giờ dựa trên lượt mở và lượt nhấp trước đây của họ” hoặc “Gửi ngay: chưa có lượt mở hay lượt nhấp nào”.
Hãy xem dòng Phân bổ trước tiên. Nếu 85% được gửi ngay, đó chủ yếu là một lượt gửi bình thường, chỉ có một phần nhỏ phía sau được hẹn giờ. Điều này thường gặp ở danh sách mới, và không phải là thất bại.
Hãy dùng tính năng này khi chênh lệch vài giờ sớm hay muộn không làm thay đổi ý nghĩa của email: bản tin, cập nhật sản phẩm hằng tháng, email tổng hợp nội dung, email nuôi dưỡng gửi tới một phân khúc có tương tác.
Đừng dùng khi bản thân thời điểm chính là thông điệp: lời nhắc webinar lúc 14:00 hôm nay, đợt giảm giá kết thúc lúc nửa đêm, thông báo gắn với một thông cáo báo chí. Với những trường hợp đó, hãy dùng “Lên lịch”.
Chọn đúng thời điểm không cứu được một email bị lỗi. Hãy rà soát theo danh sách kiểm tra chất lượng email trước khi gửi trước khi chọn thời điểm bắt đầu.
Những điều khác cần biết:
Intelligent Send không giữ lại nhóm đối chứng và cũng không báo cáo mức tăng (lift), nên bạn cần tự so sánh và cẩn thận với hiệu ứng pha loãng. Chỉ những liên hệ được hẹn giờ mới có thể thay đổi kết quả. Chia 20.000 liên hệ thành hai nửa, mỗi nửa 10.000, và giả sử 35% của nửa dùng Intelligent Send được hẹn giờ. Nếu việc hẹn giờ nâng tỷ lệ nhấp của nhóm đó từ 3,0% lên 3,6%, một kết quả tốt, thì cả nửa đó chỉ tăng từ 3,0% lên khoảng 3,2%. Với 10.000 liên hệ mỗi nửa, chênh lệch 0,2 điểm phần trăm ở mức tỷ lệ nhấp 3% nằm trong mức nhiễu thông thường giữa các lượt gửi. Bạn sẽ kết luận rằng tính năng không hiệu quả.
Vì vậy, hãy kiểm tra trên những liên hệ có thể được hẹn giờ:
Hướng dẫn thử nghiệm A/B đề cập đến cỡ mẫu, còn bài những chỉ số thực sự quan trọng giải thích vì sao lượt nhấp là tín hiệu đáng tin hơn.
Tính năng hoạt động ở mọi nơi bạn có thể gửi email:
POST /v1/sends với smartSend: true, thêm scheduledAt nếu muốn bắt đầu muộn hơn.send_email nhận tham số smartSend, nên bạn có thể yêu cầu Claude hoặc Cursor “gửi bằng Intelligent Send”.Khi đọc lại một lượt gửi, bạn nhận được object smartSend gồm windowEndsAt, assignedViaModel, assignedImmediately và modelFallbacks, tức những con số giống dòng Phân bổ.
Nếu muốn xem tín hiệu thô, GET /v1/contacts/{email}?include=openProfile trả về lịch sử mở của một liên hệ dưới dạng 48 khung nửa giờ theo UTC. Khi một liên hệ có ít nhất 5 lượt mở duy nhất, kết quả có thêm giờ mở tốt nhất, giờ gửi tốt nhất và điểm confidence từ 0 đến 1. Khóa API cần cả phạm vi emails lẫn contacts. Hồ sơ này có thể bao gồm lượt mở tự động, và Intelligent Send không đọc nó. Bộ lập kế hoạch dùng trực tiếp lượt mở và lượt nhấp của người thật.
Không. Liên hệ không có lịch sử, hoặc có giờ tốt nhất trùng với giờ bắt đầu, sẽ nhận email vào thời điểm bắt đầu. Chỉ những liên hệ có lịch sử cho thấy giờ muộn hơn mới phải chờ, và chỉ chờ đến đúng giờ đó.
Lúc đầu thì chưa. Khi chưa ghi nhận lượt mở hay lượt nhấp nào của người thật, mọi người đều nhận email vào thời điểm bắt đầu. Tính năng chỉ phát huy tác dụng sau khi có dữ liệu tương tác từ vài lượt gửi.
Không. Thời điểm bắt đầu vẫn là thời điểm gửi cho tất cả những ai chưa có lịch sử, và nó quyết định khung 24 giờ. Hãy chọn một thời điểm mà bạn vẫn thấy ổn nếu đó là một lượt gửi bình thường.
Không. Tính năng chỉ dùng thời điểm mà mỗi người đã mở và nhấp email trước đây, và đó là bằng chứng đáng tin hơn một múi giờ được lưu sẵn.
