# OpenSearch Community Meeting - 2024-0130 **URL:** \ **Category:** Community\ **Tags:** community-meeting\ **Created:** [December 29, 2023, 6:59pm UTC](https://forum.opensearch.org/t/opensearch-community-meeting-2024-0130/17282 "2023-12-29T18:59:44Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![kris](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/kris/32/2208_2.png) [@kris](https://forum.opensearch.org/u/kris)\ **Post date:** [December 29, 2023, 6:59pm UTC](https://forum.opensearch.org/t/opensearch-community-meeting-2024-0130/17282/1 "2023-12-29T18:59:44Z")
[OpenSearch Community Meeting - 2024-0130](https://forum.opensearch.org/t/opensearch-community-meeting-2024-0130/17282) - Hope we see you all there! Agenda: - User Behavior Logging (UBL) - [RFC available](https://github.com/opensearch-project/OpenSearch/issues/4619) - @macrakis & Eric Pugh (OSC) - Documentation feedback: [New documentation home page design - request for feedback](https://forum.opensearch.org/t/new-documentation-home-page-design-request-for-feedback/17420) - @hdhalter **Date:** Tue, January 30, 2024 **Time:** 08:00 AM PT (UTC -7) [Event page](https://opensearch.org/events/2024-0130-community-meeting/) [Meetup page](https://www.meetup.com/opensearch/events/298210906/) [Meeting Link](https://us02web.zoom.us/j/89425352972) Meeting ID: 894 2535 2972 Passcode: 239444 Would you like to present? Tag @kris @dtaivpp @nateynate and we’ll work to get you added to the agenda! Feel free to comment on this agenda before the meeting if you want to add an item or have a question. After the meeting, we will post the chat log and any meeting notes. We welcome you to keep the conversation going here on the forum. ======== _By joining the OpenSearch Community Meeting, you grant OpenSearch, and our affiliates the right to record, film, photograph, and capture your voice and image during the OpenSearch Community Meeting (the “Recordings”). You grant to us an irrevocable, nonexclusive, perpetual, worldwide, royalty-free right and license to use, reproduce, modify, distribute, and translate, for any purpose, all or any part of the Recordings and Your Materials. For example, we may distribute Recordings or snippets of Recordings via our social media outlets._ ---
**Author:** ![kris](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/kris/32/2208_2.png) [@kris](https://forum.opensearch.org/u/kris)\ **Post date:** [January 26, 2024, 3:03pm UTC](https://forum.opensearch.org/t/opensearch-community-meeting-2024-0130/17282/2 "2024-01-26T15:03:44Z")
---
**Author:** ![kris](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/kris/32/2208_2.png) [@kris](https://forum.opensearch.org/u/kris)\ **Post date:** [January 30, 2024, 6:19pm UTC](https://forum.opensearch.org/t/opensearch-community-meeting-2024-0130/17282/3 "2024-01-30T18:19:51Z")
Chat log: 08:05:50 From Kris Freedain to Everyone: Proposal: Process for moving/delaying a release Comments please: [Update RELEASING.md by mashah · Pull Request #184 · opensearch-project/.github · GitHub](https://github.com/opensearch-project/.github/pull/184#partial-pull-merging) 08:06:07 From Kris Freedain to Everyone: Blog: Continued performance progress [An update on the OpenSearch Project’s continued performance progress through version 2.11 · OpenSearch](https://opensearch.org/blog/opensearch-performance-improvements/) Blog: AI and machine learning: Recapping 2023 and what’s next [OpenSearch AI and machine learning: Recapping 2023 and what’s next · OpenSearch](https://opensearch.org/blog/opensearch-ai-retrospective/) 08:07:22 From Kris Freedain to Everyone: •User Behavior Logging (UBL) with Stavros Macrakis & Eric Pugh •[RFC] Search User Behavior Logging and Data Reuse for Relevance 08:09:27 From Kris Freedain to Everyone: We would love to get feedback on the RFC Mark Cohen has written on this. Thanks in advance 08:10:19 From Kris Freedain to Everyone: Hey Jeff! 08:10:48 From Jeff Zemerick to Everyone: Hi! 08:11:46 From Eric Pugh to Everyone: [[RFC] User Behavior Logging and Insights · Issue #12084 · opensearch-project/OpenSearch · GitHub](https://github.com/opensearch-project/OpenSearch/issues/12084) 08:12:14 From Mark Cohen to Everyone: I’m going to close 4619 to reduce confusion. 08:12:19 From Kris Freedain to Everyone: Reacted to “I’m going to close 4…” with 👍🏻 08:18:03 From Mark Cohen to Everyone: User Behavior Macrakis? 08:19:15 From Kris Freedain to Everyone: Hahha, was about to type that Eric - Loggy McLogface 08:19:19 From Widdis, Daniel (Dan) to Everyone: haBIT (high accuracy Behavior Information Tracking) 08:19:57 From Mark Cohen to Everyone: Is this an open board for us to add notes to? 08:20:44 From Kris Freedain to Everyone: [OpenSearch](https://opensearch.org/codeofconduct.html) 08:24:13 From Stavros Macrakis to Everyone: PughCollect 08:25:07 From Jason Robinson to Everyone: PughLog 08:26:46 From Ryan Paras to Everyone: have you been working with the folks working on ss4o in regards to standard schema? 08:29:25 From Jason Robinson to Everyone: [Simple Schema for Observability - OpenSearch Documentation](https://opensearch.org/docs/latest/observing-your-data/ss4o/) 08:32:29 From Mark Cohen to Everyone: [Search Backlog & Triage Meeting , Wed, Jan 31, 2024, 9:00 AM | Meetup](https://www.meetup.com/opensearch/events/298411948/) 08:33:02 From Eric Pugh to Everyone: Hi heather! We met at OpenSearch Con, and I learned about Vale! 08:33:28 From Kris Freedain to Everyone: •Documentation feedback with Heather Halter •New documentation home page design - request for feedback 08:38:39 From Amitai Stern to Everyone: We could use some app that analyzes user behavior to know when they found what they were searching for… @Eric Pugh ? 08:38:49 From Kris Freedain to Everyone: Reacted to “We could use some ap…” with 👍🏻 08:40:28 From Eric Pugh to Everyone: Reacted to “We could use some ap…” with 👍🏻 08:42:42 From Kris Freedain to Everyone: Feedback please [New documentation home page design - request for feedback](https://forum.opensearch.org/t/new-documentation-home-page-design-request-for-feedback/17420) 08:43:56 From Amitai Stern to Everyone: FLOOP 08:47:47 From Andriy Redko to Everyone: Thank you folks! ---
**Author:** ![kris](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/kris/32/2208_2.png) [@kris](https://forum.opensearch.org/u/kris)\ **Post date:** [January 30, 2024, 6:23pm UTC](https://forum.opensearch.org/t/opensearch-community-meeting-2024-0130/17282/4 "2024-01-30T18:23:43Z")
![Slide1](https://us1.discourse-cdn.com/flex019/uploads/mauve_hedgehog/original/2X/a/ac5716efa7159f28fb9a54a489a818fe91ddb8b6.png) ![Slide4](https://us1.discourse-cdn.com/flex019/uploads/mauve_hedgehog/original/2X/0/09688dced7d92fa47504eb8163100c91cb59b815.png) > > > Proposed an update to create a process with involvement from the leadership comm…ittee for moving the release date. > > \### Description > See above. > > \### Issues Resolved > See above. > **[An update on the OpenSearch Project’s continued performance progress through...](https://opensearch.org/blog/opensearch-performance-improvements/)** > > OpenSearch is a community-driven, Apache 2.0-licensed open source search and analytics suite that makes it easy to ingest, search, visualize, and analyze data. > **[OpenSearch AI and machine learning: Recapping 2023 and what’s next](https://opensearch.org/blog/opensearch-ai-retrospective/)** > > OpenSearch is a community-driven, Apache 2.0-licensed open source search and analytics suite that makes it easy to ingest, search, visualize, and analyze data. ![Slide5](https://us1.discourse-cdn.com/flex019/uploads/mauve_hedgehog/original/2X/2/28db7eb9b970689d7730c8084fb53383bda9797d.png) > > > \## What/Why > \### What are you proposing? > Currently, there is no way for users o…f OpenSearch to get a full picture of how search is being used without building their own logging and metrics collection system. This is a request for comments to the community to discuss needs for a standardized logging schema & collection mechanism. We want to work with the community to understand where we can make the most impactful improvements to help the most users in understanding how search is used in their applications and how they can tune results most effectively. > > We believe that application builders using OpenSearch for e-commerce, product, and document based search have a common set of needs in how they collect and expose data for analytics and reuse. Regarding analytics, we believe builders, business users, and relevance engineers want to see metrics out of the box for any search application like top queries, top queries resulting in a high value action (HVA - like a purchase, stream, download, or whatever the builder defines), top queries with zero results, top abandoned queries, as well as more advanced analytics like similar queries in the long tail that may be helped by synonyms, query rewrites/expansion or other relevance tuning techniques. This same data can also be re-used to feed manual judgement and automated learning to improve relevance in the index. > > > > > \### What users have asked for this feature? > \_Highlight any research, proposals, requests or anecdotes that signal this is the right thing to build. Include links to GitHub Issues, Forums, Stack Overflow, Twitter, Etc\_ > > \### What problems are you trying to solve? > Template: When \\\ , a \\\ wants to \\\, so they can \\\. (Example: When \*\*searching by postal code\*\*, \*\*a buyer\*\* wants to \*\*be required to enter a valid code\*\* so they \*\*don’t waste time searching for a clearly invalid postal code.\*\*)\_ > > \* When any search results are returned, search application builders want to report on the top requested queries so that they can learn about what their users intend to find. > \* When users search for content, a search relevance engineer wants to feed behavioral data back into the search system for automatic reranking. > \* When users search for content, a search relevance engineer wants to feed behavioral data back into the search system for manual tuning of search results. > > \### What is the developer experience going to be? > \_Does this have a REST API? If so, please describe the API and any impact it may have to existing APIs. In a brief summary (not a spec), highlight what new REST APIs or changes to REST APIs are planned. as well as any other API, CLI or Configuration changes that are planned as part of this feature.\_ > > \* Allow the user to submit an optional field containing the original, user typed query. Track that original query through all steps of querying the index: user typed 1) query -\> 2) rewritten query -\> 3) results from OpenSearch -\> 4) reranked results outside of OpenSearch -\> 5) actions taken by the end users (query again, abandon search, some other high value action). > \* Initially, we are focused on adoption so even if we started from the inside out with #2 and #3 above, it would be helpful. The API change would be providing a place in the query DSL to optionally submit the original query. We could build that in as well, but only include it in logging and analysis if it is there. > > > \#### Are there any security considerations? > \_Describe if the feature has any security considerations or impact. What is the security model of the new APIs? Features should be integrated into the OpenSearch security suite and so if they are not, we should highlight the reasons here.\_ > \* New data will be logged inside OpenSearch. Possible injection attacks could occur. > > \#### Are there any breaking changes to the API > \_If this feature will require breaking changes to any APIs, ouline what those are and why they are needed. What is the path to minimizing impact? (example, add new API and deprecate the old one)\_ > > > \### What is the user experience going to be? > \_Describe the feature requirements and or user stories. You may include low-fidelity sketches, wireframes, APIs stubs, or other examples of how a user would use the feature via CLI, OpenSearch Dashboards, REST API, etc. Using a bulleted list or simple diagrams to outline features is okay. If this is net new functionality, call this out as well.\_ > > > \#### Are there breaking changes to the User Experience? > \_Will this change the existing user experience? Will this be a breaking change from a user flow or user experience perspective?\_ > \* No breaking changes > > \### Why should it be built? Any reason not to? > \_Describe the value that this feature will bring to the OpenSearch community, as well as what impact it has if it isn't built, or new risks if it is. Highlight opportunities for additional research.\_ > \* Building this feature will standardize a set of reporting and data collection needs that are common across search applications and allow software engineers and relevance engineers to focus on higher level concerns out of the box like tuning queries, query rewriting, synonyms, and results reranking. > \* If it isn't built, users will either have no insights into search results and how to tune them, they will keep building analytics and data collection applications without getting an understanding of what is happening inside OpenSearch. > \* If it is built, one technical concern is trade offs between adding latency to OpenSearch and adding complexity to the platform. Logging every request and each step like rewrites, results returned from the index, reranking, and HVAs could have impact on an OpenSearch cluster if we decide to do all of this in OpenSearch. On the other hand adding a whole new set of infrastructure to deal with this level of data collection, even with a separate OpenSearch cluster adds complexity to the architecture. > > \### What will it take to execute? > \_Describe what it will take to build this feature. Are there any assumptions you may be making that could limit scope or add limitations? Are there performance, cost, or technical constraints that may impact the user experience? Does this feature depend on other feature work? What additional risks are there?\_ > > \### Any remaining open questions? > \_What are known enhancements to this feature? Any enhancements that may be out of scope but that we will want to track long term? List any other open questions that may need to be answered before proceeding with an implementation.\_ > \#### Questions for the Community > \* Do you have first (homegrown) or third party analytics tools like Google Analytics, Adobe, or others? Would it make sense for us to connect the logging and metrics we propose to deliver inside OpenSearch with the clickstream/application metrics you have in those other systems? > > > \#### Review & Validate this Proposal for tracking data through OpenSearch: https://github.com/opensearch-project/search-relevance/issues/12 > > > \# What/Why > > This RFC is an evolution of \[4619\](https://github.com/opensearch-p…roject/OpenSearch/issues/4619) to capture user behaviors and track queries through all steps of querying and website usage. > > In this RFC we are proposing to develop tooling that can be integrated with OpenSearch to collect application user behavior and store the behavior metrics in OpenSearch indices. Additionally, we are proposing to build an analytics dashboard integrated with OpenSearch Dashboards to provide the ability to analyze and visualize the collected metrics. > > This capability will be able to link client-side actions with backend search actions, such as linking queries submitted by users with customer clients, scroll depth, and search result detail pages viewed. This is not a full list of events that will be captured and we welcome the community’s input on what events are important to your search relevance understanding. > > \## What users have asked for this feature? > > This functionality has been discussed on the OpenSearch Search Relevance Meetup and through individual conversations with users of OpenSearch and with the larger community. > > \## What problems are you trying to solve? > > The key problem being addressed is giving OpenSearch users the ability to have a holistic view of client-side, browser and app events to enable a deeper understanding of search user behavior for the purposes of improving search relevance and user experience. > > With this tooling, users of OpenSearch will be able to collect client-side events and link them with queries from their data stores. This will allow users to create a comprehensive view of users’ search journeys to improve the user experience. > > \## What is the developer experience going to be? > > Our initial plan is to develop an OpenSearch plugin that exposes REST endpoints for the purposes of indexing events and managing the backend event stores. We also plan to build a client-side library to connect to and log to OpenSearch, so that a developer can link the logging to any common framework that tracks javascript events. > > We plan to research currently available open source libraries under acceptable licenses that we can either utilize directly or customize to meet our needs. > > We plan to “program to the interface” to permit future extensibility. For instance, we plan to store event data in OpenSearch, but do not want to restrict someone from creating the ability to use a relational database as the backend instead. > > The development plan may and is likely to evolve over time. We are going to prioritize using existing open source code where possible and applying existing standards to avoid reinventing the wheel whenever possible. > > A high-level, preliminary design of the proposed plugin is shown below: > > \## Are there any security considerations? > > Event data will be sent to OpenSearch for indexing and all communication needs to be over secure channels. > The client-side event capturing code must behave ethically and only track user activity when permitted. > Strict security parameters and constraints must be in place to connect the client code to the backend OpenSearch logging engine. > > The community’s input around these items will be vital during development. > > \## Are there any breaking changes to the API? > > No breaking changes to the API are expected. > > \# What is the user experience going to be? > > The user will be able to analyze the collected events via a dashboard that is integrated with OpenSearch Dashboards. This functionality will likely be implemented as a its own OpenSearch Dashboards plugin or integrated into the OpenSearch \[dashboards-search-relevance\](https://github.com/opensearch-project/dashboards-search-relevance) plugin. > > The data will be queryable using SQL and/or DSL, and be exportable to an external data store for additional analysis or training machine learning models. > > \## Are there breaking changes to the User Experience? > > No breaking changes to the user experience are expected. > > \## How is this different from other applications? > > We lean on OpenSearch’s ability to log and analyze data, while leaving the client developer free to choose whichever javascript library they want, such as Snowplow, etc. > > This will provide a stronger “out of the box” search analytics focus than more general tools. > > We have a stretch goal of being near real time for event tracking, with an eye to being able to provide data for personalization as the user is engaging with the search experience. We want to be able to learn about an individual's preferences, not just focus on aggregated user preferences. > [@New documentation home page design - request for feedback](https://forum.opensearch.org/t/new-documentation-home-page-design-request-for-feedback/17420): > > Hi all, we’ve recently updated our documentation home page and are looking for feedback. We’ve separated the Data Prepper, OpenSearch Benchmark, and Clients content from OpenSearch and OpenSearch Dashboards because their content follows a different versioning sequence. For this initial iteration, we wanted to keep it simple by presenting the four options. But we want to know what you think: is there information that we should include on the home page that would make it easier to find what you’re… ---
**Author:** ![kris](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/kris/32/2208_2.png) [@kris](https://forum.opensearch.org/u/kris)\ **Post date:** [January 30, 2024, 6:24pm UTC](https://forum.opensearch.org/t/opensearch-community-meeting-2024-0130/17282/5 "2024-01-30T18:24:55Z")
---
**Author:** ![kris](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.opensearch.org/kris/32/2208_2.png) [@kris](https://forum.opensearch.org/u/kris)\ **Post date:** [February 1, 2024, 8:58pm UTC](https://forum.opensearch.org/t/opensearch-community-meeting-2024-0130/17282/6 "2024-02-01T20:58:26Z")
[![](https://us1.discourse-cdn.com/flex019/uploads/mauve_hedgehog/original/2X/b/b5b32030d45f4bf63ec0902645c3302232536d98.jpeg "OpenSearch Community Meeting January 30, 2024") ](https://www.youtube.com/watch?v=7p0ri3isSbg)