Singular 프러드 방지 이해하기

Singular의 프러드 방지 엔진이 어떻게 작동하는지 배워보시고, 사전에 정의된 보호 메서드와 커스텀 프러드 규칙과의 차이와 프러드 감지 과정을 위한 단계들에 대해 배워보세요.  

프러드 분석과 리포트에 대해 배우시려면, 프러드 리포팅과 프러드 데이터 FAQ를 참고하세요.

 

Singular의 프러드 방지 엔진은 어트리뷰션 프러드를 방지하기 위해 틀에 박히지 않은 감지 메서드와 유저가 정의한 커스텀 규칙들을 사용하여 광고주의 마케팅을 적극적으로 보호합니다.  

프러드 방지 엔진은 어트리뷰션을 최종화하기 전이나 파트너에게 리포팅하기 전의 인스톨을 평가하여 CPI/CPA 캠페인에 대해 과도하게 요금이 부과되는 것을 방지합니다.

프러드 방지 메서드

Singular는 어트리뷰션 프러드를 감지하여 가장 유용하며 실행 가능한 프러드 방지 메서드를 구현하기 위해 시장에서 광범위한 조사를 했습니다. 이 방법은 Singular 광고주로부터 얻은 집합적인 정보를 기반으로 세밀하게 조정하여 거짓 양성반응(false positives)을 최소화하는 결과를 도출합니다. 

광고주는 각 메서드 별로 활성화하거나 비활성화 할 수 있습니다. 메서드를 활성화할 때, 광고주는 메서드를 발생시킨 터치 포인트를 거부(rejected)하거나 (어트리뷰션에 부적합하다고 표시하거나) 추후의 후속 조치를 위해 의심스럽다(suspicious)고 표시할 수 있습니다. 

 프러드 방지 메서드를 활성화하기 위한 더 많은 방법을 알고 싶으시면, 프러드 설정 세팅하기를 참고하세요.

거짓 인스톨 방지 메서드

다른 종류의 어트리뷰션 프러드는 합법적인 앱 인스톨의 신용을 훔쳐 오는 것을 기반하는 반면, 인스톨 프러드는 인스톨을 어트리뷰트 하기 위한 목적으로 거짓된 인스톨 생성과 거짓된 유저에 기반합니다.  

COLLAPSE ALL
신규: Android 인스톨 확인

Android의 인스톨 프러드를 공략하기 위해, Singular는 Android 인스톨 확인(Android Install Validation)을 개발하였고, 이는 인스톨을 평가하여 합법적인지 확인하는 저희 고유의 결정론적인(deterministic) 방법입니다. Android 인스톨 확인은 이전에 개발되었던 어떠한 도구들보다 높은 정확성으로 모든 형식의 거짓 인스톨 공격을 감지하고 방지합니다.   

  더 많은 정보를 원하시면 고급 Android 프러드 보호를 참고하세요.

iOS 인스톨 영수증 확인

애플은 iTunes를 통해 iOS 디바이스에 각 인스톨 된 앱의 영수증을 제공합니다. 영수증은 앱이 실존 유저의 실존 디바이스에서 일어난 것인지 확인하는 데 쓰입니다. 영수증 확인은 다음과 같은 절차들로 이루어져 있습니다. 

  1. 영수증이 존재하는지 확인합니다.
  2. Apple의 디지털 서명 확인을 통해 영수증의 진정성을 확인합니다. 
  3. 영수증의 세부 사항과 현재 인스톨을 매칭하여 확인합니다. (예를 들어, 앱의 longname과 비교) 
  4. 영수증이 다른 인스톨에 사용되지 않았는지 점검합니다. (이 과정을 통하여 사기꾼(fraudsters)들이 같은 영수증을 복수 인스톨/디바이스에 사용할 수 없도록 합니다)

주의: Singular는 iOS 7.0 버전 또는 그 이상의 버전인 디바이스와 앱 내 설치된 Singular SDK 버전이 8.2 또는 그 이상인 디바이스에서만 영수증 확인을 진행합니다.

