Branch에서 AppsFlyer로 갈아타기

마케팅 비용 문제로 어트리뷰션 툴을 Branch에서 AppsFlyer로 교체했다.

딥링크 12종·이벤트 트래킹·어트리뷰션을 기능 손실 없이 이전하는 게 목표였고,

가장 어려웠던 건 SDK 교체가 아니라 타이밍 - 딥링크는 앱 준비보다 먼저 도착한다.

1️⃣ 왜 갈아탔나

마케팅팀에서 비용 문제로 Branch 계약을 정리하고 AppsFlyer로 전환하기로 결정했다. 개발 입장에서 요구사항은 명확했다.

• 기존 Branch가 담당하던 딥링크 12종이 그대로 동작할 것
• 디퍼드 딥링크(설치 전 클릭 → 설치 후 목적지 도착)가 유지될 것
• 회원가입·결제 등 전환 이벤트 트래킹이 이어질 것
• 마케팅팀이 보던 유입(어트리뷰션) 데이터가 끊기지 않을 것

2️⃣ 무엇을 무엇으로 대체하나

3️⃣ 아키텍처 - 문자열이 아니라 타입으로 라우팅

딥링크 처리는 잘못 만들면 "URL 문자열 파싱 + if-else 분기"가 앱 전체에 흩어지기 쉽다. 이번 기회에 라우팅을 타입으로 강제하는 구조로 잡았다.

Appsflyer
│   ├── AppsFlyerDeepLink.swift        // 경로 enum (12종)
│   ├── AppsFlyerManager.swift         // SDK 초기화 + delegate
│   ├── AppsFlyerRepository.swift      // 라우팅 + 화면 이동
│   ├── AppsflyerEventManager.swift    // 전환 이벤트
│   └── Protocol
│       ├── AppsFlyer.swift            // path + param 추상화
│       └── AppsFlyerRepositable.swift // 12종 구현 강제

딥링크 경로는 전부 enum이다.

enum AppsFlyerDeepLink: String {
    case onelink_mainscreen           = "onelink/mainscreen"
    case onelink_notice               = "onelink/notice"
    case onelink_mobilegift_detail    = "onelink/mobilegift/detail"
    case onelink_brandgift_main       = "onelink/brandgift/main"
    // ... 총 12종
}

이 구조를 고른 이유는 세 가지다.