筆者が開発をお手伝いさせていただいているアプリは小売業向けが多く、それもあってアプリ内でECを利用可能なものが大半を占めています。
そういうアプリを作ればEC売上アップへの貢献が当然期待されるわけですが、実際にアプリの効果・貢献度を測るのは意外と骨が折れることです。
ECサイトとアプリをクロスチャネルで分析する手段として、主に以下の3通りの方法があります。
- GA4とECサイトを連携し、ECサイト側で分析
- GA4上でアプリとウェブを横断して分析
- アプリとECサイトを連携し、アプリ側のGA4で横断して分析
GA4を使いECサイト側で計測する
アプリ内のEC機能はアプリ内ブラウザ(Webview)を使ってECサイトをそのまま表示する、という手法で作られていることがほとんどです。
※これについては以前詳しく書かせていただいた記事がありますので、お時間あればご覧ください。
この場合の効果測定によく用いられるのは、EC側のGoogleアナリティクス上で「参照元/メディア」として分析できるよう、アプリ内ブラウザでECサイトを開くときにパラメータをつけておく方法です。
簡単に言うと、アプリをECサイトへの流入元の１つと捉えて計測するということです。
手法自体は広告計測などで用いられる一般的なやり方なので詳細は省きますが、アプリからECサイトを開くときに指定するURLに
?utm_source=app_name&utm_medium=app
のようなパラメータをつけておくだけです。こうしておけばGoogleアナリティクス上で参照元に「app_name」、メディアに「app」という情報が入るので
- アプリからECサイトへどのくらいの流入があったか
- アプリ経由でEC購入に至ったユーザー数や売上はどのくらいあったか
といったことが、Googleアナリティクスでわかるようになります。
さらにutm_campaignパラメータとしてアプリ内のどこから遷移したかわかる情報を追記しておけばより詳細に分析できるでしょう。
また、アプリ側の実装に少し手間がかかりますが、どのプッシュ通知でアプリを起動したかといった情報をutm_campaignに入れておけば、施策として有効なプッシュ通知がどれだったか調べることも可能になってきます。
ユニバーサルアナリティクスの頃はパラメータをつけてアクセスするとそのたびにセッションがリセットされてしまっていました。
そのためパラメータ付きのURLでアクセスさせると、アプリからECサイトへ遷移するたびにセッションが新規カウントされてしまい、ECサイトのGoogleアナリティクスのセッション数が高く出てしまう問題がありました。
また、上記のようにutm_campaignを使って流入元を細かく分析しようとしても、遷移するたびにパラメータがリセットされてしまうので、常に最後に遷移したときの情報になってしまう点も課題だったと思います（これが課題になるかどうかは計測の方針次第ですが）。
このあたりは現行のGA4では仕様が変わっています。アプリの作り方にもよりますが、基本的にセッションがタイムアウトしていない限りはアプリとECサイトで行き来が発生してもセッションは維持されます。そのためアプリ経由のアクセスでセッション数が異常に高くなったりすることもないですし、パラメータもセッション開始時に設定された内容が維持されるのです。
結論として、GA4を使ってECサイト側で計測するやり方なら比較的リーズナブルに、そこそこ精度も高く計測・分析ができると言えます。
GA4のアプリ・ウェブ統合分析
ただ、ここまで紹介したやり方ではアプリ内のユーザー利用状況・行動と、ECの成果を紐付けた分析といったことはできません。
アプリのアクセス状況も含めてもっと詳しく計測・分析しようと思った場合、真っ先に思いつくのはGA4を使ったアプリとウェブの統合分析ではないでしょうか。
GA4はもともとアプリの利用状況を計測するために作られた『Googleアナリティクス for Firebase』がベースになっていて、それがWeb計測にも対応する形でバージョンアップされたものです。
そういった経緯もあって、GA4はその特長として「アプリとWebの両方のデータを収集し、カスタマージャーニーをより詳細に把握できる」ことがGoogleアナリティクスのドキュメントにも書かれています。
※GA4によるアプリ分析の基礎については以前記事を書かせていただいています。
ただGA4を使った統合分析についてはかなりハードルが高く、社内に詳しい方がいらっしゃるか外部にコンサルティングを依頼できる状況でもない限り、あまりおすすめできないのが現状です。
まず、単にアプリとWebの両方の計測データを１つのGA4プロパティに流し込んでも、それらが１つのセッションとしてつながらないので、それだけではアプリ経由のEC成果を測ることがそもそもできません。
少なくとも統合分析するにはアプリとウェブで共通のユーザーIDをGoogleアナリティクスのプロパティに送信して、それぞれどのアクセスが同じユーザーなのかを判別（GA4のレポート用識別子）できるようにする必要があります。まずこの対応に手間がかかります。
また、仮にこの対応をしたとしてもGA4の探索レポート機能ではユーザーIDを使ったレポート作成がほとんどできません。そのため現状のGA4単体ではアプリとウェブのアクセスを統合的に分析するのはかなり難しいのでは？と考えています。当然アプリ経由のEC成果を測ることも困難になってきます。
このような統合分析を行う案件で筆者が関わったものでは、例外なくGA4のコンサルティングを行う業者が入って計測設計を緻密に行っていましたし、分析に関してもBigQueryなどを活用することが前提になっていました。このこともGA4単体で成果を測ることが難しいのではないかと考える理由になっています。
アプリ側でウェブの計測も行う方法
実はGA4を使ったアプリとウェブの統合分析にはもう１つ方法があり、このやり方であればアプリとウェブを行き来するようなアクセスを同一セッションで捉えることも可能になります。
そもそもアプリとウェブのアクセス計測がバラバラになってしまうのは、アプリの計測方法とウェブの計測方法が異なっていて、それぞれ個別に計測を行っていることが原因です。
この解決策として、アプリ内ブラウザで表示しているウェブページの計測をアプリ側でも行えるようにして、アプリのデータストリーム上にウェブの分析データを流し込むという方法があります。これはGoogleからも公式にアナウンスされている方法です。
ただこれは実装に若干手間がかかる難点があり、アプリだけでなくWeb側にも別途計測用のJavaScriptを組み込む必要があります。
成果を測るためにはECのコンバージョンイベントなども送らなくてはいけないですし、アプリとウェブの計測イベントが混在することを想定した設計も必要です。
このレベルになると、前項で書いた統合分析の場合と同様にコンサルティング会社に依頼して設計から担ってもらっていることが多く、筆者のもとに届くアプリへの実装指示書もコンサルティング会社から送られてくることがほとんどです。
また、このやり方はアプリだけに絞って成果を見ていくことになるので、ECサイト全体を見ている担当者との役割分担は事前によく話して決めておく必要があるでしょう。アプリ経由のECアクセスや成果の計測を既存のEC分析から外すと言うことであれば、それも考慮した実装が必要になってきます。
まとめ
- EC側で割り切った計測が無難だが、この方法ではアプリ内の行動との連動性はわからない
- GA4を使った統合分析は現状ではハードルがかなり高い
- 折衷案としてアプリ側の計測にまとめる方法もあるが、これも難易度がそこそこ高い
このようにアプリのEC貢献度を測るのがなかなか難しいなか、弊社で開発しているアプリプラットフォーム『MGRe』は独自にこれを計測可能にした「ECコンバージョン機能」を昨年リリースしました。
ECサイト側の対応は特に必要なく、MGReをご利用いただいていれば追加料金もなくご覧いただけます。ご興味あればぜひお問い合わせください。
▼「MGRe」についてのお問い合わせはこちら
https://mgre.jp/
合わせて読みたい
