Commerce.com WebMCP 도입, Cloudflare와 함께 스토어프런트에 쇼핑 도구 제공

Commerce.com과 Cloudflare는 10월 21일 브라우저 기반 쇼핑 도구를 발표했으며, Cloudflare는 약 10만 개 도메인에 이를 제공한다고 밝혔다. Commerce.com WebMCP 도입은 호환되는 AI 에이전트에 구조화된 스토어프런트 작업을 제공하는 한편, 결제는 판매자가 계속 처리하도록 한다. WebMCP는 웹사이트가 AI 어시스턴트에 호출 가능한 도구를 제공할 수 있게 하는 제안된 브라우저 인터페이스다.

당장의 변화는 에이전트가 스토어와 상호작용하는 방식에 관한 것이다. 어시스턴트는 버튼과 상품 페이지를 해석하는 대신, 스토어프런트에 지원되는 작업을 수행하도록 요청할 수 있다. 이에 따라 에이전트가 실제로 무엇을 할 수 있는지를 정의하는 책임은 판매자와 플랫폼 쪽으로 이동한다.

핵심 쟁점은 구조화된 쇼핑 도구와, 인간용 인터페이스를 바탕으로 에이전트가 작업을 추론하는 방식의 대비다. Shopify와 Google 역시 상거래 시스템 간 상호작용을 표준화하는 Universal Commerce Protocol을 통해 구조화된 커머스를 추진하고 있다. Commerce.com의 브라우저 배포는 이 전환의 특정 부분을 다룬다. 즉, 개별 판매자가 스토어를 재구축하지 않아도 어시스턴트가 기존 스토어프런트 안에서 작동하도록 돕는 것이다.

Commerce.com WebMCP 도입이 스토어프런트 인터페이스를 바꾼다

이 배포는 에이전트 접근을 참여 판매자별 개별 프로젝트가 아닌 플랫폼 기능으로 만든다.

Cloudflare의 스토어프런트 배포 설명은 웹사이트를 제공하는 인프라를 통해 추가되는 코드인 엣지 제공 스크립트를 언급한다. Commerce.com은 이미 거의 10만 개 도메인에서 이 인프라를 사용하고 있었다.

두 회사는 Commerce.com의 기존 쇼핑 도구와 방문자의 브라우저를 연결하는 브리지를 설명한다. Cloudflare가 연결을 제공하고 Commerce.com은 기반 쇼핑 로직을 유지한다. 개별 판매자는 호스트네임에 대한 Cloudflare 규칙에 정보를 제공하는 설정을 통해 제외를 선택할 수 있다.

이 아키텍처가 중요한 이유는 플랫폼 전반의 전환이 그렇지 않으면 지나치게 단순한 선택지를 만들기 때문이다. 공유 인프라에는 참여하는 스토어와 소유자가 기능을 거부하는 스토어를 구분할 방법이 필요하다. 여기서는 배포와 판매자 선택권을 함께 처리한다.

Commerce.com의 브라우저 쇼핑 발표는 자격을 갖춘 BigCommerce 판매자에게 이 기능이 기본으로 제공된다고 설명한다. 상품 검색, 비교, 장바구니 구성, 판매자 결제로의 전환을 언급한다.

발표문에 담긴 재킷 쇼핑 사례는 측정된 고객 성과의 증거라기보다 예시다. 쇼핑객은 어시스턴트에 적합한 상품을 찾아 달라고 요청하고, 어시스턴트는 장바구니를 준비한다. 이후 구매자는 스토어에서 결제를 완료한다.

이 구분은 범위를 명확히 유지한다. 상품 찾기, 옵션 선택, 장바구니 준비, 구매 승인에는 서로 다른 책임이 따른다. 성공적인 쇼핑 어시스턴트는 각각의 단계만큼이나 그 경계를 신중하게 다뤄야 한다.

판매자에게 유용한 변화는 스토어의 기존 비즈니스 운영을 통과하는 새로운 경로다. 어시스턴트는 쇼핑 경험의 또 다른 참여자가 된다. 판매자는 여전히 그 참여자가 호출할 수 있는 작업을 결정해야 한다.

플랫폼 운영자에게 이 배포는 에이전트 지원을 위한 다른 배포 모델을 시사한다. 다수의 스토어를 제공하는 인프라는 공유 인터페이스를 제공하고, 커머스 플랫폼은 비즈니스 동작을 제공할 수 있다. 이는 개별 스토어프런트 수정의 필요성을 줄인다.

