고객 세분화의 기술적 측면 – 데이터 동기화

게시 됨: 2022-04-18

"CRM 데이터베이스 분석 및 세분화에 대한 광범위한 경험", "고객 세분화에 대한 강력한 이해", "데이터 세분화 및 개인화된 콘텐츠 제공에 대한 이해 및 경험." 다음은 CRM/수명 주기 마케팅 구인 제안에 있는 가장 일반적인 요구 사항의 예입니다. 고객 세분화의 개념은 매우 간단하고 시작하기 쉽지만 세분화 전문가가 되려면 기술적인 세부 사항을 자세히 살펴봐야 합니다. 이 기사를 통해 이러한 도약에 도움이 되고자 합니다.

그렇기 때문에 효율적인 세분화는 여러 데이터 소스에서 단일 서버로 일관된 데이터 흐름을 보장하는 것으로 시작됩니다. 이 프로세스는 최근에 많이 들어본 이름인 데이터 동기화 또는 단순히 데이터 동기화 라는 이름을 얻었습니다. 시스템 간의 일관성을 설정하고 일관성을 유지하기 위해 후속적인 지속적인 업데이트를 수행하는 프로세스입니다.

많은 영리한 단어는 주로 엔지니어링 팀의 영역이라는 것을 의미합니다. 그러나 주요 개념에 익숙해지면 많은 도움이 됩니다. 다음은 개요입니다.

데이터 동기화 – 이 섹션에서는 고객 데이터가 저장되는 방식, 사람들이 데이터를 이동하려는 이유 및 이를 위해 디지털 팀이 극복해야 하는 장애물에 대해 알아봅니다. 좀 더 실용적인 부분에서 이 장에서는 최신 CRM 시스템이 API를 사용하여 인터넷을 통해 데이터를 교환하는 방법의 내부 부분을 설명합니다.
데이터 무결성 및 보안 – 다음 부분에서는 동기화 후 데이터를 일관된 상태로 유지하는 데 필요한 사항을 이해하는 데 도움이 됩니다. 스키마를 사용하여 데이터 고유성을 관리하고 데이터 중복을 방지하는 방법을 배웁니다. 마지막으로 GDPR 및 CCPA 이후 시대에 일류 시민이 된 데이터 보안 및 개인 정보 보호의 기술적 측면을 반영합니다.
데이터 처리 – 마지막으로 데이터 필터링에 대한 몇 가지 팁과 일반적으로 데이터 기반 의사 결정을 내리는 데 도움이 됩니다.

저장 및 형식 복잡성

최근 기술의 발전으로 인해 데이터 저장 비용이 하락했습니다. 이를 통해 기업은 엄청난 양의 데이터를 수집할 수 있었습니다.

이러한 데이터는 정형 및 비정형 의 두 가지 범주로 나눌 수 있습니다. 세분화 작업을 수행하려면 디지털 팀이 비정형에서 정형으로 전환하는 방법을 파악해야 합니다.

구조화된 데이터 저장소란 대부분 SQL 데이터베이스 또는 Excel 파일 을 의미합니다. 그들은 훌륭하고 다재다능한 도구이지만 단점도 있습니다. SQL은 기술적 배경이 없는 사람이 배우기 어렵기 때문에 Excel의 가장 큰 장점인 유연성은 데이터 무결성을 장기간 유지하는 데 악몽이 됩니다. 이것이 이러한 범용 소프트웨어 도구가 CRM, CMS, ERP 또는 분석 도구와 같은 보다 집중적인 도구로 상부 구조화된 이유입니다.

이러한 직무 지향적인 도구는 고용된 분야의 생산성을 높이지만 종종 부서/회사 수준에서 문제가 됩니다. 왜 그래? 이러한 각 도구는 일반적으로 고유한 데이터 형식을 사용하며 두 소프트웨어 플랫폼이 서로 통합되지 않는 한 데이터 교환이 방해를 받습니다. 그리고 현대 마케터는 그런 도구를 엄청나게 많이 사용합니다.

이것이 대부분의 데이터 동기화 프로세스에 중개인 이 필요한 이유입니다. 저작 소프트웨어에서 생성된 데이터 형식(IT 세계에서는 "소스"라고 함)을 대상 형식("대상")에 맞게 조정합니다. 이러한 적응 과정을 ETL이라고 합니다. Extract(소스의 데이터), Transform(대상이 인식하고 수용하는 방식), Load(데이터 일관성을 유지하는 대상에 대한)의 약어입니다.

