2015.10.30 서울시립대학교 전자전기컴퓨터공학부 인공지능연구실 김유상 8. 고객관계관리(CRM) 2015.10.30 서울시립대학교 전자전기컴퓨터공학부 인공지능연구실 김유상

8장 설명 주제 고객 성명, 주소 파싱 고객 디멘션에 구성되는 날짜 속성, 집계 팩트, 세그먼테이션 행동 속성 및 점수 카디널리티가 낮은 속성에 대한 아웃리거 테이블 구성 빈도가 희소한 속성에 대한 브리지 테이블 구성 브리지 테이블과 포지셔널 설계 간의 트레이드 오프 관계 복수 고객 접촉에 대한 브리지 테이블 동일 고객군을 찾을 때 활용되는 고객 행동 학습 그룹 순차적인 고객 행동을 분석하는데 활용되는 진행 단계 디멘션 유효기간을 효과적으로 관리하는 타임스팬 팩트 테이블 고객만족 또는 이상 시나리오가 포함된 임벨리싱 팩트 테이블 마스터 데이터 관리나 부분적인 ETL 처리를 통한 고객 데이터 통합 실시간 응답 요구 사항을 위한 실질적인 체크리스트

1. 고객관계관리 개요 고객관계관리는 고객중심관점으로 전환을 의미 비용절감을 통한 영업 생산성 향상 고객 수익성 향상 고객 만족도 향상 고객 유지율 향상을 통한 매출 상승 운영 효율성 향상

1.1 운영CRM과 분석CRM 운영CRM에서 통합 관점의 고객 정보가 생성됨

2. 고객 디멘션 속성 표준 고객 디멘션은 성공적인 고객관계관리 구축의 핵심 요인이다 표준 고객 디멘션은 성공적인 고객관계관리 구축의 핵심 요인이다 고객 디멘션은 DW/BI시스템 구축에 있어 가장 어려운 과제이다 수백만 데이터, 수백개 칼럼, 고빈도갱신, 다수의 이종시스템 통합 다음은 고객 디멘션 설계 시 고려사항이다

2.1 고객명과 주소 파싱 주소가 Address 1, Address 2 칼럼으로 관리되는 경우 용도가 여러 가지 목적으로 활용되므로 데이터 품질 이슈가 발생하게 된다 Name 칼럼은 First Name, Middle Name, Family Name등을 구별할 수가 없어서 이러한 형태면 동일고객이면서 여러 형태의 고객명 데이터를 받게 된다 특정 목적을 가진 칼럼과 다르게 주소나 성명 같은 칼럼은 될 수 있는 한 잘게 쪼개야 한다. 이를 Parsing이라고 한다

2.2 비영어권 성명과 주소 고려사항 표준영어는 ASCII를 사용하지만 비영어권 언어를 표현하기 위해서는 유니코드를 사용한다 OS레벨 위 모든 SW는 유니코드와 호환되어야한다 ETL작업 수행중에 이슈가 발생할 수 있는 특이문자가 있는지 확인해야한다 다국어 환경에서 고객의 지리적 위치정보를 다루는 것은 더 복잡할 수 있다. 국가별로 주소체계가 다르기 때문이다. (주: 우리나라 도로명주소, 신우편번호 문제) 우편번호 데이터가 정확하게 잘 관리된다면 국가별로 제각각인 주소체계의 번거로움을 해결할 수 있다

2.2.1 다국적 데이터 처리 목표 범용성과 일관성 End-to-End 데이터 품질보장과 하위호환 문화적 오류보정 데이터 정렬이 언어별로 다를 수 있다 두 단어가 번역될때 같은단어로 번역되면 디멘션 카디널리티가 달라지므로 리포트를 실행후에 디멘션을 번역해야한다 메시지나 프롬프트도 번역되어야한다 End-to-End 데이터 품질보장과 하위호환 문화적 오류보정 실시간 고객 대응 다른 종류의 주소들

2.3 고객 지향 일자 데이터 일자 속성은 데이터는 동일하나 팩트테이블에서 사용되는 의미가 다를 수 있으므로 뷰로 표현한다 일자 속성은 데이터는 동일하나 팩트테이블에서 사용되는 의미가 다를 수 있으므로 뷰로 표현한다 첫구매일자디멘션은 팩트테이블과 직접 관계를 맺지 않고 고객 디멘션과 일대다 관계를 가지는데 이를 아웃리거 디멘션이라고 한다

