DEV Community: Appluck

Calculating LTV for Mobile Games

Appluck — Tue, 16 Jun 2026 02:27:39 +0000

LTV — lifetime value — is the average revenue a player generates over their lifetime in your game. It is the number that tells you how much you can afford to spend acquiring a player. Get it wrong and you either starve growth or buy your way to bankruptcy. This guide walks through how to actually compute it.

Cumulative LTV, not a magic constant

In games, LTV is almost always cumulative: revenue accumulated per player up to day N since install.

LTV(N) = total revenue from a cohort in their first N days / cohort size

So you do not have one LTV — you have a curve: LTV(0), LTV(7), LTV(30), LTV(90), LTV(180). The curve rises fast early and then flattens as the cohort stops spending. The shape matters more than any single point, because it tells you when you recover your acquisition cost.

A subtle point: LTV(N) is a cohort metric, denominator-anchored on day 0. Everyone in the cohort stays in the denominator forever, including the 95% who never pay. That is correct — they cost money to acquire too.

Payer distribution and whales

Average LTV hides an extreme distribution. In most free-to-play games, revenue is brutally concentrated:

The vast majority of players never pay at all.
A small slice of payers ("dolphins") spend modestly.
A tiny fraction ("whales") drive the bulk of revenue.

If you only look at the average, you will misread everything. Pull the payer distribution — bucket players by total spend (e.g. $0, $0.01–$10, $10–$100, $100+) and look at how much each bucket contributes. When the top bucket carries half your revenue, your retention strategy for those players is your revenue strategy. The game analytics views in Keentics surface this whale curve directly.

ARPU vs ARPPU

Two averages, often confused, both useful:

ARPU — Average Revenue Per User. Total revenue ÷ all active users. Includes non-payers.
ARPPU — Average Revenue Per Paying User. Total revenue ÷ paying users only.

The relationship:

ARPU = ARPPU × pay-rate

This decomposition is the actionable part. If ARPU is low, is it because few people pay (low pay-rate → fix the first-purchase funnel) or because payers spend little (low ARPPU → fix pricing and depth)? Two completely different roadmaps. Use a funnel analysis on the path to first purchase to find where would-be payers drop.

LTV against CAC and ROAS

LTV only means something next to what a player costs:

CAC — Customer Acquisition Cost — what you paid to acquire that player.
ROAS — Return On Ad Spend — revenue ÷ ad spend, usually quoted at a day window (D7 ROAS, D30 ROAS).

The core rule: LTV must exceed CAC, with margin. Because LTV is a curve, the real question is when cumulative LTV crosses CAC — your payback period. A channel that pays back by D30 is a money printer; one that pays back at D400 is a loan you may never collect, because the cohort decays first.

break-even: LTV(N) ≥ CAC
D30 ROAS = revenue through day 30 / ad spend

Always compute this per channel and per cohort, never blended. A blended ROAS of 1.2 can easily hide one channel at 2.5 and another at 0.4 that you should kill today.

Forecasting LTV

You rarely have 180 days to wait. The practical approach: use early signals to project the mature curve.

Anchor on early LTV — LTV(3) or LTV(7) is observable within a week.
Apply a maturity multiplier — from past cohorts, learn the ratio LTV(180) / LTV(7). If history says mature LTV is ~3.5× your D7 value, you can project new cohorts within days of a campaign launching.
Refit constantly. The multiplier drifts when you change monetization, seasonality hits, or channel mix shifts. Treat it as a living estimate, not a constant.

This is rough, but rough-and-early beats precise-and-too-late when you are deciding whether to scale ad spend tomorrow. Pair it with retention analysis — LTV is just retention multiplied by spend, so a retention crack will always show up as an LTV cap.

How to Find What SDKs and Tech Stack an App Uses

Appluck — Tue, 16 Jun 2026 02:27:37 +0000

