인터랙션 및 분석

수신자가 투표에 참여하거나, 폼을 제출하거나, 평점을 매기면 그 인터랙션은 MailInApp의 호스팅된 엔드포인트에 의해 실시간으로 기록되고 여러분의 프로젝트에 귀속됩니다.

인터랙션이 전달되는 방식

인터랙티브 블록은 폴백 철학에 맞춰 두 가지 방식으로 기록 엔드포인트에 도달합니다:

링크(범용). 투표나 평점의 모든 선택지는 일반 링크입니다. 탭하면 동작을 확인하고 기록하는 가벼운 호스팅 페이지가 열립니다. 이 방식은 모든 이메일 클라이언트의 100%에서 동작합니다.
이메일 내 폼 제출(개선). 이를 지원하는 클라이언트(Gmail 웹/Android, Yahoo)에서는 폼과 투표가 표준 HTML 폼 인코딩을 사용해 이메일에서 바로 제출될 수 있습니다 — 페이지 이동이 없습니다. 제출 후 수신자는 여러분이 선택한 페이지로 리디렉션됩니다.

두 경로 모두 동일한 데이터를 받아들이므로, 수신자가 어떤 클라이언트를 사용했는지와 무관하게 결과는 한곳으로 모입니다.

상품 블록의 지금 구매 클릭은 유일한 예외입니다: 구매는 오직 Stripe 자체의 호스팅된 체크아웃 페이지에서만 완료될 수 있으므로 이 엔드포인트를 통해서는 전혀 기록되지 않습니다. 그래도 금액, 통화, 수량과 함께 purchase 이벤트로 여기에 남지만, 이는 구매자의 클릭만으로는 절대 발생하지 않고 오직 Stripe의 웹훅이 결제가 실제로 완료되었음을 확인한 뒤에만 발생합니다.

봇과 스캐너로부터 보호

기업 보안 도구는 검사하는 모든 이메일의 모든 링크를 미리 가져옵니다(prefetch). 단순 링크 클릭만으로 투표가 기록된다면, 여러분의 투표 결과는 로봇으로 가득 찰 것입니다. MailInApp은 단순 GET에서는 아무것도 기록하지 않습니다: 링크 기반 동작은 수신자의 명시적인 확인 동작을 요구하며, 라이브 뷰 인터랙션은 폼 제출을 통해 기록됩니다. 라이브 뷰 링크를 참고하세요.

엔드포인트는 필연적으로 공개되어 있으므로(받은편지함은 인증할 수 없습니다), 모든 페이로드는 서버 측에서 검증되며, 개인화된 제출은 라이브 뷰 링크를 보호하는 것과 동일한 서명된 토큰을 통해 귀속됩니다 — 위조되었거나 일치하지 않는 토큰은 거부됩니다.

결과의 신뢰성을 지키는 두 가지 계층이 더 있습니다:

수신자별 중복 방지. 한 수신자의 투표, 평점, 공개, 또는 폼 제출은 한 번만 카운트됩니다 — 자신의 링크를 다시 클릭해도(성급한 더블 탭, 재시도된 페이지 로드) 두 번째 행이 생기는 것이 아니라 아무 일도 일어나지 않습니다. 반복되는 캐러셀 슬라이드 조회는 의도적으로 중복 제거되지 않습니다 — 여기서 반복은 중복 집계가 아니라 의미 있는 참여 신호이기 때문입니다.
익명 폭주 제한. 캠페인의 campaignId는 이메일 자체의 HTML 소스에 그대로 노출되어 있으므로, 수신자 토큰 없이도 스크립트가 임의의 투표를 게시하는 것을 막을 방법은 없습니다. 귀속되지 않은 제출은 IP 주소당, 캠페인당, 분당으로 상한이 설정됩니다. 이는 정확한 신원 확인이 아니라 최선의 방어망입니다 — 공유된 기업이나 웹메일 네트워크는 여러 실제 수신자를 하나의 IP 뒤에 둘 수 있으므로, 정상적인 열람 폭주를 막지 않을 만큼 상한은 넉넉하게 유지됩니다.

기록되는 내용

각 인터랙션 이벤트는 다음을 담습니다:

소속된 프로젝트(캠페인),
이를 발생시킨 블록(어떤 투표, 어떤 폼),
값(선택한 옵션, 제출된 필드, 별점 개수),
이메일이 데이터 소스로 개인화되었을 때의 수신자 행 — 그저 몇 명인지가 아니라 누가 응답했는지 볼 수 있습니다,
타임스탬프.

설문조사 생명주기

