데이터 모델 모범 사례

이 문서에서는 Adobe Campaign 데이터 모델을 디자인하는 동안 주요 권장 사항에 대해 설명합니다.

Adobe Campaign 시스템은 매우 유연하며 초기 구현 이상으로 확장할 수 있습니다. 그러나 가능성은 무한하지만 현명한 결정을 내리고 데이터 모델 디자인을 시작할 강력한 기반을 구축하는 것이 중요합니다.

Campaign 기본 제공 표와 이들이 상호 작용하는 방법을 보다 잘 이해하려면 다음을 참조하십시오 이 섹션 .

읽기 이 섹션 campaign 스키마를 시작하려면 다음을 수행하십시오.

에서 Adobe Campaign 데이터베이스의 개념적 데이터 모델을 확장하기 위해 확장 스키마를 구성하는 방법을 알아보십시오 이 페이지.

데이터 모델 아키텍처

Adobe Campaign은 개인화된 고객 경험을 구축하기 위해 온라인 및 오프라인 전략을 연계할 수 있는 강력한 크로스채널 캠페인 관리 시스템입니다.

고객 중심 접근 방식

대부분의 이메일 서비스 공급업체는 목록 중심의 접근 방식을 통해 고객에게 커뮤니케이션하고 있지만 Adobe Campaign은 고객과 해당 특성에 대한 광범위한 보기를 활용하기 위해 관계형 데이터베이스를 사용합니다.

각 테이블의 설명에 액세스하려면 다음 위치로 이동하십시오. Admin > Configuration > Data schemas​를 클릭하고 목록에서 리소스를 선택한 다음 Documentation 탭.

노트

Adobe Campaign에서 사용자 지정 수신자 테이블. 그러나 대부분의 경우 기본 제공 기능을 활용하는 것이 좋습니다 수신자 테이블 에는 이미 추가 테이블 및 기능이 사전 빌드되어 있습니다.

Adobe Campaign 데이터

Adobe Campaign으로 어떤 데이터를 전송해야 합니까? 마케팅 활동에 필요한 데이터를 파악하는 것이 중요합니다.

노트

Adobe Campaign은 데이터 웨어하우스나 보고 도구가 아닙니다. 따라서 가능한 모든 고객 및 관련 정보를 Adobe Campaign으로 가져오거나 보고서를 작성하는 데만 사용할 데이터를 가져오려고 하지 마십시오.

Adobe Campaign에서 속성을 필요로 하는지 여부를 결정하려면 속성이 다음 카테고리 중 하나에 속하는지 자신에게 문의하십시오.

  • 에 사용된 속성 세분화
  • 에 사용된 속성 데이터 관리 프로세스 (예를 들어 집계 계산)
  • 에 사용된 속성 개인화

이러한 속성에 속하지 않는 경우 Adobe Campaign에서 이 속성이 필요하지 않을 수 있습니다.

데이터 유형 선택

시스템의 우수한 아키텍처와 성능을 보장하기 위해 아래 모범 사례에 따라 Adobe Campaign에서 데이터를 설정하십시오.

  • 큰 테이블 내에서 문자열 또는 숫자 필드를 삽입하고 참조 테이블에 링크를 추가할 수 있습니다(값 목록 작업 시).
  • 다음 expr 속성을 사용하면 스키마 속성을 테이블의 물리적 세트 값이 아닌 계산된 필드로 정의할 수 있습니다. 이렇게 하면 두 값을 모두 저장하지 않고 다른 형식(예: 연령 및 생년월일)으로 정보에 액세스할 수 있습니다. 이는 필드가 중복되지 않도록 하는 좋은 방법입니다. 예를 들어 수신자 테이블은 전자 메일 필드에 이미 있는 도메인에 대한 표현식을 사용합니다.
  • 그러나 표현식 계산이 복잡하면 expr 속성을 즉시 계산하면 쿼리의 성능에 영향을 줄 수 있습니다.
  • 다음 XML 유형은 너무 많은 필드를 만들지 않는 좋은 방법입니다. 그러나 데이터베이스의 CLOB 열을 사용하여 디스크 공간을 확보합니다. 또한 복잡한 SQL 쿼리를 생성하고 성능에 영향을 줄 수 있습니다.
  • 길이 string 필드는 항상 열을 사용하여 정의해야 합니다. 기본적으로 Adobe Campaign의 최대 길이는 16K이지만, 크기가 더 짧은 길이를 초과하지 않는다는 것을 이미 알고 있는 경우 필드를 더 짧게 유지하는 것이 좋습니다.
  • 소스 시스템의 크기가 과대평가되어 도달하지 않을 것으로 확신하는 경우 Adobe Campaign에서 소스 시스템보다 짧은 필드를 포함할 수 있습니다. 이는 Adobe Campaign에서 더 짧은 문자열 또는 더 작은 정수를 의미할 수 있습니다.

