Bốn cái bẫy khi tự làm hệ thống đo cuộc gọi

Phần 1 dừng ở chỗ: cách duy nhất còn lại là tự cấp số điện thoại Việt Nam cho từng người xem web. Bài này kể hệ thống đó hoạt động ra sao, và bốn chỗ đã sập phải khi chạy thật trên 1fix.vn, đơn vị dịch vụ sửa chữa nhà tại TP.HCM, hệ thống do chính chúng tôi xây và vận hành.

Bốn cái bẫy này không có trong tài liệu nào. Chúng chỉ hiện ra khi có khách thật gọi vào.

Hệ thống chạy thế nào

Bảy bước, từ lúc khách bấm quảng cáo tới lúc Google học được điều gì đó.

1. Khách bấm quảng cáo. Google gắn vào địa chỉ một mã nhận dạng riêng cho lần bấm đó.
2. Website đọc mã, lưu lại, nhưng vẫn hiện số hotline thật. Đây là chi tiết quan trọng: nếu tráo số ngay lúc tải trang thì công cụ tìm kiếm cũng đọc được số tráo, và số điện thoại của bạn trên Google sẽ loạn.
3. Khách bấm nút gọi. Đúng khoảnh khắc đó, hệ thống mới lấy một số trong kho ra, đổi số trên nút, rồi mới quay máy.
4. Khách gọi vào số đó. Tổng đài nhận cuộc gọi kèm số máy khách và số bị gọi.
5. Hệ thống tra ngược: số bị gọi này vừa cấp cho ai, người đó vào từ quảng cáo nào.
6. Nếu khách chốt đơn, doanh thu thật của đơn đó được nối vào cuộc gọi.
7. Mỗi sáng, toàn bộ dữ liệu đó được đẩy về Google Ads.

Kho số của chúng tôi có 3 số. Nghe ít, nhưng nó vừa đủ vì mỗi số chỉ bị giữ trong 3 phút. Con số 3 phút không phải chọn bừa: đo trên dữ liệu thật, 77% khách gọi trong vòng 1 phút sau khi bấm nút, 82% trong vòng 3 phút. Ai bấm rồi để đó nửa tiếng mới gọi thì hệ thống thà không ghi nhận nguồn còn hơn ghi nhầm. Lý do nằm ở cái bẫy đầu tiên.

Bẫy 1. Cửa sổ tra ngược quá rộng: 168 đơn bị gán nhầm nguồn

Bản đầu tiên tra ngược trong 24 giờ: cuộc gọi vào số X, tìm xem trong 24 giờ qua ai được cấp số X, lấy nguồn quảng cáo của người đó.

Logic này sai ở chỗ chỉ có 3 số trong kho, mỗi số được dùng lại khoảng 17 lần mỗi ngày. Trong 24 giờ, một số đã đi qua tay hơn chục người khác nhau. Cuộc gọi đến sẽ được gán cho ai? Người gần nhất, và người đó thường không phải người đang gọi.

Kết quả: 168 đơn hàng bị gán nhầm nguồn quảng cáo. Tệ hơn cả việc không đo, vì số liệu sai vẫn được đẩy về Google, và Google học theo số sai đó.

Cách sửa: thu cửa sổ tra ngược từ 24 giờ xuống 3 phút, bằng đúng thời gian giữ số. Hệ quả là những cuộc gọi đến muộn không còn nguồn. Đó là đánh đổi có chủ đích: thà thiếu dữ liệu còn hơn có dữ liệu sai. Thiếu thì Google học chậm; sai thì Google học nhầm hướng, và cái đó tốn tiền thật.

Bẫy 2. Múi giờ: lỗi cùng một nguyên nhân, hai lần

Tổng đài gửi thời gian cuộc gọi theo giờ Việt Nam. Cơ sở dữ liệu lưu theo giờ quốc tế. Không ai để ý cho tới khi số liệu vô lý.

Lỗi này gây ra hai sự cố khác nhau. Lần một: phần nối cuộc gọi với đơn hàng so sánh giờ Việt Nam với giờ quốc tế, lệch 7 tiếng nên ghép nhầm cuộc gọi vào đơn của người khác. Lần hai: phần chống trùng lặp lẽ ra chỉ nhìn lại 2 phút, vì lệch múi giờ mà thành nhìn lại 7 tiếng, nghĩa là mọi cuộc gọi trong 7 tiếng đó bị coi là trùng và bị bỏ.