고객 세분화 산업에서 어떤 종류의 데이터 형식을 만날 수 있습니까?

데이터 형식

요즘 분할 소프트웨어는 대부분의 경우 데이터 동기화를 위해 두 가지 개방형 형식을 사용합니다. 그러나 "데이터 형식"은 무엇입니까? 이것은 컴퓨터가 이해할 수 있는 방식으로 구성된 텍스트에 불과합니다. 첫 번째, 더 간단한 것부터 시작하겠습니다.

CSV – 쉼표로 구분된 값. 당신이 테이블을 가지고 있다고 상상해보십시오. MS Word의 일반 테이블은 괜찮습니다. 이제 외부 테두리를 제거하고 내부 테두리를 쉼표로 바꿉니다. 짜잔, 방금 CSV 파일을 만들었습니다.

가장 큰 장점은? 단순함과 컴팩트함. SQL 및 Excel 데이터베이스는 데이터를 테이블에 저장하기 때문에 개발자는 이 형식으로 데이터를 쉽게 내보낼 수 있습니다.

반면 CSV에는 두 가지 주요 결함이 있습니다. 첫째, CSV 파일 내에서 계층 구조를 나타낼 수 없습니다. 예를 들어 한 값이 다른 값과 관련되어 있음을 표시할 수 없습니다. 두 번째로 중요한 단점은 CSV가 고정 형식이라는 것입니다. 처음에 정의한 열의 정확한 수와 유형에 따라 데이터를 교환할 수 있습니다. 다른 대상 시스템에 필요한 컬럼을 추가하거나 단순히 컬럼을 제거하면 가져오기 시도 시 오류가 발생합니다. 이러한 경우 개발자는 구조적 변경 사항을 반영하도록 코드를 조정해야 합니다.

최근 몇 년 동안 마케팅 기술이 얻은 역학 관계로 인해 이러한 제한이 주요 장애물로 판명되었습니다.

이러한 이유로 현대 시스템은 XML 및 JSON 데이터와 데이터를 교환하기 시작했습니다. 둘 다 데이터 표현의 동일한 개념을 기반으로 합니다. 후자가 더 유명하기 때문에 후자를 설명하겠습니다.

이것은 JSON 파일의 예입니다. JSON 파일을 CSV 파일과 비교할 때 유사점을 즉시 찾을 수 있습니다. 이 파일이 정확히 동일한 데이터를 저장한다는 것을 알 수 있습니다.

눈에 띄는 차이점은 CSV 파일의 열 이름이 반복된다는 것입니다. 이것이 중복되어 사람에게 가독성을 방해하는 것처럼 보일 수 있지만 JSON 유연성을 제공하는 것은 반복이므로 항목의 순서가 무의미해집니다. 이것은 교환된 파일에 새 속성(열)을 추가해야 하는 경우에 유용합니다. 새 속성을 예상하는 대상 소프트웨어는 이를 소비하지만 열 추가 전에 파일을 처리한 대상은 새 속성을 무시하고 방해받지 않고 작동합니다.

이 기능은 소스 응용 프로그램에서 보낸 데이터 형식에 더 많은 필드를 추가해도 대상이 손상되지 않도록 보장합니다. 이것이 JSON 형식이 CSV보다 더 확장 가능하고 유연하다고 말하는 이유입니다.

여기에서 JSON 파일에 대한 자세한 내용을 읽을 수 있습니다.

동기화 주파수

오늘날 일반적인 요구 사항은 전자 상거래 시스템이 실시간 이어야 한다는 것입니다. 고객은 주문 상태, 실시간 소포 추적 또는 계정의 현재 잔액이 무엇인지 확인하고 싶어합니다. 또한 마케터는 빠른 반응을 원하고 적시에 쇼핑 경험을 생성하는 실시간 캠페인을 실행하기를 원합니다.

이를 달성하기 위해 기본 데이터 저장소는 실시간 동기화 를 채택했습니다.

그러나 실시간 동기화에는 두 가지 문제를 염두에 두어야 합니다.

첫째, 일반적인 경험 법칙입니다. 더 많은 실시간 정보를 얻으려면 더 많은 비용이 듭니다 . 이 비용은 개발자의 시간에 나타나며 데이터 동기화 시스템을 계속 가동하고 실행하는 데 필요한 서버를 실행하는 하드웨어(오늘날 대부분 클라우드 솔루션임)에서도 나타납니다. 따라서 엔지니어와 대화할 때 "실시간" 요구 사항을 제시하기 전에 가장 먼저 해야 할 일은 실제로 필요한 데이터 동기화 빈도의 종류를 고려하는 것입니다. 아마도 한 시간 또는 하루에 한 번 업데이트를 전송하면 개발자의 작업을 줄이고 예산을 절약하면서 우수한 고객 경험을 보장하기에 충분할 것입니다.

