Nhật ký thay đổi tài khoản quảng cáo: sáu trường bắt buộc

Nhật ký thay đổi là bản ghi từng hành động đã xảy ra trên tài khoản quảng cáo, kèm lý do và người cấp quyền. Một dòng nhật ký dùng được phải có sáu trường: lúc nào, quy tắc nào, đối tượng nào, số liệu lúc đó, đổi từ đâu sang đâu, và ai cho phép. Thiếu một trường là bạn phải đi hỏi người khác mới hiểu chuyện gì xảy ra.

Bài này đi qua từng trường, ba câu hỏi mà nhật ký phải trả lời được trong ba phút khi có sự cố, bốn mức khó khi bạn muốn quay lại, và một ca có thật kể đủ từ lúc phát hiện tới lúc xử xong.

Cuối bài có một mẫu bảng tính năm cột để bạn tự ghi, dùng được ngay nếu công cụ hiện tại chưa có nhật ký đủ tốt.

Sáu trường trong một dòng nhật ký

Một: lúc nào

Thời điểm, ghi theo múi giờ của người đọc chứ không phải múi giờ máy chủ.

Nghe vặt vãnh cho tới lần đầu bạn phải đối chiếu một dòng nhật ký ghi giờ máy chủ với một báo cáo nền tảng ghi giờ địa phương, trong lúc đang cần biết việc gì xảy ra trước việc gì. Chúng tôi từng mất một buổi vì đúng chuyện này.

Hai: quy tắc nào

Mã quy tắc, không phải mô tả bằng lời. Mã tra ngược được về định nghĩa: điều kiện là gì, ngưỡng bao nhiêu, giới hạn ra sao.

Mô tả bằng lời đọc dễ hơn, nhưng nó thay đổi theo thời gian trong khi mã thì cố định. Nhật ký ghi mô tả sẽ nói dối bạn sau lần cập nhật thứ ba, vì dòng cũ vẫn ghi mô tả cũ trong khi quy tắc đã khác.

Ba: đối tượng nào

Chiến dịch, nhóm quảng cáo hay mẫu quảng cáo cụ thể, kèm định danh chứ không chỉ tên. Tên đổi được, định danh thì không. Một tài khoản chạy hai năm thường có vài chiến dịch đã đổi tên, và nhật ký chỉ ghi tên sẽ trỏ vào hư không.

Bốn: số lúc đó

Các con số đã làm cho điều kiện đúng, chụp lại tại thời điểm hành động.

Đây là trường hay bị bỏ nhất, và bỏ nó là hỏng cả nhật ký. Lý do: dữ liệu nền tảng thay đổi ngược về sau. Chuyển đổi được ghi nhận trễ, số liệu chi tiêu được điều chỉnh lại. Nếu nhật ký không lưu số tại thời điểm hành động thì ba ngày sau khi bạn mở ra xem, con số đã khác, và bạn sẽ kết luận hệ thống hành động sai trong khi lúc đó nó đúng. Phần riêng ở dưới nói kỹ hơn về trường này.

Năm: đổi gì, từ đâu sang đâu

Không chỉ "đã tăng ngân sách" mà "từ 1.000.000 lên 1.200.000".

Giá trị cũ là bắt buộc, vì nó là thứ cho phép quay lại. Nhật ký không ghi giá trị cũ thì việc khôi phục biến thành việc đoán, hoặc thành việc mở nền tảng ra tra một con số lẽ ra đã nằm sẵn trong dòng nhật ký.

Sáu: ai cho phép

Mã của quyền đã cho phép loại hành động này, kèm ngày cấp và người cấp.

Đây là trường bị bỏ nhiều nhất và cần nhất. Khi có chuyện bất ngờ, câu hỏi đầu tiên không phải là "cái gì đã đổi", nhìn tài khoản là thấy. Câu đầu tiên là "ai đã cho phép loại việc này, và từ bao giờ". Nhật ký không trả lời được câu đó biến một cuộc rà soát năm phút thành một buổi chiều.

Ba trường nên có thêm nếu bạn chạy quy trình nhiều bước

