Mobile Attribution for Rork Apps — A Production Guide to AppsFlyer, Adjust, SKAdNetwork 4.0, and ATT

Wiring AppsFlyer into a Rork (Expo + React Native) Project

Rork builds on Expo's managed workflow, so adding native modules means using Config Plugins. AppsFlyer ships an official react-native-appsflyer package, and from Expo SDK 51 onward Prebuild handles almost everything for you.

# Step 1: install the package
npx expo install react-native-appsflyer
 
# Step 2: register the Config Plugin in app.json (required)
# It auto-injects SKAdNetworkItems into Info.plist

In app.json, register the plugin and the ATT usage description. Toggle isDebug on while developing — the AppsFlyer logs in the Xcode console make wiring problems obvious.

{
  "expo": {
    "plugins": [
      [
        "react-native-appsflyer",
        {
          "shouldUseStrictMode": true
        }
      ]
    ],
    "ios": {
      "infoPlist": {
        "NSUserTrackingUsageDescription": "We use limited measurement data to deliver content and offers tailored to you. You can change this in Settings at any time."
      }
    }
  }
}

The cardinal rule of SDK initialization: only initialize after the ATT status is finalized. If you initialize on app launch, IDFA is still locked, the SDK records empty IDs, and even a later opt-in won't backfill the early data.

// src/lib/attribution.ts
import appsFlyer from 'react-native-appsflyer';
import { getTrackingPermissionsAsync, requestTrackingPermissionsAsync, PermissionStatus } from 'expo-tracking-transparency';
import { Platform } from 'react-native';
 
const APPSFLYER_DEV_KEY = process.env.EXPO_PUBLIC_APPSFLYER_DEV_KEY!;
const APPSFLYER_APP_ID = process.env.EXPO_PUBLIC_APPSFLYER_APP_ID!; // numeric App Store ID
 
export async function initAttribution(): Promise<void> {
  // 1. Resolve ATT to a final state (granted or denied) — no-op if already determined
  if (Platform.OS === 'ios') {
    const current = await getTrackingPermissionsAsync();
    if (current.status === PermissionStatus.UNDETERMINED) {
      // Show your pre-prompt UI before this call if you have one
      await requestTrackingPermissionsAsync();
    }
  }
 
  // 2. Initialize the SDK only after ATT is finalized (order matters)
  return new Promise((resolve, reject) => {
    appsFlyer.initSdk(
      {
        devKey: APPSFLYER_DEV_KEY,
        isDebug: __DEV__,
        appId: APPSFLYER_APP_ID,
        onInstallConversionDataListener: true, // first-launch attribution payload
        onDeepLinkListener: true,              // OneLink deep links
        timeToWaitForATTUserAuthorization: 60, // max seconds to wait for ATT
      },
      (result) => {
        console.log('[Attribution] init success', result);
        resolve();
      },
      (error) => {
        console.warn('[Attribution] init failed', error);
        reject(error);
      },
    );
  });
}

timeToWaitForATTUserAuthorization: 60 is doing real work. The system ATT dialog can take a moment to settle, and if the SDK initializes too eagerly, IDFA goes out empty. Giving the SDK runway to re-read IDFA after consent is what makes the integration robust.

Expected behavior: on first launch, the ATT dialog appears, the user taps Allow, and the install event is fired with both appsflyer_id and idfa correctly attached. You'll see [Attribution] init success in the Xcode console.

Designing SKAdNetwork 4.0 Conversion Values

The conversion-value schema is where you should spend the most design time in SKAN 4.0. fine is 0–63, coarse is low/medium/high. Once campaigns are live, changing the schema fragments your data — so commit to a thoughtful weighting before you start spending.

Here is the baseline I usually start from. Adjust the numbers to your app, but the shape — small score for activation events, larger jumps for monetization signals — generalizes well.

• App open: 1 point
• Onboarding completed: 4 points
• First content view: 8 points
• Account created: 16 points
• Trial started: 32 points

Map the cumulative score to fine (cap at 63), and bucket coarse so the top 30% of LTV lands in high, the next 40% in medium, and the rest in low. coarse shines in postback window 1 (3–7 days post-install), which is exactly when subscription apps separate winners from losers.

Before the working version, here's the one I shipped first. It reads perfectly well, and it has two holes in it.

