AdOps mengunci rule pada jam lewat dua metric: Time greater than dan Time less than. Masing-masing membawa pemilih 24 jam dari 12:00 AM sampai 11:00 PM dan pemilihan hari yang dimulai dari Minggu, dan hanya dua metric inilah di AdOps yang menerima hari. Keduanya tidak menerima periode lookback, karena keduanya menggambarkan saat ini, bukan sebuah jendela data.
Apa yang sebenarnya bisa dinyatakan kondisi waktu?
Satu batas jam, plus hari-hari tempat batas itu berlaku. Gabungkan dua kondisi dalam satu task dan Anda punya jendela:
Time greater than09.00, hari Senin sampai JumatTime less than21.00, hari Senin sampai Jumat- operator task AND
Kedua kondisi itu duduk bersama kondisi performa di task yang sama, jadi action hanya menembak ketika uji metric dan uji jam sama-sama benar. Itu saja mekanismenya, dan kesederhanaan itulah intinya: rule-nya tetap terbaca di log, tempat setiap kondisi mencetak Pass atau Fail-nya sendiri.
Kenapa jam yang dipilih ikut terhitung?
Karena kedua perbandingan bersifat inklusif pada jam batas. Time greater than baru gagal ketika jam berjalan berada di bawah jam yang Anda sebut; Time less than baru gagal ketika jam berjalan berada di atasnya. Jam yang disebut selalu lolos di kedua sisi.
Konsekuensi praktisnya pantas ditempel di meja. Jendela Time greater than 09.00 AND Time less than 21.00 terbuka dari 09.00.00 sampai 21.59.59 — empat belas jam, bukan dua belas. Kalau Anda ingin jendelanya tutup pukul sembilan malam, sebutkan 20.00 sebagai batas atas.
Hal yang sama berlaku untuk rule satu sisi. Time greater than 22.00 mulai tepat pukul 22.00, bukan pukul 23.00.
Dayparting sebaiknya di jadwal atau di kondisi?
Keduanya tersedia, dan keduanya menyelesaikan masalah yang berbeda.
| Jadwal timetable | Kondisi waktu | |
|---|---|---|
| Yang dikendalikan | Apakah rule bangun sama sekali | Apakah action menembak saat rule bangun |
| Granularitas | Grid 7 hari kali 24 jam yang diklik | Batas jam plus hari terpilih, per kondisi |
| Terlihat di log | Sebagai jadwal rule | Sebagai Pass atau Fail di tiap eksekusi |
| Paling cocok untuk | Rule yang hanya masuk akal di satu waktu, misalnya reset malam | Rule yang harus sering jalan tapi hanya bertindak di dalam jendela |
Rule yang menaikkan budget ketika ROAS kuat sebaiknya jalan pada interval pendek dan membawa kondisi waktu, karena Anda ingin ia mengevaluasi sepanjang hari tetapi hanya bertindak pada jam yang Anda percayai. Rule yang mengembalikan budget pukul 23.00 sebaiknya hidup di timetable, karena tidak ada gunanya ia bangun 90 kali sehari.
Satu catatan mekanis soal timetable: kalau hari ini tidak ada slot tersisa, AdOps memindai maju hari demi hari mencari slot berikutnya, sampai tujuh hari ke depan. Timetable dengan satu slot hari Minggu karena itu terjadwal seminggu kemudian, yang memang benar tetapi mengagetkan saat pertama kali melihat timestamp Next Scheduled Execution.
Bagaimana menulis reset budget malam?
Bentuk yang paling dicari pengiklan Indonesia biasanya: tekan spend pada jam yang mengonversi, tarik budget saat tengah malam, kembalikan lagi pagi harinya. Itu dua rule, atau satu rule dengan dua task dan kondisi waktu yang berlawanan.
Task 1 — Decrease budget. Kondisi: Time greater than 23.00, tujuh hari. Action: decrease budget dengan persentase, dan isi Minimum budget cap supaya penurunannya tidak menjatuhkan campaign sampai dasar. Action frequency: sekali sehari.
Task 2 — Increase budget. Kondisi: Time greater than 07.00 AND Time less than 08.00, tujuh hari. Action: increase budget, dengan Maximum budget cap terisi. Action frequency: sekali sehari.
Tiga detail yang membuat pola ini berperilaku benar.
Ketiga action budget membaca ulang daily budget yang live dari Meta tepat sebelum menulis, jadi perubahan persentase berlaku terhadap budget campaign yang sebenarnya, bukan terhadap angka terakhir yang dilihat AdOps. Cooldown sekali sehari itulah yang menahan rule berinterval 15 menit agar tidak menerapkan penurunan yang sama berulang kali sepanjang jam ketika kondisinya benar. Dan kedua cap bekerja ke arah berlawanan: maksimum pada increase, minimum pada decrease.
Kalau pengembalian pagi harus mendarat di angka pasti, bukan persentase, pakai set budget — action itu menerima nilai literal atau custom metric, dan tidak punya mode persentase. Memasangkannya dengan custom metric dari Google Sheets memberi Anda tabel budget siang per campaign yang bisa disunting tanpa menyentuh rule-nya. Template bawaan Night Budget Reset adalah versi jadi dari pola ini untuk titik mulai.
Jam siapa yang sebenarnya dibaca rule?
AdOps tidak punya field zona waktu per rule, jadi kondisi waktu dievaluasi terhadap jam mesin yang menjalankan engine. Jangan berasumsi; pastikan.
Pengecekannya cukup satu hari. Set live rule dengan jendela sempit, lalu buka Rule Logs dan baca kolom Execution Time pada batch pertama, ditambah status Pass atau Fail kondisi waktu di detail batch tersebut. Kalau jendelanya mendarat satu jam atau beberapa jam dari yang Anda kira, geser batas jamnya, jangan berdebat dengan jam. Lalu tulis selisih itu di nama rule, supaya orang berikutnya yang membukanya tidak mengulang penyelidikan yang sama.
Apa yang tidak bisa diperbaiki dayparting?
Dayparting tidak mencarikan jam Anda. AdOps tidak menyajikan rincian per jam, jadi kurvanya harus datang dari laporan Meta sendiri; AdOps adalah tempat keputusannya dinyatakan setelah kurvanya Anda pegang.
Dayparting juga tidak membuat jam yang sepi jadi untung. Memotong spend antara tengah malam sampai 06.00 baru menguntungkan kalau jendela itu memang buruk di akun Anda, dan uji yang jujur adalah dua minggu data, bukan aturan jempol dari pasar lain. Minggu gajian, libur panjang, dan bulan Ramadan menekuk kurva itu dengan cara berbeda untuk kategori yang berbeda — persis alasan kenapa jawabannya harus datang dari akun Anda, bukan dari sebuah artikel.
Mulai dari satu jendela, satu kondisi metric, dan satu action. Baca log selama seminggu. Baru melebar.
