Melhorar a Vertex AI Search for commerce com a personalização do CRM

Este guia de implementação da API para a Vertex AI Search for commerce descreve como usar os dados do seu Customer Relationship Management (CRM) para personalizar as experiências de pesquisa na Vertex AI Search for commerce. Ao integrar os atributos do usuário do seu CRM, você pode oferecer resultados de pesquisa mais relevantes, melhorando o engajamento e a conversão dos clientes. Este documento detalha o processo de integração desses atributos do usuário, incluindo considerações sobre dados e especificações técnicas.

Selecionar dados para personalização

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

Quando os testes piloto forem concluídos, você terá recomendações mais fortes sobre quais dados são (e não são) relevantes.

Essas categorias de dados constituem as informações mais relevantes sobre o comportamento do usuário no seu site de comércio.

  • Informações geográficas: localização do cliente, como estado ou país. As informações de CEP são muito detalhadas. Consulte a seção Granularidade excessiva para mais informações.
  • Dados demográficos: principais características do cliente, como idade e gênero.
    • Conhecer a faixa etária de um cliente (18 a 24 anos em vez de 55 a 64 anos) provavelmente informaria diferentes estratégias de exibição de produtos para itens como roupas ou eletrônicos. Esses dados são muito importantes.
  • Personas de clientes: por exemplo, um comprador consciente do orçamento ou econômico em vez de um grande gastador.

Categorias de dados com menos probabilidade de serem impactantes

Essas categorias de dados têm um impacto marginal na coleta de dados de comércio.

  • Atributos derivados do histórico de compras:
    • Nosso sistema já incorpora o comportamento de compra anterior para personalização.
    • Enviar atributos como user bought a green dress yesterday é redundante, porque essas informações são capturadas e usadas de forma nativa.
    • Foque em insights inovadores do seu CRM.
  • Dados específicos de resposta de marketing, como Clicked email #7:
    • Embora seja relevante para a análise de campanhas de marketing, não informa à IA qual resultado da pesquisa mostrar.

Integridade dos dados

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

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

Embora sejam interessantes, esses dados esparsos dificultam a derivação de sinais de personalização significativos pelo sistema devido à falta de exemplos suficientes. Em vez disso, priorize atributos que ofereçam uma cobertura mais ampla nos perfis dos clientes.

Diretrizes de granularidade de dados

O nível adequado de granularidade dos dados é crucial para uma personalização eficaz. Dados muito abrangentes ou muito específicos podem diminuir a capacidade do sistema de identificar padrões significativos. Procure atributos que segmentem sua base de clientes em grupos úteis.

Granularidade adequada

Exemplos de granularidade adequada são campos para:

  • Gênero
  • Estado
  • Cidade
  • Faixa etária (por exemplo, de 30 a 39 anos)

Esse nível de granularidade oferece diferenciação para personalização sem criar um número incontrolável de categorias.

Granularidade insuficiente

Um exemplo de granularidade insuficiente é country:US se a grande maioria da sua base de clientes reside nos Estados Unidos. Isso acontece porque um atributo com pouca variância na sua base de clientes oferece valor mínimo para a personalização.

Granularidade excessiva

Exemplos de granularidade excessiva:

  • Códigos postais ou CEPs exatos (zipcode:12345): com dezenas de milhares de códigos postais em potencial, a maioria terá poucos clientes associados. Essa atomização dilui o indicador. Se você estiver usando CEPs, corte os dois primeiros dígitos para alcançar um nível de granularidade mais adequado. Os dois primeiros dígitos dos CEPs são mapeados aproximadamente para áreas do tamanho de um estado.
  • Idades exatas (age:37): isso cria um número excessivo de categorias de idade. Para reduzir o número, agrupe dados numéricos, como idade, em aproximadamente 10 classes ou intervalos predefinidos (como age:30-39).

Outras diretrizes sobre dados

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

Formato de dados categóricos

