게재 실패 이해 delivery-failures
바운스 수는 ISP가 백 실패 알림을 제공하는 게재 시도 및 실패의 결과입니다. 바운스 처리 프로세싱은 목록 안전 상태의 중요한 부분입니다. 지정된 이메일이 여러 번 연속적으로 반송된 후 이 프로세스는 해당 이메일에 대해 비표시 플래그를 지정합니다.
이 프로세스를 수행하면 시스템이 잘못된 이메일 주소를 계속 보내지 못합니다. 바운스 수는 ISP가 IP 평판을 확인하는 데 사용하는 주요 데이터 중 하나입니다. 이 지표를 주시하는 것이 중요합니다. "전달됨"과 "바운스됨"은 마케팅 메시지 전달을 측정하는 가장 일반적인 방법입니다. 전달률이 높을수록 좋습니다.
메시지를 프로필로 보낼 수 없는 경우 원격 서버는 자동으로 Adobe Campaign에 오류 메시지를 보냅니다. 이 오류는 이메일 주소, 전화 번호 또는 장치를 격리해야 하는지 여부를 결정할 수 있습니다. 바운스 메일 관리를 참조하세요.
메시지가 전송되면 게재 로그에서 각 프로필에 대한 게재 상태 및 관련 실패 유형과 이유를 확인할 수 있습니다.
차단 목록에 추가하다 이메일 주소가 격리되거나 프로필이 게재 중인 경우, 수신자는 게재 준비 단계에서 제외됩니다. 제외된 메시지는 게재 대시보드에 나열됩니다.
메시지 게재가 실패한 이유 delivery-failure-reasons
메시지가 실패하는 경우 두 가지 유형의 오류가 있습니다. 각 게재 실패 유형에 따라 주소가 격리(으)로 전송되는지 여부가 결정됩니다.
-
하드 바운스
하드 바운스는 ISP가 전달할 수 없는 구독자 주소에 대한 메일링 시도를 결정한 후 생성된 영구적인 실패입니다. Adobe Campaign 내에서 하드 바운스는 전달할 수 없는 것으로 분류되어 격리 목록에 추가되므로 다시 시도하지 않습니다. 실패 원인을 알 수 없는 경우 하드 바운스가 무시되는 경우가 있습니다.하드 바운스의 일반적인 예는 다음과 같습니다. 주소가 존재하지 않음, 계정이 비활성화됨, 잘못된 구문, 잘못된 도메인
-
소프트 바운스
소프트 바운스는 ISP가 메일을 전달하기 어려울 때 생성하는 일시적인 실패입니다. 소프트 실패는 성공적인 전달을 시도하기 위해 다시 시도합니다(사용자 지정 또는 기본 전달 설정의 사용에 따라 달라짐). 소프트 바운스가 지속적인 주소는 최대 다시 시도 횟수가 시도될 때까지(설정에 따라 다시 달라짐) 격리에 추가되지 않습니다.소프트 바운스의 몇 가지 일반적인 원인은 다음과 같습니다. 사서함 가득 참, 이메일 서버 작동 중지 수신, 보낸 사람 신뢰도 문제
무시됨 유형의 오류는 "부재 중"과 같은 일시적인 오류이거나 예를 들어 발신자 유형이 "postmaster"인 경우와 같은 기술적인 오류로 알려져 있습니다.
피드백 루프는 바운스 이메일과 같이 작동합니다. 사용자가 이메일을 스팸 처리하면 Adobe Campaign에서 이메일 규칙을 구성하여 이 사용자에게 전달되는 모든 것을 차단할 수 있습니다. 이러한 사용자의 주소는 구독 취소 링크를 클릭하지 않았더라도 차단 목록에 추가된으로 제공됩니다. 주소는 Denylisted 상태의 (NmsRecipient) 받는 사람 테이블이 아니라 (NmsAddress) 격리 테이블에 추가됩니다. Adobe 전달성 모범 사례 안내서에서 피드백 루프 메커니즘에 대해 자세히 알아보세요.
동기 및 비동기 오류 synchronous-and-asynchronous-errors
메시지 게재가 즉시 실패할 수 있으며, 이 경우 동기 오류로 간주됩니다. 메시지를 보낸 후 나중에 메시지를 보내지 못하는 경우 오류는 비동기적으로 발생합니다.
이러한 유형의 오류는 다음과 같이 관리됩니다.
-
동기 오류: Adobe Campaign 게재 서버가 접속한 원격 서버에서 즉시 오류 메시지를 반환합니다. 프로필 서버로 게재를 보낼 수 없습니다. MTA(메일 전송 에이전트)는 반송 유형을 결정하고 오류를 검증하며, 관련 이메일 주소를 격리해야 하는지 여부를 결정하기 위해 해당 정보를 Campaign으로 다시 보냅니다. 반송 메일 조건을 참조하십시오.
-
비동기 오류: 반송 메일 또는 SR이 나중에 수신 서버에 의해 다시 전송됩니다. 이 오류는 오류와 관련된 레이블로 확인됩니다. 게재를 보낸 후 1주일까지 비동기 오류가 발생할 수 있습니다.
반송 메일 조건 bounce-mail-qualification
Adobe Campaign에서 바운스 메일 자격이 처리되는 방식은 오류 유형에 따라 다릅니다.
-
동기 오류: MTA가 바운스 유형 및 자격을 결정하고 해당 정보를 Campaign으로 다시 보냅니다. Delivery log qualification 테이블의 반송 조건은 동기 게재 실패 오류 메시지에 사용되지 않습니다.
-
비동기 오류: Campaign에서 비동기 게재 실패를 확인하기 위해 사용하는 규칙이 Administration > Campaign Management > Non deliverables Management > Delivery log qualification 노드에 나열됩니다. 비동기 바운스는 Inbound email 규칙을 통해 inMail 프로세스에 의해 검증됩니다. 자세한 내용은 Adobe Campaign Classic v7 설명서를 참조하세요.
관리 다시 시도 retries
일시적인 오류(소프트 또는 무시됨) 후 메시지 배달이 실패하면 Campaign에서 전송을 다시 시도합니다. 이러한 재시도는 게재 기간이 끝날 때까지 수행할 수 있습니다.
소프트 바운스 재시도 및 재시도 간 시간은 메시지 이메일 도메인에서 돌아오는 바운스 응답의 유형 및 심각도에 따라 MTA에 의해 결정됩니다.
유효 기간 valid-period
Campaign 게재의 유효 기간 설정이 3.5일 이하(으)로 제한됩니다. 게재의 경우 Campaign에서 3.5일보다 큰 값을 정의하면 고려되지 않습니다.
예를 들어 Campaign에서 유효 기간을 기본값 5일로 설정하면 소프트 바운싱 메시지는 MTA 다시 시도 대기열로 이동하며 해당 메시지가 MTA에 도달한 시점부터 최대 3.5일 동안만 다시 시도됩니다. 이 경우 Campaign에 설정된 값은 사용되지 않습니다.
메시지가 3.5일 동안 MTA 큐에 있고 배달하지 못하면 시간이 초과되고 게재 로그에서 Sent 에서 Failed(으)로 상태가 업데이트됩니다.
유효 기간에 대한 자세한 내용은 Adobe Campaign Classic v7 설명서를 참조하십시오.
이메일 오류 유형 email-error-types
이메일 채널에 대해 게재 실패의 가능한 이유는 아래에 나와 있습니다.
푸시 알림 오류 유형 push-error-types
모바일 앱 채널의 경우 게재 실패의 가능한 이유가 아래에 나와 있습니다.
iOS 격리 ios-quarantine
HTTP/V2 프로토콜을 통해 각 푸시 게재에 대한 직접 피드백 및 상태를 사용할 수 있습니다. HTTP/V2 프로토콜 커넥터를 사용하는 경우 mobileAppOptOutMgt 워크플로우에서 더 이상 피드백 서비스를 호출하지 않습니다. 모바일 애플리케이션을 제거하거나 다시 설치하면 토큰이 등록 취소된 것으로 간주됩니다.
동기적으로 APNs가 메시지에 대해 "등록되지 않음" 상태를 반환하면 대상 토큰이 즉시 격리됩니다.
Android 격리 android-quarantine
Android V1용
각 알림에 대해 Adobe Campaign은 FCM 서버로부터 직접 동기 오류를 수신합니다. Adobe Campaign은 즉시 오류를 처리하고 오류의 심각도에 따라 하드 또는 소프트 오류를 생성하며 재시도를 수행할 수 있습니다.
- 페이로드 길이 초과, 연결 문제, 서비스 가용성 문제: 다시 시도, 소프트 오류, 실패 이유는 Refused 입니다.
- 장치 할당량 초과: 다시 시도 없음, 소프트 오류, 실패 이유는 Refused 입니다.
- 토큰이 잘못되었거나 등록되지 않았습니다. 예기치 않은 오류, 보낸 사람 계정 문제: 다시 시도 안 함, 하드 오류, 실패 이유는 Refused 입니다.
mobileAppOptOutMgt 워크플로는 6시간마다 실행되어 AppSubscriptionRcp 테이블을 업데이트합니다. 등록이 취소되었거나 더 이상 유효하지 않다고 선언된 토큰의 경우 필드 Disabled 이(가) True(으)로 설정되고 해당 장치 토큰에 연결된 구독은 향후 게재에서 자동으로 제외됩니다.
게재 분석 중에 대상에서 제외된 모든 장치가 excludeLogAppSubRcp 테이블에 자동으로 추가됩니다.
- 게재 시작 시 연결 문제: 실패 유형 Undefined, 실패 이유 Unreachable, 다시 시도됩니다.
- 게재 중 연결이 끊어졌습니다. 소프트 오류, 실패 이유 Refused, 다시 시도합니다.
- 보내는 동안 Baidu에서 동기 오류를 반환했습니다. 하드 오류, 오류 원인 Refused, 다시 시도하지 않습니다.
Android V2용
Android V2 격리 메커니즘은 Android V1과 동일한 프로세스를 사용하므로 구독 및 제외 업데이트에도 동일하게 적용됩니다. 자세한 내용은 Android V1 섹션을 참조하세요.
SMS 격리 sms-quarantines
표준 커넥터용
SMS 채널에 대한 특성은 아래에 나와 있습니다.
확장된 일반 SMPP 커넥터의 경우
SMPP 프로토콜을 사용하여 SMS 메시지를 전송하는 경우 오류 관리가 다르게 처리됩니다.
SMPP 커넥터는 정규 표현식(정규 표현식)을 사용하여 반환되는 SR(상태 보고서) 메시지에서 데이터를 검색하여 해당 콘텐츠를 필터링합니다. 그런 다음 이 데이터는 Delivery log qualification 테이블에 있는 정보와 일치합니다(Administration > Campaign Management > Non deliverables Management 메뉴를 통해 사용 가능).
새로운 유형의 오류가 검증되기 전에 기본적으로 실패 이유는 항상 거부됨(으)로 설정됩니다.
생성된 메시지의 예:
SR Generic DELIVRD 000|#MESSAGE#
-
모든 오류 메시지는 SMS 오류 코드와 전자 메일 오류 코드를 구별하기 위해 SR(으)로 시작합니다.
-
오류 메시지의 두 번째 부분(이 예제의 경우 일반)은 SMS 외부 계정의 SMSC implementation name 필드에 정의된 것과 같은 SMSC 구현의 이름을 참조합니다.
동일한 오류 코드는 각 공급자에 대해 다른 의미를 가질 수 있으므로 이 필드를 사용하면 오류 코드를 생성한 공급자를 알 수 있습니다. 그런 다음 관련 공급자의 설명서에서 오류를 찾을 수 있습니다.
-
오류 메시지의 세 번째 부분(이 예에서는 DELIVRD)은 SMS 외부 계정에 정의된 상태 추출 정규식을 사용하여 SR에서 검색한 상태 코드에 해당합니다.
이 정규식은 외부 계정의 SMSC specificities 탭에 지정됩니다.
기본적으로 정규 표현식은 SMPP 3.4 사양 의 부록 B 섹션에서 정의한 stat: 필드를 추출합니다. -
오류 메시지의 네 번째 부분(000)은 SMS 외부 계정에 정의된 오류 코드 추출 정규식을 사용하여 SR에서 추출된 오류 코드에 해당합니다.
이 정규식은 외부 계정의 SMSC specificities 탭에 지정됩니다.
기본적으로 정규 표현식은 SMPP 3.4 사양 의 부록 B 섹션에서 정의한 err: 필드를 추출합니다.
-
파이프 기호(|) 뒤에 오는 모든 항목은 Delivery log qualification 테이블의 First text 열에만 표시됩니다. 메시지가 표준화된 후 이 콘텐츠는 항상 #MESSAGE#(으)로 바뀝니다. 이 프로세스는 유사한 오류에 대해 여러 항목을 포함하지 않으며 이메일과 동일합니다.
확장된 일반 SMPP 커넥터는 추론을 적용하여 합리적인 기본값을 찾습니다. 상태가 DELIV 로 시작하는 경우 대부분의 공급자가 사용하는 일반적인 상태 DELIVRD 또는 DELIVERED 와(과) 일치하므로 성공한 것으로 간주됩니다. 그 밖의 어떤 상황도 하드 장애로 이어집니다.