헤드리스 전자 상거래 – 이점, 단점 및 목표

헤드리스 커머스와 왜 지금?

오늘날 제품 관리자가 헤드리스 CMS 플랫폼을 선택하는 가장 큰 이유는 프레젠테이션과 비즈니스 로직을 분리하기 때문입니다. 이 접근 방식을 통해 개발자는 사이트를 사용자 지정하고 진화하는 구매 경험을 해결할 수 있는 더 많은 자유를 얻을 수 있습니다.

그리고 디지털 팀은 이를 판촉, 배송 또는 장바구니와 같은 다른 전자 상거래 시스템에 적용할 수 있습니다.

궁극적으로 개발자의 시간에 부담을 주지 않고 다음과 같은 상거래 동향을 따라갈 수 있습니다.

• 모바일 – 메시징을 포함하여 모바일 장치와 호환되는 새로운 고객 접점에 개방 앱 및 스마트워치;
• IoT – Alexa, Amazon Dash 및 기타 스마트 가전 제품과 같은 새로운 가정용 기기를 통합합니다.
• 미개척 웹 마케팅 채널 – 쿠폰 수집기, 마이크로(나노) 인플루언서, 틈새 포럼, 소셜 미디어 판매, 채팅, 봇 등 앞으로 등장할 더 많은 채널.
  

오늘날 전자 상거래 세계의 거의 모든 사람들은 Amazon과 거래해야 합니다. 그들의 최첨단 마케팅 개인화 전술은 점점 더 많은 시장을 흡수합니다. 크든 작든 회사는 같은 무기고를 사용하는 것 외에 선택의 여지가 없습니다.

기술 제공업체와 시스템 통합업체는 이미 자신의 제안을 수정해야 한다는 사실을 깨달았습니다.

• Magento는 미래는 머리가 없다고 말합니다.
• BigCommerce는 SaaS에서 Commerce-as-a-Service로 전환하고 있습니다.
• Isobar는 고객에게 헤드리스 접근 방식을 사용하여 지속 가능한 비즈니스 성장을 제공할 수 있는 장기적인 고객 관계를 구축하는 방법을 교육합니다.
• Demandware(Salesforce)는 API 우선 접근 방식을 통해 소매의 민주화에 베팅합니다.
  

수많은 고객 대면 부서를 지원하고 새로운 경험을 만들고 새로운 고객 접점에 구매 버튼을 전파하는 헤드리스 플랫폼의 폭발은 말할 것도 없습니다.

전통적인 전자 상거래에서는 왜 이것이 불가능합니까?

이전 접근 방식에서는 프런트 엔드(또는 "헤드")가 백 엔드와 밀접하게 연결되어 있습니다. 그리고 이러한 강력한 관계는 마케팅 혁신 속도 에 영향을 미치고 경쟁력을 유지합니다 . 더 느린 시장 출시 속도 뒤에 어떤 쇼스토퍼가 있는지 살펴보겠습니다.

소프트웨어 개발 팀:

• 디자인은 레거시 프레임워크에 의해 제한되며 사전 정의된 경험 세트만 사용할 수 있습니다.
• 작은 프런트 엔드 변경은 데이터베이스 및 백 엔드 코드의 변경을 필요로 할 수 있으므로 테스트 시간이 증가하고 따라서 작업의 총 비용이 늘어납니다.
• 백엔드 코드를 변경하면 프론트엔드에서 예기치 않은 오류가 발생할 수 있습니다.
  

마케팅 부서:

• 개인화할 여지가 거의 또는 전혀 없습니다.
• 작은 소프트웨어 변경을 완료하는 데 오랜 시간이 걸리기 때문에 기술 팀과의 혼동과 상호 오해.
• 새로운 마케팅 채널이 개발되지 않았거나 자체적으로 구축된 우선순위가 낮은 소프트웨어 우회
  

그리고 오늘날 중요한 것은 개인화와 새로운 쇼핑 채널을 수용하는 것입니다 . 소비자의 50%는 회사가 자신의 요구를 예상하지 못하면 브랜드를 전환할 가능성이 높습니다(NRF의 2018 소매 동향 보고서). 따라서 적절한 속도로 기능을 제공하는 숙련된 소프트웨어 팀이 있더라도 적절한 도구 없이 새 채널을 활용하는 데 속도가 느려질 수 있습니다.

헤드리스로 전환하면 조직에 어떤 이점이 있습니까?

헤드리스 커머스가 답이 될 수 있다고 우리는 이미 말했습니다. 소프트웨어 제공과 궁극적으로 마케팅 혁신을 광범위하고 깊이 있게 변화시키는 방법을 분석해 보겠습니다.

다시 한 번, 헤드리스는 비즈니스 로직(전자상거래 백오피스 시스템)을 프레젠테이션 계층(웹, 이메일, SMS, 모바일, 광고, 계열사 등과 같은 고객 접점)에서 분리하는 것을 의미합니다.

