Zendeskメッセージングの会話のマージ：完全な技術ガイド

顧客が複数のチャネルを通じて連絡を取る際、企業は顧客が誰であるかを記憶していることを期待します。しかし、Zendeskメッセージングでは、ユーザーのIDが断片化する可能性があります。顧客がウェブサイトから開始し、WhatsAppで継続し、メールでフォローアップすると、3つの別々のユーザープロファイルが作成されることがあります。ここで、会話のマージが不可欠になります。

Zendeskがユーザーと会話のマージをどのように処理するかを理解することで、シームレスなサポート体験を構築できます。プロセスがどのように機能するか、いつトリガーされるか、効果的に管理するために知っておくべきことを詳しく見ていきましょう。

Zendeskメッセージングにおける会話のマージとは？

Zendeskメッセージングにおける会話のマージとは、別々のユーザープロファイルとそれに関連する会話履歴を、単一の統合されたレコードに結合するプロセスです。適切なマージがないと、エージェントは断片化された顧客とのやり取りを見ることになるため、これは重要です。リピーターの顧客が3人の異なる人物として表示され、エージェントは完全な状況を理解するために複数のチケットを検索する必要が生じる可能性があります。

2つの関連する概念を区別することが重要です。

ユーザーのマージは、2つのユーザープロファイルを1つに結合します。「生き残る」ユーザーはマージされたIDを保持し、「破棄される」ユーザーは削除されます。すべてのプロファイルデータ、メタデータ、および会話履歴は、生き残るユーザーに転送されます。

会話のマージは、特に別々の会話スレッドを単一の履歴に結合することを指します。これは、構成によっては、自動的に行われる場合とそうでない場合があります。

マージプロセスは、複数のデータポイントに影響を与えます。ユーザーがマージされると、プロファイル情報が結合され、競合が発生した場合は、破棄されたユーザーの値が優先されます。メタデータもマージされますが、4KBのサイズ制限内に収まります。クライアントとデバイスのリストは重複排除され、結合されます。最も重要なことは、会話履歴が単一のスレッドにマージされるか、複数会話が有効になっているかどうかによって、別々のままになるかです。

Zendeskはいつ会話をマージしますか？

マージはランダムには発生しません。Zendeskは、3つの特定のメカニズムを通じてマージをトリガーします。それぞれが異なるユースケースに対応します。

API呼び出しによるマージ

ユーザーを手動で結合する必要がある場合があります。Sunshine Conversations APIを使用すると、生き残るユーザーIDと破棄されるユーザーIDを指定して、プログラムでマージをトリガーできます。これは、次のような場合に役立ちます。

• データインポート後の重複ユーザーのクリーンアップ
• サポートチームによって発見されたIDの問題の修正
• ビジネスルールに基づいたカスタムマージロジックの実装

APIマージ呼び出しの基本的な例を次に示します。

POST /v1.1/apps/{app_id}/appusers/merge
{
  "surviving": {"_id": "user_a_id"},
  "discarded": {"_id": "user_b_id"}
}

SDKユーザーに対するAPIマージには注意してください。認証されていないユーザーが認証されたユーザーとマージされると、セッショントークンが失効します。続行するには、新しいJWTが必要になります。2人の認証されたユーザーがマージされると、外部IDに複雑な問題が発生します。ほとんどの場合、認証を通じてZendeskにマージを自動的に処理させる方が安全です。

チャネル転送によるマージ

チャネル転送は、顧客が異なるプラットフォーム間で会話を継続したい場合に発生します。顧客がウェブサイトのウィジェットでチャットを開始したが、離れる必要があるとします。代わりにWhatsAppで継続することを選択します。Zendeskが両方のIDが同じ人物を表していると判断した場合、この転送によってマージがトリガーされる可能性があります。

これらのマージは、次の2つのフローを通じて発生します。

ビジネス主導の転送は、システムがチャネルの切り替えを積極的に提供する場合に発生します。たとえば、顧客がウェブチャット中に電話番号を提供し、SMSで継続することを提案します。顧客がその電話番号の所有権を確認すると、ZendeskはウェブとSMSのユーザープロファイルをマージします。

ユーザー主導の転送は、顧客が自分で会話を継続することを選択した場合に発生します。ウェブサイトでチャットしている顧客が「Messengerで継続」をクリックし、Facebookアカウントを認証すると、Zendeskは2つのセッション間の接続を認識します。

ログインイベントによるマージ

最も一般的なマージトリガーは認証です。認証されていないユーザーがアプリまたはウェブサイトにログインし、そのログインが外部IDを介して既存のユーザープロファイルと一致する場合、Zendeskはプロファイルをマージします。

