ストアの要件から始める
カスタムストアフロントはデリバリー上の選択であり、それ自体が目的ではありません。ビジネスが現在実現できない動作を書き出してください：製品コンフィギュレーター、編集的な購買体験、顧客ポータル、またはバックオフィスシステムとの統合などです。その上で、テーマの変更や特定のアプリでそれを満たせるかどうかを確認します。
ヘッドレスShopifyは、顧客向けのストアフロントをコマースバックエンドから分離します。ShopifyはこのアプローチのためにStorefront APIとHydrogenツールを提供しています。その柔軟性は、チームがストアフロントアプリケーションを保守しなければならないことも意味します。チェックアウトやプランの制限が自動的に取り除かれるわけではありません。 Shopifyのヘッドレスに関するドキュメント を対象範囲の機能とプランに照らして確認してください。
3つの範囲を比較する
- テーマ作業： 既存のストアに適合するマーチャンダイジング、コンテンツ、ナビゲーション、レイアウトの変更。別のランタイムを導入する前に、既存のアプリとテーマのパフォーマンスを評価します。
- 統合作業： Shopifyと別のビジネスシステムの間で移動する在庫、注文、顧客記録、またはフルフィルメント。そのようなワークフローの多くは、現在のストアフロントを維持できます。
- カスタムストアフロント： 別個のアプリケーション開発、プレビュー、ホスティング、継続的な保守を正当化できるほど十分に独自性のある顧客体験。
例：在庫と注文の引き渡し
卸売業者が注文を自社のフルフィルメントシステムにコピーし、在庫水準をストアに返す必要があるとします。最初の成果物は、製品識別子、在庫の所有権、注文状態のマッピングであるべきです。注文が編集、キャンセル、または二重に処理された場合に何が起こるか、またスタッフが失敗した転送をどのように調整するかを定義します。ストアフロントを置き換えても、それ自体でこれらの問題が解決するわけではありません。
準備すべきもの
ストアのURL、現在のテーマとアプリのリスト、ターゲット市場、カタログの例、関連するシステムを用意してください。利用可能な場合はサンドボックスへのアクセスと、在庫と注文がどう動作すべきかを決定できるビジネスオーナーを提供してください。最初の問い合わせで本番の認証情報を共有することは避けてください。
有用な提案は、顧客体験をデータ移行、プラットフォーム統合、分析、受け入れテスト、保守から分離します。チェックアウトの制限、プラン確認が必要なサブスクリプションやB2Bの要件、デリバリーに影響し得るサードパーティの依存関係を特定すべきです。
WooCommerceについては、WordPressのホスティング、プラグインスタック、アップグレードプロセスを個別に評価してください。これはShopify実装と交換可能なものではありません。ストア機能については ShopifyとWooCommerceの開発 を、ビジネスシステムの接続については API統合サービス をご覧ください。
