DSP는 SKAdNetwork 포스트백을 어떻게 처리하나요? DSP(수요 측 플랫폼) 및 광고 네트워크는 안전한 HTTP POST 수집 엔드포인트를 구축하고, U+2063 구분자를 사용하여 직렬화된 UTF-8 메시지 문자열을 생성하며, Apple의 공개 키를 통해 Apple의 암호화된 ECDSA P-256 서명을 검증하고, 입찰 모델을 업데이트하기 전에 중복 처리를 방지하기 위해 검증된 트랜잭션 ID를 기록하는 방식으로 SKAdNetwork 포스트백을 처리합니다.
SKAdNetwork 설치 검증 포스트백은 운영 체제가 적격 광고 네트워크와 어트리뷰션 성과에 기여한 경우 광고 대상 앱 개발자가 구성한 복사 엔드포인트에 선택적으로 전송하는 Apple 서명 기반 HTTPS POST 알림입니다. 데이터 무결성을 보장하기 위해 백엔드 수집 시스템은 Apple의 ECDSA P-256 서명을 검증하고, 매개변수 직렬화를 확인하며, 트랜잭션 수준의 중복 제거를 적용해야 합니다.
| 용어 | 정의 |
|---|---|
| SKAdNetwork | 프라이버시를 보호하는 광고 캠페인 어트리뷰션을 위한 Apple의 플랫폼 수준 프레임워크입니다. |
| 설치 검증 포스트백 | 적격 광고 전환 후 설치 검증 및 어트리뷰션 메타데이터를 포함하는 Apple 서명 기반 JSON 페이로드입니다. |
| ECDSA P-256 | Apple이 설치 검증 포스트백에 서명하는 데 사용하는 타원 곡선 암호화 알고리즘입니다. |
| 트랜잭션 ID | 수신자가 중복 감지를 위한 멱등성 키로 사용하는 고유한 검증 식별자입니다. |
DSP 및 광고 네트워크를 위한 SKAdNetwork 포스트백 수집 아키텍처
이중 수집 파이프라인: 직접 광고 네트워크 전달 대 개발자 포스트백 엔드포인트
어트리뷰션된 iOS 애플리케이션 설치가 발생하면 Apple의 어트리뷰션 서브시스템이 HTTPS POST를 통해 설치 검증 포스트백을 발송합니다.
- 광고 네트워크 수집: 기기는 Apple 레지스트리의 해당
ad-network-id아래에 등록된 서버 URL로 기본 승인 포스트백(did-win: true)을 직접 전달합니다. - 개발자 복사본 수집: 광고 대상 앱이
Info.plist에NSAdvertisingAttributionReportEndpoint키를 지정한 경우, 기기는 승인 포스트백의 정확한 복사본을 개발자 서버로 동시에 직접 발송합니다. - 비승인 포스트백 라우팅: SKAdNetwork 3.0부터 여러 광고 네트워크가 어트리뷰션 자격을 충족했으나 승인되지 않은 경우, 기기는 최대 5개의 비승인 포스트백(
did-win: false)을 해당 2차 적격 광고 네트워크로 직접 전송합니다. 비승인 포스트백은 개발자 복사본 엔드포인트로 전달되지 않습니다.
백엔드 수집 엔드포인트는 HTTP 200 OK로 응답해야 합니다. 기기가 200 응답을 받지 못하면 최대 9일 동안 최대 9회까지 전달을 재시도할 수 있습니다.
개발자 감사를 위한 NSAdvertisingAttributionReportEndpoint의 역할
NSAdvertisingAttributionReportEndpoint를 통해 앱 개발자는 광고 네트워크 전달과 무관하게 승인 포스트백의 직접 복사본을 받을 수 있습니다.
- 독립적 감사: 개발자는 애플리케이션을 위해 생성된 모든 승인 포스트백의 정확한 복사본을 받아 광고 네트워크 리포팅을 내부적으로 검증할 수 있습니다.
- 전용 엔드포인트 경로: 개발자 서버는
https://<domain>/.well-known/skadnetwork/report-attribution/에 엔드포인트를 호스팅해야 합니다. - AdAttributionKit 차이점: AdAttributionKit의 경우, Apple은 JWS(JSON Web Signature) 검증 아키텍처를 사용하는
https://<domain>/.well-known/appattribution/report-attribution/으로 라우팅되는 별도의 구성을 정의합니다.
MMP의 다중 네트워크 S2S 이벤트 스트림 수집, 집계 및 정규화 방식
상업적 통합에 따라 MMP(모바일 측정 파트너)는 개발자 측 포워딩, 광고 네트워크 통합 또는 커스텀 파트너 서버 플로우를 통해 SKAdNetwork 데이터를 수집할 수 있습니다.
- 다중 소스 수집: 직접 광고 네트워크 리포팅 스트림과 함께 개발자 엔드포인트에서 전달된 검증된 포스트백 데이터를 수집합니다.
- 스트림 간 중복 제거: 공유된 광고 네트워크 복사본과 개발자 복사본 간의 고유한
transaction-id를 사용하여 레코드를 정규화하고 중복을 제거합니다. - 다운스트림 BI 정규화: 세부 및 요약 전환 값을 클라이언트가 정의한 수익 모델 및 퍼널 이벤트에 매핑합니다.
참고 항목: SKAdNetwork ──> 모바일 어트리뷰션 모델
암호화 검증: Apple의 ECDSA P-256 서명 유효성 검사
암호화 스택 이해: SHA-256을 포함하는 NIST 곡선 P-256(secp256r1)
모든 SKAdNetwork 포스트백에는 attribution-signature 필드가 포함됩니다. 이 암호화 서명은 NIST P-256(secp256r1) 곡선과 SHA-256 다이제스트를 사용하는 ECDSA(타원 곡선 디지털 서명 알고리즘)를 사용하여 Apple이 생성합니다.
이 서명은 두 가지 기본 보안 속성을 검증합니다.
- 진위성: 포스트백이 악의적인 클라이언트나 프록시에 의해 위조된 것이 아니라, 검증된 기기의 Apple 플랫폼 서브시스템에 의해 직접 생성되었음을 보장합니다.
- 무결성: 서명이 적용된 매개변수가 전송 중에 변경되지 않았음을 보장합니다.
Apple이 공개한 SKAdNetwork 공개 키 사용
서명을 검증하려면 수집 서버가 Apple의 공식 공개 키를 로드해야 합니다. SKAdNetwork 2.1 이상 버전의 경우, Apple은 개발자 문서에 전용 NIST P-256 공개 키를 게시합니다.
- 키 초기화: 서버 초기화 중에 공개 키가 표준 X.509/DER 공개 키 객체로 메모리에 로드됩니다.
- 비대칭 서명 확인: 검증 엔진은 정확히 직렬화된 UTF-8 메시지 문자열을 재구성하고, SHA-256 해시를 계산한 후, Base64로 디코딩된
attribution-signature를 재구성된 메시지와 대조하여 검증합니다.
[Device / Subsystem] ──► [Dispatches Signed JSON Postback]
│
▼
[DSP / Ad Network Ingestion Endpoint]
(HTTPS POST to registered postback URL)
│
▼
[Parse JSON & Reconstruct Message String]
(Concatenate UTF-8 fields with \u2063)
│
▼
[ECDSA P-256 Public Key Signature Verification]
│
┌──────────────┴──────────────┐
▼ ▼
[Signature Valid] [Signature Invalid]
│ │
▼ ▼
[Atomic Deduplication] [Log Error & Discard]
(Check transaction-id)
│
▼
[Process Attribution]
해시만으로는 충분하지 않은 이유: 비대칭 서명 검증
Apple은 비공개 키를 사용하여 페이로드에 서명하고 공유 비밀 키를 배포하지 않기 때문에 대칭 유효성 검사(예: HMAC-SHA256)를 사용할 수 없습니다. 수집 엔진은 표준 암호화 라이브러리(예: OpenSSL, Node.js crypto, Python cryptography)를 사용하여 표준 비대칭 공개 키 서명 검증을 구현해야 합니다.
서명 검증을 위한 메시지 문자열 구성
엄격한 직렬화 프로토콜: 보이지 않는 구분자(\u2063)의 역할
Apple은 서명 유효성 검사를 위한 메시지 문자열을 구성하는 정확한 UTF-8 바이트 직렬화 형식을 지정합니다. 매개변수는 보이지 않는 유니코드 문자 \u2063(U+2063 보이지 않는 구분자, UTF-8 바이트 시퀀스 0xE2 0x81 0xA3)로 구분되어 정확한 순서로 연결되어야 합니다.
공백, 표준 구두점 또는 대체 유니코드 구분자를 대신 사용하면 암호화 검증이 실패합니다.
SKAN 4.0을 위한 버전별 매개변수 순서
설치 검증 포스트백 검증에 관한 Apple 개발자 문서에 따라, SKAdNetwork 4.0 포스트백의 매개변수는 정확히 다음 순서로 직렬화되어야 합니다.
version(예:"4.0")ad-network-id(예:"example123.skadnetwork")source-identifier(예:"4821")app-id(예:1234567890)transaction-id(예:"6a8b1c2d-3e4f-5a6b-7c8d-9e0f1a2b3c4d")redownload(예: 소문자 문자열인"true"또는"false")source-app-id(앱 간 광고의 경우) 또는source-domain(Safari의 웹투앱 광고의 경우, 포스트백에 존재하는 경우에만 포함)fidelity-type(예: StoreKit 렌더링 광고 또는 SKAdNetwork 어트리뷰션 웹 광고의 경우1; 조회형 광고의 경우0)did-win(예: 소문자 문자열인"true"또는"false")postback-sequence-index(예:0,1또는2)
중요한 SKAN 4 사양: 변환 값은 서명에서 제외됨
SKAdNetwork 4.0에서 Apple의 서명에는 JSON 페이로드에 해당 필드 중 하나가 포함되어 있는 경우에도 conversion-value 또는 coarse-conversion-value가 포함되지 않습니다. SKAN 4용 직렬화된 문자열은 postback-sequence-index로 끝납니다. 메시지 문자열에 변환 값을 추가하려고 하면 검증에 실패합니다.
아래의 JSON 페이로드는 완전한 SKAdNetwork 4.0 포스트백 스키마를 보여줍니다. 아래의 서명은 예시용 플레이스홀더이며 암호화 검증을 통과하지 못합니다. 단위 테스트를 위해서는 공식 검증 문서에 있는 Apple의 서명된 예시를 사용하십시오.
{
"version": "4.0",
"ad-network-id": "example123.skadnetwork",
"source-identifier": "4821",
"app-id": 1234567890,
"transaction-id": "6a8b1c2d-3e4f-5a6b-7c8d-9e0f1a2b3c4d",
"redownload": false,
"source-app-id": 9876543210,
"fidelity-type": 1,
"did-win": true,
"postback-sequence-index": 0,
"conversion-value": 47,
"attribution-signature": "MEQCIFz8...SAMPLE_CRYPTOGRAPHIC_SIGNATURE...=="
}
다중 윈도우 SKAN 4.0 페이로드 및 개발자 엔드포인트 처리
순차적 전환 윈도우 전반에 걸친 postback-sequence-index 파싱
SKAdNetwork 4.0에서 전환은 최초 앱 실행 후 최대 35일에 걸치는 전환 윈도우로부터 포스트백을 생성하며, 실제 전달은 Apple의 무작위화된 윈도우 이후 지연 시간 후에 발생합니다. 백엔드 수집 시스템은 postback-sequence-index 필드를 파싱하여 전환 데이터를 올바른 라이프사이클 윈도우에 할당합니다.
- 인덱스
0(윈도우 1: 0~2일차): 세부 전환 값(0~63) 또는 대략적인 전환 값(low,medium,high)을 포함하거나 해당 필드가 생략됩니다. - 인덱스
1(윈도우 2: 3~7일차): 포스트백 데이터 티어 1~3의 경우 제공되는 경우 대략적인 전환 값(low,medium,high)을 공개할 수 있으며, 티어 0은 2차 또는 3차 포스트백 대상이 아닙니다. - 인덱스
2(윈도우 3: 8~35일차): 포스트백 데이터 티어 1~3의 경우 제공되는 경우 대략적인 전환 값(low,medium,high)을 공개할 수 있으며, 티어 0은 2차 또는 3차 포스트백 대상이 아닙니다.
세부 전환 값과 대략적인 전환 값 관리
수집 디코더는 페이로드 가변성을 고려해야 합니다.
- 상호 배타성: Apple은 설치 검증 포스트백이
conversion-value또는coarse-conversion-value중 하나를 포함할 수 있지만 두 가지를 동시에 포함할 수는 없음을 명시합니다. - 전환 값 생략: 할당된 포스트백 데이터 티어가 낮음(티어 0)인 경우, JSON 페이로드에서 전환 값 필드가 생략됩니다.
재생 공격 및 스푸핑된 전환 페이로드 방어
중복 제거 키로서의 transaction-id 역할
모든 SKAdNetwork 포스트백에는 고유한 transaction-id UUID가 포함되어 있습니다. Apple 문서는 수신자가 이 식별자를 멱등성 키로 사용하여 중복 전환 포스트백을 감지하고 폐기할 것을 권장합니다.
포스트백 리스너는 공개적으로 액세스 가능한 HTTPS 엔드포인트이므로, 악의적인 행위자가 유효한 포스트백을 캡처하여 반복적으로 다시 제출함으로써 전환 지표를 인위적으로 부풀리는 재생 공격을 시도할 수 있습니다.
분산 인메모리 캐싱 및 영구 원장 구현
Apple은 보편적인 중복 제거 보존 기간을 지정하지 않습니다. 프로덕션 수신자는 조정 및 재생 방어 요구사항에 따라 검증된 트랜잭션 ID에 대한 지속적인 멱등성 레코드를 유지해야 합니다. Redis TTL은 유일한 권위 있는 중복 원장이 아닌 핫 캐시 최적화로 사용될 수 있습니다.
- 암호화 검증 우선: 트랜잭션 ID를 스토리지에 커밋하기 전에 Apple의 공개 키에 대해 ECDSA 서명을 완전히 검증합니다.
- 원자적 중복 제거: 지속적인 관계형 또는 문서 데이터베이스 고유 제약 조건으로 뒷받침되는 원자적 쓰기 작업(예: Redis
SET key value NX EX <seconds>)을 수행합니다. - 중복 제거 기간: 예상되는 포스트백 전달, 네트워크 재시도(Apple은 실패한 전달을 최대 9일 동안 재시도함), 다운스트림 조정을 포함하는 캐시 레이어의 운영 보존 창을 설정합니다.
아래의 백엔드 구현은 Python에서의 서명 유효성 검사, 스키마 유효성 검사 및 원자적 중복 제거를 보여줍니다.
import base64
import json
import redis
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives.serialization import load_der_public_key
from cryptography.exceptions import InvalidSignature
# Initialize Redis client for hot-cache transaction deduplication
redis_client = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True)
# Official Apple SKAdNetwork 2.1+ Public Key (Base64 DER encoded, published by Apple)
APPLE_SKAN_PUBLIC_KEY_B64 = (
"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWdp8GPcGqmhgzEFj9Z2nSpQVdday"
"aPe4FMzqM9wib1+aHaaIzoHoLN9zW4K8y4SPykE3YVK3sVqW6Af0lfx3gg=="
)
# Exact Apple-specified invisible separator: U+2063 INVISIBLE SEPARATOR (UTF-8: 0xE2 0x81 0xA3)
SEPARATOR = "\u2063"
def construct_skan4_message_bytes(payload: dict) -> bytes:
"""
Constructs the serialized UTF-8 message string for SKAN 4.0 signature verification.
Apple specification explicitly EXCLUDES conversion-value and coarse-conversion-value from the signature.
"""
parts = [
str(payload["version"]),
str(payload["ad-network-id"]),
str(payload["source-identifier"]),
str(payload["app-id"]),
str(payload["transaction-id"]),
"true" if payload["redownload"] is True else "false"
]
# Include source-app-id (app ad) OR source-domain (web ad) if present
if payload.get("source-app-id") is not None:
parts.append(str(payload["source-app-id"]))
elif payload.get("source-domain") is not None:
parts.append(str(payload["source-domain"]))
parts.append(str(payload["fidelity-type"]))
parts.append("true" if payload["did-win"] is True else "false")
parts.append(str(payload["postback-sequence-index"]))
# Join with U+2063 separator and encode to UTF-8
message_string = SEPARATOR.join(parts)
return message_string.encode('utf-8')
def verify_and_ingest_skan4_postback(postback_json_str: str) -> dict:
"""
Validates payload schema, verifies the ECDSA P-256 signature against Apple's public key,
and performs atomic transaction-id deduplication.
"""
try:
payload = json.loads(postback_json_str)
except Exception:
return {"status": "REJECTED", "reason": "INVALID_JSON_FORMAT"}
# Version Gate: Enforce SKAN 4.0 payload handling
if payload.get("version") != "4.0":
return {"status": "REJECTED", "reason": "UNSUPPORTED_SKAN_VERSION"}
# Schema Validation: Required fields for SKAN 4.0
required_fields = [
"version", "ad-network-id", "source-identifier", "app-id",
"transaction-id", "redownload", "fidelity-type", "did-win",
"postback-sequence-index", "attribution-signature"
]
for field in required_fields:
if field not in payload:
return {"status": "REJECTED", "reason": f"MISSING_REQUIRED_FIELD_{field.upper()}"}
# Strict Type Validation
if not isinstance(payload["redownload"], bool):
return {"status": "REJECTED", "reason": "INVALID_TYPE_REDOWNLOAD"}
if not isinstance(payload["did-win"], bool):
return {"status": "REJECTED", "reason": "INVALID_TYPE_DID_WIN"}
if payload["postback-sequence-index"] not in (0, 1, 2):
return {"status": "REJECTED", "reason": "INVALID_SEQUENCE_INDEX"}
if payload["fidelity-type"] not in (0, 1):
return {"status": "REJECTED", "reason": "INVALID_FIDELITY_TYPE"}
# Enforce mutual exclusivity between source-app-id and source-domain
has_source_app = payload.get("source-app-id") is not None
has_source_domain = payload.get("source-domain") is not None
if has_source_app and has_source_domain:
return {"status": "REJECTED", "reason": "CONFLICTING_SOURCE_FIELDS"}
signature_b64 = payload["attribution-signature"]
transaction_id = payload["transaction-id"]
try:
# Step 1: Reconstruct the exact UTF-8 serialized message
message_bytes = construct_skan4_message_bytes(payload)
signature_der = base64.b64decode(signature_b64, validate=True)
# Step 2: Verify ECDSA P-256 / SHA-256 signature using Apple's published public key
apple_public_key = load_der_public_key(base64.b64decode(APPLE_SKAN_PUBLIC_KEY_B64))
apple_public_key.verify(
signature_der,
message_bytes,
ec.ECDSA(hashes.SHA256())
)
except InvalidSignature:
return {"status": "REJECTED", "reason": "INVALID_CRYPTOGRAPHIC_SIGNATURE"}
except Exception as e:
return {"status": "ERROR", "reason": f"VERIFICATION_FAILED: {str(e)}"}
# Step 3: Atomic Deduplication via Redis (Hot cache layer)
# Note: In production, pair this hot cache with a persistent unique database constraint.
# 14-day TTL (1,209,600 seconds) serves as an illustrative receiver cache policy covering retries.
is_new = redis_client.set(f"skan_tx:{transaction_id}", "1", nx=True, ex=1209600)
if not is_new:
return {"status": "DUPLICATE", "reason": "TRANSACTION_ALREADY_PROCESSED"}
return {
"status": "VERIFIED",
"transaction_id": transaction_id,
"sequence_index": payload["postback-sequence-index"],
"did_win": payload["did-win"]
}
실시간 입찰 모델 및 CPA 최적화 도구로 포스트백 수집
에지 수집과 비동기 처리의 분리
볼륨이 큰 DSP는 최고 캠페인 기간 동안 상당한 양의 포스트백을 처리합니다. 동기식 다운스트림 처리는 지연 병목 현상을 유발할 수 있습니다.
엔터프라이즈 아키텍처는 비동기 파이프라인을 구현합니다.
- 에지 수신자: 수신되는 HTTP POST를 수락하고, 서명 진위 여부를 검증하며,
transaction-id에 대해 원자적 중복 제거를 실행하고 즉시 HTTP200 OK를 반환합니다. - 이벤트 큐: 검증된 페이로드를 분산 이벤트 브로커(예: Apache Kafka 또는 AWS SQS)에 게시합니다.
- 입찰 및 분석 워커: 이벤트 스트림을 소비하고, 전환 값을 수익 지표에 매핑하며, RTB(실시간 입찰) 타겟 CPA 모델을 업데이트합니다.
계층형 소스 식별자 활용
첫 번째 승인 포스트백은 포스트백 데이터 티어에 따라 계층형 source-identifier의 2자리, 3자리 또는 4자리를 노출할 수 있습니다. 해당 자릿수의 의미는 광고 네트워크 자체의 소스 식별자 분류 체계에 의해 정의됩니다. 입찰 시스템은 자릿수와 특정 지면 또는 크리에이티브 세부 정보 간의 보편적인 매핑을 가정하는 대신, 네트워크 자체의 캠페인 메타데이터에 대해 수신된 소스 식별자를 확인해야 합니다.
비교 매트릭스: Apple 직접 전달 대 MMP S2S 수집
| 기능적 차원 | Apple 직접 전달(광고 네트워크) | 개발자 엔드포인트(NSAdvertising...) |
MMP S2S 수집 파이프라인 |
|---|---|---|---|
| 수신자 | 등록된 광고 네트워크 | 광고 대상 앱 개발자 | 모바일 측정 파트너 |
| 어트리뷰션 범위 | 해당 네트워크에 대한 승인 포스트백 | 앱에 대한 승인 포스트백 복사본 | 다중 네트워크 집계 뷰 |
| 서명 유효성 검사 | 광고 네트워크 백엔드에 의해 실행됨 | 개발자 백엔드에 의해 실행됨 | 구현에 따라 다름(파트너 플로우) |
| 비승인 포스트백 | 자격을 갖춘 경우 수신됨(did-win: false) |
개발자 엔드포인트로 전달되지 않음 | 파트너 플로우를 통해 사용 가능할 수 있음 |
| 주요 사용 사례 | 다이렉트 입찰자 및 타겟 CPA 최적화 | 내부 웨어하우스 감사 및 검증 | 크로스 채널 성과 대시보드 |
자주 묻는 질문(FAQ)
Apple의 포스트백 서명을 검증하는 데 어떤 공개 키가 사용되나요?
유효한 SKAdNetwork 포스트백의 서명 검증이 실패하는 이유는 무엇인가요?
광고 대상 앱의 개발자 엔드포인트가 비승인 SKAdNetwork 포스트백을 수신할 수 있나요?
요약 및 결정 프레임워크
대규모로 SKAdNetwork 포스트백을 처리하려면 저지연 에지 수집과 엄격한 암호화 검증 및 트랜잭션 수준의 중복 제거를 결합해야 합니다. Apple 포스트백은 예산 할당과 입찰 알고리즘에 직접적인 영향을 미치므로, ECDSA 서명을 검증하고 transaction-id 멱등성을 강제하면 위조되거나 변조된 포스트백 및 중복 재생 처리로부터 수집 파이프라인을 보호할 수 있습니다.
플랫폼 중개 SKAdNetwork 리포팅을 마이크로 수준의 사용자 온보딩 및 인스턴트 딥 링크 라우팅으로 보완하기 위해, 엔지니어링 팀은 플랫폼 API와 함께 퍼스트파티 라우팅 아키텍처를 배포합니다.
서버 측 어트리뷰션 포스트백 및 딥 링크 파이프라인 구성에 대한 자세한 내용은 OpoInstall 문서를 참조하십시오.
관련 자료
-
개념: S2S 포스트백, 암호화 검증, ECDSA P-256, 재생 공격 방어, 트랜잭션 중복 제거
-
기술: Apple SKAdNetwork, Apple AdAttributionKit, Redis 인메모리 캐시, OpoInstall 모바일 SDK
-
표준: IETF RFC 8259(JSON 데이터 교환), RFC 5480(타원 곡선 암호화)
-
API: StoreKit SKAdNetwork API, Apple S2S 포스트백 전달 사양, OpoInstall S2S API
공식 문서
Share this article
