Migliorare Vertex AI Search for commerce con la personalizzazione del CRM

Questa guida all'implementazione dell'API per Vertex AI Search for commerce descrive come utilizzare i dati di Customer Relationship Management (CRM) per personalizzare le esperienze di ricerca in Vertex AI Search for commerce. Integrando gli attributi utente del tuo CRM, puoi offrire risultati di ricerca più pertinenti, migliorando in definitiva il coinvolgimento dei clienti e le conversioni. Questo documento descrive in dettaglio il processo di integrazione di questi attributi utente, incluse le considerazioni sui dati e le specifiche tecniche.

Seleziona i dati per la personalizzazione

L'efficacia della personalizzazione dipende dalla qualità, dalla copertura e dalla pertinenza dei dati CRM che fornisci. Considera quali informazioni su un cliente influenzerebbero davvero i risultati di ricerca che un addetto alle vendite esperto potrebbe offrire.

Suggerimento: chiediti: se un addetto del negozio conoscesse questi dati sul cliente, gli mostrerebbe un prodotto diverso?

Una volta completati i test pilota, avrai consigli più efficaci su quali dati sono (e non sono) significativi.

Categorie di dati consigliate per l'impatto

Queste categorie di dati costituiscono le informazioni più significative sul comportamento degli utenti del tuo sito di e-commerce.

• Informazioni geografiche: la posizione del cliente, ad esempio stato o paese. Le informazioni sul codice postale sono troppo granulari. Per saperne di più, consulta la sezione Granularità eccessiva.
• Dati demografici: caratteristiche principali dei clienti, come età e genere.
  • Conoscere la fascia d'età di un cliente (18-24 anni anziché 55-64 anni) probabilmente suggerirebbe diverse strategie di visualizzazione dei prodotti per articoli come abbigliamento o elettronica. Si tratta di dati di grande impatto.
• Buyer persona: ad esempio, un acquirente attento al budget o parsimonioso, anziché un acquirente che spende molto.

Categorie di dati con meno probabilità di avere un impatto

Queste categorie di dati hanno un impatto marginale sull'acquisizione dei dati di commercio.

• Attributi derivati dalla cronologia acquisti:
  • Il nostro sistema incorpora già il comportamento di acquisto passato per la personalizzazione.
  • L'invio di attributi come user bought a green dress yesterday è ridondante, perché queste informazioni vengono acquisite e utilizzate in modo nativo.
  • Concentrati su nuove informazioni dal tuo CRM.
• Dati specifici sulla risposta di marketing, ad esempio Clicked email #7:
  • Sebbene sia pertinente per l'analisi delle campagne di marketing, non indica all'AI quale risultato di ricerca mostrare.

Completezza dei dati

Oltre alla pertinenza, la completezza dei dati nell'intera base utenti influisce in modo significativo sulla loro utilità per la personalizzazione. Un attributo è più prezioso quando è disponibile per una parte sostanziale dei tuoi utenti, consentendo al sistema di identificare pattern più ampi e applicare la personalizzazione in modo più ampio.

• Molto utile:
  • Attributi che hai per una maggioranza significativa dei tuoi utenti, ad esempio shipping_state:MA, se disponibile per il 70% della tua base utenti.
  • Ciò consente un solido riconoscimento dei pattern e un'applicazione diffusa della personalizzazione.
• Meno utile:
  • Attributi disponibili solo per una piccola parte degli utenti, ad esempio hair_color:blonde se disponibile solo per lo 0,1% della base utenti.

Sebbene interessanti, questi dati sparsi rendono difficile per il sistema ricavare segnali di personalizzazione significativi a causa della mancanza di esempi sufficienti. Dai invece la priorità agli attributi che offrono una copertura più ampia nei profili dei clienti.

Linee guida per la granularità dei dati

Il livello appropriato di granularità dei dati è fondamentale per una personalizzazione efficace. Dati troppo ampi o troppo specifici possono ridurre la capacità del sistema di identificare pattern significativi. Scegli attributi che segmentino la tua base clienti in gruppi su cui è possibile intervenire.