If you have ever opened a competitor's app and wondered "what is this thing actually built with?" — which ad network monetizes it, which analytics SDK it phones home to, whether it is React Native or fully native — you are asking a tech-stack fingerprinting question. The good news: most of the answer is sitting in public signals you can pull without anything exotic.

This guide walks through the layers, cheapest-first.

1. Start with store metadata

Before you touch a binary, the Google Play listing already tells you a lot:

Declared permissions hint at capabilities — com.google.android.gms.permission.AD_ID strongly implies an advertising SDK; fine-location permissions suggest a location-data SDK.
The Data Safety section enumerates what data the app collects and shares, which maps closely to the analytics and attribution SDKs in the build.
Update cadence, install count, and rating velocity tell you how mature and well-resourced the team is.

You can browse this kind of structured metadata across hundreds of thousands of titles in the Appluck app directory — sort and filter to line up a competitor against its category peers before you dig deeper.

2. Read the permissions and declared components

Android apps declare their components in the manifest. Even from the outside, the set of permissions and the services/receivers an app registers is a fingerprint. A few quick tells:

BILLING → in-app purchases (Play Billing).
A cluster of ad permissions + INTERNET + ACCESS_NETWORK_STATE → a mediated ad stack (AdMob, AppLovin MAX, ironSource, and friends).
A push-related service → a messaging SDK such as Firebase Cloud Messaging or a vendor like OneSignal.

Map the publisher's whole portfolio to see which SDKs they reuse across apps — a developer's full app portfolio usually shares one monetization and analytics spine.

3. Fingerprint the SDKs by package signatures

The most reliable signal lives in class paths and package names. Popular SDKs ship under stable namespaces, so a presence check is essentially a substring match:

Namespace prefix	Likely SDK
`com.google.android.gms.ads`	Google AdMob
`com.applovin`	AppLovin / MAX
`com.unity3d.ads`	Unity Ads
`com.facebook.ads`	Meta Audience Network
`com.amplitude`	Amplitude analytics
`io.branch`	Branch attribution

Maintain a dictionary of namespace → SDK and you have a detector. Cross-check against multiple namespaces before you call it — mediation SDKs pull in several ad adapters, so seeing com.applovin and com.google.android.gms.ads usually means MAX mediating AdMob, not two independent integrations.

4. Confirm with network behavior

Runtime traffic is the tie-breaker. Endpoints are stable and recognizable:

graph.facebook.com / *.facebook.com → Meta SDK.
app-measurement.com → Firebase / Google Analytics.
*.appsflyer.com, *.adjust.com, *.branch.io → attribution.

A handful of hostnames will confirm the analytics and attribution layer you inferred from steps 1–3.

5. Turn signals into a comparison

One app is an anecdote; the pattern across a category is the insight. Once you can fingerprint a stack, run it across a competitor set: which ad mediator dominates puzzle games, which attribution vendor the top-grossing finance apps trust, how monetization choices track with retention.

That cross-app view is exactly what Appluck is built for — and the historical trend and ad-network intelligence behind it lives in the Pro plan.

Wrapping up

You do not need to crack open every APK to understand an app's stack. Start with store metadata, read the permissions, fingerprint by package namespace, confirm with network endpoints — then scale the analysis across a whole category. The public surface area is bigger than most people assume.

Frequently asked questions

Is it legal to inspect the SDKs an app uses?

Inspecting publicly distributed binaries and store metadata for interoperability and research is widely accepted. Stay on the right side of the relevant store terms and local law, avoid redistributing copyrighted assets, and never use the data to attack users or infringe IP.

Can I detect SDKs without decompiling the APK?

Often yes. Store metadata, permissions, declared services, privacy labels, and network behavior already leak most of the stack. Decompilation gives you certainty, but the cheap public signals get you 80% of the way.

How accurate is SDK fingerprinting?

Package-name and class-path signatures are highly reliable for popular SDKs. Heuristic signals (permissions, hostnames) are directional. Combine several signals before you treat a detection as confirmed.