클로드 커머스 에이전트: 상품 추천을 확인하고 GA4로 측정하기

클로드 커머스 에이전트(Claude Commerce Agents)는 앤트로픽이 2026년 9월 2일 공개한 개발용 참조 코드와 설계 안내입니다. 쇼핑몰에 바로 설치하면 끝나는 완제품이나 개인용 쇼핑 앱은 아닙니다. 소매, 여행, 통신, 티켓 예제와 클로드 코드 플러그인이 아파치 2.0 라이선스로 공개됐습니다. 코드를 활용할 수 있는 권리와 실제 AI 호출 비용은 별개입니다.

온라인 가게를 운영한다면 “이 상품 중 무엇을 추천하게 할까?”와 “추천이 실제 구매로 이어졌는지 어떻게 확인할까?”가 먼저입니다. 이 글에서는 설치 없이 상품 자료를 비교하는 작은 연습을 한 뒤, 에이전트의 역할과 측정 방법을 살펴봅니다. 현재 공식 코드와 GA4 문서는 2026년 10월 4일 확인했으며, 기존 화면과 발표 수치는 해당 시기의 기록으로 남겼습니다.

가게로 치면 이번 청사진은 점원과 매니저를 붙여 주되 계산대는 그대로 두는 구성입니다. 이 글은 이 비유를 따라 점원(쇼핑 에이전트)과 매니저(판매자 에이전트)가 하는 일, 계산대(결제)를 뺀 이유, 그리고 추천 뒤의 방문과 행동을 분석 도구(GA4)에 어떻게 기록할지 순서로 갑니다.

클로드 커머스 에이전트의 구성: 점원과 매니저

위 이미지는 2026년 9월 8일 보관한 깃허브 저장소 화면입니다. 별 2,400개와 포크 416개는 당시 관심도를 보여 주는 값이며 품질이나 실제 도입 효과의 점수는 아닙니다. 저장소는 참조 구현을 제공하며 유지보수와 지원을 보장하는 완성 제품과 구분해야 합니다.

저장소에는 에이전트가 둘 있습니다. 하나는 손님을 상대하는 쇼핑 에이전트이고, 다른 하나는 가게 안쪽에서 일하는 판매자 에이전트입니다. 각각 다섯 가지 흐름을 스킬, 즉 업무별 실행 지침으로 나눠 갖습니다.

두 에이전트 모두 우리 시스템에 붙이는 방법은 같습니다. 개발자는 쇼핑 에이전트의 StorefrontBackend와 판매자 에이전트의 MerchantBackend 인터페이스에 맞춰 자사 카탈로그와 주문 시스템을 연결하는 코드를 구현합니다. 카탈로그는 상품명, 가격, 재고 같은 상품 정보를 모은 자료이고 인터페이스는 시스템끼리 주고받을 항목과 동작의 약속입니다. 모델은 연결 도구의 결과를 근거로 답하도록 설계됐지만, 답변의 사실성은 별도로 점검해야 합니다. 장바구니가 없는 사이트라면 해당 기능을 끄는 스위치가 있어서 그 기능의 도구와 프롬프트가 함께 빠집니다.

예제는 네 가지 업종으로 나왔고, 업종마다 손님용 화면과 운영자용 포털이 한 쌍입니다.

• 소매: 검색, 비교, 계획, 장바구니, 체크아웃 넘기기, 기억. 포털에는 재고 보충과 상품 목록 수정이 대기 변경안으로 뜹니다
• 여행: 날짜에 묶인 재고와 일정표 화면. 포털에는 점유율 달력과 날짜 구간별 요금 조정이 있습니다
• 통신: 계정 맥락과 요금제 비교표, 서버가 작성한 수수료 고지. 포털에서 가격을 바꾸면 영향받는 회선 수가 함께 표시됩니다
• 티켓: 시간 제한이 있는 좌석 홀드, 대기자 명단, 양도, 공연장 지도, 수수료 포함 가격 고지

설치 없이 상품 추천 기준부터 시험하기

현재 쓰는 AI 채팅에서 다음 가상 자료를 입력합니다. 별도 API 키나 쇼핑몰 계정은 필요하지 않습니다. 이 단계는 참조 코드의 안전장치를 시험하는 것이 아니라 추천 결과를 확인하는 연습입니다.

