표준 이벤트는 사용자 여정 단계별로 이름과 발화 시점이 이미 정의돼 있어 임의로 바꾸면 안 된다
PageView는 페이지 로드 시, ViewContent는 상품 상세 렌더링 시 발화하는 것이 원칙이다
AddToCart는 서버 응답(재고 확인) 이후, InitiateCheckout은 결제 페이지 진입 시 발화해야 한다
Purchase는 결제 승인이 서버에서 확정된 뒤에만 발화해야 중복·허위 전환을 막을 수 있다
표준 이벤트는 왜 이름을 임의로 바꾸면 안 되나
구글·메타가 정의한 표준 이벤트(PageView, ViewContent, AddToCart, InitiateCheckout, Purchase 등)는 각 플랫폼의 자동 최적화·리포팅 로직이 이 이름과 파라미터 구조를 전제로 동작합니다. 임의로 이벤트명을 바꾸거나 커스텀 이벤트로 대체하면 플랫폼의 스마트 입찰·전환 최적화 알고리즘이 해당 신호를 표준 전환으로 인식하지 못해, 캠페인 최적화 자체가 제대로 작동하지 않게 됩니다. 커스텀 이벤트가 필요한 경우는 8강에서 다루는 별도 행동 지표에 한정해야 합니다.
PageView는 어느 시점에 발화해야 하나
PageView는 사용자가 웹페이지를 로드하는 시점에 발화하는 것이 원칙입니다. 대부분의 픽셀 기본 코드가 페이지 상단(head 영역)에 삽입돼 페이지 로드와 동시에 자동으로 발화하도록 설계돼 있어, 이 이벤트 자체는 추가 엔지니어링이 거의 필요 없습니다. 다만 싱글페이지앱(SPA) 구조의 사이트라면 페이지 전체가 다시 로드되지 않고 화면만 바뀌는 경우가 많아, 라우팅이 바뀔 때마다 PageView를 수동으로 재발화하는 로직을 별도로 넣어야 합니다.
ViewContent는 무엇을 기준으로 발화 시점을 정해야 하나
ViewContent는 사용자가 특정 상품·콘텐츠의 상세 페이지를 실제로 렌더링한 시점에 발화해야 합니다. 목록 페이지에서 상품 카드가 화면에 노출된 것만으로 발화시키면 실제 관심도보다 훨씬 부풀려진 신호가 매체에 전달돼, 이 신호를 학습한 유사 타겟팅·리마케팅 오디언스의 품질이 떨어집니다. 상세 페이지 진입 후 상품 정보(가격, ID, 카테고리)가 화면에 표시된 직후를 발화 시점으로 잡는 것이 안전합니다.
AddToCart와 InitiateCheckout은 어디서 흔히 어긋나나
AddToCart는 사용자가 버튼을 클릭한 순간이 아니라, 서버가 실제로 장바구니 담기 요청을 처리하고 재고 확인까지 마친 응답을 반환한 이후에 발화하는 것이 정확합니다. 버튼 클릭 즉시 발화시키면 품절·오류로 실제 담기가 실패한 경우까지 전환 신호로 잡혀 매체 최적화가 왜곡됩니다. InitiateCheckout은 결제 정보 입력 페이지에 실제로 진입한 시점에 발화해야 하며, 장바구니 페이지에서 결제 버튼을 누른 시점이 아니라 결제 페이지가 렌더링을 마친 시점으로 정의하는 것이 표준적인 관행입니다.
Purchase는 왜 가장 신중하게 다뤄야 하나
Purchase는 표준 이벤트 중 매체의 입찰·예산 배분에 가장 큰 영향을 미치는 이벤트이므로, 결제 승인이 서버에서 최종 확정된 뒤에만 발화해야 합니다. 결제 수단 선택 페이지나 결제 진행 중 화면에서 미리 발화시키면 실제로는 결제가 실패하거나 취소된 주문까지 매출로 잡혀, 캠페인 성과가 실제보다 부풀려진 채로 보고됩니다. 이 왜곡은 매체의 자동 입찰 알고리즘이 허위 전환 패턴을 학습해 엉뚱한 사용자층에 예산을 쏟게 만드는 결과로 이어질 수 있습니다.
발화 시점을 검증하는 실무 절차는 어떻게 짜야 하나
표준 이벤트를 설계한 뒤에는 실제 사용자 흐름을 단계별로 재현하며 각 이벤트가 정확한 시점에, 정확히 한 번만 발화하는지 확인해야 합니다. 이 검증에 쓰이는 도구(픽셀 헬퍼 등)와 흔한 실패 패턴은 6강에서 이어서 다루며, 결제 완료 시점의 정의는 2강에서 다룬 포스트백 발송 시점과도 동일하게 맞춰야 두 데이터가 서로 어긋나지 않습니다.
여러 표준 이벤트가 한 페이지에서 동시에 발화될 때 주의할 점
결제 완료 페이지처럼 한 화면에서 Purchase와 함께 부가 이벤트(예: 회원가입 완료)가 같이 발화해야 하는 경우, 두 이벤트의 파라미터를 서로 혼동해 담지 않도록 각 이벤트 호출 코드를 명확히 분리해야 합니다. 특히 새로고침이나 뒤로가기로 결제 완료 페이지에 재진입했을 때 Purchase가 다시 발화하는 사고가 흔한데, 이는 다음 강의에서 다루는 중복 집계 문제의 대표적 원인이므로 페이지 진입마다 무조건 발화시키는 대신 주문번호 기준으로 한 번만 발화하도록 막는 로직이 함께 필요합니다.
이벤트 설계 문서를 미리 만들어야 하는 이유
어떤 이벤트를 어느 페이지, 어느 사용자 행동 시점에 발화시킬지는 마케터의 머릿속에만 있으면 안 되고, 개발팀이 그대로 구현할 수 있는 문서로 정리돼 있어야 합니다. 이벤트명, 발화 조건, 전달할 파라미터를 표로 정리해두면 신규 페이지가 추가되거나 개발자가 바뀌어도 기존 설계를 그대로 이어받을 수 있습니다. 이 문서화 방식은 10강에서 다루는 데이터 레이어 스펙 작성과 같은 원리를 공유하며, 매체가 픽셀 사양을 업데이트할 때마다(예: 파라미터 필수값 추가) 이 문서를 함께 갱신해두면 11강에서 다룰 정기 점검 작업의 기준 자료로도 그대로 재사용할 수 있습니다.
다음 행동
자사 사이트의 AddToCart·Purchase 이벤트가 실제로 서버 확정 이후에 발화하고 있는지, 개발팀과 함께 코드 삽입 위치를 직접 확인해보세요. 다음 편(4강)에서는 이런 설계에도 불구하고 데이터가 유실되거나 중복 집계되는 서버 응답 오류를 진단하는 법을 다룹니다.
← 이전 글 · 레슨 02 포스트백(Postback/S2S) 통신의 핵심 원리: 자사 쇼핑몰 서버와 애드네트워크 서버 간 전환 데이터를 주고받는 통신 규약과 파라미터 구조
CHALLENGE
배운 걸 실전 문제로 확인
카테고리별 Level Test로 실무 레벨을 점검해보세요.
