Apply HN: IoQS – Message-based service to measure and track anything | Hacker News Reader

Apply HN: IoQS – Message-based service to measure and track anything

3 pointsgraeham6 comments

IoQS is a general case of internet of things, to make quantified self easier. (Name is a blend of the two: Internet of Quantified Self)

Our service accepts tagged messages from users, where the tag applies data in the message to a category. Users can configure alerts from the service to be sent to them as reminders to send in data.

Sample use case: instead of a bluetooth or wifi connected bathroom scale that sends weights to a remote database, IoQS reminds the user every morning to weight themselves and message the result to the service. Reminders help build habits, and the user doesn't need new hardware to collect data.

This lets users measure things that are subjective or are hard to measure - such as mood, food eaten, time spent in various activities. Being a general case, the user can choose to measure whatever is important to them. Such things can change with time, and this lets users experiment without having to purchase expensive hardware they may only use for a few weeks.

Once the data from an IoQS message is in the cloud, there are many possibilities for comparison with other data sources, graphing, and forming insights for the user. Data can be shared for friendly competition, or possibly with a doctor for medically-relevant tracking.

We've got a prototype in private beta using SMS messages for the reminders and user-entered messages. Thinking of building native-apps next to lower text fees, but started with SMS to make it platform independent.

Looking forward to feedback, questions, or opportunities!

I think I get the idea and it seems reasonable. I'm curious about the use cases. It's basically a remote interface for a spreadsheet or, more abstractly, an array of key:value pairs.

The thing is, that's kind of a constrained interface. It's rare to track only one value at a time. Normally you want to track either sets of values (EX: how many grams protein, fat, carbs) or at least multiple individual values (EX: calories, weight, sleep).

So if there's nothing new about the data store (IE: just a spreadsheet on a server) and there's nothing new about the data (IE: just calories or mood or whatever) then the new part is the interface. Instead of firing up an entire application you do the exact opposite; ping one or two simple codes.

But, like, what do YOU add? Is there no other service that accepts brief messages from any registered phone/email and tracks the values over time? Is that filling a hole? Maybe if there is a hole you could build a platform that performs that function for anything. Individuals could use it for data like weight, businesses could use it for logging business things.

For example, I currently use google docs to track this kind of information. I just open a spreadsheet, plug in my values, and they're automatically saved "to the cloud." Normally I don't even close the sheet; I just leave it open for weeks at a stretch. I doubt it takes fewer clicks to enter a single value into an already-open sheet than to send a text message. However, it does mean if I want to review the data, or rearrange it, or add another column, or backdate something, I've already got the appropriate interface open.

IoQS would work for people who don't have a smartphone...but is there a lot of overlap between people who have an old phone and people who want to track quantified self data?

Sorry for the slow reply, thought I was so far down the list people wouldn't be seeing it.

First - thanks for the feedback and discussion. Really useful insights.

You are correct in that the interface is the 'new' - and also that single codes are a poor way of input. The original reason for SMS was to interupt the user to actually get them to make a measurement. I've since changed that the interupt still comes as a message, but the input/logging is done through a full application. It also means that the application is more accessable for reviewing data, making changes, processing, etc - as you mention is an advantage for simple spreadsheets.

The advantage over a spreadsheet is trading some 'freedom' for easier analytics. I'm wanting to make quantified self more accessible for people without the skills (or maybe interest) to do data processing themselves.

Agreed that having a smartphone is probably a good assumption for the market.

> IoQS reminds the user every morning to weight themselves and message the result to the service

You're quickly going to burn your users out with incessant notifications. They'll actually train themselves to ignore the notifications until eventually uninstalling your app out of frustration. How will you avoid this?

Definately can be a problem. What I've found helps is encouraging new users to actually not set too many reminders, to avoid burnoit when novelty wears off. Secondly is to allow individual sets notifications to be disabled easily to avoid removing/ disusing the whole app. Thanks for question!

Edit: also, the service allows a default 'no reply' to be set, so if the reminder is ignored, there is still data entered. For the weight example, the default could be the previous days weight. This makes ignoring a reminder potentially into a positive, time saving behaviour for the user.

How does the user's mood get measured, tagged and messaged to the backend?

What is the role of user data in the business model?

Mood would be self-reported, then the tag and message is sent by the user.

I've been thinking about business models. Data privacy and control by the user is important to me. I see the service as being something that users may want to put quite personal information into, so I think it's important for the user to trust the service.

My preference would be towards a business model where the user also values the protection of their data, and pays directly for the service rather than through their data being sold to a 3rd party. That said, I do also see a role for using aggregated, non-identifiable data as part of the business model, or acting as a middle man where a commission is taken for brokering data from the user to a 3rd party.

Reply on news.ycombinator.com