광고 데이터 파이프라인의 이해

이 글은 일반적으로 광고플랫폼에서 데이터를 처리하는 과정과 분석·리포팅용 데이터 처리를 중심으로 전체 흐름을 살펴봅니다..

광고플랫폼은 광고를 매체에 송출하여 노출과 클릭, 전환 같은 데이터를 수집하고 처리합니다. 이런 기록이 곧바로 보고서의 성과 지표가 되는 것은 아닙니다. 오류와 중복을 확인하고, 서로 다른 형식을 맞추고, 캠페인과 매체 정보를 연결한 뒤 집계하는 과정이 필요합니다.

예를 들어 대시보드에 표시된 ‘캠페인별 광고비와 구매 실적’도 여러 처리 단계를 거친 결과입니다. 광고비는 매체 API에서, 구매 기록은 웹사이트나 앱에서 들어올 수 있습니다. 이 데이터를 어느 날짜와 캠페인에 연결할지, 중복된 구매 신호는 어떻게 처리할지, 어떤 구매를 광고 성과로 인정할지 정해야 합니다.

이처럼 데이터가 수집부터 저장·가공·활용까지 이동하는 처리 구조를 데이터 파이프라인(Data Pipeline)이라고 합니다.

광고플랫폼의 실제 구조는 플랫폼의 역할과 규모에 따라 다르며, 모든 플랫폼이 아래의 데이터를 수집하거나 각 단계를 별도 시스템으로 운영하는 것은 아닙니다.

광고 데이터 처리의 개념 구조입니다. 실제 플랫폼에서는 일부 단계가 통합되거나 병렬로 실행되며, 목적에 따라 배치 처리와 스트리밍 처리를 함께 사용합니다.

1. 측정 설계: 무엇을 어떤 기준으로 기록할까

데이터 처리는 수집 코드를 붙이기 전에 시작됩니다. 먼저 무엇을 기록하고, 각 기록에 어떤 정보를 담을지 정해야 합니다.

구매를 측정한다면 주문 생성 시점에 기록할지, 결제 완료 시점에 기록할지 정합니다. 구매 금액에 배송비를 포함할지, 취소와 환불은 어떻게 반영할지도 확인해야 합니다. 기준이 명확하지 않으면 같은 ‘구매’라는 이름 아래 서로 다른 기록이 쌓일 수 있습니다.

이때 기록할 대상이 되는 행동이나 발생 사실을 이벤트(Event)라고 합니다. 광고 노출, 클릭, 상품 조회, 구매 완료 등이 이벤트에 해당합니다.

이벤트에 담을 항목과 형식을 정의한 것이 스키마(Schema)입니다. 예를 들어 구매 이벤트에는 이벤트 식별자, 주문번호, 발생 시각, 금액, 통화 등을 담도록 정할 수 있습니다. 금액을 숫자로 받을지 문자열로 받을지, 필수 항목이 빠지면 어떻게 처리할지도 스키마의 일부입니다.

캠페인과 소재를 일관되게 분류하는 기준도 필요합니다. 이를 택소노미(Taxonomy)라고 합니다. 캠페인 목적, 상품군, 매체, 소재 유형 등을 어떤 규칙으로 구분할지 정하는 체계입니다.

측정 설계가 잘돼 있어야 이후 데이터를 연결하고 비교하는 과정에서 불필요한 해석과 수정이 줄어듭니다.

2. 데이터 수집: 필요한 기록을 가져오기

수집 단계에서는 각 시스템에서 발생하거나 집계된 데이터를 가져옵니다.

플랫폼이 직접 처리하는 광고 노출·클릭 로그가 있을 수 있고, 외부 매체가 제공하는 광고비와 성과 보고서가 있을 수도 있습니다. 웹사이트나 앱에서는 행동·전환 이벤트가 들어오고, 연동 범위에 따라 주문 시스템이나 CRM(Customer Relationship Management)의 고객·거래 데이터를 활용하기도 합니다.

데이터를 가져오는 방식은 출처에 따라 달라집니다.