조건에 맞는 상품은 T02 기본 텀블러, 18,000원입니다. T01은 싸지만 재고가 없고 T03은 예산을 넘습니다. “무료 배송”이 붙었다면 원자료에 없는 설명이므로 삭제하도록 요청합니다. 장바구니에 담았다는 문구가 나와도 이 텍스트 연습에는 실제 장바구니가 없습니다.

같은 대화에서 “T02의 재고가 0개로 바뀌었어. 같은 조건으로 다시 골라 줘”라고 요청합니다. 이제 조건에 맞는 상품이 없어야 합니다. 재고나 가격을 임의로 바꿔 추천하면 T02 재고를 0개로 수정한 전체 자료를 다시 붙이고 어떤 조건을 어겼는지 짚어 수정합니다.

마지막으로 새 대화에 T01 재고 2개, T02 재고 0개, T03 재고 5개인 전체 자료와 같은 예산 조건을 직접 넣어봅니다. 상품 이름과 가격은 처음 자료 그대로 유지합니다. 이번에는 T01이 선택돼야 합니다. 이 세 결과를 구분할 수 있으면 개발자와 어떤 상품 데이터와 검증이 필요한지 이야기할 수 있습니다.

개발 환경이 있는 분의 로컬 예제 실행

아래는 Git, Python 3.11 이상, Node 22를 준비하고 터미널 사용 경험이 있는 분의 선택 단계입니다. 첫 상품 비교 연습만 하려면 건너뛰어도 됩니다. 명령은 macOS, Linux 또는 이미 준비한 WSL, 즉 Windows 안에서 Linux를 실행하는 환경의 셸 기준이며 Windows PowerShell에 그대로 넣는 명령이 아닙니다.

새 연습 폴더에서 저장소를 받고 별도 파이썬 환경을 만듭니다. 같은 이름의 폴더가 이미 있으면 덮어쓰지 말고 다른 빈 폴더에서 시작합니다.

카탈로그를 둘러보는 화면은 API 키 없이도 열 수 있습니다. 터미널에 나온 storefront 주소를 브라우저에서 엽니다. 기본 주소는 http://localhost:3000이며, 이미 사용 중인 포트가 있으면 실행 도구가 다른 포트를 골라 표시하므로 실제로 출력된 주소를 사용합니다. 샘플 상품이 보이면 화면 실행은 확인한 것입니다. AI 대화가 작동한다는 뜻은 아닙니다.

대화까지 시험하려면 별도 과금되는 Claude API 키와 사용 예산이 필요합니다. API 키는 프로그램이 모델을 호출할 때 사용하는 인증값입니다. 일반 클로드 구독에 포함된 대화 한도를 쓰는 방식이 아닙니다. 실행 중인 터미널에서 Ctrl+C로 멈춘 뒤, 저장소의 .env.example을 새 .env로 복사해 편집기에서 ANTHROPIC_API_KEY를 설정합니다. 기존 .env가 있다면 덮어쓰지 않습니다. 키는 채팅, 화면 캡처나 Git에 넣지 않고 다시 python scripts/run_demo.py retail로 시작합니다.

소매 예제의 대화창에 “노트북을 충전할 수 있는 여행용 어댑터를 찾아 줘. 구매하지 말고 상품만 보여 줘”라고 입력합니다. 공식 예제의 정상 결과는 65W 어댑터를 보여 주는 것입니다. 상품 화면의 이름과 출력 용량을 대조하고 원자료에 없는 특징을 덧붙이지 않았는지 확인합니다. 이는 한국어 응답을 여기서 직접 실행해 확인한 결과가 아니라 예제 문서의 확인 기준입니다.

설치 오류가 나면 마지막 명령과 오류 문구를 확인하고 다음 단계로 넘어가지 않습니다. 화면만 열리고 대화가 실패한다면 API 키, 사용 가능한 모델과 잔액을 확인합니다. 작업이 끝나면 실행한 터미널에서 Ctrl+C를 누릅니다. 다시 시작할 때는 같은 폴더에서 가상 환경을 활성화하고 실행 명령을 사용합니다. 참조 예제에는 실제 사용자를 구분하는 인증이 없으므로 인터넷에 그대로 공개할 서비스가 아닙니다.

