【WhatYa】会員情報連携のトラブルシューティング
WhatYa
サンプルコードについてのご留意事項
後述するサンプルコードは、お客さまがご利用のECパッケージの仕様に合わせてカスタマイズが必要なことがあります。
カスタマイズ内容やカスタマイズ後の挙動については、サポート対象外となりますことご了承ください。
WhatYaで会員情報連携を設定したがうまくいかない
前提条件
このトラブルシューティングは、弊社担当からお渡ししている「WhatYaV2_会員情報連携」をお読みいただき会員情報連携の設定を実施しても、うまくいかなかったベンダー様を対象としています。
WhatYaで会員情報連携をするには、data-cs-id(id) と data-cs-secret(パスワード)の設定が必須です。
また、このトラブルシューティングは、はじめに以下用語と概念を理解しておく必要がございます。
会員情報連携の用語
会員情報連携の用語
青の部分
青の部分はマスターキーワードと言います。こちらは、連携する情報の「項目」にあたります。
「data-cs-id」と「data-cs-secret」は固定になりますので名称変更できません。
緑の部分
青の部分はマスターキーワードの「値」と言います。こちらは来訪者ごとに変わる顧客情報です。
以下の例は、data-cs-idにログインしたユーザーの「会員No.」連携させ、data-cs-secretにはユーザー毎にパスワードを発行しています。
※idとパスワードの値、どちらかが変わってしまうとルームが別れますのでご注意下さい。
会員情報連携の概念
会員情報連携は以下の仕組みを使って、接客管理画面に連携された情報を送信しています。まず、この概念図と認識の相違がないかをご確認下さい。
埋め込みタグの情報「data-cs-id」の値を会員番号の情報としてそのまま接客管理画面に送信します。
そして「data-cs-id」の値をユニークユーザーのキーとして、来訪者を毎回特定します。
こうする事でブラウザの「Local storage」の情報を利用せず個人を特定できるので、アクセスするデバイスが変わっても、来訪者を特定できる仕組みになっています。
よくある質問とトラブルシューティング
jQueryでスクリプトを作ってしまうと「data-cs-id」と「data-cs-secret」を認識しませんので、jQueryを利用しない方法でScriptを作成して下さい。
一般的に多くのクライアント様で、data-cs-idをメールアドレス、data-cs-secretをECパッケージ側が保持している何かしらのユニークコードで設定しているケースが多く見られます。
※data-cs-secretにユーザーログインパスワードを設定するのはセキュリティ上問題が想定されますので、お控えいただきますようお願い致します。
結論から先にお伝えすると、初回ログイン時のみ、ログが引き継がれる仕様となっております。
内部の仕組みとしては、初回ログイン時はチャットボタンクリック時に生成されるID(whatya_id)でユーザーを特定し、アノニマスの時に生成されたID(whatya_id)はルームの引き継ぎ時に削除されます。
※イメージ図1
その後2回目以降のログインの場合は、cs-id&cs-secretでユーザーを特定します。
そのため、デバイスをまたいでも、cs-id&cs-secretが同一である限りは同一のルーム、同一のログで会話が可能となります。
※イメージ図2
前提として、非ログイン⇒初回ログインは会話内容を引き継ぎます。詳しくは上記の回答をご確認ください。
その上で、過去の会話が出てこない場合は、ルームが継続されず、新しくなっている為です。
よくあるケースとしては
デバイス、ブラウザが違う
シークレットモードを使っている
ログインをしていない、もしくは、ログインをしている
などが考えられます。
前提としてWhatYaは、
ユーザーがログインしているときは、WEBサイトから連携された情報(cs-id&cs-secret)を利用して来訪者を特定し、
ユーザーがログアウトしているときは、LocalStorageの情報で来訪者を特定し、会話を継続します。
その為、ログイン時、ログアウト時は、それぞれ来訪者は別々のルームになります。
以下に詳細を例示します。
ユースケース1:前回訪問時にログインをしてチャットを使ったが、次回訪問時はブラウザの影響でログアウトしていて、会話ログがログアウト時の会話ログになっているケース
この場合、ログインしたときはWEBサイトから連携された情報(cs-id&cs-secret)を使って来訪者を識別しますが、ログアウトしたときは、LocalStorageで発行したID(whatya_id)を利用されているため、別ルームになっています。
ユースケース2:サブドメインが異なるサイトで、ログアウトした状態でチャットを利用したケース
以下の様な場合、最初からログアウトされている為、会員情報が連携ができない上に、ドメインが変わった事により、LocalStorageも継続できない為、別ルームとなっています。
「会話ログが消えた」というお問い合わせについては、顧客がログインとログアウトを繰り返していたり、最初からログアウトしてる事が理由により起こりますので、顧客のログイン状況をご確認下さい。
会員情報連携の機能は、ログイン時の会員情報を埋め込みタグに連携させます。従って、未ログイン時は連携する情報がないため、会員情報の連携ができません。
会員情報を連携を導入する際、動的に未ログイン時はID連携のタグを表示させず、通常のタグを表示させる導入方法がよく使われています。
※詳細は「WhatYa 会員情報連携資料」のP15の「ログインしていないとき」の手順をご確認下さい。
ログインしていないユーザーのルームが毎回変わってしまう
会員情報連携はログイン時は会員情報連携のタグ、未ログイン時の場合は、会員情報連携のない通常のタグになるなどの処理を組み込む必要がございます。
この問題は、未ログイン時のユーザーにこの処理が入っていない場合に起きます。
例えば以下のような処理を入れます。※こちらはあくまで例になりますので、未ログイン時にの対処法については開発ベンダー様にご相談下さい。
ログイン時の埋め込みタグの例
<script
src='https://whatya.solairo-api.com/sola3/chat.js'
data-cs-id=‘xxxxxx’
data-cs-secret=‘xxxxxxx'>
</script>
※太字部分はお客様ごとに異なります。
未ログイン時の埋め込みタグの例
※未ログイン時はログイン時の赤字部分が表示されない、もしくは無効になるようにします。
<script src="https://whatya.solairo-api.com/sola3/chat.js"></script>
※太字部分はお客様ごとに異なります。
会員情報の連携のタグを埋めたがルームに情報が届かない
会員情報連携のタグは埋めているのに、接客管理画面を確認すると以下のようにルームに情報が届いていない場合は、以下の解決策を参考にして下さい。
考えられる可能性
上記のような事象の場合、何らかの原因でタグの「値」部分の連携が正しくされていません。
この事象の原因の殆どが以下である事が報告されています。
ログイン後のタグが、会員情報連携の部分が無い通常のタグになってしまっている
会員情報連携の「値」となる部分が正しく連携されていない
ベンダーと担当者間のやり取りに齟齬があり、確認する場所を間違えている
(例)ベンダー側は、ステージング環境に会員情報連携のタグを埋めたが担当者は本番環境を見ていた等
接客管理画面側の設定がされていない
この場合は、以下の方法で本当に会員情報連携が正しく設定されているか、確認する事ができます。
切り分け方法
切り分けの方法として、以下の方法を利用すると、サイトから連携した情報が送信されているかを確認する事ができます。
①画面上で右クリックして「検証」からデベロップルールを開きます。
②デベロップツールの「Network」の「ALL」を選択して、F5キーを押してページをリロードします。
③リロード後「initialize」>「Request Payload」を展開して、id連携タグに指定した値が表示されているかを確認します。
タグの指定がただしく設定されていれば、paramsForPutSignInの中に「id」「pw」が表示されます。
もし、タグの指定が間違っている場合は、以下3つの例のようにidもしくはpwを認識しません。
以下のように表示された場合、タグを埋め込んだページにマスターキーワードと値が正しく設定されていない可能性がありますので、連携の開発を実施いただいたベンダー様に以下をご確認下さい。
ログイン時は会員情報連携のタグ、未ログイン時は会員情報連携がない通常のタグになっているか?
変数などで設定した値はちゃんと連携されているか?
タグの記述に間違いはないか?
タグを埋め込んだページを間違えてないか?
※タグの指定が間違っている場合の例1
※画像はSigninを開いていますが、initializeを開いてください。
※タグの指定が間違っている場合の例2
※画像はSigninを開いていますが、initializeを開いてください。
※タグの指定が間違っている場合の例2
※画像はSigninを開いていますが、initializeを開いてください。
未ログイン時のようにid連携をしていない場合は、idとpwがnullになっている事が正常です。
正しい設定例
弊社の検証用のサイトにID連携を設定してますので、デベロップツールで確認をしてみて下さい。
※こちらはあくまでサンプルとなりますので、変数やScriptのサポートは出来ませんのでご了承下さい。
なお、このサイトは、ECCUBE4系でif文と変数で、動的にタグを条件で変更しています。
{# 会員としてログインしている場合の処理 #}
{% if is_granted('ROLE_USER') %}
{# trueの場合の表示 #}
<script src="https://whatya.solairo-api.com/sola3/chat.js"
data-cs-id="{{ app.user.email }}"
data-cs-secret="{{ app.user.secret_key }}"
data-cs-name="{{ app.user.name01 }}{{ app.user.name02 }}"
></script>
{% else %}
{# falseの場合の表示 #}
<script src="https://whatya.solairo-api.com/sola3/chat.js"></script>
{% endif %}
Google Tag Manager 移行後も継続して会員情報連携をご利用いただく場合には、現在のサイト上での会員情報の受け渡し方法やGoogle Tag Manager の運用方法によって、実現の可否や対応策が異なってきますので、詳細はベンダー様にお問い合わせください。