Overview

유저의 개인 정보를 보호하기 위해, 귀하는 Branch가 개인식별정보(PII)로 사용하거나 인식할 수 있는 데이터를 Branch 서비스를 통해 전송해서는 안 됩니다. PII에는 성명, 유저 이름, 이메일 주소 및 계정 번호와 같은 정보가 포함되며 꼭 이에 국한되지만은 않습니다.

디지털 프로퍼티 내에서 Branch를 설정할 때 이 문서의 모범 사례를 따라 PII가 Branch로 전달될 가능성을 줄이세요. 국가 및 지역에 따라 법률이 다르고 Branch 서비스를 다양한 방식으로 사용할 수 있기 때문에 특정 정보가 PII인지 여부가 확실하지 않은 경우 내부 법률 고문과 상의하세요.

이 문서는 다음을 이해하는 데 도움이 됩니다.

개인정보, PII, 가명 데이터 또는 익명 데이터인지에 대한 분류에 따라 Branch가 다양한 유형의 데이터를 취급하는 방법.
Branch 또는 기타 써드파티와 공유하기 전에 개인정보를 보호하는 것이 중요한 이유.
Branch 서비스 전반에 걸친 다양한 데이터 파라미터 처리.

PII, 개인정보, 가명 및 익명 데이터

개인 정보 보호 관점에서 데이터는 개인식별정보, 개인정보, 가명 데이터 또는 익명 데이터의 4개 카테고리로 분류되는 경우가 많습니다. 일반적으로 개인식별정보에는 개인을 식별할 수 있는 보다 민감한 형태의 데이터가 포함됩니다. 아래에 명시된 특정 데이터 필드를 제외하고 개인정보, PII 및 기타 민감한 데이터는 Branch와 전혀 공유해서는 안 되며 Branch와 공유되기 전에 익명화되거나 가명화되어야 합니다. 아래에서는 이러한 다양한 데이터 범주와 가명화 및 익명화에 대한 몇 가지 모범 사례에 대해 설명합니다.

개인식별정보(PII)란 무엇인가요?

Branch에서는 데이터를 관련 관할권의 법률에 따라 개인정보 또는 개인식별정보로 취급합니다. 일반적으로 Branch는 개인식별정보(Personally Identifiable Information, PII)를 개인을 직접 식별, 연락 또는 정확하게 추적하기 위해 자체적으로 사용될 수 있는 정보로 해석합니다.
여기에는 다음이 포함됩니다.

이메일 주소
우편 주소
전화번호
정확한 위치 (예: 소수점 4자리 이상의 GPS 좌표)
이름 또는 유저 ID

Branch does not collect PII to provide our services and strongly advise customers to ensure they are not sending PII to Branch inadvertently.

개인정보란 무엇인가요?

개인정보는 유럽 일반 데이터 보호 규정에 따라 2018년에 도입된 비교적 광범위한 데이터 범주이며 IP 주소, 쿠키 ID, 애플 광고 식별자(IDFA) 및 구글 광고 식별자(GAID)와 같은 광고 식별자와 같이 실제 사람과 관련된 식별되거나 식별 가능한 모든 정보입니다. Branch는 서비스를 제공하기 위해 고객으로부터 개인정보를 수집합니다.

가명 데이터란 무엇인가요?

가명 데이터는 데이터 기록 상의 개인정보 또는 PII 필드를 가명으로 대체하는 기술을 통해 익명화된 데이터로, 추가 정보를 사용하지 않고는 이 데이터 기록을 통해 더 이상 엔드 유저를 특정할 수 없게 됩니다. 가명화를 수행하기 위해서는 기술 및 조직적 방법을 통해 식별 참조 정보가 별도로 유지되도록 함으로써 엔드 유저에 대한 재식별을 방지하여야 합니다.

익명 데이터란 무엇인가요?

익명 데이터는 엔드 유저의 디바이스와 연결되지 않으며 어떤 방식으로든 엔드 유저를 구체적으로 식별하지 않고 해당 엔드 유저의 향후 식별 가능성을 제공하지도 않습니다. 예를 들어, 특정 기간의 설치 수에 대해 Branch 대시보드에서 보는 집계 데이터는 익명 데이터입니다.

해싱이란 무엇인가요?

