Seeing Like An Algorithm At Omnia

Seeing Like An Algorithm At Omnia

An inside look at how Omnia is building personalized retail for the outdoor industry

When we started working on the Omnia platform four years ago, the core problem we were trying to solve for was how to create a hyper-personalized shopping experience for each angler to reduce the overwhelming number of options in the fishing gear industry.  Being overwhelmed drove nearly 90% of the $5 billion industry into brick and mortar stores to get help.  The solution was a location-based platform that narrowed down the fishing-related product options a customer needs for a specific fishing scenario. We believed that scenario could be defined well enough to enable systematic recommendation, especially if a user could clearly articulate their fishing scenario.  We believe that scenario can be structured at its core by knowing:

  1. Where you're fishing (Lake)
  2. What you're fishing for (Species)
  3. When (Season)
  4. Which strategy matches 1-3 (Technique)

My co-founder Matt always used the analogy of someone walking into a giant big-box retail store with a huge wall with thousands of SKUs on it.  A customer has a general idea of what they need but not exactly and finding those products is inefficient and extremely time-consuming.  It often takes a mix of several products to piece together what you need for a fishing trip.  Matt always said Omnia is the tool that lights up the right products on that giant wall that match the specific conditions of the fishing outing you are planning.

A wall of products in a big box store where someone from the guns department trying to help you pick out tackle doesn't result in a high-quality experience.

Understanding how products are related is the start of being able to make recommendations.  After combining the product data with the fishing scenario you still need the user feedback loop to verify and signal that the recommendation is of high quality.

How do we actually do all that?

Clarity through structure

Everything in its right place

From the beginning, every element of our architecture has been designed for consistency using a common taxonomy.  A few of our core key elements are Products, Lakes and Fishing Reports.

Here are what the core elements look like and at what current scale.

A proven taxonomy applied consistently across 20,000+ SKUs.
In addition to geolocation and seasonality, our database of 200,000 lakes contains metadata for each lake's species & water clarity.
Structured user feedback in the form of 10,000+ fishing reports adds user input to the feedback loop.
20,000+ SKUs
200,000 Lakes
10,000+ Fishing Reports

Keep things connected through composability

Small pieces loosely joined

In addition to keeping things structured and normalized, the core elements need to be easily connected, related, and extended.  We had clear initial ideas on how Products, Lakes & Fishing Reports would be related.  We then quickly realized Content was going to be an important part of the mix, often in the form of Video.  It was clear to see how we would relate in Video to mix.

Our core key elements can be programmed to interact with each other.  We view these elements as building blocks or Legos that fit together to lay the groundwork for ideas we have today and ideas we haven't thought of yet well into the future.  This allows us to rapidly iterate on features and be able to measure their effectiveness quickly.

Composable key core elements leveraging structured data.

Show the right things at the right time to the right person

Lay your cards out

We have the data structured, an understanding of unique customer intent, and the system was composable and ready to build experiences on top of it all.  That put a lot of pressure on our recommendation system to deliver value with limited inputs.

By understanding a user's species and lake preferences, just from those two points of data, we can provide a winning personalized experience the first time they used our system.  More complexity could be added over time, but we would start there.  It was also important to build a system that was ready to learn and take in feedback loops from users in the form of Orders and Fishing Reports.

In Part II, we will go into detail on how we use algorithm-friendly design to capture clean signals and create a potent flywheel of learning.

Here is a visualization of how our recommendation engine works.

The data-driven Omnia ecosystem.

Interest graph over social graph

No new friends

One of the strongest opinions that I held from the beginning is that Omnia would build a system that provided personalization through a deep understanding of the user without requiring them to add friends or follow other peers.  Social graphs of course have value and add network effects that can be powerful signals for a system like Omnia.

The goal of Omnia is to understand and learn a user's preferences in order to play that back to them in the form of personalized experiences that let them be more efficient and effective within the context of fishing and their other outdoor pursuits.  We call that the Omnia Interest Graph.

We think of it as single-player mode vs multiplayer mode in a video game.  Multiplayer mode is possible, but single-player mode is what Omnia is optimized for and it's what we want to help our users perfect.  Get better and better over time and help them grow.

Stay tuned for Part II where we go into detail on the UX side of things and explain what algorithm-friendly design means at Omnia.

This post was heavily influenced and inspired by Eugene Wei's amazing trilogy: Part I, Part II, Part III.

Come Work With Us

If you or someone you know is interested in helping us to further build this out, please consider applying for one of our data science positions:

  • Customer Insights Lead: create data narratives, explore cuts of data in revealing ways, automate analysis through dashboards and visualizations.
  • Machine Learning Engineer: create the underlying tooling, create simple CI/CD pipelines, own the platform that tracks data through our system and allows for iterative modeling and versioning.