Firefox/Input/Thank you page

From MozillaWiki
< Firefox‎ | Input
Revision as of 19:56, 13 July 2015 by Willkg (talk | contribs) (fix measurement equations, update status)
Jump to navigation Jump to search

Thank you page overhaul

Summary

When a user leaves feedback using one of the forms on the site, they are redirected to a "Thank you!" page. Currently, all users see the same page regardless of their sentiment or the contents of their feedback. This page isn't very helpful to anyone.

We see many different kinds of feedback, but there are three kinds of feedback that are interesting in regards to content on the "Thank you!" page:

  1. feedback from a user who is very happy with the product
  2. feedback that's about a problem that we have known solutions for
  3. feedback that's about a problem we need more information on

We want to do things for these groups of people. This project covers that work broken into several phases and experiments.

Status

History

  • Since the dawn of time: We've been talking about this and thinking about the kinds of things we could do and what would be most effective for users while simultaneously lamenting a complete lack of time to work on it.
  • May 8th, 2014: Will decided to put a bug on the books about this (https://bugzilla.mozilla.org/show_bug.cgi?id=1007840)
  • December 17th, 2014: Will wrote up this initial project plan.
  • March 9th, 2015: End of OPW. We've got some pieces done, but there's still a bunch left to do.
  • June 3rd, 2015: Landed the suggest framework and redirector.
  • June 10th, 2015: Pushed phase 1 to prod and made it live.

Phase 1: Completed

Summary

This phase will focus on Input feedback with the following criteria:

  1. en-US only
  2. Firefox browser product only
  3. sad feedback only
  4. require at least N words? (theory: fewer than N words will yield lousy search results from SUMO plus they're less likely asking about a problem.)

When this happens, the user will see a new version of the "Thank you!" page which will have 3 links of suggested SUMO kb articles and one "I'd like to ask a question" link which goes to SUMO AAQ.

Measuring success

Bug #1133774 covered figuring out what we want to measure and from that what we need to capture.

Question: Are we helping users?

This is essentially a question of engagement--are users clicking on the suggested links we've provided? To determine whether this is helping users, we need to find out whether users are clicking on the suggested links.

Then engagement is something like:

   clicked on at least one link
   ----------------------------
   total people offered a suggestion

Gregg was thinking that 20% engagement might be a good number to shoot for. If we end up with like 5% engagement, then maybe we're trying to solve a problem that doesn't exist or the heuristics generating the suggestions are sub-par.

Question: Does tailoring work? How attractive are the results?

We can figure this out by comparing:

   clicked on a suggested link
   ---------------------------
   total people offered a suggestion

vs.

   clicked on "None of these helped" link
   --------------------------------------
   total people offered a suggestion


We'll push events to Google Analytics and use the Event Flows view to measure these.

Requirements

  1. implement SUMO suggest provider which:
    1. looks at a feedback response and determines whether to generate suggested links or not
    2. generates a request against the SUMO Search Suggest API to retrieve relevant links
    3. returns relevant links wrapped in a redirector url
  2. implement SUMO suggest redirector which:
    1. handles SUMO suggest redirect links
    2. posts a GA event
    3. redirect the user to the outbound link
  3. new thank you page view and template to show suggested links
  4. tests for everything involved

Bugs

Tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1007840

Bugzilla query error

Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1


Phase 2

Localize strings and open this up to non-en-US locales.

Can we open this up to non-Firefox desktop products as well? Do we need a setting in the Product model regarding whether to ping SUMO for relevant links and which SUMO product to search?


Future phases

Future phases will be figured out after the most recent phase is completed so we have time to act on what we've learned.

Future phases may include:

  1. pulling solved questions (plus some other filters?) from SUMO?
  2. pulling a mix of solved questions (plus some other filters?) and KB articles from SUMO?
  3. get a kb article keyword -> article map for top 25 articles per locale and using that instead of doing lots of searches?