Suggerimento: per una granularità ottimale, scegli attributi che generino da 2 a 50 categorie distinte.

Granularità appropriata

Esempi di granularità appropriata sono i campi per:

• Genere
• Stato
• Città
• Fascia d'età (ad esempio 30-39 anni)

Questo livello di granularità consente la differenziazione per la personalizzazione senza creare un numero ingestibile di categorie.

Granularità insufficiente

Un esempio di granularità insufficiente è country:US se la maggior parte della tua base di clienti risiede negli Stati Uniti. Questo perché un attributo con una varianza minima nella tua base di clienti offre un valore minimo per la personalizzazione.

Granularità eccessiva

Esempi di granularità eccessiva sono:

• Codici postali esatti (zipcode:12345): con decine di migliaia di potenziali codici postali, la maggior parte avrà pochissimi clienti associati. Questa atomizzazione diluisce il segnale. Se utilizzi i codici postali, troncali alle prime due cifre per ottenere un livello di granularità più appropriato. Le prime due cifre dei codici postali sono mappate approssimativamente su aree delle dimensioni di uno stato.
• Età esatte (age:37): in questo modo viene creato un numero eccessivo di categorie di età. Per ridurre il numero, raggruppa i dati numerici come l'età in circa 10 bin o bucket predefiniti (ad esempio age:30-39).

Ulteriori linee guida per i dati

Questa sezione tratta i formati di dati categorici e altri.

Formato dei dati categorici

Questo sistema è ottimizzato per i dati categorici: valori distinti e denominati, ad esempio:

• state:MA
• gender:male

Dati numerici

Punto chiave: il sistema considera tutti i valori (inclusi i numeri) come categorie anziché comprendere intrinsecamente la prossimità o l'ordine numerico. Ad esempio, age:37, age:37.1 e age:37.0 verranno elaborati come tre categorie distinte e non correlate. Il sistema non dedurrà che age:37 e age:38 sono vicini, né che age:37 e age:82 sono distanti.

Per questo motivo, tutti gli attributi numerici come età, reddito o frequenza devono essere raggruppati in bucket significativi prima della trasmissione dei dati.

Di seguito sono riportati esempi errati e corretti, rispettivamente:

• age:37
• age:30-39

Vincoli aggiuntivi per i dati

• Limite attributi: ogni query supporta fino a 100 coppie chiave-valore. Il supporto per altre coppie potrebbe essere aggiunto nelle release future.
• Chiavi duplicate: non sono consentite chiavi duplicate all'interno di una singola query. Tuttavia, sono supportati più valori per chiave.
• PII vietate: in nessun caso devi inviare informazioni personali specifiche, come indirizzi email dei clienti, codici fiscali, nomi e cognomi o dati finanziari, come numeri di carte di credito, in qualsiasi forma.

Integrazione API e trasmissione dei dati

I dati dei clienti devono essere trasmessi all'interno del campo query delle richieste di ricerca, non negli eventi.

Struttura del buffer del protocollo (per gli sviluppatori)

Gli attributi utente sono definiti all'interno del messaggio SearchRequest come mappa di stringhe a un messaggio StringList.

Visualizza l'esempio di 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;
}

Esempio di richiesta JSON

Questo esempio mostra come strutturare user_attributes all'interno di una richiesta di ricerca JSON.

Visualizza esempio 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"
         }
       }
      ]
}

Risposta dell'API

Non vengono apportate modifiche all'API SearchResponse quando si utilizza questa funzionalità. La personalizzazione avviene internamente in base agli attributi utente forniti.

Requisiti per l'hashing dei dati

Per garantire la privacy e la sicurezza dei dati, i valori degli attributi devono essere sottoposti ad hashing. Le chiavi possono essere inviate con o senza hashing.

Chiavi di hashing

Le chiavi degli attributi, come pet_owner e state, possono essere inviate nella loro forma di stringa originale o sottoposte ad hashing. Entrambi sono accettabili.