클로드 코드 경험이 있는 개발자는 저장소의 commerce-builder 플러그인을 선택할 수도 있습니다. 설치는 저장소 README의 Quick start: build your own을 따릅니다. 아래 명령은 플러그인 설치 뒤 사용할 수 있는 명령이며 여기서는 실행하지 않아도 됩니다. 프로젝트 생성, 업무 흐름 추가, 평가 사례 작성과 검토를 돕지만 설치만으로 자사몰 연결과 배포가 끝나지는 않습니다.

실제 운영 위치를 고를 때는 플랫폼별 공식 안내를 따릅니다. Claude API, Amazon Bedrock, Microsoft Foundry, Google Cloud Vertex AI의 지원 범위는 실행 방식에 따라 다릅니다. 특히 Managed Agents를 포함해 모든 기능이 네 환경에서 똑같이 실행된다고 가정하면 안 됩니다.

상품 안내와 결제를 나눈 설계

쇼핑 에이전트의 체크아웃은 장바구니를 화면에 보여 주고 호스트, 즉 에이전트를 넣은 서비스에 넘기는 단계입니다. 참조 코드 자체는 실제 주문이나 카드 결제를 하지 않습니다. 판매자 변경안도 기본적으로 대기 상태로 남고 운영자가 승인해야 적용됩니다.

점원이 물건을 골라 바구니에 담아 주고 계산대까지 안내하지만 돈은 계산대에서 받는 것과 같습니다. 실제 상점에 붙일 때는 결제, 인증, 업무 규칙과 데이터 전달 범위를 운영자가 구현해야 합니다. 결제를 직접 하지 않는다는 사실이 상품과 고객 관련 자료를 외부 AI에 전혀 보내지 않는다는 뜻은 아닙니다.

외부 AI 서비스의 상품 발견 기능과 자사몰 안에 넣는 에이전트는 역할이 다릅니다. 모두 반대 방향으로 간다고 묶기는 어렵습니다.

OpenAI의 공식 설명은 초기 Instant Checkout의 유연성이 부족해 판매자별 결제 방식을 지원한다고 밝힙니다. 이 설명을 낮은 이용률이나 특정 배송 오류가 종료의 단일 원인으로 확정된 것처럼 확대하지 않습니다. 실제 이용 가능 국가와 판매자, 결제 방식은 각 서비스의 현재 조건을 따로 확인해야 합니다.

청사진이 코드로 강제하는 안전장치 네 가지

에이전트가 가격을 지어내거나 없는 상품을 권하면 어떻게 되는지가 커머스에서 가장 먼저 나오는 걱정입니다. 이 참조 구현은 지시문과 함께 코드 검증 장치를 둡니다. 검증되는 동작과 모든 자연어 답변의 정확성을 구분해야 합니다. 앤트로픽의 엔지니어링 글에 적힌 장치 가운데 네 가지가 실무와 바로 이어집니다.

• 서버가 준 상품 ID만 씁니다. 하네스, 즉 모델의 도구 실행과 검증을 관리하는 코드는 세션마다 서버가 모델에게 건넨 ID를 기록해 두고, 쓰기와 화면 렌더링은 그 기록에 있는 ID만 받습니다. 모델이 지어낸 ID나 손님이 대화에 끼워 넣은 ID는 여기서 걸러집니다
• 가격은 서버가 붙입니다. 점원이 가격표를 쓰지 않고 매장이 붙인 가격표를 읽듯, 상품과 가격은 턴이 시작되기 전에 카탈로그에서 가져와 모델에 넣고 계정별 계약 가격도 서버가 계산합니다
• 규제 문구는 승인된 원문만 나갑니다. 수수료와 고지 같은 문장은 모델이 어느 상품에 붙일지만 고르고 단어는 서버가 승인된 문안에서 그대로 공급합니다. 통신과 티켓 예제의 수수료 고지가 이 방식입니다
• 바깥에서 온 글을 지시와 구분합니다. 판매자 설명, 리뷰, 정책 문서 같은 제삼자 콘텐츠는 정리하고 구분 표시를 붙여 모델에 보여 줍니다. 리뷰 속 지시를 실행 명령으로 오해하거나 손님의 기억으로 잘못 저장할 위험을 줄이려는 장치입니다. 이것만으로 모든 공격이 차단된다고 보장하지는 않습니다.

