Tài khoản nhiều loại tiền làm sai mọi ngưỡng cảnh báo

Bạn dựng một quy tắc phòng thủ rất hợp lý cho tài khoản quảng cáo: cảnh báo khi chiến dịch nào chi tiêu vượt 500. Nếu bạn quản nhiều tài khoản và trong đó có tài khoản tính bằng đô la lẫn tài khoản tính bằng đồng, con số 500 đó vừa tạo ra hai kết quả cách nhau khoảng hai mươi lăm nghìn lần, và không có gì trên màn hình cho bạn biết.

Trên tài khoản đô la, 500 là năm trăm đô, khoảng mười hai triệu bảy, chỉ chiến dịch lớn mới chạm tới. Trên tài khoản đồng, 500 là năm trăm đồng, chưa tới hai xu Mỹ, mọi chiến dịch đang chạy đều vượt. Cùng một dòng cấu hình. Một bên ngưỡng không bao giờ kích hoạt nên không chặn được gì, một bên kích hoạt với tất cả nên nếu hành động là tạm dừng thì cả danh mục tắt trong một buổi sáng.

Tài khoản nhiều loại tiền làm sai mọi ngưỡng theo cách đó, và vì cả hai kiểu sai đều không sinh ra thông báo lỗi nào nên bạn chỉ phát hiện khi đã mất tiền. Bài này chỉ bạn cách nhận ra tài khoản mình có dính không, ba cách xử lý cùng lý do hai trong ba cách là sai, và một bảng rà làm được trong một buổi.

Vì sao đơn vị tiền lại là chỗ dễ sai

Trong kho dữ liệu của bất kỳ công cụ nào, chi tiêu chỉ là một con số. Đơn vị tiền nằm ở chỗ khác, nó là thuộc tính của tài khoản quảng cáo chứ không đi kèm từng con số.

Khi bạn gõ một ngưỡng, bạn nghĩ bằng đơn vị của tài khoản đang hình dung trong đầu. Còn hệ thống thì so sánh ngưỡng đó với mọi tài khoản nằm trong phạm vi của quy tắc. Nếu phạm vi trộn nhiều đơn vị, phép so sánh trở nên vô nghĩa, và không có gì báo lỗi vì về mặt kỹ thuật thì hai con số vẫn so sánh được với nhau.

Chuyện này gần như không xảy ra với đội chỉ chạy một thị trường, vì giả định "mọi tài khoản đều dùng một loại tiền" luôn đúng nên không bao giờ bị thử thách. Nó xuất hiện đúng vào lúc bạn mở tài khoản thứ hai ở nước khác, hoặc nhận một khách nước ngoài, hoặc một agency gộp thêm tài khoản của khách mới vào cùng một cấu hình.

Và nó xuất hiện trong im lặng, vì tài khoản mới cũng chạy bình thường, quy tắc cũ cũng chạy bình thường. Thứ duy nhất đổi là ý nghĩa của những con số bạn đã gõ từ trước.

Phát hiện ra lúc nào và bằng cách nào

Chuyện này thường không lộ ra lúc thiết kế mà lộ lúc kiểm chứng.

Trong một đợt rà từng nút của công cụ tự động hoá, một thứ phải kiểm là câu ghi chú hiển thị cho người dùng khi họ đặt ngưỡng tiền. Câu đó ghi cứng đơn vị là đồng, trong khi kho dữ liệu có cả tài khoản đô la lẫn tài khoản đồng.

Nghĩa là với người đang cấu hình cho tài khoản đô la, câu ghi chú đang nói sai. Và tệ hơn, nếu một quy tắc áp lên phạm vi gồm cả hai loại tài khoản thì không có cách nào đúng cả, dù đơn vị hiển thị là gì.

Đây là loại lỗi cùng họ với chuyện ngưỡng bằng 0 bị hiểu thành không có ngưỡng: hệ thống chạy trơn tru, không báo lỗi, kết quả trông hợp lý. Chỉ khi ngồi đối chiếu ý định người dùng với hành vi thật thì mới lộ ra.

Bạn tự kiểm được chuyện này trên công cụ mình đang dùng bằng ba bước, không cần biết lập trình:

