Mejora Vertex AI Search for Commerce con la personalización del CRM

En esta guía de implementación de la API de Vertex AI Search for Commerce, se describe cómo usar los datos de tu sistema de administración de relaciones con el cliente (CRM) para personalizar las experiencias de búsqueda en Vertex AI Search for Commerce. Si integras los atributos del usuario de tu CRM, puedes ofrecer resultados de la búsqueda más pertinentes y, en última instancia, mejorar la participación y las conversiones de los clientes. En este documento, se detalla el proceso de integración de estos atributos del usuario, incluidas las consideraciones de datos y las especificaciones técnicas.

Selecciona los 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 proporciones. Considera qué información sobre un cliente influiría realmente en los resultados de la búsqueda que podría ofrecer un asociado de ventas experto.

Nota: Pregúntate: ¿Un empleado de la tienda le mostraría a este usuario un producto diferente si conociera estos datos sobre el cliente?

Cuando completes las pruebas piloto, tendrás recomendaciones más sólidas sobre qué datos son (y no son) importantes.

Categorías de datos recomendadas para el impacto

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

• Información geográfica: Es la ubicación del cliente, como el estado o el país. La información del código postal es demasiado detallada. Consulta la sección sobre Granularidad excesiva para obtener más información.
• Datos demográficos: Son las características principales de los clientes, como la edad y el género.
  • Conocer el grupo etario de un cliente (de 18 a 24 años en lugar de 55 a 64) probablemente proporcionaría información para diferentes estrategias de visualización de productos para artículos como indumentaria o productos electrónicos. Estos son datos muy importantes.
• Arquetipos de clientes: Por ejemplo, un comprador que cuida su presupuesto o es austero, en lugar de un comprador que gasta mucho.

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

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

• Atributos derivados del historial de compras:
  • Nuestro sistema ya incorpora el comportamiento de compra anterior para la personalización.
  • Enviar atributos como user bought a green dress yesterday es redundante, ya que esta información se captura y utiliza de forma nativa.
  • Enfócate en las estadísticas novedosas de tu CRM.
• Datos de respuesta de marketing específicos, como los siguientes: Clicked email #7
  • Si bien es relevante para el análisis de campañas de marketing, no le indica a la IA qué resultado de la búsqueda debe mostrar.

Integridad de los datos

Más allá de la relevancia, la integridad de tus datos en toda tu base de usuarios afecta significativamente su utilidad para la personalización. Un atributo es más valioso cuando está disponible para una parte importante de tus usuarios, lo que permite que el sistema identifique patrones más amplios y aplique la personalización de forma más generalizada.

• Muy útil:
  • Atributos que tienes para 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 fracción de tus usuarios, como hair_color:blonde si está disponible para solo el 0.1% de tu base de usuarios

Si bien son interesantes, estos datos dispersos dificultan que el sistema derive indicadores de personalización significativos debido a la falta de ejemplos suficientes. En su lugar, prioriza los atributos que ofrecen una cobertura más amplia en tus perfiles de clientes.

Lineamientos sobre el nivel de detalle de los datos

El nivel adecuado de detalle de los datos es fundamental para una personalización eficaz. Los datos demasiado generales o demasiado específicos pueden disminuir la capacidad del sistema para identificar patrones significativos. Intenta usar atributos que segmenten tu base de clientes en grupos prácticos.

Sugerencia: Para obtener una granularidad óptima, procura usar atributos que generen entre 2 y 50 categorías distintas.

Nivel de detalle adecuado

Estos son algunos ejemplos de nivel de detalle adecuado:

• Género
• Estado
• Ciudad
• Grupo etario (por ejemplo, de 30 a 39 años)

Este nivel de detalle proporciona diferenciación para la personalización sin crear una cantidad inmanejable de categorías.

Nivel de detalle insuficiente

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

Nivel de detalle excesivo

Estos son algunos ejemplos de granularidad excesiva:

• Códigos postales exactos (zipcode:12345): Con decenas de miles de códigos postales posibles, la mayoría tendrá muy pocos clientes asociados. Esta atomización diluye el indicador. Si usas códigos postales, trúncalos a los dos primeros dígitos para lograr un nivel de detalle más adecuado. Los primeros dos dígitos de los códigos postales se asignan aproximadamente a áreas del tamaño de un estado.
• Edades exactas (age:37): Esto crea una cantidad excesiva de categorías de edad. Para reducir la cantidad, agrupa los datos numéricos, como la edad, en alrededor de 10 discretizaciones o discretizaciones predefinidas (como age:30-39).

Lineamientos adicionales sobre los datos

En esta sección, se abordan 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

