Earlier this week I sat down with Ben Goldberg, lead engineer on Quill Engage, to get his take on the the product and how it's evolved, what it's like working with the Google Analytics API and his proudest moments working on the application.
How long have you been working on Quill Engage?
I’ve been working on Quill Engage since I started with Narrative Science almost two years ago. Quill Engage was about a month away from its original beta launch in March of 2014 when I joined the team.
How have you seen the application change since you joined the team?
Quill Engage today has evolved significantly in the time since I started working on it. At the outset, Quill Engage was a product which we believed -- and still believe -- could offer valuable insight to every Google Analytics user.
In the beginning, however, we were very much laying out features which we thought would be useful to users, rather than features we knew would be useful. The reason for this was that we were pioneering natural language Google Analytics reporting. We were first to market with this type of weekly and monthly summary of users Google Analytics data and it was challenging to validate what was valuable to customers and what was not. That’s why we launched in beta and spent a significant amount of time working to understand how we could add more value to our customers analytics workflow.
Today, I am proud to say that our team is extremely customer focused in the way that we think about and approach product development. Our product manager, Mickey, works very closely with our customers to gather feedback and solicit ideas regarding our product.
As an engineer, this makes a world of difference because you know that the work you’re contributing will have a positive impact for your customers as soon as it's released. Features in our paid offering, such as Ecommerce, Goals and Conversions, and Events analysis were born directly out of communications and beta testing with our customers. Similarly, our latest feature, the ability to download a PDF of your reports, was a feature request we had received from a number of our customers.
You work very closely with the Google Analytics API. What has that experience been like?
Overall, my experience working with the Google Analytics API has been a positive one. If you open the documentation for the Core Reporting API, you’ll quickly find yourself amazed at the depth of the data available. It's rare, in my opinion, for a company to provide such rich access to their data in the way that Google Analytics does. If you study the web analytics market you can clearly see how much influence Google has had in this area.
One of the things I love most about the Google Analytics API is how complicated your queries can be. These complex queries allow us to offload a significant amount of data analysis work directly to Google’s API. This is an astounding technical accomplishment on the part of the Google engineering team. Consider the quantity of data you’re recording for just your own web property in Google Analytics. Now think about trying to service an API request with that quantity of data in the 60 second duration of an HTTP request. Complicating this situation even further, imagine you’re servicing more than 10 million web properties individually via this API with their data aggregated in your data warehouse. That’s Google Analytics. The complexity of that problem is famously something Google has mitigated through technologies like BigTable and MapReduce.
What piece of advice would you give to a fellow engineer working with Google’s API?
Start with an idea of what you want as your end result and then work backward. This rule applies to many paradigms in Software Engineering, but I find it especially true in relation to the Analytics API.
Working forward from the API to a data solution is always much harder than sitting down and identifying what the goal of the data analysis or API integration is supposed to provide. From a product perspective this is also where you’ll find the most value. Simply put, the Core Reporting API provides such a diversity of data reporting options that it's often easy to lose sight of what you originally set out to do - aka your Minimum Viable Product (MVP). Developers, myself included, love data and the possibilities that it presents. Stay focused on whatever slice of reporting you originally set out to work on -- and overcome the hurdles of data sampling, rate limiting, and establishing your MVP with your customers before horizontally expanding your data analysis.
What has been your biggest accomplishment working on Quill Engage?
I think the redesign and relaunch of the application is my proudest moment working on Quill Engage. The team has grown by leaps and bounds over the past few years and I think that progress is most evident in the look and feel of our new application.
When I reflect on what we’ve done recently, I feel deeply satisfied in knowing that we’re providing a service that is simple for our customers to use and understand. It is a testament to the excellent job our UX team and engineers have done that our site can get a user up and running in under a few minutes.
Behind the scenes there is a significant amount of work happening, be it with our interactions with Google Analytics, or in our Natural Language Generation software, Quill. Wonderfully, though, a user doesn’t have to worry about any of that; all they have to do is enjoy our reports.
To me, that’s a mark of success on any product you work on as an engineer. At the end of the day, when you ship it, it serves its purpose well and with as little complexity and maintenance possible.