판매자 쪽에는 승인 절차가 하나 더 있습니다. 매니저가 가격을 내리자고 하면 사장이 도장을 찍어야 가격표가 바뀌듯, 에이전트가 변경을 제안하면 서버 ID가 붙은 대기 변경안이 만들어지고 운영자가 포털이나 콘솔에서 승인해야 적용됩니다. 적용 시점에 한도를 다시 확인하므로 승인과 적용 사이에 조건이 바뀌어도 걸러집니다. 변경안을 만드는 역할과 승인하는 역할을 나누는 방식입니다. 실제 구현에서는 승인 옵션을 바꿀 수 있으므로 현재 호스트 설정과 적용 경로도 확인해야 합니다.

설계 자체도 참고할 만합니다. 앤트로픽은 의도 분류기나 업무별 서브에이전트 없이 모델 하나에 스킬과 도구를 붙이는 구조가 자신들이 비교한 기업 사례에서 품질이 나았고 비용과 지연도 줄어든 경우가 많았다고 적었습니다. 모든 상거래 작업에 같은 구조가 최선이라는 비교 결과는 아닙니다. 턴의 3분의 1 이상에서 필요한 지시는 시스템 프롬프트에 두고 나머지는 스킬로 내리며, 평가는 대화를 시뮬레이션하는 대신 정확한 대화 상태를 만들어 놓고 한 턴을 돌려 결과를 채점하는 방식을 권합니다. 흐름마다 50개에서 100개의 평가 사례를 시작점으로 제안합니다. 처음 배우는 분은 앞의 텀블러 세 조건처럼 입력과 기대 결과를 먼저 적는 데서 시작해도 됩니다.

장바구니 35%와 구매 완료 60%를 읽는 법

앤트로픽의 발표에는 장바구니가 최대 35% 커지고 구매 완료 가능성이 60% 높아졌다는 설명이 있습니다. 다만 그 문장만으로는 소매사별 표본 수와 기간, 비교 집단을 확인할 수 없습니다. 장바구니 크기가 금액인지 수량인지도 내 지표 정의와 맞춰야 합니다.

상대 증가 60%는 60퍼센트포인트 증가와 다릅니다. 계산을 이해하기 위한 가정으로, 같은 기준의 방문 100건 중 구매 2건인 구매율 2%라면 60% 상대 증가는 2% × 1.6 = 3.2%입니다. 차이는 1.2퍼센트포인트이며 62%가 아닙니다. 이 2%와 3.2%는 해당 기업의 실측값이 아닙니다.

또 에이전트를 쓰기로 한 사람이 원래 구매 의향이 높은 사람일 수 있습니다. 이용자 집단의 구매율이 높았다는 관찰과 에이전트를 도입했기 때문에 구매율이 올라갔다는 인과 효과는 구분합니다. 이름을 공개한 협력사의 구현 시간 사례도 우리 매장의 개발 기간을 보장하지 않습니다.

우리 매장에서는 추천의 정확성과 재고 오류부터 확인하고, 운영 단계에서 비교 기간과 집단을 정해 구매율과 주문 금액을 측정합니다. 상품 추천 테스트를 통과했다고 매출 상승 효과까지 검증한 것은 아닙니다.

에이전트가 만든 방문과 주문이 GA4에서 잡히는 세 가지 경우

위 이미지는 2026년 9월에 보관한 솔루션 페이지입니다. 데모를 본 것과 실제 매출 효과를 측정한 것을 구분하려면, 먼저 어떤 행동을 어디에 기록할지 정해야 합니다. GA4는 웹사이트와 앱의 방문 및 행동을 분석하는 도구이며 주문 시스템의 원장을 대신하지 않습니다.

AI와 관련된 활동에는 사람이 추천 링크를 클릭한 방문, 사이트 안에서 에이전트를 이용한 행동, 브라우저 방문 없이 서버에 전달된 주문이 섞여 있습니다. 세 경우는 같은 채널 이름 하나로 설명할 수 없습니다.

1. AI 추천 링크에서 온 사람의 방문

구글은 2026년 5월 13일 알려진 AI 어시스턴트의 리퍼러가 있을 때 매체를 ai-assistant, 캠페인을 (ai-assistant)로 지정하고 기본 채널 그룹의 AI Assistant로 분류한다고 발표했습니다. 리퍼러는 방문 직전 어떤 사이트의 링크에서 넘어왔는지 전하는 정보입니다.