これにより、シームレスな会話の継続が可能になります。顧客はサイトを匿名で閲覧し、サポートチャットを開始し、会話の途中でアカウントにログインできます。認証後、すべての会話履歴と以前のチケットが1か所に表示されます。

ログインマージで生き残るユーザーは、常に最初に作成されたユーザーです。これにより、新しい認証されていないセッションからのデータを取り込みながら、確立されたユーザーレコードが保持されます。

マージプロセスの仕組み

メカニズムを理解することで、エッジケースを処理し、適切な統合を構築できます。Zendeskがユーザーをマージする際に何がステップごとに発生するかを次に示します。

ステップ1：生存者の選択 何よりも先に、Zendeskはどのユーザーが生き残るかを決定します。APIマージの場合、これを指定します。チャネル転送の場合、転送を開始するユーザーが生存者になります。ログインイベントの場合、古いユーザーアカウントが優先されます。

ステップ2：プロファイルの統合 破棄されたユーザーのプロファイルフィールドは、生き残るユーザーにマージされます。両方のプロファイルに同じフィールド（異なる名前など）の競合する値がある場合、破棄されたユーザーの値が優先されます。signedUpAtタイムスタンプの場合、より早い日付が保持されます。

ステップ3：メタデータのマージ ユーザーメタデータが結合され、破棄された値が競合に勝ちます。ただし、メタデータサイズには4KBの制限があります。マージされたメタデータがこの制限を超えると、Zendeskは適合するまで個々のフィールドを1つずつ破棄します。Webhookイベントは、どのメタデータが削除されたかを通知します。

ステップ4：クライアントとデバイスの統合 両方のユーザーの接続されたクライアント（メッセージングチャネル）とデバイスが、単一の重複排除されたリストにマージされます。生き残るユーザーは、両方の元のユーザーからのすべてのチャネルとデバイスにアクセスできるようになりました。

ステップ5：会話の処理 このステップは、複数会話の設定によって大きく異なります。複数会話が無効になっている場合、会話履歴はタイムスタンプでソートされた単一のスレッドにマージされます。有効になっている場合、ユーザーのマージ後も会話は別々のままになります。

ステップ6：Webhook通知 Zendeskは、生き残るオブジェクトと破棄されたオブジェクトのID、および破棄されたメタデータを含むuser:merge Webhookを発行します。システムはこれらのイベントをリッスンして、それに応じて独自のユーザーレコードを更新する必要があります。

複数会話とマージについて

複数会話機能は、マージの仕組みを根本的に変更します。この設定は元に戻すことができないため、有効にする前にその影響を理解することが重要です。

複数会話なし（デフォルト）

単一会話モードでは、ユーザーが会話の途中で認証を行うと、ユーザープロファイルと会話の両方がマージされます。認証されていない会話は、認証されたユーザーの会話履歴に1つの連続したスレッドとして結合されます。これにより、すべての顧客とのやり取りのクリーンで線形のビューが作成されます。

複数会話が有効になっている場合

複数会話がアクティブな場合、ユーザーのマージは引き続き発生しますが、会話は別々のままになります。認証されたユーザープロファイルは認証されていないプロファイルを吸収しますが、会話は区別されたままです。これにより、同じ根本的な問題に対してチケットが重複して作成される可能性があります。

ここにリスクがあります。ユーザーがログインする前に会話を開始し、認証を行うと、本来1つのサポートインタラクションであるはずのものが2つのチケットになってしまいます。エージェントは、これらのチケットを手動で特定してマージする必要があります。

また、容量制限もあります。認証されていないユーザーは無制限のアクティブチケットを持つことができますが、認証されたユーザーは一度に100個のアクティブチケットに制限されています。認証されたユーザーがこの制限を超えると、Zendeskは最近のアクティビティに基づいて、どの会話に緑色のチェックマークアイコンを表示するかを優先します。

ベストプラクティス：早期認証

チケットの重複シナリオを回避するには、可能な限り、メッセージングを開始する前にユーザーを認証してください。ウェブサイトまたはアプリでログインが必要な場合は、会話が開始された後ではなく、メッセージングウィジェットがロードされたときにすぐに認証をトリガーします。

認証、ID、および確認済みのメールフロー

Zendeskメッセージングにおける最大の課題の1つは、ユーザーの重複作成です。長年にわたり、管理者は認証されたユーザーが既存のユーザーにリンクする代わりに新しいプロファイルを作成することに苦労してきました。Zendeskは、確認済みのメールIDを通じてこれに対処しました。

問題：未確認のIDリスク

以前は、認証されていないユーザーが既存のプロファイルと一致するメールアドレスを入力した場合、Zendeskはその会話を既存のユーザーにリンクしていました。これにより、セキュリティの脆弱性が生じました。誰でもメールアドレスを入力するだけで、別の顧客になりすますことができました。

