# The Feedback Google Couldn't See On Friday, 21 August 2026, Google sent me the same email for the third time. The subject line read "More testing required to access Google Play production", and the body listed the same two possible reasons it had listed in May and again in July: my testers were not engaged with the app, or I had not followed testing best practices. There was nothing in it about my app in particular. There never was. ![The rejection email from Google Play Console, titled More testing required to access Google Play production, listing two possible reasons](https://cdn.hashnode.com/uploads/covers/64493e0be4da7ac60cc931b7/a1d80e4c-e615-42fa-9130-5bcbe0a96edd.png align="center") This time I had been sure. Twelve testers had stayed in my closed test for the whole window, most of them opening the app every day, and I had shipped two releases five days apart, all of it tracked in my own database. None of that moved the answer. It took four applications and nearly five months to get Akluma onto Google Play, and each rejection corrected a wrong idea I held about what the review measures. The application that finally passed came from a round in which fewer people opened the app each day than in the round Google had just turned down. ```text Application 1 11 May rejected 13 May Application 2 17 July rejected 25 July Application 3 18 August rejected 21 August Application 4 10 September approved 12 September ``` [Akluma](https://akluma.com) is a free savings tracker I built with Laravel: you set a savings goal, it builds a dated plan and emails you a reminder on each saving date, and it recalculates the plan when life gets in the way. I wrote about how that plan rewrites itself [in an earlier post](https://ubeyd.dev/the-savings-plan-that-rewrites-itself). This one is about getting it into a store. ## A web app in an Android shell Akluma is a web app, and why it needed a store listing at all is a story I told [in a post about my keyword research](https://dev.to/ubeydullah/i-did-keyword-research-for-my-savings-app-then-i-actually-looked-at-the-search-results-ld6): most people find apps by searching inside the store, and my research had been blind to that whole channel. The way to put a web app into Google Play is a Trusted Web Activity, a thin Android app whose only job is to open your website full screen in Chrome. There is no second codebase. The app on your phone is akluma.com without the address bar, running against the same server and the same database, and every web deploy reaches it the moment it ships. Setting that up took about a week in April, and only one detail from it is worth passing on. The file that proves you own the domain, `assetlinks.json`, has to carry the fingerprint of Google's app signing key and not only the key you upload with, because Google re-signs your app before it reaches anyone's phone. Leave Google's fingerprint out and the address bar appears inside your app. Then came the requirement I had not planned for. Google asks [new personal developer accounts](https://support.google.com/googleplay/android-developer/answer/14151465) to run a closed test with at least 12 testers opted in for 14 continuous days before they can even apply for production. My identity was verified on 20 April, the first release went to closed testing on 24 April, and twelve testers for fourteen days sounded like arithmetic. ## Round one: twelve people and a calendar My first theory was exactly that: the gate is arithmetic. Find twelve people, keep them enrolled for fourteen days, apply. So I asked family and friends over WhatsApp to install the app and, above all, not to tap "Leave the program". I did not ask anyone to use it, because by the letter of the rule nobody had to. I even got the arithmetic wrong at first, holding back my submission because I had read that the 14-day clock restarts with every tester you add. It starts when testers opt in, and the opt-in link only exists once Google has published your release, so you have to submit before you can recruit anyone. The clock has stranger habits than that, which get their own post later in this series. I applied for production on 11 May, and two days later the first rejection arrived. Its first possible reason was "Testers were not engaged with your app during your closed test." It was right. When I finally audited that round in July, only 3 of the 13 people on my list had ever registered an account in the app, and one of the three was me. One good thing did come out of it. On 14 May my wife, who had been using Akluma on the web for most of a year, left this in the closed test's feedback: > It's a very useful app to set and track saving goals. Easy to use and convenient with the automatic email reminders. What I would suggest adding is the possibility to choose or change the date for the automatic reminder (for example so you can set it around the time when your salary is paid or similar). I filed it as a good idea for later. It would matter far more than I expected. ## Round two: paying for engagement By June I understood that engagement was the problem, and my second theory was that engagement could be bought. Swapping tests with other developers cost more hours than I had, so I paid a Fiverr seller $30 for a batch of testers. When I checked my database on 9 July, 12 of the 31 people on the list had registered, 4 had an active savings goal, and exactly one had ever moved money. The seller offered me a ready-made answer sheet for Google's application form that described improvements I had never made, and I did not use it. Around 17 July the testers' five-star reviews vanished from my console, most likely removed by Google's checks for coordinated reviews, though that is my inference. Fiverr refunded the order at the end of July, and through all of August, Play's statistics still counted around ten of those testers with the app installed and not one of them opening it. The real lesson of that round came from a question I should have asked in April: what can Google actually see? Akluma is a Trusted Web Activity, which means that everything a tester does inside it, from registering to creating a goal to adding money, happens in Chrome. Play sees none of it. What Play can see is whether the app gets opened, and on how many different days. I had spent a month asking people to create piggy banks, and piggy banks are invisible to Google. I applied again on 17 July, with answers I wrote myself and kept honest. On 25 July the same email came back. ## Round three: measuring what Google measures My third theory was that if Play counts opens, I should count them too, and drive them on purpose. Before asking anyone for anything, I built the instrument: one row per user per day, the installed app told apart from a browser tab by the referrer Android attaches at launch, a heartbeat counting seconds on screen, and an admin page showing exactly which testers had gone quiet. It went live on 3 and 4 August, and I will come back to how it works. Then I designed the ask around the one habit Akluma naturally creates. A savings plan can be daily, weekly or monthly, and every saving date sends a reminder email at nine in the morning. So I asked each tester to create one small daily piggy bank, a couple of weeks toward something modest. A daily plan produces about thirteen reasons to open the app in fourteen days, where a weekly one produces two. ![Akluma's saving reminder email on an Android phone, the daily prompt that brought testers back to the app](https://cdn.hashnode.com/uploads/covers/64493e0be4da7ac60cc931b7/6545700f-578f-4efb-90e3-ee8617bfbdba.jpg align="center") From 5 August I messaged testers one by one on WhatsApp almost every day, and 12 of the 13 engaged, nearly all of them daily. I also shipped. Version 4 went out on 13 August with the feature my wife had asked for in May: on a monthly plan, you can now choose the day of the month your reminders arrive. Version 5 followed on 18 August and replaced a dashboard that had been showing placeholder figures. Those releases mattered twice over, because a web deploy is invisible to Play, and the only update Google can see is a new bundle on the testing track. I applied on 18 August. On 21 August I got the email at the top of this post. ## What I told Google, and what it could see Play Console has a page called Testing feedback, under Ratings and reviews. It is where testers' private feedback lands when they use the "Private feedback to developer" control on the app's Play Store page, and I had looked at it plenty of times over the summer. I never treated it as evidence. The application form asks how you collected feedback from your testers, and I had answered truthfully: over WhatsApp. Once I had told Google where the feedback lived, I assumed it made no difference whether any of it also appeared on that page. It did not help that after the paid reviews vanished, I had stopped asking testers to write anything on Play at all. The day after the third rejection, I read the page the way a reviewer would. Filtered to all time, it held one item: my wife's, from 14 May, on version code 1. Across the whole span Google had just evaluated there was no new feedback, and the only activity was my own reply to her, posted on 13 August, telling her that the feature she had asked for was live. Meanwhile that round had produced three useful new pieces of feedback, and all three sat in WhatsApp, where Google has no way to look. ![The Testing feedback page in Play Console, showing my wife's five-star feedback from May and my reply from August](https://cdn.hashnode.com/uploads/covers/64493e0be4da7ac60cc931b7/859b10fc-5c96-4123-a634-5d4f7100cd23.png align="center") Google's requirements page for new accounts asks you to "summarize your testing feedback when applying for production access", and I had. What I had not given Google was any way to check the summary. From the reviewer's side of the table, my answer about feedback was a claim with nothing behind it. I want to be careful here, because Google never told me this was the reason. It gave no reason at all, three times, and a support ticket asking what exactly had been judged insufficient came back with a list of best practices. That near-empty page is one of three explanations I believe fit. The second is that my testers' usage looked instructed, because it was. The third is that numbers which looked healthy over my own fourteen days looked thin over Google's twenty-four, which began at the previous review date on 25 July, eleven days before I began onboarding my testers. Two other theories died over the following weeks. Google's support told me to fix the issues in my pre-launch report, which had never been generated, and after six uploads support admitted that it cannot generate below an activity threshold they would not name. And for one day I was convinced Play could not see a Trusted Web Activity at all, until Play's own chart of daily users showed that it could. ## Round four: evidence where Google can see it The fourth round started without me. Google's 14-day counter restarts on its own at each review date, and my twelve testers had never left the programme, so the app became eligible to apply again around 5 September without a single new recruit. That left me with one simple rule for tester lists: add people, never swap them, because a single dip below twelve restarts the count. I did try to add people. On 24 and 25 August I emailed 32 existing users of the web app, a personal note to each, inviting them to join the test. None of them did. So the round came down to the one thing I could still change: putting evidence where Google looks. On 25 August I asked my family and friends to leave private feedback on the app's Play page, and instead of a general request I gave them two questions, in Turkish, that amount to: what would you want to be different in the app, and which part confused you? A general ask produces "great app". A specific question produces something you can act on. Eight pieces of feedback arrived over the next four days, and versions 7 and 8 shipped within two days of them, answering four. The buttons for adding money moved to the top of a goal's page, and every tappable row on the dashboard gained an arrow and a pressed state, because three testers had separately told me they could not tell what was clickable. Every item got a reply in the console, including the two where the thing a tester wanted already existed and my reply told them where to find it. Version 9 followed on 9 September, the ninth release on the testing track. I rewrote the application to one rule: cite only what Google can verify on its own side. Dated releases, release notes, feedback items and my replies to them are all events inside Google's system, while numbers from my own database, however careful, verify nothing for a reviewer. Each written answer had to fit in 300 characters, which is a discipline of its own. I applied on 10 September, and the approval arrived on 12 September. On 14 September I sent the first production release for review, and it was live about two and a half hours later, in 177 countries. The French and Turkish listings followed the next day. ![Akluma: Savings Goal Tracker on its public Google Play page](https://cdn.hashnode.com/uploads/covers/64493e0be4da7ac60cc931b7/fac0aa96-9148-4b12-b537-38b376083a73.png align="center") ## What changed, and what I can't claim The strangest part of the whole story sits in Play's own chart. The round Google approved had fewer people opening the app than the round it rejected. From 5 to 21 August, Play counted between 4 and 10 daily users, most days between 5 and 9. From 22 August until the day I applied, it counted between 1 and 5, partly because I had told my testers they no longer needed to open it every day. ![Play Console daily active users from 25 July to 12 September: near zero until 5 August, between 4 and 10 until 21 August, then between 1 and 5](https://cdn.hashnode.com/uploads/covers/64493e0be4da7ac60cc931b7/43285b81-6344-443b-949a-453b2526a21c.png align="center") So more engagement is not what changed. What changed is where the evidence lived: feedback inside Google's own channel with a reply under every item, releases that answered specific feedback within two days, and an application that cited nothing Google could not check for itself. I believe that is what made the difference. I cannot prove it, and Google has not said. If you are stuck behind the same requirement, this is what I would take from my five months: 1. The reviewer judges what Play Console shows. Effort that leaves no trace there does not count. 2. Play cannot see inside a Trusted Web Activity. It counts opens. 3. Describing feedback in the application is not the same as Google seeing it. Ask testers for private feedback on Play with a specific question, and reply to every item. 4. A web deploy is invisible to Play. A new bundle on the testing track is the update it sees. 5. Paying for testers bought me one tester who ever moved money, and a block of installs that sat unopened in my statistics for weeks. As for how the launch is going, it is too early to say anything honest. Akluma has been on Google Play for a week, the public listing shows 10+ downloads, and Play's own statistics run days behind. What I can say is that it is there, in English, French and Turkish, and that it is the same app the web has been running for over a year. Akluma is on [Google Play](https://play.google.com/store/apps/details?id=com.akluma.app) and at [akluma.com](https://akluma.com) if you would like to set a goal and see whether the plan holds. * * * *This is the first post in a short series on getting Akluma onto Google Play, and the next four each take one finding from this story further. For the background,* [*I did keyword research for my savings app. Then I actually looked at the search results.*](https://dev.to/ubeydullah/i-did-keyword-research-for-my-savings-app-then-i-actually-looked-at-the-search-results-ld6) *explains why a web app needed a store listing at all, and* [*The Savings Plan That Rewrites Itself*](https://ubeyd.dev/the-savings-plan-that-rewrites-itself) *covers what the app does.*