• Mở danh sách tài khoản quảng cáo và ghi lại đơn vị tiền của từng cái. Nếu có từ hai đơn vị trở lên, bạn nằm trong diện có thể dính.
• Mở từng quy tắc có ngưỡng tiền, xem phạm vi áp dụng gồm những tài khoản nào. Quy tắc nào phủ nhiều đơn vị là quy tắc đang sai, dù nó có vẻ chạy bình thường.
• Tìm ô chọn đơn vị ở chỗ đặt ngưỡng. Không có ô đó nghĩa là công cụ đang giả định một đơn vị nào đó cho mọi tài khoản, và bạn nên hỏi nhà cung cấp nó đang giả định gì.

Ba cách xử, và vì sao hai cách sai

Cách một: tự quy đổi theo tỉ giá

Cách này nghe hợp lý nhất. Hệ thống lấy tỉ giá hiện tại, quy mọi con số về một đơn vị chung, rồi so sánh. Bạn không phải làm gì thêm.

Ba lý do khiến nó hỏng, và lý do thứ ba mới là lý do quyết định.

Tỉ giá đổi hằng ngày. Cùng một ngưỡng cho kết quả khác nhau theo ngày. Hôm nay chiến dịch không khớp, mai khớp, không phải vì chiến dịch đổi mà vì tỉ giá đổi. Nhìn vào bạn không thể hiểu nổi vì sao.

Lấy tỉ giá ở đâu. Mọi nguồn tỉ giá đều khác nhau chút ít, và đều có lúc trục trặc. Khi nguồn tỉ giá không phản hồi, hệ thống làm gì? Dùng tỉ giá cũ, hay bỏ qua quy tắc? Mỗi phương án tạo ra một loại lỗi mới, và cả hai đều im lặng.

Không truy nguyên được. Ba tháng sau bạn hỏi vì sao chiến dịch này bị tạm dừng hôm mười lăm tháng sáu. Để trả lời, phải biết tỉ giá lúc đó là bao nhiêu, lấy từ nguồn nào, vào giờ nào. Không lưu thì không truy được. Lưu thì phải lưu tỉ giá kèm mọi bản ghi, phức tạp hơn nhiều so với giá trị nó mang lại.

Một quyết định tắt chiến dịch mà không giải thích được là loại quyết định không nên để hệ thống nào đưa ra.

Cách hai: bỏ qua đơn vị, coi số là số

Đây là cách phần lớn công cụ đang chạy khi chưa ai nghĩ tới vấn đề, và nó tệ nhất.

Không có cảnh báo, không có gì để bạn nhận ra. Với tài khoản đồng, ngưỡng 500 khiến mọi chiến dịch khớp, và nếu quy tắc đó có hành động tạm dừng thì hậu quả xảy ra ngay trong lượt chạy đầu tiên.

Thứ duy nhất cứu bạn trong trường hợp đó là lớp giới hạn số lượng, tức là mỗi lượt chạy chỉ được đụng tối đa mấy chiến dịch. Đó là may, không phải thiết kế.

Cách ba: bắt chọn đơn vị và chặn khi trộn

Mỗi ngưỡng có dính tới tiền phải kèm một lựa chọn đơn vị. Hệ thống lọc chiến dịch theo đúng đơn vị đó. Và nếu phạm vi của quy tắc bao gồm nhiều đơn vị lẫn lộn, hệ thống chặn không cho chạy và nói rõ lý do.

Bạn mất thêm một cú bấm. Hệ thống mất đi một cách sai âm thầm.

Vì sao chặn là quyết định khó

Về mặt sản phẩm, chặn là lựa chọn tệ nhất. Nó thêm bước, nó tạo ra thông báo lỗi, nó làm quy trình dài hơn. Trong mọi cuộc bàn về trải nghiệm người dùng, chặn luôn là phương án bị phản đối.

Lập luận ủng hộ nó chỉ có một, nhưng đủ mạnh: với tiền của người khác, phiền còn hơn đoán sai.

