Best Practices

Die folgenden Best Practices gelten für die End-to-End-Integration von Anzeigen für lokale Dienstleistungen im Actions Center und können dazu beitragen, Probleme mit der Nutzerfreundlichkeit und Leistung zu vermeiden. Eine geringe Datenqualität kann zu einer Deaktivierung von Inventar führen.

Feeds

  • Wenn für einen Dienst keine Länge festgelegt ist, legen Sie duration_sec im Verfügbarkeitsfeed auf eine der folgenden Optionen fest:
    • Die Anzahl der Sekunden, die die Ausführung des Dienstes in angemessener Weise in Anspruch nimmt.

    • Die durchschnittliche Anzahl der Sekunden, die für die Ausführung des Dienstes erforderlich sind.

  • Die Eingabe im Feld Category im Feed des Händlers muss spezifisch sein. Ein Restaurant kann beispielsweise eine bestimmte Küche wie Französisch oder Japanisch angeben. Weitere Informationen zu möglichen Werten findest du hier.

  • Legen Sie im Feld Terms des Händlerfeeds händlerspezifische Nutzungsbedingungen fest, damit die folgende Notiz unter der Schaltfläche Buchen angezeigt wird:

    Wenn Sie fortfahren, akzeptieren Sie die Nutzungsbedingungen von <merchant>.
    „Nutzungsbedingungen“ ist dann ein Link, über den der Text eingeblendet wird, der im Textfeld terms (Bedingungen) festgelegt wurde.

  • Feeds mit gzip komprimieren

Buchungsserver

So optimieren Sie die Einbindung der Maps Booking API:

  • Verwenden Sie immer UNIX-Zeitstempel im UTC-Format.
  • Eine eindeutige Buchungs-ID generieren, wenn eine neue Buchung in der CreateBooking API aufgerufen wird.

Echtzeitaktualisierungen

So sorgen Sie für eine bestmögliche Nutzererfahrung während des Buchungsvorgangs:

  • Verwenden Sie für eine Standardimplementierung die BookingNotifications API, um den Beginn, die Dauer und den Buchungsstatus eines Termins zu ändern, z. B. Stornierung oder Nichterscheinen.
  • Senden Sie bei jeder Änderung an einer Buchung im Actions Center Echtzeitaktualisierungen der Buchung über die BookingNotification API, damit die Daten im Actions Center nicht veraltet sind. So können Sie beispielsweise eine Buchung über Ihr System im Actions Center stornieren, verschieben oder aktualisieren.
  • Achten Sie bei jeder Buchungsaktualisierung von UpdateBookingRequest darauf, dass der Wert UpdateBookingResponse die Buchungs-ID enthält und dass alle aktualisierten Felder den neuen Wert widerspiegeln.
  • Wenn Inventar-RTU implementiert sind
    • Aktualisieren Sie die Verfügbarkeit nur in Batches von 100 bis 1.000 Slots pro API-Aufruf.
    • Verwenden Sie *Restrict-Felder (z. B. startTimeRestrict), um das Bearbeitungsziel einzugrenzen, die Nutzlastgröße zu reduzieren und zu vermeiden, dass zu viele unveränderte Daten noch einmal gesendet werden.
    • Wenn du mehrere Threads abgibst, implementiere einen exponentiellen Backoff, um Drosselungsfehler zu vermeiden. Wenn Sie einen exponentiellen Backoff nicht richtig implementieren, erhalten Sie möglicherweise einen RESOURCE_EXHAUSTED Kontingentfehler. Sie können den exponentiellen Backoff noch einmal versuchen, um diese zu verarbeiten. Wenn Sie jedoch feststellen, dass Ihr Server bei der Ausführung von ReplaceServiceAvailability häufig Kontingente erreicht, konfigurieren Sie ihn für Batch-Updates für die Verfügbarkeit. Mit dieser Lösung werden Kontingentfehler verhindert, da die Anzahl der API-Aufrufe, die Ihr Server ausführen muss, reduziert wird.
  • Legen Sie für die Antwortzeit von API-Aufrufen ein Limit von weniger als einer Sekunde fest. Ihr Server sollte in der Lage sein, in mindestens 95% der Fälle fünf Abfragen pro Sekunde (Queries per Second, QPS) mit einer Latenz von unter einer Sekunde zu verarbeiten.