When “Obvious” Isn’t Obvious: A Few Lessons Learned Selling Data

Having spent a good chunk of my career working in Data-as-a-Service—both leading product implementation and product direction at OAG, and as a Solutions Engineer at Sensor Tower—I’ve noticed a curious pattern that seems to pop up across almost every data provider.

When you spend 40+ hours a week neck-deep in your company’s dataset, you develop an intuitive shorthand for all its quirks. What felt like an impenetrable domain when you first joined eventually becomes second nature.

The trouble starts when we accidentally assume our customers share that exact same shorthand.

It’s completely unintentional, but this assumption has a quiet way of leaking into API JSON responses, SQL table designs, and SaaS metrics. We hand over the keys to the data warehouse or share API documentation, assuming that because a customer is technically capable of parsing a payload, they also understand the implicit domain rules woven into it.

Most of the time, they don’t. And that’s not their fault.

Little Domain Quirks Can Lead to Big Head-Scratchers

To give a casual example from my time in aviation data: there’s a massive conceptual difference between a flight schedule and real-time flight tracking, but they often get lumped together in people’s heads.

By the way, a schedule can easily be filed as a multi-stop journey (like a single flight number for SYD–SIN–LHR). But when it comes to tracking flight status—cancellations, delays, wheels-up times—physical reality dictates that it’s strictly tracked by individual legs. There isn’t a single “delay” for that entire multi-city ticket; there’s a delay on the first leg, and maybe another on the second.

Another fun edge case that occasionally trips people up is how midnight rollovers work under IATA rules:

• If an airline reschedules an 11:55 PM flight to depart at 12:05 AM the next day, industry conventions typically treat that as a deletion of the old flight and the creation of an entirely new flight record for the new calendar day.
• But if that exact same 11:55 PM flight is merely delayed until 12:05 AM, it remains legally tied to the previous day’s operating date. To check its status, you still have to query the original schedule date.

If a developer isn’t steeped in aviation rules, encountering these quirks feels like finding a bug in the API. They might wonder why a delayed flight “disappeared” or why an overnight reschedule generated duplicate records.

You see the exact same thing play out in digital and mobile intelligence. At Sensor Tower, people often ask for seemingly simple numbers like “Active Users” (DAU/MAU) or “Install Penetration.” But under the hood, what actually qualifies someone as an active user? Does opening an app by mistake for two seconds count? Does a background notification refresh count? What about penetration—is that unique lifetime devices in a market, or currently active devices?

None of these definitions are universally standard across the tech industry. When clients plug these tables into their internal BI pipelines, they naturally bring their own intuitive definitions with them.

Why the Gaps Matter

These little misunderstandings rarely cause catastrophic failures on day one, but they do cause friction:

• Engineering teams burn cycles: Developers spend hours troubleshooting why their queries return unexpected results, only to discover it’s an intended domain behavior.
• Skewed business insights: A product team might make a feature bet or allocate marketing budget based on numbers they interpreted differently from how the models actually calculated them.
• Frustration on both sides: When data behaves counter-intuitively, the customer’s immediate reaction is usually: “Wait, is this data broken?”

A Few Thoughts on Closing the Gap

Over the years, I’ve found that preventing these disconnects doesn’t require overhauling the underlying data models. It usually comes down to two things:

1. Documentation that explains the “why,” not just the schema

Field descriptions like "dep_time": "Departure timestamp" are helpful, but they don’t explain the business logic. Modern docs are much stronger when they include short, plain-English guides explaining the quirks—like a quick callout on how midnight delays are handled. With so many engineering teams now using AI coding tools to parse schemas and write queries, having clean, conversational, and well-structured context in the documentation makes an enormous difference for both humans and LLMs.

2. Bridging the gap early (the real value of Solutions Engineering)

This dynamic is largely why I love the Solutions Engineering side of the house. Business stakeholders and account managers are naturally focused on high-level outcomes, while engineering teams are focused on ingestion pipelines.

Neither side always knows what questions they should be asking about the dataset’s nuances. Having someone in the room who can act as a technical translator—proactively calling out these subtle differences before contracts are signed or schemas are deployed—saves everyone months of headache later on.

Selling data isn’t just about handing over an endpoint; it’s about helping people make sense of the real-world complexities captured inside it.

All opinions and perspectives expressed here are solely my own and do not represent the views of my current or past employers.