어트리뷰션 조작 방지 메서드

COLLAPSE ALL
신규: Android 클릭 주입 방지

클릭 주입에서, 사기꾼들이 실존 사용자의 인스톨 어트리뷰션을 강탈하기 위해 앱 인스톨을 감지하여 거짓 클릭 (또는 노출)을 만들어 냅니다. 

클릭 주입을 방지하기 위해서, Singular의 새 감지 메서드는 Google Play Referrer 값과 타임스템프를 사용하여 유저가 Play Store로 이동(directed)되거나 인스톨이 초기화된 일어난 노출과 클릭을 식별합니다.

  더 많은 정보를 원하시면, 고급 Android 프러드 방지를 참고하세요.

신규: Android 오가닉 포칭(Poaching) 방지

오가닉 포칭(Poaching)은, 사기꾼이 앱 인스톨 대한 신용(credit)을 주장하는 것으로 어떠한 소스에도 어트리뷰트 되지 않아야 하는 오가닉에 대한 신용(credit)을 주장하는 것입니다. 

Singular의 새 보호 메서드는 앱 인스톨이 오가닉인지 나타내는 Google Play Store의 시그널(광고 클릭과 무관)을 감지합니다. 이 인스톨과 관련된 어떠한 클릭도 오가닉 포칭 시도로 식별될 수 있습니다. 

  더 많은 정보를 원하시면, 고급 Android 프러드 방지를 참고하세요.

Time-to-Install (TTI) 아웃라이어 감지

“클릭 주입”은 인스톨 감지를 공격하고 거짓된 클릭(fake click)을 만들어내는 것입니다. 이것은 Time-to-Install (TTI) 에 의해 감지될 수 있는데, 이는 클릭과 인스톨 사이의 시간을 말합니다. 클릭이 앱 인스톨 이후 곧바로 발생 되었다면, 이는 비정상적으로 짧은 TTI의 원인이 됩니다. 

Geo-Bleed 감지

Singular는 클릭과 인스톨이 일어난 거리를 감지하는데 인스톨과 클릭이 일어난 시간 동안에 실제 엔드 유저(real end-user)가 여행할 수 없는 거리를 감지합니다. 예를 들어, 엔드 유저(end-user)가 광고를 클릭하고, 2시간 후 10,000km 떨어진 곳에서 인스톨이 일어났다면, 이것은 거짓 인스톨(fradulent installs)일 것입니다.  

하이퍼 인게이지먼트(Hyper-Engagement)

클릭 스패밍 같은 공격과 같은 소스로부터 오는 클릭의 유입의 생성을 뜻합니다. Singular는 의심스러운 활동을 감지하고 같은 소스로부터 오는 클릭들을 거부할 수 있습니다.  

일반 보호 메서드

COLLAPSE ALL
블랙리스트 된 IP

Singular는 의심스러운 범위로 알려진 IP로부터 오는 터치 포인트를 감지하는데, 이는 다음을 포함합니다. 

  • 클라우드 서비스 제공자와 데이터 센터  
  • 프록시(Proxy)와 IP 익명화 서비스  
  • TOR 출구점 (TOR exit points)
  • 하이리스크 IP들: 사기 치거나 인터넷상에서 남용으로 낙인된 IP들 

Singular는 이런 범위의 IP 목록을 주기적으로 업데이트합니다.

유저 지정 규칙

Singular에서 개발된 프러드 보호 메서드에 추가적으로 광고주가 직접 특정 앱에 프러드를 방지하는 커스텀 규칙들을 만들 수 있습니다. 

예를 들어, 문제가 되는 특정 퍼블리셔로부터 오는 클릭과 몇 초 이하의 인스톨 시간(클릭과 인스톨 사이의 시간)을 거부하고 싶은 경우가 해당됩니다. 

  더 자세한 정보를 원하시면, 유저가 정의한 프러드 규칙 설정하기를 참고하세요.

프러드 감지 과정

