Android(Kotlin)与iOS(Swift)网页弹窗转化后安装源及深链检测咨询

一、需求背景 #

我正在开发基于Android(Kotlin)和iOS(Swift)的跨平台移动应用，需要识别应用的安装来源，打通网页推广到应用安装、登录的链路，实现精准归因并发放优惠券。

二、使用场景与用户流程 #

使用场景 #

网站展示弹窗：

“安装应用即可领取优惠券”

用户流程 #

• 用户访问网站
• 用户点击弹窗/横幅
• 用户从App Store/Google Play安装移动应用
• 用户打开应用并登录
• 应用识别该安装来自网页弹窗推广活动
• 后端向该用户发放优惠券

三、期望实现目标 #

需要追踪以下信息并完成链路打通：

• 安装来源（install source）
• 推广活动ID（campaign ID）
• 延迟深度链接信息（deferred deep link information）
• 首次安装后的用户归因（attribution after first install）
• 打通网页推广活动→应用安装→用户登录的完整链路

四、核心问题 #

Android (Kotlin) #

• 是否有官方方法检测install referrer（安装来源追踪参数）？
• 应该选择哪种方案：
  • Google Play Install Referrer API？
  • Firebase Dynamic Links？
  • AppsFlyer / Adjust / Branch？
• 如何安全传递推广活动参数？（示例：myapp://coupon?campaign=web_popup_001）

iOS (Swift) #

• 由于App Store不支持类似Android的install referrer，推荐的实现方案是什么？
• Universal Link + 延迟深度链接（deferred deep linking）是否为正确解决方案？
• 生产环境中常用的服务有哪些？

五、额外要求 #

• 需支持全新安装场景
• 用户可能先安装应用，之后再登录
• 后端需识别推广活动并发放优惠券
• 偏好官方或稳定的解决方案

六、已调研内容 #

• Android Install Referrer API
• Firebase Dynamic Links（疑似已废弃）
• Branch.io
• AppsFlyer
• Adjust

七、解决方案建议 #

架构建议 #

采用「前端推广链接生成 + 客户端归因SDK收集数据 + 后端关联用户与归因信息」的三层架构：

1. 网页端：为每个推广活动生成带唯一参数的跳转链接（包含campaign ID等信息），引导用户跳转至应用商店或触发延迟深度链接。
2. 客户端：集成归因SDK，在应用首次启动时获取归因数据，存储本地并在用户登录时同步至后端。
3. 后端：接收客户端上传的归因数据与用户ID，关联后完成优惠券发放逻辑。

推荐SDK/服务 #

Android端

1. Google Play Install Referrer API（官方首选）：
   • 直接获取Google Play传递的安装来源参数，无需第三方依赖，数据可靠且免费。
   • 局限性：仅能获取安装来源基础信息，不支持延迟深度链接，需配合其他方案补充。
2. Firebase App Check + Firebase Analytics（官方生态）：
   • 虽然Firebase Dynamic Links已废弃，但可结合Firebase Analytics追踪安装来源，配合自定义参数传递campaign信息。
3. 第三方服务（AppsFlyer/Adjust/Branch）：
   • 适合需要跨平台统一归因、复杂链路追踪的场景，支持延迟深度链接、多渠道归因，但需付费。

iOS端

1. Universal Links + App Store Connect Attribution（官方方案）：
   • 通过Universal Links传递推广参数，结合App Store Connect的归因API获取安装来源，免费且稳定。
2. 第三方服务（AppsFlyer/Adjust/Branch）：
   • 提供成熟的延迟深度链接方案，自动处理App Store跳转后的归因逻辑，跨平台体验一致，适合企业级应用。

示例实现流程 #

网页端

生成推广链接：

• Android：https://play.google.com/store/apps/details?id=com.yourapp&referrer=campaign%3Dweb_popup_001%26source%3Dweb
• iOS：https://yourapp.com/coupon?campaign=web_popup_001（配置为Universal Link，跳转至App Store）

Android端（Kotlin）

1. 集成Google Play Install Referrer API：

val referrerClient = InstallReferrerClient.newBuilder(context).build()
referrerClient.startConnection(object : InstallReferrerStateListener {
    override fun onInstallReferrerSetupFinished(responseCode: Int) {
        when (responseCode) {
            InstallReferrerClient.InstallReferrerResponse.OK -> {
                val response = referrerClient.installReferrer
                val referrerUrl = response.installReferrer
                // 解析referrerUrl中的campaign参数
                val campaign = referrerUrl.split("campaign=")[1].split("&")[0]
                // 存储本地，待用户登录后上传后端
                SharedPreferencesManager.saveCampaign(campaign)
            }
            // 处理其他响应码
        }
    }

    override fun onInstallReferrerServiceDisconnected() {
        // 重新连接逻辑
    }
})

2. 用户登录时，将存储的campaign参数与用户ID一起上传至后端。

iOS端（Swift）

1. 配置Universal Links，在AppDelegate或SceneDelegate中处理链接：

func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool {
    if userActivity.activityType == NSUserActivityTypeBrowsingWeb {
        guard let url = userActivity.webpageURL else { return false }
        // 解析URL中的campaign参数
        if let components = URLComponents(url: url, resolvingAgainstBaseURL: true),
           let campaign = components.queryItems?.first(where: { $0.name == "campaign" })?.value {
            // 存储本地，待用户登录后上传后端
            UserDefaults.standard.set(campaign, forKey: "campaign_id")
        }
    }
    return true
}

2. 处理延迟深度链接（以Branch为例）：

Branch.getInstance().initSession(launchOptions: launchOptions) { params, error in
    if let campaign = params?["campaign"] as? String {
        UserDefaults.standard.set(campaign, forKey: "campaign_id")
    }
}

3. 用户登录时，将campaign参数与用户ID上传至后端。

Kotlin + Swift应用最佳实践 #

1. 统一参数命名：Android和iOS端使用相同的参数名（如campaign），便于后端统一处理。
2. 本地数据持久化：将归因参数存储在本地（SharedPreferences/UserDefaults），避免应用重启丢失，待用户登录后再上传后端。
3. 数据校验：后端接收归因参数时，需校验参数的合法性（如campaign ID是否存在于活动列表），防止伪造。
4. 隐私合规：遵循GDPR、CCPA等法规，告知用户数据追踪目的，提供关闭选项。
5. 测试验证：分别测试全新安装、已安装后点击链接、先安装后登录等场景，确保归因准确。

内容的提问来源于stack exchange，提问作者Nguyễn Đức Thành