해싱(난독화라고도 함)은 텍스트 string(예: 개인정보 또는 PII 필드)이 임의의 숫자 값으로 변환되는 가명화 기술입니다. 해싱은 다음과 같은 몇 가지 이유로 개인정보 및 PII를 써드파티와 공유하기 전에 가명화하는 데 사용되는 유용한 도구입니다.

해시값은 다른 텍스트 string이 동일한 해시값을 생성할 가능성이 거의 없다는 점에서 고유합니다.
해싱은 동일한 텍스트 string이 매번 동일한 해시값을 생성한다는 점에서 결정적입니다.
해시값은 실제로 해시값을 가져와서 원래 텍스트 string을 나타내기 위해 알고리즘을 반전하는 것이 불가능하다는 점에서 '일방향'입니다.

Branch는 자동 해싱 기술을 활용하여 처리하는 개인정보를 최소화합니다. 또한 앱의 데이터 기록에서 PII를 활용하는 한, 데이터 최소화를 수행하기 위해 Branch와 같은 써드파티 서비스 제공 업체와 데이터를 공유하기 전에 그러한 PII를 해시해야합니다.

표준 해싱 알고리즘

개인정보 및 PII를 암호화하고 이를 Branch 및 기타 써드파티에게 안전하게 전달하는 데 사용할 수 있는 몇 가지 표준 해싱 알고리즘이 있습니다.

MD5 – 일반적으로 32자리 16진수로 렌더링 되는 128 비트(16 바이트) 해시값을 생성합니다.
SHA-1 – 일반적으로 40자리 16진수로 렌더링되는 160 비트(20 바이트) 해시값을 생성합니다.
SHA-256 – 256 비트(32 바이트) 해시값을 생성하며 일반적으로 64자리 16진수로 렌더링 됩니다.

해싱의 예

예를 들어, 엔드 유저가 자신의 이메일 주소 ([email protected]) 를 제공했다고 가정해 보겠습니다. 이 주소는 PII로 인식되므로 Branch와 같은 써드파티 서비스 제공 업체에 이 데이터를 보내기 전에 해시하려고 합니다.


고객 이메일 주소	[email protected]
MD5 해시값	6a6c19fea4a3676970167ce51f39e6ee
SHA-1 해시값	fd9c796f4269b3484f9ef436627d0d1cb35071c5
SHA-256 해시값	d709f370e52b57b4eb75f04e2b3422c4d41a05148cad8f81776d94a048fb70af

데이터를 해싱할 때 대소문자와 구두점이 중요하다는 점을 명심하십시오. [email protected]는 [email protected]와 상이한 해시를 생성할 것입니다. 전화번호에 괄호, 공백 또는 대시 포함하는 경우도 마찬가지입니다.

Branch의 데이터

As part of Branch’s guiding Privacy Principles, we practice data minimization, which means that we avoid collecting or storing information that we don’t need to provide our services. The personal data that we collect is limited to data like advertising identifiers, IP address, and information derived from resettable cookies. In addition, we take a variety of measures to make sure personal data like this isn’t stored in raw form in our systems for longer than we need it to provide our services.

Branch가 자동으로 해싱하는 데이터

Branch has implemented automated hashing mechanisms for data parameters that are expected to or could reasonably include personal data. The following data parameters are automatically salted and sha256 hashed per Our Data Retention Policy and stored only in this hashed form thereafter:

