01
Advanced diagnostics
naming-mismatch and static-value traps most tools miss, ATT consent tracking with built-in prompt-timing experiments, daily paywall-change monitoring, and price-tier cohort quality — see which tier attracts users who actually stay
02
Release Regression Detector
links every metric change to the exact release, device, and feature flag involved — catches a regression within hours of rollout, not after it reaches every user
03
Crash & Hang Context Graph
goes beyond a bare stack trace to the user's last 20 steps, device, OS, and active experiments — turns 'we can't reproduce it' into a specific, fixable pattern. Ranks likely root causes with real evidence for and against each, classifies exactly which system API blocked the screen during a hang, can flip a connected feature flag off the moment a serious cluster is detected, and can draft a suggested fix (from a text sketch up to a real branch and Pull Request) attached to the GitHub issue it can file for you — every draft clearly labeled as unverified AI output that a human reviews and merges, never applied automatically
04
Startup Path Decomposer
breaks cold/warm/hot startup into phases (SDK init, migration, auth, first frame) so you know exactly which one is costing real users the most time
05
Push Delivery Truth Engine
Madar sends push on your behalf via your own Firebase project and tracks exactly what happened to each one, past the point where most tools just say "sent". Every rejected delivery is grouped into an actionable cause rather than a raw error code — separating routine token churn from a wrong-Firebase-project error that means nothing is reaching anyone. And a campaign that is still sending can halt itself when opt-out spikes against your own app's baseline, protecting the audience that has not been sent to yet
06
Deep-Link Journey Verifier
confirms a tapped link actually reached its intended screen, even through a login gate — not just that the routing decision was computed. Now separates WHY a link failed — a login wall that lost the destination, a route your app has no handler for, or the right screen reached without the link's parameters, which looks like success to any check comparing route names. Destinations are ranked by how many users they cost you, not by failure rate. Register the routes your app actually handles and Madar checks a campaign link BEFORE you send it — catching a link pointed at a renamed route, or one that will drop a logged-out audience at a sign-in screen, while you can still change it
07
Offline Sync Integrity Engine
catches an unstable retry key that silently duplicates a customer's action on your server, and flags a queued change that got stuck and never made it back. Now also detects two devices genuinely racing to edit the same record, and a queue bug that enqueues one logical operation twice under separate IDs — each with a drafted fix recommendation and a single sync health grade for the whole app
08
Mobile Root-Cause Brain
when a release breaks something, aggregates every finding across every Madar tool into one Root-Cause Portfolio instead of a single rushed guess. It also remembers: every incident is recorded with the SHAPE of the change that caused it and what it cost, and any future change is checked against all of them before it ships — so eighteen months later, when somebody who was not there proposes the same thing, Madar says it resembles the incident that cost 14% of checkout in 4.2.0. A post-mortem cannot do this, because prose cannot be compared against a pull request. Madar warns and never blocks: a resemblance is a reason to look, not evidence of a repeat. And when you have several fixes to make, it sequences them: measurement first regardless of impact, because a verification run against broken analytics is not inconclusive but meaningless — it produces a confident number computed from wrong data. Containment before repair, and one root fix per stage, because shipping five fixes in one release destroys the only thing that would have told you whether any of them worked
09
Screen Usability Readiness Monitor
measures the real gap between a screen opening and a user actually being able to tap something on it, AND breaks that gap down into a full seven-stage funnel (first frame, controls enabled, critical content, first interaction, interaction success, full content) so you see exactly where the delay sits, not just that one exists
10
Frame Jank Attribution Engine
surfaces scroll jank and frozen frames by device model — smooth on a flagship, stuttering on a mid-range device, with no crash anywhere to explain why. Ranks which real factor (image decoding, list scrolling, heavy animation, a third-party SDK overlay) is actually driving the jank, and on Android, captures the genuine measured time spent on every rendering stage — layout, draw, GPU commands, buffer swap — the same depth of data Android Studio's own Profiler uses
11
Long-Tail Experience Analyzer
flags metrics where the slowest 1% of experiences is far worse than typical — a healthy-looking average can still hide a genuinely bad tail. Names exactly which device, OS version, network type, or country is overrepresented in that slow tail, and can draft a segment-specific containment and root-fix recommendation from the evidence
12
API Latency Decomposer
flags endpoints where the app waits far longer than the server itself reports — the gap is time lost to DNS, connection setup, transfer, parsing, or on-device processing, settling the classic backend-vs-mobile blame game with one number. Breaks that gap into real sub-phases, statistically correlates it to an oversized payload, excessive retries, or a cache-miss problem with a drafted fix recommendation, auto-derives each endpoint’s own payload and latency ceiling from its healthy baseline to catch future regressions, and can trigger a live Remote Config fallback the moment a ceiling is breached
13
False Success Detector
catches operations where the app tells the customer it worked, but the backend never durably committed it - exactly the gap that pushes a confused customer to retry and create a duplicate order or duplicate payment. Classifies each case into a specific root cause (a lost response after a real commit, a genuine never-confirmed failure, or a client-side optimistic-UI bug), and lets you declare your own Outcome Contract per operation type — the exact conditions that must hold before Madar calls something truly successful
14
Identity-Safe Cache Auditor
catches a cache entry written under one signed-in user being read back while a different user is active - a genuine privacy risk on shared or multi-account devices, intermittent enough that it rarely surfaces in manual testing. Classifies each leak into a specific root cause (a missing identity key, wrong environment, a logout that never purged the cache, and more), drafts a fix for it, and lets you declare a Cache Ownership Contract per key that catches the architecture gap before any real leak happens
15
Auth Loop & Token Race Detector
catches users bounced back to login repeatedly, and concurrent token-refresh attempts racing each other - both inherently hard to reproduce. Classifies each incident into a specific root cause (device clock drift, a genuinely revoked session, a failed secure-storage write, and more) and drafts a fix for it. Lets you declare an allowed set of session-state transitions and catches any illegal one the moment it happens, not just after it accumulates into a pattern
16
Duplicate Identity Resolution
surfaces devices that signed in as two or more different accounts within 30 days. Now grades every candidate across four confidence tiers — from a confirmed match sharing a verified identifier, down to an explicit unsafe verdict when the two accounts carry conflicting verified identities, meaning they are two different people sharing a device and must never be merged. Only the confirmed tier is ever marked safe to merge. A pre-signup check also runs before a new account is created, showing someone that they already have an account instead of letting a second one appear — it only informs, never blocks a signup. Every check is recorded, so you get a real count of how many duplicate accounts were actually prevented rather than an estimate — counting only the near-certain matches, never inflated with shared-family-device cases
17
Account Deletion Proof Engine
catches deletion requests that never receive a matching durable confirmation - carrying its own legal and trust weight beyond a failed purchase, since a subscription surviving a deletion means continued billing for a customer who explicitly asked to leave. Now tracks every data source separately — auth, analytics, billing, each vendor — across six outcomes including anonymized and legally retained, and generates an auditable per-system report you can hand to a regulator. A system that never reports back is recorded as unknown and blocks the proof: a silent vendor is never assumed to have succeeded. Register each system up front with a named owner and a stated deletion policy, and a vendor you added but never wired up stops being invisible — its silence shows up in every proof instead
18
Background Execution Reliability Monitor
catches scheduled background or silent-sync tasks that never actually run - the OS may defer or drop the work to protect battery and resources, and there's no guarantee a scheduled task runs anywhere near its intended time. Now also measures HOW LATE tasks actually run — a nightly sync that lands the next evening technically ran, but your users saw stale data all day — and separates delays you can fix in your own code from ones caused by OS battery management, so your backlog does not fill with tickets nobody can close. Register a delay budget, an owner and a recovery policy per job, and a task whose app forgot to declare its own tolerance stops being invisible — it can finally be counted late
19
Billing Acknowledgement Guardian
catches purchases at risk of Google Play's automatic refund because acknowledgement was slow or never happened - Google requires acknowledgement within 3 days, and a silent handler failure can make a genuinely paid customer lose what they bought. Now shows a per-transaction countdown instead of a rate — which purchase has hours left, ordered by time remaining rather than value, because a small one about to expire cannot wait while a large one with a day of runway can. Money is split into what is still saveable and what is already gone, since those call for entirely different responses. Failed acknowledgements are also classified by cause — separating a revoked service account, which blocks every purchase until someone re-grants it, from a single malformed token that affects nothing else. Both arrive from Google as the same class of error, and confusing them sends you auditing credentials over one bad token
20
Subscriber Quality Intelligence
flags acquisition sources where paid conversions immediately refund or cancel within days of first billing - separating a genuinely engaged paying customer from one who converts once and leaves right away, inflating that source's reported performance. It also refuses to grade a source before its quality window closes — a cohort that started yesterday has no reversal rate at all, and Madar reports that as 'too early' rather than as a zero, because a zero and an absence of data look identical on a dashboard and one of them reads as a green light. And once a source can be judged, it is graded against your OTHER sources rather than a fixed number — if your healthy traffic sits at 3%, a source at 12% is a serious problem that any absolute threshold waves through, and if your whole business runs at 14% an absolute bar would flag everything you have. When a source is severe, well-evidenced and large enough, Madar recommends pausing spend — but only when all four conditions hold at once, and it lists every gate that blocked a recommendation so you see whether a source was one condition away or three. Madar never pauses anything itself; it does not touch your ad accounts. And if you supply what a subscriber costs you to serve, Madar reports contribution rather than revenue — catching a source with zero refunds and happy renewals that still loses money on every subscriber, which every other quality signal would call excellent
21
Paywall Integrity & Economics Auditor
flags a paywall where a meaningful share of purchase-button taps never result in the native store purchase sheet appearing at all - a specific, fixable technical bug costing real revenue, distinct from a customer who sees the sheet and simply declines. Before you ship a new paywall it also checks three things conversion cannot see: whether some regions physically cannot buy, whether the price and restore button are reachable with assistive technology, and whether unclear trial terms are lifting conversion while raising refunds with it — the failure that looks most like a win. And when you A/B test a paywall, Madar judges the result on net revenue after refunds rather than conversion — a variant that lifts conversion while raising refunds is reported as a loss, because judging on conversion alone actively rewards the variants that promise most and disclose least
22
Release Retention Causality Engine
compares D7 retention release-over-release and flags a meaningful drop right after a new version ships - before it quietly gets written off as normal variance instead of being traced back to the release that actually caused it. It also judges a rollout on four dimensions rather than crashes alone — a release can be entirely crash-free and still be the worst thing that happened to your app that quarter, and a dimension you did not measure is reported as unchecked rather than passing. And when something does regress, it attributes the damage to the individual changes in that release, so you revert one instead of twelve — while refusing to clear a change that reached every user, since those are the ones most likely to be responsible
23
Activation Truth Engine
flags a large gap between onboarding completion and reaching a real first-value moment - a completion metric that doesn't correlate with actual product value means every onboarding tweak is optimizing for the wrong outcome. It also judges each individual step against the users it costs — a step can genuinely help the people who finish it and still be a net loss, and reporting that completers do better without the drop-off is exactly how a harmful step survives review after review. Steps whose advantage is small enough to be explained by motivated users self-selecting are reported as unproven, not justified. And because a step that saves one audience can kill another, each one is also judged per intent cohort — two groups at +40% and -40% average to zero, the same number a step nobody notices produces, and the right answer there is to make the step conditional rather than delete it or keep it for everyone
24
Permission Friction Intelligence
flags a permission where users who denied the prompt return at a far lower rate than users who granted it - the friction from a specific prompt, made directly measurable instead of a vague sense that retention feels lower lately. It also asks the question that would have prevented it: does this permission have a fallback at all? On camera, location and notifications the system prompt appears once, so a permission without one does not cost you a conversation — it costs that user the feature forever, from a single tap made before they had any context. Permissions your app asks for that nobody registered with an owner, a user-facing value and a fallback are listed separately. And when you change a prompt, Madar judges it on the outcome rather than the grant rate — an earlier, more insistent prompt reliably lifts grant rate while people turn the permission off in Settings and the feature it unlocks goes unused, which every permission dashboard reports as a win
25
Battery Drain Causal Profiler
flags an abnormally high battery drain rate while the app sits in the background - a backgrounded app should be nearly idle, so real drain points directly at excessive wakeups, background network calls, or a location/sensor mode left running longer than intended. Set a battery budget per feature and per SDK before it ships, and Madar shows which one is over and by how much — a third-party SDK's energy cost is never published by its vendor and disappears into normal variance when you measure the app as a whole, so it goes unnoticed until a phone dies before evening and produces a one-star review about battery and no bug report. The number worth watching most is the drain nobody has attributed to any component at all. Madar also recommends an energy posture from the device's actual state — the same work is free on a charging phone and takes a share of the last half hour on a phone at 8%, and on a thermally throttled device it runs slower AND drains more, so the user gets a hot phone, a slow app and a flat battery from one behaviour. Thermal state outranks charging: a phone charging while critically hot still gets background work suspended
26
Third-Party SDK Risk Ledger
flags a third-party SDK when it accounts for a disproportionate share of your app's total crash volume - concrete grounds for a vendor conversation, version pin, or replacement, instead of a vague sense that crashes just happen sometimes. It also checks each SDK against seven admission requirements and scores it on declared value minus performance, privacy, maintenance and risk cost. The one that matters most is the removal plan, because an SDK without one is not merely undocumented — it is permanent by construction: from the day it ships, removing it becomes a research project, and research projects lose to the roadmap. Madar also finds SDKs doing substantially the same job — each scores fine alone, because each genuinely does something useful, and nobody ever compared them: every one entered through a separate decision by a different team at a different time. And it flags any SDK contacting a host that is not in your privacy declaration, which makes that declaration wrong rather than merely slow — something you cannot find by reading your own code, because the call is inside someone else's binary
27
Silent Failure Intelligence
flags a non-fatal failure type where affected users return at a meaningfully lower rate than a no-failure baseline, AND traces individual actions end-to-end (started → processing → result → confirmation) to catch the ones that go silent - a button tap that never resolves, a success screen the backend never actually confirmed, a spinner that never stops
28
Memory Intelligence
a P50/P90/P99 view of daily peak memory across your devices and versions, plus - once the latest SDK is installed - a real per-screen memory curve for every session, flagging the specific screen where memory climbs and never comes back down
29
Purchase-to-Entitlement Auditor
catches paid customers who never got what they paid for, tracing the full chain from store transaction to entitlement grant to find exactly where it broke. Now checks the reverse too — access still active after a refund, revoke or expiry, which nobody ever reports because no one opens a ticket to say they are getting something free. Both directions come with a dollar figure: what was taken from customers who cannot use it, and what is leaking every month to accounts that stopped paying. Every mismatch becomes a tracked incident with a deadline — 24 hours for a paying customer who cannot access what they bought, a week for a slow leak — so a gap has an age instead of reappearing unchanged in every report, and a problem that comes back is flagged as a recurrence rather than looking new
30
Subscription State Reconciler
keeps Apple, Google, and your backend in agreement on every subscriber's real status — trial, grace, billing retry, canceled-but-active, and more. Now also catches event histories that are internally impossible — an expiry followed by a renewal resolves to a sensible final state while being a sequence no store produces, and it is the early warning that a webhook pipeline will eventually get someone's access wrong. And before Madar corrects anything, a shadow ledger runs its verdict alongside yours without touching a thing, so you can see how often they agree on access before trusting it with a decision that can take a paying customer's product away. And when it does recommend an action, the two directions are held to different bars on purpose: restoring access needs only reasonable evidence because being wrong is recoverable, while ending access needs the store's own confirmation — anything weaker gets flagged for you to decide rather than acted on
31
Mobile Analytics Truth Firewall
flags chronologically impossible event sequences and duplicate signatures before a broken metric drives a real decision. Register the events you actually make decisions from and Madar checks a build against them in CI, so a release that renames an event or changes a field's type fails there instead of going quietly wrong on a dashboard for weeks — a revenue field that starts arriving as a string still fills the chart, it just sums to zero. And when you find a window that was already broken, mark it quarantined — Madar then stops every automated recommendation from being built on it, including its own advice to cut spend on a source whose numbers only look bad because its events were broken that week
Every system below is included in Full, Growth and Enterprise. Tiers differ by capacity and governance, not by which systems you get.
