Praktik terbaik

Praktik terbaik berikut berlaku untuk integrasi Tindakan Pusat Janji Temu Ulang dan dapat dimanfaatkan untuk menghindari masalah kegunaan dan performa. Kualitas data yang rendah dapat menyebabkan penghapusan inventaris.

Feed

  • Jika layanan tidak memiliki durasi tetap, tetapkan duration_sec di Feed ketersediaan ke salah satu dari berikut:
    • Jumlah detik yang diperlukan untuk melakukan layanan dengan cara yang wajar.

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

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

  • Tetapkan persyaratan layanan khusus penjual di kolom Terms 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, jika diklik, akan menampilkan teks yang ditetapkan di kolom teks terms.

  • Mengompresi feed menggunakan gzip

Booking Server

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 tidak hadir, dari janji temu.
  • Setelah ada perubahan pada pemesanan Actions Center dari pihak Anda, selalu kirim pembaruan pemesanan real-time dari sistem dengan BookingNotification API secara real-time sehingga data tidak menjadi usang di sisi Actions Center. Misalnya, Anda dapat membatalkan, menjadwalkan ulang, atau memperbarui pemesanan dari sistem di Pusat Tindakan.
  • Untuk setiap pembaruan pemesanan dari UpdateBookingRequest, pastikan nilai UpdateBookingResponse berisi ID pemesanan dan semua kolom yang diperbarui harus mencerminkan nilai baru.
  • Jika Inventory RTU diterapkan
    • Hanya perbarui ketersediaan dalam batch 100-1.000 slot per panggilan API.
    • Gunakan kolom *Restrict (seperti startTimeRestrict) untuk mempersempit target pengeditan, mengurangi ukuran payload, dan menghindari pengiriman ulang terlalu banyak data yang tidak berubah.
    • Jika Anda memisahkan beberapa thread, terapkan 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 Anda mendapati bahwa server Anda sering kali mencapai kuota saat menjalankan ReplaceServiceAvailability, konfigurasikan server untuk penggantian batch untuk ketersediaan. Solusi ini mencegah error kuota karena mengurangi jumlah panggilan API yang harus dilakukan server Anda.
  • Tetapkan batas waktu respons panggilan API Anda kurang dari satu detik. Pastikan server Anda dapat menangani lima kueri per detik (QPS) dengan latensi sub-detik setidaknya 95% dari waktu.