이 분류는 사람의 링크 클릭을 분류한 것이며 AI 봇이 방문했다는 증거가 아닙니다. 리퍼러가 없더라도 URL의 캠페인 정보가 있으면 출처를 식별할 수 있고, 식별할 정보가 없으면 직접 유입 등으로 남을 수 있습니다. 랜딩 페이지가 같다는 이유만으로 직접 유입을 AI 방문으로 바꾸지는 않습니다.

이미 GA4 조회 권한이 있다면 왼쪽 보고서에서 획득 > 트래픽 획득을 열어 같은 기간의 세션 기본 채널 그룹과 세션 소스/매체를 비교합니다. AI Assistant에 어떤 소스가 묶였는지 확인하고, 분류되지 않은 방문은 모르는 상태로 남깁니다. 보고서가 없으면 관리자에게 해당 보고서와 조회 권한을 확인합니다. 직접 유입의 다른 원인은 GA4 직접 유입 글에서 이어서 볼 수 있습니다.

2. 자사 사이트 안의 장바구니 행동

에이전트 기능을 넣었다고 대화 내용이 자동으로 GA4에 수집되지는 않습니다. 반대로 아무 이벤트도 남지 않는다고 단정할 수도 없습니다. 기존 사이트에서 실제 장바구니 변경을 수집하고 있다면 그 경로를 재사용할 수 있습니다.

개발자가 확인할 것은 도구를 호출했다는 신호와 실제로 장바구니에 담겼다는 결과의 차이입니다. 참조 코드가 내보내는 tool_call은 실패할 수도 있고, cart_update는 단순히 현재 장바구니를 다시 보여 주는 동작일 수도 있습니다. 모든 신호를 새 상품 추가로 집계하면 수치가 부풀 수 있습니다.

실제 상품 추가에는 GA4의 권장 이벤트 add_to_cart, 구매에는 purchase를 사용하고 필요한 상품 정보와 금액, 통화를 보냅니다. 구분이 필요하면 interaction_actor=agent 같은 자체 매개변수를 덧붙이고 보고서용 맞춤 측정기준을 설정합니다. 이 이름은 이 글의 설계 예시이며 GA4가 기본 제공하는 항목이 아닙니다. agent_add_to_cart만 보내면 표준 전자상거래 보고서가 자동으로 채워진다고 기대하기 어렵습니다.

구현 뒤 테스트 환경에서 디버그 모드를 켜고 상품 하나를 한 번 담습니다. GA4 관리 화면의 DebugView에서 add_to_cart가 한 번 기록되고 상품 ID와 수량이 맞는지 확인합니다. 이벤트가 안 보이면 기록이 0건이라고 결론 내리기 전에 디버그 모드, 측정 ID와 전송 상태를 개발 담당자와 확인합니다. 같은 장바구니를 다시 조회했을 때 추가 이벤트가 늘면 조건을 고칩니다. 구매는 주문 ID와 주문 원본을 대조해 브라우저와 서버에서 같은 거래를 중복 보내지 않는지 봅니다. 실제 운영 데이터 대신 테스트 자료로 확인하고 대화 원문이나 고객 연락처를 분석 매개변수에 담지 않습니다.

3. 브라우저 방문 없이 생성된 주문

서버끼리 주문을 전달했다면 사이트의 브라우저 태그가 실행되지 않을 수 있습니다. 이때 주문 자체는 주문 시스템에 남아도 GA4의 방문 경로가 함께 생기는 것은 아닙니다. 별도 수집이 이미 있는지도 확인해야 합니다.

Measurement Protocol은 서버에서 GA4로 이벤트를 보내는 방법입니다. 공식 문서는 브라우저나 앱의 기존 수집을 보완하는 용도로 설명하며, 이것만 사용하는 경우 일부 보고서만 제공될 수 있다고 안내합니다. 유효한 사용자 및 세션 정보가 없는데 서버 이벤트를 보낸다고 원래 광고 클릭이나 세션 출처가 복원되지는 않습니다.

먼저 주문 원본의 주문 ID, 금액, 통화와 확인 가능한 AI 채널을 보관합니다. 개발 담당자는 실제 사용자 식별과 동의, 기존 주문 수집 및 중복 방지를 함께 검토한 뒤 연동합니다. 출처를 모르는 주문은 모르는 상태로 두고 서버 주문과 웹 세션을 같은 분모로 비교하지 않습니다. GA4 세션 소스/매체 not set 글은 그 차이를 이해하는 데 도움이 됩니다.