그러나 공통 배포가 모든 스토어를 상업적으로 동일하게 만들지는 않는다. 구성 가능한 장비를 판매하는 스토어는 단순한 의류 카탈로그를 판매하는 스토어와 다른 요구사항을 마주한다. 노출되는 작업의 품질은 여전히 이런 차이에 달려 있다.

따라서 Commerce.com WebMCP 도입은 인프라 결정으로서 주목할 만하다. 그 의미는 플랫폼의 일반적인 배포 경로 안에 에이전트 인터페이스를 배치한다는 데 있다. 판매자는 기본 기능과 이를 유지할지에 대한 선택권을 함께 받는다.

이는 책임 소재도 바꾼다. 어시스턴트가 잘못된 상품 설명을 접한다면 카탈로그를 점검해야 한다. 작업을 잘못 호출했다면 조사에는 어시스턴트의 요청과 스토어의 응답이 모두 포함되어야 한다.

공유 인터페이스는 이 구분을 더 명확하게 만든다. 설명되지 않는 클릭 기록보다 실패를 조사할 위치를 참여자에게 더 분명히 제공한다. 이것이 일관되게 결과를 개선하는지는 실제 쇼핑 세션의 증거가 필요하다.

이제 플랫폼은 쇼핑 에이전트가 할 수 있는 일을 정의해야 한다

구조화된 쇼핑은 신뢰성 문제의 일부를 페이지 해석에서 비즈니스 작업 설계로 옮긴다.

압박은 먼저 커머스 플랫폼과 쇼핑 인터페이스를 구축하는 개발자에게 가해진다. 매력적인 스토어프런트는 사람이 탐색하는 데 도움이 된다. 에이전트에게도 이용 가능한 작업과 그 결과에 대한 모호하지 않은 설명이 필요하다.

Google의 WebMCP 문서는 도구 탐색, 정의된 입력, 공유 페이지 컨텍스트를 설명한다. 또한 도구 탐색을 위한 직접 사이트 방문과 복잡한 인터페이스에 필요한 추가 작업 등을 포함한 한계도 지적한다.

이러한 한계는 이 발표가 지금 중요한 이유를 이해하는 데 도움이 된다. 브라우저 도구는 커머스 플랫폼이 광범위한 배포를 시도할 만큼 발전했다. 그러나 이용 가능성은 여전히 호환되는 브라우저와 에이전트가 이 인터페이스를 사용하기로 선택하는지에 달려 있다.

판매자는 도구가 존재한다는 사실만으로 수요를 추론할 수 없다. 스토어는 훌륭한 쇼핑 작업을 제공할 수 있지만 어시스턴트로부터 유입되는 트래픽은 적을 수 있다. 마찬가지로 이용 가능한 작업이 구매자의 요구를 표현하지 못한다면 유입되는 에이전트 트래픽도 큰 가치를 제공하지 못한다.

실질적인 대응에는 카탈로그, 스토어프런트, 플랫폼 팀 전반의 조율이 필요하다. 상품 속성은 의미 있는 비교를 뒷받침해야 한다. 장바구니 작업은 선택 사항을 보존해야 한다. 어시스턴트가 중간 작업을 수행할 때도 고객 대상 설명은 이해하기 쉬워야 한다.

비 오는 날 출퇴근을 위한 재킷을 찾는 가상의 쇼핑객을 생각해 보자. 상품 검색은 방수 제품과 발수 제품을 함께 반환할 수 있다. 어시스턴트는 여전히 이러한 특성을 구분하고 결과가 요청을 충족하는지 설명해야 한다.

구조화된 작업은 상품 정보를 더 직접적으로 반환할 수 있다. 그러나 그 정보가 완전하다는 점이나 어시스턴트가 쇼핑객을 올바르게 해석했다는 점을 보장하지는 않는다. 인터페이스는 근거에 대한 접근성을 개선하지만, 판단은 별개의 과제로 남는다.

이 때문에 카탈로그 품질은 더 중요해진다. 누락된 소재 세부 정보나 일관되지 않은 사이즈 표기는 어시스턴트가 자신 있게 추천할 수 있는 범위에 영향을 준다. 소매업체는 브라우저 인터페이스가 이를 보완할 것이라 가정하기보다 이러한 약점을 운영 문제로 다뤄야 한다.

같은 논리는 인간 쇼핑객의 접근성에도 적용된다. 명확한 속성, 이해하기 쉬운 오류, 예측 가능한 장바구니 동작은 사람이 구매를 평가하는 데 도움이 된다. 에이전트 지원은 이러한 기반을 유지해야 할 또 다른 이유를 더한다.

