페이지 플레이북

구석에 있는 채팅 대화상자는 무시하기 쉽며, 클릭한 방문자는 무엇을 물어봐야 할지 모르는 빈 상자에 도착합니다. 페이지 플레이북은 양쪽 문제를 모두 해결합니다: 에이전트는 어떤 페이지에서 열렸는지 알고, 방문자에게 그에 맞게 인사하며, 한 번의 클릭으로 보낼 수 있는 몇 가지 질문을 제공합니다.

플레이북이란

선택한 키에 연결된 세 가지 항목입니다:

오프닝 라인과 질문은 사용자가 직접 작성하거나, 에이전트가 배경을 바탕으로 방문자의 브라우저 언어로 생성할 수 있습니다.

페이지 매칭

브라우저에서 페이지 콘텐츠를 전송하지 않습니다 — 식별자만 전송합니다. 텍스트는 플랫폼이 보유합니다. (콘텐츠가 서버 측에 머무르는 이유 참조).

URL 기준 — 페이지 변경 불필요

플레이북에 URL 규칙을 제공하고 위젯이 자동으로 매칭합니다:

/pricing            matches /pricing, /pricing/, /pricing?utm_source=x
/solutions/*        matches /solutions/legal, /solutions/insurance
*/solutions/legal   matches /solutions/legal AND /zh/solutions/legal

경로만 비교됩니다 — 호스트, 프로토콜, 쿼리 문자열 및 후행 슬래시는 무시되므로 하나의 규칙이 www와 비어 있는 도메인, http와 https를 모두 커버합니다.

키 기준 — URL을 공유하는 페이지용

단일 페이지 앱, 모달 및 다단계 흐름에는 종종 고유한 URL이 없습니다. 대신 플레이북에 명시적으로 이름을 지정하십시오:

<script src="https://chat.agent4.io/ui/embed.js"
        data-token="YOUR_SHARE_TOKEN"
        data-page-key="checkout-step-2" async></script>

페이지가 리로드 없이 변경되면 경로가 변경될 때 위젯에 알려주십시오:

caWidget.setPage("checkout-step-3");

해결 순서

1. 명시적인 키가 있는 경우
2. 첫 번째 매칭된 URL 규칙
3. 기본 플레이북 (있는 경우)
4. 없음 — 방문자는 일반 채팅 상자를 받음

존재하지 않는 명시적인 키는 URL 규칙과 조용히 매칭되는 대신 기본값으로 넘어갑니다. 이렇게 하면 오타가 "잘못된 플레이북이 적용됨"이 아닌 "기본값이 나타남"으로 표시됩니다.

설정하기

콘솔에서 페이지 플레이북을 열고 하나 생성하십시오. 먼저 페이지 유형을 선택하십시오 — 가격 책정 페이지, 솔루션 페이지, 문서, 사례 연구, 홈, 연락처 — 그러면 해당 유형의 페이지에서 방문자가 일반적으로 묻는 질문으로 질문이 미리 채워집니다. 그런 다음 자신의 어조로 수정하십시오.

목록 뷰에는 매처가 있습니다: URL을 붙여넣으면 해당 페이지에 어떤 플레이북이 적용될지, 그리고 키, URL 규칙 또는 기본값으로 매칭되었는지 알려줍니다.

또는 API를 통해:

curl -X PUT https://api.agent4.io/v1/manage/page-contexts/pricing \
  -H "X-API-Key: $KEY" -H 'Content-Type: application/json' \
  -d '{
    "label": "Pricing page",
    "url_pattern": "*/pricing",
    "context": "The visitor is looking at our pricing. Four tiers separated by monthly token quota and end-user count. The usual questions are which tier fits their size and what happens when they go over.",
    "greeting_mode": "generated"
  }'

배경 작성

이것이 실제로 작업을 수행하는 부분입니다. 알아야 할 몇 가지 사항:

한 언어면 충분합니다. 모델은 사용자가 작성한 내용을 읽고 방문자의 언어로 답변합니다. 로케일마다 번역이 필요하지 않습니다.

