Best practice

Le seguenti best practice si applicano all'integrazione end-to-end degli annunci di Servizi locali del Centro azioni e possono essere utilizzate per evitare problemi di usabilità e prestazioni. Una bassa qualità dei dati potrebbe comportare la rimozione dell'inventario.

Feed

  • Se per un servizio non è impostata una durata, imposta duration_sec nel feed di disponibilità su una delle seguenti opzioni:
    • Il numero di secondi necessari per eseguire il servizio in modo ragionevole.

    • Il numero medio di secondi necessari per completare il servizio.

  • Assicurati che il campo di inserimento Category nel feed del commerciante sia specifico. Ad esempio, un ristorante potrebbe inviare un tipo specifico, come Francese o Giapponese. Per maggiori dettagli, consulta Tipi di luoghi per i potenziali valori delle categorie.

  • Imposta i Termini di servizio specifici del commerciante nel campo Terms del feed del commerciante in modo che sotto il pulsante Prenota venga visualizzata la seguente nota:

    Se continui, accetti i Termini di servizio di <merchant>.
    In questo caso, "Termini di servizio" è un link che, se selezionato, mostra il testo impostato nel campo di testo dei termini.

  • Comprimi i feed utilizzando gzip

Server di prenotazione

Per ottimizzare l'integrazione dell'API Maps Booking:

  • Utilizza sempre timestamp UNIX in formato UTC.
  • Genera un ID prenotazione univoco quando viene chiamata una nuova prenotazione nell'API CreateBooking .

Aggiornamenti in tempo reale

Per garantire la migliore esperienza utente durante il processo di prenotazione:

  • Per un'implementazione standard, utilizza l'API Booking Notifications per modificare l'ora di inizio, la durata e lo stato della prenotazione, ad esempio annullamento o mancato arrivo, di un appuntamento.
  • Dopo qualsiasi modifica alla prenotazione del Centro azioni da parte tua, invia sempre aggiornamenti delle prenotazioni in tempo reale dal sistema con l'API BookingNotification in tempo reale, in modo che i dati non diventino inattivi sul lato del Centro azioni. Ad esempio, puoi annullare, riprogrammare o aggiornare una prenotazione dal tuo sistema nel Centro azioni.
  • Per ogni aggiornamento della prenotazione da UpdateBookingRequest, assicurati che il valore UpdateBookingResponse contenga l' ID prenotazione e che tutti i campi aggiornati devono rispecchiare il nuovo valore.
  • Se sono state implementate le RTU dell'inventario
    • Aggiorna la disponibilità solo in batch di 100-1000 slot per chiamata API.
    • Utilizza i campi *Restrict (ad esempio startTimeRestrict) per restringere il target di modifica, ridurre le dimensioni del payload ed evitare di inviare di nuovo troppi dati invariati.
    • Se spingi più thread, implementa un backoff esponenziale per evitare errori di limitazione. Se non implementi correttamente un backoff esponenziale, potresti visualizzare un errore di quota RESOURCE_EXHAUSTED. Puoi riprovare a gestire il backoff esponenziale, ma se il tuo server raggiunge spesso le quote quando esegui ReplaceServiceAvailability, configura il tuo server in modo da sostituire in gruppo per la disponibilità. Questa soluzione impedisce errori di quota perché riduce il numero di chiamate API che l'utente può effettuare.
  • Imposta i limiti del tempo di risposta delle chiamate API su un valore inferiore a un secondo. Assicurati che il tuo server sia in grado di gestire cinque query al secondo (QPS) con una latenza inferiore al secondo per almeno il 95% delle volte.