user_data_aaid - 유저와 관련된 Google 광고 ID입니다.
user_data_android_id - 유저와 관련된 Android ID입니다.
user_data_browser_fingerprint_id - 유저와 관련된 웹 브라우저 지문 ID입니다.
user_data_randomized_device_token - The device fingerprint ID associated with the user.
user_data_developer_identity - 유저와 관련된 개발자 지정 ID입니다.
user_data_geo_lat - IP 주소(위에 표시)에서 파생된 위도. 서버 측에서 자동으로 설정합니다.
user_data_geo_lon - IP 주소(위에 표시)에서 파생된 경도. 서버 측에서 자동으로 설정합니다.
user_data_idfa - 이벤트가 발생한 기기의 iOS 광고 ID. 클라이언트가 지정합니다.
user_data_idfv - 이벤트가 발생한 기기의 iOS 공급 업체 ID. 공급 업체 단위로 저장됩니다. (예: Facebook: idfv는 Facebook 및 Messenger에서 동일하지만 Twitter에서는 상이) 클라이언트가 지정합니다.
user_data_ip - 이벤트를 트래킹하는 API 호출이 시작된 IP 주소입니다. 자동으로 서버 측에서 설정됩니다.
user_data_local_ip - 디바이스의 로컬 IP. Android 전용입니다.
user_data_persona_id - 유저와 연관된 Branch의 페르소나가 할당한 ID입니다.
last_attributed_touch_data_custom_fields
- $aaid - 유저와 연관된 Google 광고 ID입니다.
- $idfa - 이벤트가 발생한 기기의 iOS 광고 ID. 클라이언트가 지정합니다.
- +url- %24idfa 및 %24aaid 필드가 '+url'에 쿼리 파라미터로 추가됩니다. 따라서, 이 부분들은 해시되어 '+url'필드에 다시 추가됩니다.

다음 필드도 해시되지만, 7일 후가 아닌 60일 후에 해시됩니다. JSON 필드의 경우 JSON 객체의 모든 데이터가 아니라 나열된 key-value가 해시됩니다.

last_attributed_touch_data_plus_referring_domain
last_cta_view_data_plus_referring_domain
user_data_http_referrer
install_activity_touch_data_plus_referring_domain
install_activity_touch_data_additional_data_plus_referring_domain
reengagement_activity_touch_data_plus_referring_domain
reengagement_activity_touch_data_additional_data_plus_referring_domain
last_attributed_touch_data_custom_fields, install_activity_touch_data_additional_data_custom_fields, reengagement_activity_touch_data_additional_data_custom_fields
- +referrer
- +url
- $original_url
- $fallback_url
- $fallback_url_xx
- $canonical_url
- $desktop_url
- $ios_url
- $ipad_url
- $android_url
- $samsung_url
- $huawei_url
- $windows_phone_url
- $blackberry_url
- $fire_url
- $ios_wechat_url
- $android_wechat_url
- $android_deeplink_path
- $ios_deeplink_path
- $deeplink_path
- $og_image_url
- $og_video
- $og_url
- $twitter_image_url
- $og_image
- +apple_search_ads_attribution_response
- email
- email_address
- referral_email
- emailId
- userEmail
- $email
- referrerEmail
- pw
- password

PII 모범 사례

유저 개인 정보를 보호하기 위해 Branch 정책은 개인식별정보(PII)로 인식할 수 있는 데이터를 Branch에 전달하지 않도록 강력히 권장합니다.

Branch only collects (and soon thereafter hashes) the Personal Data listed above.

Branch는 다음과 같은 PII를 수집하지 않습니다.

이메일 주소
계좌 번호
우편 주소
성명 또는 유저 ID
HIPAA에 의해 보호되는 Protected Health Information

This is by no means an exhaustive list - if the specific data parameter is not the list in our Privacy Policy and you believe it to be PII or otherwise sensitive data, chances are you shouldn’t be sending it to Branch without at least anonymizing or pseudonymizing it first.

이 PII를 Branch로 보낼 확률을 줄이려면 아래에 설명된 모범 사례를 따르세요.

비가공 PII를 Branch로 전송하지 마세요.

Do not send raw PII to Branch via any data parameters you configure to collect information.

Branch로 PII를 보내기 전에 해시하세요.

Branch를 통해 PII를 보내야 하는 경우 Branch로 데이터를 보내기 전에 해시해야합니다. 이상적으로는 sha256 해싱 기능을 사용합니다.
Branch does not need to collect the PII fields mentioned above for our services to work, and Branch does not support dedicated parameters for you to pass their hashed versions. If you need to send these hashed fields through Branch, you can do so by passing them into a custom data object via API or SDK. You should work with your account team to make sure this is done correctly before sending this data to Branch.

"custom_data": {
    "user_phone_sha256": "15e2b0d3c33891ebb0f1ef609ec419420c20e320ce94c65fbc8c3312448eb225",
    "user_email_sha256": "d709f370e52b57b4eb75f04e2b3422c4d41a05148cad8f81776d94a048fb70af"
  },

Developer Identity

