The Five Levels of Data Maturity in Mobile Apps

Level 1: Aligned definitions and conscious measurement

The first level is not really about technology at all. It's about deciding, purposefully, what you measure, how, and what each metric actually means. You pick a handful of metrics, perhaps five or ten, you write down the definitions and agree on them across the team, and you commit to updating them on a regular basis. No system integration necessary; just a single person entering numbers into a spreadsheet by hand.

This basic setup may sound underwhelming. But it works, because at this stage, the biggest challenge is agreeing on what each metric actually means and how it should be calculated.

Moreover, it could very well outperform a heavily resourced enterprise BI system. It’s not unusual to find a large organization with a thousand reports in production and no shared definition of what a loyalty program member is. This makes everyone believe they are on the same page, while they actually reference completely different data. A small set of clearly defined metrics in a spreadsheet can be more useful than that.

For mobile apps specifically, this level has obvious limits. You will not capture screen-level behavior or funnel drop-offs with a manual sheet. But for a business measuring revenue and a few product KPIs, it can be enough for a long time. With a caveat of making sure all the metrics are well-defined and updated consistently, of course.

Level 2: Mobile-native analytics around a single data source

The second level is where mobile-specific analytics show up properly. The organization starts collecting events from the app itself: screen views, session lengths, cart abandonment, checkout completion, opened push notifications. The data lives in one place and gets analyzed right there.

The defining feature of this level is that the analytical conversation is still all about the app. You can answer detailed questions about user behavior inside the application, but you can’t easily connect those behaviors to inventory, fulfillment, or customer service interactions.

That isolation often produces a pattern that looks a lot like Level 1, just at a different point in the chain: app metrics get copied, by hand, out of the mobile analytics environment and into whatever the rest of the business uses for C-level reporting. The same definitional drift that Level 1 was supposed to prevent shows up again, now between systems instead of between teams.

This is also where shadow IT tends to grow. A common pattern: IT runs one vendor for ERP reporting, marketing and product run a completely different one for app reporting, and nobody at the top of the organization has a complete picture of which numbers are coming from where. The question worth raising explicitly is whether to accept this consciously, with IT taking ownership of the second stack, or to work toward at least some tooling-level alignment across departments.

For smaller organizations this can be a stable endpoint, while for larger ones, it’s usually a transitional stage. The whole point of a mature data setup in a bigger company is to combine sources, and a stand-alone mobile analytics environment will eventually feel limiting.

Level 3: Enterprise BI with mobile events as one of many sources

At Level 3, mobile events stop sitting on their own. They get pulled into the same place as everything else the business tracks: inventory, product information, orders, customer service history, marketing results. Reports are no longer about the app on its own; they are about the business, and the app is one of the things feeding into them.

This is the familiar setup at a large company. There is a data team, a set of regularly maintained tables, dashboards that the business agrees on, and a steady queue of requests for new reports. A mobile event ends up as one number among many on a wider dashboard.

The way people think about the data here is still mostly in rows and columns. Underneath every dashboard there is a set of tables, and what gets reported is mostly averages, totals, and rankings: average screen views per session, the most-visited pages, conversion rates by segment. The data has been brought together, but the team is not yet thinking about it as a live stream of things happening to individual users.

The real challenge at this level is making sure you don't treat every data source the same. A daily refresh works perfectly well for most reporting needs: sales figures, inventory levels, weekly KPI summaries. But customer-facing use cases are a different story. Fraud detection, real-time recommendations, or a push notification triggered by something a user just did all rely on fresh data. If you force those into the same once-a-day refresh cycle as everything else, they stop being actionable and become little more than historical reports.

This is also where many organizations get stuck. Part of the reason is organizational: the teams running this setup tend to be the ones with the strongest governance discipline, which is what holds it together, and which gives them little reason to push for change. Part of it is operational: the reports go out every Monday, but the data mostly stays where it is. Getting it from a dashboard into a system that actually talks to a customer is still a manual, one-off effort, so most of the time, nothing is done with it at all.

Level 4: Adding an activation layer

The hardest distinction in this whole framework is between Level 3 and Level 4. The tools can look almost identical, but adding an activation layer changes everything.

At this level, the organization stops treating data as something to look at and starts treating it as something to act on. Reports still matter, but they're no longer the finish line; the data feeds into marketing automation and the systems that actually talk to customers.

From our perspective, this level’s activation layer is quickly becoming the standard for larger companies; more of a baseline they are expected to meet rather than a competitive advantage.

The missing piece at Level 3 was always the last step: someone had to copy a number out of the warehouse by hand before it could reach a customer. Level 4 closes that gap by making the warehouse work in both directions. An audience or a metric defined there gets pushed back out, on a schedule, to the systems that actually talk to customers: the messaging platform, the marketing automation tool, or the CRM. This is the operational analytics layer, often called reverse ETL, and it's the plumbing that turns a Level 3 dashboard into a Level 4 action.

All of this is still a batch, by the way. The warehouse refreshes, the sync runs, the audience updates, somewhere between once a day and every hour or two at the tightest. That's fast enough for most of what activation gets asked to do:

• When a customer's credit card is about to expire, they get a message. Knowing this a day ahead is fine.
• When a user adds an item to the cart and leaves without checking out, they get a push reminder an hour or so later.
• When a product on a user's wishlist comes back in stock, they get a notification within an hour or two.

