Why We Built This

dylan dulleaNews0 Comments

The inspiration for Method Mill came from our work as a services company. Throughout the last year, we worked closely with dozens of web and app developers to 1) set up and implement analytics and 2) help them analyze their data.

After doing consulting for a while you start to see common problems and solutions throughout the industry. Yet there was one issue that seemed to come up for virtually every client we worked with:

“Analytics Tool X can’t answer any of my questions”

If we had a dime for the number of times we heard that, we could have opened a second office in Silicon Valley.

Most of the time, Tool X can’t answer the client’s specific questions because of restrictions imposed by Tool X’s dashboard. The problem with a dashboard is that it has to work for everyone, and not everyone has the same kinds of questions.

Don’t get us wrong, we’re huge fans of data visualization, and believe that dashboards can be extremely powerful tools in the right hands. One common and unmistakable trend we’ve noticed, however, is the encumbrance many common “one-size-fits-all” dashboards impose on the structure and presentation of data.

The core premise of our argument is that the foundation of effective analytics has to be based on relevance to the user, rather than quantity or how “trendy” a particular metric might be. Plug and play dashboards may be effective at answering coarse metrics like “How many times did a user press a button?” but they typically can’t answer something like “How much money did our retargeting campaign earn from people in New Orleans who purchased items over $50 on our website?”.

Business relevant questions like these can only be answered from a more holistic perspective. With the ever growing complexity and plurality of third party tools platforms (ad networks, social media platforms, “app stores”, development tools and so on), the need for effective orchestration and consolidation of data is becoming increasingly more relevant.

“Why do I have to go to so many different dashboards?”

Many of the delights and horrors of running a consulting company come from seeing clients making the same mistakes over and over again. One of our clients had a dedicated full-time position titled “Dashboard Checker.” The poor dashboard checker’s only role was to check dozens of different dashboards every week and report on what he saw. Apart from being terribly monotonous, the workflow for dashboard checking was horribly inefficient and provided dubious, if any, value to the company.

Every company has different concerns, needs, and questions that can’t be addressed by a generic dashboard. Consolidating all of the company’s data into a single, cohesive source of information, enables organizations to easily build powerful dashboards and reporting around the data that matters most to them. So that’s what we set out to build.

“We mostly just write queries against the production database” **Shudder**

A very common mistake we’ve encountered is when a company runs reporting and analysis directly against the application (backend) database (the same production database that was running their site or app). Voices of sanity within the company (often coming from the devs who knew better) are ignored in favor of the “simpler faster” solution. Unfortunately the situation becomes noticeably less simple when a particularly large query brought the entire site offline during peak hours (and the devs still get the blame for it).

To recap, the three biggest business intelligence problems that we’ve seen have been:

  1. The inability to answer very specific questions and performance metrics and how they tie in to each team as well as the direction of the company as whole.
  2. Compromising the performance and efficiency of a product by not using proper tools for data analysis.
  3. Operational inefficiency incurred by having to manage disparate streams of information.

We wanted to build a product that solved all 3 of these common problems. By piping atomic-level data from many disparate data sources, and unifying them in a dedicated analytics database, we enable:

  1. Developers and company stakeholders of all kinds to answer almost any question about their product that they can think of, no matter how specific the question is.
  2. Developers to easily layer their own reporting tool on top of an analytics database, or plug into an existing BI tool.
  3. The decoupling of the application database as a source of analytics in favor of a dedicated analytics database.

Sometimes we hear questions like, “So, are you guys a competitor to services like Mixpanel and KISS Metrics?” And the answer is… absolutely not. Method Mill is not:

  1. A competitor to any analytics provider. We collect data from analytics providers, and many other sources. Each source and tool has a purpose, and our tool is meant for answering low level questions across many sources of data, as well as giving developers the ability to build their own fully customized dashboards.
  2. A magic wand for perfect analytics. You still will have to configure your schema, tag your product properly, and implement certain necessary SDKs.
  3. A visualization tool. Although we do offer some clients a Kibana integration, we have no plans to build any visualization software of our own. We feel that there are a host of great tools already out there, but the hard part is getting data into the right place. Pipelining data for customized analytics is our focus.

We want to provide our clients with granular access to all of their data, no matter where it is or what format it may be in. In a landscape where a single organization may have upwards of 15 dashboards and reporting tools across dozens of third party services, the hardest task is drawing any meaningful insights from the data as a whole.

We aim to be the backbone of your business intelligence needs, and to give you the tools to make your internal reporting and analysis as robust and powerful as any enterprise company.

Custom reporting has historically been hard. Our mission is to prove that it doesn’t have to be.