필드 선택

타겟팅 또는 개인화 목적이 있는 경우 필드에 저장해야 합니다. 즉, 필드를 사용하여 개인화된 이메일을 전송하지 않거나 쿼리의 조건으로 사용하지 않으면 디스크 공간을 불필요하게 차지합니다.

키 선택

추가 autouid자동 대부분의 테이블에 기본적으로 정의된 논리 또는 비즈니스 키(계정 번호, 클라이언트 번호 등)를 추가하는 것이 좋습니다. 나중에 가져오기/조정 또는 데이터 패키지에 사용할 수 있습니다. 자세한 내용은 식별자.

효율적인 키는 성능에 필수입니다. Snowflake을 사용하여 숫자 또는 문자열 기반 데이터 유형을 표의 키로 삽입할 수 있습니다.

식별자

Adobe Campaign 리소스에는 세 개의 식별자가 있으며 추가 식별자를 추가할 수 있습니다.

다음 표에서는 이 식별자와 그 목적을 설명합니다.

식별자 설명 모범 사례
Id
  • id는 Adobe Campaign 테이블의 실제 기본 키입니다. 기본 제공 테이블의 경우 UUID(Universally Unique ID)입니다
  • 이 식별자는 고유해야 합니다.
  • UUID는 스키마 정의에 표시될 수 있습니다.
  • 자동 생성된 식별자는 워크플로우 또는 패키지 정의에서 참조로 사용할 수 없습니다.
  • 테이블의 ID는 UUID이므로 이 유형을 변경할 수 없습니다.
이름(또는 내부 이름)
  • 이 정보는 테이블의 레코드의 고유 식별자입니다. 이 값은 일반적으로 생성된 이름으로 수동으로 업데이트할 수 있습니다.
  • 이 식별자는 Adobe Campaign의 다른 인스턴스에 배포할 때 값을 유지하며 비워 둘 수 없습니다.
  • 객체가 환경에서 다른 환경으로 배포하려는 경우 Adobe Campaign에서 생성한 레코드 이름의 이름을 변경합니다.
  • 개체에 네임스페이스 특성(스키마 예를 들어) 이 공통 네임스페이스는 생성된 모든 사용자 지정 개체에서 활용됩니다. 일부 예약된 네임스페이스는 사용하지 않아야 합니다. nms, xtk​등 일부 네임스페이스는 내부용입니다. 자세히 알아보기
  • 개체에 네임스페이스가 없는 경우(워크플로우 또는 게재 예를 들어) 이 네임스페이스 개념은 내부 이름 개체의 접두사로 추가됩니다. namespaceMyObjectName.
  • 공백 "", 세미열 ":" 또는 하이픈 "-"과 같은 특수 문자는 사용하지 마십시오. 이러한 모든 문자는 밑줄 "_"(허용되는 문자)로 바뀝니다. 예를 들어 "abc-def" 및 "abc:def"는 "abc_def"로 저장되고 서로 덮어씁니다.
레이블
  • 레이블은 Adobe Campaign에 있는 개체 또는 레코드의 비즈니스 식별자입니다.
  • 이 개체에는 공백 및 특수 문자가 허용됩니다.
  • 그것은 레코드의 고유성을 보장하지 않습니다.
  • 개체 레이블의 구조를 결정하는 것이 좋습니다.
  • Adobe Campaign 사용자의 레코드 또는 개체를 식별하는 데 가장 사용자 친화적인 솔루션입니다.

