
Apply HN: IoQS – Message-based service to measure and track anything - graeham
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)<p>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.<p>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&#x27;t need new hardware to collect data.<p>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.<p>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.<p>We&#x27;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.<p>Looking forward to feedback, questions, or opportunities!
======
mpbm
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?

~~~
graeham
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.

------
buss
> 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?

~~~
graeham
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.

------
brudgers
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?

~~~
graeham
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.