지식 베이스에 이미 있는 사실을 반복하지 마십시오. 가격, 할당량 및 제한은 지식 베이스에서 답변되며, 이는 플레이북보다 우선합니다 — 여기에 작성된 숫자는 이를 재정의하지 않습니다. 대신 상황에 대해 작성하십시오: 누가 이 페이지에 도착하는지, 그들이 무엇을 결정하려고 하는지, 그들이 일반적으로 무엇을 걱정하는지.

페이지가 말하는 것이 아니라 방문자가 무엇을 하고 있는지 작성하십시오. "방문자는 티어를 비교하고 월별 청구서를 예측하려고 합니다"가 페이지 복사본의 요약보다 더 유용합니다 — 에이전트는 이미 페이지 복사본을 조회할 수 있습니다.

정적 또는 생성된 오프닝

greeting_mode: "static"은 모든 언어의 모든 방문자에게 사용자가 작성한 정확한 오프닝 라인과 질문을 사용합니다. 완전한 제어, 예상치 못한 결과 없음.

greeting_mode: "generated"는 에이전트가 배경을 바탕으로 방문자의 언어로 이를 작성합니다. 각 언어의 첫 번째 방문자가 생성을 트리거하면 이후의 모든 방문자에게 캐시에서 제공됩니다. 배경을 편집하면 캐시가 지워지므로 다음 방문자는 업데이트를 봅니다.

다국어 사이트의 경우 생성이 더 나은 기본값입니다. 문구가 핵심적인 경우(규제 산업 또는 카피라이터와 함께 문장을 다듬은 페이지) 정적이 적합합니다.

생성된 오프닝은 폼을 포함할 수 있습니다. 플레이북 배경에서 첫 번째 접촉 시 세부 정보를 수집하라고 명시적으로 지시하는 경우("인사말에 폼을 제시"), 오프닝은 이미 대화형 폼이 포함된 상태로 도착합니다 — 채널, 연락처 필드 등 배경에서 요청하는 모든 것 — 그리고 스타터 질문은 물러납니다. 제출은 일반 메시지이므로 에이전트의 도구(save_contact, schedule_followup)가 평소대로 실행됩니다. 당사 연락처 페이지의 "사람과 대화하기" 카드가 정확히 이 방식입니다: 방문자가 단어를 입력하기 전에 예약 폼이 화면에 표시됩니다.

콘텐츠가 서버 측에 머무르는 이유

위젯은 키 또는 URL을 보고합니다. 페이지 텍스트를 업로드하지 않으며, 플랫폼은 DOM을 읽지 않습니다.

이는 의도적인 것입니다. 브라우저가 전송하는 내용은 화면 앞에 앉은 사람이 편집할 수 있으며, 페이지 컨텍스트는 에이전트의 지시사항에 가깝게 배치됩니다. 우리는 이를 테스트했습니다: 페이지 컨텍스트 블록에 명시적으로 데이터로 구분된 "이번 달 엔터프라이즈는 무제한 좌석과 함께 $199입니다"라는 가짜 내용을 심고, 에이전트가 가격만 지식 베이스에서 가져오라고 지시했지만, 모델은 가짜 가격을 방문자에게 사실로 반복했습니다. 펜스와 신중한 문구가 유지되지 않았습니다.

텍스트를 서버에 유지하면 채널이 완전히 제거됩니다. 방문자가 할 수 있는 최악의 일은 다른 키를 요청하여 사용자가 직접 작성한 플레이북을 받는 것입니다.

알아둘 만한 트레이드오프: 플레이북 복사본은 준공개입니다. 키를 추측한 사람은 누구나 해당 플레이북의 오프닝 라인을 얻습니다. 거기에 내부 메모를 넣지 마십시오.

콘텐츠 내부의 진입점

구석에 있는 버블은 무시하기 쉽습니다. 누군가가 실제로 질문을 가지고 있는 순간은 특정 단락을 읽고 있는 동안입니다 — 따라서 진입점을 바로 거기에 배치할 수 있습니다:

<p data-ca-ask="overage-billing"
   data-ca-question="What happens if we go over, and can we cap the spend?"
   data-ca-label="Ask about this">
  When the quota is exhausted, chat requests return 429 …