프러드 감지 과정은 다음과 같은 과정으로 이루어져 있습니다.

1. 모든 터치 포인트 로깅(logging)

터치 포인트는 클릭, 노출 (뷰스루),  자가 기여 네트워크(Facebook, AdWords, Twitter와 같은 매체의) 터치 포인트, Google Play Install 레퍼러 정보와 같은 추가적인 특수 터치 포인트와 같은 엔드 유저 이벤트를 포함합니다. 

2. 인스톨 이벤트 로깅 (logging)

앱이 처음 열릴 때, 인스톨 이벤트가 발동되고 Singular 서버로 전송됩니다. Singular는 인스톨을 로그하고 매칭된 모든 터치 포인트들을 수집합니다. 

3. 어트리뷰션 후보군을 평가

프러드 감지 엔진은 모든 어트리뷰션 후보군의 리스트를 모아 각 어트리뷰션을 모든 프러드 감지 메서드와 커스텀 프러드 규칙을 바탕으로 평가합니다. 

예를 들어, 다음과 같이 인스톨에 관련된 두 터치 포인트가 있을 경우입니다. 

Screen_Shot_2019-11-24_at_11.10.47.png

이 예시에서, 어트리뷰션 후보군은 다음과 같습니다.

  • Network B (for Click 2)
  • Network A (for Click 1)
  • Organic

프러그 감지 엔진은 프러드로 감지된 터치 포인트도 거부(reject)할 수 있습니다. 만약 인스톨 자체가 거짓으로 판정되면 이 엔진은 오가닉 옵션 또한 거부할 수 있습니다. 예를 들어, 만약 인스톨 이벤트가 봇 활동(bot activity) 에 관여된 블랙리스트 된 IP로부터 온다면 엔진은 그 오가닉 인스톨 옵션을 거부할 수 있습니다.   

프러드 세팅에 기반하여, 몇몇 터치 포인트들은 거부되지는 않으나 의심스럽다(suspicious) 표기될 수 있습니다. 이 터치 포인트들은 어트리뷰션에 유효한 후보이나, 추가적인 조사를 위해, 리포트에는 의심스럽다고 표기될 것입니다.

4. 최종 어트리뷰션 결정

Singular의 어트리뷰션 매커니즘은 최선부터 최악 순으로 어트리뷰션 옵션을 점검하여, 해당 인스톨을 프러드 방지 엔진에 의해 거부되지 않은 최선의 옵션으로 어트리뷰트 합니다.  

(오가닉 인스톨인 옵션을 포함하여) 만약 모든 옵션이 프러드로 거부된다면, 해당 인스톨은 신뢰할 수 없다(Untrusted) 고 표기될 것입니다.  

Screen_Shot_2019-11-17_at_13.26.36.png

5. 리포트 업데이트와 포스트 백 전송

거부("Rejected")하기로 결정된 어트리뷰션:

Singular 어트리뷰션 매커니즘에서, 만약 어트리뷰션 결정이 프러드 방지 엔진에 의해 영향 받았다면(만약 최선의 어트리뷰션 후보가 거부되었다면) 다음과 같이 작동합니다.

  1. 거부 리포트(rejection report) 에 거부 사항을 추가합니다. (원문:Adds a rejection to the rejection report)
  2. 거부된 포스트 백을 전송합니다. (만약 거부된 포스트 백이 구현되었다면, 프러드 포스트 백을 참고하세요)

만약 프러드 방지 엔진이 어트리뷰션 결정을 변경하지 않았다면, 프러드 포스트 백이 전송되지 않은 것입니다. 예를 들어, 엔진이 낮은 우선순위로 설정된 클릭을 거부할 수 있습니다. 이것은 거부 리포트(rejection reports)와 프러드 포스트 백을 위한 거절로서 카운트되지 않습니다. 

"의심스러움"으로 결정된 어트리뷰션:

