Pesquise à medida que escreve

A barra de pesquisa de comércio eletrónico moderna é muito mais do que apenas um campo de entrada. É um assistente dinâmico e interativo que orienta os utilizadores para os produtos certos antes mesmo de terminarem de introduzir texto. Esta experiência de pesquisa à medida que escreve (SAYT), que apresenta sugestões de consultas, marcas populares, categorias relevantes e até os principais resultados de produtos em tempo real, aumenta a interação do utilizador e a probabilidade de conversão.

Embora a Vertex AI Search for commerce forneça APIs distintas para o preenchimento automático de consultas e a pesquisa de produtos, deixa intencionalmente a implementação final de uma experiência do utilizador SAYT em aberto.

Este guia de criação com o Vertex AI Search for commerce explora dois padrões de design principais para implementar um widget SAYT robusto através das APIs Vertex AI Search for commerce, detalhando as vantagens e desvantagens de cada abordagem.

Compreenda os componentes principais

Para criar uma funcionalidade SAYT abrangente, tem de compreender as duas APIs fundamentais fornecidas pelo Vertex AI Search para comércio:

  1. API CompleteQuery: esta é a base das suas sugestões de preenchimento automático.

    • Função: para uma determinada string de entrada, como lipst, devolve uma lista de conclusões de consultas sugeridas, incluindo batom e brilho labial, marcas populares associadas e categorias relevantes.
    • Custo: esta API está incluída nos preços do pacote Vertex AI Search for commerce.
    • Desempenho: é uma API de elevado débito concebida para as respostas rápidas e de baixa latência necessárias para uma experiência de introdução de texto. Tiram partido das funcionalidades de aprendizagem automática, incluindo a correção ortográfica e as sugestões concebidas para gerar resultados, todas preparadas com base nos eventos de pesquisa diários da sua loja.

  2. API Search:este é o seu motor de descoberta de produtos principal.

    • Função:para uma determinada consulta, devolve uma lista classificada de resultados de produtos relevantes.
    • Custo:esta é uma API paga e a respetiva utilização afeta diretamente os seus custos operacionais.
    • Eventos: para a preparação de modelos e as estatísticas, cada chamada da API Search deve ser associada a um evento de pesquisa para acompanhar o comportamento do utilizador e melhorar os modelos de relevância ao longo do tempo.

Para criar a experiência SAYT, tem de escrever uma API wrapper ou uma lógica de frontend que chame ambas as APIs e combine os respetivos resultados numa interface do utilizador única e coesa.

Padrão de implementação 1: abordagem direta, mas mais dispendiosa

Este é o método mais simples de implementar. A lógica é que, para cada tecla premida, faz chamadas paralelas às APIs CompleteQuery e Search.

Flow

O fluxo segue este caminho sequencial:

  1. Um utilizador introduz um caráter, como l.
  2. A sua aplicação envia l para a API CompleteQuery.
  3. Em simultâneo, a sua aplicação envia l para a API Search.
  4. Os resultados são combinados e apresentados.
  5. O utilizador introduz outro caráter (l), o que torna a consulta li.
  6. O processo repete-se para a nova consulta li.

alt_text

Vantagens

As vantagens incluem uma implementação rápida, o que lhe permite escrever e implementar rapidamente o registo.

Desvantagens

  • Volume elevado da API Search: esta abordagem aumenta drasticamente o número de chamadas da API Search. Uma consulta como lipstick (batom) acionaria oito pedidos de pesquisa separados, o que levaria a um aumento significativo no volume.
  • Aumento do custo: uma vez que a API Search é um serviço pago, este volume elevado traduz-se diretamente em custos operacionais mais elevados, o que dificulta a obtenção de um retorno do investimento (ROI) positivo.
  • Complexidade da gestão de eventos: cada chamada da API Search deve ser registada com um evento de pesquisa correspondente para uma medição e uma preparação do modelo precisas. O elevado volume de chamadas dificulta a garantia de que todos os eventos são capturados, o que pode levar à perda de dados e a estatísticas distorcidas.
  • Resultados potencialmente de qualidade inferior: as pesquisas de um ou dois carateres, como l, li, podem devolver resultados ruidosos ou excessivamente amplos, o que leva a uma experiência inicial menos relevante.

