# Context
We want to measure query federation in the Wikibase ecosystem to be able to evaluate the success of our initiatives focused on improving it. See details in [the main doc](https://docs.google.com/document/d/1BssreulTHIZvYEys_NChtIjgYTe0v0YbRvRnAiLalqw/edit?tab=t.0#heading=h.6y2qhme44d4).
We are currently looking for a metric that could be used that is 1) easiest to measure, 2) provides meaningful insights that can drive our work.
One of the approaches we decided to explore is measuring on the Query Service backend.
+: On Wikidata QS, some instrumentation already exists to analyze query logs and place them into a dataset discovery.processed_external_sparql_query
+: We see even queries that started outside of our UIs
-: The results will only be reliable if we are able to de-duplicate queries in the ecosystem: a single query that ended up in N subqueries going across the ecosystem should only be counted once, otherwise, our metric won't be useful. For this reason, it's important to differentiate between the 'original' query that is being coordinated by the given backend, and the subqueries that it is executing on behalf of another endpoint.
# Task
Measure:
* A: # of **federated** queries that are coordinated on a specific WD/WBQS backend in the last day/week/month
* B: # of **non-federated** queries that are coordinated on this WD/WBQS backend in the last day/week/month
Our metric is A/(A+B).
# Acceptance Criteria
1. No dashboard required at this point, but we should be able to run this measurement ad hoc for a given WD/WBQS backend to get the measurement.
2. For WBQS backend on Cloud, we should be able to get measurements for all running Wikibases separately.
# Notes
1. To differentiate between 'original' queries and subqueries, we could try looking at the Useragent or other metadata attached to the query. If it came from another SPARQL endpoint - this is a subquery and should not be counted towards A or B; otherwise, it is an 'original' query.
2. The PrPL team is already doing segmentation of queries on WDQS for their purposes (although, they are classifying them according to different criteria). Please get in touch with them to make use of existing groundwork where possible. See details in [GitLab](https://gitlab.wikimedia.org/repos/wmde/analytics/-/blob/main/tasks/product_platform/2025/T386342_wdqs_query_segmentation_dataset/T386342_wdqs_query_segmentation_dataset.ipynb)
3. Some useful information can be found in the recommendations from the Search team here: T391383