La atribución de datos adecuada, la identificación coherente de los usuarios y el seguimiento preciso de los eventos permiten obtener resultados fiables y un rendimiento óptimo del modelo. Los problemas pueden provocar que las métricas estén sesgadas, que las comparaciones sean parciales y que los datos de entrenamiento estén dañados. Estos resultados dificultan la toma de decisiones fundamentadas y la mejora de la búsqueda.
Antes de empezar
Consulta las directrices generales para llevar a cabo experimentos A/B.
Componentes de prueba
Las comprobaciones iniciales de las pruebas A/B incorporan estos componentes:
ID de visitante: es obligatorio para monitorizar a un visitante en un dispositivo, independientemente de si ha iniciado sesión o no. No debería cambiar, independientemente de si el visitante inicia o cierra sesión. Si el usuario inicia sesión entre los recorridos, el ID de visitante se mantiene constante.
ID de sesión: se usa para hacer un seguimiento de la sesión de interacción de un visitante. Se define como una agregación del comportamiento de los usuarios en un periodo de tiempo que suele finalizar tras 30 minutos de inactividad.
ID de usuario: es un identificador persistente muy recomendable para un usuario que ha iniciado sesión (como un ID de cliente) que se usa en todos los dispositivos para personalizar la experiencia. Siempre debe ser un valor cifrado.
Token de atribución: token hash que se devuelve en cada respuesta de búsqueda. Los tokens de atribución son únicos, independientemente de si los parámetros de consulta de búsqueda coinciden exactamente.
Descripción
Esta comprobación consiste en verificar que el número de IDs de visitante únicos se divide aleatoriamente entre los grupos de control y de prueba en un experimento A/B.
El ID de visitante es un identificador único de un usuario en un solo dispositivo.
Impacto
Si los IDs de visitante no se dividen de forma equitativa, pueden producirse errores de medición en las pruebas A/B.
Si una variante de un experimento contiene un número desproporcionado de determinados tipos de visitantes (por ejemplo, un bot que envía grandes volúmenes de tráfico de sondeo), puede afectar negativamente a las métricas de esa variante. Esto sesga las comparaciones de los indicadores clave de rendimiento y afecta en gran medida a la medición, pero no directamente al entrenamiento del modelo.
Descripción
Esta comprobación asegura que el número de IDs de usuario únicos, que representa a un usuario que ha iniciado sesión, se distribuya de forma uniforme entre los grupos de control y de prueba. El ID de usuario debe ser el mismo en todos los dispositivos.
Impacto
El impacto es similar al del ID de visitante. Si los usuarios que han iniciado sesión no se asignan aleatoriamente a los grupos de prueba y de control, puede producirse una división demográfica sesgada.
Por ejemplo, si el grupo experimental contiene principalmente usuarios nuevos, mientras que los usuarios que gastan mucho permanecen en el grupo de control, las métricas parecerán favorecer artificialmente a un lado.
Esto afecta a las comparaciones de métricas e indicadores clave de rendimiento (KPIs).
Descripción
Esta comprobación analiza específicamente la distribución de los usuarios con un número elevado de transacciones o compras repetidas, a menudo identificados por sus IDs de visitante y su historial de compras, en las diferentes variantes del experimento.
El objetivo es asegurarse de que estos usuarios con un gasto elevado se dividan de forma equitativa.
Impacto
- Una distribución desigual de los usuarios avanzados, que contribuyen significativamente a los ingresos, puede sesgar en gran medida las comparaciones de KPIs entre los grupos del experimento.
- Depurar sesgos basados en información demográfica, como los hábitos de gasto, puede ser complejo.
- Esto afecta de forma desproporcionada a las métricas basadas en ingresos, como los ingresos por visitante o los ingresos por sesión.
- Destaca el impacto en la precisión de las mediciones durante las pruebas A/B.
Descripción
Esta comprobación verifica que el token de atribución devuelto en la respuesta de búsqueda se incluya correctamente en el evento de búsqueda que se ha producido como resultado de esa búsqueda.
Vertex AI Search for commerce necesita el token de atribución para vincular los eventos con la búsqueda que los ha generado:
- Esto suele ser relevante para el tráfico servido por Vertex AI Search.
- Este problema también indica la posibilidad de que se almacenen en caché las respuestas de búsqueda, lo que afectará negativamente al rendimiento de búsqueda y a la experiencia de usuario debido a que el inventario y la clasificación estarán obsoletos.
Impacto
Para vincular el comportamiento de los usuarios (incluidos los clics y las compras) con llamadas específicas a la API de búsqueda, es fundamental usar la atribución adecuada mediante el token. Sin el token, los eventos de búsqueda podrían usarse incorrectamente como si procedieran de otro proveedor de búsqueda, y los eventos posteriores no se podrán vincular a la búsqueda con precisión.
Si los tokens de atribución son incorrectos o faltan, se interrumpe el entrenamiento del modelo, ya que se usan para vincular datos de eventos (como búsquedas seguidas de compras) con el fin de generar ejemplos positivos y negativos para entrenar el modelo de clasificación. También impide que se calculen con precisión las métricas por búsqueda, como los ingresos por búsqueda, que son vitales para evaluar el rendimiento durante los experimentos A/B.
Esto afecta tanto al entrenamiento del modelo como a la medición y al análisis del rendimiento.
Descripción
Esta comprobación asegura que el ID de visitante y el ID de usuario que se usan en una llamada de solicitud de búsqueda a la API Search sean el mismo ID de visitante y el mismo ID de usuario que se incluyen en el evento de usuario de búsqueda posterior (si es posible detallar los eventos page-view, add-to-cart y purchase-complete relacionados con esa interacción de búsqueda).
- Los campos
visitorIdyuserIdson identificadores únicos de un usuario en un solo dispositivo. - Para que la búsqueda identifique correctamente la actividad de los usuarios, es necesario que el formato de los IDs de visitante y de uso sea coherente en todas las solicitudes de búsqueda y eventos de usuario.
- Para depurar, se pueden usar el ID de visitante y el ID de usuario para monitorizar las interacciones.
Impacto
Una discrepancia indica posibles problemas, como eventos que faltan o datos dañados.
El ID de visitante y el ID de usuario son fundamentales para el entrenamiento del modelo de Retail Search, sobre todo para las funciones de personalización. Para que la atribución de compra sea precisa, es necesario usar de forma coherente un ID de visitante y un ID de usuario.
Vertex AI Search for commerce usa el ID de visitante para vincular los resultados de búsqueda que ve un usuario con si ese mismo ID de visitante ha comprado más tarde un producto mostrado. Se usa para vincular datos de búsqueda a clic, de añadir al carrito o de compra para generar ejemplos positivos y negativos con los que entrenar el modelo de clasificación.
Si el ID de visitante no coincide, se produce un error que impide que los eventos de compra se atribuyan a la búsqueda o a la vista de la página de detalles que los precedieron, por lo que parece que ninguna búsqueda tiene una compra posterior. Esto no solo interrumpe el entrenamiento del modelo, sino que también dificulta el cálculo de métricas por búsqueda, como los ingresos por búsqueda. Otro reto es calcular con precisión los indicadores clave de rendimiento (KPIs), como los ingresos por visitante, la tasa de conversión y el valor medio de los pedidos, que dependen de la vinculación precisa de los eventos de usuario con las búsquedas. Por lo tanto, esta comprobación afecta tanto al entrenamiento del modelo como a la medición.
Descripción
Esta comprobación compara el volumen de solicitudes de búsqueda realizadas a la API Search de un carril de experimento específico (en concreto, el carril de Google) con el volumen de eventos de usuario de búsqueda registrados en ese mismo carril.
Lo habitual es que el número de eventos de búsqueda recogidos coincida con el número de llamadas a la API Search.
Impacto
- Una discrepancia significativa indica que los eventos de usuario no se están recogiendo o enviando correctamente a Google.
- Esto puede deberse a problemas de ingestión de eventos (eventos incompletos o que faltan) o a que los eventos de usuario se hayan etiquetado incorrectamente con el ID del experimento.
- Es fundamental recoger los eventos de usuario correctamente, ya que las interacciones de los usuarios registradas en los eventos proporcionan al modelo la información necesaria para optimizar los resultados.
- Si faltan eventos, el modelo recibe menos datos para el entrenamiento, lo que puede afectar negativamente a su rendimiento.
- La precisión y la fiabilidad de las métricas que se usan para evaluar las pruebas A/B (como la tasa de clics, la tasa de conversión y las métricas de ingresos) dependen por completo de la integridad y la exactitud de los datos de eventos de usuario.
- Si faltan eventos, estas métricas no se pueden calcular con precisión, lo que lleva a un análisis del rendimiento sesgado y a resultados de pruebas A/B poco fiables.
- Si no coinciden los recuentos de consultas entre las llamadas a la API y los eventos, se verán afectados tanto el entrenamiento del modelo como la medición.
Descripción
Esta comprobación verifica que, cuando un usuario aplica filtros a los resultados de búsqueda (que se reflejan en la solicitud de búsqueda), el evento de usuario de búsqueda correspondiente, vinculado por el token de atribución, también incluye la información de filtro correcta.
Esta comprobación implica verificar la coherencia de pares específicos vinculados a tokens, así como la coherencia general de los datos de filtro presentes en los eventos en comparación con las llamadas a la API.
Impacto
- Para usar las facetas dinámicas, es necesario incluir instrucciones de filtro en los eventos de búsqueda.
- El modelo de Retail Search deduce la popularidad de las facetas a partir de los filtros presentes en las solicitudes de búsqueda, lo que es crucial para que las facetas dinámicas funcionen de forma óptima.
- Si faltan datos de filtro o son incorrectos en los eventos de usuario, se verá afectada la capacidad del modelo para aprender de las interacciones de los usuarios que implican filtros.
- Esto influye directamente en el entrenamiento y la eficacia de funciones como la facetado dinámico.
- Esta comprobación también es útil para depurar problemas relacionados con los resultados de búsqueda, la búsqueda conversacional y las facetas dinámicas.
- Aunque el impacto principal se produce en el entrenamiento de modelos específicamente para las facetas dinámicas y las funciones relacionadas, también afecta a la capacidad de depurar y medir con precisión el rendimiento de estas funciones concretas.
- Afecta al entrenamiento de modelos relacionado con las facetas dinámicas y es importante para depurar y analizar el rendimiento (medición) de las funciones que dependen de los datos de filtro.
Descripción
- Esta comprobación verifica que los parámetros de paginación (desplazamiento) y los criterios de ordenación (ordenar por) incluidos en una solicitud de búsqueda realizada a la API Search se representan correctamente en el evento de usuario de búsqueda correspondiente.
- Estos eventos suelen estar vinculados a la solicitud original mediante el token de atribución.
- Esta comprobación asegura la coherencia de las interacciones vinculadas a tokens específicos y de los datos generales enviados en los eventos.
- Mantener esta coherencia en los datos de eventos es importante para depurar los recorridos de los usuarios que implican paginación u ordenación, así como para funciones como la búsqueda conversacional y las facetas dinámicas.
Impacto
- Si no coinciden, no se podrá analizar con precisión cómo interactúan los usuarios con los resultados de búsqueda en condiciones específicas de paginación u ordenación.
- Esto afecta a las tareas de depuración de estas funciones y dificulta la evaluación precisa de su rendimiento (lo que afecta a la medición de funciones como la búsqueda conversacional o el rendimiento del facetado dinámico).
- La coherencia de los datos de eventos es fundamental para entrenar los modelos, y las incoherencias podrían afectar indirectamente a las estadísticas derivadas del análisis del comportamiento de los usuarios en diferentes condiciones de visualización.
- Se indica que la coherencia de los parámetros de solicitud y los valores de evento es importante para el rendimiento de los modelos de reordenación basados en clics.
- Esto afecta principalmente a la depuración y la medición de funciones específicas y, en cierta medida, a la eficacia del entrenamiento del modelo relacionada con la comprensión de la interacción de los usuarios con los resultados paginados u ordenados.
Descripción
- Esta comprobación asegura que un ID de visitante único (que se usa para los usuarios que no han iniciado sesión) se asigne a un solo grupo o variante del experimento (es decir, al control o a la prueba) durante todo el periodo de la prueba A/B.
- Se espera que la asignación de visitantes sea coherente, a menos que haya un cambio planificado, como un aumento del tráfico o una reorganización explícita.
- Detectar cambios significa que un único usuario, identificado por su ID de visitante, se está moviendo inesperadamente entre los grupos experimentales.
- Esto puede deberse a problemas como el envío incorrecto de eventos, el etiquetado incorrecto del ID de experimento en los eventos, problemas de implementación en el frontend o un enrutamiento del tráfico de búsqueda mal configurado.
Impacto
- Es fundamental que los visitantes del sitio se asignen de forma coherente para que la prueba A/B sea justa.
- Si un visitante del sitio cambia de variante, sus eventos de usuario (clics, adiciones al carrito, compras) pueden registrarse con IDs de experimento diferentes, lo que hace que sea imposible atribuir con precisión su comportamiento general a una sola experiencia. Esto daña los datos que se usan para calcular los indicadores clave de rendimiento de cada carril, lo que da lugar a resultados de medición sesgados y poco fiables.
- El entrenamiento del modelo de Retail Search, especialmente en lo que respecta a la personalización, depende en gran medida de los campos
visitorIdyuserIdpara vincular las interacciones de los usuarios a lo largo del tiempo y atribuir las compras a los eventos de búsqueda anteriores. - Si se cambia el ID de visitante, se rompe este enlace, lo que impide que el modelo aprenda de forma eficaz del recorrido de un usuario en una experiencia de búsqueda coherente. Esto afecta significativamente tanto a la medición como al entrenamiento del modelo.
Descripción
- Esta comprobación analiza específicamente los eventos de usuario de búsqueda etiquetados con un ID de experimento que pertenece al grupo de control o al tráfico de retención, pero que contienen inesperadamente un token de atribución generado por Google.
- La API Retail Search devuelve tokens de atribución, que deben incluirse en los eventos de usuario posteriores del tráfico servido por Google.
- El tráfico de control usa el buscador actual y no debe recibir ni enviar tokens de atribución de Google.
- Este problema está relacionado con la comprobación del cambio de ID de experimento, ya que implica que los eventos se están etiquetando o enrutando por error.
- Este problema puede indicar la posibilidad de que se almacenen en caché las respuestas de búsqueda, lo que afectará negativamente al rendimiento de búsqueda y a la experiencia de usuario debido a que el inventario y la clasificación estarán obsoletos.
Impacto
- Si hay un token de atribución de Google en un evento de un grupo de control, las atribuciones se etiquetan por error.
- Esto significa que los eventos de los usuarios que han experimentado la búsqueda de control (no de Google) se asocian incorrectamente con el carril del experimento de Google.
- Esto sesga directamente el cálculo de las métricas de la vía de Google, ya que incluye datos del grupo de control, lo que distorsiona el rendimiento percibido e invalida la medición.
- Desde el punto de vista del entrenamiento de modelos, el modelo usa eventos de usuario atribuidos para aprender de las interacciones con los resultados de búsqueda.
- Si se incluyen eventos atribuidos erróneamente del grupo de control, se introducen datos irrelevantes o contradictorios en el conjunto de entrenamiento, lo que puede provocar una degradación del rendimiento del modelo.
- Esta comprobación afecta tanto a la medición como al entrenamiento del modelo.
Descripción
- Esta comprobación se centra en las llamadas de solicitudes de búsqueda entrantes a la propia API Retail Search.
- Busca solicitudes que procedan de IDs de visitante o de experimento designados para el grupo de control o el tráfico de retención.
- Esto indica que el tráfico destinado al grupo de control o al de retención se está dirigiendo incorrectamente al endpoint de la API de la vía del experimento de Google.
- Este problema es muy similar a la comprobación del cambio de ID de visitante, pero se observa desde el lado de la solicitud de la API en lugar de solo desde el lado del evento de usuario.
Impacto
- Este hallazgo indica que hay un error de configuración fundamental en el mecanismo de división y enrutamiento del tráfico de la prueba A/B.
- Las variantes experimentales no están aisladas correctamente si el tráfico de control se envía a la API de Google.
- Esto invalida la configuración de la prueba A/B y compromete la imparcialidad de la comparación.
- Esto afecta directamente a la medición, ya que el volumen y la composición del tráfico en el carril de Google se inflan al incluir usuarios no deseados, lo que provoca que los cálculos y los análisis de las métricas sean imprecisos.
- En el entrenamiento del modelo, aunque los registros de la API no son los datos de entrenamiento principales, los eventos de usuario posteriores generados por este tráfico mal dirigido, si también se atribuyen por error, introducen ruido y señales potencialmente incorrectas en los datos de entrenamiento.
- Este problema afecta tanto a la medición como al entrenamiento del modelo.
Descripción
- Esta comprobación valida que los eventos de usuario de compra completada registrados para un usuario (identificado por su ID de visitante o ID de usuario) estén etiquetados con el
experimentIdscorrecto correspondiente a la variante de la prueba A/B a la que se le haya asignado, como la de control o la experimental. - Detecta los casos en los que el evento de compra de un usuario se asocia a un carril de experimento distinto de aquel en el que se encontraba cuando realizó las acciones de búsqueda pertinentes que llevaron a la compra.
- Este problema está estrechamente relacionado con la asignación coherente de visitantes a grupos de experimentos y depende de que los IDs de experimento se incluyan en el evento purchase-complete.
Impacto
- Es fundamental que los visitantes se asignen de forma coherente a los segmentos de los experimentos para que las pruebas A/B sean precisas.
- Si los eventos purchase-complete se etiquetan por error con el ID de experimento incorrecto, se atribuirán incorrectamente a ese carril.
- Esto sesga directamente las métricas que dependen de los datos de compra por canal, como la tasa de ingresos, la tasa de pedidos de compra, el valor medio de pedido y la tasa de conversión.
- Si la atribución es incorrecta, no se puede comparar con precisión el rendimiento de los distintos grupos de experimento, lo que da lugar a resultados de medición de pruebas A/B no válidos y poco fiables.
- Desde el punto de vista del entrenamiento de modelos, los modelos de Búsqueda de Retail, sobre todo los que se optimizan para aumentar los ingresos o la tasa de conversión, se entrenan vinculando las interacciones de los usuarios (como las búsquedas) con las compras posteriores para saber qué resultados llevan a las conversiones.
- La atribución adecuada, que suele usar IDs de visitante, usuario y experimento para conectar los eventos de compra con las búsquedas, es esencial para crear estos ejemplos de entrenamiento positivos.
- Si los eventos de compra se atribuyen por error debido a IDs incoherentes o a cambios de carril de experimentos, los datos de entrenamiento se corrompen con señales incorrectas.
- Válido si los IDs de experimento se envían en el evento de compra: como se ha indicado, esta comprobación solo es válida y tiene un impacto si los
experimentIdsse implementan y se envían correctamente en los eventos de usuario de compra completada.
Descripción
- Al igual que en la comprobación del evento de compra, se verifica que los eventos de usuario de añadir al carrito de un visitante determinado se asocian correctamente al carril de experimento asignado al usuario mediante el campo de IDs de experimento.
- Identifica los casos en los que un evento de añadir al carrito se etiqueta con un ID de experimento de un carril al que no se ha asignado el usuario.
- Este problema puede deberse a un uso incoherente del ID de visitante en diferentes tipos de eventos o a un etiquetado
experimentIdsincorrecto.
Impacto
- Si los eventos de añadir al carrito se etiquetan por error, la atribución de este comportamiento de los usuarios a las variantes del experimento será incorrecta.
- Esto afecta directamente a métricas como la tasa de adición al carrito y la tasa de conversión, sobre todo si la tasa de adición al carrito se considera un paso importante en el embudo de conversión.
- Si las métricas no son precisas, se verá afectada la fiabilidad de los resultados de la prueba A/B y la capacidad de medir correctamente el impacto del experimento.
- Desde el punto de vista del entrenamiento de modelos, los eventos de añadir al carrito sirven como señales positivas importantes de las que aprenden los modelos, sobre todo los optimizados para los ingresos.
- Si estos eventos se atribuyen por error a la variante incorrecta del experimento debido a que el ID o el etiquetado
experimentIdsno son coherentes, el modelo recibe señales de entrenamiento ruidosas o incorrectas. - Válido si los IDs de experimento se envían en el evento de añadir al carrito: como se ha indicado, esta comprobación solo es válida y tiene un impacto si los
experimentIdsse implementan y se envían correctamente en los eventos de usuario de añadir al carrito.
Descripción
- Esta comprobación evalúa si la distribución de la actividad de los usuarios, categorizada por tipo de dispositivo (por ejemplo, móvil, ordenador o aplicación), está equilibrada entre las variantes de control y de experimento para cada tipo de evento de usuario (Búsqueda, Vista de página de detalles, Añadir al carrito o Compra).
- Su objetivo es asegurarse de que la proporción de usuarios que interactúan con el sitio mediante dispositivos móviles sea aproximadamente la misma en el grupo de control que en el grupo de prueba, y lo mismo con otros tipos de dispositivos.
- Si se detecta una asimetría significativa, significa que puede haber un problema en el mecanismo usado para dividir el tráfico o enrutar eventos en función del tipo de dispositivo.
Impacto
Si la distribución de los dispositivos es asimétrica, significa que los grupos de control y de prueba no están equilibrados demográficamente en cuanto a los dispositivos utilizados, lo que es similar al problema de la distribución demográfica.
El comportamiento de los usuarios, los patrones de navegación y las tasas de conversión pueden variar significativamente en función del dispositivo que se utilice. Por eso, si los dispositivos no se dividen de forma equilibrada entre las variantes del experimento, se introduce un sesgo en la comparación de la prueba A/B, lo que lleva a una medición imprecisa de las métricas empresariales clave de cada variante. Esto también se debe a que los resultados de un grupo pueden verse influidos de forma desproporcionada por un porcentaje mayor o menor de usuarios de un tipo de dispositivo específico, lo que dificulta determinar el verdadero impacto del experimento.
Aunque el tipo de dispositivo no siempre es una función directa en todos los modelos, asegurar un tráfico equilibrado ayuda a que los datos de entrenamiento, que se derivan de los eventos de usuario de cada carril, reflejen con precisión la distribución real del comportamiento de los usuarios en los dispositivos. Un desequilibrio podría dar lugar indirectamente a datos de entrenamiento que representen en exceso o en defecto el comportamiento de los usuarios de determinados dispositivos, lo que podría provocar que el modelo no esté optimizado para la base de usuarios en general.
Los eventos son la base del seguimiento de los KPIs y de la solución de problemas generales.
Descripción
- Esta comprobación compara los datos de filtro incluidos en los eventos de usuario de búsqueda entre las variantes de control y de experimento para consultas de búsqueda similares.
- Verifica que la información de los filtros se capture correctamente, de forma coherente y con paridad entre los carriles.
- Esto incluye comprobar si las opciones de filtro disponibles (facetas) que se muestran a los usuarios son las mismas o equivalentes, si los valores de filtro enviados en los eventos coinciden con los formatos esperados o los datos del catálogo, y si la interfaz de usuario y la experiencia de usuario para filtrar son comparables.
- Puede haber discrepancias si los filtros no se registran o se registran de forma incorrecta, o si la interfaz de usuario o las opciones de filtrado son diferentes. Normalmente, esto se debe a un problema de configuración en la API Catalog o Search.
Impacto
- Las diferencias en la experiencia de filtrado o en la forma en que se capturan los datos de los filtros entre los carriles de los experimentos pueden influir directamente en la forma en que los usuarios interactúan con los resultados de búsqueda.
- Si un carril ofrece opciones de filtrado mejores o diferentes, los usuarios de ese carril pueden refinar sus búsquedas de forma distinta, lo que puede provocar variaciones en el comportamiento de los usuarios y afectar a métricas como las tasas de conversión de las búsquedas filtradas.
- Esto introduce un sesgo variable en la prueba A/B, lo que dificulta atribuir las diferencias observadas en las métricas únicamente a las diferencias en la clasificación de búsqueda principal.
- Si no se registran datos de filtros en los eventos, también se limita la capacidad de analizar las métricas de rendimiento segmentadas por el uso de filtros, lo que afecta a las estadísticas de medición.
- Para entrenar modelos, la información de los filtros en los eventos de búsqueda es fundamental para entrenar modelos de facetas dinámicas, ya que el modelo aprende la popularidad de las facetas a partir de las señales de uso de los filtros de los usuarios.
- La información precisa sobre el uso de filtros en los eventos también es importante para los modelos de reclasificación basados en clics. Si los valores de los filtros de los eventos no coinciden con los de las solicitudes de búsqueda, el rendimiento del modelo en las consultas con filtros se verá afectado negativamente.
- Si los datos de los filtros de los eventos son incoherentes o faltan, la calidad del modelo se verá afectada en relación con las facetas dinámicas y la reclasificación de las consultas filtradas.
Descripción
- Esta comprobación consiste en examinar un recorrido de usuario de búsqueda específico vinculando un evento de búsqueda a su solicitud correspondiente de la API Search mediante el
attributionToken. - Vertex AI Search for commerce genera el token de atribución y lo devuelve con cada solicitud de búsqueda.
- Esta comprobación compara específicamente el campo
searchQuerydel evento de búsqueda con la cadena de consulta real enviada en la solicitud inicial a la API Search que devolvió el token de atribución. - Si estas cadenas de consulta no coinciden a pesar de que haya un token de atribución de vinculación, significa que la cadena de consulta de búsqueda que se envía en el evento de usuario no refleja con precisión la consulta de búsqueda original del usuario.
Impacto
- Este problema afecta en gran medida al entrenamiento del modelo.
- Vertex AI Search for commerce usa datos de eventos para entrenar sus modelos.
- Los modelos, sobre todo los de reordenación basados en clics, aprenden vinculando las interacciones de los usuarios (como los clics, las adiciones al carrito y las compras) a las solicitudes de búsqueda que generaron los resultados.
- Esta vinculación se basa en la información precisa de los eventos, incluidos los campos
searchQueryyattributionToken. - Si el
searchQuerydel evento no coincide con la consulta real de la solicitud de la API Search, el modelo se entrena con datos incorrectos, lo que asocia el comportamiento del usuario con la consulta equivocada. - Esto puede afectar negativamente a la calidad de los resultados de búsqueda, ya que el modelo aprende estrategias de clasificación subóptimas basadas en datos de consultas erróneos.
- Aunque el impacto principal se produce en la calidad del entrenamiento del modelo, también puede afectar indirectamente a la medición, ya que los modelos entrenados con datos incorrectos pueden tener un rendimiento deficiente, lo que puede dar lugar a resultados sesgados en las pruebas A/B, aunque los eventos se registren correctamente.
Descripción
- Esta comprobación es un proceso de validación manual en el que un tester simula el recorrido habitual de un usuario, que implica una secuencia de acciones como buscar, hacer clic en un producto (evento
detail-page-view), añadirlo al carrito y, posiblemente, hacer una compra. - Al registrar el ID de visitante y las marcas de tiempo de estas acciones, el tester recupera los eventos de usuario registrados para ese ID de visitante específico de los registros o las plataformas de datos.
- El objetivo es verificar que haya una correspondencia de uno a uno entre las acciones observadas de los usuarios y los eventos registrados en el sistema (por ejemplo, una acción de búsqueda debe generar un evento de búsqueda, un clic o un evento
detail-page-view). - Si faltan eventos, los IDs de visitante son incorrectos o los datos de los eventos están dañados (por ejemplo, faltan IDs de producto o de experimento), significa que hay problemas en el proceso de los eventos.
Impacto
- Los problemas identificados por esta comprobación afectan en gran medida tanto a la medición como al entrenamiento de modelos.
Medición
- Los eventos de usuario precisos y completos son fundamentales para calcular las métricas empresariales clave en una prueba A/B, como el porcentaje de clics de búsqueda, el porcentaje de conversión de búsqueda, el porcentaje de adiciones al carrito de búsqueda y los ingresos por visitante.
- Estas métricas se basan en la atribución del comportamiento de los usuarios (clics, adiciones al carrito y compras) a resultados de búsqueda y variantes de experimentos específicos.
- Si faltan eventos de un usuario o están dañados, sus acciones no se registran por completo, lo que provoca que estas métricas se calculen de forma incorrecta en la variante del experimento en la que se encontraba.
- Esto introduce sesgos y ruido, lo que hace que los resultados de la prueba A/B sean imprecisos y poco fiables para tomar decisiones. Por ejemplo, si faltan eventos de compra, se verán afectadas directamente las métricas de tasa de conversión y de incremento de los ingresos.
Preparación de modelos
- Los modelos de Vertex AI Search for commerce se entrenan exhaustivamente con datos de eventos de usuario para aprender patrones de comportamiento de los usuarios y optimizar la clasificación.
- Los IDs de visitante y de usuario son fundamentales para las funciones de personalización y para vincular eventos con el fin de crear ejemplos de entrenamiento.
- Si faltan eventos o están dañados, el modelo pierde señales de entrenamiento valiosas de la secuencia de interacciones de ese usuario. Por ejemplo, si faltan eventos de compra o de adición al carrito, el modelo no podrá saber qué interacciones con los productos han llevado a las conversiones.
- Del mismo modo, si faltan eventos de vista de página de detalles, el modelo no recibe señales sobre los clics. Esta reducción en la cantidad y la calidad de los datos de entrenamiento deteriora la capacidad del modelo para aprender de forma eficaz, lo que da lugar a una calidad deficiente de los resultados de búsqueda y puede anular las ventajas de usar un buscador basado en aprendizaje automático.
- Si la asignación o el formato del ID de visitante no son coherentes, también se puede interrumpir este proceso.
- Si faltan eventos de compra, el entrenamiento del modelo se verá afectado porque el modelo nunca verá compras.