쇼핑 에이전트 개발자도 상응하는 압박에 직면한다. 이들은 이용 가능한 도구를 인식하고 제약을 따라야 하며, 완료를 과장하지 않고 실패를 처리해야 한다. 어시스턴트가 상품이 준비되었다고 말한다면 검증 가능한 장바구니 상태와 일치해야 한다.

사용자 경험에는 구매자에게 명확하게 돌아가는 전환 과정도 필요하다. 장바구니 전환은 선택된 상품, 미해결 선택 사항, 남은 단계를 설명해야 한다. 그렇지 않으면 자동화는 혼란을 결제에 더 가깝게 옮길 뿐이다.

제품 관리자에게 이는 더 구체적인 평가 프레임워크를 만든다. 관련 질문은 어시스턴트가 정의된 쇼핑 작업을 정확하게 완료하는가가 된다. 설득력 있는 대화만으로는 그 결과를 입증할 수 없다.

이러한 테스트를 문서화하는 팀은 사양과 결과를 공유 검토 프로세스에 보관할 수 있다. 검색 가능한 기술 지식 기반은 엔지니어가 실패 사례를 의도한 동작과 비교하는 데 도움이 된다.

더 넓은 결과는 책임의 이동이다. 플랫폼은 사람뿐 아니라 소프트웨어 참여자에게도 스토어를 점점 더 설명해야 한다. Commerce.com의 배포는 이 요구사항을 일상적인 스토어프런트 운영으로 가져온다.

구조화된 작업은 자율 결제와 다른 문제를 다룬다

명시적인 쇼핑 작업은 모호성을 줄이지만, 구매자의 의도에는 여전히 해석이 필요하다.

개념적 수준에서 메커니즘은 간단하다. 웹사이트는 이용 가능한 작업과 기대하는 정보를 선언한다. 에이전트는 주변의 시각적 요소에서 목적을 재구성하지 않고도 해당 작업을 호출할 수 있다.

이는 스토어 기능으로 들어가는 경로를 바꾼다. 스토어의 규칙을 없애거나, 카탈로그를 대체하거나, 어떤 상품이 구매자에게 가장 적합한지를 결정하지는 않는다. 이러한 책임은 여전히 구분된다.

이 분리는 AI 쇼핑에 관한 주장들을 평가하는 유용한 방법을 제공한다. 한 시스템은 상품 검색을 개선하면서 추천 품질에는 거의 기여하지 못할 수 있다. 다른 시스템은 장바구니를 정확하게 준비하면서도 중요한 제한 사항을 빠뜨린 설명을 만들 수 있다.

따라서 평가는 상호작용 정확성과 구매 적합성을 구분해야 한다. 전자는 요청된 작업이 올바르게 수행됐는지에 관한 것이다. 후자는 그 작업이 쇼핑객의 실제 목표를 진전시켰는지에 관한 것이다.

예를 들어, 가상의 어시스턴트가 요청한 사이즈의 재킷을 정확하게 장바구니에 추가할 수 있다. 최종 세일 제한을 간과한다면 기술적 실행이 올바르더라도 구매자는 충분한 정보를 얻지 못한다. 쇼핑 결과는 두 차원 모두에 달려 있다.

Commerce.com WebMCP 도입은 명시적인 상업 인터페이스를 향한 더 넓은 움직임 안에 위치한다. Shopify 역시 판매자의 기능을 소프트웨어가 발견하고 사용할 수 있는 것으로 다룬다는 점에서 유용한 비교 대상이다.

Shopify의 Universal Commerce Protocol에 관한 엔지니어링 설명은 Google과 공동 개발한 개방형 커머스 표준을 소개한다. 판매자는 기능을 선언하고, 에이전트는 지원되는 기능을 협상하며, 거래에는 사람의 인계가 포함될 수 있다.

이 접근 방식은 서로 다른 계층에서 관련 문제를 다룬다. WebMCP는 브라우저 컨텍스트에서 웹 애플리케이션이 노출하는 도구에 관한 것이다. UCP는 참여 시스템 전반의 상업적 기능과 상호작용을 설명한다.

이 구분은 오해를 부르는 승자독식 비교를 막는다. 브라우저 인터페이스와 커머스 프로토콜은 서로를 대체할 필요가 없다. 실질적 가치는 서로 다른 진입점에서 일관된 비즈니스 동작을 보존하는지에 달려 있다.

