Friday, October 2nd 2026
Google Play Console Analytics: what Shopify brands can (and can't) measure

Google Play Console is Google's dashboard for managing and measuring an Android app, and the source of the Google Play Store analytics most brands look at first. For a Shopify brand, it shows how people find and install the app, lets you test the Play listing, diagnoses deep links, and reports Android quality signals that affect conversion and discovery.
It is not your commerce system. It cannot report app average order value, compare app and web buyer lifetime value, or show the app's share of online revenue. For physical Shopify products, that data lives in Shopify and the app platform. The same boundary applies in App Store Connect.
This guide covers the Android app analytics that matter for a commerce app and the Play Console sections that do not apply to a physical-goods store.
For the iOS counterpart, see App Store Connect Analytics for Shopify brands. For the combined commerce, retention, and app-store scorecard, use the mobile app metrics guide.
What Google Play Console is, and why it is not Shopify analytics
Google Play Console is the dashboard for apps on Google Play. It reports store and device performance across Android phones, tablets, Wear OS, and more. It covers acquisition, Android quality, audience statistics, and transactions processed through Google Play Billing.
Two things shape everything below.
First, the data is aggregated and privacy-thresholded. Small sources, campaigns, or search terms may be grouped under "Other", so a new campaign can appear to produce nothing when it is below the threshold.
Second, and most important for a Shopify brand: Play Console can measure the store and the device, but it cannot connect an Android install to a Shopify customer, an order, or an email address. It has no view of average order value, repeat purchase rate, or lifetime value. Those are the numbers that decide whether the app is working, and they live entirely outside this tool.
What Play Console cannot tell you. Revenue from Shopify physical-product orders, average order value, repeat purchase rate, or customer lifetime value; which Android install maps to which Shopify customer; and your app-versus-web revenue split. All of that lives in Shopify and your app platform. Play Console measures acquisition, store conversion, Android quality, and any digital sales that run through Google Play Billing. It is the front-of-funnel and app-quality layer, not the system of record for commerce.
The store-listing funnel: visitors, acquisitions, conversion, and sources
The most useful reports for an ecommerce app are the store-analysis and conversion-analysis tools. Where App Store Connect tells a brand where iOS downloads came from, Play Console more visibly turns the Android listing into a measurable conversion funnel. Using Google's own wording, it breaks acquisition into three sources (Google's acquisition reports documentation):
- Google Play Explore: users who find your store listing while browsing or searching on Google Play without searching for your app by name (home pages, suggestions, and top charts).
- Google Play Search: users who find your listing by searching for your app's name or closely associated terms.
- Ads and referrals: users who reach your listing from an ad or a referral, such as a link outside Google Play. Google attributes every Google Ads visit to this source.
Around those, it reports store-listing visitors, clicks, click-through rate (CTR), and acquisitions. Two distinctions matter. The conversion analysis page now counts clicks: store-listing visitors who tapped the install, open, or pre-register button. Its CTR replaces the legacy conversion rate, and a click is intent, not a completed install. Completed installs are store-listing acquisitions: users who install while not already having the app on another device, which strips out re-install and multi-device noise that inflates raw install counts. That metric now sits in Statistics and the exports.
The conversion reports can also slice traffic by UTM source and campaign, country, language, install state, traffic source, and store listing. For a Shopify brand, that turns four practical questions into answerable ones:
- Are customers searching for the brand by name, or discovering the app through category browsing?
- Does a paid campaign produce store-listing visitors who actually convert, not just clicks?
- Which email, influencer, QR, or paid source drives qualified install traffic?
- Is a localization problem depressing conversion in a specific country or language?
One caveat to state plainly: Play Console store-listing visitors will not exactly match Google Ads clicks. A click may never become a loaded store visit, and Play Console does not report Google Ads impressions or conversions at all; Google points you to your Google Ads account for those. Read the two tools as related, not reconcilable to the unit.
Custom store listings: campaign landing pages inside Google Play
Google Play supports up to 50 custom store listings, each targetable by country, pre-registered users, unique URL, particular Google Ads campaigns, inactive users, and Play Search keywords (Google's custom store listings documentation).
For an ecommerce brand, the Play listing can become a set of campaign landing pages rather than one static page. Match the promise in an ad, email, creator post, or QR code to its screenshots and short description:
| Campaign or audience | Store-listing angle |
|---|---|
| Paid fashion campaign | New-drop imagery and an app-exclusive offer |
| Loyalty audience | Points, early access, saved preferences |
| New market | Local delivery, currency, language, returns reassurance |
| Sale-season traffic | Speed, offer clarity, wish lists, stock alerts |
| Brand searchers | Trust, native checkout, app-only convenience |
One caveat before you treat this as an unrestricted paid-campaign workflow: Google Ads-targeted listings do not yet support every app campaign format (same custom store listings documentation), so a specific creative type may not be eligible for a custom listing. Check format support before you build a campaign around it. The store credit and app-exclusive mechanics that make these angles convert are a program in themselves; if you are pairing custom listings with paid acquisition, use the Shopify mobile app ROI calculator to pressure-test the spend.
Store Listing Experiments: what to test for a commerce app
Play also has Store Listing Experiments for A/B testing your icon, feature graphic, and screenshots, plus descriptions in up to five languages on a localized listing. You pick one target metric per experiment: unique user install clicks, open clicks, or pre-registration clicks. Google recommends testing one asset at a time, so you can tell what caused a change (Google's store listing experiments documentation).
On Google Play, the listing is a testable storefront. For a commerce app, the most useful tests are:
- The first screenshots, since they are the ones every visitor sees.
- The feature graphic, especially during a sale season.
- The short description, where a concrete benefit beats a slogan.
- Localized creative in a market where conversion is lagging.
Change one thing, wait until Play Console reports a result, and let install clicks decide, rather than a hunch about which icon "feels" better. The same listing discipline carries across both stores; we go deeper on the creative side in App Store Optimization for Shopify brands.
Deep links: the web-to-app configuration report most brands overlook
The Deep Links page is a real differentiator, and for a retailer with meaningful mobile-web traffic it is worth a look most brands never give it. It is a configuration and diagnostics tool, not a full attribution platform. What it does, per Google Play's Deep Links overview, is help you monitor the web domains linked to your app, flag important URLs that are not yet deep-linked, diagnose the association and setup issues that stop a link opening the correct in-app destination, test a route's destination experience in an emulator, and patch deep-link configuration without shipping a new release.
That is genuinely useful, but be clear about what it is not: it is not a report of how many users resolve into the app versus the web, and it is not a Google Ads attribution surface. Treat it as an audit of your deep-link coverage and correctness.
For commerce, the operational question it answers is: when an existing app customer clicks a product, collection, campaign, or loyalty link, does it open the relevant app screen, or fail over to generic web? A brand that spends on product-level Google Ads, email clicks, social traffic, and SMS should audit its highest-traffic product and collection URLs first, because a missing app destination on a high-traffic URL is silent lost value. The console makes that gap visible instead of leaving it buried in the implementation. For a Tapcart-specific migration example, see the NAPPS vs Tapcart comparison.
One limitation to explain honestly: Google Play promotional-content deep links help existing app users reach the right in-app destination, but they do not currently persist through a new installation. A new user who installs after clicking such promotional content lands at the app's default destination, not the deep-linked one (Google's promotional-content deep-link guidance).
Statistics: installed audience, new users, returning users, and user loss
Play Console distinguishes users from devices, which is a better fit for a commerce narrative than raw installs. A user can have several Android devices, so device acquisition and user acquisition are different measures. The concepts worth reading:
- Installed audience: users with the app on at least one active device.
- New users: first-time installers.
- Returning users: people who had removed the app from all devices, then came back.
- User loss: people who uninstall the app from all their devices, or whose devices with the app go inactive for more than 30 days. That makes it a broader app-health signal than a pure uninstall or churn count, so read it as "users who dropped out of the active base," not strictly "users who deleted the app."
- Install base: active devices with the app installed.
(These follow Google Play's statistics metric definitions.) Framed as a funnel, it reads:
Store visitor -> new user -> installed audience -> app open -> shopper -> repeat buyer
Play Console helps with the first three steps. Shopify, your app platform, and your customer analytics have to measure the rest. "Installed" does not mean "opened," and "opened" does not mean "shopped."
Android vitals: why crashes and freezes are acquisition problems too
App Store Connect reports crashes, but Android vitals sits closer to the center of how Google Play works, so it deserves more attention in a commerce context. Android vitals tracks crashes, application-not-responding errors (ANRs), startup performance, battery use, permissions, and other device-level quality signals. Google states that poor core-vital performance can reduce your app's discoverability or trigger a warning on the store listing (Android vitals documentation).
The point for a commerce team is to translate the engineering metric into a customer moment:
| Android signal | Commerce interpretation |
|---|---|
| Crash rate | A customer may lose a browsing, cart, checkout, or login session |
| User-perceived ANR | The app visibly freezes while a customer is trying to interact |
| Slow startup | A customer waits on a blank screen before they can shop |
| Permission-denial rate | A notification, location, or camera request may be poorly timed or explained (Android vitals permission data) |
| Device-specific issues | A checkout or catalog problem may hit only certain Android models or OS versions |
So Android quality is not just engineering hygiene. It can affect conversion and store visibility at the same time. (Whether customers are leaving the active base altogether is a separate question, and it lives in the user loss statistic covered above, not in vitals.) One scope note: Android vitals covers apps installed through Google Play on certified devices, so it is not a complete view of every Android distribution.
Reviews and ratings as product and customer-service intelligence
For a retail app, reviews often expose issues that store analytics will never surface: login failures, discount-code or loyalty confusion, checkout friction, delivery expectations, missing sizes or product-search gaps, and slow performance on specific Android devices.
Play Console lets teams break ratings down by country, language, app version, Android version, device type and model, and carrier. Its reviews analysis also summarizes recurring positive and critical themes (for reviews written in English), shows how each topic affects your rating, and compares your ratings with peer apps (Google's ratings and reviews documentation).
Treat that as a public, structured voice-of-customer program, not a reputation-management chore. When the same complaint clusters on one Android version, you have a bug report with a customer count attached.
One rule to hold: never offer a discount or incentive in exchange for a rating. Google prohibits incentivized ratings and reviews (Google Play's user ratings policy), and it is not worth the risk to the listing.
Monetization: why physical-product revenue is not in Play Console
Here is the caveat that most Play Console guides skip, and the single most useful thing to understand if you sell physical products. It mirrors the boundary on the Apple side exactly.
Google Play's revenue, buyers, orders, subscriptions, and financial reports measure transactions processed through Google Play's billing system, which is for digital products, digital content, and digital services. Google explicitly states that physical goods, including groceries, clothing, home appliances, and electronics, are not supported by Play Billing (Google's guide to the Payments policy).
When a customer buys a swimsuit or a bag of coffee in your app, that sale checks out through Shopify and your own payment processor. Google does not charge a Google Play Billing service fee on that physical-goods checkout, because the transaction does not run through Play Billing at all. (That is a narrow point about physical goods, not a claim that Google never charges fees: it does take a service fee on digital sales that do run through Play Billing.) The consequence is that revenue from your Shopify physical-product orders does not appear in Play Console's financial tabs. For a free Shopify app selling physical goods, those tabs will normally read empty or irrelevant. That is expected behavior, not an analytics gap.
The two-dashboard model: Play Console for acquisition and quality, Shopify for commerce
The practical takeaway is that the strongest brands run two dashboards and never confuse them. Here is where each number lives:
| You want to measure | Where it lives |
|---|---|
| Store visitors, installs, conversion, source, listing experiments | Google Play Console |
| Android crashes, ANRs, device-specific issues | Android vitals / Play Console |
| Web-to-app deep-link coverage | Play Console Deep Links |
| Google Play billing revenue, subscriptions, digital IAP | Google Play Console |
| Physical-product orders, AOV, repeat rate, LTV | Shopify + app platform |
| App versus web revenue share | Shopify sales-channel reporting |
Two more things to keep straight when you read across the tools. Installation metrics are reported in Pacific Time while financial data is in UTC, so do not join daily figures without accounting for the offset (Google's metric definitions). And a store-listing acquisition is not a customer, a purchase, or an order. Play Console measures the store and the device. Shopify measures the money. You need both open.
How NAPPS fits in
NAPPS, a native mobile app builder for Shopify and Shopify Plus brands, builds the Android app that Play Console then measures, and supplies the commerce half that Google's tool can't.
The differentiator isn't that NAPPS invented commerce reporting; Shopify already reports on any sales channel. It's how a NAPPS app is implemented. A NAPPS app is truly native (Jetpack Compose on Android, SwiftUI on iOS) and it's wired into your store as a Shopify sales channel, with checkout running through Shopify. So the app's orders, sessions, and revenue land in Shopify's own reporting next to your online store, and you can compare app versus web directly on metrics like AOV, repeat purchase rate, and revenue share. (How cleanly each metric resolves to a single customer depends on your login, identity resolution, and reporting setup, but the app-versus-web channel comparison is native to Shopify.) That's the reporting Play Console can't produce, because it never sees a Shopify order.
That's how NAPPS customers can report numbers Play Console will never surface. Across the customers we track, average order value runs +5% to +38% higher in the app, and spend per customer is typically about +47% higher.
Methodology: based on NAPPS customer data comparing the app channel with the online storefront. Results vary by brand, period, audience mix, and attribution; app audiences are self-selecting, so these comparisons describe observed differences and do not establish causal lift.
Zippy, Portugal's largest children's fashion brand, is the clearest example: within about seven months of launching a NAPPS app, roughly 34% of their total online revenue ran through it. Their app converts at about 6x the website and about 4.7x mobile web (+370%) over the same period (same methodology and caveats as above). Their push notifications, which announce app-exclusive price campaigns, average a 21% open rate. None of that lives in Play Console. All of it lives in Shopify and the app.
Use Play Console for acquisition, listing optimization, deep-link coverage, and Android quality. Use Shopify and your app channel for the money. That commerce half is where NAPPS reporting does its work.
Frequently asked questions
It's included with a Google Play Developer account, which has a one-time registration fee. (Setting one up as an organization? Our D-U-N-S number guide covers the verification step.) The analytics themselves carry no additional charge, and they cover acquisition, Android vitals, statistics, ratings and reviews, and Google Play billing monetization.
No. The financial reports only measure transactions processed through Google Play's billing system, which is for digital products and subscriptions. Physical goods are not supported by Play Billing, so they check out through Shopify, and your actual revenue appears in Shopify's sales-channel reporting and your app platform, not in Play Console.
Because your sales don't run through Google Play's billing system. Google's policy requires physical goods to be sold outside Play Billing (with no Google cut), so those orders never enter the financial reports. That's expected, not an error.
A user who installs your app while not already having it on another device. It filters out some re-install and multi-device noise, so it's a cleaner reach number than raw installs. It is still not a customer or an order.
Up to 50 alternate versions of your Play listing, targetable by country, audience, unique URL, Google Ads campaign, inactive users, or Play Search keywords. For a commerce brand, they let the listing behave like campaign landing pages, so the promise in an ad or email is matched by the screenshots that follow.
They can, in two ways. A crash or freeze during browsing, cart, or checkout costs you that session directly, and Google states that poor core-vital performance can reduce your app's discoverability or trigger a store-listing warning. So Android quality affects both conversion and visibility.
The bottom line
Google Play Console is a strong, granular tool for the acquisition and quality side of an Android app: a clear store-listing funnel, up to 50 custom listings you can match to campaigns, store listing experiments, a web-to-app deep-link report most brands overlook, user-level statistics, Android vitals, and structured reviews. What it does not measure is revenue from your Shopify physical-product orders, because those never touch Google Play's billing system. The brands that get the most from their app run both dashboards: Play Console for how the app is found, installed, and kept working, and Shopify plus their app platform for what it earns.
If you want an Android app whose revenue shows up as a real Shopify channel you can measure against your web store, see how NAPPS works.
Keep reading

October 27, 2026 - 10 min read
4 MobiLoud alternatives for Shopify: pricing and fit




October 23, 2026 - 8 min read
Tapcart vs Shopney: pricing, features, and which fits your Shopify store




September 18, 2026 - 13 min read
Tapcart Alternative: NAPPS Pricing, Features & Migration