• API(Application Programming Interface)는 시스템끼리 정해진 방식으로 데이터를 요청하고 주고받는 인터페이스입니다. 매체의 비용·성과 보고서를 자동으로 가져올 때 사용할 수 있습니다.
• 태그(Tag)는 웹페이지에 설치하는 코드로, 페이지 조회나 구매 같은 이벤트의 수집·전송에 사용됩니다.
• SDK(Software Development Kit)는 앱 등에 기능을 구현할 수 있도록 제공되는 개발 도구 모음입니다. 광고·분석 SDK는 이벤트 수집과 전송 기능 등을 제공합니다.
• 서버 간 전송은 브라우저나 앱을 거치지 않고 시스템 간에 데이터를 전달하는 방식입니다. 주문 서버에서 결제 완료 이벤트를 보내는 경우가 한 예입니다.

수집·처리 주기도 목적에 맞춰 정합니다. 일정 시간 동안 쌓인 데이터를 묶어서 처리하는 방식은 배치(Batch), 들어오는 데이터를 지속적으로 처리하는 방식은 스트리밍(Streaming)이라고 합니다.

일별 보고서는 배치로 충분할 수 있지만, 빠른 이상 감지에는 스트리밍 처리가 유용할 수 있습니다. 모든 데이터를 실시간으로 처리하는 것이 항상 필요한 것은 아닙니다.

또한 수집할 수 있다는 이유만으로 모든 데이터를 가져오지는 않습니다. 목적에 필요한 항목인지, 적법하게 처리할 수 있는지, 접근 권한과 플랫폼 정책에 부합하는지를 함께 확인해야 합니다.

3. 원본 저장: 다시 처리할 수 있는 근거 남기기

수집한 데이터는 바로 보고서용 숫자로 바꾸기보다, 보관이 허용되는 범위에서 수집 당시의 형태를 남겨두는 것이 유용합니다.

이렇게 원래의 구조와 값을 최대한 유지한 데이터를 원본 데이터(Raw Data)라고 합니다. 언제, 어느 시스템에서 가져온 데이터인지도 함께 기록하면 문제를 추적하기 쉬워집니다.

예를 들어 광고비를 잘못된 통화 기준으로 변환했다면, 원본이 있어야 올바른 기준으로 다시 계산할 수 있습니다. 가공된 합계만 남아 있으면 오류가 어디에서 발생했는지 확인하기 어려워집니다.

이 단계에서 자주 등장하는 용어가 데이터 레이크(Data Lake)와 데이터 웨어하우스(Data Warehouse)입니다.

데이터 레이크는 로그나 파일처럼 다양한 형식의 데이터를 저장하는 데 사용됩니다. 데이터 웨어하우스는 데이터를 분석하고 조회하기에 적합하도록 관리하는 시스템입니다.

두 시스템을 반드시 순서대로 도입해야 하는 것은 아닙니다. 하나의 저장 시스템 안에서 원본 영역과 가공 영역을 나누기도 합니다. 중요한 것은 시스템의 이름보다 원본을 추적하고 필요한 구간을 다시 처리할 수 있는 구조입니다.

원본을 보관한다는 이유로 데이터를 무기한 저장해서는 안 됩니다. 보관 기간, 접근 권한, 삭제 기준도 함께 적용해야 합니다.

4. 정제·표준화: 비교할 수 있는 형태 만들기

수집한 데이터에는 형식이 맞지 않는 값, 중복된 기록, 누락된 항목 등이 포함될 수 있습니다. 이를 점검하고 사용 목적에 맞게 정리하는 과정이 정제와 표준화입니다.

광고 데이터에서는 다음과 같은 작업이 자주 필요합니다.

• 날짜와 시간대를 공통 기준으로 변환합니다.
• 금액과 통화의 형식을 맞춥니다.
• 필수 식별자가 없는 기록을 구분합니다.
• 반복 수신된 이벤트가 중복 집계되지 않도록 처리합니다.
• 매체별로 다른 컬럼 이름을 공통 구조에 매핑합니다.

