CRM 개인화로 AI 커머스 검색 강화

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

맞춤설정을 위한 데이터 선택

맞춤설정의 효과는 제공하는 CRM 데이터의 품질, 범위, 관련성에 달려 있습니다. 지식이 풍부한 영업 담당자가 제공할 수 있는 검색 결과에 실제로 영향을 미치는 고객에 관한 정보를 고려하세요.

파일럿 테스트를 완료하면 어떤 데이터가 영향을 미치고 어떤 데이터가 영향을 미치지 않는지에 관한 더 강력한 권장사항을 얻을 수 있습니다.

이러한 데이터 카테고리는 커머스 사이트 사용자 행동에 관한 가장 중요한 정보를 구성합니다.

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

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

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

  • 구매 내역에서 파생된 속성:
    • 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 및 라이브러리 액세스

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