← All articles

Blog

App Conversion Tracking: Firebase, SKAdNetwork, and Google Play Install Campaigns

app conversion trackingfirebase conversion trackingskadnetwork conversionsapp install tracking google ads

"We're running app install campaigns, but we're not sure the conversions are actually counting." App conversion tracking is a different animal from web tracking — if you need web-side setup instead, see our GA4 conversion tracking guide or Google Ads conversion tracking guide. There's no tag on a page, no thank-you URL, no DevTools Network tab to check. Instead, you're dealing with SDKs, app stores as intermediaries, and privacy frameworks that limit what data you can even receive.

This guide covers how app conversion tracking works across the major platforms, what's different from web, how to verify it's set up correctly, and what the iOS privacy changes mean for your data.

1. How app conversion tracking differs from web

On the web, the tracking chain is straightforward: tag on page → user action → request to ad platform → conversion recorded. With apps, several factors make it fundamentally different.

Web App
Tag loads in the browser you control SDK is compiled into the app binary
Conversions fire on page load or button click Conversions fire on install or in-app event
You can inspect with DevTools in real time You rely on SDK logs, Firebase DebugView, or test devices
First-party cookies carry identity Device ID (IDFA/GAID) or privacy-preserving frameworks carry identity
Changes deploy instantly (update the tag) Changes require an app update and review cycle

The most critical difference: you can't patch app tracking with a quick tag change. If the SDK version or event implementation is wrong, fixing it means pushing an app update, waiting for app store review, and then waiting for users to update.

2. The three measurement paths

Path 1: Firebase + Google Ads

Firebase is Google's SDK for app analytics and is the primary path for tracking app conversions in Google Ads.

How it works:

  1. Integrate the Firebase SDK into your app
  2. Log events (e.g., first_open, purchase, sign_up) in your app code
  3. Link your Firebase project to Google Ads
  4. In Google Ads, import the Firebase events as conversion actions

What gets tracked:

  • App installs — automatically tracked via first_open event
  • In-app actions — any custom event you log (purchase, level completion, subscription start)
  • In-app purchase revenue — if you pass the value and currency parameters with your events

Key advantage: Firebase provides a direct data pipeline to Google Ads. No third-party attribution tool needed for Google campaigns.

Path 2: SKAdNetwork (SKAN) for iOS

After Apple's App Tracking Transparency (ATT) framework in iOS 14.5, most iOS users opt out of tracking. SKAdNetwork is Apple's privacy-preserving alternative for measuring ad-driven app installs.

How it works:

  1. The ad network (Google, Meta, etc.) registers with Apple as an ad network
  2. When a user installs the app after seeing/clicking an ad, Apple sends a postback to the ad network
  3. The postback contains limited data: the ad network ID, campaign ID, and a "conversion value" (0–63 in SKAN 3.0, or "coarse" values in SKAN 4.0)
  4. The postback is delayed (24–48 hours minimum) and contains no user-level identifiers

What you lose compared to Firebase:

  • No user-level attribution (can't see which specific user converted)
  • Limited conversion value granularity (63 possible values vs. unlimited with Firebase)
  • Delayed reporting (vs. near-real-time with Firebase)
  • No view-through attribution in early SKAN versions
  • Campaign-level attribution only (no ad group or keyword level in most cases)

What you keep:

  • Aggregate install counts by campaign
  • A coarse signal of post-install value (if you map your conversion value schema correctly)
  • Privacy compliance — no user consent required

Path 3: Google Play Install Referrer (Android)

On Android, the Google Play Install Referrer API provides deterministic attribution without the privacy restrictions of iOS.

How it works:

  1. When a user clicks a Google Ads ad and installs the app from the Play Store, the referrer data (including gclid) is passed to the app
  2. Firebase or your attribution SDK reads the referrer at first launch
  3. The install is attributed to the specific click, campaign, ad group, and keyword

Key advantage: Android attribution is significantly more complete than iOS post-ATT. You get user-level, keyword-level attribution with full conversion data.

3. Setting up Firebase for Google Ads conversion tracking

Step 1: Add Firebase to your app

Follow the Firebase setup for iOS or Android. This involves adding the Firebase SDK, a configuration file (GoogleService-Info.plist for iOS, google-services.json for Android), and initializing Firebase in your app code.

Step 2: Log conversion events

In your app code, log the events you want to track as conversions:

// iOS (Swift)
Analytics.logEvent("purchase", parameters: [
  AnalyticsParameterValue: 9.99,
  AnalyticsParameterCurrency: "USD"
])
// Android (Kotlin)
firebaseAnalytics.logEvent("purchase") {
  param(FirebaseAnalytics.Param.VALUE, 9.99)
  param(FirebaseAnalytics.Param.CURRENCY, "USD")
}

Step 3: Link Firebase to Google Ads

In the Firebase console → Project settings → Integrations, link to your Google Ads account. This allows Google Ads to import events from Firebase.

Step 4: Import events as conversions in Google Ads

In Google Ads → Goals → Conversions → New conversion action → App → Firebase, select the events you want to import. Mark the primary conversion event (e.g., purchase) as "Primary" for bidding.

4. Configuring SKAdNetwork conversion values

SKAdNetwork gives you 6 bits (values 0–63) to encode post-install behavior. How you map those 64 values determines what you can measure.

Common mapping strategies

Revenue-based: Map value ranges to conversion values (e.g., 0 = no purchase, 1 = $0–$5, 2 = $5–$10, ... 63 = $500+). This gives Google Ads a revenue signal for bidding.

Event-based: Map key post-install events to conversion values (e.g., 0 = install only, 1 = registration, 2 = tutorial complete, 3 = first purchase). This tells the ad network which quality of user was acquired.

Hybrid: Combine revenue tiers and key events into the 64 available values.

SKAN 4.0 changes

SKAN 4.0 introduces:

  • Three postbacks instead of one (at different time windows)
  • Coarse conversion values (low/medium/high) for the second and third postbacks
  • Source identifiers with more campaign-level granularity

Google Ads and other platforms are still rolling out full SKAN 4.0 support. Check your platform's current documentation for the latest capabilities.

SKAN 4.0 Web-to-App attribution

A significant addition in SKAN 4.0: Safari-to-App Store transitions are now eligible for attribution. Previously, only in-app ads could trigger SKAN postbacks. With 4.0, web ads viewed in Safari that lead to an App Store install can also be attributed — a major improvement for advertisers who run web campaigns alongside app install campaigns.

Privacy Sandbox on Android: what's coming

While iOS's ATT has already reshaped app measurement, Android's equivalent is still developing. Google's Privacy Sandbox on Android will gradually reduce reliance on the GAID (Google Advertising ID):

  • Attribution Reporting API replaces device-ID-based attribution with aggregate, privacy-preserving reports (similar in concept to SKAN)
  • Topics API replaces interest-based ad targeting without per-user tracking
  • The timeline for GAID deprecation remains fluid, but advertisers should prepare for an Android measurement landscape that increasingly resembles iOS

Practical advice: don't assume Android's current measurement precision will last forever. Start evaluating your readiness for aggregate-only attribution on Android now.

5. Choosing an MMP (Mobile Measurement Partner)

If you advertise across multiple ad networks, a third-party MMP provides cross-network attribution that Firebase alone can't offer. Here's how the major platforms compare:

Feature AppsFlyer Adjust Singular
Market share Largest globally Strong, especially in gaming Growing, unified analytics focus
Cross-network attribution Extensive integrations (10,000+ partners) Broad integration library Good coverage with cost aggregation
SKAN support Advanced (SKAN 4.0, predictive modeling) Full SKAN support Full SKAN support
Privacy focus Data Clean Rooms, aggregated data Strong privacy controls, fraud prevention Privacy-first architecture
Cost aggregation Available (separate product) Available Built-in (key differentiator)
Pricing Usage-based, can be expensive at scale Usage-based Usage-based, competitive
Best for Large advertisers, complex multi-channel Gaming, privacy-sensitive apps Cost-conscious teams wanting unified view

When you need an MMP:

  • Running app install campaigns on 3+ ad networks simultaneously
  • Need to deduplicate installs across networks (each network claims credit)
  • Want a single source of truth for cross-network ROAS
  • Need advanced fraud detection (click injection, SDK spoofing)

When Firebase alone is enough:

  • Google Ads is your only (or dominant) app ad channel
  • You don't need cross-network attribution
  • Your app advertising budget is under ~$50K/month

6. Deep linking and re-engagement measurement

App conversion tracking isn't just about new installs. For apps with an existing user base, re-engagement — bringing users back into the app — is often more valuable than acquisition.

Deep links and conversion tracking

Deep links send users directly to a specific screen within your app (not just the home screen). They affect conversion tracking because:

  • A user who clicks a retargeting ad and lands on the exact product page converts at roughly 2x the rate of one who lands on the app's home screen
  • Deep link clicks are tracked as a separate conversion type (re-engagement vs. new install)

Re-engagement attribution rules

MMPs typically count a re-engagement conversion when:

  1. The user already has the app installed
  2. The user has opened the app at least 3 times before (not a brand-new user)
  3. At least 10 minutes have passed since install (to separate from new-install attribution)

Web-to-App measurement

Tracking users who start on the web and convert in the app is one of the hardest attribution challenges:

  • App Links (Android) / Universal Links (iOS) route users from web URLs directly into the app
  • The identity bridge between web session and app session depends on device-level signals that privacy changes are eroding
  • Google's App Campaigns for Engagement and MMP deep link solutions (AppsFlyer OneLink, Adjust Links) provide the infrastructure, but expect attribution gaps

7. How to verify app conversion tracking

Verification method 1: Firebase DebugView

Enable debug mode on your test device:

  • iOS: Add -FIRDebugEnabled as a launch argument in Xcode
  • Android: Run adb shell setprop debug.firebase.analytics.app your.package.name

Then open Firebase Console → DebugView. Events should appear in real time as you perform actions in the app. Verify:

  • The event name matches what you configured as a conversion
  • The value and currency parameters are present and correct
  • The event fires at the right moment (not on app launch, not delayed)

Verification method 2: Google Ads conversion tracking status

In Google Ads → Goals → Conversions, check the status of your app conversion actions:

  • "Recording conversions" — working correctly
  • "No recent conversions" — either no installs/events have occurred, or the link between Firebase and Google Ads is broken
  • "Unverified" — the conversion action was created but no data has been received yet

Verification method 3: Test with a real ad click (Android)

On Android, you can test the full attribution chain:

  1. Click a real ad for your app (use a test campaign with minimal budget)
  2. Install the app from the Play Store
  3. Check Firebase for the first_open event
  4. Check Google Ads for the recorded conversion (allow 24–48 hours for processing)

Warning for iOS: Due to ATT, this test is less reliable on iOS. If you haven't opted in to tracking on the test device, the install may only show up via SKAdNetwork (delayed, no user-level data).

Verification method 4: Check SKAdNetwork postbacks

For iOS, verify that SKAN postbacks are being received:

  • In Google Ads, check the "SKAN conversions" column in your campaign report
  • In your SKAdNetwork reporting dashboard (if using a third-party MMP), check for received postbacks
  • Compare SKAN install counts against your internal first-launch data — significant gaps suggest misconfiguration

8. Common app tracking problems

Problem Cause Fix
Installs show in Firebase but not in Google Ads Firebase-to-Google Ads link is broken, or the event isn't imported as a conversion Re-check the link in Firebase Console → Integrations; verify the event is imported in Google Ads
Conversion values are all zero The value parameter isn't passed with the event, or the SKAN conversion value mapping is empty Add value/currency to your event logging code; configure SKAN value mapping
iOS installs are drastically undercounted ATT opt-out rate is high; SKAN postbacks are the only signal This is expected behavior post-iOS 14.5; use SKAN data alongside modeled conversions
Android installs are undercounted Firebase SDK not initialized at first launch, or Play referrer not captured Ensure Firebase initializes in the Application class (not in a delayed activity)
In-app events fire but aren't recorded as conversions The event is logged in Firebase but not imported as a conversion action in Google Ads Import the event in Google Ads → Goals → Conversions → App
Duplicate installs Multiple SDKs (Firebase + third-party MMP) both sending install events Use one source of truth for each conversion action; don't import the same event from two sources

9. The ATT impact: what to expect on iOS

Since iOS 14.5, most users see the ATT prompt ("Allow [App] to track your activity across other companies' apps and websites?") and roughly 70–80% decline.

For users who decline:

  • Firebase still logs events (analytics work without IDFA), but Google Ads cannot attribute the install to a specific click
  • SKAdNetwork provides aggregate attribution with limited granularity
  • Google's modeled conversions fill in some of the gap using machine learning

Practical impact:

  • iOS conversion counts will be lower than actual installs
  • Campaign-level ROAS on iOS will be less accurate than Android
  • You cannot compare iOS and Android conversion numbers directly — they're measured with fundamentally different precision

Frequently asked questions

Q. Do I need both Firebase and a third-party MMP (AppsFlyer, Adjust, etc.)? A. For Google Ads only, Firebase is sufficient. If you run campaigns on multiple ad networks (Google, Meta, TikTok, etc.) and need cross-network attribution, a third-party MMP provides a unified view. Most large app advertisers use both.

Q. Can I track web-to-app conversions (user clicks a web ad, installs the app, then converts in-app)? A. Yes, using Firebase Dynamic Links (now being replaced by App Links / Universal Links) or Google Analytics' cross-platform measurement. This is one of the hardest attribution problems — the identity bridge between web and app relies on device-level signals that privacy changes are eroding.

Q. Our SKAN conversion values all show as 0. What's wrong? A. Either your conversion value mapping isn't configured (check your MMP or Google Ads SKAN settings), or the measurement window expired before the user took a qualifying action. SKAN has a limited timer — if the user doesn't perform a valuable action within the window, the value stays at 0.

Q. How do I verify in-app purchase revenue is accurate? A. Compare the value parameter in Firebase DebugView against your app store or payment processor records. For server-verified purchases, ensure the revenue logged matches the actual charge (watch for currency mismatches and tax/fee inclusion).

Conclusion: app tracking is a different discipline

App conversion tracking requires different tools, different verification methods, and different expectations than web tracking. The core principle is the same — verify that the signal reaches the ad platform — but the mechanisms (SDKs vs. tags, device IDs vs. cookies, SKAN vs. direct attribution) are fundamentally different.

The biggest adjustment for teams coming from web: accept that iOS measurement is structurally imprecise. Post-ATT, you won't have the same user-level, real-time attribution you're used to on the web. Build your measurement strategy around a combination of Firebase (for analytics and Android attribution), SKAN (for iOS aggregate attribution), and modeled conversions (for filling the gaps).

ConversionOK focuses on web conversion signals — verifying that the tags on your landing pages and thank-you pages actually fire and reach the ad platform. For apps, the equivalent verification starts with Firebase DebugView and SKAN postback monitoring, using the methods described above. If you use server-side GTM to bridge web and app data, see how to verify server-side GTM is actually working.