See Which Devices and Browsers Actually Install Your WordPress PWA
You shipped a WordPress PWA. Manifest looks fine. Icons are sharp. Someone says “people can install it now.” A week later nobody can tell you whether Android Chrome is converting, whether iPhone Safari is a dead end, or whether one country never sees a working install path.
That is a measurement problem. If you cannot see installs by device, browser, and country, you are guessing. Progressify ships install analytics for exactly that: real install events broken down so you stop arguing from anecdotes.
This post is about install analytics only. Not push notifications, not offline cache, not tab bars, not store bundles, not a deep dive into prompt timing or prompt styles. Prompt rules get a light mention as a related lever once you know where installs fail. For the PWA baseline in plain English, see What is a Progressive Web App (PWA)?. For the installed shell after the home-screen add, see app-like UI, tab bar, and transitions.
The problem: “it installs” is not a metric
Most WordPress PWA setups stop at “the prompt appeared on my phone.” That is a screenshot, not a system. You still do not know:
- Whether Android tablets install at a different rate than phones
- Whether desktop Chrome carries installs while mobile Safari barely converts
- Whether one country drives traffic but almost zero installs
- Whether a theme or CDN change broke the install path for a slice of users
Pageviews and bounce rate do not equal “added to home screen.” Without a clean install signal tied to device, browser, and country, you cannot answer the only PWA question that matters: who actually installed, and who never did.
Guessing leads to the wrong fix. You redesign the prompt when the real issue is a broken iOS path. You chase more traffic when one browser never meets installability. You blame “people do not want apps” when analytics would have shown solid Android installs and a cliff everywhere else.
What Progressify actually ships for install analytics
Stick to real features. No invented cohort builders or fictional heatmaps.
Install analytics by device, browser, and country. Progressify records install activity and breaks it down so you can see which devices, browsers, and countries convert. That is the core of this post.
Manifest, service worker, icons, and platform-specific install logic. Analytics only matter on top of a real PWA. Progressify handles the baseline: web app manifest, service worker, icons, and install behaviour that respects how iOS and Android actually work. Platforms are handled separately, not with one fake “works the same everywhere” claim.
Install prompt styles (context, not the focus). Banner, popup, overlay, button, and QR exist in the product. They are the surface people see. This article is about measuring installs, not picking a style.
Prompt rules as a light related lever. Visit count, time on page, and scroll depth can gate when a prompt appears. Dismissed stays dismissed. Once analytics show a weak segment, those rules are one place to tune. They are not a substitute for seeing the numbers first.
If the baseline is incomplete, analytics look empty for the wrong reason. Fix HTTPS, manifest completeness, icons, and a working service worker before you declare “nobody installs.”
How to use install analytics without fooling yourself
Treat Install Analytics like a weekly product review, not a vanity dashboard.
Confirm the PWA can install on real devices. Open the site on an Android phone in Chrome and on an iPhone in Safari. Complete one install on each path you care about. Launch from the home screen once. If the baseline fails, analytics under-report and you chase ghosts.
Open Progressify install analytics and set a baseline week. Note total installs, then the top devices, browsers, and countries. Write them down. “Android high, iOS low” is a decision. Your own phone is not a baseline.
Compare traffic share to install share. If one country is 40% of visits and 5% of installs, that is a product problem, not a content problem. If desktop Chrome installs while mobile Safari barely moves, fix the mobile path before you buy more phone traffic.
Segment before you redesign. Is the gap device (phone vs tablet vs desktop), browser (Chrome vs Safari vs others), or geography (different default browsers or OS mixes)? Fix the segment that is actually broken.
Use prompt rules only after you see the gap. If a segment sees the site but rarely installs, check visit count, time on page, and scroll depth. Too high and engaged people never see a prompt. Too low and it feels spammy. Dismissed stays dismissed, so a bad first impression costs that visitor. Tune lightly. Measure again.
Re-check after theme, plugin, or CDN changes. A new header script or caching layer can break installability for one browser while another still works. Browser breakdowns catch that faster than “it works on my Pixel.”
Ship one PWA owner. Deactivate competing PWA plugins before you trust the numbers. Two stacks fighting scramble install behaviour and make Progressify look broken when the conflict is the stack.
What a useful install breakdown looks like in practice
For a content site, useful means knowing whether phone readers add the home-screen shortcut, or whether installs are almost all desktop people who already bookmark everything. For a shop, useful means seeing if checkout-heavy countries install before return visits, and whether tablets behave differently from phones. For a membership or course site, useful means knowing if students on iOS ever complete install, or if your “app-like” promise only lands on Android.
Device tells you form factor. Browser tells you engine and install UX constraints. Country tells you market mix and default browser reality. Together they answer whether your PWA is a real channel or a feature you enabled once.
Pitfalls that make install analytics useless
Declaring success from one personal install. Your own phone is a QA check. It is not a sample.
Optimising prompt style before reading device and browser splits. A prettier banner will not fix a platform path that never becomes installable.
Ignoring iOS and Android differences. Progressify handles platforms separately for a reason. One prompt strategy does not equal one outcome across both.
Reading country data as “those users do not like apps.” Often it is browser mix, network quality, or a broken asset on that region’s CDN path. Investigate the stack before you write off a market.
Changing prompt rules every day. Dismissed stays dismissed. Thrashing visit count, time on page, and scroll depth burns first impressions. Change one lever, wait, compare the same breakdowns.
Skipping the post-install shell. Analytics tell you who installed. The installed experience still needs a solid UI. That is a different post (tab bar and app-like UI). Do not conflate empty analytics with a weak shell.
No weekly review. Analytics nobody opens might as well not exist. Pick a weekday, open the breakdowns, and decide one action or consciously wait.
How this fits DaftPlug Pro
Progressify is one of five Pro plugins on a single membership. One licence unlocks Progressify (PWA), Lightify (performance), Generatify (AI), Rankify (SEO and GEO), and Snapshotify (backups). Plans differ by site count only: Pro $37.99/year (1 site), Pro Plus $74.99 (5), Pro Max $138.99 (100). Features are identical across plans. Checkout is Freemius, with a 14-day money-back guarantee. See pricing.
Free Progressify on WordPress.org covers a lot of the PWA baseline. Install analytics by device, browser, and country are why teams that treat the home-screen add as a real channel move to Pro instead of flying blind after the first test install.
Takeaway
A WordPress PWA you cannot measure is a feature you hope works. Progressify install analytics by device, browser, and country turn that hope into a weekly number you can act on. Keep the manifest, service worker, icons, and platform-specific install logic solid underneath. Use prompt rules (visit count, time on page, scroll depth, dismissed stays dismissed) only as a light lever after the breakdowns show where installs stall. Then you stop guessing whether people install, and you start fixing the segments that do not. Start in Progressify and open install analytics on a real week of traffic, not a single test on your own phone.