Firefox/Input/Heartbeat: Difference between revisions

updated HB project document
(Created page with "= 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 o...")
 
(updated HB project document)
Line 9: Line 9:
== Status ==
== Status ==


Status: In-progress
'''Status''': In-progress


== History ==
== History ==
Line 17: Line 17:
** Going to build a prototype which requires an addon and some infrastructure on Input to handle incoming data.
** 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.
** 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:
# API endpoint to capture specified data
# captured data is put into a db table that's specific to heartbeat
# need to capture the following:
#* '''locale''': the locale the user is using the product in (e.g. <tt>en-US</tt>)
#* '''platform''': the operating system information (e.g. <tt>Windows 8</tt>)
#* '''product''': the product name (e.g. <tt>Firefox</tt>)
#* '''version''': the version (e.g. <tt>33.0a1</tt>)
#* '''channel''': the channel being used (e.g. <tt>beta</tt>)
#* '''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. <tt>1</tt>); 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
# Gregg prefers the data be passed via GET querystring params
Anti-requirements:
# don't need to provide a way to access the data on Input--people will pull it from the db
# don't need to allow for multiple answers--all polls will be a single answer for now
# 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:
# we'll do GET querystring params for now, but probably change it in the near future
# 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:
<bugzilla>
    {
        "id": "1033419"
    }
</bugzilla>
Confirmed users
539

edits