本文へスキップ
インサイト一覧に戻る
ECとShopify8 分で読めます

Shopifyのオンラインショップにメガネのバーチャル試着を導入する

机の上に置かれた黒いサングラス。その奥のノートパソコンには、同じフレームの商品ページが開かれています。
商品ページ、試着、カートが、同じバリエーションを示す必要があります。

プラグインをインストールし、3Dモデルを用意して、試着ボタンが動く状態にしても、カタログと整合した連携ができているとは限りません。表示されたフレームのレンズ幅が、オンラインショップで選択したバリエーションのレンズ幅と異なる場合もあります。試着で選んだカラーがカートに引き継がれないことも、新しいコレクションが対応付けから漏れることもあります。連携の品質は、商品のライフサイクル全体を通じて、商品データ、デジタルアセット、テーマの動作がどのように結び付いているかで評価します。

メガネの小売事業者がバーチャル試着を導入する際は、カタログに加わるデジタル表現が、販売する商品と同じものを示す必要があります。Shopifyは販売するバリエーションとそのデータ、注文フローを管理します。バーチャル試着サービスはデジタル表現とその利用を管理します。両者を連携するには、対応付け、販売可否、選択内容、更新について明確なルールが必要です。Shopifyはすでに、対応するテーマで商品メディアとして3Dモデルを表示できます1。ここで扱うのは、顔の上での試着と、販売するバリエーションと承認済みアセットの対応関係を継続して維持するための連携です。

商品カタログと3Dカタログでは状態が異なる

バリエーションは、承認済みの3Dモデルがなくてもオンラインショップで公開できます。逆に、アセットが用意されていても、一時的に販売できない場合があります。これらの状態は区別して扱う必要があります。

Shopifyのデータ構造では、バリエーションに識別子、オプション、販売可否の情報が紐付きます。在庫ポリシーによって、在庫切れの場合に販売を許可するかどうかを設定できます2。3D表現が存在しても、こうした販売上の判断が決まるわけではありません。

そのため、オンラインショップでは試着をいつ表示するかを決める必要があります。購入可能なバリエーションにアセットがない場合は、通常のコンテンツで商品ページを利用できる状態を保ちます。アセットがあっても商品を注文できない場合は、必要に応じて閲覧を可能にし、注文できないことを明示します。判断はラインナップと、そのページの役割によって変わります。現在販売する商品のページか、先行公開か、アーカイブかを踏まえて決めます。

試着の対応範囲は、販売上の対象に含める商品のうち、バリエーションに対応するデジタル表現を実際に試着で使える範囲です。納品済みファイルの一覧と、購入可能な商品の一覧は、それぞれ異なる条件を示しています。公開する試着機能は、その両方を満たす必要があります。

SKUとバリエーションIDは役割が異なる

サプライヤーとのやり取りや共有のLibraryの利用では、SKUやバーコードを使って対応する商品を検索できます。一方、Shopify内では、バリエーションIDが、オンラインショップやカートの操作対象を特定します。

同じサングラスフレームのブラック、デミ、グリーンの3つのバリエーションが白い台に並び、それぞれにタグが付いています。

各バリエーションには固有のコードがあり、それを基に3Dモデルを対応付けます。

ShopifyはSKUとバーコードを明確に区別し、各バリエーションに一意のSKUを使うことを推奨しています。ドキュメントでは、コードの重複が外部サービスとの連携で問題を起こす可能性を指摘しています3。複数のブランドを扱う小売事業者は、そのコードが何を示すかも確認する必要があります。オンラインショップで付与した内部SKUと、メーカーが同じフレームを識別するために使うコードは、異なる場合があります。

対応付けには、これらのコードの間に安定した関係が必要です。商品ページの名称を修正しても、バリエーションの同一性が変わるべきではありません。一方、SKUを変更すると、そのコードでアセットを検索する処理に支障が出る可能性があります。商品を削除して作り直す場合は、オンラインショップの識別子に基づく対応関係を再構築する必要が生じることもあります。

ARShadesのプラグインは、SKU、EAN、UPCを使って対応する3Dモデルを検索します。商品の名称や画像から対応関係を推測することはありません。同期によってLibraryで利用できる3Dモデルへのリンクを作成し、オンラインショップに紐付くARShadesのカタログに保存します4。

実物のカラーやレンズ幅まで確認する必要があります。形式上は有効なコードでも、別のカラーや異なるレンズ幅に対応付けられている場合があります。そのため、データの確認と目視の確認は、互いを補う役割を持ちます。前者は対応関係を確認し、後者はお客様が実際に見る内容を確認します。

選択内容をカートまで一貫して引き継ぐ

お客様は商品ページでカラーを選んでから、バーチャル試着機能のVirtual Try-On(VTO)を開き、試着中にカラーを変更し、その後に注文へ進むことがあります。これらの変更をどのように引き継ぐか、連携の設計時に決める必要があります。

VTOが初期設定のバリエーションで開く場合は、オンラインショップで選んだバリエーションとの関係をページ上で分かるようにします。試着中に別のバリエーションを選べる場合は、商品ページに戻った際に選択を更新するか、あらためて明示的な選択操作を求めるかを決めます。2つの選択内容が食い違っているのに、それを知らせない状態は避ける必要があります。

Shopifyのカートのドキュメントでは、商品の追加にバリエーションIDを使います5。そのため、試着の見た目が正しくても、購入操作で以前の識別子を保持していると、購入フローに誤りが生じる可能性があります。最後に見た画像とカートに追加した商品が、同じバリエーションに対応する必要があります。

有効な確認方法の1つは、複数のカラーと少なくとも2種類のレンズ幅があるフレームを使うことです。特定のバリエーションが選択されるリンクから入り、試着中に選択を変更して、商品名、価格、販売可否、カートの明細を確認します。Shopifyは、?variant=パラメーターで特定のバリエーションに直接リンクする方法を公開しています。このパラメーターがない場合、テーマは選択済みのバリエーションか、最初の購入可能なバリエーションを開くため、確認結果が変わります6。期待する結果は、連携で実際に有効になっている機能によって異なります。VTO内からカートに追加できる場合も、同じ確認が必要です。

同じ原則は、より複雑な度付きメガネの構成にも当てはまります。フレームの試着と度付きレンズの設定は、別々のシステムで行われることがあります。表示するデジタル表現がどの組み合わせを示すのかを明確にし、購入可能なオプションの検証は注文フローで行います。

機能をどこに、どう組み込むかはテーマによって決まる

Shopifyのテーマアプリ拡張は、対応するセクションに配置できるアプリブロックと、重ねて表示する要素やサイト全体で使うコンポーネントにも利用されるアプリ埋め込みを区別しています。アプリ埋め込みはテーマ内で有効化する必要があります。ブロックの追加と、それに関連する連携機能の有効化は、別々の操作になる場合があります7。

この仕組みによって、テーマのファイルを直接編集する必要は減ります。ただし、連携の実装は、使用するテンプレート、ブロックの位置、バリエーション選択のロジック、ページの動的な更新に依存します。オンラインショップでは、カテゴリーやブランドごとに異なるテンプレートを使うことがあります。メインのテンプレートに加えた変更を公開しても、対象の商品ページすべてに反映されるとは限りません。

一部の商品クイックビューのように、ページの一部分だけを更新するコンポーネントでの動作も確認が必要です。テーマはバリエーションの変更時に、選択欄やボタンを置き換えることがあります。連携機能は、操作部品を重複させたり、前の商品への参照を保持したりせず、正しい状態を読み取り続ける必要があります。

これらを確認するには、未公開のテーマで試すことが有効です。一般公開の前には、実際に使うドメイン、割り当てられているテンプレート、スクリプトが起動する条件も確認します。ヘッドレス構成のオンラインショップや、大幅にカスタマイズした購入フローでは、標準テーマへの対応状況に加えて、独自のアーキテクチャで連携を評価する必要があります。

試着の対応範囲は、どの商品に関心が集まるかで変わる

100のバリエーションでバーチャル試着が使えるというだけでは、購買体験のどこまでをカバーしているかは分かりません。その100のバリエーションが、最も需要の高い商品をカバーしている場合もあれば、販売上の重要性が低い商品群にとどまる場合もあります。フレーム数との関係も確認する必要があります。サブスクリプションの上限は商品数ではなく、対応付けたバリエーション数で数えます。100のバリエーションは、20種類のフレームをそれぞれ5色ずつ用意したものかもしれません4。

分析では、試着に対応するバリエーションの割合と、商品ページへの総アクセスに対する、試着できる商品ページへのアクセスの割合を分けて見ることが有効です。後者の算出には、オンラインショップのアクセスデータが必要です。3Dモデルの数だけからは求められません。特に、キャンペーンによって少数の商品にアクセスが集中する場合は、この2つの割合が大きく異なることがあります。

そのため、最初に対象とするフレームを選ぶ際は、販売上の重要性、種類の幅、アセットの有無を合わせて検討する必要があります。再現しやすいフレームだけのラインナップは、初期の技術確認には適していても、カタログ全体におけるサービスの品質について分かることは限られます。半透明のアセテート、細いメタルフレーム、異なるレンズは、それぞれデジタル表現の異なる側面を検証する材料になります。

対応範囲は、時間の経過とともに見直す必要もあります。新しいコレクションを公開しても対応付けが完了していなければ、VTOの3Dモデル数が変わらなくても、試着できる商品ページへのアクセスの割合は下がる可能性があります。カタログの確認は、キャンペーンや新商品の入荷に合わせて行う必要があります。

同期を商品管理の一部として扱う

公開後もカタログは変わり続けます。コードの追加、商品の削除、バリエーションの追加、3Dモデルの修正などが発生します。それぞれの変更は、対応関係の異なる部分に影響する可能性があります。

ARShadesのドキュメントでは、商品の追加、SKUやバーコードの変更、新しい3Dモデルの提供時に、再度同期するよう案内しています。対応付けはARShadesのカタログ上で行い、Shopifyの商品を変更しません4。そのため、同期をラインナップの運用計画に組み込み、担当者を決める必要があります。

サービスを利用できるかどうかは、プラットフォームへのアクセス条件にも左右されます。ライセンス、許可されたドメイン、有効なバリエーションの範囲が関わります。対応付けが正しく、アセットも利用できる商品でも、これらのいずれかに問題があると、試着を開けない場合があります。対処方法が異なるため、確認時にはこの3つを区別する必要があります。

継続できる運用では、新商品の公開時に対応範囲も確認します。どのバリエーションが対応付け済みか、どれがアセットの制作待ちか、どれを試着なしで閲覧可能にしておくかを把握します。フレームの取り扱いを終了する際も、何を表示し続けるか、すでに配布されたリンクをどう扱うかについて、同様の判断が必要です。

購買プロセスの中でサービスを評価する

連携の信頼性を評価する際は、VTOを利用しないお客様への影響も含めます。スクリプトやアセットが、商品ページの閲覧、オプションの選択、通常の購入を妨げるべきではありません。Shopifyのテーマアプリ拡張のドキュメントは、必要なページだけでスクリプトを読み込むことを推奨しています7。Built for Shopifyの要件では、アプリによるストアのLighthouseスコアの低下は10ポイント以内とし、テーマに追加する要素はテーマアプリ拡張で構築するよう定めています8。小売事業者は、どのサプライヤーにもこの基準を求めることができます。初期読み込みの負荷と、試着を開いた際に加わる負荷は、分けて評価する必要があります。

試着を開くお客様にとっては、正しいバリエーションが読み込まれるか、オンラインショップに戻った際に選択内容の整合性が保たれるかが重要です。EC責任者は、売上への影響を解釈する前に、これらを確認する必要があります。試着を選んだお客様の購入率が高くても、それだけで試着機能による因果的な効果が証明されるわけではありません。この点は、パイロットプロジェクトの記事で詳しく解説しています。

オンラインショップに変更が加わっても整合性を維持できて初めて、連携の信頼性が保たれます。そのため、連携の成否は、最初の公開時だけでなく、その後の数週間の作業も含めて判断します。新しいバリエーションの対応付け、コードの修正、更新したテーマの公開を経ても、お客様が注文できるメガネを正しく表示し続けることが求められます。

出典

  1. Shopifyヘルプセンター、商品メディア:3Dモデル ↩

  2. Shopify開発者向けドキュメント、Liquidのvariantオブジェクト:識別子、販売可否、在庫ポリシー ↩

  3. Shopifyヘルプセンター、SKUを使った在庫管理 ↩

  4. Knowledge Base ARShades、New synchronisationとCatalogue synchronisation。 ↩ ↩2 ↩3

  5. Shopify開発者向けドキュメント、Cart APIリファレンス ↩

  6. Shopify開発者向けドキュメント、商品マーチャンダイジング、バリエーション、バリエーションへのディープリンクの項 ↩

  7. Shopify開発者向けドキュメント、テーマアプリ拡張の設定、アプリブロック、アプリ埋め込みブロック、パフォーマンスの各項 ↩ ↩2

  8. Shopify開発者向けドキュメント、Built for Shopify要件、2.2.1ストアの速度への影響の最小化と3.2.1 ↩

共有

この記事を同僚に送ったり、リンクを保存したりできます。