// ❌ My first attempt. Looks fine, loses measurement in two places.
let cumulativeScore = 0;
 
export async function reportEvent(event: Event): Promise<void> {
  const next = Math.min(63, cumulativeScore + SCORE_MAP[event]);
  if (next > cumulativeScore) {
    cumulativeScore = next;
    appsFlyer.updateConversionValueWithErrorCallback(next, (e) => console.warn(e));
  }
}

The first hole is that cumulativeScore lives in process memory. Kill the app, reopen it the next morning, and it starts from 0 — so every value you compute from there is lower than what you already reported. SKAN accepts monotonically increasing values only, so the low value is dropped. No error, no warning. The shape of the failure is oddly specific: everything up to onboarding looks right, and the 32-point trial signal never arrives.

The second hole is that only fine is ever set. Under SKAN 4.0, fine can only ride the first postback (activity up to two days post-install); postbacks two and three can carry coarse only. If you never set a coarse value, those postbacks come back as coarse: none. That is the most common reason a dashboard shows a healthy window 0 and nothing after it. I had written a whole section about coarse buckets while my code was still SKAN 3.0.

Designing for 4.0 while implementing 3.0 fails silently — the report just goes empty.

Here's the version that closes both.

// src/lib/conversion-value.ts
import AsyncStorage from '@react-native-async-storage/async-storage';
import appsFlyer from 'react-native-appsflyer';
import { updateSkanConversionValue, type CoarseValue } from './skan';
 
type Event =
  | 'app_open'
  | 'onboarding_completed'
  | 'first_content_view'
  | 'account_created'
  | 'trial_started';
 
const SCORE_MAP: Record<Event, number> = {
  app_open: 1,
  onboarding_completed: 4,
  first_content_view: 8,
  account_created: 16,
  trial_started: 32,
};
 
const STORE_KEY = 'skan:cumulative-fine';
 
// Derive coarse from where fine landed. Tune the cutoffs to your own LTV distribution.
function toCoarse(fine: number): CoarseValue {
  if (fine >= 32) return 'high';   // reached trial
  if (fine >= 8) return 'medium';  // first content view and beyond
  return 'low';
}
 
async function readScore(): Promise<number> {
  const raw = await AsyncStorage.getItem(STORE_KEY);
  const parsed = Number(raw);
  return Number.isFinite(parsed) ? parsed : 0;
}
 
export async function reportEvent(event: Event, payload?: Record<string, unknown>): Promise<void> {
  // 1. Send the regular event for dashboard analytics
  appsFlyer.logEvent(event, payload ?? {}, () => {}, (err) => {
    console.warn('[Attribution] logEvent error', err);
  });
 
  // 2. Read the cumulative score from storage — a module variable resets to 0 on relaunch
  const current = await readScore();
  const next = Math.min(63, current + SCORE_MAP[event]);
  if (next <= current) return;
 
  await AsyncStorage.setItem(STORE_KEY, String(next));
 
  // 3. Update fine and coarse together; close the window once the trial signal lands
  await updateSkanConversionValue({
    fine: next,
    coarse: toCoarse(next),
    lockWindow: event === 'trial_started',
  });
}

updateSkanConversionValue is a thin bridge over SKAdNetwork.updatePostbackConversionValue(_:coarseValue:lockWindow:), available from iOS 16.1. It's about thirty lines with the Expo Modules API, so there's no need to wait for your MMP's SDK to expose it.

// modules/skan/ios/SkanModule.swift — a thin Expo Modules bridge
import ExpoModulesCore
import StoreKit
 
public class SkanModule: Module {
  public func definition() -> ModuleDefinition {
    Name("Skan")
 
    AsyncFunction("update") { (fine: Int, coarse: String, lockWindow: Bool, promise: Promise) in
      // Below iOS 16.1 there is no coarse value at all, so send fine only.
      guard #available(iOS 16.1, *) else {
        if #available(iOS 15.4, *) {
          SKAdNetwork.updatePostbackConversionValue(fine) { error in
            if let error { promise.reject("skan", error.localizedDescription) } else { promise.resolve(nil) }
          }
        } else {
          promise.resolve(nil)
        }
        return
      }
 
      let coarseValue: SKAdNetwork.CoarseConversionValue = {
        switch coarse {
        case "high": return .high
        case "medium": return .medium
        default: return .low
        }
      }()
 
