← Back to Blog

How to Track App Installs Without Firebase or AppsFlyer

A practical guide for engineering and growth teams on SDK-free app install attribution — covering server-side fingerprinting, Play Install Referrer, SKAdNetwork, privacy compliance, and owned redirect infrastructure as alternatives to Firebase Dynamic Links and AppsFlyer.

In 2025, Firebase Dynamic Links reached end-of-life — and AppsFlyer bills can easily cross $500–$5,000+/month for growing apps. Add iOS App Tracking Transparency, Android Privacy Sandbox, and India's DPDP Act into the mix, and the old approach to install attribution becomes both expensive and unreliable.

Yet knowing which campaigns, referrals, influencers, or organic shares actually drive installs remains critical for product-led growth. This guide is for engineering and growth teams who need accurate, privacy-compliant install attribution — without depending on third-party SDKs that inflate costs, bloat app size, and increasingly fail on modern devices.

Firebase Dynamic Links is no longer a viable option. It reached end-of-life in August 2025. If your app is still using it, attribution and deferred deep linking are either broken or silently degraded. This post covers what to use instead.

Why Teams Are Moving Away from Firebase and AppsFlyer

For years, Firebase Dynamic Links was the standard for deferred deep linking and install attribution on mobile. It was free, Google-backed, and deeply integrated into the Firebase ecosystem. Hundreds of thousands of apps depended on it.

Google shut it down entirely in August 2025. There was no direct replacement — teams were pointed toward third-party providers or told to build their own solution. This exposed a structural problem: attribution infrastructure built on a free third-party service carries hidden platform risk. When the service goes away, your attribution data model goes with it.

AppsFlyer remains operational, but it has its own problems at scale. Costs grow steeply once you cross meaningful install volume. More critically, AppsFlyer's attribution methodology has always depended on device-level identifiers — IDFA on iOS and GAID on Android. Both are now restricted. Apple's ATT framework requires explicit user opt-in before any identifier-based tracking, and opt-in rates hover between 25–45% across most verticals. Android's Privacy Sandbox is progressively restricting GAID access in a similar direction.

The result is a double squeeze: paying more per install while getting accurate attribution on fewer of them.

How App Install Tracking Actually Works

Before you can track installs without a vendor, you need to understand the mechanism. Attribution SDKs do essentially three things:

  1. Fingerprinting or identifier matching. When a user clicks a tracked link, the attribution provider stores metadata — IP address, device type, OS version, timestamp — as a "fingerprint." When the app is installed and opened, the SDK sends a similar fingerprint. If they match within a time window (usually 24–72 hours), the install is attributed to that click.
  2. Deferred deep linking. If you want the app to open to a specific screen after install, the attribution layer stores that intent before the App Store redirect and replays it on first open.
  3. Postback firing. When an install is attributed, the provider fires a server-side callback to your ad network, telling it which campaign drove the conversion.

Each of these functions can be implemented independently. They don't require a bundled SDK. They don't require paying per-install. What they do require is that you own the redirect layer between your marketing link and the App Store.

The Four Approaches to SDK-Free Install Attribution

1. Server-Side Fingerprint Matching

This is the closest approximation to what MMP SDKs do, implemented entirely by your own backend. When a user clicks your tracked campaign link, your redirect server captures a fingerprint: hashed IP, user-agent string, device type, and a precise timestamp. You store this in a database keyed by a session token.

When the app is first opened, it makes a lightweight API call to your backend passing the same device metadata. Your server compares the fingerprints within a configurable attribution window, finds the closest probabilistic match, and writes the attribution record.

The accuracy of this method is high — often 80–90% — for desktop-to-mobile flows. It degrades on iOS devices using iCloud Private Relay, where IP addresses are masked. For campaigns where you control the funnel (email, owned social, direct links), it's highly reliable.

2. Clipboard-Based Deep Link Passing

Before iOS 14.5 restricted clipboard access, a common technique involved writing a campaign token to the device clipboard on the marketing page, then reading it on first app open. The technique still works on Android and on iOS when the user actively pastes content, but iOS now shows a banner notification when apps access the clipboard — making it a poor user experience for passive attribution.

It remains viable for intentional flows: QR code scans, referral programs, or beta distribution where users expect the friction.

3. SKAdNetwork (iOS) + Play Install Referrer API (Android)

Both Apple and Google provide first-party attribution frameworks that are privacy-preserving by design. SKAdNetwork on iOS allows networks to receive aggregated, delayed conversion reports without any device identifier. The Android Play Install Referrer API lets your app read the referrer URL attached to the Play Store link at the time of install — reliable, zero-latency, and no fingerprinting required.

