Best practice

Le best practice riportate di seguito si applicano all'integrazione end-to-end degli annunci di Servizi locali di Actions Center e possono essere utilizzate per evitare problemi di usabilità e rendimento. La bassa qualità dei dati potrebbe comportare il ritiro dell'inventario.

Feed

  • Se la durata di un servizio non è impostata, imposta duration_sec nel feed 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 l'input del campo Category nel feed del commerciante sia specifico. Ad esempio, un ristorante potrebbe inviare un tipo specifico, come francese o giapponese. Per maggiori dettagli, consulta la sezione Tipi di luoghi per i potenziali valori di categoria.

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

    Se continui, accetti i Termini di servizio di <merchant>.
    In questo caso, "Termini di servizio" è un link che, se fatto clic, visualizza il testo impostato nel campo di testo terms.

  • Comprimi i feed utilizzando gzip

Server di prenotazione

Per ottimizzare l'integrazione dell'API Maps Booking, svolgi i seguenti passaggi:

  • Utilizza sempre i 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 la procedura di prenotazione, segui questi passaggi:

  • Per un'implementazione standard, utilizza l'API BookingNotifications per modificare l'ora di inizio, la durata e lo stato della prenotazione, ad esempio annullamento o mancato arrivo, di un appuntamento.
  • In caso di modifiche alla prenotazione nel Centro azioni da parte tua, invia sempre aggiornamenti in tempo reale delle prenotazioni dal sistema con l'API BookingNotification in modo che i dati non diventino obsoleti nel 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 debbano riflettere il nuovo valore.
  • Se sono stati implementati i report RTU sull'inventario
    • Aggiorna la disponibilità solo in batch di 100-1000 slot per chiamata API.
    • Utilizza i campi *Restrict (ad es. startTimeRestrict) per restringere il target di modifica, ridurre le dimensioni del payload ed evitare di inviare nuovamente troppi dati invariati.
    • Se esegui lo spin off di più thread, implementa un backoff esponenziale per evitare errori di throttling. Se non implementi correttamente un backoff esponenziale, potresti ricevere un RESOURCE_EXHAUSTED errore di quota. Puoi riprovare con il backoff esponenziale per gestirle, ma se noti che il tuo server spesso raggiunge le quote quando esegui ReplaceServiceAvailability, configuralo per la sostituzione collettiva per la disponibilità. Questa soluzione impedisce errori di quota perché riduce il numero di chiamate API che il tuo servizio deve effettuare.
  • Imposta i limiti di tempo di risposta delle chiamate API su meno di un secondo. Assicurati che il tuo server possa gestire cinque query al secondo (QPS) con una latenza inferiore al secondo almeno il 95% delle volte.