MobilePush Point 정리

MobilePush를 이용하는데 있어 자주 문의주시는 내용을 정리했습니다.
*Document 가 상시 업데이트 되고 있기 때문에 예고없이 내용이 변경되는 경우가 있습니다.

Point: 메시지 발송 대상은 Device 단위
OutBound 메시지를 발송할 경우, 지정된 리스트 혹은 Data Extension에 존재하는 Contact중 [해당 어플리케이션에 OptIn Status 인 Device]를 대상으로 메시지 발송이 시도됩니다.
*하나의 Contact에 Device가 여러개 연결되어있는 경우, [Status가 OptIn]인 Device 모두 메시지 발송대상이 됩니다.

때문에 메시지 발송건수는 리스트 혹은 Data Extension에 존재하는 Contact의 숫자보다 많거나 일치하지 않는 경우가 많습니다.
Send 탭 등에서 확인하신 발송건수와 리스트상의 건수가 일치하지 않는다는 문의가 많습니다만, 일치하지 않는 경우가 대부분이라는 점 유의해주시면 감사드리겠습니다.

하나의 Contact에 여러개의 Device가 연결되어 있는 경우는 자주 있으며, 이때 리스트의 건수보다 많은 발송건수가 기록되곤 합니다.
한편으로 OptOut 된 Device가 많은 경우나 Contact가 발송대상의 어플리케이션에 OptIn한 것이 아닌 경우, 이러한 Device 에는 메시지가 발송되지 않기 때문에 리스트 혹은 Data Extension의 건수보다 적은 경우가 있습니다.
*Inbox 메시지는 OptOut 인 Device에도 발송됩니다.

Point: 발송결과 확인방법
개별 Device로의 발송결과를 확인하기 위해서는 Data Extract Activity: MobilePush Detail Extract 를 이용합니다.
Push 메시지가 정상적으로 Device 에 표시되지 않는 경우, 먼저 해당 Report 를 확인해주시면 감사드리겠습니다.
원인불명의 경우 Support 에 해당 Report 를 첨부하시어 문의주시면 원활한 조사가 가능합니다.

해당 Report 의 결과에 발송 Status 가 Success 일 경우, Marketing Cloud 에서 ISP(APNs/FCM)으로의 발송은 성공한 것을 의미하므로 메시지가 수신되지 않는 원인은 ISP(APNs/FCM) ~ 유저의 핸드폰 및 어플리케이션간의 문제인 것을 알 수 있습니다.
반면 Status 가 Fail 인 경우에는 아래 Document 에 기재된 바와 같이 ServiceResponse 의 값을 참조하면 에러 상세내역을 확인 가능합니다.

참고정보 : MobilePush Message Detail Extract Errors

일부 발송에서 Status 가 Fail 인 경우, 대부분 InvalidToken (iOS), NotRegistered (Android) 가 원인인 경우가 많습니다.
주로 유저측에서 어플리케이션을 삭제했거나, Push 메시지 수신거부를 설정했을 경우 등에 의해 Push 메시지의 Token 정보가 무효화되었을 경우에 발생합니다.

위와 같은 이유로 발송 Fail 된 디바이스는 유저측에서 어플리케이션을 재설치하거나, Push 메시지 수신설정을 허가하여 새로운 Token 정보가 Marketing Cloud 에 연동되지 않는 이상 해당 어플리케이션으로의 Push 메시지의 발송은 불가능합니다.
또한 메시지 발송이 3번 Fail 될 경우, 혹은 iOS는 Feedback 서비스를 이용하여 자동으로 메시지 발송에 실패한 디바이스는 OptOut 으로 유저의구독 Status가 변경되기 때문에 메시지 발송 불가 디바이스에 대해 무의미한 메시지가 발송되는 일은 없습니다.

추가정보
Data Extract Activity 작성시 Extract Type 에 MobilePush Detail Extract Report 가 표시되지 않는 경우, MID 와 함께 MobilePush Detail Extract Report 설정 의뢰를 Case 로 문의주시면 서포트측에서 대응해드립니다.

참고정보 : Run the MobilePush Detail Extract Report

