Jawaban singkat: pada 12 Oktober 2026 tim Google Ads API mengumumkan perpindahan ke dua rilis per bulan mulai v26. Empat rilis mayor per tahun tetap berlaku, sedangkan rilis lainnya berupa rilis minor yang hanya menambah fitur tanpa perubahan yang merusak. Jadwal sunset, menurut pengumuman yang sama, tidak berubah. Dampak praktisnya bagi bisnis dan agensi: yang perlu dipantau adalah tanggal sunset versi mayor yang dipakai konektor Anda, bukan setiap nomor rilis minor.
Artikel ini ditujukan bagi pemilik bisnis, tim marketing, dan agensi di Indonesia yang memakai laporan otomatis, konektor data, skrip, atau aplikasi internal berbasis Google Ads API. Jika Anda hanya mengelola kampanye lewat antarmuka Google Ads tanpa integrasi, tidak ada tindakan teknis yang wajib dilakukan. Tidak ada klaim hasil kampanye di sini; isinya adalah kerangka pemeriksaan berdasarkan dokumentasi resmi.
Apa yang sebenarnya berubah pada jadwal rilis?
Pengumuman 12 Oktober 2026 menyebut bahwa tahun lalu Google beralih ke jadwal rilis bulanan, dan kini bergerak ke dua rilis per bulan mulai v26. Ada empat hal yang perlu dipisahkan agar tidak salah tafsir:
- Empat rilis mayor per tahun tetap ada.
- Rilis lain adalah rilis minor yang, menurut pengumuman, hanya menambah fitur non-breaking.
- Setiap rilis mayor masih tersedia selama satu tahun setelah dirilis.
- Setiap rilis minor berhenti bersama versi mayor induknya.
Artinya, frekuensi rilis naik, tetapi kewajiban migrasi tidak ikut naik. Pengumuman itu menyatakan sendiri bahwa jadwal sunset tidak berubah sehingga Anda tidak perlu bermigrasi lebih sering. Satu perubahan lain bersifat komunikasi: artikel blog rilis dan siaran langsung YouTube pindah ke dua kali per kuartal dan merangkum beberapa rilis sekaligus. Untuk mengikuti rilis satu per satu, Google menyarankan menyimpan halaman release notes.
Konsekuensi bagi tim Anda: jangan menunggu blog untuk tahu ada perubahan. Catatan rilis di dokumentasi menjadi sumber yang lebih cepat berubah.
Bagaimana jadwal 2026-2027 dibaca?
Google memublikasikan tabel jadwal yang bersifat tentatif. Dokumen itu menegaskan tanggal adalah estimasi dan dapat berubah, serta rilis dapat ditambah, dihapus, atau berpindah antara mayor dan minor. Ringkasan di bawah mengutip tabel tersebut, bukan janji tanggal pasti.
| Versi | Jenis | Proyeksi rilis | Proyeksi sunset |
|---|---|---|---|
| v26 | Mayor | Oktober 2026 | November 2027 |
| v26.2 | Minor | November 2026 | November 2027 |
| v26.3 | Minor | Desember 2026 (dapat dilewati karena musim libur) | November 2027 |
| v27 | Mayor | Januari 2027 | Februari 2028 |
| v28 | Mayor | April 2027 | Mei 2028 |
Untuk versi yang sudah ada, jadwal sunset 2027 yang tertera adalah v23 pada Februari 2027, v24 pada Mei 2027, v25 pada Agustus 2027, dan v26 pada November 2027. Semuanya berstatus estimasi.
Catatan penting: v22 dijadwalkan sunset pada 7 Oktober 2026. Pengingat Google pada 2 September 2026 menyebut semua permintaan v22 mulai gagal sejak tanggal itu. Jika konektor lama di akun klien masih memanggil v22, penyebab laporan kosong bisa berasal dari sini. Periksa log konektor sebelum menyalahkan perubahan akun iklan.
Mengapa agensi perlu peduli walau tidak menulis kode?
Banyak agensi tidak memanggil API secara langsung. Mereka memakai spreadsheet connector, platform dashboard, alat bidding pihak ketiga, atau aplikasi buatan vendor. Pemilik hubungan klien tetap bertanggung jawab bila laporan berhenti di tengah bulan. Tiga skenario yang masuk akal:
- Konektor berhenti total. Versi yang dipakai konektor sudah sunset, permintaan gagal, dan dashboard klien kosong.
- Konektor jalan tetapi memakai versi lama. Tidak ada kegagalan hari ini, tetapi ada tenggat yang tidak tercatat.
- Konektor sudah diperbarui tanpa uji. Versi baru terpasang, tetapi nama field atau arti enum berubah dan angka dashboard bergeser tanpa penjelasan.
Skenario ketiga paling sulit dideteksi. Contohnya sudah muncul pada rilis v26: bidang enhanced_conversions_for_leads_enabled dihapus dan pembacaan konfigurasi Enhanced Conversions beralih ke ConversionTrackingSetting.enablement_setting. Pembahasan teknisnya ada di artikel audit migrasi konversi Google Ads API v26. Artikel ini membahas lapisan di atasnya: siapa memegang tanggal, siapa menguji, dan kapan harus bertindak.
Apa isi inventaris integrasi yang layak dibuat hari ini?
Mulai dari daftar sederhana. Satu baris per koneksi ke Google Ads API, tanpa format rumit.
| Kolom | Pertanyaan yang dijawab |
|---|---|
| Nama integrasi | Dashboard, skrip, konektor, atau alat bidding apa? |
| Pemilik teknis | Vendor, freelancer, atau tim internal siapa? |
| Versi API yang dipakai | Versi mayor berapa, dan dari mana angkanya diketahui? |
| Akun yang dibaca | Akun klien mana, dan siapa yang memberi akses? |
| Tanggal sunset versi tersebut | Dari tabel resmi, ditandai estimasi atau pasti |
| Tanggal uji terakhir | Kapan terakhir dibandingkan dengan antarmuka Google Ads? |
| Rencana migrasi | Target versi, penanggung jawab, tenggat internal |
Jika versi API tidak diketahui, tulis “belum diketahui” dan jadikan itu tugas pertama. Dokumentasi Google menyebut Anda dapat melihat versi Google Ads API yang dipakai proyek pada Google Cloud Console di bagian APIs & Services. Jangan menebak dari nama paket pustaka klien.
Kapan sebaiknya bermigrasi: di rilis minor atau mayor?
Pedoman dokumentasi menyebut versi mayor berumur sekitar 12 bulan, versi minor sekitar 10 bulan, dan Anda hanya perlu melakukan paling banyak dua upgrade per tahun. Anda juga tidak wajib naik secara berurutan; dari versi N dapat langsung ke N+2. Dokumentasi juga menyebut ada tumpang tindih minimal 20 minggu antara rilis pustaka klien untuk versi terbaru dan sunset versi yang dipensiunkan.
Dari sini, aturan kerja yang masuk akal bagi tim kecil:
- Rilis minor tidak memuat perubahan yang merusak. Anda tidak perlu mengujinya satu per satu, kecuali Anda memerlukan fitur barunya.
- Rilis mayor berisi breaking changes. Jadwalkan uji regresi, bukan sekadar mengganti nomor versi.
- Mulai migrasi jauh sebelum sunset, tidak menunggu bulan terakhir. Tumpang tindih 20 minggu adalah jendela dukungan pustaka, bukan alasan menunda.
Ini rekomendasi kerja Socta berdasarkan dokumentasi, bukan kewajiban dari Google. Sesuaikan dengan ukuran tim dan jumlah akun.
Apa checklist upgrade yang resmi dan bagaimana menerapkannya?
Halaman panduan upgrade Google (diperbarui 16 Oktober 2026) memuat checklist untuk migrasi mayor. Berikut intinya beserta cara menerapkannya pada tim marketing:
- Perbarui pustaka klien dan endpoint. Endpoint berubah ketika Anda pindah versi mayor. Pastikan versi pustaka mendukung target rilis.
- Audit breaking changes dan deprecation. Baca perubahan untuk setiap versi mayor di antara versi saat ini dan target, bukan hanya versi terakhir.
- Adopsi fitur baru secara sadar. Fitur baru tidak harus dipakai hari itu. Catat mana yang relevan.
- Gunakan tabel proto diff. Google menyediakan tabel perbedaan antarversi, misalnya v25 versus v26, untuk mencari layanan, resource, enum, atau error tertentu.
Untuk agensi, tambahkan langkah yang tidak ada di dokumentasi karena memang urusan operasional Anda: bandingkan keluaran sebelum dan sesudah untuk satu akun uji, dokumentasikan perbedaan yang dapat dijelaskan, dan simpan salinan laporan lama selama masa transisi. Bila angka berbeda dan penyebabnya belum jelas, tahan laporan itu untuk keputusan anggaran.
Bagaimana memeriksa vendor konektor tanpa menjadi insinyur?
Ajukan pertanyaan yang jawabannya dapat diverifikasi, dan minta jawaban tertulis:
- Versi Google Ads API mana yang dipakai konektor kami saat ini?
- Kapan vendor berencana pindah ke v26, dan apakah sudah diuji pada akun sungguhan?
- Bagaimana vendor menangani perubahan field, misalnya bidang Enhanced Conversions yang dihapus pada v26?
- Apakah ada pemberitahuan sebelum konektor otomatis berpindah versi?
- Siapa yang menanggung perbaikan bila laporan klien kosong setelah sunset?
Jawaban samar seperti “sudah menyesuaikan” bukan bukti. Bukti yang dapat diterima adalah nomor versi, tanggal uji, dan contoh perbandingan angka pada akun yang Anda kenali. Kami tidak mengklaim vendor tertentu aman atau bermasalah; Socta tidak menguji konektor pihak ketiga untuk artikel ini.
Apa saja tanda peringatan dini di laporan?
Tidak semua masalah muncul sebagai pesan error. Pantau gejala berikut:
- Baris data tiba-tiba nol pada tanggal tertentu, lalu kembali normal.
- Kolom yang sebelumnya terisi menjadi kosong atau
null. - Jumlah konversi berubah setelah pembaruan konektor, padahal pengaturan kampanye sama.
- Kategori konversi baru muncul, misalnya nilai
MESSAGE_LEADyang masuk pada rilis v26, dan dashboard tidak punya label untuknya. - Notifikasi dari vendor tentang pemeliharaan atau perubahan versi tidak pernah dibaca siapa pun.
Tidak satu pun dari gejala ini otomatis berarti API bermasalah. Bisa saja penyebabnya zona waktu, atribusi, atau izin akun. Karena itu, urutan diagnosis penting: cek log permintaan, cek versi, baru bandingkan angka.
Kapan tidak perlu bereaksi?
Jangan tergoda membuat proyek migrasi besar hanya karena frekuensi rilis naik. Anda tidak perlu bereaksi bila:
- Tim hanya memakai antarmuka Google Ads dan ekspor manual.
- Konektor dikelola vendor yang menyediakan jadwal migrasi tertulis dan sudah Anda verifikasi.
- Versi yang dipakai punya sunset jauh dan tidak ada kebutuhan fitur baru.
Dalam kasus seperti ini, cukup masukkan tanggal sunset ke kalender dan tetapkan pemilik tugas. Mengubah versi tanpa alasan menambah risiko tanpa menambah manfaat.
Bagaimana menyusun rencana 30 hari?
| Minggu | Tindakan | Bukti selesai |
|---|---|---|
| 1 | Buat inventaris integrasi dan temukan versi API tiap koneksi | Tabel terisi, nilai “belum diketahui” ditandai |
| 2 | Cocokkan versi dengan tabel sunset resmi | Tanggal tentatif dan pemilik tugas tercatat |
| 3 | Kirim pertanyaan tertulis ke vendor konektor | Jawaban tersimpan di folder proyek |
| 4 | Uji satu akun dengan versi target, bandingkan keluaran | Catatan perbedaan beserta penjelasannya |
Rencana ini sengaja pendek. Tujuannya membuat tanggal dan pemilik terlihat, bukan menyelesaikan semua migrasi dalam satu bulan.
Catatan batas klaim
Panduan ini bersandar pada dokumentasi Google per 19 Oktober 2026. Tabel jadwal bersifat tentatif dan dapat berubah, sehingga cek ulang sebelum mengikat tenggat kontrak. Tidak ada pengujian pada akun pengiklan, tidak ada data kinerja, dan tidak ada klaim bahwa konektor tertentu terdampak. Dokumentasi menyebut jumlah versi mayor yang dijaga tersedia berbeda antara dua bagian halamannya (empat dan lima), sehingga artikel ini tidak mengandalkan angka tersebut.
Sumber primer
- Google Ads API Team, Google Ads API Release and Sunset Schedules for 2026-2027, 12 Oktober 2026: http://ads-developers.googleblog.com/2026/10/google-ads-api-release-and-sunset.html
- Google Ads API, Deprecation and sunset, diperbarui 14 Oktober 2026: https://developers.google.com/google-ads/api/docs/sunset-dates
- Google Ads API, Upgrade your API version, diperbarui 16 Oktober 2026: https://developers.google.com/google-ads/api/docs/upgrade
- Google Ads API Team, Google Ads API v22 sunset reminder, 2 September 2026: http://ads-developers.googleblog.com/
- Google Ads API, Release notes v26, 14 Oktober 2026: https://developers.google.com/google-ads/api/docs/release-notes
Butuh laporan iklan yang tidak mati saat versi API berganti?
Mulai dari inventaris, bukan dari alat baru. Socta dapat membantu merapikan website, formulir, dan alur data agar pelacakan konversi dan laporan bisnis memiliki pemilik yang jelas, serta dapat diperiksa tim teknis dan pemasaran.
