Praktik terbaik

Praktik terbaik berikut berlaku untuk integrasi menyeluruh dengan Pesan dengan Google dan dapat dimanfaatkan untuk menghindari masalah kegunaan dan performa. Kualitas data yang rendah dapat menyebabkan penghapusan inventaris.

Feed

  • Jika layanan tidak memiliki durasi yang ditetapkan, tetapkan duration_sec dalam feed Ketersediaan ke salah satu opsi berikut:
    • Jumlah detik yang diperlukan untuk menjalankan layanan dengan cara yang wajar.

    • Jumlah detik rata-rata yang diperlukan untuk menyelesaikan layanan.

  • Buat input kolom Category di feed penjual yang spesifik. Misalnya, restoran dapat mengirimkan jenis tertentu, seperti Prancis atau Jepang. Untuk mengetahui detailnya, lihat Jenis tempat untuk mengetahui potensi nilai kategori.

  • Tetapkan persyaratan layanan khusus penjual di kolom Terms pada feed Penjual sehingga catatan berikut muncul di bawah tombol Pesan:

    Dengan melanjutkan, Anda menyetujui Persyaratan Layanan <merchant>.
    Dalam hal ini, "Persyaratan Layanan" adalah link yang, saat diklik, akan menampilkan teks yang disetel di kolom teks terms.

  • Kompresi feed Anda menggunakan gzip

Server Pemesanan

Untuk mengoptimalkan integrasi Maps Booking API, lakukan hal berikut:

  • Selalu gunakan stempel waktu UNIX dalam format UTC.
  • Buat ID pemesanan unik saat pemesanan baru di CreateBooking API dipanggil.

Update realtime

Untuk memastikan pengalaman pengguna terbaik selama proses pemesanan, lakukan hal berikut:

  • Untuk penerapan standar, gunakan BookingNotifications API untuk mengubah waktu mulai, durasi, dan status pemesanan, seperti pembatalan atau ketidakhadiran untuk janji temu.
  • Setelah Anda mengubah pemesanan Reservasi dengan Google dari pihak Anda, selalu kirimkan pembaruan pemesanan real-time dari sistem dengan BookingNotification API secara real-time agar data tersebut tidak menjadi usang di sisi Pesan dengan Google. Misalnya, Anda dapat membatalkan, menjadwalkan ulang, atau memperbarui pemesanan dari sistem Anda di Pesan dengan Google.
  • Untuk setiap pembaruan pemesanan dari UpdateBookingRequest, pastikan nilai UpdateBookingResponse berisi ID pemesanan dan semua kolom yang diperbarui harus mencerminkan nilai baru.
  • Jika RTU Inventaris diterapkan
    • Hanya perbarui ketersediaan dalam batch 100-1000 slot per panggilan API.
    • Gunakan kolom *Restrict (seperti startTimeRestrict) untuk mempersempit target edit, kurangi ukuran payload dan hindari mengirim terlalu banyak data yang tidak berubah.
    • Jika Anda meluncurkan beberapa thread, implementasikan backoff eksponensial untuk mencegah error throttle. Jika tidak menerapkan backoff eksponensial dengan benar, Anda mungkin mendapatkan error kuota RESOURCE_EXHAUSTED. Anda dapat mencoba kembali backoff eksponensial untuk menanganinya, tetapi jika server Anda sering kali mencapai kuota saat Anda menjalankan ReplaceServiceAvailability, konfigurasikan server Anda ke penggantian batch untuk ketersediaan. Solusi ini mencegah error kuota karena mengurangi jumlah panggilan API yang harus dilakukan oleh layanan Anda.
  • Tetapkan batas waktu respons panggilan API Anda menjadi kurang dari satu detik. Pastikan server Anda dapat menangani lima kueri per detik (QPS) dengan latensi sub-detik setidaknya 95% sepanjang waktu.