2.4 집계된 팩트를 디멘션 속성으로 이용하기 연간 사용 금액, 평생 누적 사용 금액 같은 속성은 고객평가에 자주 사용되는 데이터로 고객 디멘션 테이블의 속성으로 관리하여 고객 속성의 일부처럼 표현할 수 있다 고객평가기준의 여러 측정값들은 고객 디멘션에서 파생된 별도의 디멘션으로 생성되어 반영되기도 한다

2.5 세그먼테이션 속성과 스코어 다음 속성은 마케팅 관점에서 고객을 여러 유형으로 구분할 수 있는 기준이 되는 속성이며 고객디멘션에서 활용도가 높다 성별 민족(주: 미국기준. 한국에서는 불필요) 나이 및 나이와 관련된 생애 단계 구분(유년기,청소년기…) 소득 및 소득과 관련된 생활유형(패션지향,자기주장,실리추구…) 고객상태(신규,활동,휴면,탈퇴 등) 고객신용평가기관 산업특성에 따른 시장 분류(선호고객기준) 고객을 특성별로 그룹화하기 위해 스코어링을 하기도 한다

2.5.1 고객 행동 시계열 꼬리표 고객 스코어링과 프로파일링의 대표적 방법 중 하나는 RFI 또는 RFM이다. R: Recency, 얼마나 최근에 구매한 고객인가? F: Frequency, 얼마나 자주 구매한 고객인가? I: Intensity, 같은 기간 동안 얼마나 많이 구매한 고객인가? I는 M(Monetary, 구매금액규모)으로 불리기도 한다 고객 기반의 RFI데이터를 그림8-5와 같은 큐브 형태로 표현할 수 있다 RFI큐브의 세그먼테이션 셀을 다음과같이 분류한다. 아래 제시한 A~H고객 구분은 데이터마이닝을 통해 도출하는 전형적 고객 유형이다 A:대량주문반복고객,고신용,저반품율 B:대량주문반복고객,고신용,고반품율 C:신규가입고객,신용패턴없음 D:가끔들르는고객,고신용 E:가끔들르는고객,저신용 F:공식우량고객,최근미방문 G:자주들르는돈안되는고객 H:기타 존 도우씨가 CCCDDAAABB이면 신규가입한 이후에 가끔 들르다가 물건을 한두개씩 사게 되었다. 그러다가 대량주문을 자주 하고 있는데 반품율이 올라가고 있음을 알 수 있다.

2.5.2 데이터마이닝과 DW/BI와의 관계 데이터마이닝은 DW시스템의 우량 고객이다 데이터마이닝 분석 방법 의사결정나무(Decision Tree) 신경망분석(Neural Network) 사례기반추론(Case-Based Reasoning) …

2.6 타입2 디멘션 관리에서의 고객 카운트 타입 2는 고객 디멘션의 일부 속성 값이 변경된 경우 이전 값을 가지는 원본 레코드는 유지한 채 신규 레코드를 추가하는 방식이다 이경우 고객 디멘션의 PK를 가지고 중복 제거를 하지 않으면 고객 데이터는 중복 집계될 수 있다 최종 레코드를 식별할 수 있도록 식별자 칼럼을 추가하여 관리한다

2.7 소수 카디널리티 속성의 아웃리거 그림8-6의 국가인구통계학 아웃리거디멘션은 고객디멘션에 넣기에 부적당하므로 스노우플레이크 스키마를 사용하는것이 낫다 소수 카디널리티인지 확인하고 아웃리거 디멘션으로 분리한 경우와 통합한 경우를 비교해서 어느것이 유리한지 판단해야 한다

2.8 고객 계층 고려사항 조직 계층 같은경우 고정된 계층 레벨로 설계 할 수 있다 하지만 대부분의 고객 디멘션의 계층구조는 고정적이지 않고 가변 레벨 계층이다. 전력 회사에서 전력을 사용하는 기업고객에 대한 요율을 산정한다면.. 그 기업고객은 자회사,지역영업본부,생산사업장 등이 있다 지역별로 인구,경제규모가 달라 전력 판매량도 다르고 영업조직레벨도 다르다