解決策：確認済みのメールID

Zendeskは現在、確認済みのメールIDと未確認のメールIDを区別しています。確認済みのメールとは、ユーザーがJWTを通じて認証し、そのメールアドレスの所有権を証明したことを意味します。エージェントは、確認済みのユーザーの横に緑色のチェックマークが表示され、IDを信頼できることを示します。

簡略化された48以上のフローシナリオ

専門家による分析では、約48種類の認証フローの順列がマッピングされました。完全なマトリックスは複雑ですが、ほとんどの現実世界のシナリオは、次の2つの結果に集約されます。

認証済み+確認済み=プロファイルがリンク ユーザーが既存のZendeskユーザーと一致するexternal_idを使用してJWT経由で認証し、そのユーザーが確認済みのメールを持っている場合、会話は既存のプロファイルにリンクされます。エージェントには、緑色のチェックマークと完全な会話履歴が表示されます。

その他すべてのシナリオ=新しいプロファイルが作成 認証されていないユーザー、または一致するexternal_idのない認証されたユーザーは、新しいユーザープロファイルを作成します。これらのプロファイルには、緑色のチェックマークの確認ステータスがありません。

構成オプション

管理センターの[メッセージング] > [設定] > [詳細設定]で、メールIDオプションを見つけることができます。

• 「確認済みのメールのみを使用する」（新しいデフォルト）：最大のセキュリティ。確認済みの認証されたユーザーのみが既存のプロファイルにリンクされます。
• 「確認済みのメールと未確認のメールの両方を使用する」（従来の動作）：セキュリティは低いですが、認証されていないユーザーがメールの一致を介してリンクできます。

新しいZendeskアカウントは、デフォルトで安全なオプションになっています。既存のアカウントは、手動で調整する必要がある場合があります。

会話のマージを管理するためのベストプラクティス

技術的な詳細を検討した後、実装に関する実用的な推奨事項を次に示します。

早期かつ一貫して認証します。 会話の開始後ではなく、メッセージングウィジェットが初期化されたときにJWT認証をトリガーします。これにより、チケットの重複の問題を完全に防ぐことができます。

user:merge Webhookを処理します。 マージイベントを受信して処理するロジックを構築します。Zendeskからマージの通知を受け取ったときに、内部ユーザーレコードを更新して、システム全体のデータの一貫性を維持します。

重複のクリーンアップを計画します。 複数会話を使用する場合は、遅延認証によって作成されたチケットを特定して手動でマージするようにエージェントをトレーニングします。潜在的な重複にフラグを立てるのに役立つ自動化ルールを検討してください。

ステージングでマージフローをテストします。 本番環境に移行する前に、ステージング環境でマージシナリオをシミュレートします。認証が適切なリンクをトリガーし、チャネル転送がスムーズに機能し、Webhookハンドラーが正しく応答することを確認します。

認証の決定を文書化します。 メールID設定の複雑さは、チームが選択した構成とその理由に関する明確なドキュメントを必要とすることを意味します。一般的なIDの問題のトラブルシューティング手順を含めます。

代替アプローチを検討します。 Zendeskは強力なマージ機能を提供しますが、一部のチームは、AI搭載のサポートプラットフォームが、複雑なマージロジックやJWTの実装を必要とせずに、クロスチャネルIDの解決をよりシームレスに処理することを発見しています。eesel AIのようなソリューションは、複雑なマージロジックやJWTの実装を必要とせずに、チャネル全体の顧客コンテキストを自動的に統合します。

Zendeskセットアップで会話のマージを実装する

これを実際に試してみる準備はできましたか？実装チェックリストを次に示します。

複数会話を有効にする前に：

• 認証フローが正しく機能することを確認します
• JWTトークンにユーザーデータベースと一致するexternal_idが含まれていることを確認します
• 遅延認証シナリオでユーザーエクスペリエンスをテストします
• 決定を文書化します（元に戻すことはできません）

API統合チェックリスト：

• user:merge Webhookハンドラーを実装します
• 新しいユーザーを作成する前に、既存のユーザーをクエリするロジックを構築します
• マージ関連のエラーの監視を追加します

避けるべき一般的な落とし穴：

• IDにメールの一致のみに依存しないでください（セキュリティリスク）
• チケットへの影響を理解せずに、会話の途中でユーザーを認証しないでください
• マージ中に4KBのメタデータ制限を無視しないでください
• マージが発生したときに独自のシステムを更新することを忘れないでください

詳細については、次のリソースを参照してください。

• ユーザーのマージに関するZendesk開発者ドキュメント
• アプリケーションでのユーザーの認証
• 複数会話構成ガイド