Developer Identity: Branch customers can optionally set a custom parameter called Developer Identity by calling the .setIdentity method on our SDKs (Android, iOS, Web). Generally this is done when a user logs in, and should represent some sort of non-PII user ID.
자체적인 유저 식별자를 사용하여 오프라인 데이터를 Branch의 데이터와 결합하려는 경우 Developer ID로 사용할 값을 선택할 때 염두에 두어야 할 몇 가지 사항이 있습니다.
개인식별정보(PII)가 포함된 식별자를 개발자 ID로 사용할 수 없습니다. 이는 이메일 주소, 유저 로그인, 주민등록번호, 전화번호 또는 'PII'로 간주되는 모든 데이터를 배제합니다.
방문자를 위해 생성한 난독화되지 않은 영숫자 데이터베이스 식별자를 사용할 수 있습니다. 또 다른 허용 가능한 옵션은 PII를 기반으로 하지만 Protected Health Information(HIPAA에 정의 된 대로)이 아닌 해시 또는 암호화된 식별자를 Branch에 전달하는 것입니다. 단, 적절하게 강력한 해싱 또는 암호화를 사용해야 합니다. Branch는 강력한 해싱 알고리즘과 솔트 사용을 권장합니다.
Branch 데이터를 해시 되지 않은 자체 내부 식별자에 다시 조인하려는 경우 비가공 PII 또는 개인정보와 해시된 해당 데이터와 일치하는 자체 내부 참조 테이블을 만드는 것이 좋습니다. 이렇게 하면 민감하고 해시되지 않은 데이터 없이 과거에 추출한 Branch 데이터를 자체 내부 데이터베이스와 잘 정렬하여 상대적으로 안정적인 시스템을 유지할 수 있습니다.

URL 내의 PII

URLs: Email is often used for verification as part of site registration and sign up processes, or in the context of password resets or newsletter signups. These verification emails can sometimes inadvertently include PII in the confirmation/registration link. For instance, site.com/confirm?email=sample%40email.com&token=413203.
확인 페이지의 URL에 PII가 포함되어 있고 페이지가 Branch의 웹 SDK를 호스팅하는 경우, PII가 실수로 URL string의 일부로 Branch의 시스템으로 전달될 수 있습니다.
PII가 없는지 링크 확인: 회원가입을 합니다. 가입 확인 이메일의 URL에 이메일 주소 또는 기타 PII가 포함되어 있는지 확인하세요. 어떤 상황에서도 URL에 비가공 PII를 포함해서는 안 됩니다. 이 PII를 해시 또는 암호화하거나 더 안전한 가명 식별자를 사용하십시오.

Branch 링크 데이터의 PII (쿼리 파라미터 포함)

위에서 설명한 대로 Branch 링크 데이터에 비가공 PII를 포함하는 것은 Branch의 정책에 위배됩니다. 여기에는 Branch가 전체 URL을 저장하므로 "아무것도 설정되지 않은" Branch 링크에 쿼리 매개 변수로 PII를 추가하는 것이 포함됩니다.
For example, imagine a Branch link with a raw email appended as a query param, like this: https://www.test.app.link/abc123?email=sample%40email.com&token=413203. Branch will store the full URL, including the unwanted PII, in our systems when a user clicks on this link.
모범 사례로, Branch 링크 데이터에 비가공 PII를 추가하지 않도록 유의하십시오. 이는 해싱하거나 가명화하여 추가되어야 합니다. (링크 생성 후 추가된 쿼리 파라미터도 마찬가지).

HIPAA 고지 사항

Branch가 서면으로 달리 명시하지 않는 한, Branch는 수정된 건강 보험 이동성 및 책임법('HIPAA')에 따른 의무를 창출하기 위해 Branch 서비스를 사용할 의도가 없으며, Branch 서비스가 HIPAA 요구 사항을 충족한다고 진술하지도 않습니다. 귀사가 HIPAA에 따른 적용 대상 기업이거나 비즈니스 어소시에이트인 경우(혹은 될 경우), 귀사는 Branch로부터 그러한 사용방식에 대한 사전 서면 동의를 받지 않는 한, Protected Health Information과 관련된 어떤 목적이나 방식으로든 Branch 서비스를 사용할 수 없습니다.

필터