      SKAdNetwork.updatePostbackConversionValue(fine, coarseValue: coarseValue, lockWindow: lockWindow) { error in
        if let error { promise.reject("skan", error.localizedDescription) } else { promise.resolve(nil) }
      }
    }
  }
}

One boundary matters here. If you've enabled a server-side conversion-value product such as AppsFlyer's SKAN Conversion Studio, do not also update values from the app. Whichever writes last wins, and debugging that is miserable. Pick one owner for the conversion value — the app or the server — and keep it. I keep it in the app today, though the server side gets more attractive as the number of media partners grows, so I expect to revisit that.

Setting lockWindow: true sends the postback without waiting out the rest of the window. Reserve it for a point where you know the score can't move again, such as trial start; setting it eagerly throws away measurement opportunities for everything that follows.

Expected output: open Cohort Report → SKAN Postbacks in the AppsFlyer dashboard and you'll see a fine distribution in postback window 0, and low/medium/high coarse distributions in windows 1 and 2. As long as windows 1 and 2 read none, your coarse value still isn't landing.

An ATT Pre-prompt that Actually Lifts Opt-in Rates

ATT opt-in rate is one of the highest-leverage numbers in your app. From what I've seen, raw ATT dialogs get 25–35% opt-in. A well-designed pre-prompt pushes that to 55–65%. The framing matters more than the wording.

The trick is to frame the ask around user benefit, not advertiser benefit. "Required for ads" tanks acceptance. "So we can show you content that fits you" lifts it. I've watched this play out in A/B tests too many times to be a coincidence.

// src/components/PrePromptATT.tsx
import { useEffect, useState } from 'react';
import { Modal, Text, View, Pressable, StyleSheet } from 'react-native';
import { getTrackingPermissionsAsync, requestTrackingPermissionsAsync, PermissionStatus } from 'expo-tracking-transparency';
import { initAttribution } from '../lib/attribution';
 
export function PrePromptATT() {
  const [visible, setVisible] = useState(false);
 
  useEffect(() => {
    (async () => {
      const { status } = await getTrackingPermissionsAsync();
      if (status === PermissionStatus.UNDETERMINED) setVisible(true);
    })();
  }, []);
 
  const onAllow = async () => {
    setVisible(false);
    await requestTrackingPermissionsAsync(); // OS dialog appears here
    await initAttribution();                  // SDK starts only after consent finalizes
  };
 
  if (!visible) return null;
 
  return (
    <Modal animationType="fade" transparent>
      <View style={styles.backdrop}>
        <View style={styles.card}>
          <Text style={styles.title}>Tailor what you see</Text>
          <Text style={styles.body}>
            Tap Allow on the next screen so we can show you content and offers
            that fit your interests. You can change this any time in Settings.
          </Text>
          <Pressable onPress={onAllow} style={styles.cta}>
            <Text style={styles.ctaText}>Continue</Text>
          </Pressable>
        </View>
      </View>
    </Modal>
  );
}
 
const styles = StyleSheet.create({
  backdrop: { flex: 1, backgroundColor: 'rgba(0,0,0,0.5)', justifyContent: 'center', padding: 24 },
  card: { backgroundColor: '#fff', borderRadius: 16, padding: 24 },
  title: { fontSize: 18, fontWeight: '700', marginBottom: 8 },
  body: { fontSize: 14, lineHeight: 22, color: '#444', marginBottom: 16 },
  cta: { backgroundColor: '#000', paddingVertical: 14, borderRadius: 12, alignItems: 'center' },
  ctaText: { color: '#fff', fontSize: 15, fontWeight: '600' },
});

Show this pre-prompt at the end of onboarding — after the user has felt the value of the app. Asking immediately on launch reads as "you're being measured before you've done anything," and decline rates climb.

If you also need to combine ATT with GDPR consent through a CMP, my companion piece Running ATT + UMP Consent in Production covers the integrated flow.

Deep Linking with Universal Links, OneLink, and Adjust Tracker Links

