Firefox/Input/Heartbeat

Heartbeat

(This is rough sketch. I need a template for doing this better.)

Summary

The telemetry experiments tool allows people to deploy add-ons to users based on user profile, version, OS, set sample rates, etc. We will be using this tool as a platform to deliver in-product polls that ask a for very simply happy/sad or star rating for a specified question. Gathering sentiment from our overall user base on a daily/weekly basis is what we are calling Firefox Heartbeat.

Status

Status: In-progress

History

• June 17th, 2014: Planning meeting conference call
• July 1st, 2014: Will talked with Gregg
  • Going to build a prototype which requires an addon and some infrastructure on Input to handle incoming data.
  • It'll be minimal so we can tweak it easily as we flesh things out.
• July 16th, 2014: Will started working on v1 implementation

Requirements

v1

Requirements:

1. API endpoint to capture specified data as JSON content
2. captured data is put into a db table that's specific to heartbeat
3. need to capture the following:
   • locale: the locale the user is using the product in (e.g. en-US)
   • platform: the operating system information (e.g. Windows 8)
   • product: the product name (e.g. Firefox)
   • version: the version (e.g. 33.0a1)
   • channel: the channel being used (e.g. beta)
   • poll_id: the id of the poll being used--this is a text field so we don't have to do work on both sides in order to start a new poll
   • answer: the answer the user gave (e.g. 1); for the most part this is an integer, but we're going to make this a text field to allow for different answer domains in the future
   • arbitrary additional contextual content

Anti-requirements:

1. don't need to provide a way to access the data on Input--people will pull it from the db
2. don't need to allow for multiple answers--all polls will be a single answer for now
3. this is a prototype to get all our ducks in a row--it doesn't need to be perfect and we expect to make it better for the next iteration

Will's thoughts:

1. Gregg asked for GET querystring params, but that has spam/abuse issues, so we're going to do POST content instead
2. we'll toss all the arbitrary additional contextual content into a JSON blob and stick it in an extra field in the db; this means we won't be able to easily query this via SQL, but we can extract it other ways and if this turns out to be a problem, we can redo the db structure

Bugs:

Full Query

ID	Summary	Priority	Status
1033419	build backend for heartbeat project prototype	P1	RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);