Melhorar a pesquisa de e-commerce com IA usando a personalização do CRM

Este guia de implementação da API para a Pesquisa de e-commerce com IA descreve como usar os dados do seu gerenciamento de relacionamento com o cliente (CRM, na sigla em inglês) para personalizar as experiências de pesquisa na Pesquisa de e-commerce com IA. Ao integrar os atributos do usuário do seu CRM, você pode oferecer resultados de pesquisa mais relevantes, melhorando o engajamento do cliente e a conversão. 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, cobertura e relevância dos dados do CRM que você fornece. Considere quais informações sobre um cliente influenciariam genuinamente os resultados da pesquisa que um vendedor experiente poderia oferecer.

Quando você concluir os testes piloto, terá recomendações mais fortes sobre quais dados são (e não são) impactantes.

Essas categorias de dados constituem as informações mais relevantes para o comportamento do usuário do seu site de e-commerce.

  • Informações geográficas: localização do cliente, como estado ou país. As informações de CEP são muito granulares. Consulte a seção sobre 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 impactantes.
  • Personas do cliente: por exemplo, um comprador consciente do orçamento ou econômico em vez de um grande gastador.

Categorias de dados com menor probabilidade de serem impactantes

Essas categorias de dados têm um impacto marginal na captura de dados de e-commerce.

  • Atributos derivados do histórico de compras:
    • Nosso sistema já incorpora o comportamento de compras anteriores para personalização.
    • O envio de atributos como user bought a green dress yesterday é redundante, porque essas informações são capturadas e usadas nativamente.
    • Concentre-se em novos insights 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, ele não informa à IA qual resultado de 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 personalização. Um atributo é mais valioso quando está disponível para uma parte substancial dos usuários, permitindo que o sistema identifique padrões mais amplos e aplique a personalização de forma mais ampla.

  • 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 o reconhecimento de padrões robustos e a aplicação generalizada da personalização.
  • Menos útil:
    • Atributos disponíveis apenas para uma pequena fração dos seus usuários, como hair_color:blonde, se disponível para apenas 0,1% da sua base de usuários.

Embora 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 de dados é fundamental para uma personalização eficaz. Dados muito amplos 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 acionáveis.

Granularidade adequada

Exemplos de granularidade adequada são campos para:

  • Gênero
  • Estado
  • Cidade
  • Faixa etária (como 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 residir nos Estados Unidos. Isso ocorre porque um atributo que tem pouca variação na base de clientes oferece valor mínimo para personalização.

Granularidade excessiva

Exemplos de granularidade excessiva são:

  • CEPs ou códigos postais exatos (zipcode:12345): com dezenas de milhares de códigos postais em potencial, a maioria terá muito poucos clientes associados. Essa atomização dilui o sinal. Se você usar códigos postais, corte-os para os dois primeiros dígitos para alcançar um nível mais adequado de granularidade. 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 cerca de 10 agrupamentos ou buckets predefinidos (como age:30-39).

Outras diretrizes de 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 esse motivo, todos os atributos numéricos, como idade, renda ou frequência, precisam ser agrupados em buckets 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 oferece suporte a 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, vários valores por chave são aceitos.
  • PII proibidas: em nenhuma circunstância envie informações de identificação pessoal (PII) específicas, como endereços de e-mail de clientes, números de 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 suas 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.

Ver 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 do usuário fornecidos.

Requisitos de hash de dados

Para garantir a privacidade de dados e a segurança, os valores do atributo precisam ser codificados com 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 no formato 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 atributo, como dog e CA, precisam ser codificados com hash. 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 codificados com hash, eles precisam ser codificados de forma independente. Não codifique a string de chave-valor combinada.

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 como lidar com perfis de usuários variados.

Como lidar com valores repetidos

Se um usuário tiver vários valores para um único atributo, como possuir um cachorro e um gato, forneça todos os valores em uma única key na 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 a consistência estrita na ortografia, espaçamento e capitalização 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 de nomenclatura de chaves de atributos

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 transmitidos.

Como lidar com perfis de usuários 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 animal de estimação. O sistema processa perfis parciais normalmente.

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 à medida que elas ficam disponíveis.

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

Consistência multiplataforma

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

  • Ideal: o usuário A é consistentemente age:30-39 no app para dispositivos móveis e no site.
  • Não ideal: 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 ao SDK e à biblioteca

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