Khi hành động không đứng một mình mà nằm trong một quy trình nhiều bước, ba trường sau tiết kiệm rất nhiều thời gian đoán mò.

Ghi cả bước không làm gì. Một quy trình năm bước mà bước ba không thoả điều kiện thì hai bước sau không chạy. Nếu nhật ký chỉ ghi các bước đã chạy, bạn nhìn vào sẽ tưởng quy trình bị lỗi giữa chừng. Ghi rõ "bước ba: điều kiện không đúng, dừng" là một dòng.

Ghi bản lưu nào của quy trình đang chạy. Quy trình sửa được, và sửa xong thì hành vi đổi. Nếu nhật ký không ghi hành động này chạy trên bản lưu nào thì một tháng sau bạn không dựng lại được vì sao nó làm vậy.

Ghi lượng xử lý đã dùng. Mỗi bước tiêu một lượng xử lý và bạn trả tiền cho nó. Ghi con số đó vào nhật ký cho phép bạn thấy quy trình nào đang tốn mà không mang lại gì, thường là quy trình đặt bước tốn kém trước bước lọc rẻ.

Ba câu hỏi lúc có sự cố

Sự cố ở đây không nhất thiết là thảm hoạ. Phần lớn là chuyện nhỏ: sáng ra thấy một chiến dịch bị tắt mà không ai nhớ đã tắt.

Ba câu này phải trả lời được trong ba phút, chỉ bằng những gì có sẵn trong nhật ký, không phải mở thêm bốn tab nữa.

Chuyện gì đã xảy ra

Dễ nhất. Hầu hết hệ thống trả lời được, và bản thân nền tảng quảng cáo cũng có lịch sử thay đổi riêng.

Vì sao nó làm vậy

Khó hơn. Cần biết điều kiện nào đã đúng, số lúc đó bao nhiêu, ngưỡng đặt ở đâu.

Đây là chỗ phân biệt một nhật ký thật với một danh sách sự kiện. Danh sách sự kiện nói cái gì đã xảy ra. Nhật ký nói vì sao.

Ai chịu trách nhiệm

Câu khó nhất, và ít hệ thống trả lời được.

Không phải để đổ lỗi. Để biết cần nói chuyện với ai, và để biết quyết định cấp quyền hồi đó dựa trên cơ sở nào. Có thể cơ sở đó giờ không còn đúng nữa, và cái cần sửa là quyền chứ không phải ngưỡng.

Cách làm đúng là mỗi lần thả quyền tự chạy được ghi thành một bản ghi riêng có mã, và mỗi hành động tự chạy đều tham chiếu tới mã đó. Không có phần này thì việc dựng lại "ai đã duyệt cái gì" phải làm bằng cách đọc lịch sử cấu hình, chậm và không chắc chắn.

Bốn mức khó khi muốn quay lại

"Quay lại được" nghe như một tính chất có hoặc không. Thực tế nó có bốn mức, và nhầm mức là nguồn gốc của phần lớn bất ngờ khó chịu.

Mức một: đảo sạch

Bật lại chiến dịch vừa bị tắt vài phút trước. Trạng thái gần như y nguyên, hệ tối ưu của nền tảng chưa kịp nhận ra.

Đây là mức mà mọi người tưởng tượng khi nghe câu "đảo được trong một cú bấm". Nó chỉ đúng trong một khoảng rất ngắn sau hành động.

Mức hai: đảo được nhưng mất trạng thái

Bật lại chiến dịch bị tắt vài giờ trước. Chiến dịch chạy lại, nhưng có thể phải vào lại giai đoạn học, và hiệu quả vài ngày đầu sẽ khác trước khi tắt.

Về mặt cấu hình thì đã khôi phục. Về mặt kết quả thì chưa. Đây là mức của phần lớn hành động tắt bật.

Mức ba: đảo được số, không đảo được hệ quả

Ngân sách bị tăng và đã chi ba ngày. Bạn đưa số về cũ được, tiền đã tiêu thì không.

Đây là mức của phần lớn hành động thuộc nhóm tăng trưởng, và là lý do nhóm đó cần trần tuyệt đối chứ không chỉ cần khả năng khôi phục. Một quyền "được tăng ngân sách" mà không kèm trần là quyền không có đáy.

Mức bốn: không đảo được

Nội dung đã hiển thị cho khách hàng. Bạn gỡ được mẫu quảng cáo, không gỡ được việc người ta đã đọc.

Đây là lý do không nên cho chạy tự động với nội dung và chữ nghĩa trong bất kỳ cấu hình nào. Không có ngưỡng nào bảo vệ được ở mức này.

Hai hiểu lầm hay gặp về việc quay lại

Cứ đảo được là an toàn. Khả năng đảo là điều kiện cần, không phải điều kiện đủ. Một hành động đảo được nhưng không ai phát hiện trong hai tuần thì khả năng đảo đó không có giá trị gì. Khi xét một quyền tự chạy, phải xét cả hai: đảo được tới mức nào, và bao lâu thì có người biết. Cái thứ hai thường quan trọng hơn.

Hành động phòng thủ luôn ở mức đảo sạch. Tắt chiến dịch nghe như hành động đảo được hoàn toàn, và trong vài phút đầu thì đúng vậy. Sau vài giờ thì đã sang mức hai. Điều này không làm hành động phòng thủ kém an toàn đi, nó chỉ nghĩa là cái giá của một lần tắt nhầm không bằng không, và nên tính vào khi đặt ngưỡng.

Vì sao "số lúc đó" là trường khó làm nhất

Trong sáu trường, năm trường là chép lại thứ đã biết. Trường "số lúc đó" là trường duy nhất phải chủ động chụp lại một trạng thái sẽ biến mất.

Dữ liệu quảng cáo không đứng yên. Chuyển đổi được ghi nhận trễ tới vài ngày. Số liệu chi tiêu được điều chỉnh lại. Một số chỉ số được tính lại khi nền tảng cập nhật cách đo.

Hệ quả: nếu nhật ký chỉ ghi định danh chiến dịch rồi để người đọc tự tra số, thì con số họ thấy hôm nay không phải con số hệ thống thấy lúc hành động. Khoảng lệch đó luôn theo một hướng. Dữ liệu về sau luôn đầy đủ hơn, nên mọi hành động cũ đều trông như quá vội.

Đây là nguồn gốc của một hiểu lầm rất phổ biến. Người vận hành mở lại một quyết định cũ, thấy số bây giờ trông ổn, và kết luận hệ thống sai. Trong nhiều trường hợp hệ thống đúng theo dữ liệu lúc đó, và cái cần sửa là khoảng thời gian lấy số liệu chứ không phải quy tắc.

Cách làm đúng là chụp lại toàn bộ các con số tham gia vào điều kiện, ngay tại lúc điều kiện được đánh giá, và lưu chúng cùng dòng nhật ký. Tốn thêm chút dung lượng, và đó là chỗ đáng tốn nhất trong cả hệ thống.

Một chỗ khác cũng hay bị bỏ: lần thử thất bại

Khi gọi tới nền tảng bị lỗi giữa chừng, nhiều hệ thống không ghi gì cả. Nhìn vào nhật ký thì giống hệt như quy tắc không kích hoạt.

Đó là kiểu im lặng nguy hiểm nhất, vì nó làm bạn tin rằng không có gì xảy ra, trong khi thực tế có một hành động đã thử, đã thất bại, và có thể đã thực hiện được một phần. Mọi lần thử đều nên được ghi kèm mã lỗi, và hệ thống không nên tự thử lại âm thầm. Tự thử lại âm thầm là cách một thay đổi định làm một lần biến thành ba lần.

Nhật ký của công cụ khác gì lịch sử thay đổi của nền tảng

Google Ads và Meta đều có lịch sử thay đổi riêng, miễn phí, ghi khá đầy đủ. Câu hỏi hợp lý: vậy cần nhật ký riêng làm gì?

	Lịch sử của nền tảng	Nhật ký của công cụ
Ghi cái gì đã đổi	Có	Có
Ghi vì sao đổi	Không, vì nó không biết có quy tắc nào tồn tại	Có, kèm điều kiện và số lúc đó
Ghi ai cấp quyền	Chỉ ghi tài khoản thực hiện	Có, kèm mã quyền và ngày cấp
Gộp nhiều nền tảng	Không, mỗi nền một định dạng	Có, chung một trình tự thời gian
Bắt thay đổi thủ công	Có, kể cả người ngoài công cụ	Chỉ khi thay đổi đi qua công cụ
Ghi lần thử thất bại	Không	Có, nếu công cụ làm đúng

Hai dòng cuối là lý do nên dùng cả hai. Nhật ký công cụ hiểu được vì sao, nhưng nó mù với những thay đổi ai đó làm thẳng trên nền tảng. Lịch sử nền tảng bắt được những thay đổi đó, nhưng không giải thích được gì.

Đọc nhật ký thế nào cho có ích: bốn thứ nhìn trước

Có nhật ký là một chuyện, dùng được nó là chuyện khác. Bốn thứ dưới đây nhìn trước, phần còn lại nhìn khi cần.

Một: hệ thống đã tự làm gì đêm qua

Năm phút mỗi sáng, và không phải đọc từng dòng. Đọc phần tóm tắt những hành động tự chạy.

Mục tiêu không phải kiểm tra mà là quen. Sau vài tuần bạn sẽ nhận ra ngay khi có dòng lạ, vì bạn đã biết dạng bình thường trông ra sao. Đây là khác biệt lớn nhất giữa người kiểm soát được hệ thống và người chỉ tin nó.

Hai: một dòng bất kỳ, đọc ngược tới cùng

Mỗi tuần chọn ngẫu nhiên một hành động, mở ra, và tự trả lời: điều kiện nào đúng, số lúc đó bao nhiêu, ngưỡng ở đâu, mình có đồng ý không.

Mất chừng ba phút. Tác dụng là phát hiện những quy tắc đang hành động đúng vì lý do sai. Chúng làm việc bạn đồng ý, nhưng vì một điều kiện khác với điều kiện bạn nghĩ, và đến lúc bối cảnh đổi thì chúng làm sai mà không báo trước.

Ba: phần thay đổi cấu hình

Không phải phần hành động, mà phần ghi ai đã đổi cài đặt gì. Mỗi quý một lần là đủ.

Trên tài khoản một người thì phần này thường trống. Trên tài khoản nhiều người, nó giải thích được phần lớn những thay đổi hành vi mà không ai hiểu vì sao.

Bốn: những lần thử thất bại

Lọc riêng các dòng có mã lỗi. Đọc lý do, không chỉ đếm số lần. Lỗi mất kết nối và lỗi thiếu quyền có cách xử hoàn toàn khác nhau, và loại thứ hai thường im lặng kéo dài nhiều tuần trước khi ai đó để ý.

Một ca có thật, kể đủ chi tiết

Đây là loại tình huống mà nhật ký kiếm lại toàn bộ công sức dựng nó.

Bối cảnh. Sáng thứ hai, người vận hành mở tài khoản, thấy hai chiến dịch đang tạm dừng. Không ai trong nhóm nhớ đã tắt.

Nếu không có nhật ký. Bật lại, đoán là ai đó tắt nhầm, đi tiếp. Nếu nguyên nhân thật là một quy tắc có ngưỡng sai, nó sẽ tắt lại vào cuối tuần sau, và vòng lặp cứ thế lặp lại.

Có nhật ký thì thấy gì. Mở ra, thấy hai dòng: cùng một mã quy tắc, kích hoạt lúc hai giờ sáng chủ nhật, kèm số liệu tại thời điểm đó. Chi tiêu đã vượt ba lần giá mỗi đơn mục tiêu, một trăm ba mươi lượt nhấp, không chuyển đổi trong hai ngày.

