Service Portal Logs: Search logs not captured<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Issue: Service Portal Logs: Search logs not captured Steps to reproduce: 1. Search the term "software" for example.2. Check Service Portal Log Entries table, search does not track. Cause: Search terms will be logged in Search Events table for AI Search (sys_search_event_list.do). Additional info: How is the ts_query_kb table populated and what triggers record creation?The ts_query_kb table is populated through ServiceNow's internal search analytics aggregation processes, which summarize Knowledge Base search activity over time. Record creation is triggered when KB search data is processed and rolled up by scheduled analytics jobs, rather than at the moment an individual user performs a search. How does it differ from sys_search_event in terms of purpose and data granularity?The ts_query_kb table is designed for analytics and reporting, storing aggregated and summarized search data, while sys_search_event captures raw, individual search events each time a user performs a search. As a result, ts_query_kb offers lower granularity but better performance for reporting, whereas sys_search_event provides detailed transactional data. What does each field represent (e.g., query text, result count, user, timestamps, etc.)?Fields in ts_query_kb typically represent aggregated search characteristics, such as the query text, total or average result counts, frequency of searches, and time‑based reporting indicators (for example, daily or weekly buckets). User‑specific details are generally not stored at an individual level, as the table focuses on trend analysis rather than user auditing. Is ts_query_kb tied specifically to Knowledge Base searches only, or does it include broader search contexts?The ts_query_kb table is specific to Knowledge Base searches only and does not include data from global search, service catalog search, or record searches performed elsewhere in the platform. How should we interpret discrepancies between ts_query_kb and sys_search_event for the same query?Discrepancies between the two tables are expected because sys_search_event logs every individual search execution, while ts_query_kb contains filtered, aggregated data produced during scheduled analytics runs. Differences may also occur due to timing, data roll‑up logic, or non‑KB searches being excluded from ts_query_kb. Which table should be considered the authoritative source for search analytics?For search analytics, trend reporting, and dashboarding, ts_query_kb should be considered the authoritative source, as it is purpose‑built for these use cases. The sys_search_event table should be used primarily for detailed investigation, validation, or troubleshooting scenarios. Best practices for using these tables to analyze and improve the user search experience in PortalsBest practice is to use ts_query_kb to analyze top search terms, zero‑result queries, and usage trends to guide Knowledge Base improvements, while leveraging sys_search_event selectively for root‑cause analysis of specific issues. Reporting directly on sys_search_event should be avoided due to data volume and performance considerations, and insights from ts_query_kb should be used to optimize content, synonyms, and search relevance in portals.