Có một lập luận phụ đáng nói. Khi hệ thống chặn, bạn học được điều gì đó: bạn nhận ra phạm vi mình chọn đang trộn nhiều loại tài khoản, thứ mà có thể chính bạn cũng chưa nhận ra. Thông báo chặn không chỉ ngăn lỗi, nó còn chỉ ra chỗ cấu hình sai. Khi hệ thống tự đoán, bạn không học được gì và cũng không biết mình đang không biết.

Cách chọn này cũng có giá của nó, và nên nói ra để bạn cân nhắc khi chọn công cụ. Người chỉ có một loại tài khoản vẫn phải chọn đơn vị mỗi lần đặt ngưỡng, thao tác đó thừa với họ. Một agency quản ba mươi tài khoản ở nhiều nước không viết được một quy tắc duy nhất áp cho tất cả mà phải tách theo đơn vị tiền. Và thông báo chặn dễ bị hiểu là phần mềm hỏng chứ không phải cấu hình sai, nên nó phải viết cho rõ mới có tác dụng.

Nếu không sửa thì hỏng theo hai hướng

Hình dung cụ thể sẽ rõ hơn. Giả sử một agency quản hai mươi tài khoản: mười lăm tài khoản trong nước tính bằng đồng, năm tài khoản khu vực tính bằng đô la. Họ dựng một quy tắc phòng thủ: nếu chiến dịch chi tiêu vượt 2.000.000 mà không có kết quả nào, tạm dừng.

Ý định rõ ràng: hai triệu đồng là ngưỡng đau với tài khoản trong nước.

Hướng hỏng thứ nhất: ngưỡng không chặn được gì. Trên năm tài khoản đô la, hai triệu đô là con số không tài khoản nào chạm tới. Quy tắc không bao giờ kích hoạt ở đó. Năm tài khoản này mất hoàn toàn lớp bảo vệ mà agency tưởng là đang có. Và không có gì báo cho họ biết: nhật ký ghi "đã chạy, không có hành động", đúng như một tài khoản khoẻ mạnh.

Hướng hỏng thứ hai: ngưỡng quét sạch. Nếu ngưỡng được đặt theo góc nhìn đô la, chẳng hạn "chi tiêu vượt 200 mà không kết quả", thì trên mười lăm tài khoản đồng, hai trăm đồng là số tiền không tồn tại. Mọi chiến dịch đều vượt, và nếu hành động là tạm dừng thì cả danh mục bị tắt.

Hai kịch bản, một sai theo hướng không bảo vệ gì, một sai theo hướng phá huỷ, cả hai đến từ cùng một chỗ thiếu.

Ngưỡng trôi theo tỉ giá trông như thế nào

Nếu công cụ của bạn chọn cách tự quy đổi, vấn đề đổi hình dạng chứ không mất đi. Ngưỡng của bạn đứng yên, nhưng cái nó chặn thì trôi theo tỉ giá mỗi ngày.

Hệ quả thực tế của chuyện trôi này gồm ba thứ.

Kết quả không lặp lại được. Chạy cùng một quy tắc trên cùng một tập chiến dịch, hai ngày khác nhau, ra hai danh sách khác nhau. Khi bạn muốn kiểm chứng một nghi ngờ, bạn không có điểm tựa nào.

Không quy trách nhiệm được. Một chiến dịch bị tạm dừng ở gần ranh giới ngưỡng thì lý do thật là tỉ giá hôm đó, chứ không phải hiệu quả của chiến dịch. Khi khách hỏi, bạn không có câu trả lời nào nghe được.

Sai lệch dồn về một phía trong thời gian dài. Nếu tỉ giá đi theo một chiều suốt vài tháng, ngưỡng thực tế của bạn siết dần hoặc nới dần mà không ai quyết định chuyện đó. Đây là kiểu sai khó thấy nhất, vì mỗi ngày chỉ lệch một chút.

Nếu bạn buộc phải dùng một công cụ có quy đổi tự động, tối thiểu hãy yêu cầu hai thứ: hệ thống ghi rõ tỉ giá đã dùng vào từng bản ghi để sau này truy lại được, và hiện rõ cho bạn thấy nó đang quy đổi chứ không im lặng làm. Thiếu hai thứ đó thì đừng để quy tắc nào có quyền tự thực hiện, chỉ để ở chế độ đề xuất.

Cách hiển thị đơn vị tiền cho người dùng không nhầm