프러드 방지 엔진에 의해 "의심스럽다" 표기된 터치 포인트들도 어트리뷰션에 유효한 후보입니다. 만약 Singular 어트리뷰션 매커니즘이 그러한 터치 포인트를 최종 어트리뷰션으로 결정한다면, 이는 다음 사항들을 수반합니다.   

  1. 의심스러움 리포트에 의심스러움 인스톨로 표기합니다.
  2. 광고주 내부 BI에 전송된 인스톨 포스트 백에 파라미터를 추가합니다. (만약 이러한 포스트 백이 구현되었다면, 프러드 포스트 백을 참고하세요). 해당 파라미터는 의심스럽다고 결정한 이유를 포함합니다. 

또한 신뢰할 수 없는 인스톨은 의심스럽다(suspicious)고 표시되며 또한 의심되는 리포트(suspicious report) 에 나타날 것입니다. 

예시

프러드 평가 결과에 의해 영향을 받은 몇몇 간단한 어트리뷰션 결정에 대한 상황들을 예로 들겠습니다. 

COLLAPSE ALL
예시 1: 거절된 클릭(Rejected Click)

image1.png

  1. 프러드 감지 과정:이 예시는, 프러드 방지 엔진이 모든 터치 포인트들을 점검했고 클릭 2를 프러드로 거절하기로 한 경우입니다. 
  2. 어트리뷰션 로직: 어트리뷰션 매커니즘은 다음 어트리뷰션 후보 중 선택해야 합니다. 
    • Network B (for Click 2)
    • Network A (for Click 1)
    • Organic

    만약 프러드 평가가 없었다면, 클릭 2는 인스톨에 가장 가까운 클릭으로서 최선의 어트리뷰션이 될 것입니다. 하지만, 클릭2가 거절된다면, 그다음 차선인 옵션이 선택됩니다. 

  3. 어트리뷰션 결정: 해당 인스톨이 (Click 1의) 매체 A로 어트리뷰트 됩니다.
  4. 리포트: Singular는 매체 B에 대한 거부를 거부 리포트(rejection reports) 에 추가합니다. 
  5. 포스트 백: Singular는 매체 B에 거부된 포스트 백을 전송합니다.  
예시 2: 모든 클릭이 거부되었을 때 

image4.png

  1. 프러드 감지 과정: 이 예시는, 프러드 방지 엔진이 모든 터치 포인트들을 점검하고 클릭1과 클릭2를 프러드로 거부한 경우입니다. 
  2. 어트리뷰션 로직: 어트리뷰션 매커니즘은 다음 어트리뷰션 후보 중 선택해야 합니다.
    • Network B (for Click 2)
    • Network A (for Click 1)
    • Organic
  3. 어트리뷰션 결정:모든 클릭이 거부되었기 때문에, 해당 인스톨도 오가닉(Organic)으로 표시됩니다.
  4. 리포트: Singular는 매체 B에 대한 거부를 거부 리포트(rejection reports) 에 추가합니다.
  5. 포스트 백: Singular는 매체 B를 거부된 포스트 백으로 전송합니다.
예시 3: "오가닉" 옵션이 거절된 경우 (신뢰할 수 없는 인스톨)

Screen_Shot_2019-11-17_at_13.42.09.png

  1. 프러드 감지 과정: 이 예시는, 프러드 방지 엔진이 모든 터치 포인트들을 점검하고 프러드인 클릭1과 클릭2를 거부한 경우입니다. 또한, 엔진은 이 해당 인스톨 이벤트 자체를 거짓으로 인식하여 거부한 경우입니다.   
  2. 어트리뷰션 로직: 어트리뷰션 매커니즘은 다음 어트리뷰션 후보 중 선택해야 합니다.
    • Network B (for Click 2)
    • Network A (for Click 1)
    • Organic
  3. 어트리뷰션 결정: (이벤트 인스톨이 거짓으로 판정됨에 따라) 모든 클릭이 거절되었고 오가닉 옵션 또한 거절되었기에, 인스톨은 신뢰할 수 없다(Untrusted)로 어트리뷰트 됩니다. 
  4. 리포트: 
    • Singular는 매체 B에 대한 거부를 거부 리포트(rejection reports) 에 추가합니다.
    • Singular는 의심스러움 리포트(suspicious report) 에 신뢰할 수 없다고 여겨지는 의심스러움 인스톨을 추가합니다. 
  5. 포스트 백: Singular는 매체 B에 거부된 포스트 백을 전송합니다.