커머스 기능 모델은 플랫폼을 기능의 소비자, 비즈니스를 제공자로 정의한다. 이 프레임은 인터페이스 아래의 상업적 관계를 부각한다. 한 시스템이 다른 시스템이 통제하는 작업을 요청하는 관계다.

판매자에게 중요한 아키텍처 질문은 일관성에 관한 것이다. 브라우저에서 작동하는 어시스턴트와 별도 통합을 통해 연결되는 다른 어시스턴트는 호환되는 규칙을 마주해야 한다. 그렇지 않으면 쇼핑 결과는 구매자가 우연히 사용한 경로에 따라 달라진다.

고객 지원에서도 일관성은 중요합니다. 선택 항목을 이용할 수 없게 되거나 장바구니에 추가 정보가 필요할 때, 고객은 이해할 수 있는 설명을 받아야 합니다. 답변은 판매자의 실제 정책을 반영해야 합니다.

이 지점에서 구조화된 작업은 더 나은 엔지니어링을 위한 기회를 만듭니다. 요청과 응답을 정의된 기대치에 따라 평가할 수 있습니다. 팀은 실패가 정보 누락, 거부된 입력 또는 지원되지 않는 작업에서 비롯됐는지 확인할 수 있습니다.

그러나 잘 정의된 작업도 지나치게 포괄적일 수 있습니다. 선택, 장바구니 변경, 확정을 결합한 도구는 오해의 여지를 더 크게 만듭니다. 책임을 좁게 나누면 결과를 더 쉽게 설명하고 평가할 수 있습니다.

따라서 이 배포에 대한 가장 설득력 있는 해석은 실용적입니다. 이는 에이전트가 스토어와 상호작용하는 더 명시적인 방식을 제공합니다. 자율 구매, 더 뛰어난 추천 또는 상업적 수익에 대한 주장은 별도의 근거가 필요합니다.

구매자에게 이러한 구분은 정보에 기반한 기대를 뒷받침합니다. 어시스턴트는 중요한 의사 결정을 눈에 보이게 유지하면서 반복적인 상호작용을 줄일 수 있습니다. 이러한 방식의 품질은 인터페이스가 구매자의 역할을 얼마나 명확하게 보존하는지에 달려 있습니다.

판매자 옵트아웃은 도입, 보안 또는 정확성을 결론짓지 못한다

판매자 통제는 배포의 특성일 뿐이며, 신뢰할 수 있는 쇼핑을 위해서는 전체 상호작용에 대한 근거가 필요합니다.

발표된 옵트아웃은 특정 질문을 다룹니다. 개별 판매자가 브라우저 통합을 거부할 수 있는가? 이는 유용한 통제 수단입니다. 그러나 참여 에이전트가 얼마나 정확하게 행동하는지, 또는 쇼핑객이 자신의 행동을 어떻게 이해하는지는 입증하지 못합니다.

공개된 도메인 수 역시 신중히 해석해야 합니다. 도메인은 보고된 배포 범위를 나타냅니다. 활성 쇼핑객 수, 완료된 장바구니 수, 고유 판매자 수 또는 기능에 기인한 구매 수를 제공하지는 않습니다.

이러한 구분은 발표를 상업적으로 평가할 때 중요합니다. 광범위한 인터페이스 배포는 잠재적 도달 범위를 확립합니다. 실제 사용량, 성공적 결과 및 추가적인 비즈니스 가치는 측정되어야 할 과제로 남습니다.

10월 22일 기준으로, 여기서 검토한 발표는 쇼핑 결과에 대한 통제된 비교를 제공하지 않습니다. 전환율 향상을 입증하거나 참여 스토어 전반의 실패를 수치화하지도 않습니다. 이러한 결과는 여전히 공개적으로 확인해야 할 질문입니다.

브라우저 호환성은 또 다른 경계를 만듭니다. 판매자는 쇼핑객이 선택한 브라우저가 의도한 워크플로를 지원하기 전에 통합을 활성화할 수 있습니다. 웹사이트에서의 배포와 방문자에게 실질적으로 제공되는 것은 별개의 조건입니다.

현재 WebMCP draft는 W3C Standard가 아니라고 명시합니다. 보안 논의에서도 악의적인 지시, 오도하는 의도, 불필요한 정보 공개와 관련된 위험을 지적합니다.

이러한 우려에는 정확한 이해가 필요합니다. 프롬프트 인젝션은 신뢰할 수 없는 콘텐츠가 어시스턴트의 행동 방향을 바꾸려 시도하는 것을 의미합니다. 구조화된 도구는 에이전트에 더 명확한 작업을 제공하지만, 에이전트는 여전히 적절한 신뢰 경계가 필요한 설명과 결과를 마주합니다.

