Measuring what your app does

The first is the Dashboard, the first entry in your menu, which opens a page titled Overview. It sums up the last thirty days, ready to read, nothing to configure. Its job is to show you in ten seconds whether anything has moved.

The second is the Statistics menu, one notch below. Each of its screens covers one subject, and that's where you go for a precise answer. The controls depend on the screen: traffic is the best equipped, with a period, a platform filter and an export; the technical and international screens display as they are.

The two product lines don't have the same screens, because they aren't measuring the same thing. A content app counts reads, a shop counts sales.

Two landmarks to get you straight to the right place. The Social entry opens the International screen, the one with countries, cities and languages. And on the shop side, the External analytics entry opens the same External tools screen as on the content side.

This is the only screen both product lines share. It opens on three numbers that look alike and answer three different questions: telling them apart changes everything you'll take away from them.

Pageviews count screens displayed. A reader who opens three articles produces at least three: it's a measure of consumption, not of attendance.

Sessions count app openings. The same reader coming back three times in a day produces three. This is your habit metric, and it's the number your Dashboard picks up under the same name.

Unique sessions count people who come back several times only once. This is the number to look at when you want to know how many people you're reaching, and the only one of the three that doesn't move when a regular becomes more regular.

The ratio between the last two says a great deal on its own: if your sessions climb while your unique sessions stay flat, you haven't widened your audience, you've made it more devoted. Both are wins, they simply call for different decisions.

Those three blocks aren't three numbers sitting side by side: they're three tabs. The one you select decides which curve is drawn below, which gives you three readings of the same month without leaving the screen.

The Downloads block gives installs for the period, their variation, a daily average, and a running total. Each number has its use: the total is the one you'll put forward, the period is the one you steer by.

Visit Duration splits your sessions into five brackets, from under ten seconds to the last one, which runs from three to ten minutes. This is the indicator that resets expectations best: on many apps the shortest bracket is the fullest, and that isn't necessarily a failure. Someone who opens a notification, reads the headline and closes has consumed exactly what you sent them.

Top days ranks pageviews by day of the week. Cross it with your publishing habits: if your best day is the one you publish nothing on, you have an easy decision to make.

At the top of the screen, a period selector offers the last 7 or 30 days, this month, last month, or a customized range you set with two dates. Next to it, a filter narrows the display to one platform: iOS, Android, tablet or Progressive Web App.

That second filter is worth the detour. Your iOS users and your PWA users have neither the same install journey nor the same relationship with the app, and the average of the two describes neither.

Finally, every block on this screen has its own Export data link, which produces a CSV file. That's what opens the spreadsheet to you: putting two periods side by side, working out a change, keeping a record month after month, all of it becomes possible in five minutes.

Two screens reserved for content apps, and two concrete decisions at the end of them.

Statistics › Technical gives the split between platforms, the detail of operating system versions, and the list of the most common devices. The OS versions are what matters: they tell you whether the old phone one user is complaining about represents one person or a third of your audience.

Statistics › Social opens the International screen, which ranks your installs by country, by city and by device language. Two uses: deciding whether to add a language to your app, and knowing what time to send a notification. An audience spread over several time zones makes the local-time sending option, described in "Sending push notifications", far less incidental than it looks.

One point that helps read it right: the language measured is the device's. A French reader living in Portugal therefore shows up as French, which makes it the right indicator for choosing your interface language, to be crossed with the country column when you decide what language to publish in.

E-commerce apps have their own screen, Statistics › Activity, which gathers everything to do with sales. Its period is set by week, month or year, current or previous, with a custom view if you want other boundaries.

Four indicators open it: Total sales, Average cart, Orders, and the Conversion rate of the checkout process. Each carries an arrow and a percentage comparing it with the previous period. That comparison is what makes it information: a revenue figure on its own says nothing until you know whether it's climbing.

Below, the Conversion funnel lines up three steps: started carts, started checkouts, then orders. The first two count visitors, the last one counts paid orders, and each shows its share of the total.

The two drops are read separately, because they don't have the same causes. Between the cart and the checkout, shipping is usually what's at stake, its cost discovered at that moment or a sign-up asked for too early: "Defining your shipping strategy" covers that ground. Between the checkout and the sale, it's payment: a form that's too long, an expected payment method missing, a doubt about security. "Choosing your payment methods" covers that one.

