> ## Documentation Index
> Fetch the complete documentation index at: https://doc.lucidworks.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Signals data flow
export const LwTemplate = ({title = "Key questions to get you started", icon = "sparkles", cta = "Powered by Agent Studio", linkHref = "https://lucidworks.com/demo/?utm_source=docs&utm_medium=referral&utm_campaign=docs_cta_ai"}) => {
const [isLoaded, setIsLoaded] = useState(false);
useEffect(() => {
const timer = setTimeout(() => {
setIsLoaded(true);
}, 500);
return () => clearTimeout(timer);
}, []);
return
{isLoaded && `
}} />}
Powered by Lucidworks Agent Studio
;
};
[localhost link]: http://localhost:3000/docs/lucidworks-search/07-improve-your-queries/signals/signals-data-flow
[mintlify link]: https://doc.lucidworks.com/docs/lucidworks-search/07-improve-your-queries/signals/signals-data-flow
[old doc.lw link]: https://doc.lucidworks.com/managed-fusion/5.9/mrne8z
This diagram shows the flow of signals data from the search app through Lucidworks Search. The numbered steps are explained below.
1. The search app sends a query to a Lucidworks Search query pipeline.\
The query request should include a user ID and session query parameter to identify the user.
2. Optionally, the Lucidworks Search query pipeline queries the `COLLECTION_NAME_signals_aggr` collection to get boosts for the main query based on aggregated click data.
3. The search app also sends a request signal to the Lucidworks Search [`/signals` endpoint](/api-reference/signal-indexing-api/index-an-event-signal).\
The primary intent of a request signal is to capture the raw user query and contextual information about the user’s current activity in the app, such as the user agent and the page where they generated the query. The request signal does not contain any information about the results sent to Solr; it is created before a query is processed.
4. Once Solr returns the response to Lucidworks Search, the SearchLogger component indexes the complete request/response data into the `COLLECTION_NAME_signals` collection as a response signal using the `_signals_ingest` pipeline. Therefore, the response signal captures all results from Lucidworks Search as it related to the original query.
Query activity is not indexed into the `_logs` collection. All response signals use the `fusion_query_id` (see below) as the unique document ID in Solr.
5. When the user clicks a link in the search results, the search app sends a click event to the Lucidworks Search signals endpoint (which invokes the `_signals_ingest` pipeline behind the scenes).\
The click signal *must* include a field named `fusion_query_id` in the `params` object of the raw click signal. The `fusion_query_id` field is returned in the query response (from step 1) in a response header named `x-fusion-query-id`. This allows Lucidworks Search to associate a click signal with the response signal generated in step 4. The `fusion_query_id` is also used by Lucidworks Search to associate click signals with [experiments](/docs/lucidworks-search/06-metrics-and-analytics/experiments). For experiments to work, each click signal must contain the corresponding `fusion_query_id` that produced the document/item that was clicked.
6. The `_signals_ingest` pipeline enriches signals before indexing into the `COLLECTION_NAME_signals` collection.\
This enrichment includes field mapping, geolocation resolution, and updating the `has_clicks` flag to "true" on request signals when the first click signal is encountered for a given request using the [Update Related Document index stage](/docs/lucidworks-search/09-developer-documentation/config-specs/index-pipeline-stages/update-related-document).
7. Lucidworks Search queries the `COLLECTION_NAME_signals` collection through a Lucidworks Search query pipeline to generate query analytics reports from raw signals.
8. Behind the scenes, the [SQL aggregation](/docs/lucidworks-search/09-developer-documentation/config-specs/jobs/sql-aggregation/overview) framework aggregates click signals to compute a weight for each query + `doc_id` + filters group.\
The resulting metrics are saved to the `COLLECTION_NAME_signals_aggr` collection to generate boosts on queries to the main collection (step 2 above).
9. Recommendations also use aggregated documents in the `COLLECTION_NAME_signals_aggr` collection to build a [collaborative filtering-based recommender model](/docs/lucidworks-search/07-improve-your-queries/recommendations/methods-recs).
1. The search app sends a query to a Lucidworks Search query pipeline.\
The query request should include a user ID and session query parameter to identify the user.
2. Optionally, the Lucidworks Search query pipeline queries the `COLLECTION_NAME_signals_aggr` collection to get boosts for the main query based on aggregated click data.
3. The search app also sends a request signal to the Lucidworks Search [`/signals` endpoint](/api-reference/signal-indexing-api/index-an-event-signal).\
The primary intent of a request signal is to capture the raw user query and contextual information about the user’s current activity in the app, such as the user agent and the page where they generated the query. The request signal does not contain any information about the results sent to Solr; it is created before a query is processed.
4. Once Solr returns the response to Lucidworks Search, the SearchLogger component indexes the complete request/response data into the `COLLECTION_NAME_signals` collection as a response signal using the `_signals_ingest` pipeline. Therefore, the response signal captures all results from Lucidworks Search as it related to the original query.