Adobe Campaign 기본 키는 모든 기본 테이블에 대해 자동 생성된 UUID입니다. 사용자 지정 테이블에 UUID를 사용할 수도 있습니다. 자세히 알아보기

ID 수가 무한하더라도 최적의 성능을 보장하기 위해 데이터베이스 크기를 관리해야 합니다. 문제를 방지하려면 인스턴스 제거 설정을 조정해야 합니다. 자세한 내용은 이 섹션을 참조하십시오.

사용자 지정 내부 키

기본 키는 Adobe Campaign에서 만든 모든 테이블에 필요합니다.

대부분의 조직은 외부 시스템에서 레코드를 가져옵니다. 수신자 테이블의 실제 키는 "id" 속성이지만 사용자 지정 키도 결정할 수 있습니다.

이 사용자 지정 키는 Adobe Campaign을 제공하는 외부 시스템의 실제 레코드 기본 키입니다.

사용자 지정 테이블을 생성할 때 두 가지 옵션이 있습니다.

  • 자동 생성된 키(id)와 내부 키(사용자 지정)의 조합입니다. 시스템 키가 정수가 아니거나 복합 키인 경우 이 옵션이 흥미롭습니다. Snowflake을 사용하면 정수 또는 문자열 기반 키가 큰 테이블에서 더 높은 성능을 제공하고 다른 테이블과 연결합니다.
  • 기본 키를 외부 시스템 기본 키로 사용. 일반적으로 이 솔루션은 서로 다른 시스템 간에 일관된 키를 사용하여 데이터를 가져오고 내보내는 방법을 간소화하므로 선호됩니다. Autuuid 키 이름이 "id"이고 외부 값으로 채워야 하는 경우(자동 생성되지 않음) 비활성화해야 합니다.
주의

워크플로우에서 autouid를 참조로 사용해서는 안 됩니다.

큰 테이블에 있는 "자체" 무결성을 주의하십시오. "자체" 무결성에 큰 테이블이 있는 레코드를 삭제하면 인스턴스가 중지될 수 있습니다. 테이블이 잠겼고, 한 테이블씩 삭제한다. 따라서 용량이 큰 하위 테이블에서 "중립" 무결성을 사용하는 것이 가장 좋습니다.

링크를 외부 조인으로 선언하는 것은 성능에 좋지 않습니다. 0ID 레코드는 외부 조인 기능을 에뮬레이션합니다. 링크가 autouid.

워크플로우에서 테이블을 조인할 수 있지만 Adobe은 데이터 구조 정의에서 직접 리소스 간의 공통 링크를 정의하는 것을 권장합니다.

링크는 표의 실제 데이터와 일치하도록 정의해야 합니다. 잘못된 정의는 링크를 통해 검색된 데이터에 영향을 줄 수 있습니다(예: 예기치 않게 레코드를 복제하는 경우).

링크의 이름을 테이블 이름으로 일관되게 지정합니다. 링크 이름은 떨어진 테이블이 무엇인지 이해하는 데 도움이 됩니다.

"id"가 있는 링크의 이름을 접미사로 지정하지 마십시오. 예를 들어 이름을 "transactionId"가 아닌 "transaction"로 지정합니다.

기본적으로 Adobe Campaign에서는 외부 테이블의 기본 키를 사용하여 링크를 만듭니다. 보다 명확하게 하기 위해 링크 정의에서 연결을 명시적으로 정의하는 것이 좋습니다.

카디널리티

링크를 디자인할 때 1-1 관계를 선언할 때 대상 레코드가 고유한지 확인합니다. 그렇지 않으면 한 레코드만 예상되면 조인이 여러 레코드를 반환할 수 있습니다. 이렇게 하면 "쿼리에서 예상보다 많은 행을 반환"할 때 게재를 준비하는 동안 오류가 발생합니다. 링크 이름을 대상 스키마와 동일한 이름으로 설정합니다.

(1) 쪽의 스키마에 카디널리티(1-N)가 있는 링크를 정의합니다. 예를 들어, 관계 수신자 (1) - (N) 트랜잭션은 트랜잭션 스키마에 정의되어 있어야 합니다.

링크의 역방향 카디널리티는 기본적으로 (N)입니다. 링크 정의에 revCardinality='single' 속성을 추가하여 링크(1-1)를 정의할 수 있습니다.