Phần này về giao diện, và nó quan trọng hơn vẻ ngoài của nó. Sau khi quyết định bắt chọn đơn vị, câu hỏi tiếp theo là hiển thị thế nào để người dùng không thấy phiền mà cũng không lướt qua.

Ô chọn riêng cạnh ô số. Rõ ràng nhưng làm giao diện rối, và người dùng hay bỏ qua vì nó trông như tuỳ chọn phụ.

Gắn đơn vị vào chính ô nhập. Người dùng gõ số, đơn vị hiện ngay bên trong ô. Gọn hơn, nhưng khi cần đổi đơn vị thì không rõ bấm vào đâu.

Đơn vị là một phần của nhãn ngưỡng. Thay vì "Ngưỡng chi tiêu" thì ghi "Ngưỡng chi tiêu (chọn đơn vị)". Người dùng buộc phải nhìn thấy nó khi đọc nhãn, không thể lướt qua.

Nguyên tắc đó áp cả cho thông báo chặn. Một thông báo ghi "phạm vi không hợp lệ" thì đúng về kỹ thuật và vô dụng với người đọc. Thông báo dùng được phải nói rõ: phạm vi này gồm tài khoản dùng nhiều loại tiền khác nhau, hãy tách quy tắc hoặc thu hẹp phạm vi. Chênh lệch giữa hai bản không nằm ở chức năng mà ở chỗ bản sau cho người đọc biết phải làm gì tiếp.

Nếu bạn tự dựng bảng theo dõi cho đội mình, cùng một nguyên tắc áp được: ghi đơn vị ngay trên tiêu đề cột, đừng để ở chú thích cuối bảng. Cuối bảng là chỗ không ai đọc, và khi file được gửi đi thì phần chú thích thường bị cắt mất.

Bốn chỗ khác trong quảng cáo cũng thiếu đơn vị

Đơn vị tiền là ví dụ dễ thấy nhất, nhưng cùng một cái bẫy có ở nhiều chỗ khác. Bốn chỗ dưới đây gặp thường xuyên và cách nào cũng làm ngưỡng sai theo kiểu im lặng.

Múi giờ: "chi tiêu hôm nay" là hôm nay theo giờ nào

Tài khoản quảng cáo có múi giờ riêng, do người tạo tài khoản chọn và thường không đổi được sau đó. Máy chủ của công cụ có múi giờ khác. Bạn ngồi ở múi giờ thứ ba. Một quy tắc so sánh chi tiêu theo ngày mà không xác định rõ ngày theo múi giờ nào sẽ cho kết quả lệch, rõ nhất vào những giờ gần nửa đêm và vào ngày đầu tháng khi bạn đối chiếu hoá đơn.

Cách kiểm: lấy chi tiêu một ngày bất kỳ trong công cụ, so với chi tiêu cùng ngày đó lấy thẳng từ giao diện nền tảng. Lệch nghĩa là hai bên đang cắt ngày ở hai thời điểm khác nhau.

Phần trăm: 2,5 hay 0,025

Tỉ lệ nhấp trả về là 2,5 hay 0,025? Cả hai cách đều phổ biến, tuỳ nền tảng và tuỳ giao diện lập trình. Một ngưỡng đặt theo cách này áp lên dữ liệu theo cách kia sẽ sai đúng một trăm lần, và vì cả hai con số đều trông hợp lý nên rất khó nhận ra.

Cùng loại vấn đề với mọi con số phần trăm khác: mức điều chỉnh giá thầu, tỉ lệ chuyển đổi, tỉ lệ xem hết. Cách kiểm: đặt một ngưỡng ở mức mà bạn biết chắc phải khớp với một chiến dịch cụ thể, chạy, xem có khớp không.

Cửa sổ quy kết: "20 chuyển đổi" của ai

Số chuyển đổi của một chiến dịch phụ thuộc vào cửa sổ quy kết, tức là bao nhiêu ngày sau khi nhấp thì chuyển đổi vẫn được tính về chiến dịch đó. Mỗi nền tảng có mặc định khác nhau, và người dùng đổi được.

