A atribuição de dados adequada, a identificação consistente dos utilizadores e a monitorização precisa de eventos alcançam resultados fiáveis e um desempenho ideal do modelo. Os problemas podem causar métricas distorcidas, comparações tendenciosas e dados de preparação danificados. Estes resultados dificultam as decisões informadas e a melhoria da pesquisa.
Antes de começar
Consulte as Orientações gerais sobre a realização de experiências A/B.
Componentes de teste
As verificações A/B iniciais incorporam estes componentes de teste:
ID do visitante: obrigatório para monitorizar um visitante num dispositivo, independentemente do estado de início de sessão. Não deve mudar, quer o visitante inicie ou termine sessão. Se o utilizador iniciar sessão entre percursos do utilizador, o ID do visitante permanece constante.
ID da sessão: para acompanhar a sessão de interação de um visitante. Definido como uma agregação do comportamento do utilizador num intervalo de tempo, que termina normalmente após 30 minutos de inatividade.
ID do utilizador: identificador persistente altamente recomendado para um utilizador com sessão iniciada (como um ID de cliente) que é usado em todos os dispositivos para personalização. Deve ser sempre um valor com hash.
Token de atribuição: um token de hash devolvido em todas as respostas de pesquisa. Os tokens de atribuição são únicos, independentemente de os parâmetros de consulta de pesquisa terem correspondido exatamente.
Descrição
Esta verificação envolve a confirmação de que o número de IDs de visitantes únicos é dividido aleatoriamente entre os grupos de controlo e de teste numa experiência A/B.
O ID de visitante é um identificador exclusivo de um utilizador num único dispositivo.
Impacto
Historicamente, uma divisão injusta dos IDs de visitantes pode causar erros de medição nos testes A/B.
Se um grupo de teste contiver um número desproporcionado de determinados tipos de visitantes, como um visitante bot que envia volumes elevados de tráfego de sondagem, pode afetar negativamente as métricas desse grupo. Isto distorce as comparações dos indicadores essenciais de desempenho e afeta fortemente a medição, mas não diretamente a preparação do modelo.
Descrição
Esta verificação garante que o número de IDs de utilizadores únicos, que representa um utilizador com sessão iniciada, está distribuído uniformemente entre os grupos de controlo e de teste. O ID do utilizador deve permanecer consistente em todos os dispositivos.
Impacto
O impacto é semelhante ao do ID de visitante. Se os utilizadores com sessão iniciada não forem atribuídos aleatoriamente entre as faixas de teste e de controlo, pode ocorrer uma divisão demográfica tendenciosa.
Por exemplo, se o grupo experimental contiver predominantemente novos utilizadores, enquanto os utilizadores com gastos elevados permanecerem no grupo de controlo, as métricas vão parecer favorecer artificialmente um dos lados.
Isto afeta a medição e as comparações de indicadores essenciais de desempenho (IEDs).
Descrição
Esta verificação analisa especificamente a distribuição de utilizadores com um número elevado de transações ou compras repetidas, frequentemente identificados pelos respetivos IDs de visitantes e histórico de compras, nas faixas da experiência.
O objetivo é garantir que estes utilizadores com gastos elevados estão divididos uniformemente.
Impacto
- Uma distribuição desigual de utilizadores avançados, que contribuem significativamente para a receita, pode distorcer fortemente as comparações de KPIs entre os grupos de experiência.
- A depuração de parcialidades com base em informações demográficas, como os hábitos de gastos, pode ser complexa.
- Isto afeta desproporcionadamente as métricas baseadas na receita, como a receita por visitante (RPV) ou a receita por sessão.
- Realce o impacto na precisão da medição durante os testes A/B.
Descrição
Esta verificação confirma que o token de atribuição devolvido na resposta de pesquisa está corretamente incluído no evento de pesquisa resultante dessa pesquisa.
O token de atribuição é necessário para que o Vertex AI Search for commerce associe os eventos à pesquisa que os gerou:
- Normalmente, isto é relevante para o tráfego publicado pelo Vertex AI Search.
- Este problema também indica a possibilidade de colocação em cache da resposta de pesquisa, o que degrada o desempenho da pesquisa e a experiência do utilizador devido ao inventário obsoleto e à classificação desatualizada.
Impacto
A atribuição adequada através do token é fundamental para associar o comportamento do utilizador, incluindo cliques e compras, a chamadas API de pesquisa específicas. Sem o token, os eventos de pesquisa podem ser usados incorretamente como se fossem de outro fornecedor de pesquisa, e os eventos subsequentes não podem ser associados com precisão à pesquisa.
Os tokens de atribuição incorretos ou em falta interrompem a preparação do modelo, porque são usados para associar dados de eventos (como pesquisas seguidas de compras) para gerar exemplos positivos e negativos para preparar o modelo de classificação. Também impede o cálculo preciso das métricas por pesquisa, como a receita por pesquisa, que são essenciais para avaliar o desempenho durante as experiências A/B.
Isto afeta a preparação do modelo, a medição e a análise do desempenho.
Descrição
Esta verificação garante que o ID do visitante e o ID do utilizador usados numa chamada de pedido de pesquisa para a API Search são o mesmo ID do visitante e ID do utilizador incluídos no evento de utilizador de pesquisa subsequente (se possível, para eventos de visualização da página de detalhes, de adição ao carrinho e de compra concluída, que estão relacionados com essa interação de pesquisa).
- Os campos
visitorIdeuserId, respetivamente, são um identificador exclusivo de um utilizador num único dispositivo. - A formatação consistente do ID do visitante e do ID de utilização em pedidos de pesquisa e eventos do utilizador é necessária para que a pesquisa identifique corretamente a atividade do utilizador.
- As abordagens de depuração podem envolver a utilização do ID do visitante e do ID do utilizador para rastrear interações.
Impacto
Uma incompatibilidade indica potenciais problemas, como eventos em falta ou dados danificados.
O ID do visitante e o ID do utilizador são essenciais para a preparação do modelo de pesquisa de retalho, especialmente para as funcionalidades de personalização. A atribuição precisa de compras baseia-se na utilização consistente de um ID de visitante e um ID de utilizador.
O Vertex AI Search para comércio usa o ID do visitante para associar os resultados da pesquisa vistos por um utilizador ao facto de esse mesmo ID do visitante ter comprado posteriormente um produto apresentado. É usado para associar dados de pesquisa a cliques, de adição ao carrinho ou de compra para gerar exemplos positivos e negativos para a preparação do modelo de classificação.
Se o ID do visitante não corresponder, ocorre uma falha em que os eventos de compra não podem ser atribuídos à pesquisa ou à visualização da página de detalhes que os precedeu, o que faz parecer que nenhuma pesquisa tem uma compra de seguimento. Isto não só interrompe a preparação do modelo, como também dificulta o cálculo de métricas por pesquisa, como a receita por pesquisa. Outro desafio reside no cálculo preciso dos indicadores essenciais de desempenho (IEDs), como a receita por visitante, a taxa de conversão e o valor médio da encomenda, que dependem da associação precisa dos eventos do utilizador às pesquisas. Assim, esta verificação afeta a preparação do modelo e a medição.
Descrição
Esta verificação compara o volume de pedidos de pesquisa feitos à API Search para uma faixa de teste específica (particularmente a faixa da Google) com o volume de eventos do utilizador de pesquisa registados para essa mesma faixa.
A expetativa é que o número de eventos de pesquisa recolhidos corresponda de perto ao número de chamadas da API Search feitas.
Impacto
- Uma incompatibilidade significativa indica que os eventos do utilizador não estão a ser recolhidos ou enviados corretamente para a Google.
- Isto pode ser causado por problemas de carregamento de eventos (eventos em falta ou incompletos) ou etiquetagem incorreta de eventos do utilizador com o ID da experiência.
- A recolha adequada de eventos do utilizador é essencial porque as interações dos utilizadores captadas nos eventos fornecem ao modelo o feedback necessário para otimizar os resultados.
- Se faltarem eventos, o modelo recebe menos dados para preparação, o que pode afetar negativamente o respetivo desempenho.
- A precisão e a fiabilidade das métricas usadas para avaliar os testes A/B (como a taxa de cliques, a taxa de conversão e as métricas de receita) dependem inteiramente da integridade e da correção dos dados de eventos do utilizador.
- Os eventos em falta significam que estas métricas não podem ser calculadas com precisão, o que leva a uma análise de desempenho distorcida e a resultados de testes A/B não fiáveis.
- Uma falta de correspondência nas contagens de consultas entre as chamadas API e os eventos afeta a preparação e a medição do modelo.
Descrição
Esta verificação confirma que, quando um utilizador aplica filtros aos resultados da pesquisa (refletidos no pedido de pesquisa), o evento de utilizador de pesquisa correspondente, associado pelo token de atribuição, também inclui as informações de filtro corretas.
Esta verificação envolve a validação da consistência de pares específicos associados a tokens, bem como a validação da consistência geral dos dados de filtros presentes nos eventos em comparação com as chamadas da API.
Impacto
- A inclusão de declarações de filtros em eventos de pesquisa é necessária para usar facetas dinâmicas.
- O modelo de pesquisa de retalho deduz a popularidade dos filtros das facetas presentes nas solicitações de pesquisa, o que é fundamental para o desempenho ideal das facetas dinâmicas.
- Se os dados de filtros estiverem em falta ou incorretos nos eventos do utilizador, a capacidade do modelo de aprender com as interações do utilizador que envolvem filtros fica prejudicada.
- Isto afeta diretamente a preparação e a eficácia de funcionalidades como a segmentação dinâmica.
- Esta verificação também é útil para depurar problemas relacionados com resultados da pesquisa, pesquisa conversacional e facetas dinâmicas.
- Embora o impacto principal seja na preparação do modelo especificamente para facetas dinâmicas e funcionalidades relacionadas, também afeta a capacidade de depurar e medir com precisão o desempenho destas funcionalidades específicas.
- Afeta a preparação do modelo relacionada com facetas dinâmicas e é importante para a depuração e a análise do desempenho (medição) das funcionalidades que dependem de dados de filtros.
Descrição
- Esta verificação confirma se os parâmetros de paginação (desvio) e os critérios de ordenação (ordenar por) incluídos num pedido de pesquisa feito à API Search estão corretamente representados no evento do utilizador de pesquisa correspondente.
- Normalmente, estes eventos estão associados ao pedido original através do token de atribuição.
- A verificação garante a consistência das interações específicas associadas a tokens e dos dados gerais enviados em eventos.
- Manter esta consistência nos dados de eventos é importante para depurar percursos do utilizador que envolvem paginação ou ordenação, e para funcionalidades como a pesquisa conversacional e os filtros dinâmicos.
Impacto
- Uma não correspondência dificulta a capacidade de analisar com precisão a forma como os utilizadores interagem com os resultados da pesquisa em condições específicas de paginação ou ordenação.
- Isto afeta os esforços de depuração destas funcionalidades e dificulta a avaliação precisa do respetivo desempenho (afetando a medição de funcionalidades como a pesquisa conversacional ou o desempenho da segmentação dinâmica).
- Os dados de eventos consistentes são fundamentais para a preparação de modelos, e as inconsistências podem afetar indiretamente as estatísticas derivadas da análise do comportamento do utilizador em diferentes condições de apresentação.
- A consistência dos parâmetros de pedido e dos valores de eventos é considerada importante para o desempenho dos modelos de reclassificação baseados em cliques.
- Isto afeta principalmente a depuração e a medição de funcionalidades específicas e, em certa medida, a eficácia da preparação do modelo associada à compreensão da interação do utilizador com resultados paginados ou ordenados.
Descrição
- Esta verificação garante que um ID de visitante único (usado para utilizadores que não iniciaram sessão) permanece atribuído a um único grupo experimental ou faixa, ou seja, o controlo ou o teste, durante o período do teste A/B.
- É esperada uma atribuição consistente de visitantes, a menos que haja uma alteração planeada, como o aumento gradual do tráfego ou a reorganização explícita.
- A deteção de comutações significa que um único utilizador, identificado pelo respetivo ID do visitante, está a mover-se inesperadamente entre grupos experimentais.
- Isto pode dever-se a problemas como o envio incorreto de eventos, a etiquetagem incorreta do ID da experiência em eventos, problemas de implementação no front-end ou o encaminhamento de tráfego de pesquisa configurado incorretamente.
Impacto
- A atribuição consistente de visitantes do site é crucial para um teste A/B justo.
- Se um visitante do site mudar de faixa, os respetivos eventos de utilizador (cliques, adições ao carrinho, compras) podem ser registados em IDs de experiências diferentes, o que torna impossível atribuir com precisão o respetivo comportamento geral a uma única experiência. Isto corrompe os dados usados para calcular os indicadores essenciais de desempenho (IEDs) de cada faixa, o que leva a resultados de medição distorcidos e não fiáveis.
- A preparação do modelo de pesquisa de retalho, especialmente para personalização, depende fortemente de campos
visitorIdeuserIdconsistentes para associar as interações dos utilizadores ao longo do tempo e atribuir compras a eventos de pesquisa anteriores. - A mudança do ID do visitante quebra esta associação, o que impede que o modelo aprenda eficazmente com o percurso de um utilizador numa experiência de pesquisa consistente. Isto afeta significativamente a medição e a preparação do modelo.
Descrição
- Esta verificação analisa especificamente os eventos de utilizadores da pesquisa etiquetados com um ID de experiência pertencente ao grupo de controlo ou ao tráfego de retenção, mas que contêm inesperadamente um token de atribuição gerado pela Google.
- Os tokens de atribuição são devolvidos pela API Retail Search e destinam-se a ser incluídos em eventos de utilizadores subsequentes para tráfego publicado pela Google.
- O tráfego de controlo usa o motor de pesquisa existente e não deve receber nem enviar tokens de atribuição da Google.
- Este problema está relacionado com a verificação da mudança do ID da experiência, uma vez que implica que os eventos estão a ser etiquetados ou encaminhados por engano.
- Este problema pode indicar a possibilidade de colocação em cache de respostas de pesquisa, o que vai degradar o desempenho da pesquisa e a experiência do utilizador devido ao inventário desatualizado e à classificação desatualizada.
Impacto
- A presença de um token de atribuição da Google num evento de grupo de controlo leva a atribuições etiquetadas incorretamente.
- Isto significa que os eventos de utilizadores que experimentaram a pesquisa de controlo (não Google) estão incorretamente associados ao grupo experimental da Google.
- Isto distorce diretamente o cálculo das métricas para a faixa da Google, incluindo dados do grupo de controlo, distorcendo o desempenho percebido e invalidando a medição.
- Do ponto de vista da preparação do modelo, o modelo usa eventos do utilizador atribuídos para aprender com as interações com os resultados da pesquisa.
- A inclusão de eventos atribuídos por engano do grupo de controlo introduz dados irrelevantes ou em conflito no conjunto de preparação, o que pode levar a uma degradação no desempenho do modelo.
- Esta verificação afeta a medição e a preparação do modelo.
Descrição
- Esta verificação centra-se nas chamadas de pedidos de pesquisa recebidas para a própria API Retail Search.
- Procura pedidos que tenham origem em IDs de visitantes ou IDs de experiências designados para o grupo de controlo ou o tráfego de retenção.
- Isto indica que o tráfego destinado ao grupo de controlo ou de exclusão está a ser direcionado incorretamente para o ponto final da API da via de experiências da Google.
- Este problema é muito semelhante à verificação da mudança do ID do visitante, mas é observado do lado do pedido da API e não apenas do lado do evento do utilizador.
Impacto
- Esta descoberta aponta para uma configuração incorreta fundamental no mecanismo de divisão e encaminhamento do tráfego do teste A/B.
- Os grupos experimentais não estão devidamente isolados se o tráfego de controlo for enviado para a API Google.
- Isto invalida a configuração do teste A/B e compromete a imparcialidade da comparação.
- Afeta diretamente a medição, uma vez que o volume e a composição do tráfego na faixa da Google são aumentados pela inclusão de utilizadores não intencionais, o que leva a um cálculo e uma análise de métricas imprecisos.
- Para a preparação do modelo, embora os registos da API em si não sejam os dados de preparação principais, os eventos de utilizador subsequentes gerados por este tráfego encaminhado incorretamente, se também forem atribuídos por engano, introduzem ruído e sinais potencialmente incorretos nos dados de preparação.
- Este problema afeta a medição e a preparação do modelo.
Descrição
- Esta verificação valida se os eventos do utilizador purchase-complete registados para um utilizador (identificado pelo respetivo ID do visitante ou ID do utilizador) estão etiquetados com o
experimentIdscorreto correspondente ao grupo de teste A/B ao qual foi atribuído, como o grupo de controlo ou o grupo de experiência. - Deteta instâncias em que o evento de compra de um utilizador está associado a uma faixa de experiência diferente daquela em que se encontrava quando realizou as ações de pesquisa relevantes que levaram à compra.
- Este problema está estreitamente relacionado com a manutenção da atribuição consistente de visitantes a grupos de experiências e depende da inclusão de IDs de experiências no evento purchase-complete.
Impacto
- A atribuição consistente de visitantes a faixas de experiências é crucial para testes A/B precisos.
- Se os eventos de conclusão de compra forem etiquetados por engano com o ID da experiência errado, são atribuídos incorretamente a essa faixa.
- Isto distorce diretamente as métricas que dependem dos dados de compra por faixa, como a taxa de receita, a taxa de pedidos de compra, o valor de encomenda médio e a taxa de conversão.
- A atribuição incorreta impossibilita a comparação precisa do desempenho de diferentes grupos de experiência, o que leva a resultados de medição de testes A/B inválidos e não fiáveis.
- Do ponto de vista da preparação de modelos, os modelos de pesquisa de retalho, particularmente os que são otimizados em função da receita ou da taxa de conversão, são preparados associando as interações dos utilizadores (como a pesquisa) às compras subsequentes para compreender que resultados geram conversões.
- A atribuição adequada, que usa frequentemente IDs de visitantes, utilizadores e experiências para associar eventos de compra a pesquisas, é essencial para criar estes exemplos de preparação positivos.
- Se os eventos de compra forem atribuídos por engano devido a IDs inconsistentes ou à mudança de um grupo de teste para outro, os dados de preparação ficam danificados com sinais incorretos.
- Válido se os IDs das experiências forem enviados no evento de compra: conforme indicado, esta verificação é válida e tem impacto apenas se os parâmetros
experimentIdsforem implementados e enviados corretamente nos eventos de utilizador de compra concluída.
Descrição
- Semelhante à verificação do evento de compra, isto verifica se os eventos de utilizador de adição ao carrinho para um determinado ID de visitante estão corretamente associados ao grupo de teste atribuído ao utilizador através do campo de IDs de experiências.
- Identifica casos em que um evento de adição ao carrinho é etiquetado com um ID de experiência para uma faixa à qual o utilizador não foi atribuído.
- Este problema pode resultar de uma utilização inconsistente do ID do visitante em diferentes tipos de eventos ou de uma etiquetagem
experimentIdsincorreta.
Impacto
- Os eventos add_to_cart etiquetados incorretamente levam a uma atribuição incorreta deste comportamento do utilizador às faixas da experiência.
- Isto distorce diretamente métricas como a taxa de adição ao carrinho e a taxa de conversão, especialmente se a taxa de adição ao carrinho for considerada um passo importante no funil de conversão.
- As métricas imprecisas comprometem a fiabilidade dos resultados dos testes A/B e a capacidade de medir corretamente o impacto da experiência.
- Do ponto de vista da preparação de modelos, os eventos de adição ao carrinho servem como sinais positivos importantes a partir dos quais os modelos, particularmente os otimizados em função da receita, aprendem.
- Se estes eventos forem atribuídos por engano à faixa de teste errada devido a uma etiquetagem ou um ID inconsistente, o modelo recebe sinais de preparação ruidosos ou incorretos.
experimentIds - Válido se os IDs das experiências forem enviados no evento add_to_cart: conforme indicado, esta verificação só é válida e tem impacto se os
experimentIdsforem implementados e enviados corretamente nos eventos de utilizador add_to_cart.
Descrição
- Esta verificação avalia se a distribuição da atividade do utilizador, categorizada por tipo de dispositivo (por exemplo, dispositivo móvel, computador, app), está equilibrada nas faixas de controlo e de experiência para cada tipo de evento do utilizador (Pesquisa, Visualização da página de detalhes, Adicionar ao carrinho, Compra).
- O objetivo é garantir que a proporção de utilizadores que interagem com o site através de dispositivos móveis é aproximadamente a mesma no grupo de controlo e no grupo de teste, e o mesmo se aplica a outros tipos de dispositivos.
- A deteção de uma distorção significativa indica um potencial problema no mecanismo usado para dividir o tráfego ou encaminhar eventos com base no tipo de dispositivo.
Impacto
Uma distribuição enviesada de dispositivos significa que os grupos de controlo e de teste não estão demograficamente equilibrados em termos dos dispositivos usados, semelhante ao problema de divisão demográfica.
O comportamento do utilizador, os padrões de navegação e as taxas de conversão podem variar significativamente consoante o dispositivo usado. É por este motivo que uma divisão desequilibrada de dispositivos entre os grupos de teste da experiência introduz parcialidade na comparação do teste A/B, o que leva a uma medição imprecisa das principais métricas empresariais para cada grupo de teste. Isto também se deve ao facto de os resultados de um grupo poderem ser influenciados desproporcionadamente por uma percentagem mais alta ou mais baixa de utilizadores de um tipo de dispositivo específico, o que dificulta a determinação do verdadeiro impacto da experiência.
Embora o tipo de dispositivo nem sempre seja uma funcionalidade direta em todos os modelos, garantir um tráfego equilibrado ajuda a assegurar que os dados de preparação, que são derivados de eventos do utilizador em cada faixa, refletem com precisão a distribuição real do comportamento do utilizador entre dispositivos. Um desequilíbrio pode levar indiretamente a dados de preparação que representam em excesso ou em falta o comportamento do utilizador de determinados dispositivos, o que pode resultar num modelo que não está otimizado para a base de utilizadores geral.
Os eventos formam a base para a monitorização de KPIs e a resolução de problemas gerais.
Descrição
- Esta verificação compara os dados de filtros incluídos nos eventos de utilizadores de pesquisa entre os grupos de controlo e de experiência para consultas de pesquisa semelhantes.
- Valida se as informações dos filtros estão a ser captadas de forma correta, consistente e com paridade entre as faixas.
- Isto inclui verificar se as opções de filtro disponíveis (facetas) apresentadas aos utilizadores são iguais ou equivalentes, se os valores de filtro enviados em eventos correspondem aos formatos esperados ou aos dados do catálogo e se a IU/UX para filtragem é comparável.
- Pode surgir uma discrepância se os filtros não forem capturados, forem capturados incorretamente ou se as opções/IU de filtragem forem diferentes, o que normalmente pode ser rastreado até um problema de configuração no catálogo ou na API Google Search.
Impacto
- As diferenças na experiência de filtragem ou na forma como os dados de filtros são captados entre os caminhos da experiência podem influenciar diretamente a forma como os utilizadores interagem com os resultados da pesquisa.
- Se uma faixa oferecer opções de filtragem melhores ou diferentes, os utilizadores nessa faixa podem refinar as suas pesquisas de forma diferente, o que leva a variações no comportamento do utilizador e pode afetar métricas como as taxas de conversão para pesquisas filtradas.
- Isto introduz um desvio variável no teste A/B, o que dificulta a atribuição das diferenças de métricas observadas apenas às diferenças de classificação da pesquisa principais.
- A falta de dados de filtros captados em eventos também limita a capacidade de analisar as métricas de desempenho segmentadas pela utilização de filtros, o que afeta as estatísticas de medição.
- Para a preparação de modelos, as informações de filtro nos eventos de pesquisa são essenciais para preparar modelos de facetas dinâmicas, uma vez que o modelo aprende a popularidade das facetas a partir de sinais de utilização de filtros por parte dos utilizadores.
- As informações de utilização de filtros precisas nos eventos também são importantes para os modelos de reclassificação baseados em cliques. Se os valores dos filtros nos eventos não corresponderem aos dos pedidos de pesquisa, o desempenho do modelo para consultas com filtros é afetado negativamente.
- Os dados de filtros inconsistentes ou em falta nos eventos degradam a qualidade do modelo relacionada com as facetas dinâmicas e a reclassificação para consultas filtradas.
Descrição
- Esta verificação envolve o exame de um percurso do utilizador de pesquisa específico através da associação de um evento de pesquisa ao respetivo pedido da API Search usando o
attributionToken. - O token de atribuição é gerado pelo Vertex AI Search for commerce e devolvido com cada pedido de pesquisa.
- Esta verificação compara especificamente o campo
searchQueryno evento de pesquisa com a string de consulta real enviada no pedido inicial da API Search que devolveu o token de atribuição. - Se estas strings de consulta não corresponderem, apesar da presença de um token de atribuição da associação, indica que o searchQuery enviado no evento do utilizador não reflete com precisão a consulta de pesquisa original do utilizador.
Impacto
- Este problema afeta significativamente a preparação do modelo.
- O Vertex AI Search for commerce usa dados de eventos para preparar os respetivos modelos.
- Os modelos, particularmente os modelos de reclassificação baseados em cliques, aprendem associando as interações dos utilizadores (como cliques, adições ao carrinho e compras) aos pedidos de pesquisa que geraram os resultados.
- Esta associação baseia-se em informações precisas nos eventos, incluindo os campos
searchQueryeattributionToken. - Se o
searchQueryno evento não corresponder à consulta real do pedido da API Search, o modelo é preparado com base em dados incorretos, associando o comportamento do utilizador à consulta errada. - Isto pode ter um impacto negativo grave na qualidade dos resultados da pesquisa, porque o modelo aprende estratégias de classificação subótimas com base em dados de consultas com falhas.
- Embora o impacto principal seja na qualidade da preparação do modelo, isto também pode afetar indiretamente a medição, uma vez que os modelos preparados com dados incorretos podem ter um desempenho fraco, o que leva a resultados de testes A/B distorcidos, mesmo que os eventos sejam capturados.
Descrição
- Esta verificação é um processo de validação manual em que um testador simula um percurso típico do utilizador que envolve uma sequência de ações, como pesquisar, clicar num produto (evento
detail-page-view), adicionar ao carrinho e, potencialmente, fazer uma compra. - Ao registar o ID do visitante e as datas/horas destas ações, o testador obtém os eventos do utilizador registados para esse ID do visitante específico a partir de registos ou plataformas de dados.
- O objetivo é validar uma correspondência de 1:1 entre as ações observadas do utilizador e os eventos registados no sistema (por exemplo, uma ação de pesquisa deve gerar um evento de pesquisa, um clique ou um evento
detail-page-view). - Os eventos em falta, os eventos com IDs de visitantes incorretos ou os dados danificados nos eventos (como IDs de produtos ou IDs de experiências em falta) indicam problemas na canalização de eventos.
Impacto
- Os problemas identificados por esta verificação afetam significativamente a medição e a preparação do modelo.
Medição
- Os eventos do utilizador precisos e completos são fundamentais para calcular as principais métricas empresariais num teste A/B, como a taxa de cliques de pesquisa, a taxa de conversão de pesquisa, a taxa de adição ao carrinho de pesquisa e a receita por visitante.
- Estas métricas baseiam-se na atribuição do comportamento do utilizador (cliques, adições ao carrinho, compras) a resultados da pesquisa e faixas de testes específicos.
- Se os eventos estiverem em falta ou corrompidos para um utilizador, as respetivas ações não são totalmente captadas, o que leva a um cálculo incorreto destas métricas para a faixa de teste em que se encontrava.
- Isto introduz parcialidade e ruído, tornando os resultados do teste A/B imprecisos e não fiáveis para a tomada de decisões. Por exemplo, a falta de eventos purchase afeta diretamente a taxa de conversão e as métricas de aumento da receita.
Preparação de modelos
- A Pesquisa da Vertex AI para modelos de comércio é preparada extensivamente com dados de eventos do utilizador para aprender padrões de comportamento do utilizador e otimizar a classificação.
- Os IDs de visitantes e utilizadores são essenciais para as funcionalidades de personalização e para associar eventos de modo a criar exemplos de preparação.
- Os eventos em falta ou danificados significam que o modelo perde sinais de preparação valiosos da sequência de interação desse utilizador. Por exemplo, a falta de eventos de compra ou de adição ao carrinho impede o modelo de saber que interações com produtos geraram conversões.
- Da mesma forma, a falta de eventos de visualização da página de detalhes significa que o modelo não recebe sinais sobre cliques. Esta redução na quantidade e qualidade dos dados de preparação degrada a capacidade do modelo de aprender eficazmente, o que leva a uma qualidade fraca dos resultados da pesquisa e, potencialmente, anula as vantagens da utilização de um motor de pesquisa baseado em AA.
- A formatação ou o mapeamento do ID do visitante inconsistentes também podem interromper este processo.
- Os eventos de compra em falta afetam a preparação do modelo porque o modelo nunca vê compras.