Kiểm tra tiếp. Hai chiến dịch đó chạy cho một chương trình khuyến mãi cuối tuần, và trên tài khoản này việc chuyển đổi được ghi nhận trễ tới thứ hai là chuyện bình thường. Nghĩa là quy tắc hành động đúng theo dữ liệu nó thấy, nhưng dữ liệu lúc đó chưa đầy đủ.

Cách sửa. Không tắt quy tắc. Thêm điều kiện loại trừ cho chiến dịch có gắn nhãn khuyến mãi, và kéo khoảng thời gian lấy số liệu từ hai ngày lên ba ngày cho tài khoản này.

Điểm mấu chốt. Cả chẩn đoán lẫn cách sửa đều phụ thuộc vào trường "số lúc đó". Nếu nhật ký chỉ ghi "đã tắt chiến dịch X", người vận hành sẽ mở báo cáo vào thứ hai, thấy chuyển đổi đã về đủ, và kết luận hệ thống bị lỗi. Kết luận đó sai, và nó dẫn tới việc tắt một quy tắc đang có ích.

Ba dấu hiệu nhật ký của bạn chưa đủ tốt

Phải mở nhiều chỗ mới trả lời được một câu hỏi

Nếu để biết "vì sao chiến dịch này bị tắt" bạn phải mở nhật ký, rồi mở bảng cấu hình xem ngưỡng, rồi mở báo cáo xem số liệu, thì nhật ký chưa đủ. Cả ba thứ đó phải nằm trong chính dòng nhật ký.

Đọc xong vẫn phải hỏi người

Thử một bài kiểm tra: đưa một dòng nhật ký cho người trong nhóm chưa từng xử lý việc đó. Nếu họ hiểu được chuyện gì xảy ra và vì sao mà không cần hỏi ai, nhật ký đạt. Nếu không, còn thiếu trường, và thường thiếu đúng hai trường cuối.

Không ai mở nó ra bao giờ

Nhật ký không ai đọc là nhật ký nằm sai chỗ. Người ta chỉ nhớ tới nhật ký khi đã có chuyện, mà đúng lúc đó thì họ đang vội.

Cách sửa không phải là nhắc mọi người đọc, mà là đưa nội dung của nó vào chỗ người ta vốn đã đọc hằng ngày. Đưa phần "hệ thống đã tự làm gì" vào bản tổng hợp buổi sáng, cùng chỗ với các đề xuất, thì thời gian từ lúc hệ thống làm một việc tới lúc có người biết rút từ vài ngày xuống dưới một ngày, mà không phải thêm màn hình nào.

Nhật ký khi nhiều người cùng làm một tài khoản

Trên tài khoản có nhiều người, nhật ký giải quyết một vấn đề khác hẳn: thay đổi thủ công.

Nguồn nhầm lẫn phổ biến nhất trên tài khoản dùng chung không phải hệ thống làm sai, mà là một người đổi ngưỡng rồi không ai khác biết. Tuần sau, quy tắc hành xử khác đi và cả nhóm đi tìm lỗi ở hệ thống.

Nên nhật ký phải có hai phần và đọc chung được trên một trình tự thời gian: hành động trên tài khoản, và thay đổi cấu hình. Ghi hai chỗ riêng thì mất mối liên hệ nhân quả rõ ràng nhất, kiểu cấu hình đổi hôm thứ ba, hành vi đổi từ thứ tư.

Từ ba người trở lên thì đây là yêu cầu tối thiểu

Từ ba người cùng động vào một tài khoản, trí nhớ tập thể không còn đáng tin. Chuyện "tôi tưởng anh đổi" xảy ra hằng tháng, và cách duy nhất giải quyết là có bản ghi.

Với đại lý chạy tiền của khách thì nhật ký còn là bằng chứng công việc. Nó nên tách được theo từng khách và xuất ra file để đính kèm báo cáo tháng, vì mọi tranh luận về chi tiêu đều quay về câu hỏi ai đã quyết định gì, lúc nào.

Một mẫu bảng theo dõi tối thiểu làm bằng bảng tính

Nếu công cụ bạn dùng chưa có nhật ký đủ tốt, bảng tính năm cột này đủ dùng trong ba tháng đầu.

