UBI 索引模式
用户行为洞察 (UBI) 数据收集过程包括跟踪和记录用户提交的查询,以及监控和记录他们在收到搜索结果后的后续操作或事件。数据收集过程中涉及两种 UBI 索引模式:
关键标识符
为了 UBI 正常运行,在启用 UBI 的应用程序中,必须始终保持以下字段之间的连接:
object_id
表示用户响应查询所接收到的任何对象的 ID。例如,如果您搜索书籍,它可能是书籍的 ISBN 码,如978-3-16-148410-0
。query_id
是执行的原始查询语言和用户查询返回的“命中”的object_id
值的唯一 ID。client_id
表示一个唯一的查询源。这通常是唯一用户使用的网络浏览器。object_id_field
指定索引中提供object_id
的字段名称。例如,如果您搜索书籍,其值可能是isbn_code
。action_name
,虽然在技术上不是 ID,但它指定了对给定object_id
的对象执行(或未执行)的确切用户操作(例如click
、add_to_cart
、watch
、view
或purchase
)。
总而言之,query_id
标志着通过 client_id
跟踪的客户端的唯一搜索的开始。搜索返回各种对象,每个对象都有唯一的 object_id
。action_name
指定用户正在执行的操作,并与具有特定 object_id
的对象相关联。您可以通过检查 object_id_field
来区分不同类型的对象。
通常,您可以通过检索用户 client_id
的所有数据并检查单独的 query_id
数据来推断用户的整体搜索历史。每个应用程序通过检查后端数据来确定什么是搜索会话。
重要 UBI 角色
下图展示了**用户**与**搜索客户端**和**UBI 客户端**交互的过程,以及它们反过来如何与包含**UBI 事件**和**UBI 查询**索引的**OpenSearch 集群**进行交互。
蓝色箭头表示标准搜索,粗体虚线表示 UBI 特定的添加,红色箭头表示 query_id
进出 OpenSearch 的流程。
以下是关于这些角色的一些关键点:
- **搜索客户端**负责从 OpenSearch 文档索引搜索并接收**对象**(上图中的 1、2、**5** 和 7)。
步骤 **5** 加粗是因为它表示 UBI 特有的添加到标准 OpenSearch 交互中的内容,如 query_id
。
- 如果在搜索请求的
ext.ubi
段中激活,**用户行为洞察**插件会在后台管理 **UBI 查询**存储,索引每个查询,确保所有返回的object_id
值具有唯一的query_id
,然后将query_id
传回给**搜索客户端**,以便事件可以与查询链接(上图中的 3、4 和 **5**)。 - **对象**表示用户使用查询搜索的条目。激活 UBI 涉及将您的真实世界对象(使用其标识符,例如
isbn
或sku
)映射到被搜索索引中的object_id
字段。 - **搜索客户端**(如果与**UBI 客户端**分离)将已索引的
query_id
转发给**UBI 客户端**。尽管在此图中**搜索**和**UBI 事件索引**角色是分离的,但许多实现可以使用相同的 OpenSearch 客户端实例来执行这两个角色(上图中的 6)。 - **UBI 客户端**随后会使用指定的
query_id
索引所有用户事件,直到执行新的搜索。此时,**用户行为洞察**插件会生成一个新的query_id
并将其传回给 **UBI 客户端**。 - 如果**UBI 客户端**与结果**对象**进行交互,例如在**添加到购物车**事件期间,则
object_id
、add_to_cart
action_name
和query_id
都将被一起索引,表示**搜索**与**对象**之间的因果链接(上图中的 8 和 9)。
UBI 存储
支持 UBI 数据收集涉及两个独立的存储:
- UBI 查询
- UBI 事件
UBI 查询索引
所有底层查询信息和结果(object_ids
)都存储在 ubi_queries
索引中,并且大部分在后台保持不可见。
ubi_queries
索引模式包含以下字段:
-
timestamp
(事件和查询):一个 UNIX 时间戳,表示收到查询的时间。 -
query_id
(事件和查询):由客户端提供或自动生成的查询唯一 ID。相同文本的不同查询会生成不同的query_id
值。 -
client_id
(事件和查询):由客户端应用程序提供的用户/客户端 ID。 -
query_response_objects_ids
(查询):一个对象 ID 数组。ID 可以与_id
具有相同的值,但它旨在作为文档、项目或产品的外部有效 ID。
由于 UBI 管理 ubi_queries
索引,您通常无需直接写入此索引(导入数据时除外)。
UBI 事件索引
客户端直接将事件索引到 ubi_events
索引,将事件 action_name
、对象(每个都有一个 object_id
)和查询(每个都有一个 query_id
),以及任何其他重要的事件信息链接起来。由于此模式是动态的,您可以在索引时添加任何新的字段或结构(例如用户信息或地理位置信息),这些信息不在当前的**UBI 事件**模式中。
开发人员可以在 event_attributes
下定义新字段。
以下是 ubi_events
索引中预定义的最少字段:
application
(大小 100):跟踪 UBI 事件的应用程序名称(例如,amazon-shop
或ABC-microservice
)。
action_name
(大小 100):触发事件的操作名称。UBI 规范定义了一些常见的操作名称,但您可以使用任何名称。
query_id
(大小 100):查询的唯一标识符,通常是 UUID,但可以是任何字符串。query_id
由客户端提供或由 UBI 插件在索引时生成。**UBI 查询**和**UBI 事件**索引中的query_id
值必须保持一致。
-
client_id
:发出查询的客户端。这通常是唯一用户使用的网络浏览器。**UBI 查询**和**UBI 事件**索引中的client_id
必须保持一致。 -
timestamp
:事件发生的时间,可以是 UNIX 格式,也可以格式化为2018-11-13T20:20:39+00:00
。 -
message_type
(大小 100):用于对操作(每个都有一个action_name
)进行逻辑分组的“桶”。例如,QUERY
或CONVERSION
。 -
message
(大小 1,024):日志条目的可选文本消息。例如,对于message_type
为QUERY
,message
可以包含与用户搜索相关的文本。
event_attributes
:一个可扩展的结构,描述有关事件的重要上下文。此结构由两个主要结构组成:position
和object
。该结构是可扩展的,因此您可以添加有关事件的自定义信息,例如事件的时间、用户或会话。
由于 ubi_events
索引配置为执行动态映射,因此索引可能会因为许多新字段而变得臃肿。
-
event_attributes.position
:一个结构,包含有关事件源位置的信息,例如屏幕 x、y 坐标,或对象在结果列表中的位置。-
event_attributes.position.ordinal
:跟踪用户可以选择的列表位置(例如,选择第三个元素可以描述为event{onClick, results[4]}
)。 -
event_attributes.position.{x,y}
:跟踪客户端定义的 x 和 y 值。 -
event_attributes.position.page_depth
:跟踪结果的页面深度。 -
event_attributes.position.scroll_depth
:跟踪页面结果的滚动深度。 -
event_attributes.position.trail
:一个文本字段,跟踪用户到达此位置的路径/轨迹。
-
-
event_attributes.object
:包含由查询返回的对象的识别信息(例如,一本书、产品或帖子)。object
结构可以通过内部 ID 或对象 ID 引用该对象。object_id
是将先前查询链接到此对象的 ID。此字段包含以下子字段:-
event_attributes.object.internal_id
:OpenSearch 可用于内部索引对象的唯一 ID,例如索引中的_id
字段。 -
event_attributes.object.object_id
:用户可以在**文档语料库**中找到对象实例的 ID。示例包括ssn
、isbn
或ean
。变体需要包含在object_id
中,因此红色 T 恤的object_id
应该是其 SKU。初始化 UBI 需要将文档索引的主键映射到此object_id
。 -
event_attributes.object.object_id_field
:指示对象的类型/类别以及包含object_id
的搜索索引字段的名称。 -
event_attributes.object.description
:对象的可选描述。 -
event_attributes.object.object_detail
:有关对象的其他可选信息。 -
可扩展字段:请注意,
object
中任何新的索引字段都会动态扩展此模式。
-