Analytics Proposal

Analytics.md

Analytics Proposal

Overall

• The analytics system is its own app with its own repo and its own database.
• Eventually it could even have its own server, especially if disk space becomes an issue. But we'd start by deploying it on the prod server. A separate server would also be nice if we end up wanting to perform any analytics that turn out to be computationally intensive. A cheap VPS that's slow but has a big disk would be ideal.
• It has a REST interface to receive data
• No authentication at first, just don't expose it outside of localhost
• We could use whatever stack for this tiny thing, really. It might be a cool opportunity to try something new. Maybe you want to build it in Haskell or Rust? Personally, I'd consider trying Deno and Oak because I think Deno is eventually going to supplant Node, and Oak is the Deno equivalent of Express. But we could always just build it in Flask. I'm fine with anything here.
• Use Postgres
• Schema:
  • table: event
    • timestamp
    • type - string e.g. "quote", "compare", "druglookup", "cheatsheet", "signup", "cancellation"
    • user_id - ID of the user in the API's Postgres DB. Meaningless here, other than to uniquely group users.
    • device_info - JSON
    • details - JSON structured details about the event
• At first, don't build a way to inspect the data. Just use plain old SQL. Connect to the DB through an SSH tunnel. Store queries in .sql files within the repo. This means Joe wouldn't be able to run queries until we set up more of a UI. But the first priority is to start gathering data. The analytics won't be that interesting anyway until we have a decent time span.
• Search for a tool that will simplify the process of creating an analytics UI. Here are a couple off-hand that I can recall hearing about recently: POP SQL, Budibase. But there are loads of "Business Intelligence" software solutions out there. Probably lots of them are overkill for us. But we also don't want to make sure we don't dump our dev time into building an analytics system.

Front-end

• On /account/subscription/overview
  • When clicking "Suspend Subscription", open a modal window
    • Title: "Suspend Subscription"
    • Paragraph: "Sorry to see you go! We'd love to know why you're leaving and how we can improve our tools to better meet your needs. Please feel free to tell us a little more.
    • Text area (optional)
    • Two buttons at bottom: "Keep Subscription" and "Suspend Subscription"
    • On pressing suspend, send request to API with "reason" field
  • The "Resume Subscription" continues to operate immediately (no modal)
• Any time we send an API request to /quoter, pass a tool_name field (e.g. "quoter", "druglookup", etc) that will allow us to more easily distinguish between requests from the different tools.

API

• in general
  • When sending data to the analytics system, read the User-Agent HTTP header from the request the API received and put that value into the device_info field like { "userAgent": "...Mozilla..." }
• /payments/cancel
  • Receive additional reason field.
  • Send data to the analytics system, including the reason.
• /quoter
  • send data to analytics system, including the entire quote object.
• /quoter/compare
  • send data to analytics system, including the entire quote object.
  • Use the tool_name field to determine the type of the event (i.e. "quote" vs "druglookup")

Mobile

• Make sure that the User-Agent HTTP header identifies the mobile separately from requests made through a browser on the same device. Also make sure that it identifies iOS vs Android. Alter this header if necessary. If it's too hard to alter it, then set another header value or pass another param in the request body.