Email Analytics cho Shopify đa cửa hàng: Hai cửa sổ chúng tôi dùng để quy đổi doanh thu

Email analytics Shopify đa cửa hàng: vì sao chúng tôi quy đổi doanh thu theo 2 cửa sổ 5 ngày và 14 ngày, và vì sao open rate không quyết định gì.

Linh Nguyen · Cập nhật 2026-07-15

Chúng tôi dành hai ngày 14 và 15/07/2026 để xây email analytics vào hệ thống đang dùng vận hành các store Shopify của mình. Không phải làm thử — mà là thiết kế lại màn Overview, các chỉ số tiền, click analytics tới từng link, phân khúc RFM và một lớp benchmark, ship theo từng phase trong hai ngày. Bài này nói về quyết định mất nhiều thời gian nhất, và nó không phải cái biểu đồ nào cả: đó là quyết định đơn nào được tính cho email nào, và tính trong bao lâu.

Nếu bạn chỉ có một store, nền tảng email trả lời hộ bạn và bạn chẳng bao giờ phải nghĩ. Có vài store thì câu hỏi này sắc lại ngay, vì mỗi nền tảng trả lời một kiểu và không cái nào khớp cái nào. Phần gửi thì thiết lập quản lý Gmail và Outlook của chúng tôi đã gom chung giữa các store từ trước; quy đổi doanh thu mới là chỗ việc gom chung trở nên thực sự khó.

Hai cửa sổ, vì một con số sẽ nói dối

Cuối cùng chúng tôi dùng hai cửa sổ quy đổi, cố tình không gộp:

ATTRIBUTION_WINDOW_DAYS = 5          // last-touch: email khách có tương tác trước khi đặt
ONSITE_ATTRIBUTION_WINDOW_DAYS = 14  // xác định: token click sống tới lúc checkout

Cửa sổ 5 ngày là last-touch. Một đơn được tính cho email có tương tác gần nhất gửi tới địa chỉ đó trong vòng 5 ngày trước khi đặt. Đây là tương quan, không phải bằng chứng: khách mở hoặc click cái gì đó, rồi mua. Để 5 ngày là có chủ đích — nó phải ngắn hơn hẳn thời gian lưu của chính email log, nếu không bản ghi đối chiếu đã bị xoá trước khi đơn về và phần credit biến mất trong im lặng.

Cửa sổ 14 ngày khác về bản chất. Đó là tín hiệu click→đơn mang tính xác định: một token (sf_e) được đặt khi khách click từ email, rồi đọc lại lúc checkout. Đây là chuỗi bằng chứng thật, không phải trùng hợp, nên nó xứng đáng cửa sổ dài hơn. Nhưng vẫn phải chặn, và lý do rất tầm thường — một token cũ nằm lì trong localStorage sẽ vui vẻ tính công một đơn hàng vài tuần sau cho email chẳng liên quan gì. 14 ngày là câu trả lời của chúng tôi cho câu hỏi "bao lâu thì cái này hết còn là bằng chứng".

Cám dỗ ở đây là cộng cả hai lại thành một con số Doanh thu Email. Chúng tôi không làm, vì hai con số sai theo hai hướng ngược nhau: last-touch tính dư cho email tình cờ ở gần, còn cái xác định thì tính thiếu những người click trên điện thoại rồi mua trên laptop. Hiển thị cả hai, tách riêng, mới là bản trung thực. Một con số gộp sẽ dễ chịu hơn và kém đúng hơn.

Open rate không phải tín hiệu, nhưng chúng tôi vẫn ship nó

Bộ benchmark của chúng tôi gắn cờ open rate là bị thổi phồng chứ không giấu nó đi:

openRate: 0.4,   // MPP thổi phồng — chỉ để tham khảo
clickRate: 0.019,
ctor: 0.1,

Mail Privacy Protection của Apple tải trước ảnh, tức là tự động "mở" email bất kể có người nhìn hay không. Một open rate quanh 40% vì thế là phép đo proxy của Apple, không phải đo tiêu đề email của bạn. Chúng tôi vẫn hiển thị vì người làm marketing sẽ đi tìm nó và thiếu nó thì trông như lỗi — nhưng nó mang cờ cảnh báo, và mọi bề mặt ra quyết định đều được đẩy sang click với doanh thu trên mỗi người nhận.

Một điểm tôi muốn nói thẳng: những con số benchmark đó không phải kết quả của chúng tôi. Đó là các đường tham chiếu chúng tôi lấy từ benchmark ecommerce 2026 của Klaviyo cộng với các nghiên cứu danh mục (BS&Co, Flowium), để một con số có cái mà đối chiếu. Cái đáng ra quyết định nhất là khoảng cách giữa flow và campaign:

campaignRpr: 0.08,  // doanh thu/người nhận, campaign
flowRpr: 1.58       // doanh thu/người nhận, flow