Point: ContactKey 를 다른 Channel(Email,LINE,SMS등)과 통합하기
아래 Developer 페이지에 기재된 바와 같이 ContactKey 를 명시적으로 설정하는 메서드 (setProfileID/sfmc_setcontactKey) ※를 구현합니다. 이 때, 설정되는 ContactKey 를 Email Studio 등 기존 Channel 의 ContactKey 로 지정함으로서 MobilePush 의 ContactKey 를 기존 ContactKey 와 통합하는 것이 가능합니다.

예를 들면, Email Studio 에서 회원번호를 ContactKey(SubscriberKey) 로 이용하는 경우 어플리케이션에서도 유저가 회원번호를 입력하면(로그인등 특정 타이밍에서 위 메서드를 사용하여) 회원번호를 ContactKey 로 Marketing Cloud에 연동함으로서 Email Channel 의 ContactKey 에 MobilePush 의 ContactKey 를 통합할 수 있습니다.

상기 메서드는 유저의 로그인에 의해 실행되도록 구현하여 사용하시는 경우가 대부분이므로, 로그인 유무에 따른 동작에 대한 문의를 많이 주십니다.
하지만 Marketing Cloud 및 MobilePush SDK 에는 로그인/로그아웃의 개념이 없으며 어플리케이션내 로그인/로그아웃 처리에 의해 동작이 변하지 않습니다.
또한 로그인 처리에 맞추어 SDK 가 자동적으로 상기 메서드를 실행하지는 않으므로 어플리케이션내에 명시적으로 구현해주실 필요가 있습니다.
때문에 로그인 유무에 의해 동작을 변경하고 싶으신 경우에는 요건에 맞게 상기 메서드를 구현하시면 됩니다.
※ 해당 메서드는「setContactKey」로 호칭되기도 합니다.

참고자료:

• https://developer.salesforce.com/docs/marketing/mobilepush/guide/overview.html

Point: 불필요한 ContactKey를 관리하기
어플리케이션 측에서 지정된 ContactKey(예:회원번호 등)를 Marketing Cloud에 연동하지 않을 경우, SDK 초기화 타이밍에 SDK에의해 GUID 형식의 ContactKey가 발행됩니다.(Contacts and Devices) 때문에 이후 setContactKey 에 의해 ContactKey 가 Marketing Cloud에 연동될 경우 초기에 등록된 GUID 형식의 ContactKey는 어느 채널에도 연결되지 않은 [Contacts Without Channel Addresses] 로 남게 됩니다.

이러한 GUID 형식의 ContactKey 의 생성을 방지하고자 하는 경우 [Find Contacts Without Channel Addresses] 를 통해 정기적으로 무의미한 ContactKey 를 삭제하시거나 Delay Registration 메서드를 사용할 수 있습니다.
Delay Registration 를 사용하면 유저가 로그인을 한 다음 어플리케이션 내에서 setContactKey 로 ContactKey(예:회원번호 등)가 Marketing Cloud에 연동되지 않는 이상 ContactKey 는 등록되지 않습니다.
이것은 setContactKey 로 ContactKey가 등록되지 않는 이상 유저에게 메시지를 발송할 수 없다는 것을 의미합니다.
이러한 특성을 고려하여 요건에 맞게 Delay Registration 의 사용을 검토해주시면 감사드리겠습니다.

참고자료:
Delay Registration에 대해서는 아래를 참고해주십시오.
Contact Dissociation
Contactkey 의 체계에 대한 검토하실 경우 아래 Document를 참고 해주세요.
Register Contacts with Marketing Cloud Engagement

주의 사항 1:
setContactKey는 지정한 Contact 키가 이미 Marketing Cloud 환경에 존재하는 경우, 해당 Contact에 연결됩니다. 존재하지 않으면 새로운 Contact로 Marketing Cloud 환경에 등록됩니다.
ContactKey의 "덮어쓰기"를 수행하는 것이 아니라는 점에 유의하십시오.
예를 들어, 1개의 디바이스에서 setContactKey를 각각 다른 새로운 ContactKey로 10회 실행한 경우, 10개의 새로운 Contact가 생성됩니다.

