Bonnes pratiques

Les bonnes pratiques suivantes s'appliquent à l'intégration de bout en bout des annonces Local Services dans Actions Center et peuvent être utilisées pour éviter les problèmes d'usabilité et de performances. Une mauvaise qualité des données peut entraîner la suppression de l'inventaire.

Flux

  • Si la durée d'un service n'est pas définie, définissez duration_sec dans le flux de disponibilité sur l'une des valeurs suivantes :
    • Nombre de secondes nécessaires pour effectuer le service de manière raisonnable.

    • Nombre moyen de secondes nécessaires pour effectuer le service.

  • Assurez-vous que l'entrée du champ Category dans le flux du marchand est spécifique. Par exemple, un restaurant peut envoyer un type de restaurant spécifique (restaurant de cuisine italienne ou japonaise, par exemple). Pour en savoir plus sur différentes valeurs de catégories potentielles, consultez l'article Types de lieux.

  • Définissez les conditions d'utilisation spécifiques au marchand dans le champ Terms du flux du marchand afin que la note suivante s'affiche sous le bouton Réserver:

    En continuant, vous acceptez les Conditions d'utilisation de <merchant>.
    L'utilisateur peut alors cliquer sur "Conditions d'utilisation" et afficher le texte défini dans le champ textuel terms.

  • Compresser vos flux avec gzip

Serveur de réservation

Pour optimiser l'intégration de l'API Maps Booking, procédez comme suit:

  • Utilisez toujours des codes temporels UNIX au format UTC.
  • Générez un ID de réservation unique lorsqu'une nouvelle réservation est appelée dans l'API CreateBooking .

Mises à jour en temps réel

Pour garantir la meilleure expérience utilisateur possible lors du processus de réservation, procédez comme suit:

  • Pour une implémentation standard, utilisez l'API BookingNotifications pour modifier l'heure de début, la durée et l'état de réservation (par exemple, annulation ou absence) d'un rendez-vous.
  • En cas de modification de la réservation dans Actions Center de votre côté, envoyez toujours des mises à jour des réservations en temps réel à partir du système avec l'API BookingNotification afin que les données ne deviennent pas obsolètes du côté d'Actions Center. Par exemple, vous pouvez annuler, replanifier ou modifier une réservation depuis votre système dans le Centre d'actions.
  • Pour chaque mise à jour de réservation à partir de UpdateBookingRequest, assurez-vous que la valeur UpdateBookingResponse contient l'ID de réservation et que tous les champs mis à jour doivent refléter la nouvelle valeur.
  • Si des rapports RTU sur l'inventaire sont mis en œuvre :
    • Ne mettez à jour la disponibilité que par lots de 100 à 1 000 créneaux par appel d'API.
    • Utilisez des champs *Restrict (comme startTimeRestrict) pour affiner la cible de modification, réduire la taille de la charge utile et éviter de renvoyer trop de données inchangées.
    • Si vous désactivez plusieurs threads, implémentez un intervalle exponentiel entre les tentatives pour éviter les erreurs de limitation. Si vous n'implémentez pas correctement un intervalle exponentiel entre les tentatives, vous risquez de recevoir une erreur de quota RESOURCE_EXHAUSTED. Vous pouvez réessayer l'intervalle exponentiel entre les tentatives pour les gérer, mais si vous constatez que votre serveur atteint souvent des quotas lorsque vous exécutez ReplaceServiceAvailability, configurez-le pour effectuer un remplacement par lot pour la disponibilité. Cette solution évite les erreurs de quota, car elle réduit le nombre d'appels d'API que votre serveur doit effectuer.
  • Définissez les limites de temps de réponse de vos appels d'API sur moins d'une seconde. Assurez-vous que votre serveur peut gérer cinq requêtes par seconde (RPS) avec une latence inférieure à une seconde au moins 95% du temps.