CRM 개인화로 상거래를 위한 Vertex AI Search 개선

Vertex AI Search for commerce용 API 구현 가이드에서는 고객 관계 관리 (CRM) 데이터를 사용하여 Vertex AI Search for commerce 내에서 검색 환경을 맞춤설정하는 방법을 설명합니다. CRM의 사용자 속성을 통합하면 더 관련성 높은 검색 결과를 제공하여 궁극적으로 고객 참여도와 전환을 개선할 수 있습니다. 이 문서에서는 데이터 고려사항 및 기술 사양을 비롯하여 이러한 사용자 속성을 통합하는 프로세스를 자세히 설명합니다.

맞춤설정할 데이터 선택

맞춤설정의 효과는 제공하는 CRM 데이터의 품질, 범위, 관련성에 따라 달라집니다. 지식이 풍부한 영업사원이 제공할 수 있는 검색 결과에 실제로 영향을 미치는 고객 정보가 무엇인지 생각해 보세요.

파일럿 테스트가 완료되면 어떤 데이터가 효과적인지 (또는 효과적이지 않은지)에 대한 더 강력한 추천을 받을 수 있습니다.

이러한 데이터 카테고리는 상거래 사이트 사용자 행동에 대한 가장 유용한 정보를 제공합니다.

  • 지리 정보: 고객 위치(예: 주 또는 국가)입니다. 우편번호 정보가 너무 세분화되어 있습니다. 자세한 내용은 과도한 세분화 섹션을 참고하세요.
  • 인구통계 데이터: 연령, 성별과 같은 핵심 고객 특성입니다.
    • 고객의 연령대 (예: 18~24세와 55~64세)를 알면 의류나 전자제품과 같은 상품에 대해 서로 다른 제품 디스플레이 전략을 세울 수 있습니다. 이는 매우 영향력 있는 데이터입니다.
  • 고객 페르소나: 예를 들어 지출이 많은 쇼핑객이 아닌 예산에 민감하거나 절약하는 쇼핑객

영향을 미칠 가능성이 낮은 데이터 카테고리

이러한 데이터 카테고리는 커머스 데이터 수집에 미치는 영향이 미미합니다.

  • 구매 내역에서 파생된 속성:
    • Google 시스템은 이미 맞춤설정을 위해 과거 구매 행동을 통합하고 있습니다.
    • 이 정보는 기본적으로 캡처되고 활용되므로 user bought a green dress yesterday와 같은 속성을 전송하는 것은 중복됩니다.
    • CRM의 새로운 통계에 집중하세요.
  • Clicked email #7와 같은 구체적인 마케팅 응답 데이터:
    • 마케팅 캠페인 분석에는 유용하지만 AI에 표시할 검색 결과를 알려주지는 않습니다.

데이터 완전성

관련성 외에도 사용자층 전체의 데이터 완전성은 개인 최적화에 대한 유용성에 큰 영향을 미칩니다. 속성은 상당수의 사용자가 사용할 수 있을 때 가장 유용하며, 시스템이 더 광범위한 패턴을 식별하고 더 광범위하게 맞춤설정을 적용할 수 있습니다.

  • 매우 유용함:
    • 사용자 중 상당수(예: 사용자층의 70%)에 해당하는 속성(예: shipping_state:MA)
    • 이를 통해 강력한 패턴 인식과 광범위한 맞춤설정이 가능합니다.
  • 유용성이 떨어짐:
    • 사용자 중 일부에게만 제공되는 속성(예: 사용자층의 0.1% 에게만 제공되는 경우 hair_color:blonde)

이러한 데이터는 흥미롭지만 충분한 예가 없어 시스템에서 의미 있는 맞춤설정 신호를 도출하기 어렵습니다. 대신 고객 프로필 전반에 걸쳐 더 광범위한 정보를 제공하는 속성에 우선순위를 두세요.

데이터 세부사항 가이드라인

효과적인 맞춤설정을 위해서는 적절한 수준의 데이터 세부사항이 중요합니다. 너무 광범위하거나 너무 구체적인 데이터는 시스템이 의미 있는 패턴을 식별하는 능력을 저하시킬 수 있습니다. 고객층을 실행 가능한 그룹으로 분류하는 속성을 목표로 하세요.