Bài học không phải "nhớ đổi múi giờ". Bài học là: mọi cột thời gian phải ghi rõ nó ở múi giờ nào ngay tại chỗ định nghĩa, và mọi phép so sánh phải quy về một múi trước khi so. Sửa xong lần một mà không ghi lại quy ước thì lần hai vẫn sập, đúng như đã xảy ra.

Bẫy 3. Tổng đài gửi trùng một cuộc gọi

Tổng đài không gửi mỗi cuộc gọi đúng một lần. Nó gửi nhiều lần, với định dạng khác nhau tuỳ chặng: máy lễ tân bắt, chuyển tiếp sang di động, kết thúc.

Bản đầu chống trùng bằng cách: cùng số khách gọi, trong vòng 2 phút, thì coi là một cuộc. Nghe hợp lý cho tới khi gặp khách gọi lại thật sau 90 giây vì lần đầu chưa nói xong. Cuộc thứ hai bị nuốt.

Cách sửa: chống trùng theo file ghi âm thay vì theo cặp số máy và khoảng thời gian. Cùng một cuộc gọi thì cùng một file ghi âm, dù tổng đài báo về mấy lần. Hai cuộc gọi khác nhau thì hai file khác nhau, dù cách nhau 10 giây.

Nguyên tắc rút ra: chống trùng phải dựa trên thứ định danh duy nhất của sự kiện, không dựa trên phỏng đoán theo thời gian.

Bẫy 4. Hai người gọi vào cùng một số

Đây là cái tinh vi nhất, và nó chỉ tồn tại vì kho số nhỏ.

Người A bấm nút, được cấp số X. Trong lúc phiên của A còn sống, người B gọi vào số X. Có thể B lấy số từ ảnh chụp màn hình bạn bè gửi, có thể B là khách cũ lưu số trong danh bạ từ lần trước. Hệ thống thấy cuộc gọi vào số X, tra ra phiên của A, và gán nguồn quảng cáo của A cho cuộc gọi của B.

Nguồn quảng cáo của A vừa bị "lem" sang người khác.

Cách xử lý: trước khi gán, kiểm tra xem số máy đang gọi có phải là người đã được cấp số này không. Nếu là người khác, không gán nguồn. Nhưng bộ lọc này rất dễ chặn nhầm, vì chuông đổ qua nhiều chặng nên cùng một cuộc gọi có thể hiện ra dưới nhiều số máy khác nhau.

Nên nó được bật theo ba nấc:

• Tắt: không kiểm tra gì, giữ nguyên cách cũ.
• Chạy thử: bộ lọc tính toán và ghi lại quyết định của nó, nhưng không thay đổi dữ liệu thật. Chạy như vậy vài tuần trên lưu lượng thật để xem nó định chặn những gì.
• Bật thật: bộ lọc mới thực sự có quyền bỏ nguồn.

Nấc giữa là nấc quan trọng nhất. Chạy thử 11 ngày cho thấy 5 trên 6 trường hợp bộ lọc định chặn là chặn đúng, còn 1 trường hợp là khách thật bị chặn nhầm. Nếu bật thẳng từ đầu thì đã mất đơn đó mà không ai biết vì sao.

Mọi bộ lọc có quyền xoá dữ liệu đều nên có nấc chạy thử. Không có nấc đó, bạn chỉ phát hiện mình chặn nhầm khi khách hàng phàn nàn.

Về chuyện dùng AI để viết phần lớn code

Hệ thống này viết trong khoảng 4 tuần, phần lớn code do AI sinh ra, một người đọc và duyệt toàn bộ.

Điều AI làm tốt: gõ nhanh, dựng khung, tra tài liệu, viết đúng cú pháp thư viện lạ. Điều AI không làm thay được: quyết định thu cửa sổ tra ngược từ 24 giờ xuống 3 phút. Đó không phải câu hỏi kỹ thuật mà là câu hỏi kinh doanh: chấp nhận mất bao nhiêu dữ liệu để đổi lấy dữ liệu còn lại đáng tin. Không đọc dữ liệu thật của chính mình thì không ai trả lời được, kể cả AI.

Cả bốn cái bẫy trên đều được phát hiện bằng cách ngồi đọc số liệu thấy vô lý rồi lần ngược, không phải bằng cách đọc code.

Phần 3 nói về những gì đo được sau khi vá hết bốn chỗ này, và cả những gì vẫn chưa chứng minh được.