답변
딥링크·디퍼드 딥링크에서 대행사가 원본 데이터·변경 이력·승인 기록을 갖고 있지 않으면, 문제가 생겼을 때 원인 추적도 분쟁 대응도 불가능해집니다. 대행사는 플랫폼 UI에 표시되는 집계 화면 스크린샷이 아니라, 원본 데이터(raw export — 일별·캠페인별 원시 로그, CSV/BigQuery 내보내기)를 별도로 보관해야 한다. 플랫폼이 집계 로직을 바꾸거나 데이터 보관기한이 지나 UI에서 조회가 안 될 때도, 원본만 있으면 재계산·재검증·분쟁 대응이 가능하다. 설정을 바꿀 때마다 변경 일시·변경자·변경 내용·변경 사유를 로그로 남겨야 한다(스프레드시트든 티켓 시스템이든 형식은 상관없다). 성과가 갑자기 흔들렸을 때 '언제 무엇이 바뀌었는지'를 로그 없이 기억에만 의존하면 원인 추적이 불가능해지고, 광고주와의 분쟁에서도 대행사를 보호할 근거가 사라진다. 예산 증액, 타겟팅·소재 교체, 실험 승패 확정처럼 되돌리기 어려운 주요 의사결정은 구두 통화가 아니라 이메일이나 협업툴 메시지처럼 서면으로 광고주 승인을 받아 남겨야 한다. 나중에 '그런 지시 없었다'는 분쟁이 생겼을 때 서면 승인 기록이 없으면 대행사가 불리한 입장에 놓인다. 딥링크는 URI 스킴·iOS 유니버설 링크·안드로이드 앱 링크 세 가지 구현 방식 중 무엇을 썼는지, deep_link_sub1~10 같은 파라미터 슬롯에 어떤 값을 담기로 규칙을 정했는지가 원본 문서로 남아있어야 한다. 여기에 더해 MMP(앱스플라이어·에어브릿지 등)가 제공하는 원링크(OneLink)/스마트링크의 raw 어트리뷰션 로그를 별도로 export해 보관해야, 나중에 특정 클릭이 왜 특정 화면으로 연결됐는지(또는 안 됐는지) 재현할 수 있다. 이 세 가지를 미리 갖춰두면, 문제가 생겼을 때도 원인을 빠르게 좁히고 대행사 스스로를 보호할 수 있습니다.