적절한 세분화

적절한 세분화의 예는 다음 필드입니다.

  • 성별
  • 주
  • 시
  • 연령대 (예: 30~39세)

이 세분화 수준은 관리할 수 없는 수의 카테고리를 만들지 않고도 개인화에 차별화를 제공합니다.

세부사항이 충분하지 않음

예를 들어 고객층의 대부분이 미국에 거주하는 경우 country:US는 세분성이 부족합니다. 고객층 전반에 걸쳐 분산이 적은 속성은 맞춤설정에 거의 도움이 되지 않기 때문입니다.

과도한 세부사항

과도한 세부사항의 예는 다음과 같습니다.

  • 정확한 우편번호 (zipcode:12345): 잠재적인 우편번호가 수만 개에 달하므로 대부분의 우편번호에는 연결된 고객이 거의 없습니다. 이러한 원자화는 신호를 희석합니다. 우편번호를 사용하는 경우 적절한 세부사항 수준을 달성하기 위해 처음 두 자리로 자릅니다. 우편번호의 처음 두 자리는 주 크기의 지역에 대략적으로 매핑됩니다.
  • 정확한 연령 (age:37): 연령 카테고리가 너무 많이 생성됩니다. 수를 줄이려면 연령과 같은 수치 데이터를 미리 정의된 10개의 구간 또는 버킷 (예: age:30-39)으로 그룹화하세요.

추가 데이터 가이드라인

이 섹션에서는 범주형 및 기타 데이터 형식을 다룹니다.

범주형 데이터 형식

이 시스템은 다음과 같은 범주형 데이터에 최적화되어 있습니다.

  • state:MA
  • gender:male

수치형 데이터

따라서 연령, 소득, 빈도와 같은 숫자 속성은 데이터 전송 전에 의미 있는 버킷으로 그룹화해야 합니다.

다음은 각각 잘못된 예와 올바른 예입니다.

  • age:37
  • age:30-39

추가 데이터 제약 조건

  • 속성 한도: 각 쿼리는 최대 100개의 키-값 쌍을 지원합니다. 향후 출시에서 더 많은 쌍이 지원될 수 있습니다.
  • 중복 키: 단일 쿼리 내에서 중복 키는 허용되지 않습니다. 하지만 키당 여러 값은 지원됩니다.
  • 금지된 PII: 고객 이메일 주소, 주민등록번호, 성명, 신용카드 번호와 같은 금융 데이터와 같은 특정 개인 식별 정보 (PII)를 어떤 형태로도 전송해서는 안 됩니다.

API 통합 및 데이터 전송

고객 데이터는 이벤트가 아닌 검색 요청의 query 필드 내에서 전송해야 합니다.

프로토콜 버퍼 구조 (개발자용)

사용자 속성은 SearchRequest 메시지 내에 문자열에서 StringList 메시지로의 맵으로 정의됩니다.

protobuf 샘플 보기

// A list of string values.
message StringList {
// String values.
repeated string values;
}

// Request message for [SearchService.Search][] method.
message SearchRequest {
...
// The user attributes that could be used for personalization of search.
maptring, StringList> user_attributes;
}

JSON 요청 예시

이 예에서는 JSON 검색 요청 내에서 user_attributes를 구조화하는 방법을 보여줍니다.

JSON 샘플 보기

{
...

user_attributes: [
       { key: "pets" # note keys can be hashed or unhashed
         value {
           values: "dog" # Note: these values MUST be hashed
           values: "cat"
         }
       },
       { key: "state"
         value {
           values: "CA"
         }
       }
      ]
}

API 응답

이 기능을 활용할 때 SearchResponse API는 변경되지 않습니다. 맞춤설정은 제공된 사용자 속성을 기반으로 내부적으로 이루어집니다.

데이터 해싱 요구사항

데이터 개인 정보 보호 및 보안을 위해 속성 값을 해싱해야 합니다. 키는 해싱되거나 해싱되지 않은 상태로 전송될 수 있습니다.

해싱 키

pet_owner 및 state과 같은 속성 키는 원래 문자열 형식으로 전송하거나 해싱할 수 있습니다. 두 가지 모두 허용됩니다.

