Melhore o Vertex AI Search para comércio com a personalização do CRM

Este guia de implementação da API para o Vertex AI Search for commerce descreve como usar os seus dados de gestão das relações com clientes (CRM) para personalizar as experiências de pesquisa no Vertex AI Search for commerce. Ao integrar atributos de utilizadores do seu CRM, pode oferecer resultados de pesquisa mais relevantes, o que melhora a interação dos clientes e a conversão. Este documento detalha o processo de integração destes atributos do utilizador, incluindo considerações sobre os dados e especificações técnicas.

Selecione os dados para personalização

A eficácia da personalização depende da qualidade, da cobertura e da relevância dos dados de CRM que fornece. Considere que informações sobre um cliente influenciariam genuinamente os resultados da pesquisa que um associado de vendas experiente poderia oferecer.

Quando tiver testes-piloto concluídos, terá recomendações mais fortes sobre que dados são (e não são) impactantes.

Estas categorias de dados constituem as informações mais reveladoras sobre o comportamento dos utilizadores do seu site de comércio.

  • Informações geográficas: localização do cliente, como o estado ou o país. As informações do código postal são demasiado detalhadas. Consulte a secção sobre Detalhes excessivos para mais informações.
  • Dados demográficos: caraterísticas essenciais dos clientes, como a idade e o género.
    • Saber a faixa etária de um cliente (18-24 em vez de 55-64 anos) provavelmente informaria diferentes estratégias de apresentação de produtos para artigos como vestuário ou eletrónica. Estes são dados de grande impacto.
  • Perfis fictícios de clientes: por exemplo, um comprador preocupado com o orçamento ou frugal, em oposição a um comprador que gasta muito.

Categorias de dados com menor probabilidade de serem impactantes

Estas categorias de dados têm um impacto marginal na captura de dados de comércio.

  • Atributos derivados do histórico de compras:
    • O nosso sistema já incorpora o comportamento de compra anterior para personalização.
    • O envio de atributos como user bought a green dress yesterday é redundante, porque estas informações são captadas e usadas de forma nativa.
    • Foque-se em novas estatísticas do seu CRM.
  • Dados de resposta de marketing específicos, como Clicked email #7:
    • Embora seja relevante para a análise de campanhas de marketing, não indica à IA que resultado da pesquisa deve apresentar.

Integralidade dos dados

Além da relevância, a integridade dos seus dados em toda a base de utilizadores afeta significativamente a sua utilidade para a personalização. Um atributo é mais valioso quando está disponível para uma parte substancial dos seus utilizadores, o que permite ao sistema identificar padrões mais amplos e aplicar a personalização de forma mais abrangente.

  • Muito útil:
    • Atributos que tem para uma maioria significativa dos seus utilizadores, como shipping_state:MA, se estiverem disponíveis para 70% da sua base de utilizadores.
    • Isto permite um reconhecimento de padrões robusto e uma aplicação generalizada da personalização.
  • Menos útil:
    • Atributos disponíveis apenas para uma pequena fração dos seus utilizadores, como hair_color:blonde, se estiverem disponíveis apenas para 0,1% da sua base de utilizadores.

Embora sejam interessantes, estes dados escassos dificultam a derivação de sinais de personalização significativos por parte do sistema devido à falta de exemplos suficientes. Em alternativa, dê prioridade aos atributos que oferecem uma cobertura mais ampla nos perfis dos clientes.

Diretrizes de nível de detalhe dos dados

O nível adequado de detalhe dos dados é fundamental para uma personalização eficaz. Os dados demasiado abrangentes ou demasiado específicos podem diminuir a capacidade do sistema de identificar padrões significativos. Procure atributos que segmentem a sua base de clientes em grupos acionáveis.

Nível de detalhe adequado

Exemplos de granularidade adequada são campos para:

  • Género
  • Estado
  • Cidade
  • Faixa etária (como 30 a 39 anos)

Este nível de detalhe permite a diferenciação para a personalização sem criar um número incontrolável de categorias.

Nível de detalhe insuficiente

Um exemplo de granularidade insuficiente é country:US se a grande maioria da sua base de clientes residir nos Estados Unidos. Isto deve-se ao facto de um atributo com pouca variação na sua base de clientes oferecer um valor mínimo para a personalização.

Nível de detalhe excessivo

Exemplos de nível de detalhe excessivo:

  • Códigos postais exatos (zipcode:12345): com dezenas de milhares de códigos postais potenciais, a maioria tem muito poucos clientes associados. Esta atomização dilui o sinal. Se usar códigos postais, reduza-os aos dois primeiros dígitos para alcançar um nível de detalhe mais adequado. Os dois primeiros dígitos dos códigos postais são mapeados aproximadamente para áreas do tamanho de um estado.
  • Idades exatas (age:37): isto cria um número excessivo de categorias de idades. Para reduzir o número, agrupe dados numéricos, como a idade, em ~10 recipientes ou segmentos predefinidos (como age:30-39).

Outras diretrizes de dados

Esta secção aborda formatos de dados categóricos e outros.

Formato de dados de categoria

Este sistema está otimizado para dados categóricos: valores distintos e com nome, como:

  • state:MA
  • gender:male

Dados numéricos

Por este motivo, todos os atributos numéricos, como a idade, o rendimento ou a frequência, devem ser agrupados em intervalos significativos antes da transmissão de dados.

Seguem-se exemplos incorretos e corretos, respetivamente:

  • age:37
  • age:30-39

Restrições de dados adicionais

  • Limite de atributos: cada consulta suporta até 100 pares de chave-valor. O suporte para mais pares pode ser adicionado em lançamentos futuros.
  • Chaves duplicadas: não são permitidas chaves duplicadas numa única consulta. No entanto, são suportados vários valores por chave.
  • PII proibidas: sob nenhuma circunstância deve enviar informações de identificação pessoal (PII) específicas, como endereços de email de clientes, números da segurança social, nomes completos ou dados financeiros, como números de cartões de crédito, sob qualquer forma.

Integração da API e transmissão de dados

Os dados de clientes devem ser transmitidos no campo query dos seus pedidos de pesquisa e não nos eventos.

Estrutura do buffer de protocolo (para programadores)

Os atributos do utilizador são definidos na mensagem SearchRequest como um mapa de strings para uma mensagem StringList.

Ver amostra de protobuf

// A list of string values.
message StringList {
// String values.
repeated string values;
}

// Request message for [SearchService.Search][] method.
message SearchRequest {
...
// The user attributes that could be used for personalization of search.
maptring, StringList> user_attributes;
}

Exemplo de pedido JSON

Este exemplo ilustra como estruturar user_attributes numa solicitação de pesquisa JSON.

Ver amostra JSON

{
...

user_attributes: [
       { key: "pets" # note keys can be hashed or unhashed
         value {
           values: "dog" # Note: these values MUST be hashed
           values: "cat"
         }
       },
       { key: "state"
         value {
           values: "CA"
         }
       }
      ]
}

Resposta da API

Não existem alterações à API SearchResponse quando usa esta funcionalidade. A personalização ocorre internamente com base nos atributos do utilizador fornecidos.

Requisitos de aplicação de hash aos dados

Para garantir a privacidade e a segurança dos dados, os valores dos atributos têm de ter hash. As chaves podem ser enviadas com ou sem hash.

Aplicação de hash às chaves

As chaves de atributos, como pet_owner e state, podem ser enviadas na respetiva forma de string original ou com hash. Ambos são aceitáveis.

Por exemplo:

  • Aceitável: pet_owner
  • Aceitável: hash(pet_owner)

Aplicação de hash aos valores

Os valores dos atributos, como dog e CA, têm de ter hash. Não é permitido o envio de valores de texto simples.

Por exemplo:

  • Aceitável: hash(dog)
  • Não aceitável: "Dog"

Hash de chave-valor combinado

Se a chave e o valor tiverem de ser aplicados hash, têm de ser aplicados hash de forma independente. Não aplique hash à string de chave-valor combinada.

Por exemplo:

  • Aceitável: pet_owner:hash("dog")
  • Aceitável: hash(pet_owner):hash("dog")
  • Não aceitável: hash("Pet_owner:dog")

Práticas recomendadas para a transmissão de dados

Esta secção descreve várias práticas recomendadas para a transmissão de dados, incluindo como processar valores repetidos, a consistência dos dados, a flexibilidade da nomenclatura das chaves de atributos e o processamento de perfis de utilizadores variados.

Como processar valores repetidos

Se um utilizador tiver vários valores para um único atributo, como ter um cão e um gato, forneça todos os valores num único elemento key no elemento StringList.

Estes exemplos de código demonstram exemplos de utilização incorreta e correta, respetivamente:

Ver amostra

// This is incorrect because it sends the same key multiple times for different
// values, causing only one of the two values for pets to be used, choosing one
// value or the other in an inconsistent manner.
{
  key: "pets",
  value {
    values: "dog"
  }
},
{
  key: "pets",
  value {
    values: "cat"
  }
}

Ver amostra

{
  key: "pets",
  value {
    values: "dog",
    values: "cat"
  }
}

Consistência dos dados

Mantenha uma consistência rigorosa na ortografia, nos espaços e na utilização de maiúsculas e minúsculas de todas as chaves e valores. O sistema interpreta até as variações menores como categorias distintas.

Por exemplo, State:MA, state:MA, state:ma, STATE:MA e residence_state:MA são tratados como atributos separados e não relacionados.

Flexibilidade na nomenclatura das chaves de atributos

Embora seja consistente, a convenção de nomenclatura específica para as chaves de atributos (por exemplo, pet_owner, pets, codeabc) não afeta inerentemente a capacidade do sistema de usar os dados. O aspeto crucial é a consistência dos dados que transmite.

Como lidar com perfis de utilizadores variados

É aceitável que diferentes utilizadores tenham diferentes conjuntos de atributos.

  • Exemplo: o Utilizador A pode ter age:30-39 e pet:dog, enquanto o Utilizador B tem gender:male, mas não tem dados sobre animais de estimação nem idade. O sistema processa os perfis parciais de forma adequada.

Atualizações dinâmicas de dados

Os atributos do utilizador podem evoluir ao longo do tempo. Pode atualizar o perfil de um utilizador com novas informações à medida que ficam disponíveis.

  • Exemplo: um utilizador inicialmente identificado com age:30-39 e pet:dog pode ter state:MA adicionado posteriormente se a respetiva localização for adquirida.

Consistência multiplataforma

Esforce-se por ter uma transmissão consistente de atributos para um determinado utilizador em todos os pontos de contacto, como a app para dispositivos móveis ou o Website. Isto garante uma experiência de personalização unificada.

  • Ótimo: o utilizador A está sempre age:30-39 na app para dispositivos móveis e no Website.
  • Subótimas: o utilizador A tem age:30-39 na app para dispositivos móveis, mas apenas pet:dog no Website.

Como processar dados em falta

Se uma informação específica sobre um utilizador não estiver disponível, não envie um marcador de posição nem um valor vazio. Basta omitir esse par de chave-valor do pedido.

  • Exemplo: evite pet:unknown ou pet:

Acesso ao SDK e à biblioteca

Pode encontrar o acesso a estas bibliotecas nas seguintes versões e posteriores: