EC-CUBEでQRコード起点のトラッキング機能を追加した話
目次
はじめに
デジタルエンジニアリング部 Eビジネスエンジニアリング課のN.S.です。
これまでECサイトの構築や運用支援に携わってきた中で、「なかなか売上が伸びない..」「広告費をかけても集客に繋がっている実感がない..」といった切実な声を多く聞いてきました。昨今ではSNSなど販売チャネルは多様化し、その販売戦略も複雑化しているように感じます。
このような中、いかに「データ」を可視化し、施策に活かせる基盤を作るかは、ECサイトの命運を分ける鍵だと考えています。
そこで本記事では、このような分析基盤を作る一助となればと思い、「QRコード起点のトラッキング機能」をEC-CUBE上に構築した事例をご紹介します。
代理店の販売実績評価の課題
今回の事例の課題は、「オフラインの営業活動」と「オンラインの購買データ」の分断でした。 このビジネスモデルでは、複数の販売代理店が対面接客や営業活動を通じて、顧客へ商品を直接案内していました。このような、オフラインでの接客は「誰が、いつ、誰に案内したか」というログがデジタル上に残りません。ECサイト構築にあたり、このアナログな接客ログをいかにデジタルの会員データや購買データと統合するかが、戦略上の大きな焦点となりました。
GA4によるトラッキングの検討と限界
GA4の計測用パラメータを付与したURLをQRコード化して配布すれば、この分断は解消できると考えていました。GA4を使えば、「どの代理店のQRコードから、何回アクセスがあったか」という流入元の特定が可能です。
しかし、計測には以下の限界があります。
-
「会員属性」の活用限界: GA4はあくまで行動分析ツールであり、個人情報保護の観点から、氏名、詳細な居住地、電話番号などの個人特定情報をGA4側に保持することは禁止されています。[1] 「会員データや購買データとの統合」を行うには、情報の多くを自社DB内に持つ必要がありました。
-
データの永続性:パラメータによる紐付けは、ブラウザのCookieに依存するため、時間が経ったりデバイスが変わったりすると途切れてしまいます。長期的なLTV分析(累計購入額の算出など)に利用するデータとしては、正確性と永続性に欠けるという懸念がありました。
技術要件と解決策
そこで、EC-CUBEのデータベース側で 「会員の属性情報として代理店IDを永続化する」 というアプローチを採用しました。今回の事例では、以下の技術要件を満たす必要がありました。
- 代理店ごとに固有の識別子を持たせること
- 顧客が入力の手間なく、自社DBの会員属性と代理店情報を確実に紐付けられること
- 会員属性や受注情報と連動した、カスタマイズ可能な分析・集計ロジックを構築すること
これらの解決策として、会員登録時にクーポンを付与するインセンティブ設計と、 QRコードを起点としたトラッキング・集計機能をEC-CUBEに組み込みました。
代理店用のQRコードを取り入れたECでの商品購入フローです。 
DB構成
まずは、DBの構成です。EC-CUBEのデフォルトではクーポン管理や代理店管理といった機能がないため、カスタマイズが必要になります。[2]
テーブル設計
※視認性確保のため、一部カラムを省略しています。
-
dtb_agency(新規)代理店マスタ: 代理店の名称や独自の代理店コードを管理します。
-
dtb_agency_margin(新規)代理店手数料率テーブル: 「商品単位」「カテゴリ単位」での柔軟な手数料設定を可能にします。
-
dtb_coupon(新規)クーポンテーブル: クーポンの名称や値引き額を管理します。特定の代理店に紐付くagency_idを持ちますが、共通クーポンも扱えるようNullableに設定。
-
dtb_customer(既存拡張): 会員が「どの代理店から流入したか」という初期属性を保持します。一度紐付いた顧客を永続的に追跡するための基点となります。
-
dtb_order/dtb_order_item(既存拡張): 受注時点の「代理店」および「適用手数料率」をスナップショットとして保存します。
QRコード発行の実装
トラッキングの起点となる「代理店コード」を保持したQRコードの生成には、PHPライブラリのendroid/qr-codeを採用しました。 本ライブラリはSymfonyコンポーネントとの親和性が高く、EC-CUBEで安定した動作と柔軟な出力制御が可能です。
動作環境
紹介する実装コードは、対象のプロジェクトを実装した以下の環境を前提としたサンプルになります。
- EC-CUBE 4.2.3
- PHP 8.1
- Symfony 5.4
- endroid/qr-code v4.8
また、endroid/qr-codeは事前にライブラリを追加する必要があります。 ターミナルで以下のコマンドを実行し、プロジェクトにライブラリを追加します。
composer require endroid/qr-code
QRコード生成ロジック
代理店登録時に、固有の代理店コード(agency_code)をパラメータに含むURLを動的にQRコード化します。 実運用では、DBの肥大化やパフォーマンス低下を防ぐため、表示のたびに動的に生成するか、生成したファイルをS3等のオブジェクトストレージへ保存する構成を推奨します。
以下は、Controller内で動的にQRコードを生成し、Data URIとして返却する実装サンプルです。
use Endroid\QrCode\Builder\Builder;
use Endroid\QrCode\Encoding\Encoding;
use Endroid\QrCode\ErrorCorrectionLevel\ErrorCorrectionLevelHigh;
use Endroid\QrCode\Writer\PngWriter;
use Symfony\Component\Routing\Generator\UrlGeneratorInterface;
/**
* 代理店専用URLのQRコードを生成する
*/
public function generateAgencyQrCode(Agency $Agency)
{
// 1. 代理店識別子を含んだトラッキングURLの生成
// UrlGeneratorInterface::ABSOLUTE_URL により、env等で設定されたドメインを含むフルURLが生成されます
$url = $this->generateUrl('entry', [
'agency_code' => $Agency->getAgencyCode()
], UrlGeneratorInterface::ABSOLUTE_URL);
// 2. Builderを使用してQRコードを構成・生成
$result = Builder::create()
->writer(new PngWriter())
->data($url)
->encoding(new Encoding('UTF-8'))
->errorCorrectionLevel(new ErrorCorrectionLevelHigh())
->size(300)
->margin(10)
->build();
// 3. フロントエンドでの表示用にData URIを取得
return $result->getDataUri();
}
フロントエンド連携
ユーザーが代理店のQRコードを読み取ると、URLパラメータに含まれる代理店コードを検知し、サーバーサイドでセッションに保持する仕組みを構築しました。 フロントエンド側では、このコードが会員登録画面の「特典コード」として自動入力されるようにしています。ユーザーは特典として認識しつつ、システム側では代理店と紐付く設計となっています。
- 自動入力: 会員登録画面(EntryType)のビルド時にセッションから値を自動取得し、初期値としてセットします。
- セッション保存: ユーザーが入力中に一度ブラウザバックして戻ってきた場合、URLパラメータが消失し、トラッキングが途切れてしまうリスクを回避しています。

