e채널 활용한 관계기반 마케팅 수행

김이평/아이마스 전략기획팀장

지난 회까지 ‘커뮤니케이션 히스토리(Communication History)에 기반한 eCRM 접근’ 사상에 대해 설명했다. 이번 호에는 이러한 사상에 기반을 둔 eCRM 프로젝트 수행때 반드시 필요한 시스템적 접근방안에 대해 알아본다.

분석지표: 데이터 모델링

eCRM을 위한 첫번째 단계인 고객의 정의와 고객 세분화 정의를 통해 거시적 마케팅 지표를 확보한다. 일반적으로 고객 세분화 지표는 다양한 각도에서 디자인되는데 다기준 스코어링 기반의 고객 등급화(CV-고객가치 모형, LTV모형 등)와 인구통계학적 데이터에 기반한 라이프 스타일의 정의, 고객의 이해를 바탕으로 하는 고객거래목적기반 세분화 등 여러 각도의 고객 세분화가 이뤄진다.

이러한 고객 세분화를 위한 원천데이터(Source Data)가 어느 위치에 존재하는가가 프로젝트의 규모를 결정하게 되는데 기존 운영계와 같은 레거시(Legacy)에 존재하는지 혹은 이미 구축된 데이터웨어하우스에 존재하는지 등의 여부가 전체적인 프로젝트 수행비용과 기간을 결정하는 중요한 변수가 된다. 어떤 경우이든 원천데이터를 우리가 원하는 로컬시스템에 이관해 우리의 목적에 맞는 지표를 생성해야 한다. 이때 필요한 것이 마케팅 마트(Marketing Mart)를 디자인하는 기술과 이에 맞는 원천데이터를 발견해 타겟데이터(Target Data)를 정의하고 데이터를 추출(Extraction)해 정제(Trans-formation), 적재(Loading)하는 기술이다.

우선 마케팅 마트를 구축하기 위해 논리 모델링 단계에서 정보요건을 바탕으로 데이터를 모델링해야 하는데 여기서 주의할 사항은 다음과 같다.

▲논리 모델링 단계

여러 부분에서 공유되는 엔티티 타입(Entity Type)을 ‘공유 엔티티 타입’이라고 하는데 고객이나 주문 등이 이에 해당된다. 이러한 공유 엔티티 타입은 전체적인 데이터 모델링 단계에서 매우 중요한 역할을 담당하기 때문에 모델링 초기 단계부터 정의돼야 하며 어떤 정보를 어떤 형식으로 관리할 것인가에 대한 자세한 정의가 요구된다. 정보의 중복성을 최소화 하지 못하거나 체계적인 관리체계 부재로 인해 야기될 수 있는 정보조회의 저효율화를 방지하기 위한 중요한 정의 요소이다.

논리 모델링시에 자주 접하게 되는 문제가 엔티티 타입을 통합할 것인지 분리할 것인지에 대한 의사결정이다. 이러한 엔티티 타입 통합 및 분리는 방식별로 각각 장점과 단점이 존재한다. 엔티티 타입의 통합 시에는 종합적인 정보의 집계나 분석이 용이하며 정보자원의 관리가 용이하고 업무규칙을 단순화해 관리할 수 있는 장점이 있지만 여러 엔티티 타입이 통합돼 있어서 해당업무 및 정보에 대한 광범위한 이해가 수반돼야 정보관리가 가능한 어려움도 있다. 또한 통합 엔티티 타입의 비대함으로 인해 관리가 불편하고 일부 정보만을 도출할 경우 매우 불편하다.

다음은 집계정보에 대한 내용인데 집계된 정보의 조회요구가 빈번한 경우에는 집계된 정보의 형태도 모델링의 대상이 된다. 특히 원천 데이터의 분량이 많아 주기적인 집계과정 없이 정보의 조회가 불가능한 경우에는 반드시 집계정보 엔티티 타입을 추가해 관리해야 한다.

시계열에 대한 준비도 필요한데 이는 정보를 조회하는 경우 특정기간의 변화추이를 조회하는 작업이 빈번히 발생하기 때문이다. 시계열정보를 효과적으로 관리하기 위해서는 해당정보의 변경 히스토리 뿐만 아니라 관련 정보의 변경 히스토리도 함께 관리할 필요가 있다. 따라서 모든 엔티티 타입에 대해 시계열 정보의 필요성 여부를 검증해야 하며 집계된 정보의 경우 시계열의 간격에 대한 구체적인 고려가 필요하다.

