Wearable Device Integrations: Build or Buy?
Many prospective customers we talk to consider building their own direct wellness integrations as opposed to using our Wearable API. I’d like to propose the idea that there are very few cases where doing so is better and more cost effective (especially in the long run). Most of the time, you’re probably better off relying on a product like ours.
If you use Amazon Web Services or Microsoft Azure, then you already know the fundamental benefits of those platforms compared to operating your own “bare metal” servers. I’m writing this post with the hope of helping you understand how the Human API platform provides analogous benefits compared to building your own direct integrations.
As a product-led company, we apply product-first thinking to our problems. So, we understand the problems you’re trying to solve. One big question is where it’s best to focus your energy and attention on: building and maintaining integrations, or improving other aspects of your product?
After reading my post, I hope you’ll be able to answer that question and more.
Technical and Operational Considerations
So you’ve decided to build your own direct wellness integrations? Good for you! Since 2014, we’ve been operating one of the largest device data networks, and have acquired technical expertise in the space.
We learned by trial and error and adapting to unforeseen challenges. I’m hoping to share our hard-earned lessons so you can make an informed decision about the future of your product.
I’m writing about technical and operational processes, but keep in mind that there are also compliance considerations for organizing and storing data securely and staying up to date on requirements for protecting consumer data. As a vendor, we would handle security this for you, but if you choose to build your own integrations, you must factor in the costs and workload associated with ensuring security and compliance.
1. Building an authentication flow
It all starts with getting your device users to grant authorization to access data on their behalf.
This is probably the easiest part of the integration process. Most device platforms support standard OAuth or OAuth 2 with minor variations.
To get started:
You’ll have to open a developer account with the provider. For some, it’s easier said than done.
Providers have slightly different implementations of the oAuth standard.
The “scope” of the authorization is not standardized. Your application needs to handle this.
2. Syncing your users’ data
Once you can reliably get user authorization, you’ll have to retrieve data from the device source by querying their APIs. Building one API integration is pretty straightforward. However, it gets much more complex when you start to build many integrations, while keeping all the data synchronized for your users.
A few things you’ll have to do:
Retrieve access tokens, store and continuously refresh them
Query the data provider’s APIs without exceeding rate limits. This actually happens more often than you might think, because the first time a user connects their device, you may be pulling several years worth of data
Handle exceptions, such as troubleshooting when the data provider’s API is not responsive
There’s also a whole set of challenges that rise from regular syncing overtime:
Handling cases when the user revoked permissions to your app.
Implementing reliable re-sync through web hook notifications or polling the source at regular intervals. Some sources support one or the other, or both.
3. Designing and maintaining a consistent data model
This requires normalizing both schemas and values. Schemas differ and don't describe exactly the same things.
Understanding every provider’s data semantics and map them into your model
Normalizing values (e.g steps) that come in different units.
Normalizing dates which are localized in different timezones
Normalizing date stamps that are available in either epoch time or standard calendar formats
4. Building Aggregations and Summarizations
Aggregates provide more actionable insights than individual data points. Take sleep data, for example. Sleep is typically tracked as entries with a few seconds to a few minutes of granularity, and a sleep data feed is not very useful unless aggregated into daily summaries.
Most data sources have aggregation capabilities. However, they’re very specific to the manufacturer and aren’t consistent across the range of devices that your users will connect. In most cases, you’ll need to build your own aggregation layers above raw data feeds.
Things you need to consider when building summaries:
Reducing time series into individual values over multiple time scales (daily, weekly, etc.) can be computationally intensive. Think of implementing a sampling strategy very early and make sure you decouple the aggregation process from the data retrieval.
Coalescing data streams from multiple devices will involve normalizing units and time offsets.
Different devices may have a slightly different logic for interpreting measurements. This means deducing data points may involve a translation step.
5. Ongoing Maintenance
if you operate a non-trivial number of integrations, there is a 100% chance that at least one of them will introduce a breaking change over a 2-year period. For example, Withings introduced OAuth2, then retired OAuth1 in late 2018.
Moreover, vendors are constantly introducing new devices and new data types that could be of interest to you. For example, Fitbit introduced extended heart rate data when they released the Versa series.
How cost-effective is your process?
There's significant engineering effort involved in building, operating, and maintaining just 5 integrations. Based on my own experience, the level of effort (LOE) is about 26 hours/week per year on average for the first 2 years.
Keep in mind, this usually includes a 10% overhead for managing the whole operation. I’ve included a breakdown the LOE for a typical project below.
Engineering Effort
Designing a unified data model (4 hours/week)
Building authorization flows (4 hours/week)
Building API integrations (10 hours/week)
Normalizing and aggregating (10 hours/week)
Ongoing maintenance (20 hours/week)
Management overhead (10% of total effort or ~5 hours per week)
Total: ~ 48 hours/week
This estimate also assumes a frictionless path for your project, where you have perfect knowledge about the technologies and the platforms and avoid major pitfalls. Additionally, you will need to factor the cost of setting up and operating a HA infrastructure for data syncing.
What else?
Even if you build your own direct integrations, working with a vendor like us provides additional benefits that are only possible due to our level of scale and specialization.
Advantages of working with us:
We’ve been nurturing partnerships with manufacturers for years, so we have preferential SLAs (e.g. rate limits, support turnarounds). We also get early access to new features and devices.
We have acquired expertise about the space and the technology. We know what kind of data is available, how often, and when. We offer our expertise to support your use case.
We are constantly exploring the wellness landscape and planning our network expansion to maximize our footprint and data quality on your behalf.
Last, but not least, our data network also includes healthcare providers, pharmacies, labs and insurance networks, which are also available to you when you need them.
We maintain a technology infrastructure that supports security and privacy compliance that is consistent with what hospitals use to protect their healthcare data (we are SOC 2 certified).
So, should you build or should you buy?
There isn’t a definitive answer to this question. It really depends on your business and use case along with your organization’s long-term strategy. Below are some questions I would ask myself before making the decision (this is a framework I use in our product development and management work).
You can score your answer to each question from 1 to 5. Then average and multiply the score 1x2x3x4.
If your score is below 30, then you should consider building your own. If it’s above 100 then you should seriously consider buying. Anything in between is nuanced. It may require a hybrid approach.
How is this data supporting your business case?
How many different data types do you need ? (1=only a couple, 5=everything)
Do you need wearables only? (1=yes, 5=no)
How frequently do you need to resync ? (1=no resync , 5= as real time as possible)
Can you afford missing on some data ? (1=totally, 5= I need all the data points)
What is your data retention strategy? (1= no retention , 2=days, …,5= forever)
How many different wearable devices do you need to support?
Do you provide devices to your users? (1=yes, 5=it’s 100% BYOD)
How often do you expect people to connect more than one device ? (1=never , 5 = very often)
Do you plan to let people enter data manually as well ? (1= never, 5=often)
What is your expected volume of traffic?
How many devices you need to connect / year? (1=100s,2=1000s, ... 5=millions)
Do you have varying traffic patterns (seasonality, time of day)? (1=no, 5=totally)
Your resources?
Do you have the required skill set in-house ? (1=all of them , 5= I don’t even know which skills)
What’s the impact of dedicating engineering, support and partnership resources ? (1=minimal , 5=major)
What relative budget do you expect to allocate to this ? (1=small , 5=important)
Last words: Focus on Your Outcomes, not Integrations
We’re living in a world where consumers have increasingly higher expectations for digital experiences, and it’s become more important than ever to free up your time and energy to focus efforts on improving outcomes and user engagement. In most cases, it’s probably better to leave the device integrations, API management, contract management, and data normalization to a vendor instead of building it yourself.
Using our Wearable API also allows you to easily scale up or down your usage as your needs change. There also isn’t a litany of contracts and device manufacturer relationships you have to own. And we believe our product is priced very reasonably compared to the manual efforts that would be required to access even a fraction of the available data sources in our network.
If you believe freeing up time and reducing complexity is important, then it’s definitely worth looking into accessing a unified API like ours.
Read our documentation and learn more about the data types we support and contact us if you have any more questions. We currently have over 300+ wearable devices and fitness apps in our data network and are actively adding new data sources. Best of luck to you!