Nghĩa là 20 chuyển đổi trên tài khoản đặt cửa sổ bảy ngày và 20 chuyển đổi trên tài khoản đặt cửa sổ hai mươi tám ngày không phải cùng một thứ. So sánh trực tiếp là sai, và không có gì trên màn hình cho biết. Nếu bạn có một quy tắc dạng "tạm dừng chiến dịch dưới 5 chuyển đổi trong 14 ngày", quy tắc đó khắt khe hơn hẳn với những tài khoản đặt cửa sổ ngắn.

Ngân sách ngày và ngân sách trọn đời

Một chiến dịch có thể đặt ngân sách theo ngày hoặc theo trọn đời chiến dịch. Cùng con số 5.000.000 mang hai ý nghĩa hoàn toàn khác: một là tiêu mỗi ngày, một là tiêu tổng cộng cho cả đợt.

Quy tắc "tăng ngân sách 20%" áp lên hai loại này cho hai kết quả rất khác. Với ngân sách ngày, tăng 20% nghĩa là mỗi ngày tiêu thêm. Với ngân sách trọn đời, nó nghĩa là kéo dài hoặc tăng tốc, tuỳ nền tảng diễn giải. Cách xử duy nhất đúng là quy tắc phải biết loại ngân sách và xử lý riêng, không gộp làm một.

Bốn chỗ trên có chung một đặc điểm với chuyện đơn vị tiền: con số trông giống nhau, ý nghĩa khác nhau, và không có gì cảnh báo.

Nguyên tắc chung: viết đơn vị ngay cạnh con số

Nếu rút gọn cả bài này thành một câu để mang đi, thì là câu này: mọi con số có đơn vị đều phải mang đơn vị theo, ở mọi chỗ nó xuất hiện. Trong kho dữ liệu, trong giao diện, trong nhật ký, trong email báo cáo, trong tài liệu nội bộ của đội.

Nghe thừa thãi. Nhưng cái giá của việc không làm là loại lỗi không bao giờ báo, và loại lỗi đó đắt hơn nhiều so với vài ký tự thừa trên màn hình.

Có một cách kiểm nhanh cho bất kỳ hệ thống nào: lấy một con số bất kỳ và hỏi đơn vị của nó nằm ở đâu. Nếu câu trả lời là "trong đầu người viết mã" hoặc "ai làm nghề này cũng biết", đó là chỗ lỗi đang chờ. Câu trả lời tốt phải là: đơn vị nằm ngay cạnh con số, trong cùng bản ghi, và đi theo nó tới mọi nơi con số đi.

Nguyên tắc này áp được cả cho những chỗ không liên quan gì tới phần mềm. Con số "giá mỗi đơn tối đa" trong tài liệu nội bộ của đội bạn có ghi đơn vị không? Nhiều đội chỉ ghi 180 và ai cũng ngầm hiểu là nghìn đồng, cho tới khi có nhân sự mới hoặc có khách nước ngoài đọc tài liệu đó.

Bảng rà đơn vị cho tài khoản của bạn

Phần này làm ngay được, không cần công cụ gì, và mất chưa tới một tiếng.

Rà một: liệt kê đơn vị tiền của từng tài khoản. Nghe hiển nhiên, nhưng nhiều đội quản chục tài khoản không có danh sách này ở đâu cả. Mở từng tài khoản, ghi lại đơn vị, lưu thành một bảng. Mất mười lăm phút và là nền cho mọi việc sau.

Rà hai: kiểm mọi quy tắc tự động đang chạy. Với từng quy tắc có ngưỡng tiền, đối chiếu phạm vi áp dụng với bảng vừa lập. Quy tắc nào áp lên nhiều đơn vị là quy tắc đang sai, dù nó có vẻ chạy bình thường. Ghi thêm một cột: quy tắc này đã kích hoạt lần nào trong ba tháng qua chưa. Quy tắc chưa kích hoạt lần nào trên một tài khoản đang tiêu tiền là dấu hiệu mạnh.

Rà ba: kiểm báo cáo tổng hợp. Nếu bạn có bảng tổng hợp chi tiêu nhiều tài khoản, hỏi con số tổng đó được tính thế nào. Cộng thẳng các số bất kể đơn vị là sai. Nếu có quy đổi thì phải biết quy đổi theo tỉ giá nào và lấy lúc nào.