분리 덕분에 백엔드와 프론트엔드 개발자 모두 더 나은 개발 도구를 얻을 수 있으므로 전자 상거래 소프트웨어의 다양한 부분과 통합하는 속도를 높일 수 있습니다.

헤드리스 접근 방식을 조직에 도입하는 것은 포괄적인 관심사이므로 마케팅 담당자, 경영진, 개발자 및 CTO에 따라 이점과 과제를 분류합니다.

마케터를 위한 이점:

• 완전히 개인화된 고객 경험.
• 전체 쇼핑 여정의 모양과 느낌을 완전히 사용자 정의할 수 있습니다.
• 빌딩 블록을 재사용하여 새로운 브랜드와 고객 접점을 출시할 수 있는 능력.
• 미개척 마케팅 채널을 통해 편리성 중심의 구매 경로를 쉽게 구축할 수 있습니다.
• 더 빠른 고객 접점 통합.
• API 우선 접근 방식은 전자 상거래와 CRM 플랫폼의 통합 노력을 크게 줄입니다.
• 헤드리스 접근 방식은 새로운 UI 프레임워크에 대한 프런트엔드 개발을 열어 새로운 고객 대면 자산을 훨씬 더 빠르게 제공합니다.
• 플랫폼 업그레이드, 성능 수정, 새로운 기능 추가에 소요되는 시간과 리소스가 줄어듭니다.
• 더 나은 전환 최적화.
• A/B 테스트를 위한 UI 변형을 빌드하는 것이 더 쉽고 빠릅니다.
• 특정 고객 세그먼트에 대한 기능을 켜고 끄는 것은 훨씬 더 제어하기 쉽습니다.

관리 이점:

• 개발 비용을 낮추고 출시 시간을 단축합니다.
• Headless는 즉시 사용 가능한 견고한 빌딩 블록을 제공합니다.
• 가격은 사용량을 기준으로 하므로 작게 시작하여 나중에 규모에 대해 걱정할 수 있습니다.

CTO를 위한 이점:

• 낮은 유지 보수 비용.
• 제공자는 지원, 교육 및 철저한 문서화를 보장합니다.
• API 우선 솔루션은 캐싱이 더 쉽기 때문에 서버 부하가 낮아집니다.
• 중대한 실패의 위험을 낮춥니다.
• 미래 지향적인 솔루션.
• 개별 기술에 대한 의존도 감소.
• Zapier와 같은 자동화 도구와 더 쉽게 통합됩니다.

개발자를 위한 이점:

• API 참조가 포함된 준비된 문서.
• 격리로 인해 더 빠른 백엔드 및 프론트엔드 테스트.
• 프론트엔드 프레임워크를 자유롭게 선택할 수 있습니다.

헤드리스 상거래 문제

망치만 있으면 모든 문제를 못으로 보는 경향이 있습니다. 헤드리스를 조직의 전자 상거래 파이프라인의 모든 부분을 "수정"하는 솔루션으로 취급하지 않는다면 도움이 될 것입니다. 다음은 발생할 수 있는 몇 가지 장애물입니다.

마케터의 과제:

• 헤드리스는 기본 UI나 WYSIWYG 편집기가 없음을 의미합니다. 고객과 종종 관리자를 위한 UI를 처음부터 빌드해야 합니다.
• 공급업체의 지원이나 개발 팀에서 개발한 내부 도구가 없는 경우 실시간 미리 보기가 어려울 수 있습니다.
• 변경 사항은 백엔드 팀에서 처리한 다음 프론트엔드에서 별도로 처리해야 하기 때문에 주요 교차 변경 사항은 더 오래 걸릴 수 있습니다.
• 많은 헤드리스 공급업체는 "성장에 따른 확장" 가격을 제공합니다. 시작할 때 소프트웨어 구매에 대한 예산을 추정하는 것은 어렵습니다.
  

관리 과제:

• 전자 상거래 인프라 비용이 약간 더 높습니다.
• 중요한 전자 상거래 파이프라인에 대한 타사 시스템에 대한 종속성.
  

CTO의 과제:

• 더 많은 소프트웨어 공급업체가 협상하고 감독해야 합니다.
• 더 많은 트래픽은 더 많은 API 요청을 의미하며 결과적으로 비용이 증가합니다.
  

개발자를 위한 과제:

• 느린 전체 스택 변경 계약 중심 접근 방식은 백엔드와 프론트엔드 간의 더 많은 커뮤니케이션이 필요합니다.
• 디버깅이 더 어렵기 때문에 교차 절단 기능과 관련하여 문제를 해결하는 데 더 오랜 시간이 걸립니다.

헤드리스 커머스를 시작할 때 주의할 점

이러한 함정을 피하려면 잠재적인 헤드리스 상거래 플랫폼을 심사할 때 세 가지 요소에 주의해야 합니다.

• API 가동 시간 – 상태 페이지를 찾고 기록 레코드를 통해 공급업체가 중단을 처리하는 방법을 확인합니다. 100% 가동 시간이 보인다면 누군가가 100% 정직하지 않다는 것을 의미합니다. 심지어 Amazon Web Service에도 문제가 있었습니다.

• 가격 책정 및 API 제한 – 현재 및 미래 청구서를 계산할 수 있는 투명한 가격 책정 공급업체는 월별 송장을 날려버릴 수 있는 API 사용에 대한 안전 임계값을 가질 수 있습니다.

• 문서화 및 지원 정책 – 헤드리스 상거래는 속도에 관한 것입니다. 그러나 개발자 문서와 교육용 사용자 가이드가 없으면 모든 사람이 피하고 싶어하는 낮은 우선순위 내부 프로젝트의 경우처럼 통합 및 교육이 오래 지속됩니다.
  

자세한 내용은 전자 상거래 API를 선택하는 방법에 대한 예제 기반 가이드를 참조하십시오.

{{전자책}}

{{ENDEBOOK}}

헤드리스 상거래를 시작할 때 고려해야 할 몇 가지 추가 기술 고려 사항이 있습니다. 동료 MACH Alliance 회원인 E2X가 준비한 인포그래픽을 참조하십시오.

새롭고 주목할만한 헤드리스 커머스 플랫폼

마지막으로 전자 상거래 생태계에 통합할 수 있는 몇 가지 플랫폼을 제안하고자 합니다. 계획부터 시작합시다. 현대의 ecom 스택은 대략 다음과 같이 보입니다.

헤드리스 상거래 플랫폼은 다양한 크기와 맛으로 제공됩니다. 전자 상거래 파이프라인의 모든 부분을 포괄하는 전체 제품군 유형의 시스템과 한 가지 작업을 수행하지만 대규모 적응 기능을 갖춘 전문 플랫폼을 찾을 수 있습니다. 2019년의 임계값에 사용할 수 있는 주목할만한 공급업체를 살펴보겠습니다.

프로모션:

• 상품권
• 기프빗
• 바우샤르

카탈로그 및 인벤토리:

• 리콤비
• 채널레이프
• ‍결정화

카트:

• 짤막한 카트
• 여우 같은

지불:

• 줄무늬
• 로 인한
• 정사각형

메시징:

• 층
• 미는 사람
• 퍼브넘

예약 및 이벤트:

• 타임킷
• 인그레소

배송:

• 싯포
• 쉽클라우드
• 솜씨 없는 사람

일반적인:

• 탄력있는
• 짤막한 카트
• 몰틴
• 주문클라우드
• 커머스도구
  

작게 시작할 수 있습니다 – 미니 사례 연구

성숙한 회사에서는 리소스 부족과 무거운 프로세스로 인해 새로운 기술을 배포하기가 어렵습니다. 그들은 혁신이 느려집니다. 헤드리스 커머스의 좋은 점은 작은 것부터 시작할 수 있다는 것입니다.

Media-Saturn의 자회사인 iBood를 예로 들어 보겠습니다. 수백만 달러의 수익과 여러 국가에서의 존재를 위해서는 무거운 전자 상거래 기계가 필요합니다. 이제 그들은 판촉 개인화를 활용하기를 원하지만 기존 전자 상거래 플랫폼은 이에 대한 준비가 되어 있지 않습니다.

프로모션 엔진을 처음부터 구축하는 대신 지름길을 택하고 Voucherify API를 사용하기로 결정했습니다.

일주일 안에 그들은 쿠폰 사기를 퇴치하는 데 도움이 되는 개인 쿠폰 캠페인을 시작할 준비가 되었습니다. 그런 다음 단계적으로 다른 프로모션 캠페인을 실행하여 고객 유지를 유도합니다. 이 모든 작업은 소프트웨어 팀을 너무 괴롭히지 않으면서 다음 주 내에 이루어집니다.

헤드리스 커머스 헤드 퍼스트

헤드리스 CMS를 통합했는지 여부에 관계없이 이 접근 방식을 비즈니스의 다른 부분에 적용하는 방법은 세 단계로 요약됩니다.

• Amazon 및 Co와 경쟁하기 위해 활용하고자 하는 새로운 고객 접점을 인식하십시오.
• 기사에서 배운 내용을 고려하여 사용 가능한 헤드리스 플랫폼을 조사하십시오.
• 마케팅 및 개발 팀과 함께 아기 단계를 시작하는 방법을 계획하십시오.
  

미래는 머리가 없으니 가셔야 합니다.

{{CTA}}

Voucherify로 헤드리스 프로모션 개발

시작하다

{{ENDCTA}}