국내 매장에서 도입을 판단하는 순서

자사몰은 상품과 주문 데이터를 제공하는 API, 즉 프로그램이 자료를 주고받는 연결 수단이 있는지부터 확인합니다. 네이버 스마트스토어나 쿠팡 입점만 운영한다면 플랫폼이 허용하는 상품 정보와 연동 범위를 따라야 합니다. 참조 코드가 공개됐다고 입점몰 화면과 결제 기능을 원하는 대로 바꿀 수 있는 것은 아닙니다.

결제는 기존 PG, 즉 온라인 결제 대행사를 계속 활용할 수 있는 설계이지만 연결 개발과 거래 검증은 남습니다. 자사몰 솔루션의 권한, 재고 갱신 시점, 배송비와 반품 정책을 담당자와 확인합니다. 국내 플랫폼의 향후 개방 여부를 전제로 먼저 도입비를 계산하지 않습니다.

지금 해볼 일은 상품 세 개로 시작할 수 있습니다. 가격과 재고의 원본을 정하고, 앞의 세 조건에서 어떤 결과가 나와야 하는지 기록합니다. 그다음 개발 담당자와 실제 데이터 연결, 가격 변경 승인, 행동 수집 방법을 합의합니다. 처음부터 결제 자동화나 수십 개의 스킬 설치가 필요한 것은 아닙니다.

비용을 계산할 때는 모델이 보여 준 답변 길이만 보지 않습니다. 입력과 출력, 캐시 사용량, 도구 호출과 재시도를 함께 집계해야 합니다. 캐시는 반복 입력을 재사용하는 방식이며 높은 적중률을 보인 공식 사례가 내 트래픽의 비용을 보장하지는 않습니다. 테스트 한 건의 실제 사용량과 청구 기준으로 예산을 판단합니다.

자주 묻는 질문

클로드 커머스 에이전트가 결제까지 대신해 주나요?

아니요. 청사진의 쇼핑 에이전트는 장바구니를 구성해 화면에 그리는 데서 끝나고 결제는 기존 체크아웃이나 우리가 고른 에이전트 결제 사업자가 맡습니다. 판매자 에이전트도 기본 참조 설정에서는 대기 변경안을 만들어 운영자의 승인을 기다립니다. 실제 서비스의 승인 설정은 별도로 확인합니다. 앤트로픽은 코드 어디에서도 주문을 넣거나 카드를 긁지 않는다고 저장소에 적어 두었습니다.

쇼피파이가 아니어도 쓸 수 있나요?

쓸 수 있습니다. 청사진은 특정 쇼핑몰 플랫폼에 묶여 있지 않고 StorefrontBackend와 MerchantBackend 인터페이스를 우리 시스템 위에 구현하는 방식입니다. 쇼피파이는 자기 UCP 엔드포인트와 관리자 API 위에 구현한 예제를 따로 공개했을 뿐입니다. 자사몰의 카탈로그, 장바구니, 주문 조회 API와 권한, 데이터 형식이 맞는지 개발자가 검토하고 구현해야 합니다. 없는 기능을 비활성화할 수는 있지만 연결 작업이 없어지는 것은 아닙니다.

챗GPT 쇼핑과는 무엇이 다른가요?

주로 사용자가 시작하는 위치와 운영 주체가 다릅니다. 챗GPT 쇼핑은 손님이 챗GPT 안에서 상품을 찾고 소매사 앱이나 사이트로 넘어가 결제하는 구조라서 입구가 OpenAI 쪽에 있습니다. 클로드 커머스 에이전트는 소매사가 자기 사이트 안에 점원을 두는 구조라서 판매자가 추천 흐름과 기존 결제의 연결을 설계합니다. 둘은 경쟁하기보다 같은 손님의 다른 단계를 맡을 가능성이 커 보입니다.

Sources

• Building Commerce Agents with Claude, Anthropic
• The anatomy of effective commerce agents, Anthropic
• anthropics/commerce-agents, GitHub
• Shopify/claude-for-commerce-examples, GitHub
• How agentic commerce works, Shopify
• Universal Commerce Protocol updates at Google Marketing Live, Google
• What's new in Google Analytics: AI Assistant traffic measurement, Google
• Measurement Protocol, Google Analytics
• Measure ecommerce, Google Analytics
• Powering Product Discovery in ChatGPT, OpenAI