3. 다중값 디멘션을 위한 브리지테이블 대표적인 다중값 디멘션의 예 다중값 디멘션을 대처하는 방안 인구통계학적 속성 고객 주소 이직을 위한 전문적 기술 취미 병의 증상이나 처방 자동차 옵션 사항 은행계좌 복수 명의자 부동산 임차인 다중값 디멘션을 대처하는 방안 고정칼럼설계 : 칼럼의 이름을 다르게 설계하면서 한 테이블 안에 여러 칼럼으로 설계하여 가독성이 뛰어나다 브리지 테이블 : 고정칼럼설계의 단점이 없지만 쿼리가 복잡하다. 사용자에게는 뷰를 만들어서 제공한다

3.1 희박한 속성을 위한 브리지 테이블 고정칼럼속성에서 속성이 몇 백개 이상되고 속성이 자주 추가된다면 브리지 테이블 방식을 추천한다 그림 8-7을 그림 8-8 같이 공시디멘션, 공시브리지, 공시내역디멘션의 세 개의 테이블로 구성하였다

3.2 복수 고객 접촉에 대한 브리지 테이블 대형 기업 고객의 경우 고객 접촉 정보를 칼럼화하면 양이 매우 크기 때문에 이런 경우에도 그림 8-9같이 브리지테이블화 하는 것이 좋다. 접촉 정보 브리지 테이블은 고객관리용도로만 제한할 필요가 있다.

4. 복잡한 고객행동 분석 고객집단관리 순차적인 고객 행동 포착 정밀한 타임스팬 팩트 테이블 고객만족지표 태깅 비정규적 이벤트 태깅

4.1 고객집단에대한 행동 스터디그룹 전년도에 1000달러이상 구매한 Top 100고객을 대상으로 연구를 한다고 하자. 기존방식은 쿼리가 복잡하므로 행동연구그룹을 생성하기 위해 아래 그림8-10 으로 구성한다. 단일 키로 고객을 식별해 낼 수 있는 영속성보장키를 찾아낸다. 고객행동연구그룹디멘션은 고객디멘션과 일대일 관계를 가진다. 이 두 테이블은 뷰로 만들 수 있고 팩트테이블과 조인 뷰로 해도 스타스키마구조를 유지한다 고객행동변화를 분석하기 위한 데이터를 확보하기 위해서는 사용자 애플리케이션에서 고객의 행동이 전과 다른것을 캡처하는 기능이 개발돼야한다

4.2 순차적 고객행동에대한 스텝디멘션 여기서는 웹 로그를 활용해 분석하기 위해 아래 그림8-11과 같은 스텝 디멘션을 사용하였다 세션은 상품을 살펴보고 구매나 반품을 하는 과정을 하나의 세션으로 정의하며 스텝은 이 세션을 여려 과정으로 나눈 것이다 첫번째줄은 웹 페이지에 왔다가 바로 다른 웹페이지로 빠져나간 경우다 두,세번째줄은 하나의 세션으로 첫 웹페이지에서 다른페이지를 보고 빠져나간 경우다 스텝 디멘션으로 고객이 탐색하는 정보를 담아 분석을 하면 고객이 구매결정을 하는유인책과 다른 페이지로 빠져나간 마지막페이지를 판단할 수 있다

4.3 타임스팬 팩트테이블 그림 8-12와 같이 고객 트랜잭션 팩트테이블에 유효시작일시와 유효종료일시 칼럼을 추가하여 관리하면 정확한 고객의 신용도분석이 가능해진다 그리고 인구통계학 디멘션과 상태 디멘션에도 그 유효기간이 적용된다

4.3.1 듀얼 타임스탬프 관리 고객정보 변경 이력을 추적할 때 마지막 변경시점과 직전변경시점사이 발생하는 갭이 있으므로 시작 일시와 종료 일시를 관리하도록 한다 듀얼 타임스탬프 방식에서 새로운 데이터 발생시 STEP1 : 종료 유효 일시에 시작 유효 일시보다 큰 임의의 일시 데이터를 입력한다 STEP2 : 신규 데이터 처리가 이뤄진 다음에 ETL프로세스는 반드시 종료 유효 일시에 방금 전 입력된 신규 데이터의 입력 일시를 삽입해야 한다.

4.4 만족도 지표에대한 태깅 팩트 테이블 수익성 지표 다음으로 중요한 것이 고객만족도 지표이다 공공기관 같은 조직은 고객만족도가 최고의 지표이다 판매,반품,고객지원,청구,웹사이트,탈퇴,소셜미디어 등에서 만족도 데이터를 얻어 만족도 디멘션을 만들 수 있다