Ad esempio:

• Accettabile: pet_owner
• Accettabile: hash(pet_owner)

Valori di hashing

I valori degli attributi, ad esempio dog e CA, devono essere sottoposti ad hashing. L'invio di valori di testo normale non è consentito.

Ad esempio:

• Accettabile: hash(dog)
• Non accettabile: "Dog"

Hashing combinato di coppie chiave-valore

Se sia la chiave che il valore devono essere sottoposti ad hashing, devono essere sottoposti ad hashing in modo indipendente. Non eseguire l'hashing della stringa combinata chiave-valore.

Ad esempio:

• Accettabile: pet_owner:hash("dog")
• Accettabile: hash(pet_owner):hash("dog")
• Non accettabile: hash("Pet_owner:dog")

Best practice per la trasmissione dei dati

Questa sezione descrive diverse best practice per la trasmissione dei dati, tra cui la gestione di valori ripetuti, la coerenza dei dati, la flessibilità di denominazione delle chiavi degli attributi e la gestione di profili utente diversi.

Come gestire i valori ripetuti

Se un utente ha più valori per un singolo attributo, ad esempio possiede sia un cane che un gatto, fornisci tutti i valori in un unico key all'interno di StringList.

Questi esempi di codice mostrano esempi di utilizzo errato e corretto, rispettivamente:

Visualizza l'esempio

// 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"
  }
}

Visualizza l'esempio

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

Coerenza dei dati

Mantieni una coerenza rigorosa nell'ortografia, nella spaziatura e nell'uso delle maiuscole di tutte le chiavi e di tutti i valori. Il sistema interpreta anche le variazioni minime come categorie distinte.

Ad esempio, State:MA, state:MA, state:ma, STATE:MA e residence_state:MA verranno trattati come attributi separati e non correlati.

Attenzione:per un determinato attributo deve essere sempre utilizzata la stessa chiave.

Ad esempio:

• Non alternare pets: e pets_owned:.
• Non modificare la spaziatura, la punteggiatura o l'uso delle maiuscole per un determinato attributo chiave o valore dopo che è stato stabilito.

Flessibilità nella denominazione delle chiavi attributo

Sebbene coerente, la convenzione di denominazione specifica per le chiavi degli attributi (ad esempio pet_owner, pets, codeabc) non influisce intrinsecamente sulla capacità del sistema di utilizzare i dati. L'aspetto cruciale è la coerenza dei dati che trasmetti.

Come gestire profili utente diversi

È accettabile che utenti diversi abbiano insiemi di attributi diversi.

• Esempio: l'utente A potrebbe avere age:30-39 e pet:dog, mentre l'utente B ha gender:male, ma nessun dato su animali domestici o età. Il sistema gestisce i profili parziali in modo controllato.

Aggiornamenti dinamici dei dati

Gli attributi utente possono evolvere nel tempo. Puoi aggiornare il profilo di un utente con nuove informazioni man mano che diventano disponibili.

• Esempio: un utente inizialmente identificato con age:30-39 e pet:dog può in seguito avere state:MA aggiunto se viene acquisita la sua posizione.

Coerenza multipiattaforma

Impegnati a trasmettere in modo coerente gli attributi per un determinato utente in tutti i punti di contatto, ad esempio app mobile o sito web. In questo modo si garantisce un'esperienza di personalizzazione unificata.

• Ottimale: l'utente A è costantemente age:30-39 sia nell'app mobile che sul sito web.
• Non ottimale: l'utente A è age:30-39 sull'app mobile, ma solo pet:dog sul sito web.

Come gestire i dati mancanti

Se una specifica informazione su un utente non è disponibile, non inviare un segnaposto o un valore vuoto. Basta omettere la coppia chiave-valore dalla richiesta.

• Esempio: evita pet:unknown o pet:

Accesso a SDK e librerie

L'accesso a queste librerie è disponibile nelle seguenti versioni e successive:

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