유용한 인터페이스는 상업적 결과를 명확히 파악할 수 있게 해야 합니다. 카탈로그 검색과 장바구니 변경은 구분되는 의미를 가져야 합니다. 구매자는 어시스턴트가 정보를 수집한 때와 쇼핑 상태를 변경한 때를 이해해야 합니다.

가상의 예를 들어, 쇼핑객은 액세서리가 기존 기기에 맞는지 물어볼 수 있습니다. 이 요청이 조용히 해당 액세서리를 추가할 권한으로 바뀌어서는 안 됩니다. 도구가 구현된 대로 정확히 실행되더라도, 문제는 의도에 관한 것입니다.

정보 공유 역시 유사한 검토가 필요합니다. 쇼핑 요청은 작업에 필요한 세부 정보만 제공해야 합니다. 추가적인 개인 맥락에는 이유가 필요하며, 어시스턴트를 사용한다는 이유만으로 자동적인 결과가 되어서는 안 됩니다.

따라서 판매자 옵트아웃과 구매자 승인 권한은 서로 다른 수준에서 작동합니다. 스토어 소유자는 기능을 노출할지 결정할 수 있습니다. 구매자는 방문 중 어시스턴트가 수행하는 작업을 여전히 실질적으로 통제할 수 있어야 합니다.

정확성은 기초 정보의 최신성과 완전성에도 달려 있습니다. 스토어의 직접 응답은 유용한 근거 자료입니다. 그러나 모든 제품 속성이 쇼핑객의 질문에 답한다는 보장은 아닙니다.

이는 독립 테스트를 위한 합리적인 기준을 만듭니다. 평가자는 모호한 요청, 이용할 수 없는 옵션, 중단된 세션, 거부된 작업으로부터의 복구를 포함해야 합니다. 쉬운 시연은 의도된 경로를 보여 주지만, 까다로운 사례는 경계를 드러냅니다.

상업적 측정에도 같은 수준의 주의가 필요합니다. 에이전트 지원 장바구니는 어차피 구매했을 쇼핑객의 것일 수 있습니다. 기여도 분석은 어시스턴트의 참여와 결과에 대한 실제 기여를 구분해야 합니다.

이러한 불확실성이 배포의 중요성을 없애는 것은 아닙니다. 오히려 발표가 확립하는 것과 아직 측정되지 않은 것을 정의합니다. 인프라에 대한 주장과 고객 결과에 대한 주장은 별도로 평가해야 합니다.

판매자에게 이러한 구분을 유지하는 일은 더 나은 의사 결정을 뒷받침합니다. 기능을 유지하는 것은 합리적인 실험이 될 수 있습니다. 기대를 확대하려면 고객 경험, 운영 영향 및 복구의 신뢰성에 관한 근거가 뒤따라야 합니다.

Commerce.com WebMCP 출시 이후 주목할 점

다음으로 유용한 근거는 이 순서대로 브라우저 이용 가능성, 쇼핑 정확성, 판매자 결정을 연결할 것입니다.

향후 몇 달 동안 첫 번째 신호는 실질적인 브라우저 접근성입니다. 일반 쇼핑객이 특이한 테스트 환경 없이 지원되는 작업을 사용할 수 있도록 하는 문서화된 호환성을 주시해야 합니다. 이는 배포 범위 중 실제로 도달 가능한 부분이 얼마나 되는지를 결정합니다.

더 폭넓은 접근성의 근거는 이 인터페이스를 운영 채널로 볼 수 있다는 주장을 강화할 것입니다. 전문 환경에 계속 의존한다면 즉각적인 관련성은 좁아집니다. 어느 결과든 도메인 수만으로 판단하는 것보다 더 많은 정보를 제공합니다.

브라우저 발표는 사용자 경험도 설명해야 합니다. 쇼핑객은 어시스턴트가 작업을 어떻게 발견하고 언제 확인을 요청하는지 이해할 필요가 있습니다. 이해 가능한 상호작용 모델 없는 이용 가능성은 판매자에게 불완전한 채널만 남깁니다.

두 번째 신호는 작업 완료에 관한 독립적 근거입니다. 유용한 테스트는 비교 가능한 스토어에서 동일한 쇼핑 요청을 수행하고 오류를 기록해야 합니다. 어시스턴트가 의도한 제품을 선택하고 요청한 옵션을 유지하는지 검토해야 합니다.