What batch can't do is react the moment something happens, the second an event lands instead of at the next scheduled run. Getting there takes a bigger shift in how the whole system works, and that bigger shift is Level 5.

One thing has to be true for any of this to work: the customer in the warehouse has to carry a reachable identifier, like an email, a phone number, or a push token. Without that, there's nowhere to send the message.

What ties everything at this level together is that the work still runs on a schedule, and the rule is one a person can describe step by step: when this happens, do that. The data kicks off automated processes for individual customers, but a human writes the logic and a batch job runs it.

This is also where events start to register at all. The thinking is still mostly in tables and dashboards, but a new question pops up. "What does the dashboard show?" now has a companion: "what should we do when this happens?" Thinking primarily in events comes later; at this level it's just starting to surface.

Level 5: Event-first thinking and AI-assisted activation

At Level 5 the activation layer changes again. The bigger shift, though, is in how the organization thinks about data. The mental model moves away from tables, schemas, and rigid scheduled processes, and toward events, real-time, and fast experimentation. Some systems stay in table format because that's what they're good for, but the mobile side of the organization starts to think primarily in events.

Rule-based workflows still exist. The bigger change is what gets added on top: activations driven by models the team can't fully describe in advance; a churn score decides who gets a retention offer or a ranking model decides which products appear on each user's home screen. In other words, the human sets the objective and the model finds the rule. This is where AI-driven segmentation, hyper-personalization, and predictive scoring come in, and where you can start personalizing for an individual user in real time, on the event.

It's worth being honest about the cost. Event-first, real-time, model-driven systems are meaningfully harder to run than a nightly batch. They're harder to maintain, harder to govern, and harder to reason about. Execution turns into a continuous loop you have to observe, debug, and trust. A scheduled sync that breaks is obvious by morning; a model quietly drifting, or an event stream silently dropping records, is not.

This is exactly the gap a new class of tools is trying to close. Tools that activate and make decisions directly on top of the warehouse have been chipping away at it for a while, and the more recent move is to pull the whole CDP inside the data platform. Databricks' CustomerLake, announced just a few weeks ago, does exactly that: it brings customer data, models, and activation under one governance layer instead of copying them into yet another system. In this case, the hard part becomes clear governance and maintenance.

The original promise of mobile analytics, such as data leading to personalized experience at scale, starts to be delivered for real. It's also the level where the cost of poor data foundations becomes most visible. The models are only ever as good as the features feeding them, and those features come from the same warehouse tables as everything else. In other words, sophisticated personalization on top of inconsistent data is worse than no personalization, because it acts on the error with confidence.

The counterpoint: activation should not wait until Level 5

This five-level model is useful as a map, but it implies a sequence that is misleading if taken too literally. The assumption that activation happens at the top of the ladder, and that everything below must lead to it, doesn’t hold up against actual practice.

Activation can begin at Level 1. If you have a spreadsheet with five metrics that show which customers are at risk of churn, you can act on that this week. You do not need an event pipeline, a CDP, or a predictive model to send a renewal reminder, kick off a sales call, or pause a campaign. What you need is to know what you want to do with the data.

This is why the more useful question is not "what level are we on" but "what are we trying to do." A retailer with five products and a stable set of B2B customers will design completely different scenarios than a marketplace with 1.5 million products and 11 million users. Both can take meaningful action with the data they already have, and neither needs to swap out their entire stack first.

The risk in the maturity-ladder framing is that organizations treat advancement as the goal. They invest in the next level of tools, complete the migration, build the dashboards, and then discover that nothing in the business has changed.

This is the silo problem in a different form. Enterprise organizations almost always have the data, but It's scattered across systems, hard to access, and impossible to act on without effort. Solving this is less about adding a new platform and more about architecture, integration, and a clear view of where the data needs to land for it to be useful.

Knowing where the audience actually is

A second reason to be skeptical of pure tool-level thinking is that the channels of communication vary by market. In many parts of Europe and North America, the default activation channels are email, SMS, push notifications, and in-app messages. Meanwhile, in Latin America, WhatsApp is the main channel. Two-way conversations, transactional notifications, full campaigns – customers expect them all to be run through WhatsApp.

This matters because the architecture decisions follow from the channels, not from the maturity model. An organization moving into a new market needs to integrate WhatsApp not because it has reached a certain level, but because that is where the customers are. Both small and large companies end up needing the same channel integrations, even if their underlying data stacks look completely different.

What Agentic AI changes

The reason this matters more than it used to is that the rules of the game are shifting. Agentic AI is starting to enter business operations through every available door. Models that can take actions, not just describe data, are becoming part of normal workflows.

The organizations that are best prepared for this shift are not necessarily the ones with the most elaborate BI environments, but the ones whose data is well-defined, well-organized, and operationally ready, regardless of the tool it lives in. A sophisticated BI environment on top of inconsistent definitions won't carry you to agentic AI. Neither will five clean metrics in a spreadsheet, on their own. One extreme has the tooling; the other has the discipline. Neither is enough by itself – agentic AI needs both.

Which brings the framework back to its real axis. The question worth asking has never been which level you are on, but whether your data is in a state you can act on – defined, organized, and reachable by the systems, and increasingly the agents, that will use it. Tools and levels come and go; that readiness is what decides whether anything built on top actually moves the business. It is also the hardest part, and the part no migration can do for you.