같은 기록이 여러 번 들어왔을 때 중복 집계를 방지하는 작업을 중복 제거(Deduplication)라고 합니다. 이벤트 식별자나 주문번호 등을 활용할 수 있지만, 어떤 값의 조합으로 중복을 판단할지는 데이터의 의미에 따라 달라집니다.

처리 순서를 설명할 때는 ETL과 ELT라는 용어를 사용합니다.

ETL은 데이터를 추출하고(Extract), 변환한 뒤(Transform), 대상 시스템에 적재하는(Load) 방식입니다. ELT는 먼저 추출·적재하고, 저장 시스템 안에서 변환하는 방식입니다. 어느 한쪽이 항상 우수한 것은 아니며 처리 규모와 시스템 구조에 따라 선택합니다.

여기서 주의할 점은 형식을 맞추는 것과 의미를 맞추는 것은 다른 작업이라는 것입니다.

두 매체의 컬럼 이름을 모두 ‘전환 수’로 바꾸더라도, 한쪽이 구매를 세고 다른 쪽이 회원가입을 센다면 같은 지표로 비교할 수 없습니다. 기준이 다른 항목은 차이를 남겨두고 구분해서 활용해야 합니다.

5. 연결·모델링: 분석할 수 있는 관계 만들기

정리한 데이터는 캠페인, 매체, 소재 등의 정보와 연결합니다. 필요한 데이터끼리 어떤 관계를 갖게 할지 설계하는 작업을 데이터 모델링(Data Modeling)이라고 합니다.

공통 식별값을 기준으로 여러 데이터 테이블을 연결하는 작업은 조인(Join)입니다. 성과 테이블의 캠페인 ID와 캠페인 정보 테이블의 ID를 연결하면, 성과 수치에 캠페인 목적이나 상품군 정보를 붙일 수 있습니다.

이때 반드시 확인해야 하는 것이 그레인(Grain)입니다. 데이터 한 행이 무엇을 나타내는지, 즉 기록의 단위를 뜻합니다.

예를 들어 다음 데이터는 단위가 서로 다릅니다.

• 날짜·캠페인별 광고비
• 날짜·캠페인·소재별 클릭 수
• 주문 한 건에 대한 구매 기록

캠페인별 광고비를 여러 소재 행에 그대로 연결한 뒤 합산하면, 같은 광고비가 반복해서 더해질 수 있습니다. 데이터가 연결됐다는 사실만으로 올바르게 계산할 수 있는 것은 아닙니다. 분석할 단위에 맞춰 먼저 집계하거나, 연결 관계를 다르게 설계해야 합니다.

모델링에서는 팩트(Fact)와 디멘션(Dimension)이라는 구분도 자주 사용합니다. 팩트는 광고비·클릭 수 같은 측정값이나 거래 사실을 담고, 디멘션은 매체·캠페인·소재처럼 분석 기준이 되는 속성을 담습니다.

또한 캠페인 단위의 연결과 사용자 단위의 연결은 구분해야 합니다. 매체가 제공하는 집계 보고서만으로 개별 사용자의 광고 접점과 구매 경로를 복원할 수는 없습니다.

6. 성과 집계·검증: 어떤 숫자를 보여줄지 정하기

데이터를 연결한 뒤에는 보고서에서 사용할 지표를 계산합니다. 광고비와 클릭 수를 합산하고, 구매당 비용이나 광고비 대비 매출을 계산하는 과정입니다.

이때 실제 구매가 발생했다는 사실과 그 구매를 특정 광고의 성과로 인정하는 것은 구분해야 합니다.

전환 성과를 어떤 광고 접점에 배분할지 정하는 방식을 어트리뷰션(Attribution)이라고 합니다. 전환 이전의 광고 접점을 어디까지 거슬러 살펴볼지 정하는 기간은 룩백 윈도우(Lookback Window)라고 합니다.

같은 구매라도 적용한 어트리뷰션 방식과 기간이 다르면 캠페인별 성과가 달라질 수 있습니다. 매체마다 같은 구매를 각각 자신의 광고 성과로 집계할 수도 있습니다. 따라서 여러 매체의 전환 수를 합산한 값이 실제 구매 건수와 같다고 볼 수는 없습니다.

