Práticas recomendadas

As práticas recomendadas a seguir se aplicam à integração de ponta a ponta dos anúncios dos Serviços Locais do Actions Center e podem ser aproveitadas para evitar problemas de usabilidade e desempenho. A baixa qualidade dos dados pode levar à remoção do inventário.

Feeds

  • Se um serviço não tiver uma duração definida, defina duration_sec no feed de disponibilidade como uma das seguintes opções:
    • O número de segundos necessários para realizar o serviço de maneira razoável.

    • O número médio de segundos necessários para concluir o serviço.

  • Faça com que a entrada do campo Category no feed do comerciante seja específica. Por exemplo, um restaurante pode enviar um tipo específico, como francês ou japonês. Para mais detalhes, consulte Tipos de lugar para conferir possíveis valores de categoria.

  • Defina os termos de serviço específicos do comerciante no campo Terms do feed do comerciante para que a seguinte nota apareça abaixo do botão Agendar:

    Ao continuar, você concorda com os Termos de Serviço do <merchant>.
    Nesse caso, "Termos de Serviço" é um link que, quando clicado, mostra o texto definido no campo de texto terms.

  • Compactar seus feeds usando gzip

Servidor de agendamento

Para otimizar a integração da API Maps Booking, faça o seguinte:

  • Sempre use carimbos de data/hora UNIX no formato UTC.
  • Gere um ID de agendamento exclusivo quando uma nova reserva na API CreateBooking for chamada.

Atualizações em tempo real

Para garantir a melhor experiência do usuário durante o processo de reserva, faça o seguinte:

  • Para uma implementação padrão, use a API BookingNotifications para mudar o horário de início, a duração e o estado da reserva, como cancelamento ou ausência, de um horário.
  • Sempre envie atualizações de agendamento em tempo real do sistema com a API BookingNotification para que os dados não fiquem desatualizados no Actions Center. Por exemplo, é possível cancelar, reagendar ou atualizar um agendamento no seu sistema na Central de ações.
  • Para cada atualização de reserva de UpdateBookingRequest, verifique se o valor UpdateBookingResponse contém o código da reserva e se todos os campos atualizados refletem o novo valor.
  • Se o RTU de inventário for implementado
    • Atualize a disponibilidade apenas em lotes de 100 a 1.000 espaços por chamada de API.
    • Use campos *Restrict (como startTimeRestrict) para restringir o destino da edição, reduzir o tamanho do payload e evitar o reenvio de muitos dados inalterados.
    • Se você criar várias linhas de execução, implemente uma espera exponencial para evitar erros de limitação. Se você não implementar uma retirada exponencial corretamente, poderá receber um erro de cota RESOURCE_EXHAUSTED. É possível tentar novamente a espera exponencial para processá-los, mas, se você perceber que o servidor atinge frequentemente as cotas ao executar ReplaceServiceAvailability, configure o servidor para substituição em lote da disponibilidade. Essa solução evita erros de cota porque reduz o número de chamadas de API que seu servidor precisa fazer.
  • Defina os limites de tempo de resposta da chamada de API em menos de um segundo. Verifique se o servidor pode processar cinco consultas por segundo (QPS) com latência inferior a um segundo pelo menos 95% do tempo.