프로젝트에는 마감일 및/또는 응답 상한을 설정할 수 있습니다(발송 설정과 함께 설정합니다). 둘 중 하나에 도달하면 기록 엔드포인트는 해당 프로젝트에 대한 새 이벤트 수락을 멈추고 — 라이브 뷰는 오류 대신 인터랙티브 블록을 마감 안내로 대체합니다 — 마감 전에 수집된 모든 것은 기록된 그대로 유지됩니다. 응답 및 웹훅을 참고하세요.

클릭 추적

일반 링크(버튼, 링크가 걸린 이미지, 소셜 아이콘)는 투표나 평점은 아니지만 여전히 알아둘 가치가 있습니다. 개인화된 수신자 링크로 이메일이 발송된 경우, MailInApp은 이런 일반 클릭을 실제 목적지로 가는 도중 추적되는 리디렉션을 거치도록 라우팅합니다. 클릭이 기록된 다음 수신자는 추가 단계나 지연 없이 여러분이 설정한 URL에 도착합니다. 수신자 맥락이 없는 이메일(예: 트랜잭션 API를 통한 프리폼 발송)은 대신 목적지로 바로 링크됩니다 — 클릭을 귀속시킬 대상이 없기 때문입니다.

투표나 평점과 달리 클릭은 절대 중복 제거되지 않습니다 — 수신자가 같은 버튼을 다섯 번 클릭하면 다섯 번의 클릭으로 집계됩니다. 여기서 반복 클릭은 중복 집계가 아니라 의미 있는 참여 신호이기 때문입니다. 결과는 블록별 클릭 히트맵으로 집계됩니다 — 응답 및 웹훅을 참고하세요.

스크롤 깊이

호스팅된 라이브 뷰 페이지는 수신자가 읽으면서 얼마나 스크롤했는지(페이지의 25%, 50%, 75%, 100%)도 보고합니다. 이는 MailInApp에서 작은 스크립트가 실행되는 유일한 곳입니다. 발송된 이메일 자체는 반드시 그래야 하듯 100% 스크립트 없는 상태를 유지하지만, 라이브 뷰는 이미 일반적인 호스팅된 웹페이지이므로 그곳의 스크롤 리스너는 아무것도 훼손하지 않습니다. 마일스톤은 스크롤 깊이 퍼널로 집계됩니다. 응답 및 웹훅을 참고하세요.

열람 추적

대시보드에서 발송된 모든 이메일에는 작고 보이지 않는 열람 추적 픽셀도 포함되어 있어, "열었지만 참여하지 않음"과 "한 번도 열지 않음"을 명시적인 인터랙션과 함께 구분할 신호를 얻을 수 있습니다. 이는 응답 화면에서 인터랙션 목록에 섞이지 않고 수신자별로 구분된 열람됨 표시(첫 열람 타임스탬프)로 보여집니다.

이는 최선의 최소 측정치일 뿐 정확한 측정이 아닙니다: Apple Mail의 개인정보 보호 기능과 Gmail의 이미지 프록시 모두 수신자가 실제로 메시지를 열었는지와 무관하게 이미지를 미리 가져오거나 캐시하므로, 열람 수는 과소 집계되거나 잘못 양성으로 집계될 수 있습니다. 이를 절대적인 사실이 아니라 방향성 신호로 받아들이세요.

결과가 저장되는 곳

인터랙션 데이터는 프로젝트별로 수집되어 세 가지 방식으로 여러분에게 전달됩니다:

수신자별 응답 — 대시보드의 응답 화면은 모든 인터랙션을 수신자별로 그룹화하고 데이터 소스와 연결해, 몇 명이 아니라 누가 응답했는지 볼 수 있게 합니다. 응답 및 웹훅을 참고하세요.
웹훅 — 각 인터랙션은 도착하는 즉시 여러분 자신의 엔드포인트로 전송될 수 있으며, MailInApp에서 온 것임을 확인할 수 있도록 서명됩니다. 이 역시 응답 및 웹훅에서 다룹니다.
수신자를 위한 실시간 결과 — 투표 블록은 호스팅된 결과 페이지에서 수신자에게 실시간 결과를 보여줄 수 있습니다.

개인정보 참고: MailInApp은 수신자가 의도적으로 하는 인터랙션 — 투표, 제출, 평점 — 과 위에서 설명한 열람 추적 픽셀만 기록합니다. 이 엔드포인트들은 단순 링크 요청에 대한 그 밖의 부수적인 추적은 전혀 로그로 남기지 않도록 설계되었습니다.