Esse sistema é otimizado para dados categóricos: valores distintos e nomeados, como:

  • state:MA
  • gender:male

Dados numéricos

Por isso, atributos numéricos, como idade, renda ou frequência, precisam ser agrupados em intervalos significativos antes da transmissão de dados.

Estes são exemplos incorretos e corretos, respectivamente:

  • age:37
  • age:30-39

Outras restrições de dados

  • Limite de atributos: cada consulta aceita até 100 pares de chave-valor. O suporte para mais pares pode ser adicionado em versões futuras.
  • Chaves duplicadas: não são permitidas chaves duplicadas em uma única consulta. No entanto, é possível usar vários valores por chave.
  • PII proibida: em nenhuma circunstância envie informações de identificação pessoal (PII) específicas, como endereços de e-mail de clientes, CPF ou CNPJ, nomes completos ou dados financeiros, como números de cartão de crédito, de nenhuma forma.

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

Os dados do cliente precisam ser transmitidos no campo query das solicitações de pesquisa, não nos eventos.

Estrutura do buffer de protocolo (para desenvolvedores)

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

Ver exemplo 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 solicitação JSON

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

Conferir exemplo de 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 há mudanças na API SearchResponse ao usar esse recurso. A personalização ocorre internamente com base nos atributos de usuário fornecidos.

Requisitos de hash de dados

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

Chaves de hash

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

Exemplo:

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

Valores de hash

Os valores de atributos, como dog e CA, precisam ser criptografados. Não é permitido enviar valores de texto simples.

Exemplo:

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

Hash de chave-valor combinado

Se a chave e o valor forem hash, eles precisam ser hash de forma independente. Não faça hash da string combinada de chave-valor.

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 transmissão de dados

Esta seção descreve várias práticas recomendadas para transmissão de dados, incluindo como lidar com valores repetidos, consistência de dados, flexibilidade de nomenclatura de chaves de atributos e perfis de usuários variados.

Como lidar com valores repetidos

Se um usuário tiver vários valores para um único atributo, como ter um cachorro e um gato, forneça todos os valores em um único key no StringList.

Estes exemplos de código demonstram exemplos de uso incorreto e correto, respectivamente:

Ver exemplo

// 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 exemplo

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

Consistência de dados

Mantenha uma consistência estrita na ortografia, no espaçamento e no uso de letras maiúsculas e minúsculas de todas as chaves e valores. O sistema interpreta até mesmo pequenas variações como categorias distintas.

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

Flexibilidade na nomenclatura de chaves de atributo

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

Como lidar com perfis de usuário variados

É aceitável que usuários diferentes tenham conjuntos de atributos diferentes.

  • Exemplo: o usuário A pode ter age:30-39 e pet:dog, enquanto o usuário B tem gender:male, mas não tem dados de idade ou animais de estimação. O sistema processa perfis parciais de maneira adequada.

Atualizações dinâmicas de dados

Os atributos do usuário podem evoluir com o tempo. Você pode atualizar o perfil de um usuário com novas informações assim que elas estiverem disponíveis.

  • Exemplo: um usuário inicialmente identificado com age:30-39 e pet:dog pode ter state:MA adicionado mais tarde se o local dele for adquirido.

Consistência multiplataforma

Procure transmitir atributos de forma consistente para um determinado usuário em todos os pontos de contato, como apps para dispositivos móveis ou sites. Isso garante uma experiência de personalização unificada.

  • Ideal: o usuário A está sempre age:30-39 no app para dispositivos móveis e no site.
  • Subótimo: o usuário A é age:30-39 no app para dispositivos móveis, mas apenas pet:dog no site.

Como lidar com dados ausentes

Se uma informação específica sobre um usuário não estiver disponível, não envie um marcador de posição ou um valor vazio. Basta omitir esse par de chave-valor da solicitação.

  • Exemplo: evite pet:unknown ou pet:.

Acesso a SDKs e bibliotecas

O acesso a essas bibliotecas pode ser encontrado nas seguintes versões e posteriores: