Une attribution des données appropriée, une identification cohérente des utilisateurs et un suivi précis des événements permettent d'obtenir des résultats fiables et des performances de modèle optimales. Les problèmes peuvent entraîner des métriques biaisées, des comparaisons faussées et des données d'entraînement corrompues. Ces résultats entravent la prise de décisions éclairées et l'amélioration de la recherche.
Avant de commencer
Consultez les conseils généraux pour effectuer des tests A/B.
Composants de test
Les vérifications A/B de base intègrent les composants de test suivants :
ID de visiteur : obligatoire pour suivre un visiteur sur un appareil, quel que soit son état de connexion. Elle ne doit pas changer, que le visiteur se connecte ou se déconnecte. Si l'utilisateur se connecte entre deux parcours utilisateur, l'ID de visiteur reste constant.
ID de session : pour suivre la session d'interaction d'un visiteur. Il s'agit d'une agrégation du comportement des utilisateurs sur une période donnée, qui se termine généralement après 30 minutes d'inactivité.
User-ID : identifiant persistant fortement recommandé pour un utilisateur connecté (comme un numéro client), utilisé sur plusieurs appareils pour la personnalisation. Il doit toujours s'agir d'une valeur hachée.
Jeton d'attribution : jeton de hachage renvoyé dans chaque réponse de recherche. Les jetons d'attribution sont uniques, que les paramètres de requête de recherche correspondent exactement ou non.
Description
Cette vérification consiste à s'assurer que le nombre d'ID de visiteurs uniques est réparti de manière aléatoire entre les groupes de contrôle et de test dans un test A/B.
L'ID de visiteur est un identifiant unique pour un utilisateur sur un seul appareil.
Impact
Une répartition injuste des ID de visiteurs peut historiquement entraîner des erreurs de mesure dans les tests A/B.
Si un bras de test contient un nombre disproportionné de certains types de visiteurs, comme un robot qui envoie de gros volumes de trafic d'exploration, cela peut avoir un impact négatif sur les métriques de ce bras. Cela fausse les comparaisons des indicateurs clés de performance et affecte fortement les mesures, mais pas directement l'entraînement du modèle.
Description
Cette vérification permet de s'assurer que le nombre d'ID utilisateur uniques, qui représentent un utilisateur connecté, est réparti de manière égale entre les groupes de contrôle et de test. L'ID utilisateur doit rester le même sur tous les appareils.
Impact
L'impact est semblable à celui de l'ID de visiteur. Si les utilisateurs connectés ne sont pas répartis de manière aléatoire entre les groupes test et de contrôle, cela peut entraîner une répartition démographique biaisée.
Par exemple, si le groupe expérimental contient principalement de nouveaux utilisateurs, tandis que les gros dépensiers restent dans le groupe de contrôle, les métriques sembleront artificiellement favorables à l'un des groupes.
Cela affecte les comparaisons de mesures et d'indicateurs clés de performance (KPI).
Description
Cette vérification examine spécifiquement la répartition des utilisateurs ayant effectué un nombre élevé de transactions ou des achats répétés (souvent identifiés par leur ID de visiteur et leur historique d'achats) dans les différents bras du test.
L'objectif est de s'assurer que ces utilisateurs à fort pouvoir d'achat sont répartis de manière égale.
Impact
- Une répartition inégale des utilisateurs avancés, qui contribuent de manière significative aux revenus, peut fortement fausser les comparaisons de KPI entre les groupes de test.
- Il peut être difficile de déboguer les biais basés sur des informations démographiques telles que les habitudes de dépenses.
- Cela affecte de manière disproportionnée les métriques basées sur les revenus, comme les revenus par visiteur (RPV) ou les revenus par session.
- Mettez l'accent sur l'impact sur la précision des mesures lors des tests A/B.
Description
Cette vérification permet de s'assurer que le jeton d'attribution renvoyé dans la réponse de recherche est correctement inclus dans l'événement de recherche résultant de cette recherche.
Le jeton d'attribution est nécessaire pour que Vertex AI Search for Commerce puisse associer les événements à la recherche qui les a générés :
- Cela concerne généralement le trafic diffusé par Vertex AI Search.
- Ce problème indique également la possibilité de mise en cache des réponses de recherche, ce qui dégradera les performances de recherche et l'expérience utilisateur en raison d'un inventaire obsolète et d'un classement dépassé.
Impact
Une attribution appropriée à l'aide du jeton est essentielle pour associer le comportement des utilisateurs, y compris les clics et les achats, à des appels spécifiques de l'API Search. Sans le jeton, les événements de recherche peuvent être utilisés de manière incorrecte comme s'ils provenaient d'un autre fournisseur de recherche, et les événements ultérieurs ne peuvent pas être associés précisément à la recherche.
Des jetons d'attribution inexacts ou manquants perturbent l'entraînement du modèle, car ils sont utilisés pour associer les données d'événement (comme les recherches suivies d'achats) afin de générer des exemples positifs et négatifs pour entraîner le modèle de classement. Cela empêche également le calcul précis des métriques par recherche, telles que le revenu par recherche, qui sont essentielles pour évaluer les performances lors des tests A/B.
Cela affecte à la fois l'entraînement du modèle, la mesure et l'analyse des performances.
Description
Cette vérification permet de s'assurer que l'ID de visiteur et l'ID utilisateur utilisés dans un appel de requête de recherche à l'API Search sont les mêmes que ceux inclus dans l'événement utilisateur de recherche suivant (si possible, pour les événements "vue de la page détaillée", "ajout au panier" et "achat effectué" liés à cette interaction de recherche).
- Les champs
visitorIdetuserIdsont des identifiants uniques pour un utilisateur sur un seul appareil. - Il est nécessaire de mettre en forme de manière cohérente l'ID de visiteur et d'utilisateur dans les requêtes de recherche et les événements utilisateur pour que la recherche puisse identifier correctement l'activité des utilisateurs.
- Les approches de débogage peuvent impliquer l'utilisation de l'ID de visiteur et de l'ID utilisateur pour suivre les interactions.
Impact
Un écart indique des problèmes potentiels, comme des événements manquants ou des données corrompues.
L'ID de visiteur et l'ID utilisateur sont essentiels pour l'entraînement des modèles de recherche Retail, en particulier pour les fonctionnalités de personnalisation. Pour que l'attribution des achats soit précise, vous devez utiliser un ID visiteur et un ID utilisateur de manière cohérente.
Vertex AI Search for Commerce utilise l'ID de visiteur pour associer les résultats de recherche vus par un utilisateur à l'achat ultérieur ou non du produit affiché par ce même ID de visiteur. Il est utilisé pour associer les données de recherche à celles de clics, d'ajouts au panier ou d'achats afin de générer des exemples positifs et négatifs pour entraîner le modèle de classement.
Si l'ID de visiteur ne correspond pas, cela entraîne une rupture de l'attribution. Les événements d'achat ne peuvent alors pas être attribués à la recherche ou à la vue de la page d'informations qui les ont précédés. Il semble alors qu'aucune recherche n'a été suivie d'un achat. Cela perturbe non seulement l'entraînement du modèle, mais rend également difficile le calcul des métriques par recherche, comme le revenu par recherche. Un autre défi consiste à calculer précisément les indicateurs clés de performance (KPI), tels que le revenu par visiteur, le taux de conversion et la valeur moyenne des commandes, qui dépendent d'une association précise des événements utilisateur aux recherches. Cette vérification affecte donc à la fois l'entraînement et la mesure du modèle.
Description
Cette vérification compare le volume de requêtes de recherche envoyées à l'API Search pour un canal de test spécifique (en particulier le canal Google) avec le volume d'événements utilisateur de recherche enregistrés pour ce même canal.
Le nombre d'événements de recherche collectés doit correspondre étroitement au nombre d'appels de l'API Search effectués.
Impact
- Un écart important indique que les événements utilisateur ne sont pas collectés ni envoyés correctement à Google.
- Cela peut être dû à des problèmes d'ingestion d'événements (événements manquants ou incomplets) ou à un taggage incorrect des événements utilisateur avec l'ID de l'expérience.
- Il est essentiel de collecter correctement les événements utilisateur, car les interactions utilisateur capturées dans les événements fournissent au modèle les commentaires nécessaires pour optimiser les résultats.
- Si des événements sont manquants, le modèle reçoit moins de données pour l'entraînement, ce qui peut avoir un impact négatif sur ses performances.
- La précision et la fiabilité des métriques utilisées pour évaluer les tests A/B (comme le taux de clics, le taux de conversion et les métriques sur les revenus) dépendent entièrement de l'exhaustivité et de l'exactitude des données sur les événements utilisateur.
- Si des événements sont manquants, ces métriques ne peuvent pas être calculées avec précision, ce qui fausse l'analyse des performances et rend les résultats des tests A/B peu fiables.
- Une incohérence dans le nombre de requêtes entre les appels d'API et les événements affecte à la fois l'entraînement et la mesure du modèle.
Description
Cette vérification permet de s'assurer que lorsqu'un utilisateur applique des filtres aux résultats de recherche (reflétés dans la requête de recherche), l'événement utilisateur de recherche correspondant, associé au jeton d'attribution, inclut également les informations de filtrage correctes.
Cette vérification consiste à vérifier la cohérence de paires spécifiques associées à des jetons, ainsi que la cohérence globale des données de filtre présentes dans les événements par rapport aux appels d'API.
Impact
- Pour utiliser des facettes dynamiques, vous devez inclure des instructions de filtre dans les événements de recherche.
- Le modèle Retail Search déduit la popularité des facettes à partir des filtres présents dans les demandes de recherche, ce qui est essentiel pour optimiser les performances des facettes dynamiques.
- Si les données de filtrage sont manquantes ou incorrectes dans les événements utilisateur, la capacité du modèle à apprendre des interactions utilisateur impliquant des filtres est altérée.
- Cela a un impact direct sur l'entraînement et l'efficacité de fonctionnalités telles que le facettage dynamique.
- Cette vérification est également utile pour déboguer les problèmes liés aux résultats de recherche, à la recherche conversationnelle et aux facettes dynamiques.
- L'impact principal concerne l'entraînement des modèles, en particulier pour les facettes dynamiques et les fonctionnalités associées. Toutefois, il affecte également la capacité à déboguer et à mesurer précisément les performances de ces fonctionnalités spécifiques.
- Affecte l'entraînement du modèle lié aux facettes dynamiques et est important pour le débogage et l'analyse des performances (mesure) des fonctionnalités reposant sur les données de filtrage.
Description
- Cette vérification permet de s'assurer que les paramètres de pagination (décalage) et les critères de tri (trier par) inclus dans une requête de recherche envoyée à l'API Search sont correctement représentés dans l'événement utilisateur de recherche correspondant.
- Ces événements sont généralement associés à la demande d'origine à l'aide du jeton d'attribution.
- Cette vérification garantit la cohérence des interactions spécifiques associées aux jetons et des données globales envoyées dans les événements.
- Il est important de maintenir cette cohérence dans les données d'événement pour déboguer les parcours utilisateur impliquant une pagination ou un tri, ainsi que pour les fonctionnalités telles que la recherche conversationnelle et les facettes dynamiques.
Impact
- Une incohérence empêche d'analyser précisément la façon dont les utilisateurs interagissent avec les résultats de recherche dans des conditions de pagination ou de tri spécifiques.
- Cela a un impact sur les efforts de débogage de ces fonctionnalités et rend difficile l'évaluation précise de leurs performances (affectant la mesure des performances de fonctionnalités telles que la recherche conversationnelle ou le facettage dynamique).
- Des données d'événement cohérentes sont essentielles pour l'entraînement des modèles. Les incohérences peuvent affecter indirectement les insights obtenus à partir de l'analyse du comportement des utilisateurs dans différentes conditions d'affichage.
- La cohérence des paramètres de requête et des valeurs d'événement est considérée comme importante pour les performances des modèles de reranking basés sur les clics.
- Cela affecte principalement le débogage et la mesure de fonctionnalités spécifiques, ainsi que, dans une certaine mesure, l'efficacité de l'entraînement du modèle liée à la compréhension de l'interaction des utilisateurs avec les résultats paginés ou triés.
Description
- Cette vérification permet de s'assurer qu'un ID de visiteur unique (utilisé pour les utilisateurs non connectés) reste attribué à un seul groupe de test ou à une seule voie (c'est-à-dire au groupe de contrôle ou de test) pendant toute la durée du test A/B.
- Une attribution cohérente des visiteurs est attendue, sauf en cas de changement planifié, comme une augmentation progressive du trafic ou un remaniement explicite.
- La détection de changements signifie qu'un même utilisateur, identifié par son ID de visiteur, passe de manière inattendue d'un groupe de test à un autre.
- Cela peut être dû à des problèmes tels qu'un envoi d'événements incorrect, un taggage incorrect de l'ID de l'expérience dans les événements, des problèmes d'implémentation du frontend ou un routage du trafic de recherche mal configuré.
Impact
- Il est essentiel d'attribuer les visiteurs de manière cohérente pour que le test A/B soit équitable.
- Si un visiteur du site change de voie, ses événements utilisateur (clics, ajouts au panier, achats) peuvent être enregistrés sous différents ID d'expérience, ce qui rend impossible d'attribuer précisément son comportement global à une seule expérience. Cela corrompt les données utilisées pour calculer les indicateurs clés de performance (KPI) pour chaque voie, ce qui entraîne des résultats de mesure faussés et peu fiables.
- L'entraînement du modèle Retail Search, en particulier pour la personnalisation, repose fortement sur des champs
visitorIdetuserIdcohérents pour associer les interactions des utilisateurs au fil du temps et attribuer les achats aux événements de recherche précédents. - Le changement d'ID de visiteur rompt ce lien, ce qui empêche le modèle d'apprendre efficacement à partir du parcours d'un utilisateur dans une expérience de recherche cohérente. Cela affecte considérablement la mesure et l'entraînement du modèle.
Description
- Cette vérification examine spécifiquement les événements utilisateur de recherche tagués avec un ID de test appartenant au groupe de contrôle ou au trafic de validation, mais qui contiennent de manière inattendue un jeton d'attribution généré par Google.
- Les jetons d'attribution sont renvoyés par l'API Retail Search et sont destinés à être inclus dans les événements utilisateur ultérieurs pour le trafic diffusé par Google.
- Le trafic de contrôle utilise le moteur de recherche existant et ne doit pas recevoir ni envoyer de jetons d'attribution Google.
- Ce problème est lié à la vérification du changement d'ID de l'expérience, car il implique que des événements sont tagués ou routés par erreur.
- Ce problème peut indiquer une mise en cache des réponses de recherche, ce qui dégrade les performances de recherche et l'expérience utilisateur en raison d'un inventaire obsolète et d'un classement dépassé.
Impact
- La présence d'un jeton d'attribution Google dans un événement de groupe de contrôle entraîne des attributions taguées par erreur.
- Cela signifie que les événements des utilisateurs qui ont effectué une recherche de contrôle (non Google) sont associés à tort au canal de test Google.
- Cela fausse directement le calcul des métriques pour le canal Google en incluant les données du groupe de contrôle, ce qui déforme les performances perçues et invalide la mesure.
- Du point de vue de l'entraînement du modèle, celui-ci utilise les événements utilisateur attribués pour apprendre des interactions avec les résultats de recherche.
- L'inclusion d'événements attribués à tort au groupe de contrôle introduit des données non pertinentes ou contradictoires dans l'ensemble d'entraînement, ce qui peut entraîner une dégradation des performances du modèle.
- Cette vérification affecte à la fois la mesure et l'entraînement du modèle.
Description
- Cette vérification se concentre sur les appels de requêtes de recherche entrantes vers l'API Retail Search elle-même.
- Il recherche les requêtes provenant d'ID de visiteurs ou d'ID de tests désignés pour le groupe de contrôle ou le trafic de validation.
- Cela indique que le trafic destiné au groupe de contrôle ou de validation est redirigé de manière incorrecte vers le point de terminaison de l'API du canal d'expérimentation Google.
- Ce problème est très semblable à la vérification du changement d'ID de visiteur, mais il est observé du côté de la requête API plutôt que du côté de l'événement utilisateur uniquement.
Impact
- Ce résultat indique une erreur de configuration fondamentale dans le mécanisme de répartition et de routage du trafic du test A/B.
- Les bras de test ne sont pas correctement isolés si le trafic de contrôle est envoyé à l'API Google.
- Cela invalide la configuration du test A/B et compromet l'équité de la comparaison.
- Cela a un impact direct sur la mesure, car le volume et la composition du trafic dans le canal Google sont gonflés par l'inclusion d'utilisateurs non souhaités, ce qui entraîne un calcul et une analyse inexacts des métriques.
- Pour l'entraînement des modèles, bien que les journaux d'API eux-mêmes ne soient pas les données d'entraînement principales, les événements utilisateur ultérieurs générés par ce trafic mal acheminé, s'ils sont également attribués de manière incorrecte, introduisent du bruit et des signaux potentiellement incorrects dans les données d'entraînement.
- Ce problème affecte à la fois la mesure et l'entraînement du modèle.
Description
- Cette vérification permet de valider que les événements utilisateur d'achat finalisé enregistrés pour un utilisateur (identifié par son ID de visiteur ou son ID utilisateur) sont tagués avec le
experimentIdscorrect correspondant au groupe de test A/B auquel il a été attribué (par exemple, le groupe de contrôle ou le groupe de test). - Il détecte les cas où l'événement d'achat d'un utilisateur est associé à un bras de test autre que celui dans lequel il se trouvait lorsqu'il a effectué les actions de recherche pertinentes qui ont conduit à l'achat.
- Ce problème est étroitement lié au maintien d'une attribution cohérente des visiteurs aux groupes de test et repose sur l'inclusion des experimentIds dans l'événement purchase-complete.
Impact
- Il est essentiel d'attribuer les visiteurs de manière cohérente aux voies de test pour effectuer des tests A/B précis.
- Si des événements d'achat finalisé sont tagués par erreur avec un ID de test incorrect, ils seront attribués à tort à ce canal.
- Cela fausse directement les métriques qui s'appuient sur les données d'achat par canal, comme le taux de revenus, le taux de commandes, le panier moyen et le taux de conversion.
- Une attribution erronée empêche de comparer précisément les performances des différents groupes de test, ce qui fausse les résultats des tests A/B.
- Du point de vue de l'entraînement des modèles, les modèles de recherche Retail, en particulier ceux qui optimisent le revenu ou le taux de conversion, s'entraînent en associant les interactions des utilisateurs (comme les recherches) aux achats ultérieurs pour comprendre quels résultats génèrent des conversions.
- Une attribution appropriée, qui utilise souvent des ID de visiteurs, d'utilisateurs et de tests pour relier les événements d'achat aux recherches, est essentielle pour créer ces exemples d'entraînement positifs.
- Si des événements d'achat sont attribués par erreur en raison d'ID incohérents ou de changements de bras de test, les données d'entraînement sont corrompues par des signaux incorrects.
- Valide si les ID de test sont envoyés dans l'événement d'achat : comme indiqué, cette vérification n'est valide et efficace que si les
experimentIdssont correctement implémentés et envoyés dans les événements utilisateur d'achat finalisé.
Description
- Semblable à la vérification de l'événement d'achat, cette vérification permet de s'assurer que les événements utilisateur "Ajouter au panier" pour un ID de visiteur donné sont correctement associés au groupe de test attribué à l'utilisateur à l'aide du champ "ID de test".
- Il identifie les cas où un événement "Ajouter au panier" est tagué avec un ID de test pour un emplacement auquel l'utilisateur n'a pas été attribué.
- Ce problème peut provenir d'une utilisation incohérente des ID de visiteur pour différents types d'événements ou d'un taggage
experimentIdsincorrect.
Impact
- Si des événements "Ajout au panier" sont tagués par erreur, le comportement de l'utilisateur sera attribué de manière incorrecte aux bras du test.
- Cela fausse directement des métriques comme le taux d'ajout au panier et le taux de conversion, en particulier si le taux d'ajout au panier est considéré comme une étape importante de l'entonnoir de conversion.
- Des métriques inexactes compromettent la fiabilité des résultats des tests A/B et la capacité à mesurer correctement l'impact du test.
- Du point de vue de l'entraînement des modèles, les événements "Ajout au panier" servent de signaux positifs importants à partir desquels les modèles, en particulier ceux optimisés pour les revenus, apprennent.
- Si ces événements sont attribués par erreur à la mauvaise voie de test en raison d'un ID ou d'un tag
experimentIdsincohérents, le modèle reçoit des signaux d'entraînement bruyants ou incorrects. - Valide si les ID de test sont envoyés dans l'événement "Ajouter au panier" : comme indiqué, cette vérification n'est valide et efficace que si les
experimentIdssont correctement implémentés et envoyés dans les événements utilisateur "Ajouter au panier".
Description
- Ce contrôle évalue si la répartition de l'activité des utilisateurs, classée par type d'appareil (par exemple, mobile, ordinateur, application), est équilibrée entre les bras de contrôle et de test pour chaque type d'événement utilisateur (Recherche, Vue de la page de détails, Ajout au panier, Achat).
- Il vise à s'assurer que la proportion d'utilisateurs interagissant avec le site sur mobile est à peu près la même dans le groupe de contrôle que dans le groupe de test, et de même pour les autres types d'appareils.
- La détection d'un biais important indique un problème potentiel dans le mécanisme utilisé pour répartir le trafic ou acheminer les événements en fonction du type d'appareil.
Impact
Une distribution asymétrique des appareils signifie que les groupes de contrôle et de test ne sont pas équilibrés sur le plan démographique en termes d'appareils utilisés, comme pour le problème de répartition démographique.
Le comportement des utilisateurs, leurs habitudes de navigation et les taux de conversion peuvent varier considérablement en fonction de l'appareil utilisé. C'est pourquoi une répartition déséquilibrée des appareils entre les bras de test introduit un biais dans la comparaison des tests A/B, ce qui entraîne une mesure inexacte des métriques commerciales clés pour chaque bras. Cela est également dû au fait que les résultats d'un groupe peuvent être influencés de manière disproportionnée par un pourcentage plus ou moins élevé d'utilisateurs d'un type d'appareil spécifique, ce qui rend difficile la détermination de l'impact réel du test.
Bien que le type d'appareil ne soit pas toujours une fonctionnalité directe dans tous les modèles, l'équilibre du trafic permet de s'assurer que les données d'entraînement, qui sont dérivées des événements utilisateur dans chaque canal, reflètent fidèlement la répartition réelle du comportement des utilisateurs sur les appareils. Un déséquilibre peut indirectement entraîner des données d'entraînement qui surreprésentent ou sous-représentent le comportement des utilisateurs sur certains appareils, ce qui peut conduire à un modèle qui n'est pas optimisé pour l'ensemble de la base d'utilisateurs.
Les événements constituent la base du suivi des KPI et du dépannage général.
Description
- Cette vérification compare les données de filtre incluses dans les événements utilisateur de recherche entre les bras de contrôle et de test pour des requêtes de recherche similaires.
- Il vérifie que les informations de filtrage sont capturées correctement, de manière cohérente et avec parité entre les voies.
- Cela inclut de vérifier si les options de filtrage (facettes) disponibles présentées aux utilisateurs sont identiques ou équivalentes, si les valeurs de filtre envoyées dans les événements correspondent aux formats attendus ou aux données du catalogue, et si l'UI/UX pour le filtrage est comparable.
- Une différence peut survenir si les filtres ne sont pas capturés ou s'ils sont capturés de manière incorrecte, ou si l'interface utilisateur/les options de filtrage diffèrent. Cela peut généralement être attribué à un problème de configuration dans l'API Catalog ou Search.
Impact
- Les différences dans l'expérience de filtrage ou dans la façon dont les données de filtre sont capturées entre les bras de test peuvent influencer directement la façon dont les utilisateurs interagissent avec les résultats de recherche.
- Si une voie propose des options de filtrage plus performantes ou différentes, les utilisateurs de cette voie peuvent affiner leurs recherches différemment, ce qui entraîne des variations dans le comportement des utilisateurs et peut avoir un impact sur des métriques telles que les taux de conversion pour les recherches filtrées.
- Cela introduit un biais variable dans le test A/B, ce qui rend difficile l'attribution des différences de métriques observées uniquement aux différences de classement dans les résultats de recherche.
- L'absence de données de filtre capturées dans les événements limite également la possibilité d'analyser les métriques de performances segmentées par utilisation des filtres, ce qui a un impact sur les insights de mesure.
- Pour l'entraînement des modèles, les informations de filtrage dans les événements de recherche sont essentielles pour entraîner les modèles de facettes dynamiques. En effet, le modèle apprend la popularité des facettes à partir des signaux d'utilisation des filtres par les utilisateurs.
- Il est également important que les informations sur l'utilisation des filtres dans les événements soient précises pour les modèles de reclassification basés sur les clics. Si les valeurs de filtre dans les événements ne correspondent pas à celles des requêtes de recherche, les performances du modèle pour les requêtes avec filtres sont affectées négativement.
- Des données de filtre incohérentes ou manquantes dans les événements dégradent la qualité du modèle liée aux facettes dynamiques et au reclassement des requêtes filtrées.
Description
- Cette vérification consiste à examiner un parcours utilisateur de recherche spécifique en associant un événement de recherche à sa requête d'API Search correspondante à l'aide de
attributionToken. - Le jeton d'attribution est généré par Vertex AI Search for Commerce et renvoyé avec chaque requête de recherche.
- Cette vérification compare spécifiquement le champ
searchQueryde l'événement de recherche à la chaîne de requête réelle envoyée dans la requête initiale de l'API Search qui a renvoyé le jeton d'attribution. - Si ces chaînes de requête ne correspondent pas malgré la présence d'un jeton d'attribution d'association, cela indique que la searchQuery envoyée dans l'événement utilisateur ne reflète pas précisément la requête de recherche d'origine de l'utilisateur.
Impact
- Ce problème affecte fortement l'entraînement du modèle.
- Vertex AI Search pour le commerce utilise des données d'événement pour entraîner ses modèles.
- Les modèles, en particulier les modèles de réorganisation basés sur les clics, apprennent en associant les interactions des utilisateurs (comme les clics, les ajouts au panier et les achats) aux requêtes de recherche qui ont généré les résultats.
- Cette association repose sur des informations précises dans les événements, y compris les champs
searchQueryetattributionToken. - Si le
searchQueryde l'événement ne correspond pas à la requête réelle de la demande de l'API Search, le modèle est entraîné sur des données incorrectes, associant le comportement de l'utilisateur à la mauvaise requête. - Cela peut avoir un impact négatif important sur la qualité des résultats de recherche, car le modèle apprend des stratégies de classement non optimales basées sur des données de requête erronées.
- Bien que l'impact principal concerne la qualité de l'entraînement des modèles, cela peut également affecter indirectement les mesures. En effet, les modèles entraînés sur des données de mauvaise qualité peuvent être peu performants, ce qui peut fausser les résultats des tests A/B, même si les événements sont capturés.
Description
- Cette vérification est un processus de validation manuelle dans lequel un testeur simule un parcours utilisateur type impliquant une séquence d'actions telles que la recherche, le clic sur un produit (événement
detail-page-view), l'ajout au panier et éventuellement l'achat. - En notant l'ID de visiteur et les codes temporels de ces actions, le testeur récupère ensuite les événements utilisateur enregistrés pour cet ID de visiteur spécifique à partir des journaux ou des plates-formes de données.
- L'objectif est de vérifier qu'il existe une correspondance un-à-un entre les actions observées de l'utilisateur et les événements enregistrés dans le système (par exemple, une action de recherche doit générer un événement de recherche, un clic ou un événement
detail-page-view). - Des événements manquants, des événements avec des ID de visiteur incorrects ou des données corrompues dans les événements (comme des ID de produit ou d'expérience manquants) indiquent des problèmes dans le pipeline d'événements.
Impact
- Les problèmes identifiés par cette vérification ont une incidence considérable sur la mesure et l'entraînement du modèle.
Mesure
- Des événements utilisateur précis et complets sont essentiels pour calculer les métriques clés de votre activité dans un test A/B, comme le taux de clics sur les résultats de recherche, le taux de conversion des recherches, le taux d'ajout au panier des recherches et les revenus par visiteur.
- Ces métriques reposent sur l'attribution du comportement des utilisateurs (clics, ajouts au panier, achats) à des résultats de recherche et des groupes de test spécifiques.
- Si des événements sont manquants ou corrompus pour un utilisateur, ses actions ne sont pas entièrement enregistrées, ce qui entraîne un calcul incorrect de ces métriques pour le bras de test auquel il a été attribué.
- Cela introduit des biais et du bruit, ce qui rend les résultats des tests A/B inexacts et peu fiables pour la prise de décision. Par exemple, l'absence d'événements d'achat a un impact direct sur les métriques "Taux de conversion" et "Hausse des revenus".
Entraînement du modèle
- Les modèles Vertex AI Search pour le commerce sont entraînés de manière intensive sur les données d'événements utilisateur pour apprendre les schémas de comportement des utilisateurs et optimiser le classement.
- Les ID de visiteurs et d'utilisateurs sont essentiels pour les fonctionnalités de personnalisation et pour associer des événements afin de créer des exemples d'entraînement.
- Si des événements sont manquants ou corrompus, le modèle perd de précieux signaux d'entraînement provenant de la séquence d'interactions de l'utilisateur. Par exemple, si des événements d'achat ou d'ajout au panier sont manquants, le modèle ne peut pas apprendre quelles interactions avec les produits ont généré des conversions.
- De même, si des événements de vue de page de détails sont manquants, le modèle ne reçoit pas de signaux sur les clics. Cette réduction de la quantité et de la qualité des données d'entraînement nuit à la capacité du modèle à apprendre efficacement, ce qui entraîne une mauvaise qualité des résultats de recherche et peut potentiellement annuler les avantages de l'utilisation d'un moteur de recherche basé sur le ML.
- Une mise en correspondance ou une mise en forme incohérentes des ID de visiteurs peuvent également perturber ce processus.
- Les événements d'achat manquants ont un impact sur l'entraînement du modèle, car il ne voit jamais les achats.