매체의 집계 결과를 가져와 보여주는 것과 플랫폼이 자체 기준으로 성과를 다시 계산하는 것도 다른 작업입니다. 보고서에는 어느 기준의 수치인지 드러나야 합니다.

서로 다른 시스템의 수치를 비교하고 차이를 확인하는 작업은 대사(Reconciliation)라고 합니다. 수집 누락뿐 아니라 시간대, 전환 인정 기준, 반영 지연, 취소·환불 처리 등도 차이의 원인이 될 수 있습니다.

검증의 목적은 모든 숫자를 억지로 일치시키는 것이 아닙니다. 차이가 생기는 이유를 설명하고, 오류인지 정상적인 기준 차이인지 구분하는 것입니다.

7. 제공·활용: 필요한 형태로 데이터 전달하기

검증한 데이터를 사용 목적에 맞게 정리해 대시보드, 보고서, 분석 도구 등에 제공합니다.

특정 업무나 분석 목적에 맞춰 구성한 데이터 묶음을 데이터 마트(Data Mart)라고 합니다. 캠페인 성과 보고용 데이터 마트라면 날짜, 광고주, 캠페인, 비용, 전환, 매출 등을 반복 조회하기 쉬운 형태로 구성할 수 있습니다.

이 데이터를 조회하고 시각화해 업무 판단을 돕는 도구와 활동을 BI(Business Intelligence)라고 합니다. 실무자가 보는 대시보드는 그 활용 형태 중 하나입니다.

데이터는 보고서 외에도 운영 알림이나 캠페인 운영 시스템과 연결될 수 있습니다. 분석 결과나 조건에 맞는 데이터를 실제 마케팅 실행에 활용하는 과정은 액티베이션(Activation)이라고 부릅니다.

다만 집계 보고서에 사용할 수 있는 데이터라고 해서 개인별 타기팅에도 그대로 사용할 수 있는 것은 아닙니다. 목적에 맞는 처리 근거와 권한, 식별 가능성, 플랫폼 정책을 별도로 확인해야 합니다.

활용하는 사람이 데이터의 한계를 알 수 있도록 마지막 갱신 시각과 집계 기준도 함께 제공하는 것이 좋습니다. 수치가 아직 잠정적인지, 지연된 이벤트가 추가 반영될 수 있는지 알아야 잘못된 판단을 줄일 수 있습니다.

파이프라인은 운영 중에도 계속 관리해야 합니다

데이터가 한 번 정상적으로 들어왔다고 파이프라인이 완성되는 것은 아닙니다. 매체 API가 바뀌거나 접근 권한이 만료될 수 있고, 특정 구간의 데이터가 늦게 도착할 수도 있습니다.

작업 간 실행 순서와 의존 관계, 실패 시 재시도 등을 관리하는 것을 오케스트레이션(Orchestration)이라고 합니다. 수집이 끝나야 집계를 시작하고, 필요한 데이터가 준비되지 않았다면 보고서 갱신을 보류하는 식입니다.

데이터가 요구되는 시점에 맞춰 들어오는지는 최신성(Freshness)으로 점검합니다. 처리 프로그램이 정상 종료됐더라도 데이터가 오래된 상태일 수 있으므로, 실행 성공 여부만으로 판단해서는 안 됩니다.

누락이나 로직 변경 때문에 과거 구간을 다시 채우는 작업은 백필(Backfill)이라고 합니다. 필요한 데이터를 다시 수집하거나 원본부터 재처리할 수 있습니다. 재실행 과정에서 같은 기록이 반복 집계되지 않도록 설계하는 것도 중요합니다.

광고플랫폼의 데이터 처리는 결국 기록을 모으는 일, 의미를 맞추는 일, 믿고 사용할 수 있도록 검증하는 일이 연결된 과정입니다.

대시보드의 숫자를 이해하려면 계산식뿐 아니라 그 숫자가 어떤 경로와 기준을 거쳐 만들어졌는지도 알아야 합니다. 데이터 파이프라인은 그 과정을 설명하고 관리하기 위한 구조입니다.