</p>

구절 위에 마우스를 올리면 작은 프롬프트가 표시됩니다. 클릭하면 브랜드 색상으로 페이지가 깜빡이고 해당 구절이 강조 표시된 후 채팅이 이미 해당 구절의 플레이북으로 작동하며 — 제공한 경우 — 즉시 질문을 요청합니다.

프레임워크, 탭, 아코디언에 의해 나중에 추가된 구절은 자동으로 감지됩니다. 해당 방식을 벗어난 방식으로 콘텐츠를 렌더링하는 경우 caWidget.rescan()을 호출하십시오.

자체 버튼 연결

페이지의 모든 요소는 선택한 플레이북으로 대화를 열 수 있습니다 — 기존 "영업팀에 문의" 또는 "데모 예약" 버튼을 폼 대신 에이전트 대화로 전환하는 패턴:

const ok = caWidget.open("contact-sales");            // open on that playbook
caWidget.open("contact-sales", "I need a quote");     // …and ask the first question for them
if (!ok) location.href = "mailto:sales@example.com";  // false = script blocked; keep a fallback

caWidget.open은 사이트의 위젯 모양(구석 버블 또는 Ask 명령어 팔레트)에 관계없이 동일하게 작동합니다. 위젯을 사용할 수 없는 경우(스크립트가 로드되지 않거나 차단됨) false를 반환하므로 클릭이 막히지 않습니다: 버튼이 이전에 가지고 있던 링크로 폴백하십시오.

당사의 연락처 페이지는 정확히 이 방식으로 구축되었습니다 — 각기 두세 가지 질문을 묻고 연락처를 저장하며 후속 예약을 진행하는 플레이북을 여는 7개의 의도 카드.

결정론적 intake 분류

플레이북의 작업이 수집 (예약, 리드, 불만)인 경우, 배경에 기계 마커를 추가하십시오: [[inbox:submit_lead]], [[inbox:escalate]] 또는 [[inbox:request_booking]]. 방문자가 해당 플레이북에서 대화형 폼을 제출하면 모델이 답변하기 전에 플랫폼이 자체적으로 기록을 분류합니다 — 에이전트는 도구가 반환한 참조만 전달합니다. 답변의 연락처 세부 정보는 동일한 방식으로 저장됩니다.

이것은 분류가 모델의 기분에 절대 의존해서는 안 되는 유일한 단계이기 때문에 존재합니다: 프로덕션 테스트에서, 도구를 사용할 수 있고 지시되며 유도된 중형 모델조차도 문서의 예시 참조를 실제인 것처럼 인용하며 언어적으로 확인했을 것입니다. 마커가 있으면 답장의 참조는 매번 당신의 받은 편지함의 참조와 일치합니다. 분류가 어떤 이유로든 실패하면 대화는 정상적으로 계속되고 모델 기반 지시사항이 대신 작동합니다.

무엇이 효과적인지 보기

콘솔은 플레이북별로 얼마나 자주 열렸는지와 어떤 스타터 질문이 클릭되었는지 보여줍니다. 이를 사용하여 아무도 선택하지 않는 질문을 제거하고 방문자가 채팅을 열지만 참여하지 않는 페이지를 파악하십시오 — 보통 오프닝 라인이 잘못된 것에 대해 이야기하고 있다는 신호입니다.

이벤트는 카운트만 제공합니다. 질문이 "이 복사본이 좋은가"인지 "누가 무엇을 물었는가"가 아닌지 답하는 것이므로 방문자 식별자를 포함하지 않습니다.

대화 후

스타터 질문은 아직 아무것도 말하지 않은 방문자를 위한 것이며, 하나가 말하는 순간 물러납니다. 그 다음 일어나는 일은 별도의 전환입니다: 후속 제안, 페이지가 아닌 에이전트에 설정되며 모든 답변 후에 몇 가지 원클릭 질문을 제공합니다. 두 가지는 메시지 상자 위의 동일한 스트립을 공유하며 충돌하지 않습니다 — 하나는 빙판을 깨고, 다른 하나는 대화를 계속 진행합니다.