모델링시 자주 접하게 되는 대표적인 문제 중에 하나가 정보의 상세정도이다. 분석용 DB에서는 기간계와 같이 상세한 정보를 모두 보관한다는 것이 불가능하다. 이유는 여러 가지가 있는데 우선 디스크 여유의 문제이다. 기간계가 현 상태의 정보만을 관리하는 반면 분석용 DB는 시계열 정보를 관리하기 때문에 상당한 디스크 용량을 필요로 한다. 또한 정보의 분량이 많을 경우 조회 성능이 떨어질 수밖에 없기 때문에 정보의 상세화 정도를 잘 가름해 모델링해야 한다. 이러한 문제를 해결하기 위해 보편적으로 상세한 정보에 대한 조회요건이 빈번히 발생하지 않다는 점과 있다 하더라도 대게 최신 정보에 대해서만 발생하는 경향을 이용해 상세정보에 대한 보관 주기를 최소화하고, 이후에는 집계형태로 관리해 디스크 용량을 줄이고 조회성능을 향상시키는 방법을 사용한다.

▲물리 모델링 단계

논리 모델링은 DB가 구현되는 시스템이나 DBMS의 환경을 고려하지 않거나 수행처리속도를 고려하지 않는 상황에서 디자인된다. 주로 DB의 구조를 합리화하는 목적으로만 디자인되기 때문에 실제 상황에서는 처리 속도 문제가 큰 문제로 부상하게 된다. 주어진 환경을 바탕으로 데이터 처리 속도가 최적화 되도록 논리 모델을 수정하는 작업이 물리 모델링 단계이다.

이러한 문제를 해결하기 위해서 DBMS 전문가와 함께 가상의 데이터를 입출력 해보는 등의 성능 테스트를 다각도로 진행해 최적의 데이터 모델로 가다듬어 가는 작업이 필수적이다

데이터 운영: 데이터 추출, 정제, 적재

데이터 모델링을 통해 고객분석 지표의 틀이 완성되면 구체적인 분석로직을 작성해 이에 필요한 데이터를 발견하고 정제하여 분석용 저장 장소에 적재한다. 데이터 모델링 단계가 끝나고 나면 실질적인 데이터 적재가 수행돼야 한다. 이때 여러가지 프로세스상의 복잡성과 데이터 정합성 등의 문제점들을 예상할 수 있는데 이러한 데이터 추출, 정제, 적재 프로세스상의 자동화를 실현시키는 도구가 ETT이다. ETT가 하는 역할을 간단히 살펴보자.

추출하고자 하는 소스 데이터와 타겟 데이터의 구성요소 등을 정의한다. 이것은 소스 테이터의 정의와 함께 소스 데이터의 위치와 테이블, 컬럼 등을 정의하고 타겟 데이터의 주제별 정의와 상세 테이블 정의를 수반한다. 이때 각 테이블간의 매핑방법(1:N, 1:1)과 데이터의 정제 및 변경 방법에 대해서도 정의한다.

이같은 매핑 방법은 소스 테이블과 타겟 테이블간의 관계설정에 기인하며 데이터를 추출, 정제하는 단계에서 중요한 과정을 기술할 수 있는 근간이 된다. 이 과정을 데이터 정제 과정이라 하며 물리 데이터 정제 과정과 논리 데이터 정제 과정으로 나눌 수 있다.

물리 데이터 정제과정은 소스 데이터로부터 비표준화, 비통일화 되어 있는 데이터를 표준화하기 위한 전환규칙을 적용하는 단계이다. 이 전환 규칙(Conversion Rule)은 일종의 비즈니스 규칙이라고 할 수 있는데 소스 데이터로부터 입수된 정보를 마케팅 마트에서 필요로 하는 형식으로 바꾸는 작업과 함께 텍스트 상의 오류를 수정하는 작업이 병행된다. 예를 들어 ‘XX상품’, ‘YY상품’이 들어 있는 트랜젝션은 ‘A상품군’으로 트랜젝션 내용을 정제하는 경우이다.

논리 데이터 정제는 거짓값이 예상되는 오류를 논리적으로 측정해 올바른 값으로 변경하는 규칙을 적용해 양질의 데이터를 확보하는 단계이다. 예를 들어 주민번호 뒷자리의 첫번째 자리수가 1인 경우 성별이 남자로 정의되는데 트랜젝션 중 이러한 경우에 성별이 여자인 경우는 남자로 수정된다.

이러한 정제 과정이 끝나면 데이터가 타겟 데이터로 이동하기 위해 전송돼야 하는데 소스 DB와 타겟 DB가 통신할 수 있는 환경의 정의가 선행돼야 한다. 이러한 추출, 정제, 전송 프로세스는 일정 시기별로 자동화돼 수행할 수 있는데 일반적으로 Job 스케줄링이라고 한다.

Job 스케줄링에 의해 데이터가 전송되면 기존 타겟 데이터 영역의 데이터들은 갱신되거나 추가되어야 한다. 이러한 적재 방법은 일반적으로 두 가지 방안이 있는데 전체를 갱신하는 방법, 타임 스템프(Time Stamp)에 의해 일정 데이터만 갱신됨과 함께 추가되는 방안들이 있다. 적재 방법에 따라 데이터 추출과정에서 소스데이터의 범위가 결정되므로 적재방안의 올바른 선택이 시스템의 가용성을 결정하는 중요한 변수가 된다. 또한 올바른 데이터 갱신 주기의 선택도 중요하다.