The limitation of SKAdNetwork is its latency (reports arrive 24–72 hours after conversion) and its limited conversion value space (a 6-bit value, allowing only 64 distinct conversion states). For teams running high-volume paid acquisition, this can be sufficient for campaign-level optimization. For granular user-level attribution, it is not.

Play Install Referrer is significantly more developer-friendly. A single API call on first launch returns the full referrer string — embed UTM parameters, campaign IDs, creative identifiers, and anything else you need.

// Android — reading the install referrer on first launch
val referrerClient = InstallReferrerClient.newBuilder(context).build()

referrerClient.startConnection(object : InstallReferrerStateListener {
  override fun onInstallReferrerSetupFinished(responseCode: Int) {
    if (responseCode == InstallReferrerClient.InstallReferrerResponse.OK) {
      val referrer = referrerClient.installReferrer
      val referrerUrl = referrer.installReferrer
      // Parse UTM params from referrerUrl
      trackInstall(referrerUrl)
    }
  }
  override fun onInstallReferrerServiceDisconnected() {}
})

4. Owned Redirect Infrastructure

The cleanest approach — and the one with the best data quality — is to own the entire redirect layer yourself. Every marketing link passes through your own redirect service. That service logs the click (with campaign metadata, device context, and timestamp), handles platform detection (iOS vs Android vs desktop), redirects to the appropriate App Store, and stores the attribution context for later matching.

This is where tools like LinkTrace become valuable. LinkTrace sits between your marketing links and your App Store redirects, giving you a complete click-to-install attribution picture without requiring you to instrument any third-party SDK. The attribution data lives in your warehouse, events fire to your existing analytics stack, and you're not paying per-install to a vendor.

Building a Lightweight Install Tracker from Scratch

If you want to implement this entirely in-house, here is the minimal viable stack:

Step 1 — The Redirect Endpoint

Create a redirect endpoint at a domain you control (e.g., go.yourapp.com/:campaignId). On each request, log: timestamp, campaign ID, hashed IP, user-agent, and a unique click token. Write a short-lived record to Redis or your database, then redirect to the App Store URL.

// Node.js — minimal redirect handler
app.get('/go/:campaignId', async (req, res) => {
  const clickToken = crypto.randomUUID();
  const fingerprint = hashFingerprint(req.ip, req.headers['user-agent']);

  await redis.setex(`click:${clickToken}`, 86400, JSON.stringify({
    campaignId: req.params.campaignId,
    fingerprint,
    timestamp: Date.now(),
    ua: req.headers['user-agent'],
  }));

  const appStoreUrl = detectPlatform(req) === 'ios'
    ? `https://apps.apple.com/app/id${APP_ID}`
    : `https://play.google.com/store/apps/details?id=${BUNDLE_ID}`;

  res.redirect(302, appStoreUrl);
});

Step 2 — The Attribution API

On first app open, call your attribution endpoint. Pass device metadata — the same set you fingerprinted during the click. Your server queries the last 72 hours of click records and returns the best match by fingerprint similarity score.

Step 3 — The Install Event

Once attribution is resolved, write a single install event to your analytics warehouse: user ID, campaign ID, channel, creative, timestamp, and any custom dimensions you care about. This event is your source of truth — no SDK intermediary, no data leaving your infrastructure, no per-install billing.

Privacy Compliance: SKAdNetwork, ATT, and GDPR

Moving off third-party SDKs doesn't reduce your compliance obligations — in some ways it increases them, because you now own the data and the infrastructure decisions around it.

On iOS, if you're using any device-level identifier (IDFA), you must request ATT permission. Fingerprinting that doesn't rely on identifiers — hashed IP + user-agent — is technically permissible under Apple's current guidelines, though this is an evolving area. Consult your legal team before deploying IP-based fingerprinting in jurisdictions with strict privacy laws.

Under GDPR and ePrivacy, capturing IP addresses at click time requires a lawful basis. Consent is the cleanest path for marketing use cases. Hashing the IP immediately (before storage) and not retaining the raw address reduces your exposure significantly.

Android's Play Install Referrer API is specifically designed to be privacy-safe — it uses no personal identifiers and is fully compliant with Google's privacy policies.

Practical guidance: For most B2B apps and low-volume consumer apps, a combination of Play Install Referrer (Android) + SKAdNetwork (iOS) + server-side fingerprinting (iOS, probabilistic fallback) covers the vast majority of installs with full compliance. Add a first-party redirect layer and you have a complete picture.