가장 유용한 결과에는 복구도 포함됩니다. 이용할 수 없는 상품은 이해 가능한 응답으로 이어져야 합니다. 중단된 장바구니 작업은 무엇이 변경됐고 무엇이 아직 완료되지 않았는지 쇼핑객이 명확히 알 수 있게 해야 합니다.

이러한 근거는 구조화된 접근에서 얻은 개선과 어시스턴트 자체의 개선을 구분하는 데 도움이 됩니다. 향상된 모델은 어느 인터페이스든 더 좋아 보이게 할 수 있습니다. 신중한 비교는 어떤 구성 요소가 바뀌었는지 설명해야 합니다.

결과는 장바구니 준비와 완료된 구매의 차이도 보존해야 합니다. 이를 하나의 성공 지표로 합치면 쇼핑객이 개입하는 지점을 가립니다. 또한 어시스턴트가 작업을 처리했는지, 다시 넘겼는지도 불분명하게 만들 수 있습니다.

상호작용 실수가 줄었다는 근거는 배포의 기술적 근거를 뒷받침할 것입니다. 옵션, 장바구니 상태 또는 인계 과정에서 지속되는 모호성은 인터페이스 개선이 필요한 지점을 보여 줄 것입니다. 두 결과 모두 참여 여부를 평가하는 판매자에게 유용합니다.

세 번째 신호는 실제 사용 경험에 노출된 뒤의 판매자 행동입니다. 스토어가 기능을 유지하거나 비활성화하거나 변경을 요청하는 이유에 관한 구체적 사례를 주시해야 합니다. 이들의 결정은 플랫폼 전반의 출시만으로는 포착되지 않는 요구사항을 드러낼 수 있습니다.

기능 유지만으로는 여전히 맥락이 필요합니다. 판매자는 의미 있는 트래픽을 보지 못한 채 기본 설정을 활성화된 상태로 둘 수 있습니다. 더 강력한 근거는 참여 여부를 문서화된 사용량, 고객 피드백 및 운영상 영향에 대한 설명과 함께 제시할 것입니다.

마찬가지로 기능을 비활성화했다고 해서 이 접근 방식이 실패했다는 결론이 자동으로 나오지는 않습니다. 스토어에는 특수한 요구사항이나 호환되지 않는 워크플로가 있을 수 있습니다. 스위치의 표면적 방향보다 이유가 더 중요합니다.

개발자에게 이러한 신호는 이야기를 추적하는 데 집중된 방법을 제시합니다. 호환성 변화를 추적하고, 작업 결과를 비교하며, 판매자 결정의 배경 조건을 기록하십시오. 이를 함께 살피면 고립된 시연보다 유용한 그림을 제공합니다.

엔터프라이즈 구매자에게도 같은 근거는 조달 논의를 뒷받침합니다. 제공업체에 지원되는 작업, 승인 경계 및 실패 처리 방식을 평이한 언어로 설명하도록 요청하십시오. 제안서는 통합을 관찰 가능한 고객 결과와 연결해야 합니다.

Commerce.com WebMCP 출시는 에이전트를 위한 스토어프런트 지원을 구체적인 플랫폼 결정으로 만듭니다. 다음 장은 이 배포가 판매자와 구매자가 계속 사용하기로 선택하는 쇼핑 경험을 만들어 내는지에 달려 있습니다. 공개된 근거는 결과를 미리 가정하지 않고도 그 진행 과정을 명확히 할 수 있습니다.

스토어프런트를 관리한다면, 고객이 실제로 완료하기 어려워하는 쇼핑 작업을 문서화하는 것부터 시작하십시오. 플랫폼에 어시스턴트가 수행할 수 있는 작업과 구매자가 다시 통제권을 갖는 지점을 물어보십시오. 그런 다음 실패한 세션을 포함해 대표적인 세션을 그 기대치와 비교해 검토하십시오. 평가할 때 브라우저 호환성, 장바구니 정확성, 고객의 이해를 분리해서 살피십시오. 도구를 노출한 스토어는 기술적 단계를 밟은 것입니다. 사람들이 의도한 작업을 완료하도록 돕는 스토어는 고객 혜택을 제공한 것입니다. 어시스턴트의 역할을 확대하기 전에 이 두 단계를 연결하는 근거를 따르십시오. 쇼핑 경험 중 더 명확하고 명시적으로 정의된 작업으로 가장 큰 도움을 받을 부분은 무엇입니까?