Rule đọc dữ liệu theo thứ tự nào

Biết thứ tự này thì phần lớn câu hỏi “sao nó lại làm vậy?” bạn tự trả lời được, không cần hỏi support.

Thứ tự

Một lần chấm đã xong trông như thế này: action trước, rồi tới từng criterion kèm giá trị đã đạt.

1. Lấy assignment

Rule xét các ad group mà nó được gán vào, và các target bên trong. Ngoài assignment thì rule không xét gì cả, trừ phần kiểm tra đơn hàng 365 ngày ở bước 3.

2. Mở cửa sổ dữ liệu

Rule đọc số liệu trong Data Window của nó. Theo mặc định, nó bỏ qua mấy ngày gần nhất vì Amazon vẫn đang ghi nhận thêm đơn cho những ngày đó.

Có hai trigger mode đọc cửa sổ riêng. Performance Deterioration đọc Historical Window cộng hai mốc cố định 60 và 30 ngày. Momentum Guard đọc baseline cộng thang các mốc kiểm tra.

Target không có traffic trong cửa sổ thì không có số liệu nào để đọc, nên hầu hết rule không bao giờ xét tới nó. Riêng hai kiểu rule Bidding vẫn đọc mọi target đang bật trong ad group của mình, kể cả target không có traffic trong cửa sổ:

• rule có action tăng bid một khoản cố định và Criteria đặt mức Impressions tối đa. Rule này chấm target đó với impressions, clicks và orders đều bằng không. Rule Explore trong Starter Rules là một ví dụ;
• rule Momentum Guard dùng thang mốc kiểm tra. Rule này so target đó với baseline, nên một target từng chạy tốt mà nay im hẳn vẫn được chẩn đoán. Rule Momentum cũ lưu ở dạng hai cửa sổ thì không làm vậy.

3. Chốt scope

Với rule Negation và Negation word, Search Term scope (Individual ASIN hoặc Product Group, xem Decision scope) quyết định phần kiểm tra đơn hàng 365 ngày nhìn rộng tới đâu. Chỉ cần có một đơn trong bất kỳ ad group nào đang quảng cáo sản phẩm đó, hoặc bất kỳ sản phẩm nào trong group, là tính, dù ad group đó có được gán hay không. Unnegate cũng có cài đặt này nhưng không có phần kiểm tra đó.

Criteria của các rule này chỉ đọc search term của những ad group mà rule được gán vào. Negation và Unnegation chấm riêng từng ad group. Rule Negation word thì đếm số term khác nhau chứa một từ, gộp trên các ad group được gán có cùng scope. Rule Import không có ô scope. Nguồn search term của nó quyết định nó đọc ở đâu.

Với rule Bidding, bước này áp Rule Applicability thay vào đó: Ad Product, Billing Basis và Target Kind. Target nằm ngoài phạm vi đó bị bỏ qua trước khi rule xét tới các ngưỡng số liệu.

Với Negation, bước này còn gom search term theo campaign, ad group và nhóm biến thể gần giống kiểu close variant của Amazon. Criteria được chấm trên tổng số liệu của cả nhóm, không chấm riêng từng dòng chữ. Negative product target vẫn chấm theo từng dòng. Unnegation thì gom search term theo negative đang chặn chúng, rồi chấm tổng của mọi term mà negative đó che.

4. Áp trigger mode

Trigger mode quyết định action có đáng chạy hay không, trong số các mode mà loại rule đó cho chọn:

• Standard Criteria hỏi: mọi ngưỡng có đạt trong cửa sổ không.
• Loss Budget Guard đo số tiền đã mất vượt quá mức cho phép.
• Momentum Guard chấm Criteria trên một baseline dài, rồi so baseline đó với tốc độ ra đơn ở các mốc kiểm tra ngắn hơn. Chỉ cần một mốc vượt ngưỡng là rule kích hoạt.
• Performance Deterioration cần Historical Criteria đạt, và Recent Criteria đạt ở cả mốc 60 lẫn mốc 30 ngày.

Nếu rule có Campaign Criteria, bộ này phải đạt trên tổng số liệu của campaign chứa target, ngoài các điều kiện trigger ở cấp target.

Target không qua được bước này thì bị bỏ qua, và lần chạy ghi lại là criteria chưa đạt.

5. Áp các lớp bảo vệ

Trigger đã đạt mà target bị lớp bảo vệ loại ra thì vẫn không có thay đổi nào. Với rule negation, các lớp này gồm: khóa targeting của Sponsored Brands, Whitelist (trừ khi rule chủ động bỏ qua nó), lớp bảo vệ đơn hàng 365 ngày, và việc term đó đã bị negate sẵn hay chưa. Xem rule Negation và Unnegate.

Rule Bidding được import kèm các ngưỡng bảo vệ Top of Search Impression Share tối thiểu hoặc tối đa riêng thì được kiểm tra ở bước này. Trình sửa rule hiện tại không có ô đó nữa, mà cho Top of Search IS làm một metric trong Criteria. Cooldown và priority giữa các rule được chốt trước khi App xếp danh sách thay đổi cuối cùng.

Mỗi lần loại đều được ghi kèm lý do riêng. Nhờ vậy, một target bị bỏ qua cho bạn biết lớp kiểm tra nào đã chặn nó, chứ không chỉ báo là không có gì xảy ra.

6. Tính và giới hạn action

Với bid, App tính mức bid mục tiêu, áp chốt chặn hướng theo ACOS, áp mức dịch tối đa mỗi lần chạy, rồi mới áp giới hạn của bạn và giới hạn kỹ thuật bắt buộc của Amazon. Giới hạn của bạn đứng sau mức dịch tối đa mỗi lần chạy, nên có lúc nó buộc bid dịch xa hơn mức đó. Thứ tự đầy đủ, cùng cách mức trần và mức sàn xử lý khác nhau, nằm ở rule Bidding.

7. Xếp hàng hoặc gửi đi

Kết quả hiện trong bản xem trước của lần chạy. Dù thế nào, lần chạy cũng ghi lại nó đã quyết định gì.

Đọc một kết quả bạn không ngờ tới

Đi ngược lại đúng danh sách trên:

1. Target có nằm trong assignment không?
2. Dữ liệu có nằm trong cửa sổ mà trigger thực sự đọc không? Cửa sổ đó không phải lúc nào cũng là Data Window.
3. Scope có đúng như bạn nghĩ không?
4. Trigger mode có đo đúng thứ bạn tưởng nó đo không?
5. Có lớp bảo vệ nào loại target ra không, và là lớp nào?
6. Có giới hạn nào kẹp bớt độ lớn của thay đổi không?

Với Bidding, hiểu “scope” là Rule Applicability, và kiểm tra thêm Campaign Criteria, Top of Search share, cooldown và priority. Trang rule Bidding liệt kê các kiểu bỏ qua thường gặp do thiếu dữ liệu đầu vào hoặc giới hạn đặt sai.

Thực tế, bước 1, 2 và 5 giải thích được phần lớn các trường hợp bất ngờ.