고객 반응정보 관리: 트리거 및 로그 관리

e채널을 활용한 관계기반 마케팅 수행의 배경을 다시 한 번 점검해보자. 마케팅 효과가 높은 고객 접근 방안은 기업의 마케팅 메시지를 고객이 접했을 때 이 메시지가 왜 나에게 전달되었는지에 대한 고객의 추측이 가능할 때 효과가 가장 높다고 할 수 있다.

이러한 마케팅 효과를 일관성 있게 유지하기 위해서 고객의 행위와 고객의 상황변화 포인트를 마케팅 동기화 하는 과정이 필요하다. 이것이 가능하기 위해서는 조직화되어 있고 잘 관리되는 트리거 시스템(Trigger System)이 필요하다.

트리거들은 마케팅 동기를 확보하기 위해서 시스템에서 인지할 수 있는 고객의 행위나 거래사실을 즉각적으로 포착하고 이를 e마케팅 제어 콘솔에 전달하는 매우 중요한 작업이므로 e마케팅 시스템에서 중추적인 역할을 담당한다고 정의할 수 있다. 이러한 트리거들의 유연한 작동을 위해서는 이벤트 감지 파이프라인이 동적이어야 한다.

일정주기의 데이터베이스 스캐닝을 통한 이벤트 감지와 TCP/IP 등을 통해 모듈간 통신으로 감지하는 이벤트 감지 시스템이 유기적으로 운영돼야 하며 이러한 가용성 높은 트리거 운영 시스템은 구조적인 로그 관리 시스템에 기반하게 된다.

로그를 기록하고 저장하는 방안은 각 시스템의 용량적, 네트워크적 환경에 따라 다르게 설계돼야 한다. 일반적으로 로그는 트랜젝션 단위로 기록되는데 기록되는 저장매체에 따라 DB 직접기록방식과 파일기록 방식이 있다. DB 직접기록방식의 경우 단위 로그 저장 단위가 초기에 설정돼야 하기 때문에 각각의 로그길이에 대한 엄밀한 초기 계산이 필요하다. 로그저장 시스템의 가장 중요한 성패의 가름은 얼마나 고도의 압축을 이뤄 효율적인 로그관리 기반을 마련할 수 있는가에 있다.

파일기록방식의 경우 DB 직접기록방식에 비해 입출력이 빠르고, 지속적 로그 관리가 상대적으로 편하다는 장점이 있다. 이러한 장점을 살리기 위해서는 로그 내에 속성필드길이를 DBMS와 마찬가지로 고정시키고 입력되는 속성값이 가변인 경우에는 적절한 공백자를 활용해 저장한다. 이는 로그의 길이를 고정하여 파일 입력방식의 약점인 저장의 안정성과 검색의 어려움을 극복하기 위한 방안이다.

고객 니즈의 조합: 규칙 기반 시스템

CRM에서는 전략적인 고객접근을 위해 캠페인이 자주 활용된다. 마케팅 캠페인은 주로 고객·상품 및 서비스·오퍼·채널 등의 적절한 조합으로 고객을 설득한다. 이러한 일련의 프로세스들은 철저한 마케팅 캠페인 경험을 기반으로 조합되는데, 여기서의 경험은 규칙 기반 시스템이 표현하고 담당한다. 각 규칙들은 연계하거나 참조하는 오브젝트를 보유하고 있는데, 주로 참조하는 분석 데이터 혹은 외부 모듈의 특성이나 방법, 규칙 수행 결과 데이터 목록 등이 이에 해당된다.

오브젝트들은 물리적으로 연계해야 할 외부시스템이나 데이터라고 표현할 수 있다. 이러한 오브젝트의 유기적인 맵핑기능과 함께 규칙의 모순과 에러를 체크하는 디버그 기능이 절실히 요구된다. 일반적인 규칙 디자인 도구들은 규칙과 규칙이 참조하는 오브젝트의 상관관계를 ‘규칙흐름’이라고 정의하고, 이러한 규칙흐름이 각 단계별로 수행해야 하는 업무, 분기, 루프 등을 정의하고 관리할 수 있는 기능을 제공한다.

최종적인 규칙 적용단계에서는 규칙기반 아키텍처 상에서 룰간의 상관관계가 정확하게 제어되고 있는가를 살펴봐야 한다. 복수로 운영되는 규칙들은 운영관점에서 전사적인 시야를 갖추지 못하면 복잡한 조건분기나 루프 제어의 미숙으로 인해 규칙 작동의 오류 혹은 일관되지 못한 수행, 비싼 비용을 들여 구축한 OLAP나 데이터마이닝 모델을 통한 분석 데이터들의 표현이 일순간 물거품으로 끝날 수도 있기 때문이다.

제공 : DB포탈사이트 DBguide.net