사용자가 역방향 링크를 볼 수 없으면 링크 정의 revLink='로 숨길 수 있습니다​없음' 예를 들어 완료된 마지막 트랜잭션과 수신자의 링크를 정의하는 것이 좋습니다. 수신자로부터 마지막 트랜잭션으로의 링크만 볼 수 있고, 트랜잭션 테이블에서 역방향 링크는 볼 필요가 없습니다.

외부 조인(1-0.1)을 수행하는 링크는 시스템 성능에 영향을 주므로 주의해서 사용해야 합니다.

데이터 유지

Adobe Campaign은 데이터 웨어하우스나 보고 도구가 아닙니다. 따라서 Adobe Campaign 솔루션의 성능을 향상시키기 위해 데이터베이스 증가가 계속 제어되어야 합니다. 이를 위해 아래 모범 사례 중 일부를 따르는 것이 도움이 될 수 있습니다.

보존과 관련하여 Campaign의 기본 로그인 로그 테이블에는 사전 설정된 보존 기간이 있으며 일반적으로 데이터 저장소를 6개월 이내로 제한합니다.

기본 제공 테이블에 대한 기본 보존 값은 다음과 같습니다. 보존 구성은 구현 중에 Adobe 기술 관리자가 설정하며 고객 요구 사항에 따라 각 구현마다 값이 달라질 수 있습니다.

  • 통합 추적: 1년
  • 게재 로그: 6개월
  • 추적 로그: 1년
  • 삭제된 게재: 1주
  • 가져오기 거부: 6개월
  • 방문자 프로필: 1개월
  • 오퍼 제안: 1년
  • 이벤트: 1개월
  • 이벤트 처리 통계: 1개월
  • 보관된 이벤트: 1년
  • 파이프라인 이벤트 무시: 1개월
주의

사용자 지정 테이블은 표준 정리 프로세스로 삭제되지 않습니다. 첫 번째 날에는 이러한 작업이 필요하지 않지만, 사용자 지정 테이블에 대한 제거 프로세스를 만드는 것을 잊지 마십시오. 이 경우 성능 문제가 발생할 수 있습니다.

Adobe Campaign에는 다음과 같은 몇 가지 해결 방법이 있어 레코드 필요성을 최소화할 수 있습니다.

  • Adobe Campaign 외부의 데이터 웨어하우스에서 데이터를 내보냅니다.
  • 마케팅 관행에 충분하면서 더 적은 공간을 사용하는 집계된 값을 생성합니다. 예를 들어 마지막 구매를 추적하기 위해 Adobe Campaign에 전체 고객 거래 기록이 필요하지 않습니다.

스키마에서 "deleteStatus" 속성을 선언할 수 있습니다. 레코드를 삭제로 표시한 다음 정리 작업에서 삭제를 연기하는 것이 더 효율적입니다.

관리 Cloud Services 사용자는 Adobe 컨설턴트나 기술 관리자에게 연락하여 보존에 대한 자세한 내용을 확인하거나 사용자 지정 테이블에 대한 보존을 설정해야 합니다.

성능

언제든지 더 나은 성능을 보장하려면 아래 모범 사례를 따르십시오.

일반 권장 사항

  • 쿼리에 "CONTAINS"와 같은 작업을 사용하지 마십시오. 의 예상 내용을 알고 있고 을 필터링하려는 경우 "EQUAL TO" 또는 기타 특정 필터 연산자와 동일한 조건을 적용합니다.
  • 가져오기 및 내보내기와 같은 프로세스가 업무 시간에 발생하는지 확인하십시오.
  • 모든 일별 활동에 대한 일정이 있는지 확인하고 일정대로 하세요.
  • 일별 프로세스 중 하나 또는 일부가 실패하여 같은 날에 실행해야 하는 경우 시스템 성능에 영향을 줄 수 있으므로 수동 프로세스를 시작할 때 실행 중인 충돌하는 프로세스가 없는지 확인합니다.
  • 가져오기 프로세스 또는 수동 프로세스가 실행되는 동안 일별 캠페인이 실행되지 않도록 하십시오.
  • 모든 행에 필드를 복제하지 않고 하나 또는 여러 개의 참조 테이블을 사용합니다. 키/값 쌍을 사용할 때는 숫자 키를 선택하는 것이 좋습니다.
  • 짧은 문자열을 사용할 수 있습니다. 외부 시스템에서 참조 테이블이 이미 있는 경우 이를 다시 사용하면 Adobe Campaign과의 데이터 통합이 용이해집니다.