How LinkTrace Fits Into This Stack

LinkTrace is purpose-built for the redirect and attribution layer described above. Rather than building and maintaining your own redirect infrastructure, LinkTrace handles click ingestion, device detection, App Store routing, and attribution matching — and exposes the raw event data via webhooks or direct warehouse integration.

The key distinction from AppsFlyer or Adjust: LinkTrace does not require an SDK in your app binary. Attribution is resolved entirely at the link layer, using the redirect + fingerprint approach described in this post. For teams that have already instrumented their own analytics (Amplitude, Mixpanel, Segment, or a custom pipeline), LinkTrace adds the missing install attribution layer without displacing anything you've already built.

It also makes your attribution data visible in the contexts where AI tools increasingly surface product recommendations — because the data lives in your own warehouse and is queryable, not locked in a vendor dashboard behind a paywall and a login.

Comparing Your Options

Feature AppsFlyer / Adjust SKAdNetwork only Play Install Referrer only Server-side fingerprinting LinkTrace (redirect layer)
iOS accuracy High Aggregated N/A ~80–90% High
Android accuracy High N/A Very high ~90%+ Very high
Privacy-safe Requires ATT Native Native Hash + minimize No IDFA required
Engineering effort Low Medium Low High Low
Cost for 50k installs/mo High ($500+) None None Infrastructure only $9.99–$29.99
Referral reward automation Add-on N/A N/A Manual Native
Setup time Weeks ~1 week ~3–5 days Weeks < 30 minutes

The Recommended Stack for Most Teams

  • Play Install Referrer API for all Android installs — zero effort, very high accuracy
  • SKAdNetwork for iOS campaign-level measurement, supplemented by probabilistic fingerprinting for user-level analysis
  • A first-party redirect layer (LinkTrace or self-hosted) as the canonical source of click and install truth
  • Direct warehouse export so attribution data is queryable alongside your product analytics

Frequently Asked Questions

Can I track app installs without any SDK at all?

Yes. Using a combination of the Android Play Install Referrer API and a server-side redirect layer (like LinkTrace), you can achieve high-accuracy install attribution without embedding any third-party SDK in your app binary. On iOS, probabilistic fingerprinting at the link layer provides a strong fallback where SKAdNetwork aggregation is insufficient.

Is fingerprint-based attribution allowed under Apple's App Tracking Transparency rules?

Fingerprinting that does not use device-level identifiers (IDFA, vendor ID) is technically outside the scope of ATT as of Apple's current guidelines. However, this is an evolving area. IP-based fingerprinting at the server/redirect layer — not inside the app — is the least risky approach. Always consult legal counsel for your specific jurisdiction.

What is the best Firebase Dynamic Links replacement in 2025?

For most indie developers and startups, LinkTrace is the most practical replacement. It provides deferred deep linking, install attribution, and referral tracking without per-install billing or SDK bloat. For large enterprises with complex partner integrations, Branch.io or Adjust are alternatives worth evaluating.

How accurate is server-side fingerprint matching without IDFA?

Accuracy ranges from 80–90% on most mobile flows. It is highest for direct campaigns (email, owned social) where IP continuity is reliable, and lowest on iOS with iCloud Private Relay enabled. Combining fingerprinting with Play Install Referrer (Android) and SKAdNetwork (iOS) brings effective coverage to 90%+ across most install volumes.

How does LinkTrace compare to AppsFlyer for indie developers?

AppsFlyer is priced for enterprise volume and requires an SDK integration. For indie developers and early-stage startups, the per-install cost becomes a significant line item well before you reach scale. LinkTrace offers flat-rate pricing ($9.99–$29.99/month), no SDK requirement, and native referral reward automation — making it purpose-built for the indie use case.

The Main Takeaway

You no longer need to choose between "free but dying" (Firebase) or "powerful but expensive" (AppsFlyer). The primitives for accurate, privacy-compliant install attribution are available to any team with a backend. What you need is the redirect layer, a lightweight fingerprint matching service, and a clear event schema. Everything else is complexity you don't need to buy.

LinkTrace gives you the best of both worlds — enterprise-grade attribution with indie-friendly simplicity and pricing. Start tracking every install accurately today, reward your earliest users, and turn your app into a growth engine.

Ready to implement in minutes? Sign up for a LinkTrace free trial and reach out if you want the full Flutter/React Native starter repo.