주의 사항 2:
1개의 Contact에 연결하는 디바이스 수에 제한은 없지만, 불특정 다수의 디바이스를 1개의 Contact에 등록하는 것은 권장하지 않습니다.
사용자를 특정할 수 없는 익명의 상태의 디바이스를 1개의 ContactKey에 등록하여 문의주시는 경우가 종종 있습니다.
이 경우 Contact Builder 등에서 익명의 Contact 정보를 열람할 수 없고, 정보 추적이 어려워지는 등 여러 문제가 발생할 수 있습니다.
익명의 Contact 를 해결하는 방법으로, 이들을 Contact로 등록하고 싶지 않은 경우에는 앞서 언급한 Delay Registration 을 이용하는 것을 검토해주세요. *익명의 Contact를 등록하고 싶은 경우에는 기본 GUID 형식의 Contact로 등록하세요.
참고 자료: Registration Updates Via Contact Key, Attributes, and Tags
*인용: Don't set the contact key to a generic, non-unique value

주의 사항 3:
각 채널의 주소 정보를 갖지 않게 되어 불필요해진 Contact를 추출할 때는 반드시 [Contacts Without Channel Addresses]를 이용하여 삭제 대상을 추출하십시오. 필터링된 리스트 등을 이용하여 추출하면 모바일 채널의 주소를 가진 유효한 Contact를 잘못 삭제할 수 있습니다.
특히 모바일 채널은 이메일 채널과 달리 채널 주소가 각 BU에서 관리되므로, 이를 고려하지 않고 하위 BU의 유효한 Contact를 삭제하는 경우가 있습니다.
이 경우, 아래 기재된 바와 같이 삭제한 Contact가 가진 디바이스에 대한 Push 알림을 비롯한 모든 MobilePush 기능을 이용할 수 없게 됩니다. 기능을 복구하려면 유저가 어플리케이션을 삭제하고 다시 설치해야 합니다.

https://help.salesforce.com/s/articleView?id=sf.mc_cab_contact_deletion.htm&type=5
Contact Deletion in Contact Builder > MobileConnect and MobilePush Contact Deletion
==
It’s assumed that all MobilePush contact deletions are associated with a compliance deletion based on GDPR or other regulatory requirements. The MobilePush SDK and platform restrict future push notification registrations from that contact’s specified mobile device. To reestablish themselves as a contact, the contact must delete and reinstall the mobile app on their device.
==

*Case에서는 위 내용에 따라 삭제된 Contact의 복구 방법에 대해서 재설치 이외의 방법은 안내하지 않습니다.

Contact 삭제 후 SDK의 내부 동작을 분석하여 재설치 이외의 복구방법에 대한 문의가 많습니다.
이러한 내부 동작에 의존하는 구현은 동작을 보증 할 수 없으므로, 고객 환경에서 충분히 검증한 후 구현해야 합니다.
위와 같은 상황에 빠지지 않도록 반드시 [Contacts Without Channel Addresses] 를 이용하여 Contact 삭제 대상을 추출하십시오.
부득이하게 채널 주소를 가진 Contact를 삭제하는 경우에는 위의 사항을 고려하여 불필요한 Contact를 사전에 면밀히 확인한 후 삭제하실 것을 권장드립니다.

포인트: 수신함(Inbox) 메시지의 특징
수신함 메시지는 다음과 같이 푸시 알림과는 다른 특징을 가집니다.

푸시 알림(Push message):
Marketing Cloud에서 메시지 프로바이더(FCM/APNs)에게 원격 알림을 요청합니다. 사용자가 해당 어플리케이션의 알림을 허용하지 않은 경우, 알림을 보낼 수 없습니다.

수신함(Inbox message):
어플리케이션이 포그라운드(Foreground) 상태가 되면 어플리케이션에서 Marketing Cloud에 대해 자신의 디바이스가 대상이 되는 메시지가 있는지 확인 후, 수시로 다운로드합니다. 메시지 프로바이더(FCM/APNs)를 통한 알림 메커니즘을 이용하지 않으므로 유저가 해당 어플리케이션의 알림을 허용하지 않아도 메시지를 다운로드할 수 있습니다.
또한 Marketing Cloud에서 디바이스에 접근하지 않는다는 점에 유의하십시오.
수신함(Inbox) 메시지에서 "발송" 또는 "송신"과 같은 단어가 편의상 사용되는 경우가 있지만, 실제로는 디바이스에 대해 Marketing Cloud에서 자발적으로 메세지를 발송하는 것이 아니라 해당 수신함 메시지를 다운로드할 수 있는 상태로 만드는 것을 의미합니다.