Cột	Ghi gì	Ví dụ
1. Ngày giờ	Theo giờ địa phương	Chủ nhật 02:00
2. Việc gì	Một dòng, cụ thể	Tắt chiến dịch khuyến mãi cuối tuần
3. Vì sao	Điều kiện và con số lúc đó	130 nhấp, 0 chuyển đổi trong 2 ngày
4. Mình có đồng ý không	Có, không, hoặc chưa rõ	Không
5. Nếu không thì vì sao	Cột quý nhất	Chuyển đổi trên tài khoản này về trễ tới thứ hai

Bảng này thô, và nó làm đúng việc quan trọng nhất: buộc bạn ghi lại đánh giá tại thời điểm sự việc, thay vì nhớ lại sau ba tuần. Trí nhớ về chuyện mình có đồng ý hay không thay đổi rất nhanh theo kết quả về sau.

Sau hai tuần, đọc lại riêng cột năm là biết ngay ngưỡng nào cần sửa. Nếu cột năm trống trơn thì hoặc mọi thứ đang chạy tốt, hoặc bạn đang điền cho có, và bạn sẽ tự biết là trường hợp nào.

Bốn câu hỏi cho nhà cung cấp công cụ

Bốn câu này cho biết nhiều về sản phẩm hơn một danh sách tính năng.

Cho tôi xem một dòng nhật ký thật. Không phải ảnh chụp màn hình trong tài liệu quảng cáo, mà một dòng thật từ một tài khoản thật. Đếm xem có đủ sáu trường không.

Nhật ký có ghi giá trị trước khi đổi không. Nếu không, việc khôi phục sẽ là việc đoán.

Khi gọi tới nền tảng bị lỗi thì ghi thế nào. Nếu câu trả lời là "không ghi gì", đó là kiểu im lặng nguy hiểm nhất.

Hành động tự chạy có tham chiếu tới quyền đã cấp không. Đây là câu phân biệt rõ nhất giữa một hệ thống có mô hình phân quyền thật và một hệ thống chỉ có công tắc bật tắt.

Đọc nhật ký cả tháng: tìm gì

Đọc từng ngày là để bắt chuyện bất thường. Đọc cả tháng là để thấy những thứ một ngày không lộ ra.

Quy tắc nào kích hoạt nhiều nhất. Nếu một quy tắc chiếm phần lớn số dòng trong tháng, hoặc ngưỡng của nó quá nhạy, hoặc nó đang che một vấn đề thật mà chưa ai xử tận gốc. Cả hai trường hợp đều cần bạn nhìn vào nguyên nhân chứ không phải nhìn vào quy tắc.

Quy tắc nào chưa kích hoạt lần nào. Có thể tài khoản đang khoẻ ở mặt đó, cũng có thể điều kiện đặt sai tới mức không bao giờ đúng. Cách kiểm nhanh là tra thử điều kiện đó bằng tay trên số liệu tháng qua.

Cùng một chiến dịch bị đụng nhiều lần. Dấu hiệu hai quy tắc đang giằng nhau, hoặc một quy tắc đang đổi rồi đổi lại. Đây là chỗ tốn tiền âm thầm mà nhìn báo cáo tổng không thấy.

Khoảng cách từ lúc hành động tới lúc có người xem. Nếu nhật ký ghi cả lúc ai đó mở dòng đó ra đọc, con số này đo được. Nó là con số quan trọng nhất mà gần như không ai đo, vì nó quyết định khả năng quay lại có giá trị thật hay chỉ có trên giấy.

Những dòng bạn đã đánh dấu là không đồng ý. Đọc lại theo cụm. Nếu chúng dồn về một quy tắc, sửa ngưỡng quy tắc đó. Nếu chúng rải đều, vấn đề nằm ở việc bạn thả quyền quá rộng chứ không ở ngưỡng nào cả.

Ba việc nhật ký không làm được

Nói rõ để khỏi kỳ vọng sai.

Không ngăn được lỗi. Nhật ký ghi lại, không chặn. Cái chặn là các giới hạn: số đối tượng tối đa mỗi lượt, mức thay đổi tối đa, danh sách loại trừ. Nhật ký chỉ giúp bạn phát hiện nhanh và sửa đúng chỗ.