Rà bốn: kiểm mục tiêu và ngưỡng nội bộ. Mở tài liệu mục tiêu của đội, tìm mọi con số tiền, kiểm xem có ghi đơn vị không. Đây là chỗ ít ai nghĩ tới nhưng gây nhầm nhiều nhất khi có người mới vào.

Rà năm: kiểm file xuất ra. Khi bạn xuất báo cáo gửi khách hoặc gửi kế toán, kiểm lại xem đơn vị có đi theo trong file không. File rời khỏi ngữ cảnh thì người nhận không có gì để đoán, và họ sẽ đoán theo đơn vị quen của họ.

Khi tài khoản thật buộc phải nhiều loại tiền

Chặn là đúng, nhưng nó không giải quyết việc bạn thật sự cần theo dõi cả hai nhóm tài khoản. Bốn cách làm dưới đây dùng được ngay với công cụ hiện tại của bạn.

Tách quy tắc theo đơn vị, đặt tên rõ. Thay một quy tắc phủ cả hai mươi tài khoản bằng hai quy tắc, mỗi cái phủ một nhóm đơn vị. Đặt tên có ghi đơn vị ngay trong tên, chẳng hạn "Chặn chi tiêu vô ích — nhóm VND" và "Chặn chi tiêu vô ích — nhóm USD". Tên là chỗ duy nhất bạn nhìn thấy khi lướt danh sách quy tắc, nên đơn vị phải nằm ở đó.

Quy ngưỡng ra tỉ lệ thay vì ra tiền, ở những chỗ làm được. Nhiều ngưỡng viết lại được dưới dạng không có đơn vị tiền: "chi tiêu vượt 150% ngân sách ngày", "chi phí mỗi đơn cao hơn mục tiêu 40%", "chi tiêu chiếm quá 30% tổng chi của tài khoản". Những ngưỡng dạng này đúng cho mọi đơn vị tiền và không trôi theo tỉ giá. Đây là cách xử tốt nhất khi làm được, và làm được ở nhiều chỗ hơn bạn nghĩ.

Đặt ngưỡng bằng số đếm khi tỉ lệ không hợp. Số ngày liên tiếp không có chuyển đổi, số lượt nhấp không ra kết quả, số ngày chiến dịch chạm trần ngân sách. Những con số này không có đơn vị tiền nên không dính vấn đề, và với nhiều tình huống cảnh báo thì chúng còn nói đúng hơn con số tiền.

Gom tài khoản theo đơn vị ngay từ cấu trúc. Nếu công cụ cho phép nhóm tài khoản, tạo nhóm theo đơn vị tiền chứ đừng nhóm theo khách hàng hay theo thị trường. Sau đó mọi quy tắc đều áp lên nhóm, và bạn không bao giờ vô tình trộn.

Khi một chiến dịch chuyển giữa hai tài khoản khác đơn vị

Tình huống này ít gặp hơn nhưng khi gặp thì rối, nên đáng biết trước.

Nền tảng quảng cáo thường không cho đổi đơn vị tiền của một tài khoản sau khi tạo, chính vì lý do tương tự. Nên khi cần đổi, người ta tạo tài khoản mới rồi dựng lại chiến dịch ở đó. Ba chuyện xảy ra ngay sau đó, và ba chuyện đều làm số liệu của bạn không so sánh được.

Lịch sử không đi theo. Chiến dịch mới bắt đầu từ con số không, kể cả khi nó là bản sao. Mọi ngưỡng dựa trên số liệu nhiều ngày sẽ không có gì để đọc trong tuần đầu, và những quy tắc dạng "so với 30 ngày trước" sẽ im lặng vì thiếu dữ liệu chứ không phải vì mọi thứ ổn.

Giai đoạn học lại. Chiến dịch mới phải học lại phân phối, nên chi phí mỗi kết quả những ngày đầu thường xấu hơn bình thường. Nếu quy tắc phòng thủ của bạn vẫn đang trỏ vào tài khoản mới, nó sẽ tạm dừng đúng những chiến dịch chỉ đang khởi động.

