> Приходилось ли определять органических и неорганических пользователей в приложении (iOS, Swift)

Короткий ответ

Да, приходилось. Определение органических и неорганических пользователей - это стандартная задача аналитики в мобильных приложениях. Обычно решается через маркетинговые атрибуции (например, AppsFlyer, Adjust) или через собственную логику на бэкенде: фиксируем источник установки, первый переход по deep link, наличие UTM-меток. На iOS важно учитывать ограничения ATT (App Tracking Transparency) и использовать SKAdNetwork для атрибуции без IDFA.

Подробное объяснение

Органические пользователи - те, кто установил приложение самостоятельно, без платного рекламного воздействия. Неорганические - пришли по рекламной кампании, партнёрской ссылке или промо-акции.

Технически разделение происходит на уровне атрибуции:

• На клиенте: при первом запуске отправляем на бэкенд идентификатор установки (например, UUID, сгенерированный при первом запуске), данные о source (App Store, deep link, referrer), параметры кампании (campaign, adset, creative).
• На бэкенде: сервер сопоставляет эти данные с записями о рекламных кликах (клик по ссылке → установка). Если совпадение найдено - пользователь неорганический, иначе - органический.
• Через SDK атрибуции: AppsFlyer, Adjust, Branch. Они сами отслеживают клики и установки, а приложение получает callback с типом пользователя.

На iOS ключевой нюанс - IDFA. После iOS 14.5 доступ к IDFA требует разрешения пользователя через ATT. Если пользователь отказал, атрибуция через IDFA невозможна. Поэтому используется SKAdNetwork - Apple-овский механизм, который передаёт атрибуцию на уровне операционной системы, без доступа к IDFA. SDK атрибуции получает postback от SKAdNetwork и передаёт его на сервер.

Также важно различать первый запуск и повторные. Органический/неорганический статус определяется один раз - при первой сессии. Дальше он хранится в профиле пользователя и используется для аналитики, ретаргетинга и расчёта ROI.

На практике

В реальном проекте я делал так:

• Интегрировал AppsFlyer SDK в iOS-приложение.
• В application(_:didFinishLaunchingWithOptions:) инициализировал SDK и передавал conversionData в бэкенд через отдельный endpoint.
• Бэкенд сохранял is_organic флаг в профиле пользователя.
• Для аналитики использовал событие first_launch с параметрами source, campaign, is_organic.
• Если пользователь пришёл по deep link, обрабатывал его в application(_:open:options:) и передавал параметры ссылки в атрибуционную систему.

Также сталкивался с кейсом, когда нужно было отличать органических пользователей, пришедших из App Store Search Ads. Здесь используется отдельный механизм - AAAttribution (Apple Search Ads Attribution API). Он возвращает campaignId и isOrganic без запроса ATT.

Пример кода

SWIFT
import AppsFlyerLib

final class AttributionService {
    static let shared = AttributionService()
    private let appsFlyer = AppsFlyerLib.shared()
    
    func setup() {
        appsFlyer.appsFlyerDevKey = "YOUR_DEV_KEY"
        appsFlyer.appleAppID = "YOUR_APP_ID"
        appsFlyer.delegate = self
        appsFlyer.isDebug = false
    }
    
    func start() {
        appsFlyer.start()
    }
    
    func handleDeepLink(_ url: URL) {
        appsFlyer.handleOpen(url, options: nil)
    }
}

extension AttributionService: AppsFlyerLibDelegate {
    func onConversionDataSuccess(_ conversionInfo: [AnyHashable: Any]) {
        guard let isOrganic = conversionInfo["is_organic"] as? Bool else { return }
        let source = conversionInfo["media_source"] as? String ?? "unknown"
        let campaign = conversionInfo["campaign"] as? String ?? ""
        
        // Отправляем на бэкенд
        sendAttributionToBackend(
            isOrganic: isOrganic,
            source: source,
            campaign: campaign
        )
    }
    
    func onConversionDataFail(_ error: Error) {
        // Логируем ошибку, помечаем пользователя как organic по умолчанию
        sendAttributionToBackend(isOrganic: true, source: "unknown", campaign: "")
    }
}

Как отвечать на собеседовании

Начни с определения терминов, затем переходи к практическому опыту. Упомяни, что задача решается на стыке клиента и сервера, и что на iOS есть специфика с ATT и SKAdNetwork. Если есть опыт с конкретными SDK - назови их. Покажи понимание, что статус определяется один раз и хранится на бэкенде. Если спросят про Apple Search Ads - упомяни AAAttribution.

Что проверяет интервьюер

• Понимание разницы между органическими и неорганическими пользователями.
• Знание механизмов атрибуции на iOS: IDFA, ATT, SKAdNetwork, deep link.
• Опыт работы с SDK атрибуции (AppsFlyer, Adjust, Branch).
• Умение объяснить, как данные атрибуции попадают на бэкенд и используются дальше.
• Понимание ограничений приватности и как они влияют на атрибуцию.

Типичные ошибки

• Путаница между органическим пользователем и пользователем, который не дал разрешение на трекинг.
• Утверждение, что атрибуция возможна только через IDFA - это не так, есть SKAdNetwork и server-to-server атрибуция.
• Игнорирование Apple Search Ads как отдельного канала.
• Отсутствие обработки ошибок при получении conversion data - если SDK не ответил, пользователь не должен теряться.
• Хранение статуса только на клиенте - это ненадёжно, статус должен быть на бэкенде.