We could make the new experience equally uncomfortable for both A and B, by uncaching the results in both cases. Not ideal, but at least would be apples to apples.
Kevin Smith Agile Coach, Wikimedia Foundation
On Wed, Aug 26, 2015 at 2:30 PM, Max Semenik maxsem.wiki@gmail.com wrote:
We couldn't come up with a solution when discussing this with Erik, hence this thread.
On Wed, Aug 26, 2015 at 2:11 PM, Dan Garry dgarry@wikimedia.org wrote:
Nice catch Max. Thanks for reporting it. Do you have any suggestions for how we could alleviate this issue?
Thanks, Dan
On 26 August 2015 at 13:30, Max Semenik maxsem.wiki@gmail.com wrote:
While doing CR for https://gerrit.wikimedia.org/r/#/c/232896/3/modules/ext.wikimediaEvents.sear... I came to have serious doubts about this approach.
In brief, it attempts to track user satisfaction with search results by measuring how long do people stay on pages. It does that by appending fromsearch=1 to links for 0.5% of users. However, this results in page views being uncached and thus increasing HTML load time by a factor of 4-5 and, consequentially, kicking even short pages' first paint outside of comfort zone of 1 second - and that's measured from the office, with ping of 2-3 ms to ulsfo. My concern here is that as a result we're trying to measure the very metric we're screwing with, resulting in experiment being inaccurate.
Can we come up with a way of measurement that's less intrusive or alter the requirements of the experiment?
-- Best regards, Max Semenik ([[User:MaxSem]])
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
-- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
-- Best regards, Max Semenik ([[User:MaxSem]])
Wikimedia-search mailing list Wikimedia-search@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimedia-search