Deep linking is non-negotiable for ad attribution. Universal Links alone don't connect ad-click → install, so pair them with AppsFlyer's OneLink (or Adjust's Tracker Links) to enable Deferred Deep Linking — routing the user to the intended page after the install completes.

// src/lib/deep-link.ts
import appsFlyer from 'react-native-appsflyer';
import { router } from 'expo-router';
 
let unsubscribeOnDeepLink: (() => void) | null = null;
 
export function setupDeepLinking() {
  // Handle inbound OneLink and route to the right screen
  unsubscribeOnDeepLink = appsFlyer.onDeepLink((res) => {
    if (res.deepLinkStatus !== 'FOUND') return;
    const data = res.data as { deep_link_value?: string; sub1?: string };
 
    // deep_link_value uses a "domain:id" convention (e.g. "campaign:summer-sale")
    if (data.deep_link_value?.startsWith('campaign:')) {
      const campaignId = data.deep_link_value.split(':')[1];
      router.push(`/campaign/${campaignId}` as never);
      return;
    }
 
    if (data.deep_link_value?.startsWith('content:')) {
      const contentId = data.deep_link_value.split(':')[1];
      router.push(`/content/${contentId}` as never);
    }
  });
 
  // Capture first-launch conversion data as well, just in case
  appsFlyer.onInstallConversionData((res) => {
    if (res.data?.is_first_launch === 'true' && res.data?.deep_link_value) {
      const value = String(res.data.deep_link_value);
      console.log('[DeepLink] first launch with', value);
    }
  });
}
 
export function teardownDeepLinking() {
  unsubscribeOnDeepLink?.();
  unsubscribeOnDeepLink = null;
}

Encoding the destination as domain:id in deep_link_value keeps your routing logic stable across media partners. I keep a small set — campaign:, content:, referral: — and any new ad surface inherits that convention without app-side changes.

For Universal Links basics (the apple-app-site-association setup is a frequent stumbling block), see Universal Links and Deep Linking for Rork.

Pre-launch Debugging That Actually Catches Bugs

Before the first dollar of paid spend, run a full test cycle end-to-end. Discovering misconfiguration after spend has started is expensive in both money and trust.

My pre-launch checklist:

1. Register your test device in AppsFlyer's "Test Devices" panel (by IDFV or Custom ID).
2. Run a debug build and confirm logEvent calls show up in Live Events.
3. Trigger simulated SKAN postbacks under In-app Events → SKAN and verify your conversion values update as designed.
4. Use a TestFlight build on a separate device, tap a OneLink URL, and confirm Deferred Deep Linking lands on the right screen after install.
5. Once 1–4 pass, submit to the App Store.

// src/lib/attribution-debug.ts
import appsFlyer from 'react-native-appsflyer';
 
/**
 * Debug helper for the final pre-release smoke test.
 * After registering your device under Test Devices,
 * call this once and confirm the events appear in Live Events.
 */
export function fireDebugEvents() {
  if (!__DEV__) return; // never run in production builds
  appsFlyer.logEvent('debug_app_open', { source: 'self_test' }, () => {}, () => {});
  appsFlyer.logEvent('debug_onboarding_completed', { variant: 'A' }, () => {}, () => {});
  appsFlyer.logEvent('debug_account_created', { provider: 'apple' }, () => {}, () => {});
}

Expected output: AppsFlyer's Live Events tab shows the three debug events within 1–2 minutes. That's confirmation that ATT, SDK init, and network reachability are all healthy.

Common Mistakes I've Made (So You Don't Have To)

If your numbers still look off, the cause is almost always one of the following. I've personally hit each of these — keep this list close at release time.

1. Asking for ATT too early. A launch-time prompt commonly sees 70%+ decline rates. Show it after the user has experienced the app's value — I anchor it to the final onboarding step.
2. Stale SKAdNetwork ID list. Each ad network has its own SKAdNetwork ID, and any missing entry in SKAdNetworkItems silently kills attribution from that network. react-native-appsflyer injects the latest set, but anything you've added by hand needs a manual refresh — audit it every six months.
3. Late-stage schema rewrites. SKAN values are monotonic. Reversing weights mid-flight orphans your historical data and turns reports into noise. Lock the schema before you spend.
4. Hermes / Expo Modules version drift. Skipping the react-native-appsflyer major bump after an Expo SDK upgrade unlinks the native module and crashes the app on launch. Upgrade Expo SDK and the AppsFlyer package together.
5. Debug events leaking into production. Forget the __DEV__ guard once and your "self test" events corrupt production conversion rates. Wrap debug helpers in if (__DEV__), or call setIsSandbox(true) to isolate them.
6. Bundle ID drift. I learned this one hard way — a rebrand-time Bundle ID change wasn't mirrored in AppsFlyer, and the first day's installs were lost. Always verify both sides on rename.
7. Keeping the cumulative score in memory only. As above, a relaunch resets it to 0 and every later update is dropped by the monotonic guard. To reproduce it locally: reach onboarding-completed, force-quit the app, relaunch, then push through to trial start. If the postback's fine is still stuck at 4, you're in this hole.

Optimization Loops with TikTok, Meta, and Apple Search Ads

Attribution earns its keep when you tune conversion values per channel and let LTV drive spend. Here's how I think about each major surface today.

• TikTok Ads — strong for awareness, optimizes well on lower fine scores (open / onboarding completed). Creatives fatigue fast (2–3 weeks), so let coarse tell you which creatives keep producing high-LTV cohorts.
• Meta Ads — strong for high-LTV acquisition. Optimizing on the coarse: high bucket raises CPI but ROAS often follows. Advantage+ App Campaigns + SKAN 4.0 has been my best performer.
• Apple Search Ads — high intent, high conversion, high retention. Apple Search Ads receives SKAN postbacks directly; pairing the AppsFlyer integration with the Search Ads Attribution API yields the cleanest signal.

If you also run Apple Search Ads at scale, the keyword tiering pattern in Advanced Apple Search Ads Strategy pairs naturally with this attribution stack.

For per-channel conversion-value tuning, use SKAN 4.0's lockWindow to freeze values at postback window 1 and analyze each media partner as its own cohort. AppsFlyer's SKAN Cohort Builder makes this a few-clicks job.

Adjust-Specific Differences and Migration Tips

If you're switching from AppsFlyer to Adjust — or starting fresh with Adjust — the SDK surface looks similar, but conversion-value updates and the callback-parameter model differ in subtle ways. Adjust's addCallbackParameter lets you tag arbitrary key/values onto an event after the fact, which is genuinely useful when, say, only TikTok-sourced installs need a different conversion-value schema.

// src/lib/attribution-adjust.ts — react-native-adjust v5
import { Adjust, AdjustConfig, AdjustEvent } from 'react-native-adjust';
 
export function initAdjust(appToken: string) {
  const config = new AdjustConfig(
    appToken,
    __DEV__ ? AdjustConfig.EnvironmentSandbox : AdjustConfig.EnvironmentProduction,
  );
  config.setLogLevel(__DEV__ ? AdjustConfig.LogLevelDebug : AdjustConfig.LogLevelError);
  config.setAttributionCallbackListener((attribution) => {
    console.log('[Adjust] attribution', attribution);
  });
  // v4 used Adjust.create(config). v5 renamed this to initSdk.
  Adjust.initSdk(config);
}
 
export function trackPurchase(eventToken: string, amount: number, currency: string) {
  const event = new AdjustEvent(eventToken);
  event.setRevenue(amount, currency);
  // Conversion-value updates flow through the OS layer; do per-channel slicing via callback params
  event.addCallbackParameter('plan_id', 'pro_monthly');
  Adjust.trackEvent(event);
}

Check your major version before you copy anything. react-native-adjust v5 moved the entry point: the v4 Adjust.create(config) is now Adjust.initSdk(config), and pasting an older sample gets you Adjust.create is not a function at launch. Session-level callback parameters were renamed too — addSessionCallbackParameter became addGlobalCallbackParameter, while the event-level addCallbackParameter stayed put. Adjust's SDK v5 migration guide lists the rest.

Where to Register setAttributionCallbackListener, and What to Do with the Result

The callback I left as a bare console.log above is the first thing I'd touch in a real project. My own first version logged the attribution and stopped there. A few days later I wanted to use "which campaign brought this user in" on a screen, and there was nowhere to read it from.

Three things are worth knowing.

First, register the listener before Adjust.initSdk(config). Adding it after initialization won't get you a callback. The order of lines in the snippet above is a constraint, not tidiness.

Second, design on the assumption that the callback does not fire on every launch. It runs when attribution is determined or when it changes. If you wire a screen straight to it as though it were a per-launch value, the second launch will come up empty. Persist the value the moment you receive it and read from storage afterwards.

