You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
During our research for #9293 it has become clear that we currently cannot make any changes to the offline freetext search experience without potentially affecting user workflows because we simply have no way to be sure how users are actually interacting with the freetext search (for both contacts and reports).
For example, in interviews with users, they mention searching by contact name. However, in practice we know that contact names are often de-normalized into various custom fields on both contacts and reports. So, simply indexing the name fields on contacts may not be enough to support user workflows. Most importantly, we just do not have any way to know the answer here one way or the other. The users, themselves, are probably not aware of the exact field structure on the documents they are searching for.
Describe the solution you'd like
One reason we are not currently collecting any search telemetry data is because it is likely that the search terms provided by the user will contain PII and we want to avoid logging PII in telemetry docs.
The proposal here is to add telemetry that is more holistically focused on the search workflow. Instead of merely logging what terms the user searches for, we want to focus on the whole process whereby a user searches for something and then actually selects ones of the filtered reports/contacts. Once a user chooses a report/contact to navigate to, we do a comparison between the contents of the report/contact with the user's search term and find the doc fields that were matched by the search query. Then we can log telemetry indicating a search happened (but do not include the exact search terms). Instead we can include information about the report/contact that the user ended up selecting and espeically the names of the doc fields that were matched by the search query. In this way, we avoid including PII in the telemetry, but can still construct an (imperfect) image of the kinds of things users are searching for....
Describe alternatives you've considered
Not collecting any telemetry means that any changes we make to offline freetext search functionality will be done without any way of realistically quantifying their impact.
OTOH, if we log PII in telemetry, it would make it more difficult to collect telemetry data from partners. Extra care must be taken when storing/transmitting this kind of info.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
During our research for #9293 it has become clear that we currently cannot make any changes to the offline freetext search experience without potentially affecting user workflows because we simply have no way to be sure how users are actually interacting with the freetext search (for both contacts and reports).
For example, in interviews with users, they mention searching by contact name. However, in practice we know that contact names are often de-normalized into various custom fields on both contacts and reports. So, simply indexing the
name
fields on contacts may not be enough to support user workflows. Most importantly, we just do not have any way to know the answer here one way or the other. The users, themselves, are probably not aware of the exact field structure on the documents they are searching for.Describe the solution you'd like
One reason we are not currently collecting any search telemetry data is because it is likely that the search terms provided by the user will contain PII and we want to avoid logging PII in telemetry docs.
The proposal here is to add telemetry that is more holistically focused on the search workflow. Instead of merely logging what terms the user searches for, we want to focus on the whole process whereby a user searches for something and then actually selects ones of the filtered reports/contacts. Once a user chooses a report/contact to navigate to, we do a comparison between the contents of the report/contact with the user's search term and find the doc fields that were matched by the search query. Then we can log telemetry indicating a search happened (but do not include the exact search terms). Instead we can include information about the report/contact that the user ended up selecting and espeically the names of the doc fields that were matched by the search query. In this way, we avoid including PII in the telemetry, but can still construct an (imperfect) image of the kinds of things users are searching for....
Describe alternatives you've considered
Not collecting any telemetry means that any changes we make to offline freetext search functionality will be done without any way of realistically quantifying their impact.
OTOH, if we log PII in telemetry, it would make it more difficult to collect telemetry data from partners. Extra care must be taken when storing/transmitting this kind of info.
The text was updated successfully, but these errors were encountered: