어트리뷰션 드롭이란 웹 클릭과 설치된 앱 사이의 연결이 완전히 끊겨 캠페인 파라미터가 비거나 사라지는 현상이다
매칭 실패 시 캠페인 파라미터 값들이 null이거나 아예 존재하지 않는 형태로 앱에 전달된다
원인은 SDK 연동 오류, 매체·스토어·앱 3단계 중 설정 불일치 등 여러 곳에 있을 수 있다
삭제→클릭→재설치→최초 실행의 전체 흐름을 직접 재현하는 테스트가 원인 진단의 기본이다
어트리뷰션 드롭은 정확히 어떤 현상인가
디퍼드 딥링킹이 제대로 구현되지 않으면 신규 사용자는 캠페인 맥락 없이 홈 화면에 진입하며, 원래 캠페인 파라미터를 담아야 할 값들이 비어있거나(null) 아예 존재하지 않게 됩니다. 2강에서 다룬 클릭-저장-설치-매칭 흐름 중 어느 단계에서든 문제가 생기면 이 현상으로 나타날 수 있어, "어트리뷰션 드롭"이라는 하나의 증상 뒤에 여러 다른 원인이 숨어있을 수 있습니다.
왜 웹 세션과 설치된 앱의 연결이 끊어지나
이는 웹 세션과 설치된 앱 바이너리 사이의 연결이 완전히 끊어져, 앱이 설치 출처를 식별할 방법이 없어지기 때문입니다. 클릭 시점에 저장한 디바이스 정보와 최초 실행 시점의 디바이스 정보가 매칭 서버에서 대조되지 못하면, SDK는 이 설치를 "출처를 알 수 없는 유입"으로 처리하고 캠페인 관련 값을 채워줄 근거 자체가 없어집니다.
어느 단계부터 점검을 시작해야 하나
디퍼드 딥링크 실패 요인은 SDK 연동이 정확히 구성됐는지부터 확인해야 합니다. 클릭 시점에 링크가 정상적으로 클릭 정보를 서버에 전송했는지(6강에서 다룬 검증 도구의 개념을 앱 SDK에도 유사하게 적용), 스토어로 넘어가는 과정에서 정보 손실이 없었는지, 최초 실행 시 SDK가 매칭 서버에 정상적으로 조회를 보내고 응답을 받는지를 순서대로 점검하는 것이 논리적입니다.
매체·스토어·앱 3단계를 나눠 봐야 하는 이유
어트리뷰션 드롭은 광고 매체 쪽 설정, 앱스토어·플레이스토어 리스팅 설정, 앱 내부 SDK 구현 중 어느 한 곳의 불일치에서도 발생할 수 있습니다. 예를 들어 광고 매체 템플릿에 등록된 캠페인 링크와 실제 스토어 리스팅에 연결된 트래킹 URL이 서로 다른 버전이라면, 세 곳 모두 개별적으로는 정상 작동해도 전체 흐름에서는 연결이 끊깁니다. 광고 플랫폼 템플릿, 스토어 리스팅, 인앱 라우트 설정이 서로 일치하는지 확인하고, 클릭에서 스토어를 거쳐 최초 실행까지 이어지는 전체 경로를 플랫폼별로 QA하는 것이 필요합니다.
재현 테스트는 구체적으로 어떻게 진행해야 하나
디퍼드 딥링크 정상 작동 여부는 삭제→클릭→재설치→최초 실행의 전체 흐름을 iOS·안드로이드 양쪽에서 직접 재현해, 의도한 화면과 파라미터가 정상적으로 도달하는지 확인하는 테스트로 검증해야 합니다. 실제 캠페인 링크를 클릭하고, 앱을 완전히 삭제한 뒤 스토어에서 재설치하고, 최초 실행 시 어느 화면이 열리는지 눈으로 직접 확인하는 이 과정을 생략하고 로그만 들여다보면 실제 유저 경험과 괴리된 결론에 이를 수 있습니다.
로그에서 무엇을 대조해야 원인이 좁혀지나
클릭 시점 로그(디바이스 정보, 타임스탬프)와 최초 실행 시점 로그(같은 디바이스 정보, SDK 응답 코드)를 나란히 놓고 대조하면, 매칭이 실패한 시점이 클릭 데이터 저장 단계인지 최초 실행 조회 단계인지 구분할 수 있습니다. 클릭 로그 자체가 없다면 4강에서 다룬 인앱 브라우저 우회 문제로 애초에 클릭 정보가 저장되지 못했을 가능성을, 클릭 로그는 있는데 매칭이 실패했다면 2강에서 다룬 확률적 매칭의 정확도 한계(70~90%) 안에서 발생한 자연스러운 미매칭일 가능성을 함께 고려해야 합니다.
모든 경우를 100% 해결할 수는 없다는 전제
확률적 매칭에 의존하는 이상, 일정 비율의 미매칭은 기술적으로 불가피합니다. 목표는 이 비율을 0%로 만드는 것이 아니라, 확정적 매칭(구글 인스톨 리퍼러 등)을 최대한 활용해 확률적 매칭에 의존하는 비율 자체를 줄이고, 나머지 미매칭 건에 대해서는 "미확인 유입"으로 명확히 분류해 리포팅에서 왜곡 없이 다루는 것입니다.
iOS와 안드로이드에서 원인이 다르게 나타날 수 있다
안드로이드는 구글 플레이스토어의 인스톨 리퍼러 API로 비교적 신뢰도 높은 확정적 매칭을 쓸 수 있는 반면, iOS는 이런 확정적 식별자가 제한적이라 상대적으로 확률적 매칭에 더 많이 의존하게 됩니다. 같은 캠페인이라도 어트리뷰션 드롭 발생률이 iOS에서 유독 높게 나타난다면, 이는 시스템 결함이 아니라 두 플랫폼의 근본적인 기술적 제약 차이일 수 있다는 점을 함께 감안해 원인을 판단해야 합니다.
반복적으로 발생하는 사고 유형을 기록해둬야 하는 이유
어트리뷰션 드롭 사고를 한 번 해결하고 넘어가면, 비슷한 원인(예: 특정 광고 매체 템플릿의 URL 버전 불일치)이 다른 캠페인에서 반복될 때 처음부터 다시 원인을 찾아야 합니다. 65강 11강에서 다룬 정기 점검 기록과 마찬가지로, 발견된 사고 유형과 해결 방법을 기록해두면 다음번에는 훨씬 빠르게 원인을 좁힐 수 있으며, 담당자가 바뀌더라도 이 기록이 그대로 인수인계 자산이 됩니다.
다음 행동
최근 발생한 어트리뷰션 드롭 사례 하나를 골라 삭제→클릭→재설치→최초 실행 흐름을 직접 재현해보고, 클릭 로그와 최초 실행 로그를 나란히 대조해 어느 단계에서 연결이 끊겼는지 좁혀보세요. 다음 편(10강)에서는 지금까지 다룬 온라인 딥링크 인프라를 오프라인 접점(QR코드)과 결합해 팝업스토어·배송 박스에서도 같은 원리를 적용하는 방법을 다룹니다.
← 이전 글 · 레슨 08 개발 팀과의 테크니컬 소통법: 딥링크 라우팅(Routing) 테이블 구축을 위해 마케터가 개발진에게 제공해야 할 상품 ID 및 카테고리 코드 매칭 표
CHALLENGE
배운 걸 실전 문제로 확인
카테고리별 Level Test로 실무 레벨을 점검해보세요.