Third, expect empty fields. For organic installs, or when a network doesn't return details, values like campaign or adgroup may be blank. I treat blank as "unknown" rather than as an error.

// src/lib/attribution-store.ts — persist Adjust attribution once, reuse everywhere
import AsyncStorage from '@react-native-async-storage/async-storage';
import { Adjust, AdjustConfig } from 'react-native-adjust';
 
const KEY = 'adjust:attribution';
 
type StoredAttribution = {
  network: string;
  campaign: string;
  adgroup: string;
  creative: string;
  savedAt: number;
};
 
export function attachAttributionStore(config: AdjustConfig): void {
  // Call this before initSdk. A listener added afterwards won't be invoked.
  config.setAttributionCallbackListener(async (attribution) => {
    const next: StoredAttribution = {
      network: attribution.network || 'unknown',
      campaign: attribution.campaign || 'unknown',
      adgroup: attribution.adgroup || 'unknown',
      creative: attribution.creative || 'unknown',
      savedAt: Date.now(),
    };
    // The callback can fire again when attribution changes, so overwrite to stay current
    await AsyncStorage.setItem(KEY, JSON.stringify(next));
  });
}
 
export async function readStoredAttribution(): Promise<StoredAttribution | null> {
  const raw = await AsyncStorage.getItem(KEY);
  return raw ? (JSON.parse(raw) as StoredAttribution) : null;
}

On the calling side, add one line inside initAdjust — attachAttributionStore(config) after you build config and before Adjust.initSdk(config).

To check it, run in the Sandbox environment, wait a little after first launch, then call readStoredAttribution(). A non-null result means the wiring is right. If you get null straight away, give it a moment and try again — attribution is resolved over the network, not at launch. Field names and availability can shift between SDK versions, so confirm the list against the official docs for your major version before relying on them.

A received value isn't something to use on the spot; it's something to keep. Whether it ends up on a screen, in your conversion-value weighting, or as a clue for a support request, saving it first makes every later decision easier.

The most common stumbling block in an AppsFlyer → Adjust migration is having to re-implement the ATT consent flow. Both SDKs wrap the native ATT API, but their preferred initialization order differs. Adjust will internally wait for ATT to resolve even if you call Adjust.initSdk early, which makes the launch sequence feel marginally snappier than the AppsFlyer equivalent. You may also need to update your CMP rules — Adjust expects "tracking" consent in slightly different terminology than AppsFlyer.

A migration checklist that has saved me time: keep both SDKs running in parallel for a 2-week shadow period, compare daily install totals, and only flip ad networks over to the new MMP after the numbers reconcile to within 2–3%. SKAN's per-device randomization means a small variance is normal; anything wider usually points to schema or token mismatches.

Tying RevenueCat / StoreKit Subscription Events to SKAN

For subscription apps, mapping the trial → paid → cancellation lifecycle into SKAN conversion values is what separates "I ran ads" from "I know which channels actually pay back." If you use RevenueCat, the cleanest wiring is to bridge Purchases.addCustomerInfoUpdateListener directly into your conversion-value updater.

// src/lib/revenuecat-skan-bridge.ts
import AsyncStorage from '@react-native-async-storage/async-storage';
import Purchases, { CustomerInfo } from 'react-native-purchases';
import { reportEvent } from './conversion-value';
 
const SENT_KEY_PREFIX = 'skan:sent:';
 
// The listener also fires on renewals. This is the gate that keeps each signal to one send.
async function sendOnce(event: 'trial_started' | 'paid_started', payload: Record<string, unknown>) {
  const key = `${SENT_KEY_PREFIX}${event}`;
  if (await AsyncStorage.getItem(key)) return;
  await AsyncStorage.setItem(key, '1');
  await reportEvent(event, payload);
}
 
export function bindRevenueCatToSKAN() {
  Purchases.addCustomerInfoUpdateListener((info: CustomerInfo) => {
    const active = info.entitlements.active['pro'];
    if (!active) return;
 
    const payload = { product: active.productIdentifier };
    // periodType returns 'TRIAL' / 'NORMAL' / 'INTRO' — mind the casing
    if (String(active.periodType).toUpperCase() === 'TRIAL') {
      void sendOnce('trial_started', payload);
    } else {
      void sendOnce('paid_started', payload);
    }
  });
}

In the earlier version, both branches sent trial_started. The comment promised a clamp to the top of the range for the first paid period; the code sent the same event either way. SKAN's monotonic guard swallows the duplicate without an error, so the only symptom is a high bucket that never grows. Read both branches of a conditional out loud — that's the habit I've settled on after this one.

customerInfo also fires on renewals. Sending every time is mostly harmless thanks to the monotonic guard, but your event counts inflate and you lose the ability to tell where the first purchase actually was. Persisting a "sent" flag, as above, pays off the first time you have to reconstruct a cohort from logs. Don't forget to add paid_started to SCORE_MAP.

The same pattern works for in-app consumables. Map small purchases to a +8 jump in fine, larger ones to +16, and you'll start to see realistic per-channel ROAS in the AppsFlyer or Adjust cohort builder within 2–3 weeks of consistent volume.

Setting Up Server-to-Server Postback Verification

SKAN postbacks are sent from Apple's servers directly to ad networks, but you can — and should — also receive a copy at your own endpoint. A self-hosted S2S landing zone unlocks two things: independent re-analysis later (without being locked into one MMP's reporting), and the ability to detect attribution anomalies that the MMP dashboard might smooth over.

Both AppsFlyer and Adjust offer S2S postback forwarding. A small Cloudflare Workers endpoint is plenty.

// Cloudflare Workers — SKAN postback receiver
export default {
  async fetch(request: Request, env: { SKAN_KV: KVNamespace }): Promise<Response> {
    if (request.method !== 'POST') return new Response('OK', { status: 200 });
    const payload = await request.json<Record<string, unknown>>();
 
    // Minimal schema, no PII — we only persist what the postback already contains
    const key = `${payload['source-app-id'] ?? 'unknown'}:${payload['transaction-id']}`;
    await env.SKAN_KV.put(key, JSON.stringify(payload), {
      expirationTtl: 60 * 60 * 24 * 90, // 90-day retention
    });
    return new Response('stored', { status: 200 });
  },
};

Persist into KV (or D1 if you want SQL queries later). When MMP dashboards disagree with each other — which happens — having raw postbacks lets you settle the argument with first-party data. Expected behavior: each SKAN postback writes a JSON record keyed by source-app-id:transaction-id, visible via wrangler kv:key list or your preferred dashboard.

A nice side benefit: when you eventually outgrow the free AppsFlyer tier, you already have the foundation for an in-house reporting layer. The migration from "MMP dashboard" to "MMP + your own warehouse" can be done in days rather than months once the postback pipe exists.

How I Read the Numbers — My Weekly Operating Routine

To close, here's how I actually use the data day to day. Every Monday morning I block out 30 minutes for the dashboard. I look at exactly three things:

1. Whether last week's conversion-value distribution drifted from the trailing four-week average.
2. Whether the share of coarse: high matches my expectation for that mix of channels.
3. Whether any single channel is hitting the fine ceiling of 63 too quickly (an early sign that the schema is too coarse-grained for your top spenders).

I deliberately keep the list short. Drowning in granular reports slows decisions. A jump in low share usually means creatives are fatiguing, so I rotate ad sets that day. A jump in high share earns the channel a 20% budget bump and another week of observation. Fewer signals → faster decisions → more iterations per quarter. That cadence is what makes attribution work for solo developers in particular: you're not optimizing in the abstract, you're feeding a clear, repeatable loop.

If the numbers ever feel too noisy to act on, that's almost always a sign the conversion-value schema is wrong, not that the data is wrong. Revisit the weights, simulate them on paper against your last 30 days of in-app events, and ship a fresh schema before the next campaign refresh. I've shipped at least eight schema iterations on my own apps; the current one is far better than the first, and that's because the loop kept teaching me what mattered.

Closing Thoughts

Attribution looks intimidating from the outside, but once the wiring is in place it changes the speed and quality of every spend decision. Before you close this tab, install react-native-appsflyer in your Rork project and call initAttribution() once — that single working call is the highest-leverage step. Conversion-value design and the ATT pre-prompt are easier to refine once you can see live data.

Channel-side optimization assumes your measurement is honest. Lock down the SDK and conversion values first, then scale spend. With that order in place, even a solo developer can run an attribution stack on par with what an agency would build — and keep evolving it. I still revisit my schema almost monthly. Once you have the shape, the rest is craft.