Prácticas recomendadas

Las siguientes prácticas recomendadas se aplican a la integración de extremo a extremo de los anuncios de Servicios Locales del Centro de Acciones y se pueden aprovechar para evitar problemas de usabilidad y rendimiento. La baja calidad de los datos puede provocar la eliminación del inventario.

Feeds

  • Si un servicio no tiene una duración establecida, establece duration_sec en el feed de disponibilidad en una de las siguientes opciones:
    • Es la cantidad de segundos que tarda en realizar el servicio de una manera razonable.

    • Es la cantidad promedio de segundos necesarios para completar el servicio.

  • Asegúrate de que la entrada del campo Category en el feed del comercio sea específica. Por ejemplo, un restaurante puede enviar un tipo específico, como francés o japonés. Para obtener más detalles, consulta Tipos de lugar para los valores de categoría posibles.

  • Establece las condiciones del servicio específicas del comercio en el campo Terms del feed de Merchant Center para que aparezca la siguiente nota debajo del botón Reservar:

    Si continúas, aceptas las Condiciones del Servicio de <merchant>.
    En este caso, "Condiciones del Servicio" es un vínculo que, cuando se hace clic en él, muestra el texto establecido en el campo de texto terms.

  • Cómo comprimir tus feeds con gzip

Servidor de reservas

Para optimizar la integración de la API de Maps Booking, haz lo siguiente:

  • Usa siempre marcas de tiempo UNIX en formato UTC.
  • Genera un ID de reserva único cuando se llame a una reserva nueva en la API de CreateBooking .

Actualizaciones en tiempo real

Para garantizar la mejor experiencia del usuario durante el proceso de reserva, haz lo siguiente:

  • Para una implementación estándar, usa la API de BookingNotifications para cambiar la hora de inicio, la duración y el estado de la reserva, como la cancelación o la ausencia, de una cita.
  • Cuando realices cualquier cambio en la reserva de Actions Center, envía siempre actualizaciones de reservas en tiempo real desde el sistema con la API de BookingNotification para que los datos no se vuelvan obsoletos en Actions Center. Por ejemplo, puedes cancelar, reprogramar o actualizar una reserva desde tu sistema en el Centro de acciones.
  • Para cada actualización de reserva de UpdateBookingRequest, asegúrate de que el valor de UpdateBookingResponse contenga el ID de reserva y de que todos los campos actualizados reflejen el valor nuevo.
  • Si se implementan las RTU de inventario
    • Solo actualiza la disponibilidad en lotes de 100 a 1,000 horarios por llamada a la API.
    • Usa campos *Restrict (como startTimeRestrict) para limitar el objetivo de edición, reducir el tamaño de la carga útil y evitar volver a enviar demasiados datos sin cambios.
    • Si generas varios subprocesos, implementa una retirada exponencial para evitar errores de limitación. Si no implementas una retirada exponencial correctamente, es posible que obtengas un error de cuota de RESOURCE_EXHAUSTED. Puedes volver a intentar la retirada exponencial para controlarlas, pero, si notas que tu servidor suele alcanzar cuotas cuando ejecutas ReplaceServiceAvailability, configúralo para que realice un reemplazo por lotes para la disponibilidad. Esta solución evita los errores de cuota porque reduce la cantidad de llamadas a la API que debe realizar tu servicio.
  • Establece los límites de tiempo de respuesta de las llamadas a la API en menos de un segundo. Asegúrate de que tu servidor pueda manejar cinco consultas por segundo (QPS) con una latencia inferior a un segundo, al menos, el 95% del tiempo.