Mejorar Vertex AI Search for commerce con la personalización de CRM

En esta guía de implementación de la API de Vertex AI Search for commerce se explica cómo usar los datos de gestión de relaciones con los clientes (CRM) para personalizar las experiencias de búsqueda en Vertex AI Search for commerce. Al integrar atributos de usuario de tu CRM, puedes ofrecer resultados de búsqueda más relevantes, lo que mejora la interacción con los clientes y las conversiones. En este documento se detalla el proceso de integración de estos atributos de usuario, incluidas las consideraciones sobre los datos y las especificaciones técnicas.

Seleccionar datos para la personalización

La eficacia de la personalización depende de la calidad, la cobertura y la relevancia de los datos del CRM que proporcione. Piensa en qué información sobre un cliente influiría realmente en los resultados de búsqueda que podría ofrecer un vendedor experto.

Cuando hayas completado las pruebas piloto, tendrás recomendaciones más sólidas sobre qué datos son (o no) relevantes.

Estas categorías de datos constituyen la información más reveladora sobre el comportamiento de los usuarios de su sitio de comercio.

  • Información geográfica: ubicación del cliente, como el estado o el país. La información del código postal es demasiado específica. Para obtener más información, consulta la sección sobre granulidad excesiva.
  • Datos demográficos: características principales de los clientes, como la edad y el sexo.
    • Conocer el grupo de edad de un cliente (por ejemplo, si tiene entre 18 y 24 años o entre 55 y 64) probablemente le permita adaptar las estrategias de visualización de productos como ropa o dispositivos electrónicos. Se trata de datos muy importantes.
  • Perfiles de clientes: por ejemplo, un comprador que tiene un presupuesto limitado o que es ahorrador, en contraposición a un comprador que gasta mucho.

Categorías de datos con menos probabilidades de tener un impacto

Estas categorías de datos tienen un impacto marginal en la recogida de datos de comercio.

  • Atributos derivados del historial de compras:
    • Nuestro sistema ya incorpora el historial de compras para la personalización.
    • Enviar atributos como user bought a green dress yesterday es redundante, ya que esta información se recoge y se utiliza de forma nativa.
    • Céntrate en las estadísticas novedosas de tu CRM.
  • Datos de respuesta de marketing específicos, como los siguientes:Clicked email #7
    • Aunque es útil para analizar las campañas de marketing, no indica a la IA qué resultado de búsqueda debe mostrar.

Integridad de los datos

Además de la relevancia, la integridad de los datos de toda su base de usuarios influye significativamente en su utilidad para la personalización. Un atributo es más valioso cuando está disponible para una parte importante de sus usuarios, lo que permite al sistema identificar patrones más amplios y aplicar la personalización de forma más generalizada.

  • Muy útil:
    • Atributos que tengas de una mayoría significativa de tus usuarios, como shipping_state:MA, si está disponible para el 70% de tu base de usuarios.
    • Esto permite un reconocimiento de patrones sólido y una aplicación generalizada de la personalización.
  • Menos útil:
    • Atributos disponibles solo para una pequeña parte de tus usuarios, como hair_color:blonde, si solo está disponible para el 0,1% de tu base de usuarios.

Aunque son interesantes, estos datos dispersos dificultan que el sistema obtenga señales de personalización significativas debido a la falta de ejemplos suficientes. En su lugar, prioriza los atributos que ofrezcan una cobertura más amplia en tus perfiles de cliente.

Directrices sobre la granularidad de los datos

El nivel de granularidad de los datos adecuado es fundamental para ofrecer una personalización eficaz. Los datos demasiado generales o específicos pueden reducir la capacidad del sistema para identificar patrones significativos. Intenta usar atributos que segmenten tu base de clientes en grupos a los que puedas dirigir acciones.

Granularidad adecuada

Estos son algunos ejemplos de granularidad adecuada:

  • Sexo
  • Estado
  • Ciudad
  • Grupo de edad (por ejemplo, de 30 a 39 años)

Este nivel de granularidad permite diferenciar la personalización sin crear un número inabarcable de categorías.

Granularidad insuficiente

Un ejemplo de granularidad insuficiente es country:US si la gran mayoría de su base de clientes reside en Estados Unidos. Esto se debe a que un atributo que tiene poca varianza en toda su base de clientes ofrece un valor mínimo para la personalización.

Granularidad excesiva

Ejemplos de granularidad excesiva:

  • Códigos postales exactos (zipcode:12345): como hay decenas de miles de códigos postales posibles, la mayoría tendrá muy pocos clientes asociados. Esta atomización diluye la señal. Si usa códigos postales, trúnquelos a los dos primeros dígitos para conseguir un nivel de granularidad más adecuado. Los dos primeros dígitos de los códigos postales se asignan aproximadamente a zonas del tamaño de un estado.
  • Edades exactas (age:37): se crean demasiadas categorías de edad. Para reducir el número, agrupa los datos numéricos, como la edad, en unos 10 contenedores predefinidos (por ejemplo, age:30-39).

Directrices de datos adicionales

En esta sección se tratan los formatos de datos categóricos y otros.

Formato de datos categóricos

Este sistema está optimizado para datos categóricos: valores distintos con nombre, como los siguientes:

  • state:MA
  • gender:male

Datos numéricos

Por este motivo, los atributos numéricos, como la edad, los ingresos o la frecuencia, deben agruparse en contenedores significativos antes de transmitir los datos.