Phạm vi quy tắc không tự cập nhật. Quy tắc cũ vẫn trỏ vào tài khoản cũ, tài khoản mới thì chưa quy tắc nào phủ. Đây là chỗ hay quên nhất, và nó tạo ra một khoảng thời gian tài khoản mới chạy hoàn toàn không có lớp bảo vệ nào.

Việc cần làm khi chuyển: cập nhật phạm vi quy tắc trước khi bật chiến dịch mới, tạm nới ngưỡng phòng thủ trong hai tuần đầu, và ghi một dòng vào nhật ký của đội về mốc chuyển để sau này ai đọc số liệu cũng biết vì sao có một vết đứt ở đó.

Vấn đề báo cáo mà cách làm này tạo ra

Chặn trộn đơn vị giải quyết được chuyện quy tắc chạy sai, nhưng nó đẩy vấn đề sang phía báo cáo, và phần đó bạn vẫn phải tự xử.

Khi bạn cần một con số tổng cho cả danh mục, bạn buộc phải quy đổi ở đâu đó. Ba nguyên tắc giữ cho con số tổng đó dùng được:

Ghi rõ tỉ giá và thời điểm lấy, ngay trong bảng. Một dòng nhỏ dưới tiêu đề bảng là đủ. Không có nó thì ba tháng sau không ai dựng lại được con số.

Dùng một tỉ giá cố định cho cả kỳ báo cáo. Chốt tỉ giá đầu kỳ và dùng nguyên cho tới hết kỳ. Con số sẽ lệch một chút so với thực tế, nhưng bù lại các kỳ so được với nhau, và đó mới là thứ báo cáo cần. Nếu bạn cần con số chính xác về mặt kế toán, lấy từ hoá đơn của nền tảng chứ đừng lấy từ báo cáo quảng cáo.

Luôn để cột số gốc bên cạnh cột số đã quy đổi. Người đọc cần đối chiếu với giao diện nền tảng, mà giao diện nền tảng hiện số gốc.

Hai chỗ nữa hay làm lệch số khi đối chiếu với kế toán, và cả hai đều là chuyện đơn vị.

Đơn vị nhỏ nhất của tiền. Nhiều giao diện lập trình trả về số tiền theo đơn vị nhỏ nhất, tức là xu thay vì đô. Một hệ thống đọc nhầm sẽ hiểu 500 xu thành 500 đô, sai đúng một trăm lần. Đây là lỗi kinh điển và vẫn xảy ra thường xuyên, nhất là khi đội tự dựng bảng lấy dữ liệu qua giao diện lập trình.

Chi tiêu đã gồm thuế hay chưa. Tuỳ nền tảng và tuỳ nước, con số chi tiêu trong báo cáo có thể đã gồm thuế hoặc chưa, chênh lệch cỡ mười phần trăm. Với một quy tắc đặt ngưỡng sát, mười phần trăm đủ để đổi kết quả. Và khi đối chiếu với sổ sách, chênh lệch này là nguyên nhân phổ biến nhất của những cuộc tranh luận kiểu "số của marketing không khớp số của kế toán".

Cách hỏi công cụ bạn đang dùng

Bốn câu dưới đây hỏi được trong một email, và câu trả lời nói lên nhiều hơn phần giới thiệu sản phẩm.

"Ngưỡng tiền trong hệ thống có gắn đơn vị không, hay hệ thống giả định một đơn vị?" Nếu là giả định, hỏi tiếp nó giả định gì và giả định đó ghi ở đâu.

"Nếu một quy tắc áp lên tài khoản nhiều đơn vị thì hệ thống làm gì?" Chặn là tốt. Tự quy đổi thì hỏi tiếp có lưu tỉ giá vào bản ghi không. Chạy bình thường là câu trả lời đáng lo nhất.

"Chi tiêu hôm nay trong hệ thống tính theo múi giờ nào?" Câu trả lời rõ ràng là dấu hiệu tốt. Câu trả lời mơ hồ nghĩa là có thể chưa ai nghĩ tới.

"Nhật ký có ghi đơn vị kèm mỗi con số không?" Bạn kiểm được ngay bằng cách mở một bản ghi gần nhất ra xem. Nếu chỉ ghi con số trần, ba tháng sau bạn không truy lại được.

