앞서 언급된 대로 Google 측에서는 GA 데이터 연계를 목적으로 Core Reporting API 라는 인터페이스를 제공한다.
R 에서도 해당 API 를 통해 GA 데이터를 가져올 수 있는데, 그 패키지가 바로 googleAnalyticsR 패키지다.
가령, Google 측이 제공하는 Affinity 세그먼트 별로 제품 조회 수를 알고 싶은 경우, 관련된 샘플 R 코드는 다음과 같다.
코드 별 상세 설명은 주석을 참고 바란다.
# googleAnalyticsR 패키지를 설치 및 로드
install.packages("googleAnalyticsR")
library("googleAnalyticsR")
# R 과 GA를 연동. 별도 브라우저 탭이 뜨고 계정 인증을 하면 된다.
ga_auth()
# GA ID 입력을 위해 해당 목록 조회. Property가 여러 개로 나눠져 있는 경우 유의해서 입력해야 한다.
ga_accounts <- ga_account_list()
View(ga_accounts)
# GA ID 입력
ga_id <- 12345678
# View ID 입력. View ID 는 GA 화면에서 Admin > View > View Settings 에서 조회 가능하다.
view_id <- 98765432
#스키마: https://ga-dev-tools.appspot.com/dimensions-metrics-explorer/
#데이터 호출
Affinity_PV <- google_analytics (view_id,
date_range = c("2020-01-01","2021-05-31"),
metrics = c("ga:pageviews"),
dimensions = c("ga:productDetailViews","ga:interestAffinityCategory"),
anti_sample = TRUE,
max = -1 )
목차 1. “No Code” Citizen Creators 2. Platforms, Networks & Marketplaces 3. The Great App Explosion 4. From Big Data to Big Ops 5. Harmonizing Humans & Machine
코딩의 영역은 UI에 의해 잠식당하고 있고, 그 속도는 점점 가속화되고 있다. 이제 디지털 세계에서 창작 활동은 개발자의 전유물이 아니다.
웹사이트 제작에서부터 시작해, 데이터 분석이나 심지어 앱, 챗봇, 머신러닝 개발까지도 이제 코딩 없이 제작할 수 있다.
표1. 활동 별 No Code Vendors
이를 Automation & Workflow, Content & UI Design, Databases & Spreadsheet-Driven 총 3가지 영역으로 구분해서 파악하기도 한다.
그림1. No Code Vendors 구분
☞ SO WHAT?
이러한 흐름이 초래할 결과는 다음과 같다.
디지털 세계에 비개발자 출신의 창작자(a.k.a. Citizen Creator)가 많아진다.
더 많고 다양한 디지탈 창작물(ex. SW, 디지털 자산, 앱, 분석물, 워크플로우 등)이 나온다.
이것들을 조율/활용 가능한 ①플랫폼 ②거버넌스③API연계의 중요성이 대두된다.
여러 영역을 다룰 줄 아는 Multi player로써의 전문가 니즈가 늘어날 것이다.
2. Platforms, Networks & Marketplaces
플랫폼, 네트워크, 마켓플레이스는 현 시대의 비즈니스 모델이자 운영 모델이다. 선도기업들은 이러한 모델들을 조합해 지속 가능한 하나의 생태계를 만든다.
그림2. 모델 별 특징 및 사례
이 생태계를 중심으로, 여러 벤더사들은 크게 3가지 수익화 전략을 구사하고 있다.
벤더사들은, – Provide: 참여자들에게 생태계 자체를 제공한다. – Engage: 참여자들이 기존 생태계에서 잘 활동할 수 있도록 지원한다. – Create: 참여자들이 직접 생태계를 만들 수 있도록 돕는다.
그림3. 벤더사들의 생태계 수익화 전략
☞ SO WHAT?.
운영 모델 수립 시, 기존의 ~ Chain (ex.Value, Supply etc.) 기반의 Linear한 개념에서 벗어나 보다 동적이고 다층적인 개념 적용을 고려해야 한다.
전략 수립 시 플랫폼 구축 방안을 항상 고려해야 한다.
3. The Great App Explosion
세상에는 수 많은 앱이 있으나, 다음 5가지 종류로 분류될 수 있다.
앱 종류
특징
예시
Custom App
기업에 의해 커스텀된 앱
웹사이트, 모바일 앱
Specialist App
특정 도메인/기능에 특화된 앱 API 지원되나 앱을 지원하는 생태계는 없음
Hotjar, Invision, Loom, SEMrush, Unibounce
App Platform
도메인/기능 전반을 지원하는 앱/스위트(Suite)
HubSpot, Salesforce, ServiceNow, Shopify
Service Platform
특정 비즈니스 서비스를 지원하기 위해 타 앱에 임베드할 수 있는 API 제공
Twilio, Stripe, AuthO
Cloud Platform
앱/서비스를 빌드하게끔 지원해주는 IaaS/PaaS
AWS, Azure, GCP
표1. 앱 종류 별 특징. 하단으로 갈수록 개수가 적어짐
Custom App을 제외한 미국 SaaS 시장은, 솔루션 수 기준으로 2020년 8,000 여 개로 집계되었다.
이는 지난 10년 간 무려 52배가 늘어난 수치다. 폭발(Explosion)이라는 표현이 결코 과하지 않다.
이 성장세는 앞으로도 계속해서 이어질 전망이다. 트렌드 2번에서도 기술된 Platform, Marketplace가 꾸준히 성장하면서 더 많은 참여자들을 유인할 것이다.
이로 인해 – 경쟁이 심화되고 – 벤더사들의 교섭력이 약화되어 가격이 전반적으로 낮아지면서 – 동시에 벤더사들은 서로 모방과 차별화를 반복해 전반적인 기능 수준이 높아지고 – 결과적으로, 앱 시장에서 기업들이 체감하는 효용은 증가할 것이다.
☞ SO WHAT?.
기업이 보유한 앱 포트폴리오를 얼마나 잘 orchestrate해 비즈니스 목적에 최적화해 활용하는가(Global Optimum)는, operation 단의 화두이자 중요 과제로 점점 부상할 것이다. 해당 역할을 잘 수행하는 agency 또는 인재가 각광을 받을 것이다.
위 역할을 수행하고자 하는 사람이라면, 앱 시장에서의 역학 변화를 눈 여겨 보아야 한다. 중위 값 기준 하나의 앱은 15개의 다른 앱과 연계가 가능하며, 앱의 89%는 API를 제공하고 있다(Pandium 2020.5). 연계가 가장 많이 되는 앱 플랫폼 또는 앱은 무엇인지 현황과 트렌드를 잘 살핀다면, 현재 어느 앱 플랫폼/앱이 주도권을 쥐고 있는지 파악할 수 있을 것이다.
4. From Big Data to Big Ops
2020년 7월 IDC와 Seagate의 조사에 따르면, 기업이 취급하는 데이터 중 32%만이 활용된다. 전체 데이터의 24%는 수집 후 방치되고 있고, 나머지 44%는 수집조차 되지 않는 Dark Data다.
이는 상당수의 기업이 데이터를 제대로 활용하지 못하고 있음을 시사한다. 암만 데이터를 모아봤자 뭐하나? 아무런 가치가 없는데. 게다가 방치되는 데이터는 기업의 손익에서 0이 아닌 음수(-)의 관계다. 데이터의 저장에는 유지보수 관리 비용이 수반된다.
이러한 데이터의 활용에 관한 문제의식에서 출발한 개념이 Big Ops다.
기존에 ‘데이터’에 초점을 맞춘 Big Data가 있었다. 데이터를 수집/저장/처리하는 데 만전을 가하자는 2010년대의 주된 담론이었다.
반면 Big Ops는 ‘조직’에 초점을 맞춘다. 조직이 데이터를 얼마나 잘 연결시키고, 활성화해 의사결정에 반영하는가가 관건이다. 이것이 최근 2020년대 들어 화두가 되고 있는 주제이다.
이러한 관점에서 데이터는 다음 2가지 측면에서 다루어야 한다. 데이터를 증류(distillation)하고, 활성화(activation) 시켜야 한다.
그림4. Data Distillation & Data Reflexes
데이터를 가공한다는 표현은 기존에 보편적으로 사용되었으나, 증류한다는 표현은 생소하다. 보아하니, 딥러닝 영역에서 사용하는 전문 기법이라고도 하는데 이를 확장시킨 듯 하다.
데이터 증류의 종착점은 지식과 통찰(knowledge & insight)이다. 그렇다면, 데이터 활성화는 어떨까? 데이터 활성화는 고도화됨에 따라 자동화(automated)로 수렴한다.
☞ SO WHAT?.
기업은 데이터를 활성화시키기 위해 먼저 데이터를 연결시킬 것이다.
내부적인 연결을 통해 데이터 관리의 복잡성이 증대되고, 이를 조율 및 제어하는 역량과 거버넌스의 역할이 대두된다.
LinkedIn 의 Architecture Migration (from Monolith to Microservice)
Mid-tier Service의 Data Model/Back-end Service로 API 접근 횟수 증가
이를 Service 별로 처리하기 위한 Service 별 여러 Data Pipeline들을 구축
Site Traffic에 따라 개별 Data Pipeline들이 Autoscaling 하지 못하는 문제 발생
이에 Autoscaling이 가능한 단일 Distributed Pub-Sub Platform 개발 필요 발생
아래 Design Principles에 입각하여 개발 – 심플한 API (producers & consumers양측 모두) – 높은 정보처리량(throughput) – Scale-out 방식 아키텍쳐
Use-case
현재 Kafka를 사용하는 기업 (출처 : Apache Kafka)
LinkedIn, Twitter, NetFlix, Spotify, Uber, Goldman Sachs, PayPal, Airbnb …
*Globally하게 Tech-savvy한 기업들.. Open Source 운용에는 DevOps팀 또는 그에 준하는 인력이 필요하다고 여실히 보여진다.
작동 방식
Kafka 의 작동 방식에 관해서는 DevTimes Blog 에 깔끔하게 잘 설명되어 있으니 참고.
기존 Message Queue System 과의 차이점에 대해 간략히 요약하자면,
Producer ~ Broker : 개별 메시지 전송 뿐만 아니라 Batch 전달 가능
Broker : Memory 가 아닌 File System에 메시지 저장
Broker ~ Consumer : Consumer 메시지 Push 받는 방식이 아닌 Pull 하는 방식
Increase only and does not repartition existing data
Re-shard by merging or splitting shards
Partition/Shard Limitation
No limit. Optimal partitions depend on the use case
500 shards in US East (N. Virginia), US West (Oregon), and EU (Ireland) regions. 200 shards in all other regions.
Data Replication/DR
Cluster mirroring
Automatically across 3 Availability Zones
Message Delivery Semantics
Kafka guarantees at-least-once delivery by default. Kafka supports exactly-once delivery in Kafka Streams
Kinesis Data Streams has at least once semantics
Security
Either SSL or SASL and authentication of connections to Kafka Brokers from clients; authentication of connections from brokers to ZooKeeper; data encryption with SSL/TLS
Data can be secured at-rest by using server-side encryption and AWS KMS master keys on sensitive data within KDS. Access data privately via your Amazon Virtual Private Cloud (VPC)
Monitoring
Yammer Metrics for metrics reporting in the server
AWS CloudWatch and CloudTrail
Dependency
ZooKeeper
DynamoDB
Cost
Requires a lot of human support on installation, set up, configuration and clusters management. Setup in weeks
11월 Gartner에서 CMO Spend Survey 2018-19 연례 리포트를 발표했다.
설문은 북미와 영국 지역의 마케팅 리더(CMOs) 600여명을 대상으로 진행됐으며, 관련된 몇 가지 흥미로운 fact와 개인적인 comment를 게시한다. 물론, 당연히 MarTech 위주로..
먼저 작년 대비 올해 마케팅 부서의 예산 편성을 보면, 단연 MarTech 분야가돋보인다. MarTech에 대한 예산 비중이 크게 증가했다 (+31.8%, +7%p).
Marketing technology has accounted for an increasingly significant share of marketing expense budgets in recent years. In 2018, this march of MarTech shows no signs of slowing down. Up from 22% in 2017, MarTech now accounts for a whopping 29% of the total marketing expense budget, making MarTech the single largest area of investment when it comes to marketing resources and programs
– Gartner report 원문
위 그래프는 연년차 비교이기 때문에 자칫 MarTech이 최근 들어 폭발적인 관심을 받게 된 것처럼 보인다. 그러나 중기적인 관점에서 맥락적 이해를 할 필요가 있다.
Gartner의 연례 리포트에서 최근 4년 간 MarTech 예산 비중 추이를 보면 왼쪽에서 잡은 하키 스틱 모양이다. 예산 비중이 3년에 걸쳐 감소했다가, 최근 다시 회복했다.
연도
2015
2016
2017
2018
MarTech 예산/전체 CMO 예산
33%
27%
22%
29%
출처: Gartner
위 추이를 통해 강조하고 싶은 점은,
최근 주요 기업들의 MarTech 투자 확장세가 Animal Spirit이아닌 Rationality에기반한 Organic Growth라는견해다.
그림 하나로 요약하면 다음과 같다.
출처: TechWell + 각색 (I think…)
세부적인 근거는 요약해서 다음과 같다.
// note: 언급되는 대형 벤더사 솔루션은 Martech 중에서도 캠페인 관련 솔루션 Leader group에 한정됨. 구체적인 리스트는 다음 링크 참고.
Supply Side / 대형 벤더들의 포트폴리오 안착
MarTech 대형 벤더사들은 공격적인 인수를 통해 CX 포트폴리오를 구성/보강하는 수렴 전략을 취한다. 주요 인수 시점을 보면 Adobe (2010~2018), Oracle (2012~2017), Salesforce (2013~2018) 와 같이 분포되어 있다. 이 중 포트폴리오 내 핵심적인 캠페인 솔루션들은 주로 2010년 대 초반에 몰려 있다. 대형 벤더사들은 자사 솔루션을 분기 단위로 주요 업데이트를 진행하는데, 5~8년 기간이면 약 20~30회 가량의 유지보수 cycle을 반복한 셈이다.해당 유지보수 기간 동안 캠페인 기능의 보완/추가에 대한 평가는 전반적으로 긍정적이다. 이메일 채널의 경우 주요 벤더사 솔루션이 제공하는 기능의 완성도는 거의 완벽에 가깝다.
// 이메일 채널은 환경 변화가 거의 없어 유지보수 cycle의 iteration 효과가 매우 크다. (unlike mobile channel……)
영미권 국가에서는 주력 마케팅 채널이 이메일이기 때문에 그들에게 대형 벤더사들의 솔루션은 충분히 매력적이다.
// 물론 모바일 쪽으로 넘어가는 추세지만 아직은 이메일이 주력이다. 여기서 모바일이란 ‘기기’를 의미하는 것이 아니다.
Supply Side / 솔루션모바일채널기능강화 Martech에서 모바일 채널은 다시 세 가지로 세분화할 수 있다. 1. 문자 2. 푸시 3. 인앱. 대형 벤더사의 솔루션들은 최근 1~2년 사이에 모바일 채널 기능을 대폭 강화(사실상 보완)하고 있는 추세다.1. 문자 채널은 1990년대 초중반부터 서비스되어 2000년대 중반부터 마케팅 캠페인 수단으로 활용된 채널이다. 나름 마케팅 역사가 10년이 넘은 채널이다. 채널 환경도 크게 변하지 않았다. U/I가 단순하고, 컨텐츠가 텍스트 기반으로 제한되기 때문에 URL link control 외에는 기능적 요구수준이 높지 않다. 채널 고유의 제한사항 때문에 이메일 채널과 직접적인 비교가 어렵겠지만, 문자 채널의 기능적 완성도는 나름의 범위 내에서는 준수한 편이다 (문자 채널 기능은 최근에서야 많이 보완되었음).
반면 앱 관련 채널(2. 푸시, 3. 인앱)은 신생 중에서도 신생 분야다. 앱 푸시의 경우 iOS, AOS 각각 첫 서비스가 2009년, 2010년에 출시되었다. 결정적 문제는 채널 환경의 급격한 변화다. 주요 기능이 추가되거나(Rich Push, Interaction Button), 연 단위로 OS가 업그레이드되면서 기존 API가 deprecated되기도 하고, 심지어 푸시 메시징 플랫폼 자체가 바뀌기도 한다(AOS : C2MD→GCM→FCM). 이때마다 SDK를 수정 및 보완해야하는 소요가 있다. 개발 언어가 여러 개이므로 일괄적인 배포 및 검증이 쉽지 않다 즉, 유지보수가 매우 어려워 벤더사 입장에서 푸시 서비스는 ROI가 낮을 수 밖에 없는 구조다.
이러한 배경 때문에 대형 벤더사 솔루션의 모바일 채널 기능 보완은 비교적 늦게 이루어졌다(~ing). 대형 벤더사의 캠페인 솔루션을 기준으로, 앱 관련 채널 기능은 2018년 말 현 시점에도 아직 부족함이 많다. 스타트업/모바일 앱 특화된 소형 벤더에는 존재하는 기능이 대형 벤더 솔루션에는 없는 게 허다하다. 현재 푸시 채널이 다루는 기능의 범위는 동일 솔루션 내 이메일 채널의 것에 비해 40~60% 수준 이하라고 개인적으로 보고 있다.
다만 긍정적인 부분은, 대형 벤더사들의 푸시 서비스 관련 패치가 최근 들어 매우 획기적으로 진행되고 있다는 점이다. 가령 Adobe Campagin, Oracle Responsys 등 주요 솔루션들의 올해 패치 노트를 보면 다른 의미로 충격적이다
// 뭐? 이 기능이 아직도 안 나왔었다고…? 이제서야? 라는 느낌. ex.인앱 기능 출시, 미리보기 기능 지원, 기기 수신상태 수집 / 푸시 고객행동 수집, 상호작용 기능 추가, 알림함 추가 등
앱 푸시 채널에 대해서는 할 말이 많으니 추후 포스팅을 통해 다루어 보도록 하겠다.
Supply Side / 플랫폼벤더들의성장 대형 벤더가 인수를 통한 포트폴리오 전략을 취하는 반면, 플랫폼 벤더는 API Integration을 기반으로 Application 제공사들과 파트너쉽을 맺는 생태계 확장 전략을 취한다. 기사에 따르면 HubSpot의 생태계 규모는 최근 8개월 (’18.01~08) 간 2배 이상 성장했다. 최근 Adobe가 Marketo를 인수했기 때문에 남은 주요 독립 플랫폼 벤더는 HubSpot 하나다. 플랫폼 특유의 네트워크 효과에 의해 향후에도 지속적인 성장이 기대된다.
//12월 초 Adobe가 산하 Marketo와의 Strategic Move에 대해 발표 예정이다.
Demand Side / 클라이언트사데이터누적에따른분석/실행고도화기능수요증대
캠페인 솔루션이 Implement 되었을 경우, 캠페인 솔루션은 단순히 실행뿐만 아니라 실행에 따른 고객 행동 및 반응 결과를 데이터로써 수집한다. 즉, ‘실행 → 수집 → 분석 → 수립 → 고도화된 실행’의 선순환을 가정한다. 데이터 누적이 원활히 진행될 시 일반적으로 ‘데이터 클린징’, ‘고급 분석’, ‘고도화 실행’ 에 대한 필요가 자연스럽게 생긴다. 이는 곧 관련 Martech 제품 수요로 이어지기 마련이다.
근래의 선도적인 엔터프라이즈 기업들은, 본사의 마케팅 고도화 수요에 대응하기 위해 단순히 한 개의 Martech 솔루션에 의존하지 않는 추세다. POC 차원에서 소형 벤더사의 솔루션을 몇 개 구독하거나, 대형 벤더사의 솔루션을 단기간 순차 구독하는 방식으로 스스로의 비즈니스 환경에 적합한 Martech Stack을 구성하고 있다.
Demand Side / 레퍼런스증가
상식적인 얘기다. 최근 5~8년 사이 솔루션 Best Practices 사례가 조금씩 늘어나고, 솔루션 Delivery 담당 인력(컨설턴트/벤더 CS) 역량 누적이 병행되면서 솔루션 도입의 Risk가 점점 줄고 있다.
Comment를마치며
다음 포스팅에서는 푸시 채널 behavior 관련, 안드로이드 쪽으로 다루어 볼까 한다 (Pie, FCM).
Oracle Responsys Marketing Platform Cloud Service 2017 Certified Implementation Specialist
An Oracle Responsys Marketing Platform Cloud Service 2017 Certified Implementation Specialist has the knowledge required to use the Oracle Marketing Cloud B2C solution, execute new client account configuration and activation, complete the initial configuration of a Responsys database to support client requirements, and integrate Responsys with third party systems. Individuals who earn this certification can create highly targeted and personalized promotional and triggered messaging campaigns.
※본 글은 Scott Brinker의 Chiefmartec.com의 9월 21일 기고글을 번역/각색한 것입니다. ※All copyright belong to Scott Brinker and Chiefmartec.com. This posting is translated version in Korean for the purpose of non-commercial use.
우리는 아직 Marketo의 최근 매출에 대해 정확히 알수는 없으나, 최근 회계년도 매출 규모가 대략 4억 7500만 달러 (한화 약 5300억 원) 이하일 것으로 추정합니다.
Adobe는 Marketo 연 매출액의 10배 이상이 되는 금액을 들여 인수를 한 것이죠.
2. Martech 시장의 매출 합병(Consolidation)! – 네, 그치만 일차원적입니다.
“아하! 봐요! Martech 시장에서는 역시 합병이 대세라구요! Brinker 당신은 틀렸어요!”
인수 소식이 난 후, 위 발언은 필자가 받은 메시지는 아니지만 대충 그런 느낌입니다.
단언컨대, 이번 거래는 Martech 시장에서의 커다란 합병입니다. 하지만 단기적으로, 이번 합병은 매출 중심 합병(revenue consolidation)입니다. Marketo가 벌어들여야 할 약 5억 달러 가량의 연 매출이 Adobe Experience Cloud 매출에 전이되는 셈이죠.
엄밀히 말해서 이는 제품 중심 합병(product consolidation)이 아닙니다.
이번 거래에 대한 Adobe 측의 공식 언급을 통해, Adobe는 Marketo를 기존 Adobe Campaign 솔루션과 별도로 두고 계속해서 분리시킬 것이라고 밝혔습니다. Adobe의 포트폴리오 상에서 Marketo는 Adobe의 B2B 솔루션, Adobe Campaign은 B2C 솔루션으로 존재할 것으로 보입니다.
이는 Oracle이 B2B와 B2C에 각각 Eloqua와 Responsys를, 그리고 Salesforce가 B2B와 B2C에 Pardot과 Exact Target/Marketing Cloud를 포트폴리오 솔루션으로 두고 있는 것과 같죠.
더 자세한 얘기는 제쳐두고, B2B 기업 입장에서 생각해보면, 결국 ‘마케팅 솔루션 선택의 가짓수’라는 측면에서 인수합병 전이나 후나 변함이 없습니다. 굳이 다른 점이라면 Marketo 로고가 이제 Adobe 로고로 바뀌는 것 뿐이죠.
저는 이제, 이번 매출 중심 합병이, 마케팅 자동화 솔루션 시장 내 다른 소규모 또는 신규 경쟁자들에게 압박으로 작용할 것이라고 생각합니다. 연이어 성장 중인 고객데이터플랫폼(Customer Data Platform, CDP) 솔루션도 그 경쟁에 포함되겠죠. 경쟁이 있는 와중에, 어느 한 시점에서는 대형 벤더사 측에서 인수를 할 겁니다. 거의 확실하죠.
그리고 저는 Adobe가 자신들이 갖고 있는 나머지 포트폴리오에 Marketo를 더 긴밀하게 통합시킬 것이라 생각합니다. 그렇게 함으로써 마케팅 솔루션 “Suite”룰 더 매력적이게 만들고, 기반을 더 튼튼히 다질 겁니다.
3. 자, Martech 기업 하나가 인수되었습니다. 그럼 그동안 신규 기업은 생겼을까요?
이 질문은 오래된 질문입니다만, Martech광들에게는 항상 top 10에 드는 질문이죠.
개인적인 추론으로는, 향후 12~18 개월 내에 상당 수의 Martech 기업들이 나가떨어질 것입니다. 이들은 VC들로부터 지난 5~7년 간 투자를 받았으나, 성장궤도에 진입하지 못했거나 운영 불가의 수익상태를 보이는 기업들일 것입니다.
계속해서 변화하는 이 세상에서 어떠한 예측을 하기를 매우 꺼려하지만… 개인적으로 예상하기에는 향후 12~18개월 동안 약 25% 정도의 Martech 기업들이 합병 등을 통해 사라질 것으로 봅니다.
그렇지만…
사라진 기업들이 훨씬 더 많은 새로운 세대의 Martech 벤처기업들에 의해 대체되는 데는 여러 이유가 있습니다. 이러한 역동성에 대해서는 5월 글에서 밝혔지만, 이번 Adobe/Marketo 인수합병의 맥락에서 몇 가지 사안들을 지적하고자 합니다.
창업가들은 이번 대규모 exit에 영향을 받을 것입니다. 그들은 대형 벤더사가 보유한 주력 솔루션의 약점을 지속적으로 탐색할 것이며 파괴적 혁신(disrupt)을 통해 대체할 궁리를 할 것입니다. 디지털 세상은 우리에게 교훈을 주었죠. 파괴적 혁신에서 경계선은 없다는 것을.
자본은 어디론가 가야합니다. Vista Equity Partners와 (Vista는 2016년 Marketo를 18억 달러에 인수했고 이번 거래를 통해 불과 2년 만에 29.5억 달러를 벌여들었다) 투자자들이 이번 거래를 통해 벌어들인 돈은 차후 투자지로 향하겠죠. 그 투자지가 반드시 Martech이라는 것은 당연히 아닙니다. 하지만 디지털 비즈니스/고객 경험의 영역에서 향후 성장 잠재력을 볼 때, 일정 부분의 금액이 Martech 관련 시장으로 재투자될 것으로 보입니다 (Martech 관련 시장이라고 언급한 이유는, 이 시장이 계속해서 진화 중이고 뚜렷한 경계선이 없기 때문입니다)
Martech 시장의 플랫폼화는 대형 플랫폼에 플러그인 방식으로 편승하려는 여러 소규모 기업의 진입장벽을 크게 낮출 수 있습니다. 여기에는 대형 플랫폼 보유 업체가 모든 참여자들에게 오픈 API 및 넓은 확장성을 제공한다는 전제가 있습니다. 실제로 Adobe와 Marketo는 그런 방향으로 확고히 가고 있죠. 이 플랫폼 생태계에서 소규모 기업들은 놀랍도록 특정 산업/시장에 특화된 솔루션을 출시하고, 특정 기능에 특화된 뛰어난 역량을 보이며, 기존 대형 벤더업체가 몇 년이 걸릴 신규 기술을 적용할 수도 있을 것입니다. 몇 조의 매출을 발생시킬 수는 없겠지만, 몇 백억의 매출은 가능해질 것입니다. VC사로부터 대규모 시리즈A 투자 없이 말이죠. 소지바, 엔젤, 창업자들에 의한 투자 금액으로도 충분히 사업 시작이 가능해지고 자생할 수 있을 것입니다.
Adobe의 Marketo 인수가 있기 불과 바로 하루 전 날, Salesforce의 App Exchange 비즈니스 앱스토에서는 600만 건이 넘게 설치가 되었었죠. 주목해야하는 부분입니다.
Salesforce의 App Exchange에는 3,500개의 앱이 존재하며, 많은 수의 앱들이 니치 시장에 집중되어 있습니다.
하지만 Salesforce의 App Exchange는 불과 시작에 불과합니다. Point Nine Capital의 Clement Vouillon은 ‘태동하는 SaaS 앱 스토어의 시대‘라는 제목의 분석 글을 기고했습니다.
상위 20개 Public SaaS 기업 중 70%는 자신들의 플랫폼에 “앱 스토어” 개념의 것을 갖고 있으며, Third-party 솔루션들이 여기서 제공된다고 합니다.
필자는 Clement가 얘기한 이 모델에 HubSpot이 부합한다고 생각합니다. 필자는 사실, 작년에 이 Hubspot에 플랫폼 생태계 Vice President로 합류했습니다. 이 “플랫폼화”가 Martech 시장의 변화를 주도하는 큰 흐름이라고 생각을 해서였죠. 이러한 시스템은 보다 좋은 마케팅 솔루션을 보다 빠르게 딜리버해줄 수 있게 합니다. 모두에게 득이죠.
Food for iThought 