예를 들면 다음과 같습니다.

  • 허용됨 - pet_owner
  • 허용됨 - hash(pet_owner)

값 해싱

dog, CA과 같은 속성 값은 해싱되어야 합니다. 일반 텍스트 값은 전송할 수 없습니다.

예를 들면 다음과 같습니다.

  • 허용됨 - hash(dog)
  • 허용되지 않음 — "Dog"

결합된 키-값 해싱

키와 값을 모두 해싱해야 하는 경우 독립적으로 해싱해야 합니다. 결합된 키-값 문자열을 해싱하지 마세요.

예를 들면 다음과 같습니다.

  • 허용됨 - pet_owner:hash("dog")
  • 허용됨 - hash(pet_owner):hash("dog")
  • 허용되지 않음 — hash("Pet_owner:dog")

데이터 전송 권장사항

이 섹션에서는 반복 값 처리, 데이터 일관성, 속성 키 이름 지정 유연성, 다양한 사용자 프로필 처리 등 데이터 전송에 관한 여러 권장사항을 설명합니다.

반복 값을 처리하는 방법

사용자가 개와 고양이를 모두 소유하는 등 단일 속성에 여러 값이 있는 경우 StringList 내의 단일 key 아래에 모든 값을 제공합니다.

다음 코드 샘플은 각각 잘못된 사용과 올바른 사용의 예를 보여줍니다.

샘플 보기

// This is incorrect because it sends the same key multiple times for different
// values, causing only one of the two values for pets to be used, choosing one
// value or the other in an inconsistent manner.
{
  key: "pets",
  value {
    values: "dog"
  }
},
{
  key: "pets",
  value {
    values: "cat"
  }
}

샘플 보기

{
  key: "pets",
  value {
    values: "dog",
    values: "cat"
  }
}

데이터 일관성

모든 키와 값의 맞춤법, 띄어쓰기, 대소문자를 엄격하게 일관되게 유지합니다. 시스템은 사소한 변형도 별도의 카테고리로 해석합니다.

예를 들어 State:MA, state:MA, state:ma, STATE:MA, residence_state:MA은 모두 별도의 관련 없는 속성으로 처리됩니다.

속성 키 이름 지정 유연성

일관성이 유지되는 경우 속성 키 (예: pet_owner, pets, codeabc)의 구체적인 명명 규칙은 시스템의 데이터 사용 능력에 본질적으로 영향을 미치지 않습니다. 중요한 점은 전송하는 데이터의 일관성입니다.

다양한 사용자 프로필을 처리하는 방법

사용자마다 속성 집합이 달라도 됩니다.

  • 예: 사용자 A는 age:30-39 및 pet:dog를 보유할 수 있지만 사용자 B는 gender:male를 보유하고 반려동물 또는 연령 데이터는 보유하지 않을 수 있습니다. 시스템은 부분 프로필을 원활하게 처리합니다.

동적 데이터 업데이트

사용자 속성은 시간이 지나면서 바뀔 수 있습니다. 새 정보가 제공되면 사용자의 프로필을 업데이트할 수 있습니다.

  • 예: 처음에는 age:30-39 및 pet:dog로 식별된 사용자의 위치가 획득되면 나중에 state:MA이 추가될 수 있습니다.

크로스 플랫폼 일관성

모바일 앱이나 웹사이트와 같은 모든 터치 포인트에서 특정 사용자에 대해 일관된 속성 전송을 위해 노력하세요. 이렇게 하면 통합된 맞춤설정 환경이 보장됩니다.

  • 최적: 사용자 A가 모바일 앱과 웹사이트 모두에서 일관되게 age:30-39입니다.
  • 최적이 아님: 사용자 A가 모바일 앱에서는 age:30-39이지만 웹사이트에서는 pet:dog입니다.

누락된 데이터를 처리하는 방법

사용자에 관한 특정 정보를 사용할 수 없는 경우 자리표시자나 빈 값을 보내지 마세요. 요청에서 해당 키-값 쌍을 생략하면 됩니다.

  • 예: pet:unknown 또는 pet:를 사용하지 마세요.

SDK 및 라이브러리 액세스

이러한 라이브러리는 다음 버전 이상에서 액세스할 수 있습니다.