@Darlynn Morgan let's continue in the DMs! sent you a message :)

Good questions, and the right ones to be asking before you submit rather than after. 📌 ONE STRUCTURAL THING THAT CHANGES EVERYTHING ELSE Since your shell loads live from server.url, your fixes do not go through App Store review. You fix the web app, hit Publish in Base44, and every user has the fix on their next launch. That is a big advantage over a normal native app, where a hotfix is a review gamble. the flip side is that a bad publish also hits everyone at once, instantly. So your discipline moves from "test before you submit" to "test before you publish." Your editor version and your published version are separate in Base44, which is your safety net. Use it. One warning on live loading. Pushing web updates into a wrapper is fine with both stores, but do not use it to change what the app fundamentally does after review, and do not quietly introduce an external payment path on iOS. That is the thing that gets wrapper apps pulled. 📌 ALERTING, SO YOU ACTUALLY FIND OUT Sentry does not meaningfully notify anyone by default. Set this up now, not after your first outage. - Set the environment value in Sentry.init so production events are separate from anything you trigger in the editor. Every alert rule then filters on production only. - Tier 1: a new issue type appears in production, send to email plus Slack immediately. At launch volume this is fine, you will not drown. - Tier 2: error rate spike, something like 10x baseline inside 5 minutes. Do not invent a threshold before you have a baseline. Launch, watch for two weeks, then set the number form real traffic. - Tier 3: a weekly 15 minute review of your top 10 issues sorted by affected USERS, not by event count. One error hitting 400 people matters more than 4,000 events from one stuck bot - Turn on Spike Protection in your org settings. The free tier is 5,000 errors per month and one runaway loop eats that in an afternoon. - Add your production domain to Allowed Domains in the Sentry project settings. Small note on your setup. A Sentry DSN is public by design, it is meant to sit in client code. Routing it through a backend function is not wrong, it just is not buying you security. Allowed Domains plus rate limiting is what actually protects the project.

@Rommel Cabal Good. That activation definition is the right one, and the fact that it is two steps is useful on its own. Saved birthday and favorited a perk are separate drop off points, so track them as separate events and you will know which half is leaking. 📌 YOUR RETENTION PROBLEM IS A MEASUREMENT PROBLEM FIRST Classic D1, D7 and D30 retention counts whether a user was active on exactly that day. For an app with an annual payoff that number is not low, it is irrelevant. You would be measuring your app against a question it was never built to answer. There are three ways to measure retention and almost nobody specifies which one they are using. Classic N day, which is active on exactly that day. Rolling, which is active on that day or any day after. Range, which is active at any point inside a window. For seasonal and low frequency apps, range retention over the real cycle is the honest read. Tax apps, travel apps and insurance apps all live with this. so your headline retention number is not a day count at all. It is this: "Of users who saved a birthday more than 12 months ago, what percentage opened the app during their birthday month?" That is the one number that proves PerkFinder works. The problem is obvious, it takes a year to arrive, and you need to make decisions before then. 📌 WHAT TO MEASURE IN THE MEANTIME You have an advantage most apps do not have. Your users TELL YOU their birthday, so you always know exactly who should be active right now. Use it. - Segment every user by days until their next birthday. Birthday within 30 days versus everyone else. These are two completely different populations and blending them into one DAU number destroys the signal. - Expected active share. Birthdays spread fairly evenly across the year, with a mild late summer bump in the US. So at any given moment roughly one twelfth of your users should be in their birthday window. If your monthly actives sit far below total users divided by 12, your reminder channel is broken, not your product.

Just wanted the community to know that we've moved this conversation in DMs days ago. Feel free to DM as well!