L'attribuzione corretta dei dati, l'identificazione coerente degli utenti e il monitoraggio accurato degli eventi consentono di ottenere risultati affidabili e prestazioni ottimali del modello. I problemi possono causare metriche distorte, confronti distorti e dati di addestramento danneggiati. Questi risultati ostacolano decisioni informate e il miglioramento della ricerca.
Prima di iniziare
Consulta le indicazioni generali per l'esecuzione di esperimenti A/B.
Componenti di test
I controlli A/B iniziali incorporano questi componenti di test:
ID visitatore: obbligatorio per monitorare un visitatore su un dispositivo, indipendentemente dallo stato di accesso. Non deve cambiare, indipendentemente dal fatto che il visitatore acceda o esca. Se l'utente esegue l'accesso tra i percorsi utente, l'ID visitatore rimane costante.
ID sessione: per monitorare la sessione di interazione di un visitatore. Definita come un'aggregazione del comportamento degli utenti in un intervallo di tempo, in genere termina dopo 30 minuti di inattività.
ID utente: identificatore persistente altamente consigliato per un utente che ha eseguito l'accesso (ad esempio un ID cliente) utilizzato su più dispositivi per la personalizzazione. Deve sempre essere un valore sottoposto ad hashing.
Token di attribuzione: un token hash restituito in ogni risposta di ricerca. I token di attribuzione sono univoci, indipendentemente dal fatto che i parametri di ricerca di ricerca corrispondano esattamente.
Descrizione
Questo controllo prevede la verifica che il numero di ID visitatore unico sia suddiviso in modo casuale tra i gruppi di controllo e di test in un esperimento A/B.
L'ID visitatore è un identificatore univoco per un utente su un singolo dispositivo.
Impatto
Una suddivisione non equa degli ID visitatore può storicamente causare errori di misurazione nei test A/B.
Se un braccio dell'esperimento contiene un numero sproporzionato di determinati tipi di visitatori, ad esempio un visitatore bot che invia volumi elevati di traffico di probing, può influire negativamente sulle metriche di quel braccio. Ciò distorce i confronti degli indicatori chiave delle prestazioni e influisce notevolmente sulla misurazione, ma non direttamente sull'addestramento del modello.
Descrizione
Questo controllo garantisce che il numero di ID utente unici, che rappresentano un utente che ha eseguito l'accesso, sia distribuito in modo uniforme tra i gruppi di controllo e di test. L'ID utente deve rimanere coerente su tutti i dispositivi.
Impatto
L'impatto è simile a quello dell'ID visitatore. Se gli utenti che hanno eseguito l'accesso non vengono assegnati in modo casuale alle corsie di test e di controllo, la suddivisione demografica potrebbe essere distorta.
Se, ad esempio, il gruppo sperimentale contiene principalmente nuovi utenti, mentre gli utenti con una spesa elevata rimangono nel gruppo di controllo, le metriche appariranno artificialmente a favore di una parte.
Ciò influisce sul confronto tra misurazione e indicatori chiave di prestazione (KPI).
Descrizione
Questo controllo esamina in modo specifico la distribuzione degli utenti con un numero elevato di transazioni o acquisti ripetuti, spesso identificati dai loro ID visitatore e dalla cronologia degli acquisti, nelle corsie dell'esperimento.
L'obiettivo è garantire che questi utenti con una spesa elevata siano suddivisi in modo uniforme.
Impatto
- Una distribuzione non uniforme degli utenti esperti, che contribuiscono in modo significativo alle entrate, può distorcere notevolmente i confronti dei KPI tra i gruppi dell'esperimento.
- Il debug dei bias basati su informazioni demografiche come le abitudini di spesa può essere complesso.
- Ciò influisce in modo sproporzionato sulle metriche basate sulle entrate, come le entrate per visitatore (RPV) o le entrate per sessione.
- Sottolinea l'impatto sulla precisione della misurazione durante il test A/B.
Descrizione
Questo controllo verifica che il token di attribuzione restituito nella risposta di ricerca sia incluso correttamente nell'evento di ricerca risultante dalla ricerca.
Il token di attribuzione è necessario per consentire a Vertex AI Search for Commerce di collegare gli eventi alla ricerca che li ha generati:
- Questo è in genere pertinente per il traffico pubblicato da Vertex AI Search.
- Questo problema indica anche la possibilità di memorizzazione nella cache delle risposte di ricerca, che peggiorerà il rendimento della ricerca e l'esperienza utente a causa dell'inventario obsoleto e del ranking non aggiornato.
Impatto
L'attribuzione corretta tramite il token è fondamentale per collegare il comportamento degli utenti, inclusi clic e acquisti, a chiamate API di ricerca specifiche. Senza il token, gli eventi di ricerca potrebbero essere utilizzati in modo errato come se provenissero da un altro fornitore di motori di ricerca e gli eventi successivi non possono essere collegati con precisione alla ricerca.
I token di attribuzione mancanti o errati interrompono l'addestramento del modello, perché vengono utilizzati per collegare i dati degli eventi (come le ricerche seguite dagli acquisti) per generare esempi positivi e negativi per addestrare il modello di ranking. Inoltre, impedisce il calcolo accurato delle metriche per ricerca, ad esempio le entrate per ricerca, che sono fondamentali per valutare il rendimento durante gli esperimenti A/B.
Ciò influisce sia sull'addestramento del modello sia sull'analisi della misurazione e del rendimento.
Descrizione
Questo controllo garantisce che l'ID visitatore e l'ID utente utilizzati in una chiamata di richiesta di ricerca all'API Search siano gli stessi ID visitatore e ID utente inclusi nell'evento utente di ricerca successivo (se possibile per gli eventi visualizzazione dettagli, aggiungi al carrello e acquisto completato correlati a questa interazione di ricerca).
- I campi
visitorIdeuserId, rispettivamente, sono identificatori univoci per un utente su un singolo dispositivo. - Una formattazione coerente dell'ID visitatore e dell'ID utilizzo nelle richieste di ricerca e negli eventi utente è necessaria per consentire alla ricerca di identificare correttamente l'attività utente.
- Gli approcci di debug possono comportare l'utilizzo dell'ID visitatore e dell'ID utente per tracciare le interazioni.
Impatto
Una mancata corrispondenza indica potenziali problemi come eventi mancanti o dati danneggiati.
L'ID visitatore e l'ID utente sono fondamentali per l'addestramento del modello Retail Search, in particolare per le funzionalità di personalizzazione. L'attribuzione accurata degli acquisti si basa sull'utilizzo coerente di un ID visitatore e di un ID utente.
Vertex AI Search for commerce utilizza l'ID visitatore per collegare i risultati di ricerca visualizzati da un utente al fatto che lo stesso ID visitatore abbia successivamente acquistato un prodotto mostrato. Viene utilizzato per collegare i dati di ricerca e clic, aggiunta al carrello o acquisto per generare esempi positivi e negativi per l'addestramento del modello di ranking.
Se l'ID visitatore non corrisponde, si verifica un'interruzione in cui gli eventi di acquisto non possono essere attribuiti alla visualizzazione della pagina di ricerca o dei dettagli che li ha preceduti, facendo sembrare che nessuna ricerca abbia un acquisto successivo. Questo non solo interrompe l'addestramento del modello, ma rende anche difficile calcolare le metriche per ricerca, come le entrate per ricerca. Un'altra sfida consiste nel calcolare con precisione gli indicatori chiave di prestazione (KPI) come le entrate per visitatore, il tasso di conversione e il valore medio dell'ordine, che si basano sul collegamento accurato degli eventi utente alle ricerche. Pertanto, questo controllo influisce sia sull'addestramento del modello sia sulla misurazione.
Descrizione
Questo controllo confronta il volume delle richieste di ricerca effettuate all'API Search per una specifica corsia dell'esperimento (in particolare la corsia Google) con il volume degli eventi utente di ricerca registrati per la stessa corsia.
Il numero di eventi di ricerca raccolti dovrebbe corrispondere da vicino al numero di chiamate API di ricerca effettuate.
Impatto
- Una discrepanza significativa indica che gli eventi utente non vengono raccolti o inviati correttamente a Google.
- Ciò può essere causato da problemi di importazione degli eventi (eventi mancanti o incompleti) o da un tagging errato degli eventi utente con l'ID esperimento.
- La raccolta corretta degli eventi utente è essenziale perché le interazioni degli utenti acquisite negli eventi forniscono al modello il feedback necessario per ottimizzare i risultati.
- Se mancano eventi, il modello riceve meno dati per l'addestramento, il che può influire negativamente sulle sue prestazioni.
- L'accuratezza e l'affidabilità delle metriche utilizzate per valutare i test A/B (come il tasso di click-through, il tasso di conversione e le metriche sulle entrate) dipendono interamente dalla completezza e dalla correttezza dei dati sugli eventi utente.
- Gli eventi mancanti impediscono di calcolare con precisione queste metriche, il che porta a un'analisi distorta del rendimento e a risultati inaffidabili del test A/B.
- Una mancata corrispondenza nel conteggio delle query tra chiamate API ed eventi influisce sia sull'addestramento del modello sia sulla misurazione.
Descrizione
Questo controllo verifica che quando un utente applica filtri ai risultati di ricerca (riflessi nella richiesta di ricerca), l'evento utente di ricerca corrispondente, collegato dal token di attribuzione, includa anche le informazioni corrette sui filtri.
Questo controllo prevede la verifica della coerenza per coppie specifiche collegate a token, nonché la verifica della coerenza complessiva dei dati dei filtri presenti negli eventi rispetto alle chiamate API.
Impatto
- L'inclusione di istruzioni di filtro negli eventi di ricerca è necessaria per utilizzare le sfaccettature dinamiche.
- Il modello di ricerca per il settore retail deduce la popolarità delle sfaccettature dai filtri presenti nelle richieste di ricerca, il che è fondamentale per un rendimento ottimale delle sfaccettature dinamiche.
- Se i dati dei filtri sono mancanti o errati negli eventi utente, la capacità del modello di apprendere dalle interazioni utente che coinvolgono i filtri viene compromessa.
- Ciò influisce direttamente sull'addestramento e sull'efficacia di funzionalità come la navigazione dinamica.
- Questo controllo è utile anche per il debug dei problemi relativi a risultati di ricerca, ricerca conversazionale e sfaccettature dinamiche.
- Sebbene l'impatto principale riguardi l'addestramento del modello specificamente per le sfaccettature dinamiche e le funzionalità correlate, influisce anche sulla capacità di eseguire il debug e misurare con precisione il rendimento di queste funzionalità specifiche.
- Influisce sull'addestramento del modello correlato alle sfaccettature dinamiche ed è importante per il debug e l'analisi delle prestazioni (misurazione) delle funzionalità che si basano sui dati dei filtri.
Descrizione
- Questo controllo verifica che i parametri di paginazione (offset) e i criteri di ordinamento (order by) inclusi in una richiesta di ricerca effettuata all'API Search siano rappresentati correttamente nell'evento utente di ricerca corrispondente.
- Questi eventi sono in genere collegati alla richiesta originale tramite il token di attribuzione.
- Il controllo garantisce la coerenza per interazioni specifiche collegate ai token e per i dati complessivi inviati negli eventi.
- Mantenere questa coerenza nei dati sugli eventi è importante per il debug dei percorsi utente che prevedono paginazione o ordinamento e per funzionalità come la ricerca conversazionale e le sfaccettature dinamiche.
Impatto
- Una mancata corrispondenza ostacola la capacità di analizzare con precisione il modo in cui gli utenti interagiscono con i risultati di ricerca in condizioni specifiche di paginazione o ordinamento.
- Ciò influisce sugli sforzi di debug per queste funzionalità e rende difficile valutarne con precisione il rendimento (influendo sulla misurazione di funzionalità come la ricerca conversazionale o il rendimento del faceting dinamico).
- Dati sugli eventi coerenti sono fondamentali per l'addestramento del modello e le incoerenze potrebbero influire indirettamente sugli approfondimenti derivati dall'analisi del comportamento degli utenti in condizioni di visualizzazione variabili.
- La coerenza dei parametri della richiesta e dei valori degli eventi è considerata importante per il rendimento dei modelli di ranking basati sui clic.
- Ciò influisce principalmente sul debug e sulla misurazione di funzionalità specifiche e, in una certa misura, sull'efficacia dell'addestramento del modello legata alla comprensione dell'interazione degli utenti con i risultati paginati o ordinati.
Descrizione
- Questo controllo garantisce che un ID visitatore unico (utilizzato per gli utenti non registrati) rimanga assegnato a un singolo gruppo sperimentale o corsia, ovvero al gruppo di controllo o di test, per tutto il periodo del test A/B.
- È previsto un'assegnazione coerente dei visitatori, a meno che non sia pianificata una modifica come l'aumento graduale del traffico o il rimescolamento esplicito.
- Il rilevamento dei cambi indica che un singolo utente, identificato dal suo ID visitatore, si sposta in modo imprevisto tra i gruppi sperimentali.
- Ciò può derivare da problemi come l'invio errato di eventi, la codifica errata dell'ID esperimento negli eventi, problemi di implementazione frontend o routing del traffico di ricerca configurato in modo errato.
Impatto
- L'assegnazione coerente dei visitatori del sito è fondamentale per un test A/B equo.
- Se un visitatore del sito cambia corsia, i suoi eventi utente (clic, aggiunte al carrello, acquisti) potrebbero essere registrati con ID esperimento diversi, rendendo impossibile attribuire con precisione il suo comportamento complessivo a una singola esperienza. Ciò danneggia i dati utilizzati per il calcolo degli indicatori chiave di prestazione (KPI) per ogni corsia, con conseguenti risultati di misurazione distorti e inaffidabili.
- L'addestramento del modello Retail Search, in particolare per la personalizzazione, si basa fortemente su campi
visitorIdeuserIdcoerenti per collegare le interazioni degli utenti nel tempo e attribuire gli acquisti agli eventi di ricerca precedenti. - Il cambio dell'ID visitatore interrompe questo collegamento, impedendo al modello di apprendere in modo efficace dal percorso di un utente all'interno di un'esperienza di ricerca coerente. Ciò influisce in modo significativo sia sulla misurazione sia sull'addestramento del modello.
Descrizione
- Questo controllo esamina in modo specifico gli eventi utente di ricerca taggati con un ID esperimento appartenente al gruppo di controllo o al traffico di holdout, ma che inaspettatamente contengono un token di attribuzione generato da Google.
- I token di attribuzione vengono restituiti dall'API Retail Search e devono essere inclusi negli eventi utente successivi per il traffico pubblicato da Google.
- Il traffico di controllo utilizza il motore di ricerca esistente e non deve ricevere o inviare token di attribuzione Google.
- Questo problema è correlato al controllo del cambio di ID esperimento, in quanto implica che gli eventi vengono taggati o indirizzati per errore.
- Questo problema potrebbe indicare la possibilità di memorizzazione nella cache delle risposte di ricerca, che peggiorerà il rendimento della ricerca e l'esperienza utente a causa dell'inventario obsoleto e del ranking non aggiornato.
Impatto
- La presenza di un token di attribuzione Google in un evento del gruppo di controllo comporta attribuzioni erroneamente taggate.
- Ciò significa che gli eventi degli utenti che hanno utilizzato la ricerca di controllo (non Google) sono associati in modo errato alla corsia dell'esperimento Google.
- Ciò distorce direttamente il calcolo delle metriche per la corsia Google includendo i dati del gruppo di controllo, distorcendo il rendimento percepito e invalidando la misurazione.
- Dal punto di vista dell'addestramento del modello, il modello utilizza gli eventi utente attribuiti per apprendere dalle interazioni con i risultati di ricerca.
- L'inclusione di eventi attribuiti erroneamente dal gruppo di controllo introduce dati irrilevanti o in conflitto nel set di addestramento, il che potrebbe comportare un peggioramento delle prestazioni del modello.
- Questo controllo influisce sia sulla misurazione che sull'addestramento del modello.
Descrizione
- Questo controllo si concentra sulle chiamate alle richieste di ricerca in entrata all'API Retail Search stessa.
- Cerca le richieste provenienti da ID visitatore o ID esperimento designati per il gruppo di controllo o il traffico di holdout.
- Ciò indica che il traffico destinato al gruppo di controllo o di esclusione viene indirizzato in modo errato all'endpoint API della corsia dell'esperimento Google.
- Questo problema è molto simile al controllo del cambio di ID visitatore, ma viene osservato dal lato della richiesta API anziché solo dal lato dell'evento utente.
Impatto
- Questo risultato indica una configurazione errata fondamentale nel meccanismo di suddivisione e routing del traffico del test A/B.
- I gruppi sperimentali non sono isolati correttamente se il traffico di controllo viene inviato all'API Google.
- In questo modo, la configurazione del test A/B viene invalidata e la correttezza del confronto viene compromessa.
- Influisce direttamente sulla misurazione perché il volume e la composizione del traffico nella corsia Google sono gonfiati dall'inclusione di utenti non intenzionali, il che porta a un calcolo e a un'analisi imprecisi delle metriche.
- Per l'addestramento del modello, anche se i log API stessi non sono i dati di addestramento principali, gli eventi utente successivi generati da questo traffico indirizzato in modo errato, se attribuiti anche in modo errato, introducono rumore e segnali potenzialmente errati nei dati di addestramento.
- Questo problema influisce sia sulla misurazione sia sull'addestramento del modello.
Descrizione
- Questo controllo verifica che gli eventi utente di completamento dell'acquisto registrati per un utente (identificato dal suo ID visitatore o ID utente) siano taggati con il
experimentIdscorretto corrispondente alla corsia del test A/B a cui è stato assegnato, ad esempio il gruppo di controllo o l'esperimento. - Rileva i casi in cui l'evento di acquisto di un utente è associato a una corsia dell'esperimento diversa da quella in cui si trovava quando ha eseguito le azioni di ricerca pertinenti che hanno portato all'acquisto.
- Questo problema è strettamente correlato al mantenimento di un'assegnazione coerente dei visitatori ai gruppi di esperimento e si basa sull'inclusione di experimentIds nell'evento purchase-complete.
Impatto
- L'assegnazione coerente dei visitatori alle corsie dell'esperimento è fondamentale per test A/B accurati.
- Se gli eventi di completamento dell'acquisto vengono taggati per errore con l'ID esperimento errato, verranno attribuiti in modo errato a quella corsia.
- Ciò distorce direttamente le metriche che si basano sui dati di acquisto per corsia, come il tasso di entrate, il tasso di ordini di acquisto, il valore medio dell'ordine e il tasso di conversione.
- L'attribuzione errata rende impossibile confrontare con precisione il rendimento di diversi gruppi sperimentali, il che porta a risultati di misurazione dei test A/B non validi e inaffidabili.
- Dal punto di vista dell'addestramento dei modelli, i modelli di Ricerca Retail, in particolare quelli che ottimizzano il tasso di conversione o le entrate, vengono addestrati collegando le interazioni degli utenti (come la ricerca) agli acquisti successivi per capire quali risultati portano alle conversioni.
- L'attribuzione corretta, che spesso utilizza gli ID visitatore, utente ed esperimento per collegare gli eventi di acquisto alle ricerche, è essenziale per creare questi esempi di addestramento positivi.
- Se gli eventi di acquisto vengono attribuiti erroneamente a causa di ID incoerenti o del cambio di corsia dell'esperimento, i dati di addestramento vengono danneggiati con segnali errati.
- Valido se gli ID esperimento vengono inviati nell'evento di acquisto:come indicato, questo controllo è valido e significativo solo se
experimentIdsvengono implementati e inviati correttamente all'interno degli eventi utente di completamento dell'acquisto.
Descrizione
- Analogamente al controllo dell'evento di acquisto, questo verifica che gli eventi utente di aggiunta al carrello per un determinato ID visitatore siano associati correttamente alla corsia dell'esperimento assegnata all'utente utilizzando il campo ID esperimenti.
- Identifica i casi in cui un evento Aggiungi al carrello è taggato con un ID esperimento per una corsia a cui l'utente non è stato assegnato.
- Questo problema può derivare da un utilizzo incoerente dell'ID visitatore in diversi tipi di eventi o da un tagging
experimentIdserrato.
Impatto
- Gli eventi di aggiunta al carrello taggati per errore portano a un'attribuzione errata di questo comportamento degli utenti alle corsie dell'esperimento.
- Ciò distorce direttamente metriche come il tasso di aggiunta al carrello e il tasso di conversione, soprattutto se il tasso di aggiunta al carrello è considerato un passaggio importante nel funnel di conversione.
- Metriche imprecise compromettono l'affidabilità dei risultati del test A/B e la capacità di misurare correttamente l'impatto dell'esperimento.
- Dal punto di vista dell'addestramento del modello, gli eventi Aggiungi al carrello fungono da importanti indicatori positivi da cui i modelli, in particolare quelli ottimizzati per le entrate, imparano.
- Se questi eventi vengono attribuiti erroneamente alla corsia di esperimento sbagliata a causa di un ID o di un tag
experimentIdsincoerente, il modello riceve segnali di addestramento rumorosi o errati. - Valido se gli ID esperimento vengono inviati nell'evento Aggiungi al carrello: come indicato, questo controllo è valido e significativo solo se
experimentIdssono implementati e inviati correttamente all'interno degli eventi utente Aggiungi al carrello.
Descrizione
- Questo controllo valuta se la distribuzione dell'attività degli utenti, classificata per tipo di dispositivo (ad es. dispositivo mobile, computer, app), è bilanciata nelle corsie di controllo e sperimentazione per ogni tipo di evento utente (Ricerca, Visualizzazione pagina dei dettagli, Aggiunta al carrello, Acquisto).
- L'obiettivo è garantire che la proporzione di utenti che interagiscono con il sito utilizzando dispositivi mobili sia più o meno la stessa nel gruppo di controllo e nel gruppo di test, e lo stesso vale per gli altri tipi di dispositivi.
- Il rilevamento di una distorsione significativa indica un potenziale problema nel meccanismo utilizzato per dividere il traffico o instradare gli eventi in base al tipo di dispositivo.
Impatto
Una distribuzione distorta dei dispositivi significa che i gruppi di controllo e di test non sono demograficamente bilanciati in termini di dispositivi utilizzati, in modo simile al problema della suddivisione demografica.
Il comportamento degli utenti, i pattern di navigazione e i tassi di conversione possono variare in modo significativo a seconda del dispositivo utilizzato. Per questo motivo, una suddivisione non uniforme dei dispositivi tra le corsie dell'esperimento introduce un bias nel confronto del test A/B, portando a una misurazione imprecisa delle metriche aziendali chiave per ogni corsia. Ciò è dovuto anche al fatto che i risultati di un gruppo potrebbero essere influenzati in modo sproporzionato da una percentuale maggiore o minore di utenti di un tipo di dispositivo specifico, il che rende difficile determinare il vero impatto dell'esperimento.
Sebbene il tipo di dispositivo non sia sempre una funzionalità diretta in tutti i modelli, garantire un traffico bilanciato contribuisce a fare in modo che i dati di addestramento, derivati dagli eventi utente all'interno di ogni corsia, riflettano con precisione la distribuzione reale del comportamento degli utenti sui dispositivi. Uno sbilanciamento potrebbe portare indirettamente a dati di addestramento che rappresentano in modo eccessivo o insufficiente il comportamento degli utenti di determinati dispositivi, il che potrebbe portare a un modello non ottimizzato per la base utenti complessiva.
Gli eventi costituiscono la base per il monitoraggio dei KPI e la risoluzione generale dei problemi.
Descrizione
- Questo controllo confronta i dati dei filtri inclusi negli eventi utente di ricerca tra le corsie di controllo e sperimentale per query di ricerca simili.
- Verifica che le informazioni sui filtri vengano acquisite correttamente, in modo coerente e con parità tra le corsie.
- Ciò include il controllo che le opzioni di filtro disponibili (sfaccettature) presentate agli utenti siano uguali o equivalenti, che i valori dei filtri inviati negli eventi corrispondano ai formati previsti o ai dati del catalogo e che l'interfaccia utente/l'esperienza utente per il filtraggio siano comparabili.
- Potrebbe verificarsi una discrepanza se i filtri non vengono acquisiti, vengono acquisiti in modo errato o se l'interfaccia utente/le opzioni di filtraggio sono diverse, il che di solito può essere ricondotto a un problema di configurazione nell'API Catalog o Search.
Impatto
- Le differenze nell'esperienza di filtraggio o nel modo in cui i dati dei filtri vengono acquisiti tra le corsie dell'esperimento possono influire direttamente sul modo in cui gli utenti interagiscono con i risultati di ricerca.
- Se una corsia offre opzioni di filtro migliori o diverse, gli utenti di quella corsia potrebbero perfezionare le ricerche in modo diverso, il che porta a variazioni nel comportamento degli utenti e potrebbe influire su metriche come i tassi di conversione per le ricerche filtrate.
- Ciò introduce un bias variabile nel test A/B, rendendo difficile attribuire le differenze metriche osservate esclusivamente alle differenze di ranking della ricerca principale.
- La mancanza di dati dei filtri acquisiti negli eventi limita anche la possibilità di analizzare le metriche di rendimento suddivise in base all'utilizzo dei filtri, il che influisce sugli approfondimenti sulla misurazione.
- Per l'addestramento del modello, le informazioni sui filtri negli eventi di ricerca sono fondamentali per l'addestramento dei modelli di sfaccettature dinamiche, in quanto il modello apprende la popolarità delle sfaccettature dai segnali di utilizzo dei filtri degli utenti.
- Informazioni precise sull'utilizzo dei filtri negli eventi sono importanti anche per i modelli di riposizionamento basati sui clic. Se i valori dei filtri negli eventi non corrispondono a quelli nelle richieste di ricerca, il rendimento del modello per le query con filtri viene influenzato negativamente.
- Dati dei filtri incoerenti o mancanti negli eventi peggiorano la qualità del modello correlata ai facet dinamici e al ranking per le query filtrate.
Descrizione
- Questo controllo prevede l'esame di un percorso utente di ricerca specifico collegando un evento di ricerca alla relativa richiesta API Search utilizzando
attributionToken. - Il token di attribuzione viene generato da Vertex AI Search for commerce e restituito con ogni richiesta di ricerca.
- Questo controllo confronta in modo specifico il campo
searchQuerynell'evento di ricerca con la stringa di query effettiva inviata nella richiesta iniziale dell'API Search che ha restituito il token di attribuzione. - Se queste stringhe di query non corrispondono nonostante la presenza di un token di attribuzione del collegamento, significa che la searchQuery inviata nell'evento utente non riflette con precisione la query di ricerca originale dell'utente.
Impatto
- Questo problema influisce notevolmente sull'addestramento del modello.
- Vertex AI Search for Commerce utilizza i dati sugli eventi per addestrare i suoi modelli.
- I modelli, in particolare quelli di riordino basati sui clic, apprendono collegando le interazioni degli utenti (come clic, aggiunte al carrello e acquisti) alle richieste di ricerca che hanno generato i risultati.
- Questo collegamento si basa su informazioni accurate all'interno degli eventi, inclusi i campi
searchQueryeattributionToken. - Se il
searchQuerynell'evento non corrisponde alla query effettiva della richiesta dell'API Search, il modello viene addestrato su dati errati, associando il comportamento degli utenti alla query sbagliata. - Ciò può avere un impatto negativo grave sulla qualità dei risultati di ricerca, perché il modello apprende strategie di ranking non ottimali basate su dati delle query errati.
- Sebbene l'impatto principale riguardi la qualità dell'addestramento del modello, ciò può influire indirettamente anche sulla misurazione, in quanto i modelli addestrati su dati errati possono avere un rendimento scarso, portando a risultati del test A/B distorti anche se gli eventi vengono acquisiti.
Descrizione
- Questo controllo è un processo di convalida manuale in cui un tester simula il percorso tipico di un utente che prevede una sequenza di azioni come la ricerca, il clic su un prodotto (evento
detail-page-view), l'aggiunta al carrello e, potenzialmente, l'acquisto. - Annotando l'ID visitatore e i timestamp di queste azioni, il tester recupera gli eventi utente registrati per l'ID visitatore specifico dai log o dalle piattaforme di dati.
- L'obiettivo è verificare una corrispondenza 1:1 tra le azioni osservate dell'utente e gli eventi registrati nel sistema (ad esempio, un'azione di ricerca deve generare un evento di ricerca, un clic o un evento
detail-page-view). - Eventi mancanti, eventi con ID visitatore errati o dati danneggiati all'interno degli eventi (ad esempio ID prodotto o ID esperimento mancanti) indicano problemi nel flusso di eventi.
Impatto
- I problemi identificati da questo controllo influiscono notevolmente sia sulla misurazione che sull'addestramento del modello.
Misurazione
- Eventi utente accurati e completi sono fondamentali per calcolare le metriche aziendali chiave in un test A/B, come la percentuale di clic nella ricerca, il tasso di conversione nella ricerca, il tasso di aggiunta al carrello nella ricerca e le entrate per visitatore.
- Queste metriche si basano sull'attribuzione del comportamento degli utenti (clic, aggiunte al carrello, acquisti) a risultati di ricerca e corsie di esperimento specifici.
- Se gli eventi sono mancanti o danneggiati per un utente, le sue azioni non vengono acquisite completamente, il che comporta un calcolo errato di queste metriche per la corsia dell'esperimento in cui si trovava.
- Ciò introduce distorsioni e rumore, rendendo i risultati del test A/B imprecisi e inaffidabili per il processo decisionale. Ad esempio, gli eventi di acquisto mancanti influiscono direttamente sulle metriche relative al tasso di conversione e all'aumento delle entrate.
Addestramento del modello
- I modelli di Vertex AI Search for Commerce vengono addestrati in modo approfondito sui dati degli eventi utente per apprendere i pattern di comportamento degli utenti e ottimizzare il ranking.
- Gli ID visitatore e utente sono fondamentali per le funzionalità di personalizzazione e per collegare gli eventi per creare esempi di addestramento.
- Gli eventi mancanti o danneggiati fanno sì che il modello perda preziosi segnali di addestramento dalla sequenza di interazioni dell'utente. Ad esempio, gli eventi di acquisto o aggiunta al carrello mancanti impediscono al modello di apprendere quali interazioni con i prodotti hanno generato conversioni.
- Allo stesso modo, gli eventi di visualizzazione della pagina dei dettagli mancanti indicano che il modello non riceve segnali sui clic. Questa riduzione della quantità e della qualità dei dati di addestramento peggiora la capacità di apprendimento del modello, portando a una scarsa qualità dei risultati di ricerca e potenzialmente annullando i vantaggi dell'utilizzo di un motore di ricerca basato sull'ML.
- Anche la mappatura o la formattazione incoerente dell'ID visitatore può interrompere questo processo.
- Gli eventi di acquisto mancanti influiscono sull'addestramento del modello perché il modello non vede mai gli acquisti.