Punto clave: El sistema trata todos los valores (incluidos los números) como categorías en lugar de comprender de forma inherente la proximidad o el orden numérico. Por ejemplo, age:37, age:37.1 y age:37.0 se procesarán como tres categorías distintas y no relacionadas. El sistema no inferirá que age:37 y age:38 están cerca, ni comprenderá que age:37 y age:82 están lejos.

Por este motivo, todos los atributos numéricos, como la edad, los ingresos o la frecuencia, deben agruparse en buckets significativos antes de la transmisión de datos.

Estos son ejemplos incorrectos y correctos, respectivamente:

• age:37
• age:30-39

Restricciones de datos adicionales

• Límite de atributos: Cada búsqueda admite hasta 100 pares clave-valor. Es posible que se agregue compatibilidad con más pares en versiones futuras.
• Claves duplicadas: No se permiten claves duplicadas en una sola búsqueda. Sin embargo, se admiten varios valores por clave.
• PII prohibida: Bajo ninguna circunstancia debes enviar información de identificación personal (PII) específica, como direcciones de correo electrónico de clientes, números de seguridad social, nombres completos o datos financieros, como números de tarjetas de crédito, en ninguna forma.

Integración de la API y transmisión de datos

Los datos del cliente se deben transmitir dentro del campo query de tus solicitudes de búsqueda, no en los eventos.

Estructura del búfer de protocolo (para desarrolladores)

Los atributos del usuario se definen dentro del mensaje SearchRequest como un mapa de cadenas a un mensaje StringList.

Ver muestra 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 ilustra cómo estructurar user_attributes dentro de una solicitud de búsqueda en formato JSON.

Ver muestra 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 hay cambios en la API de SearchResponse cuando se usa esta función. La personalización se produce de forma interna en función de los atributos del usuario proporcionados.

Requisitos de hashing de datos

Para garantizar la privacidad y la seguridad de los datos, los valores de los atributos deben tener un hash. Las claves se pueden enviar con o sin codificación hash.

Generación de hash de claves

Las claves de atributos, como pet_owner y state, se pueden enviar en su forma de cadena original o con hash. Ambas son aceptables.

Por ejemplo:

• Aceptable: pet_owner
• Aceptable: hash(pet_owner)

Valores de hash

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

Por ejemplo:

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

Hashing combinado de clave-valor

Si se deben generar hashes tanto para la clave como para el valor, se deben generar hashes de forma independiente. No apliques hash a la cadena combinada de 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, incluido cómo controlar los valores repetidos, la coherencia de los datos, la flexibilidad en la asignación de nombres de claves de atributos y el manejo de perfiles de usuario variados.

Cómo controlar los valores repetidos

Si un usuario tiene varios valores para un solo atributo, como tener un perro y un gato, proporciona todos los valores en un solo key dentro de StringList.

En estas muestras de código, se muestran ejemplos de uso incorrecto y correcto, respectivamente:

Ver muestra

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

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

Coherencia de los datos

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

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

Precaución: Siempre se debe usar la misma clave para un atributo determinado.

Por ejemplo:

• No intercambies pets: y pets_owned:.
• No cambies el espaciado, la puntuación ni el uso de mayúsculas para un atributo de clave o valor determinado después de que se establezca.

Flexibilidad en el nombre de las claves de atributo

Si bien es coherente, la convención de nombres específica para las claves de tus atributos (por ejemplo, pet_owner, pets, codeabc) no afecta de forma inherente la capacidad del sistema para usar los datos. El aspecto crucial es la coherencia de los datos que transmites.

Cómo controlar los diferentes perfiles de usuario

Es aceptable que diferentes usuarios tengan diferentes conjuntos de atributos.

• Ejemplo: El usuario A podría tener age:30-39 y pet:dog, mientras que el usuario B tiene gender:male, pero no datos de mascotas ni de edad. El sistema controla los perfiles parciales de forma correcta.

Actualizaciones dinámicas de datos

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

• Ejemplo: Un usuario que se identificó inicialmente con age:30-39 y pet:dog puede tener state:MA agregado más adelante si se adquiere su ubicación.

Coherencia en varias plataformas

Procura que la transmisión de atributos sea coherente para un usuario determinado en todos los puntos de contacto, como la aplicación para dispositivos móviles o el sitio web. Esto garantiza una experiencia de personalización unificada.

• Óptimo: El usuario A es age:30-39 de forma coherente tanto en la app para dispositivos móviles como en el sitio web.
• Subóptima: El usuario A es age:30-39 en la app para dispositivos móviles, pero solo pet:dog en el sitio web.

Cómo controlar los datos faltantes

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

• Ejemplo: Evita pet:unknown o pet:

Acceso al SDK y a la biblioteca

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

• Java
• Python
• Node.js
• Go
• PHP
• Ruby
• C# .NET