Custom Cars & Implementations – Part 2

In my last post, I told my saga of going from an old Corvette that didn’t work much, to a custom one that did work, but cost a lot of money. As I asked at the end of my last post, why doesn’t everyone go the custom route? Why is the norm purchasing cars that come off assembly lines? Obviously, the answer is that custom cars are more difficult to build, take more time to maintain, and are far more costly. Custom cars don’t have as many security checks as assembly-line cars. For example, my new car doesn’t have the airbags or safety sensors that are commonplace these days. It isn’t as easy to find parts—or an experienced mechanic—for my car as it would be for a standard car. For all of these reasons, most people will never be crazy enough to go custom. But when it comes to digital analytics implementations, what if I told you that the opposite is true? Virtually all analytics implementations are custom. Organizations that often don’t know that much about their analytics tools decide to create a custom implementation in tools like Adobe or Google Analytics. Many times, the people involved have only been through 1-2 other implementations in the past. Organizations that know barely more about their analytics tool than I do about cars(!), are willing to build a custom implementation. They often bring in outside consultants to help, but just like you never know if the car shop you’re working with is any good, you really don’t know if the outside consultants have the skills to build a custom implementation. As with my car, “custom” often means a lot of time and a lot of money, with the possibility that the job isn’t even done correctly, which then leads to even more money down the road!

So why do organizations go custom when it comes to digital analytics implementations? The answer is simple. Because there has been no other option. No one has taken the time to standardize analytics implementations or create industry-wide best practices. There are books, blog posts, and a cool “recipe” program I helped start at the DAA, but that is not enough. I have reviewed hundreds of analytics implementations in my career and I can tell you a few things for certain:

  1. Most [custom] implementations are bad
  2. Most organizations don’t have people that know their analytics tools well enough to fix it on their own
  3. Every organization thinks that its implementation is unique, but most are about 80% similar to other implementations in the same vertical

So how do we break out of this twenty-year paradigm? We can start by learning from what happened with cars. Eventually, cars went from being built custom to being produced in a more standard way. These standards produced:

  • Efficiencies – Cars could be produced in days instead of months
  • Consistency – Cars were more consistent, drove better, and lasted longer
  • Quality – Best practices from past experience were incorporated and continuously improved

These same principles should be applied to digital analytics implementations. It should be possible to learn from the hundreds of analytics implementations that have taken place over the past twenty years. Here is what I believe our industry needs:

  • Instead of guessing what business questions your stakeholders might have, you should have access to a tool that allows you to pick from a set of hundreds of business questions that experts (good mechanics like me!) have seen be successful in the past
  • Instead of wondering if you are architecting a solution to answer each business question in the right way, you should have access to a tool that automatically shows the best possible way to configure your analytics tool to answer each question
  • Instead of building a custom data layer, you should have access to a tool that automatically builds a best-practice data layer that is directly related to the business questions and solutions you have selected
  • Instead of manually building a custom tag management configurations, you should have access to a tool that automatically builds your tag management setup and is directly connected to your data layer, solutions, and business requirements
  • Instead of manually conducting quality assurance, you should have access to a tool that intelligently shows developers when they have and have not tagged things correctly in accordance with the data layer
  • Instead of wondering what reports and metrics you should create to answer each business question, you should have access to a tool that allows you to click a button and automatically generate reports and dashboards that are pre-built for each business question you have selected
  • Instead of relying on outdated, static implementation documentation in documents and files, you should have access to a tool that automates all documentation and keeps it constantly updated via a relational database

This is why I am so excited to be working on the Apollo product at Search Discovery.

Apollo is a tool that provides all of the above and more. As I mentioned in the blog post when I joined Search Discovery, the old, custom approach to doing implementations has run its course.

It’s time to re-think the implementation approach of the past since it is clearly not working. Eventually, our industry will move towards standardization in order to produce better quality, faster, and more cost-effective analytics implementations. We need to move out of the custom phase, just like the car industry moved to a more efficient approach. We don’t all need custom cars and can benefit from the efficiencies that can be gained by learning from the past.

If you’d like to learn more about this and get a demo of Apollo, please fill out the form below and reach out to us at apollo@searchdiscovery.com

Related Posts

Join the Conversation

Check out Kelly Wortham’s Optimization based YouTube channel: Test & Learn Community.

Search Discovery
Education Community

Join Search Discovery’s new education community and keep up with the latest tools, technologies, and trends in analytics.

Follow Us

Scroll to Top