※레포트 확인 시 주의사항※
"Push Message Detail"을 출력했을 때, 수신함 메시지(만)에 대해서는 메시지가 다운로드되지 않는 한 레코드로 출력되지 않습니다.
예를 들어, 10개의 디바이스를 대상으로 수신함 메시지를 전송(전달 가능한 상태)하고, 그중 3개의 디바이스에서 다운로드했다고 가정합니다.
이때 레포트에는 3개의 레코드만 기록됩니다. 나머지 7개의 레코드는 이 단계에서는 기록되지 않습니다.
또한 푸시 알림을 보내지 않으므로 "Status" 등의 푸시 알림 관련 항목에는 아무것도 기록되지 않고 비어 있습니다.

푸시 알림 + 수신함 (Push message + Inbox message):
푸시 알림을 보내고 수신함 메시지도 동시에 다운로드할 수 있는 상태로 만듭니다. 알림을 허용하지 않은 디바이스에 대해서는 푸시 알림이 전송되지 않고 수신함 메시지만 전달 가능한 상태가 됩니다.

※레포트 확인 시 주의사항※
알림을 허용한 디바이스에는 푸시 알림이 전송되므로, 푸시 메시지 세부 정보 레포트에는 푸시 알림을 보낸 시점에 레코드가 기록됩니다.
반대로 알림을 허용하지 않은 디바이스는 수신함 메시지가 다운로드된 시점에 레코드가 기록됩니다.
이와 같이 푸시 알림 + 수신함은 2개의 다른 메커니즘을 동시에 이용하고 있어 혼란을 야기하는 경우가 많으므로 주의하십시오.

FAQ
Q) 어플리케이션을 제거하거나 Push 알림을 OFF한 후 OptOut되는 시점은 언제입니까? 어플리케이션을 제거해 보았지만 OptIn 상태로 유지되고 전송 상태도 OK로 표시됩니다.
A) 둘 다 메시지 프로바이더(FCM/APNs)의 동작에 따라 다르므로 명확한 시점은 알 수 없습니다. 제거 후 바로 OptOut되거나 메시지 전송 시 전송 상태가 NG가 되는 것은 아닙니다.

Q) 어플리케이션을 제거한 시점을 알고 싶습니다.
A) Marketing Cloud SDK를 통해 유저가 어플리케이션을 제거했다는 내용은 확인하기 어렵습니다.

Q) 어플리케이션을 다시 설치하여 DeviceID가 변경되면, 다시 설치하기 전의 수신함 메시지는 복원됩니까?
A) 아니요, 그렇지 않습니다. 수신함 메시지는 DeviceID를 대상으로 다운로드 되므로, 다시 설치하여 DeviceID이 변경되면 수신함 메시지는 없는 상태가 됩니다.

Q) 동일한 디바이스에서 다른 계정으로 로그인하는 등 다른 Contactkey를 setProfileId를 통해 설정했지만 수신함 메시지 리스트가 변경되지 않습니다.
A) 앞서 언급한 바와 같이 수신함 메시지는 DeviceID를 대상으로 다운로드 되므로 Contactkey가 변경되어도 다운로드 대상 메시지는 변경되지 않습니다.
※ 위와 같이 어플리케이션의 계정(Marketing Cloud에서는 Contactkey)을 전환하는 경우, 수신함 메시지 리스트도 함께 전환하고 싶다는 문의가 있습니다. 그러나 안타깝게도 위와 같이 수신함 메세지는 DeviceID에 연결되므로 현재로서는 구현이 어렵습니다.

Q) CustomKey에 %%_subscriberkey%% 개인화 문자열을 설정한 경우, Contactkey를 기반으로 한 수신함 메시지를 만들 수 있습니까?
A) 아니요. 개인화 문자열은 다운로드될 때마다 렌더링되므로 다운로드 시의 Contactkey가 반환되므로 모든 메시지에서 동일한 Contactkey가 할당되어 구분할 수 없습니다.