4.5 비정형 지표를 위한 태깅 팩트 테이블 일반적인 팩트 테이블은 트랜잭션 데이터를 스냅샷형태로 쌓는다 고객이 주문하여 트럭을 통해 배송중인데 타이어 바람이 빠졌다. 그래서 다른 트럭에 옮겨싣는데 비가와서 배송물품이 젖어 고객이 인수를 거부한다면.. 주문팩트테이블은 배송단계 스냅샷 데이터가 쌓인 상태로만 있다 예외상황에서도 사용자가 전체상황을 분석할 수 있게 설계하려면.. 주문 팩트 테이블의 PK를 주문번호, 주문아이템번호 레벨로 설정한다. 주문상태뿐만 아니라 주문단계별 상세 사항을 포함한다

5. 고객 데이터 통합 방안 복수의 여러버전의 고객 데이터를 단일 고객 디멘션으로 통합 표준 속성으로 구성된 복수의 고객 디멘션으로 설계

5.1 단일 고객 디멘션을 만드는 MDM Master Data Management 는 고객 데이터를 정제 통합하며 일관된 고객 정보를 전사적으로 공유하여 사용하게 된다 그림8-14는 두 형태의 MDM 아키텍처를 보여준다. 위는 전사적인 MDM을 통해 모든 운영 시스템의 고객 정보가 통합 관리되는 형태이고 아래 후처리MDM은 운영시스템에서 발생한 서로 다른 고객 정보를 정제하고 EDW는 이 데이터를 사용하는 구조이다.

5.2 복수 고객 디멘션의 부분 통합 모든 고객 정보 속성을 하나의 단일 데이터로 통합하는 것이 가장 좋은 해결방안이지만 현실적으로 거의 불가능하다 그래서 일부 속성을 공통 속성화 하는것이 현실적인 대안이다 예를 들어 고객 카테고리가 있다면 고객 관련 디멘션을 이 고객 카테고리 칼럼으로 조인하여 분석할 수 있다

5.3 팩트테이블간 조인 피하기 그림8-15와 같이 고객요청 팩트와 고객응대 팩트에 고객 디멘션을 연결하여 다대다 관계를 다대일과 일대다 관계로 나눠서 분석할 수 있다 고객 요청과 고객 대응이 각각의 카디널리티가 다를 수밖에 없는것은 고객 요청이 있어도 고객 대응이 없을 수도 있고 그 반대도 가능하기 때문이다 고객 디멘션을 통해 쿼리하게 되면 드릴 어크로스 기법으로 데이터를 조회한다 드릴 어크로스는 고객 요청 팩트를 고객별로 조회하고 그 고객에 대한 대응 팩트를 조회하는 방식으로 성능면에서도 유리하다

6. 실시간 분석 고려사항 일반적인 ETL아키텍처는 일배치기준이며 사용자의 실시간 요구사항을 충족하기 위해 여러 번 ETL을 수행하면 데이터 품질보장이 떨어진다 즉, 실시간성으로 데이터를 제공하는 가치와 그만큼 부정확한 데이터가 제공될 수 있는 확률이 올라가게 되는 트레이드오프 관계가 있다 이를 보완하는 방법 중 하나가 혼합형 ETL 아키텍처로서 주간에 여러 번 ETL을 수행하고 야간에 일 배치를 한번 더 수행하면 익일에 제공되는 데이터는 품질이 보완된다

7. 요약 고객관계관리 개요로 시작하여 고객 디멘션 테이블 설계 방법에 대해 다루었다 고객 성명과 주소를 파싱하고 DW모델에 반영하는 방안을 검토하였다 공통적인 고객 디멘션 속성을 살펴보았다 아웃리거 디멘션을 활용하여 변화가 적고 그룹핑할 수 있는 속성을 분리하는 방법을 검토하였다 브리지테이블을 적용하여 일부 디멘션에 스노우플레이크기법을 적용하는 방안에 대해 살펴보았다 복잡한 고객 행동 데이터를 다루는 방안을 살펴보았다 분산 관리되는 고객 데이터를 어떻게 통합 관리할 것인지에 대해 검토하였다 실시간 요건을 반영하는 방안과 여러 가지 제약점을 살펴보았다