Không nói được quy tắc có tốt không. Nó cho biết quy tắc đã làm gì và vì sao. Việc quy tắc đó có hợp với tài khoản này không thì vẫn phải người đọc và đánh giá, thường qua một giai đoạn chạy ở chế độ chỉ đề xuất.

Không thay được đo lường đúng. Nhật ký ghi trung thực những con số hệ thống nhìn thấy. Nếu đo lường hỏng, nhật ký sẽ ghi trung thực một quyết định sai. Nó giúp bạn tìm ra nguyên nhân nhanh hơn, nhưng không ngăn được.

Ba việc làm được ngay tuần này

Mở nhật ký của công cụ đang dùng, đếm xem có mấy trường trong sáu. Mất năm phút và cho biết bạn đang ở đâu.

Chọn một hành động tự chạy trong tháng qua, đọc ngược tới cùng. Có trả lời được cả ba câu hỏi lúc sự cố không, chỉ bằng những gì có trong nhật ký?

Với mỗi quyền tự chạy đang bật, viết ra nó thuộc mức quay lại nào. Bốn mức, mỗi quyền một dòng. Nếu có quyền nào rơi vào mức bốn, xem lại quyền đó ngay trong tuần.

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

Giữ nhật ký bao lâu?

Đủ dài để phủ ít nhất hai chu kỳ rà soát. Nếu bạn xem lại theo quý thì giữ tối thiểu sáu tháng, vì câu hỏi hay xuất hiện ở buổi rà soát là "cái này bắt đầu từ bao giờ".

Nhật ký có nên ghi cả lần quy tắc không kích hoạt không?

Không. Ghi mọi lần đánh giá mà điều kiện không đúng sẽ tạo ra hàng nghìn dòng mỗi ngày và chôn vùi những dòng có ý nghĩa. Chỉ ghi khi có hành động, có đề xuất, hoặc có lần thử thất bại.

Nhật ký có làm nặng hệ thống không?

Không đáng kể. Một dòng nhật ký nhỏ hơn nhiều so với lượng dữ liệu cần đọc để tạo ra hành động đó. Đây không phải chỗ đáng tiết kiệm.

Có nên cho khách hàng của đại lý xem nhật ký không?

Nên, và nên tách theo từng khách. Nhật ký cho thấy đã làm gì, khi nào, vì sao, và đó thường là thứ dễ trình bày hơn một bản báo cáo chỉ số.

Hỏi trợ lý về nhật ký được không?

Được, và nên phân biệt hai loại câu hỏi. "Vì sao chiến dịch X bị tắt tối qua" là tra cứu, rẻ và chính xác, trả về đúng dòng nhật ký. "Có nên tắt chiến dịch X không" là phân tích, tốn hơn và là câu hỏi khác hẳn.

Nhật ký có nên xuất ra file được không?

Nên. Với đại lý thì đó là báo cáo cho khách, với đội nội bộ thì đó là thứ mang vào buổi rà soát quý. Nhật ký chỉ xem được trên màn hình thì không dùng được trong hai tình huống đó.

Nhật ký có thay được việc theo dõi không?

Không. Nhật ký nói cái đã xảy ra. Nó không cảnh báo, không tổng hợp xu hướng, không nói cho bạn biết cái sắp xảy ra. Nó là bằng chứng, không phải hệ thống giám sát.

Ngành nào bắt buộc phải có nhật ký?

Tài chính, y tế, giáo dục, và nói chung là những ngành mà nội dung quảng cáo phải qua duyệt. Ở đó nhật ký không chỉ để vận hành mà còn là bằng chứng cho thấy không có nội dung nào lên mà chưa qua người.

Đọc thêm: cố vấn hay tự chạy: mô hình phân quyền, 19 quy tắc tự động mẫu, bắt đầu từ đâu, và tuần đầu tiên với trợ lý quảng cáo AI.

Xem nhật ký trên tài khoản của mình ở orova.vn.