Wait, Best Buy has an API?
by Kristen Womack on 12/11/2014
HACKATHON, PART 1: WAIT, BEST BUY HAS AN API?
Hackathons. We’re really into them, but haven’t attended as many as we’d like to. In the next year we intend to change that and here’s why.
About a year and a half ago we started on this journey to transform our developer program. Being an early retailer on the API scene in 2008, we tried many things. Some worked well enough, some made a big impact and some took us a bit off course. What we learned on that journey was that it’s all about developers. In the last six years developers have created an incredible ecosystem of mobile apps in the midst of dire financial times, and the results have been astounding.
In the API space we talk a lot about how important documentation is, so we poured our hearts into the architecture of the documentation early this year and launched a new site in May 2014. To show off our new site, we headed to APIcon just days after the launch. When introducing ourselves and talking about our API, we heard a lot of variations on this response: “Best Buy has an API?” The .gif of that would be a mashup of a shocked, excited, confused, and eager face.
Clearly we had work to do in the dev community. Yes, Best Buy has an API. And it’s pretty incredible. Yes, it has some unfashionable corners that remind us we did most of this work pre-2010, but wow, it’s powerful. In the six months after launching, we saw direct evidence of how powerful excellent documentation is. Immediately after our new site launch our conversion rate (signing up for a key to using the key) saw incredibly sharp and startling hockey-stick growth. We were feeling good about our next outing to sponsor the Future of Web Apps hackathon in Boston.
[Cue that .gif face mashup again: “Wait, Best Buy has an API?”]
The conference-goers were generally excited to see Best Buy and super impressed to see the Best Buy Express kiosk we brought with us. The developers asked a lot of questions about working for Best Buy, relocating, what Minneapolis is like, how did we move the kiosk store onsite and such. But the biggest question was, “What is Best Buy doing at a developer event?” It seemed somewhat difficult for many attendees to digest that we actually had an API. They seemed impressed, but confused. This experience made it clear that we still have a lot of evangelizing to do.
There was honest surprise that Best Buy was doing anything technology related, let alone something relevant in the API space. That was sort of unexpected, because from our perspective, APIs and Best Buy make a natural match. So many of Best Buy’s everyday functions are made possible or significantly enhanced by API technology that it would be strange for us not to take a direct hand in developing our own. And we have such an amazing technology and product organization here in Minneapolis. We do a lot of cool stuff, but we don’t talk about it nearly enough.
Once we started discussing the Recommendations API as a way that Best Buy is exposing its analytical data, or we started talking about Best Buy integrating with external services like IFTTT, or that we’re in the process of adding Best Buy Express kiosk data to our Stores API, most people became engaged. In fact, they were pumped about the challenge and prizes and created some neat projects at the hackathon.
HACKATHON, PART 2: THE BEST BUY HACKS WERE PRETTY IMPRESSIVE
We brought a host of prizes to the hackathon, including Best Buy gift cards ranging from $50-$150 and five Philips Hue Starter Kits facilitated by our Home Automation merchants.
Six hours, seven teams, a bunch of pizza and tons of good ideas brought to light. Here is the run down of the teams:
Team Better View
This three-member team aimed to simplify shopping and comparing products via an app that let users view Best Buy products in 3D viewing. They used the Best Buy API, Orchestrate API, Autodesk and Node.
projectX
ProjectX’s main goal was to build something in Angular. This three-person team built an app that presented an interactive map of shopping and dining options within an airport. We waited anxiously for them to talk about Best Buy Express stores in their app, but they didn’t use any of the sponsors’ APIs. This would be really cool for discovering and locating the Best Buy Express kiosks.
Team Give Us 2 Minutes
The three members of Team Give us 2 Minutes won third prize overall. Operating from the belief that “the best gifts are surprises,” their idea was a subscription service that allows you to send surprise presents to yourself. It was funny, yet actually a good idea. They used the Best Buy API and Orchestrate’s API.
Tango
Team Tango, a team of four from Boston University, was the overall first place winner and second place Best Buy choice winner. They started out with, “Do you know how many clicks it takes to get to a Best Buy product?” Their goal was to help customers search for a product by location, reducing the number of clicks to find the location and availability of a product. Their app provided immediate availability in the map. They used the Intel XDK and the Best Buy API. Excellent presentation.
Keith
Keith was a team of one who built and open-sourced us a PHP Library for the Best Buy APIs.
Product Graph
Team Product Graph won overall Best Buy Choice Award. They were a team of three that built an app around Best Buy recommendations. Working from the belief that “categories are so dry and catalogs are so square,” they built an app that encouraged product discovery in a visual, interactive, relationship graph of products. Starting with Trending Products, users could discover Related Products. When the user clicked on a product, the graph expanded to display all accessories available for that product. The team had intended to use additional features of the Recommendations API by also allowing the user to expand the graph to include Also Viewed and Similar Products in addition to Related Accessories. They used the Best Buy APIs (top trending recommendations API) and Intel’s XDK.
HACKATHON, PART 3: THE HARD LESSONS MAKE THE BEST IMPROVEMENTS
Watching users first-hand in the hackathon arena is an incredible opportunity to learn about your own product. The pressure of the clock creates a constraint where if your API doesn’t work, users move on and you are quickly not a part of their next idea. We focus on this benchmark of being able to get up and running in the shortest amount of time to be relevant to makers and developers at hackathons everywhere.
At the FOWA event, the Philips Hue Starter Kit attracted a great deal of attention. We immediately saw this as an opportunity to get developers to consider trying our API. So we decided to run a contest. This was one of the best things we did because we ended up learning a wealth of information about our process and a peek into the DX (developer experience).
To enter the contest, you had to sign up for an API key, list “FOWA” in your application name (so we knew they signed up at the conference), and make at least one call to the API. Out of twenty-five people who signed up for a key, five of them came to us with problems making their first call. These issues are things we wouldn’t even see back home because the errors never made it back to us in our logs and were riddled with bad error messaging from Mashery. That means an unknown amount of key sign ups never convert. In this case, it was 20%.
A great deal of troubleshooting could have been self-resolved with better error messages that could guide the developer. In most cases, the developer was getting a “403: Developer Inactive” response. Sometimes that meant that their key really was active, but they had a malformed query string, or that the developer didn’t know that “&” has a special meaning on the command line and must be escaped, or that “APIKEY” versus “apikey” versus “APIKey” mean different things. We’ve always known that Mashery’s error messages gave us problems, but never saw these specifics in our logs.
We are not able to change the error messaging in this case, so we decided to do the next best thing: add these examples to our documentation for creating more digital troubleshooting guides. And that’s what we are in the process of doing now. Uncovering this opportunity was one of our biggest and richest discoveries of this experience.