Chênh khoảng 20 lần. Nếu tỷ lệ đó đúng gần đúng với store của bạn, hàm ý rất thẳng: một buổi chiều ngồi sửa flow abandoned-cart bị hỏng ăn đứt một tuần gửi campaign. Chúng tôi vẫn xây màn so sánh campaign, vì bạn vẫn cần biết campaign nào chết — nhưng khoảng cách RPR flow/campaign mới là con số chúng tôi đặt ở chỗ mắt nhìn vào đầu tiên.

Chúng tôi cũng đặt benchmark complaint rate ở 0,001. Cái này không phải để cho đẹp: tỷ lệ báo spam duy trì trên ~0,1% là vùng Gmail và Yahoo ra tay, và với người gửi đa cửa hàng thì bán kính thiệt hại là mọi store dùng chung domain gửi, không riêng store đã gửi campaign tệ đó.

Cái thực sự tốn thời gian

Không phải mấy cái dashboard. Hai lỗi đáng gọi tên:

Một từ khoá dành riêng. Truy vấn RFM của chúng tôi đặt alias cho một cột là at. BigQuery coi at là từ dành riêng nên truy vấn hỏng — sửa mất năm phút (at → last_at) nhưng chỉ lộ ra sau khi phần logic phân khúc trông như đã xong. Bài học không nằm ở chuyện vặt của BigQuery; nó nằm ở chỗ chúng tôi đã viết phần tổng hợp trước khi chạy nó với dữ liệu thật — một thói quen nên bỏ.

Một mốc chặn ngày làm rơi mất một ngày. Các truy vấn click theo link và thời điểm gửi dùng mốc chặn trên loại bỏ mất ngày cuối cùng của mọi khoảng. Không có lỗi nào bắn ra. Biểu đồ vẫn vẽ, số vẫn hợp lý, và mọi khoảng thời gian đều âm thầm thiếu đúng ngày gần nhất — cái ngày mà người làm marketing hay mở lên xem nhất. Chúng tôi nới mốc chặn thêm một ngày. Sai trong im lặng còn tệ hơn một stack trace, và code analytics là chỗ nó ẩn nấp giỏi nhất.

Còn một chiều nữa là chi phí. Click analytics tới từng link trên BigQuery nghĩa là mỗi truy vấn đều quét dữ liệu, nên phase click được ship kèm luôn cơ chế kiểm soát chi phí chứ không để làm sau. Quét-mỗi-câu-hỏi thì ổn với một store và là cú sốc hoá đơn với cả danh mục — cùng cái bẫy mà bài báo cáo và xuất dữ liệu đa cửa hàng chạm tới từ phía bên kia.

Rollout cho đúng một người

Giao diện đọc và các endpoint /api/email/analytics/* hiện chỉ mở cho một tài khoản duy nhất — tài khoản của tôi. Phần tổng hợp thì không khoá: webhook và rollup hằng ngày chạy cho mọi store ngay từ ngày đầu.

Cách tách đó là có chủ đích và tôi sẽ làm lại y vậy. Dữ liệu phải tích luỹ trước thì dashboard mới đáng mở; nếu bạn khoá cả phần thu thập, người dùng đầu tiên sẽ mở ra thấy biểu đồ rỗng và kết luận tính năng này vô dụng. Khoá phần đọc nghĩa là rủi ro rollout nằm trọn ở chuyện ai được nhìn, còn lịch sử vẫn lặng lẽ dựng lên bên dưới. Sai về giao diện thì trả giá bằng một lần thiết kế lại. Sai về thu thập thì trả giá bằng một tháng dữ liệu không bao giờ lấy lại được.

Nếu phải khuyên người mới bắt đầu

Hãy quyết cửa sổ quy đổi trước khi vẽ cái biểu đồ đầu tiên, và viết ra vì sao mỗi con số lại là con số đó. Của chúng tôi là 5 và 14, và không cái nào là "best practice" tôi đọc được ở đâu — 5 bị chặn bởi thời gian lưu log, 14 bị chặn bởi việc một token click còn đáng tin trong bao lâu. Ràng buộc của bạn sẽ khác. Cái không khác là: một dashboard mà quy tắc quy đổi chỉ nằm trong đầu một người sẽ thành thứ không tranh luận được — hai người đọc cùng một con số Doanh thu Email và hiểu hai nghĩa khác nhau, chẳng có cách nào phân xử.

Và nếu chỉ lấy một con số từ bài này, hãy lấy khoảng cách RPR flow/campaign — không phải vì ~20 lần là lời hứa, nó không phải, mà vì đó là benchmark duy nhất trong bộ này làm thay đổi việc bạn sẽ làm vào thứ Hai. Open rate đã là đồ trang trí kể từ khi MPP ra đời. Chúng tôi hiển thị nó kèm nhãn cảnh báo, và thú thật xoá đi thì tôi vui hơn. Để xem nó nằm ở đâu trong bức tranh chỉ số rộng hơn, bộ KPI cho Shopify đa cửa hàng là tấm bản đồ tổng.