다른 문제는 작업하는 데이터 저장소의 데이터 추출 기능입니다. 때때로 시스템 중 하나가 데이터를 추출하는 쉬운 방법을 제공하지 않으면 실시간 동기화가 방해받을 수 있습니다. 쉬운 의미 개발자 친화적입니다. 개발자가 시스템에서 데이터를 이동하는 방법을 통해 이 문제를 자세히 분석해 보겠습니다.

데이터 동기화 매체

데이터가 저장되는 방식, 교환에 사용되는 형식 및 동기화 빈도가 전체 동기화 시스템을 설정하는 노력에 어떻게 영향을 미칠 수 있는지 배웠습니다. 그러나 실제로 한 데이터베이스에서 다른 데이터베이스로 데이터를 전송하는 데 필요한 것은 무엇입니까? 음, 매체가 필요합니다.

DVD, USB 드라이브 또는 기타 하드웨어 기반 동기화와 같은 물리적 저장소가 될 수 있지만 방대한 양의 데이터와 실시간 동기화 요구 사항으로 인해 오늘날 이러한 방식으로 수행하는 사람은 거의 없습니다. 대부분의 경우 이 모든 것이 케이블을 통해 이루어지거나 실제로는 인터넷이라고 하는 전 세계 컴퓨터로 연결된 많은 케이블을 통해 이루어집니다.

더 구체적으로 말하면, 현대 소프트웨어 플랫폼은 World Wide Web의 기반이 되는 HTTP(Hypertext Transfer Protocol)를 사용합니다.

서버가 인터넷을 통해 서로 통신하는 방식에 관심이 있다면(그리고 더 좋을 것입니다!) 이 서버에 대한 비전문가를 위한 가이드를 시작하는 것이 좋습니다.

Kannan Chandrasegaran의 서버에 대한 비전문가를 위한 안내서

간단히 말해서 HTTP 프로토콜을 개발자가 인터넷을 통해 데이터를 보내는 방법을 알려주는 지침과 같이 취급할 수 있습니다. HTTP 외에도 개발자는 두 시스템 간에 교환할 수 있는 데이터와 순서에 대한 구체적인 설명인 API(응용 프로그래밍 인터페이스) 를 만듭니다.

API를 인터넷에서 사용할 수 있도록 하고 다른 시스템에서 액세스할 수 있도록 하는 소프트웨어(일반 웹 페이지를 방문하는 방식과 유사)를 응용 프로그램 서버라고 합니다. 다른 응용 프로그램 서버에서 들어오는 요청을 듣고 응답하며 요청에 따라 기본 데이터베이스에서 정보를 추가하거나 가져옵니다. 유용한 정보: 사람들이 API를 언급할 때 API를 인터넷에 노출하는 애플리케이션 서버의 지름길인 경우가 많습니다.

그러면 API를 사용해 보겠습니다.

API 우선 세계

API는 오늘날 디지털 마케팅의 공용어가 되었습니다. 오늘날 대부분의 데이터 동기화 작업은 API에서 데이터를 추출할 수 있는 API를 배우는 것입니다. 이 경우 HTTP에 의해 정의된 문법을 알고 있다고 가정할 때 외국어에서 다른 단어 세트를 배우는 것과 같습니다.

개발자의 일이지만 이 주제에 대해 자세히 알아보면 마케팅 기술 세계를 탐색하는 데 도움이 될 수 있습니다.

API 이해에 대한 몇 가지 실용적인 예가 포함된 전용 문서를 만들었습니다. 따라서 이를 마스터하려면(그리고 다시 해야 함) 여기 에서 읽어보세요 .

다음은 가장 중요한 발췌 내용입니다.

“식당에 손님으로 가면 부엌에 들어갈 수 없습니다. 사용 가능한 항목을 알아야 합니다. 이를 위해 메뉴가 있습니다. 메뉴를 본 후 웨이터에게 주문을 하면 웨이터가 음식을 주방으로 전달한 다음 귀하가 요청한 것을 배달합니다. 웨이터는 주방에서 제공할 수 있는 것만 배달할 수 있습니다.