集計処理の実装
集計処理として、代理店の手数料計算は受注時に完了させてDBへ保存し、データ整合性を維持できる設計にする必要があります。
以下は、対象期間における代理店別の実績レポートを出力する際の処理フローの例です。受注データ(dtb_order)のステータス遷移をトリガーとし、「発送済み」となった確定注文のみを実績として抽出・合算します。[3]
集計処理の全体フロー

分析ダッシュボードの構築
集計結果は、管理画面から、視覚的に確認できるようにします。 EC-CUBEのデフォルトでは、会員情報として性別や生年月日などがありますので、その会員特性をもとに分析ができます。 販売する商品によって重要となるデータは異なると思いますので、EC構築前に必要なデータ項目を整理しておくことが大切です。
集計例)
| 表示項目 | 期待される効果 |
|---|---|
| ユーザー属性分析 | 代理店別にユーザーの性別や年齢、居住地などを把握 |
| 商品別実績分析 | どの代理店がどの商品カテゴリを得意としているかを把握 |
| 期間別実績分析 | 代理店ごとの期間別で売れる商品の波を把握 |
まとめ
私は、ECサイトはカッコよく作るのではなく、どのように売れる設計を構築するか、戦略のための分析基盤をどうやって構築するかを事前に想定することが、将来的な売上にとって重要だと考えています。 データに基づいたPDCAサイクルを回せる基盤があるからこそ、サイトは持続的に成長できます。
本事例が、戦略的なECサイト構築を目指すエンジニアやディレクターの皆様の参考になれば幸いです。
参考・引用元
1 Google アナリティクス利用規約7. プライバシーを参照してください。 ↩
2 独自のDB拡張などを行う際は、将来的なバージョン更新や導入済みのプラグインとの競合などを考慮して行ってください。 ↩
3 事例のプロジェクトでは、決済プラグインを導入していたため「入金済みかつ発送済み」の受注を抽出していました。 ↩
アジアクエスト株式会社では一緒に働いていただける方を募集しています。
興味のある方は以下のURLを御覧ください。