Có một cách nhìn chung rút ra từ cả câu chuyện này khi chọn công cụ tự động: đừng chỉ hỏi công cụ làm được gì, hỏi thêm khi không chắc chắn thì nó làm gì. Công cụ tốt dừng lại và hỏi. Công cụ tệ đoán rồi đi tiếp. Cả hai đều chạy trơn tru trong buổi giới thiệu sản phẩm, và chỉ khác nhau ở những tình huống biên. Nếu câu trả lời là "hệ thống không bao giờ từ chối chạy", nghĩa là nó luôn đoán, và với hệ thống đụng tới tiền thì luôn đoán không phải điểm mạnh.

Câu hỏi thường gặp

Vì sao nền tảng quảng cáo không giải quyết giúp chuyện này?

Vì với nền tảng, mỗi tài khoản là một thế giới riêng và luôn có đúng một đơn vị tiền, nên trong phạm vi một tài khoản không có vấn đề gì để giải quyết. Vấn đề chỉ sinh ra ở lớp bên trên, khi một công cụ nhìn nhiều tài khoản cùng lúc. Đó cũng là lý do lỗi này chỉ xuất hiện ở công cụ quản nhiều tài khoản chứ không xuất hiện trong giao diện gốc của nền tảng.

Nếu tôi chỉ có một loại tài khoản thì có bị ảnh hưởng không?

Không, ngoài việc phải chọn đơn vị một lần khi tạo ngưỡng. Nhưng nên biết trước, vì ngày bạn nhận khách nước ngoài đầu tiên là ngày mọi quy tắc cũ của bạn cần được rà lại.

Vì sao không tự nhận diện đơn vị từ tài khoản?

Hệ thống nhận diện được đơn vị của từng tài khoản. Vấn đề là ngưỡng gắn với quy tắc, mà quy tắc có thể áp lên nhiều tài khoản khác đơn vị. Nên vẫn cần bạn nói rõ ý mình, hệ thống không đoán thay được.

Đổi đơn vị của một ngưỡng đã chạy lâu thì có ảnh hưởng lịch sử không?

Không. Những gì đã thực hiện vẫn nằm nguyên trong nhật ký kèm đơn vị lúc đó, ngưỡng mới chỉ áp cho các lượt chạy sau. Nhưng nên ghi một dòng ghi chú lý do đổi, vì khi so số liệu trước và sau mốc đổi, phần chênh lệch cần có lời giải thích.

Có công cụ nào tự phát hiện lỗi đơn vị không?

Không có công cụ chung, vì đơn vị là chuyện ngữ nghĩa chứ không phải cú pháp, máy nhìn vào chỉ thấy một con số hợp lệ. Cách duy nhất là quy ước: bắt buộc mọi trường tiền phải kèm trường đơn vị, và bắt buộc mọi phép so sánh phải kiểm đơn vị trước khi so.

Bài kiểm nào nhanh nhất để biết công cụ có vấn đề này không?

Mở chỗ đặt ngưỡng tiền và tìm ô chọn đơn vị. Không có ô đó nghĩa là công cụ đang giả định, và bạn nên hỏi nó giả định gì. Nếu bạn có sẵn hai loại tài khoản, tạo thử một quy tắc áp lên cả hai và xem hệ thống phản ứng thế nào: chặn là tốt, chạy bình thường là dấu hiệu đáng lo.

Đội tôi tự dựng bảng báo cáo thì cần lưu ý gì?

Ba việc. Mọi cột tiền phải ghi đơn vị ngay trên tiêu đề cột, không để ở chú thích cuối bảng. Nếu bảng gộp nhiều tài khoản khác đơn vị thì đừng cộng tổng, hoặc tách bảng, hoặc quy đổi và ghi rõ tỉ giá cùng thời điểm lấy. Và khi xuất file gửi người khác, kiểm lại xem đơn vị có đi theo không.

Đọc thêm: phân bổ ngân sách giữa nhiều nền tảng, chống rò rỉ chi tiêu bằng trần ngân sách, và vì sao AI phải giải thích được quyết định của mình.

Nếu bạn muốn xem cách ngưỡng nhiều đơn vị được xử lý trên tài khoản của mình, bắt đầu ở orova.vn.