일대다 관계

  • 데이터 디자인은 유용성과 기능에 영향을 줍니다. 일대다 관계가 많은 데이터 모델을 디자인하는 경우 사용자가 애플리케이션에서 의미 있는 논리를 구성하는 것이 더 어렵습니다. 일대다 필터 로직은 기술 전문가가 아닌 마케터가 올바르게 작성하고 이해하는 데 어려울 수 있습니다.
  • 사용자가 쿼리를 쉽게 작성할 수 있으므로 한 테이블에 모든 필수 필드를 포함하는 것이 좋습니다. 조인을 방지할 수 있는 경우 테이블 간에 일부 필드를 복제하는 것이 좋은 경우가 있습니다.
  • 특정 기본 제공 기능에서는 일대다 관계(예: 오퍼 가중치 공식 및 게재)를 참조할 수 없습니다.

큰 테이블

Adobe Campaign은 타사 데이터베이스 엔진을 사용합니다. 공급자에 따라 더 큰 테이블을 위해 성능을 최적화하려면 특정 디자인이 필요할 수 있습니다.

다음은 큰 테이블과 복잡한 조인을 사용하여 데이터 모델을 디자인할 때 따라야 하는 몇 가지 일반적인 모범 사례입니다.

  • 추가 사용자 지정 수신자 테이블을 사용할 때는 각 게재 매핑에 대한 전용 로그 테이블이 있는지 확인합니다.
  • 특히 사용하지 않는 열을 식별하여 열 수를 줄입니다.
  • 여러 조건 및/또는 여러 열에 대한 조인과 같은 복잡한 조인을 방지하여 데이터 모델 관계를 최적화합니다.
  • 조인 키의 경우 숫자 또는 문자열 기반 값을 사용할 수 있습니다.
  • 로그 보존 깊이를 최대한 줄입니다. 더 깊은 기록이 필요한 경우 계산 및/또는 사용자 지정 로그 테이블을 처리하여 더 큰 내역을 저장할 수 있습니다.

표 크기

테이블 크기는 레코드 수와 레코드당 열 수의 조합입니다. 둘 다 쿼리 성능에 영향을 줄 수 있습니다.

  • A 작은 크기 테이블은 배달 테이블과 유사합니다.
  • A 중간 크기 표는 수신자 테이블의 크기와 동일합니다. 고객당 한 번의 기록을 가지고 있습니다.
  • A 대형 테이블은 Broad 로그 테이블과 유사합니다. 고객당 많은 레코드가 있습니다.
    예를 들어 데이터베이스에 1,000만 명의 수신자가 포함되어 있는 경우 Broad 로그 테이블에는 약 100개~2억 개의 메시지가 포함되며 Delivery 테이블에는 수천 개의 레코드가 포함됩니다.

행 수는 성능에도 영향을 줍니다. Adobe Campaign 데이터베이스는 타깃팅 또는 개인화 목적으로 활발히 사용되지 않는 이전 데이터를 저장하도록 설계되지 않았습니다. 이것은 운영 데이터베이스입니다.

많은 수의 행과 관련된 성능 문제를 방지하려면 데이터베이스에 필요한 레코드만 유지합니다. 다른 모든 레코드는 타사 데이터 웨어하우스로 내보내고 Adobe Campaign 운영 데이터베이스에서 제거해야 합니다.

다음은 표 크기와 관련된 몇 가지 우수 사례입니다.

  • 필드 수가 적고 숫자 데이터가 많은 큰 테이블을 디자인합니다.
  • 부울 값과 같은 작은 숫자를 저장하는 데 큰 유형의 열을 사용하지 마십시오.
  • 테이블 정의에서 사용되지 않은 열을 제거합니다.
  • Adobe Campaign 데이터베이스에 내역 또는 비활성 데이터를 유지하지 마십시오(내보내기 및 정리).

이 페이지에서는