프러드 리포팅

Singular의 프러드 리포팅 툴은 프러드 방지 엔진의 결정을 추적할 수 있도록 하며 각 앱에 관련된 기만적인 활동 (fraudulent activity)를 분석할 수 있도록 합니다.

  조회 가능한 리포트와 사용법에 관하여 더 많은 정보를 원하시면 프러드 방지: 리포팅을 참고하세요.

프러드 포스트 백

Singular는 광고 매체 또는 광고주의 내부 BI 플랫폼에 연관된 프러드 결정에 대한 자동화 포스트 백을 전송할 수 있습니다. 

여기에는 두 포스트 백 종류들이 있습니다:

  • 거부 포스트 백(Rejection postback): 인스톨이 특정 터치 포인트로 어트리뷰트 되었지만, Singular의 프러드 방지 시스템에 의해 거절되었을 때 전송됩니다.
  • 의심스러운 인스톨에 대한 알림: 특정 인스톨이 의심스럽다고 표기된 터치 포인트로 어트리뷰트 된 경우 광고주의 내부 BI 시스템에 전송됩니다.

  더 많은 정보를 원하시면 프러드 포스트 백를 참고하세요.

Singular 프러드 방지를 활용하는 가장 좋은 방법

"거절(reject)“ 사용 전 의심스러움(Suspicious)으로 표기”를 활용

기본 메서드와 커스텀 규칙들을 모두 포함하는 Singular의 프러드 방지 도구는 문제에 직면했을 때 원치 않는 거짓 양성(false positive) 또는 거짓 음성(false negative)을 생성할 수 있습니다. 몇몇 새 메서드나 규칙들을 테스트하지 않고 활성화하면, 현재 진행되고 있는 마케팅 캠페인 또는 결과량에 의도치 않은 영향을 줄 수 있습니다. 

이런 이유로 저희는 새 메서드와 규칙을 "거절(reject)" 대신 "의심스러움(suspicious)으로 표기"하도록 설정시기를 권고하고 있습니다. 의심스러움(suspicious) 리포트를 사용해서 새 메서드 또는 규칙이 한동안 예상대로 작동하는지 지켜보세요.  

해당 메서드와 규칙에 대해 만족하시면, Singular가 청구서 발송하는 포스트 백으로 분류하는 것을 방지하여 CPI/CPA 요금을 낮추도록 "거절(Reject)"로 설정하시면 됩니다.   

커스텀 규칙 레버리지

모든 버티컬(vertical)과 애플리케이션은 고유한 프러드 케이스들에 직면합니다. 저희는 항상 커스텀 규칙들을 생성해서 Singular의 프러드 방지 시스템이 고유 사례들을 보호할 수 있도록 권고하고 있습니다. 다음과 같이 예를 들겠습니다. 

  • 프러드가 아니며 검증된 파트너들을 화이트리스트 (예, 내부 상호 촉진 광고) e.g., internal cross-promo.
  • 캠페인의 타깃팅 옵션과 일치하지 않는 인스톨들을 거부

Singular 알림 레버리지

가끔 프러드를 잡아내는 최상의 방법으로 KPI를 보는 방법이 있습니다. 특정 KPI에 알림을 설정하시어 소스 또는 퍼블리셔가 갑자기 극도로 훌륭한 퍼포먼스를 보여주거나 극도로 저조한 퍼포먼스를 보일 경우 알림 받을 수 있습니다. 이런 이상 현상은 프러드일 가능성이 있으며, 커스텀 규칙을 사용하여 대처할 수 있습니다.  

도움이 되었습니까?