The Abandoned orders counter, right next to it, gives the volume side of the same story, with a link to the detail. They aren't lost: "Managing your orders" explains how to win them back one by one.

The screen ends with Top sellers and the Distribution of sales by channel, between PWA on mobile, PWA on desktop, iOS and Android. That last split is useful when deciding where to put your effort, and it often holds a surprise for anyone who has only ever looked at their download numbers.

Every notification you send keeps its own report, opened from your send history: Notification › Push › History on a content app, Marketing › Push › Push history in a shop. It shows the number of sent notifications and the number of opened notifications, each split between iOS, Android and PWA, the click rate, and a chart of openings by hour.

That last curve is the most directly actionable: it tells you not when you sent, but when people opened. Two or three sends are enough for a time slot to appear.

The report carries a block titled Expected rates based on previous notifications, with your average CTR, your highest and your lowest. So the back office does the maths for you, on your own history.

That's the right instinct, and it beats a market average: a daily news app, a sports club app and a shop have neither the same sending rhythm nor the same audience. The comparison that actually concerns you is your previous send.

One point of interpretation, so you read those rates correctly. The recipient count covers registered devices: everyone who has your app installed and accepts your notifications, including people who haven't opened it in a while. That's the right number for measuring your reach. When you want to measure engagement, compare your openings with the month's unique sessions instead: both readings are correct, they simply answer different questions.

A number that changes nothing you do is worth nothing. Three screens talk to each other, and that circuit is what turns an observation into an action.

You notice a behavior in your statistics. You build a group in Community › User list, where the list of your registered users shows their last login and lets you move them from one group to another. That group then becomes a targeting criterion when you send a notification, and it also serves to restrict access to a section: it's the same object on both sides, and "Building a community with your app" describes the extension that provides it.

Push targeting can also do part of the work on its own: it offers behavioral criteria, including the number of openings over the last thirty days, with nothing for you to prepare.

On a content app, the loyalty program has its own measurement screen in Business › Loyalty › Statistics: sign-ups, points awarded, completed cards, redeemed gifts, and a per-reward breakdown between those offered and those opened. So you see directly what a reward produced, which tells you which one to run again. The screen adds an estimate of the earnings the program brought in: an order of magnitude, to be read as such.

The screens above answer questions of attendance, equipment and sales, and they answer them with nothing for you to install. Other questions call for a specialist tool: knowing which article was read most, following the journey screen by screen, or attributing a wave of installs to the campaign that produced it.

GoodBarber lets you plug in the tool of your choice, and that's the job of the Statistics › External tools screen. It's organized in three panels, one per platform, because the wiring isn't the same.

On iOS, you connect your app to Google Analytics for Firebase: the screen gives you your application identifier to declare in the Firebase console, and you then send back the configuration file downloaded from that console. On Android, there's nothing to send, Firebase is set up automatically when the app is compiled and the screen only switches it on or off. On the Progressive Web App, you paste a Google Analytics measurement ID, and optionally a Google Tag Manager container ID if you'd rather drive your tags from there. Content apps also offer Count.ly, an open platform you can host yourself.

The two complement each other more than they replace each other, and the table below helps you decide which one to open depending on the question.

That last point deserves your attention, and the screen helps you handle it: each panel has its own anonymization checkbox, adapted to its platform. iOS gives up Apple's advertising identifiers, Android gives up Google's, and the PWA anonymizes IP addresses while bringing the retention of measurement cookies down from twenty-four months to six. If you aren't running targeted advertising, tick them: you keep your measurements and you make your compliance a great deal simpler.

That leaves the question everyone asks on discovering these screens: what open rate is a good rate, how many sessions per user should you aim for, what retention is normal. The answer fits in one sentence: whatever your app did last month.

These values depend on your field, your publishing rhythm, how long your app has been out and how your users found you. The averages circulating on the web pool apps that have nothing to do with each other, while your own history describes your situation exactly. That, in fact, is what a notification's report gives you: your own reference rates, not a market average.

Three habits get the most out of them. Compare two periods of the same length, which the spreadsheet export makes immediate. Change one thing at a time, so you know what to attribute a movement to. And watch the direction rather than the value: a curve rising gently over three months teaches you more than one excellent number in isolation.