Estos son ejemplos incorrectos y correctos, respectivamente:

  • age:37
  • age:30-39

Restricciones de datos adicionales

  • Límite de atributos: cada consulta admite hasta 100 pares clave-valor. Es posible que se añadan más pares en futuras versiones.
  • Claves duplicadas: no se permiten claves duplicadas en una misma consulta. Sin embargo, se admiten varios valores por clave.
  • IPI prohibida: bajo ninguna circunstancia debe enviar información personal identificable (IPI) específica, como direcciones de correo electrónico de clientes, números de la Seguridad Social, nombres completos o datos financieros, como números de tarjetas de crédito, de ninguna forma.

Integración de APIs y transmisión de datos

Los datos de los clientes deben transmitirse en el campo query de las solicitudes de búsqueda, no en los eventos.

Estructura de búfer de protocolo (para desarrolladores)

Los atributos de usuario se definen en el mensaje SearchRequest como una asignación de cadenas a un mensaje StringList.

Ver ejemplo 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;
}

Ejemplo de solicitud JSON

En este ejemplo se muestra cómo estructurar user_attributes en una solicitud de búsqueda JSON.

Ver ejemplo 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"
         }
       }
      ]
}

Respuesta de la API

No se ha hecho ningún cambio en la API SearchResponse al utilizar esta función. La personalización se produce internamente en función de los atributos de usuario proporcionados.

Requisitos de cifrado con hash de datos

Para garantizar la privacidad y la seguridad de los datos, los valores de los atributos deben cifrarse con hash. Las claves se pueden enviar cifradas con hash o sin cifrar.

Claves de cifrado con hash

Las claves de atributo, como pet_owner y state, se pueden enviar en su formato de cadena original o cifradas con hash. Ambos son aceptables.

Por ejemplo:

  • Aceptable: pet_owner
  • Aceptable: hash(pet_owner)

Cifrado con hash de valores

Los valores de los atributos, como dog y CA, deben cifrarse con hash. No se permite enviar valores de texto sin formato.

Por ejemplo:

  • Aceptable: hash(dog)
  • No aceptable — "Dog"

Combinación de hash de pares clave-valor

Si se van a cifrar tanto la clave como el valor, deben cifrarse por separado. No apliques el hash a la cadena combinada de pares clave-valor.

Por ejemplo:

  • Aceptable: pet_owner:hash("dog")
  • Aceptable: hash(pet_owner):hash("dog")
  • No aceptable — hash("Pet_owner:dog")

Prácticas recomendadas para la transmisión de datos

En esta sección se describen varias prácticas recomendadas para la transmisión de datos, como la forma de gestionar los valores repetidos, la coherencia de los datos, la flexibilidad de los nombres de las claves de atributos y la gestión de perfiles de usuario variados.

Cómo gestionar valores repetidos

Si un usuario tiene varios valores para un mismo atributo (por ejemplo, tiene un perro y un gato), proporcione todos los valores en un solo key dentro del StringList.

Estos ejemplos de código muestran ejemplos de uso incorrecto y correcto, respectivamente:

Ver ejemplo

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

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

Coherencia de datos

Mantén una coherencia estricta en la ortografía, los espacios y el uso de las mayúsculas de todas las claves y valores. El sistema interpreta incluso las variaciones más pequeñas como categorías distintas.

Por ejemplo, State:MA, state:MA, state:ma, STATE:MA y residence_state:MA se tratarán como atributos independientes y no relacionados.

Flexibilidad en la nomenclatura de las claves de atributo

Aunque sea coherente, la convención de nomenclatura específica de las claves de atributo (por ejemplo, pet_owner, pets y codeabc) no influye en la capacidad del sistema para usar los datos. Lo fundamental es la coherencia de los datos que transmites.

Cómo gestionar perfiles de usuario variados

Es aceptable que diferentes usuarios tengan conjuntos de atributos distintos.

  • Ejemplo: El usuario A puede tener age:30-39 y pet:dog, mientras que el usuario B tiene gender:male, pero no datos sobre mascotas ni edad. El sistema gestiona los perfiles parciales correctamente.

Actualizaciones de datos dinámicas

Los atributos de usuario pueden cambiar con el tiempo. Puedes actualizar el perfil de un usuario con nueva información a medida que esté disponible.

  • Ejemplo: Un usuario que se identifica inicialmente con age:30-39 y pet:dog puede añadir state:MA más adelante si se obtiene su ubicación.

Coherencia multiplataforma

Procure que la transmisión de atributos sea coherente para un usuario determinado en todos los puntos de contacto, como una aplicación móvil o un sitio web. De esta forma, se ofrece una experiencia de personalización unificada.

  • Óptimo: el usuario A tiene un comportamiento age:30-39 constante tanto en la aplicación móvil como en el sitio web.
  • Subóptimo: el usuario A tiene age:30-39 en la aplicación móvil, pero solo pet:dog en el sitio web.

Cómo gestionar los datos que faltan

Si no tienes disponible un dato específico sobre un usuario, no envíes un marcador de posición ni un valor vacío. Solo tienes que omitir ese par clave-valor de la solicitud.

  • Ejemplo: evita pet:unknown o pet:.

Acceso a SDKs y bibliotecas

Puedes acceder a estas bibliotecas en las siguientes versiones y posteriores: