픽셀은 웹페이지에 삽입된 1×1 투명 이미지·자바스크립트로 브라우저를 통해 HTTP 요청을 보내는 방식이다
SDK는 앱 바이너리 안에 직접 심어져 브라우저 없이 앱 내부 이벤트를 측정 파트너(MMP)로 전송한다
웹은 gclid·fbclid·ttclid 같은 클릭ID로, 앱은 광고식별자(IDFA·GAID)나 SKAN으로 사용자를 식별한다
iOS 14.5 이후 ATT·iOS 26 Safari 클릭ID 제거로 두 채널 모두 클라이언트사이드 식별력이 약해지고 있다
픽셀은 정확히 어떤 방식으로 데이터를 보내나
추적 픽셀은 웹페이지나 이메일에 삽입된 1×1 크기의 투명 이미지 또는 자바스크립트 코드로, 사용자가 해당 페이지를 로드하는 순간 원격 서버로 HTTP 요청을 발생시켜 사용자 행동을 기록합니다. 구글 픽셀, 메타 픽셀, 틱톡 픽셀 등 대부분의 광고 플랫폼이 이 방식을 클라이언트사이드 추적의 기본 메커니즘으로 씁니다. 이 요청은 사용자 눈에 보이지 않지만, 광고 차단기나 강화된 개인정보보호 설정이 켜진 브라우저에서는 아예 발생하지 못하고 차단될 수 있다는 한계가 있습니다. 이 한계 때문에 픽셀 하나만으로 전환을 100% 잡아낼 수 있다고 전제하고 인프라를 설계하면 안 됩니다.
SDK는 픽셀과 무엇이 다른가
앱 환경에서는 웹의 픽셀에 해당하는 역할을 SDK(소프트웨어 개발 키트)가 맡습니다. SDK는 앱 바이너리 안에 직접 심어지는 코드 라이브러리로, 브라우저를 거치지 않고 앱 내부에서 발생한 이벤트(설치, 실행, 인앱 구매 등)를 수집해 측정 파트너(MMP) 서버로 직접 전송합니다. 웹 픽셀이 매 페이지 로드마다 브라우저를 통해 HTTP 요청을 쏘는 구조라면, SDK는 앱이 실행되는 동안 앱 프로세스 안에서 지속적으로 이벤트를 수집한다는 점에서 데이터가 만들어지는 계층 자체가 다릅니다. 이 차이를 모르고 웹 개발자에게 앱 SDK 연동을 그대로 맡기면 이벤트 누락이 발생하기 쉽습니다.
웹과 앱에서 사용자를 식별하는 방법이 왜 다른가
웹에서는 광고 클릭 시 각 플랫폼이 클릭ID를 목적지 URL에 자동으로 붙입니다. 구글의 gclid, 메타의 fbclid, 틱톡의 ttclid, 마이크로소프트의 msclkid가 대표적으로, 각각 해당 플랫폼이 클릭과 전환을 매칭하는 데 쓰는 불투명 식별자입니다. 반면 앱에서는 이런 URL 파라미터 방식 대신 광고식별자(iOS의 IDFA, 안드로이드의 GAID)나 SDK가 자체적으로 관리하는 디바이스 지문 방식으로 사용자를 식별합니다. 이 차이 때문에 웹 추적 로직을 그대로 앱에 옮겨 쓸 수 없고, 채널마다 별도의 식별 체계를 이해해야 합니다.
iOS 앱 추적에서는 왜 SDK만으로 부족한가
iOS 14.5부터 도입된 App Tracking Transparency(ATT) 이후 대다수 iOS 사용자가 추적을 거부하면서, SDK가 광고식별자를 통해 사용자를 식별하는 전통적 방식이 사실상 무력화됐습니다. 이를 보완하기 위해 애플은 SKAdNetwork(SKAN)를 유일한 공식 귀인 솔루션으로 두고 있으며, SKAN 4.0은 0~2일·3~7일·8~35일 세 개의 포스트백 윈도우로 나눠 전환 데이터를 익명화된 형태로 전달합니다. 2024년에는 후속 프레임워크인 AdAttributionKit(AAK)이 발표돼 설정 가능한 귀인 윈도우 등 더 유연한 기능을 제공하기 시작했지만, 2026년 기준으로는 SKAN 3 중심 운영이 여전히 많아 SDK·MMP·SKAN을 함께 이해해야 앱 캠페인의 데이터 인프라를 온전히 파악할 수 있습니다.
웹 픽셀에서는 왜 클릭ID를 직접 캡처해야 하나
iOS 26부터는 사파리의 Link Tracking Protection이 기본 활성화돼 프라이빗 브라우징, 메시지, 메일 등에서 gclid·fbclid·ttclid 같은 클릭ID가 제거됩니다. 이 때문에 웹 픽셀만으로는 광고 클릭과 전환을 연결하는 정확도가 크게 떨어질 수 있어, 클릭ID를 랜딩페이지 도달 즉시 자사 서버나 데이터베이스에 직접 캡처해 저장해두는 구조가 필요해졌습니다. 이렇게 캡처한 클릭ID는 이후 2강에서 다루는 포스트백 전송 시 전환 데이터와 함께 매체 서버로 되돌려 보내는 데 쓰입니다.
실무자가 픽셀·SDK 인프라를 설계할 때 첫 번째로 확인할 것
가장 먼저 자사 비즈니스가 웹 중심인지 앱 중심인지, 혹은 두 채널을 모두 쓰는지부터 명확히 해야 합니다. 웹이라면 픽셀 설치 위치와 클릭ID 캡처 로직을, 앱이라면 SDK 연동과 SKAN·AAK 대응 여부를 우선 점검 대상으로 삼아야 합니다. 두 채널을 동시에 운영한다면 각 채널이 서로 다른 식별 체계를 쓴다는 전제 아래, 이 과목 뒤에서 다룰 MMP 통합(84강)과 GA4 연동(80강)까지 함께 설계하는 것이 데이터 파편화를 막는 출발점입니다.
두 인프라를 처음부터 함께 설계해야 하는 이유
웹 픽셀과 앱 SDK를 각각 다른 팀·다른 시점에 따로 붙이면, 같은 고객이 앱에서 장바구니에 담고 웹에서 결제를 완료하는 경우처럼 채널을 넘나드는 여정을 하나의 고객으로 이어 붙이기가 어려워집니다. 초기 설계 단계에서부터 웹의 클릭ID와 앱의 광고식별자·MMP 데이터를 하나의 고객 ID(예: 로그인 회원번호)로 연결할 수 있는 구조를 함께 잡아두면, 이후 크로스 디바이스·크로스 채널 분석을 다시 갈아엎는 비용을 줄일 수 있습니다. 이 통합 설계는 이 과목 4~5강에서 다루는 포스트백 트러블슈팅, 84강 MMP 실무와 이어지는 전제 작업입니다.
다음 행동
자사가 운영 중인 채널이 웹인지 앱인지, 각각 어떤 식별자(클릭ID·광고식별자)로 사용자를 추적하고 있는지 먼저 점검해보세요. 다음 편(2강)에서는 이 데이터를 자사 서버와 매체 서버 사이에 주고받는 포스트백(S2S) 통신의 구체적 규약을 다룹니다.
CHALLENGE
배운 걸 실전 문제로 확인
카테고리별 Level Test로 실무 레벨을 점검해보세요.