API와 어떤 관련이 있습니까? 웨이터는 API입니다. 당신은 서비스를 요청하는 사람입니다. 즉, API 고객 또는 소비자입니다. 메뉴는 API에서 요청할 수 있는 내용을 설명하는 문서입니다. 주방은 예를 들어 서버입니다. 구매자가 레스토랑을 위해 재료로 구입한 것, 요리사가 제공하기로 결정한 것, 요리사가 준비하는 방법 등 특정 유형의 데이터만 보유하는 데이터베이스입니다.”

주방 – 데이터베이스, 데이터 무결성을 보호할 수 있는 고객이 없습니다.
Waiter – API, 데이터베이스의 기능을 방해하지 않고 데이터베이스에서 데이터를 제공하는 방법을 알고 있는 중개자입니다.
고객 – 데이터를 가져오려는 외부 시스템입니다.
메뉴 – 데이터 형식 참조는 외부 시스템이 작업을 수행하는 데 사용해야 합니다.
주문 – 실제 단일 API 호출입니다.

동기화로 돌아가서 이제 남은 질문은 두 시스템이 데이터를 교환해야 하는 조건을 파악하는 것입니다.

데이터 동기화 트리거

정보를 교환할 준비가 된 두 개의 애플리케이션 서버가 있다고 가정해 보겠습니다. 좀 더 구체적으로 설명하자면 이메일 서비스 제공업체( ESP )가 10번째 주문 후 프로모션 쿠폰을 보내기 위해 고객 주문(e-shop) 수를 알고 싶어한다고 가정해 보겠습니다. 이제 이 시나리오를 달성하기 위해 어떤 종류의 데이터 흐름을 구현할 수 있습니까? ESP 측에서 이메일 쿠폰 기계를 시작할 수 있는 세 가지 "트리거"를 구별할 수 있습니다.

a) 데이터 폴링 - 이 경우 ESP는 e-shop API에 반복적으로 "Jane Doe의 총 주문 금액을 알려주세요"라고 요청합니다. 매분, 한 시간 또는 하루 등으로 수행합니다. ESP가 정보를 수신하면 모든 API 요청에서 쿠폰 발송 조건을 다시 계산합니다. 이러한 방식으로 데이터를 호출하고 처리하는 것이 차선책일 수 있다고 생각한다면 직감이 옳습니다. 대안은 무엇입니까?

b) 데이터 푸시 – Jane이 10번째 주문을 하는 순간 e-shop이 ESP 애플리케이션에 알릴 수 있다면 어떨까요? 좋아요. 최신 전자 상거래 플랫폼은 이러한 단점을 인식하고 이러한 알림을 기능 세트에 포함했습니다. 일반적으로 웹훅 또는 콜아웃이라고 합니다. 간단하면서도 강력한 기능입니다. 특정 조건에서 알림을 받아야 하는 애플리케이션과 시기를 정의할 수 있습니다. 또한 알림에 포함되어야 하는 정보의 종류를 정의할 수도 있습니다. 때로는 전체 정보를 보내는 것이 합리적이지만 변경된 속성만 있으면 충분할 때도 있습니다.

c) 일괄 처리 – 때때로 요청 수가 너무 많아 이 두 가지 방법 중 어느 것도 합리적이지 않습니다. 로드를 처리하는 데 필요한 처리 능력의 양은 당사자 중 하나(또는 둘 다)에 해를 끼칠 수 있습니다. 이 경우 개발자는 모든 정보를 "일괄 처리"로 그룹화하고 야간 또는 보다 일반적으로 서버가 일일 트래픽으로 바쁘지 않을 때 데이터 교환을 예약합니다. 이렇게 하면 응용 프로그램에 대한 트래픽을 제어하고 서버에 대한 잠재적인 부담을 방지할 수 있습니다.

유용한 용어: 서버에 너무 많은 요청을 보내는 것을 방지하기 위해 애플리케이션 개발자는 애플리케이션에 속도 제한기를 적용합니다. 지정된 기간 동안 API 호출 수를 제한합니다(예: 분당 호출 5000개). 할당량을 초과하는 호출은 제한 되는 경우가 많습니다. 이것은 그것들이 (완전히 삭제하는 대신) 결국에는 제공되지만 약간의 지연이 있음을 의미합니다.

지금까지 고객 데이터를 동기화하는 방법에 대해 알아보았습니다. 그러나 실제 고객 세분화가 일어나기 전에 데이터베이스에서 데이터를 일관성 있게 유지하는 방법을 이해해야 합니다. 다음 부분에서는 데이터 무결성 및 보안 을 보장하여 성공적인 캠페인을 달성하는 방법을 설명합니다.