拡散できる診断か、買ってもらえる診断か——おすすめ診断アプリをShopifyストアの中に作り直した

機能が欲しくなると、まずアプリを探す

ユーザーのおすすめ診断、シミュレーター、条件を選ぶと結果が出る小さなツール。ストアにこういう仕掛けが欲しくなったとき、たいていまず開くのはアプリストアです。入れれば動く。作らなくていい。自然な入口だと思います。

PASS COFFEEにはいくつかの質問からユーザーに合うコーヒーを診断するコンテンツを実装しています。 そのおすすめ診断も最初はNext.jsを使って、ストアとは別サーバーで動いていました。アプリストアからインストールしたわけではなく、自分たちで構築したおすすめを診断するWebアプリをストアの画面にモーダルで重ねて表示する形です。

外に置いたのには理由があります。おすすめ診断が単体のページとして住所を持つので、Instagramのプロフィールなどストアの外で診断アプリを開けました。診断で遊んでもらってそこからストアに来てもらう。ストアの中に閉じていたらこの入口は作れません。

ただ、モーダルの中身はストアとは別のサイトのままでした。

埋め込んだ画面は、ストア本体と別扱いになる

別ドメインのページを埋め込むと、埋め込んだ側とストア本体は互いに直接触れません。ブラウザ側の制約なので、実装を丁寧にすれば済む話ではありません。

診断が「これのコーヒーがおすすめ」と出しても、その商品をストアのカートに直接は入れられません。埋め込み側からカートを呼んでも、同じ訪問者のカートとして扱われないからです。

モーダルの高さも合いません。コンテンツが何ピクセルになったかをストア側は知ることができない。当初は決め打ちの数値で指定していたので、画面幅や答えの長さが変わるたびに余白が余ったりスクロールが発生したりしました。

計測も切れます。埋め込みの中での操作はストア側の解析からは見えません。診断を触った人がそのまま買ったのかどうかが、そこで途切れます。

その課題を越える道はあります。埋め込み側とストア側でメッセージをやりとりする仕組みを作れば、カートも高さも渡せる。ただ、その受け取り役はテーマに書くことになります。外に置いたままつなごうとするほどテーマのコードは増えていく。

公式アプリでも同じです。分かれるのはアプリかどうかではなく、別ドメインの埋め込みなのかテーマの中で動くのか。テーマの中で動くタイプならこの制約はありません。

分かれ目は、管理画面にあるデータだけで作れるか

この診断は、本当に外で動かさないと作れない機能なのか。

やっているのは4つの質問に答えてもらってユーザーの好みに近い商品を出すこと。使うのは商品の情報と味の情報だけで、どちらもすでにShopifyの管理画面にあります。買う部分もストアのカートがそのまま使える。

もちろん、外の仕組みが要る機能はあります。決済や配送、在庫の連携のようにストアの外とつながることが目的のもの。自分たちで作り続けるほうが割に合わないもの。そこは迷わずアプリに任せていい領域です。

迷ったのはInstagramから直接開ける入口のほうです。外に置いていたから作れていた導線で、中に作ればそれが無くなります。それでも、来てくれた人が買うところまでスムーズにたどり着けないほうが痛い。そう考えてストアの中に作り直しました。

分かれ目はその機能が管理画面にすでにあるデータだけで作れるかどうか。作れるならストアの中で動かす道が選べます。

ストアの中に作り直したら、つながった

そこで別サーバーをやめて、ストアのテーマに診断機能そのものを作り直しました。埋め込みではなくストアの一部になります。境目が無くなるのでデータを渡す仕組みも要りません。

カートも直接つながります。結果の画面から量や挽き方を選んでそのままストアのカートに商品が入る。ユーザー経路も追えます。どの注文が診断を通って生まれたかは注文のデータに残り、診断から購入までの流れもふだん使っている解析でそのまま見えます。注文や顧客情報のメタフィールドに診断結果を記録しておけば今後の展開にも選択肢が広がります。

新しく増やしたものはありません。診断のために動かしていたサーバーは止めました。

そのかわり、Instagramのプロフィールから診断だけを直接開くことはできなくなりました。ストアに来てもらってから触ってもらう形です。

どの豆をすすめるかは、コードに書いていない

自分たちで作ると聞くと、あとから触れなくなるのが心配になります。担当者が変わったら誰も直せない。文言をひとつ変えるだけで依頼と待ち時間が発生する。作り方によっては実際そうなります。

そこは線の引き方で避けられます。診断が使うデータをコードの中に持たせませんでした。商品ごとの味わい、つまり酸味・甘み・香りの3つは管理画面から編集できる置き場（メタオブジェクト）にあります。診断はそれを読んで答えにいちばん近い商品を選ぶ。どの答えならどの豆、という対応表はどこにも書いていません。

だから商品が増えても減っても診断がついてきます。新しい豆に味わいデータを登録すれば、その日から診断の候補に入る。売り切れたものは候補から外れる。診断のためのメンテナンスが別に発生しません。

味の値を直せばおすすめの出方が変わります。診断の見出しやはじめるボタンの文言もテーマの編集画面から書き換えられる。どれもコードを開かずに済みます。

作るところはコードでも動かし続けるところは管理画面に残す。この線を引けたのは商品のデータに直接手が届く場所で動いているからです。外部から毎回取りに行く作りなら保守コストを鑑みてここまで踏み込んで作り込めなかったと思います。

仕掛けは、つながる状態で出す

以前、インタラクティブな仕掛けは計測とセットで作る話を書きました。今回はその一歩手前です。そもそも、どこで動かすか。

機能が欲しくなったら入れる前に一度だけ立ち止まる。これは管理画面にすでにあるデータだけで作れるのか。そして、その仕掛けをストアの外にも持ち出したいのか。

外に置いて人を連れてくる役をさせたいなら、外に置く理由はあります。そうでないならストアの中で動かしたほうがつながる。カートにつながって買われたかどうかまで追えて更新も管理画面に残る。

PASS COFFEEは連れてくる役を手放してつながるほうを取りました。迷ったときに選んだのは、そのあと管理し続けやすいほうです。

今回はっきりしたのは、置き場所は見た目の問題ではないということです。どこまでつながるか、そのあと誰が触れるか。決まるのはそこでした。