翊珍香のECシステム事例｜画像効率、会員管理、プロモーション管理

問題の背景

伝統的な食品ブランドが求めるのは、単なるイメージページではなく、商品、会員、プロモーション、コンテンツの運用を統合した完全なECシステムです。課題は2点あります。1つ目は、大量の商品やイベントの画像です。画像パイプラインを事前に処理しないと、最大のコンテンツレンダリング（LCP）が元の大きな画像によって制限されます。2つ目は、複雑なプロモーションルールです。複数のイベントを同時に実施したり、会員による階層別の割引やクーポンを組み合わせたりする場合、これらのルールをプログラムに記述すると、新しいイベントがリリースされるたびにエンジニアが修正する必要があり、運用ペースが開発スケジュールに依存してしまいます。

実装方法

• —Next.js、GraphQL、PostgreSQL、Redis を使用してECコアを構築：フロントエンドは GraphQL を通じて商品、会員、プロモーションのデータを取得し、それぞれをモデリングします。Redis は、頻繁なクエリのキャッシュとして機能し、データベースの負荷を軽減します。
• —画像パイプラインの優先：アップロードされた元の画像は、出力時に現代の形式に変換され、バージョンごとに異なるサイズに切り抜かれます。フロントエンドは、デバイスに応じて対応するバージョンを読み込み、元の画像をブラウザに直接提供して拡大するのではなく、最適化されたバージョンを提供します。
• —LCP リソースの読み込み順序の確認：最初の画面のメイン画像の読み込み優先順位、プリロード、およびサイズ宣言を確認し、LCP を 2.5 秒以内に設定し、配信時に検証します。
• —プロモーションルールのバックエンド化：19 種類のプロモーションタイプ（一定金額以上、一定数量以上、プレゼント、期間限定割引など）と 5 の会員レベルを組み合わせた、組み合わせて設定できるルールモデルを構築します。運用担当者は、バックエンドで条件と期間を設定し、フロントエンドでのチェックアウト時に、バックエンドでルールに基づいて計算します。新しいプロモーションをプログラムを修正する必要はありません。

Falcon の実際の責任範囲

• ECフロントエンド、商品、コンテンツページ
• 会員、イベント、クーポン運用ルール
• GraphQL API、データベース、キャッシュの統合
• 画像出力と主要な読み込みパスの最適化

ショッピングと運用データの流れ

1. 01消費者は、商品またはイベントページからショッピングプロセスに入ります。ページ内の画像は、デバイスに応じて読み込まれる最適化されたサイズのバージョンです。
2. 02フロントエンドは、GraphQL を通じて商品、会員、プロモーションに必要なデータを取得し、Redis を使用して頻繁なクエリをキャッシュします。
3. 03チェックアウト時に、バックエンドは、会員レベル、進行中のプロモーション、およびクーポンルールに基づいて最終的な金額を計算します。複数のルールが同時に適用される場合は、明確な優先順位に基づいて処理され、フロントエンドで価格を計算しません。
4. 04運用担当者は、バックエンドで商品、コンテンツ、およびプロモーションの期間を設定し、ルールを有効にするためにプログラムを修正したり、再デプロイしたりする必要はありません。

制限、失敗、および代替手段

• —画像最適化の数値は、技術的な資産の違いを記述するものであり、売上増加を導き出すものではありません。
• —ページの表示速度、画像、デバイス、ネットワーク、およびサードパーティサービスによって変動するため、これは固定値として捉えることはできません。
• —会員と活動機能の数は、システムの範囲を表しますが、実際の利用率や販売実績とは異なります。
• —割引額は、バックエンドで計算され、フロントエンドには参考として表示されます。これにより、ルール変更期間中に価格が一致しないことを防ぎます。

証拠の検証方法

• ✓ブランド、商品、および主要なショッピングインターフェースは、公開されているウェブサイトで確認できます。
• ✓88.8% は、同一の商品画像の最適化前後のファイルサイズを比較したものであり、これは一時的な技術測定です。測定対象は画像資産そのものであり、継続的な監視データではありません。
• ✓LCP（Largest Contentful Paint）の目標と機能規模は、既存の公開されたドキュメントに基づいています。
• ✓GA4、GSC（Google Search Console）、コンバージョン率、注文数、または収益に関する公開可能なデータは取得されていません。

公開可能な測定値と能力