Este padrão é otimizado em função do custo, do desempenho e da relevância através da API CompleteQuery para decidir de forma inteligente quando chamar a API Search.

Flow

O fluxo segue este caminho sequencial:

  1. Um utilizador introduz uma consulta de texto parcial, como lip.
  2. A sua aplicação envia lip para a API CompleteQuery.
  3. A API devolve uma lista de sugestões, sendo batom provavelmente o primeiro resultado.
  4. A sua aplicação aceita a primeira sugestão (batom) e faz uma única chamada à API Search com esse termo.
  5. São apresentadas as sugestões de preenchimento automático e os resultados de produtos para batom.
  6. À medida que o utilizador continua a escrever lábios, lábios, ..., pode adicionar lógica para fazer uma nova chamada de pesquisa apenas se a primeira sugestão de preenchimento automático mudar.

Vantagens

  • Redução significativa dos custos: ao reduzir drasticamente o número de chamadas API Search, este método mantém os custos sob controlo.
  • Volume de eventos e APIs controlado: os volumes de eventos e APIs são geríveis e previsíveis, o que garante dados mais fiáveis para a preparação de modelos e as estatísticas.
  • Maior relevância: está a pesquisar termos mais completos e prováveis, o que oferece resultados de produtos de maior qualidade no widget SAYT.
  • Melhor ROI: os custos mais baixos e uma melhor experiência do utilizador contribuem para um retorno do investimento mais forte.

alt_text

Processamento de casos extremos

Esta abordagem é superior, mas requer o processamento de alguns casos extremos:

  • Sem sugestões: se a API CompleteQuery não devolver sugestões, a sua lógica deve recorrer à chamada da API Search com a entrada não processada do utilizador.
  • Consulta parcial vs. sugerida: em casos raros, um utilizador pode querer ver resultados para o termo parcial, como olho, em vez da principal sugestão, sombra para os olhos. Embora seja uma pequena compensação, a abordagem otimizada dá prioridade à intenção do utilizador mais provável.

Meça o sucesso com IDs de experiências

Independentemente da implementação que escolher, é importante medir o desempenho do widget de preenchimento automático de forma independente da página principal de resultados da pesquisa. Se usar o mesmo acompanhamento para ambas, não vai poder determinar se a funcionalidade SAYT está realmente a melhorar as taxas de cliques e as conversões.

A solução para medir as taxas de conversão e de cliques do widget SAYT especificamente é usar experimentIds distintos nos seus eventos de pesquisa que diferenciem estas métricas das dos eventos de pesquisa principais.

  • Eventos SAYT: atribua um ID específico, como "experimentId": "sayt-widget", a todos os eventos de pesquisa originados da capacidade de pesquisa à medida que escreve.
  • Eventos de pesquisa principal: use um ID diferente (ou nenhum ID) para as pesquisas iniciadas quando um utilizador prime Enter ou clica em Pesquisar para aceder à página principal de resultados da pesquisa.

Ao segmentar os seus eventos desta forma, pode usar os painéis de controlo de estatísticas na consola do Vertex AI para filtrar e comparar o desempenho do widget SAYT com a experiência de pesquisa padrão, o que lhe dá estatísticas claras e acionáveis.

Conclusão

O Vertex AI Search for commerce fornece os componentes para criar uma experiência de pesquisa à medida que escreve. Ao atuar como o arquiteto que concebe a interação entre as APIs CompleteQuery e Search, pode criar uma capacidade de pesquisa que estabeleça a ligação entre a experiência do utilizador e o desempenho. Na maioria dos exemplos de utilização, a abordagem otimizada oferece uma experiência relevante para o utilizador, ao mesmo tempo que evita operações que exigem muitos recursos de computação.