GA4でアプリ内ブラウザの行動データ(PV)も統合して計測する
メグリでプランニングを担当している篠キチです。
GA4の記事を連続でnoteに投稿してましたが、前々回に続いて前回のこの記事もなかなか好評でした。
その中で、GA4は
どの顧客接点であっても統一された顧客認識ができるID(User-ID)を軸にし
オンライン・オフライン問わず様々なチャネルのデータをひとまとめにし
カスタマージャーニーの詳細な把握ができるような分析基盤となること
を指向していると書きました。これはこれで理想的な分析サービスだなと個人的には思います。
ただ、アプリとWebの統合分析という言葉に期待することとして、こういう様々なチャネルのデータをユーザー軸で統合するのとは違うイメージを持たれている場合があります。これが今回のお話のテーマです。
アプリ内の一連の行動データをひとつにまとめたい
「一連の行動データ」はアプリの機能が技術的にどんな方法で提供されているかに関わらず、アプリの使い始めから終了までを一貫した利用行動として捉え、データ化したものということです。
…よくわからないですよね
というより「そもそもの話、なんでひとつにまとまってないの？」と思う方もいると思います。
ただこれはアプリの計測ではあるあるな話で、アプリのネイティブ画面とアプリ内ブラウザでWebページを閲覧しているときの、行動データの計測方法が異なることが原因です。GA4を使っても普通に作るとこうなります。
下の図は行動データがアプリのデータストリームとウェブのデータストリームに分かれてしまう様子を表したものです
アプリ側がネイティブで用意している機能はWebViewの画面を開くところまで。アプリとしてはブラウザ機能を提供するだけで、そのブラウザ内でどのように遷移しているかは見ていません。
当然FirebaseのSDKも、Webview内の遷移を捕捉したりそのデータをアプリストリームに送ったりはしません。つまりアプリのデータストリーム上ではアプリ内ブラウザでどんなページを開いたか、ECでカートに入れたり実際に買ったりしたのか、といったウェブ側の行動を全く知ることができません。
また、アプリ内ブラウザはWebサイトから見たら数あるブラウザの一つにすぎません。そのためWeb側の計測タグはアプリからのアクセスかどうかは考慮することなく、単純にWebサイトへのアクセスとして計測し、ウェブのデータストリームに送信するだけです。
理屈ではそうなんですが、このデータの取り方はしっくりこないという方も多いと思います
内部的にアプリで提供している機能がネイティブだろうがアプリ内ブラウザを介したWebページで提供していようが、利用者はこのサービスを1つのアプリとして利用しているわけです。これはユーザー体験的にもそうですし、アプリ担当者の立場で考えてもそうです。どういう技術で提供されているかは関係ありません。
そのため、このアプリを利用したユーザーの行動は、その機能がネイティブだろうがWebだろうが一連のつながった行動データとして捕捉・分析したいというニーズがあるのも当然だろうと思います
技術的には可能
このニーズ、考え方としてはGAのユニバーサルアナリティクスを使った計測・分析に近いのかなと個人的には思います。
GA4の場合はユーザーベースで行動を捉える考え方なので、アプリとWebの計測データが分かれていても、最終的にユーザーIDベースで突合して見られればOKです。別々に計測したアプリとWebのデータストリームを簡単に一緒にできてしまうのも、そういった考え方が根底にあるからです。
(逆に共通のユーザーIDがないと単に見にくいだけになってしまうのは、GA4に関する1本目のnote記事に書いたとおりです)
しかし今回取り上げているような計測ニーズはアプリ利用時の一連の行動を一貫して捉えたい、これは1セッションの行動をすべてひとまとめにしたい、ネイティブかウェブかに関わらず一貫した行動データとして考えたいということで、セッション軸で行動を捉えていたユニバーサルアナリティクスっぽい感じがします。
実はFirebaseのドキュメントにSDK経由でWebView内の行動データを送信する方法が公開されています
ざっくり言うと、Webサイト側にアプリにデータを渡すためのjavascriptを埋め込むのと、そのデータをアプリのWebView側で拾ってFirebaseのSDKに渡す機能を作ることで実現するやり方です。
詳細はNRIネットコムの金井さんが書かれたこの記事が参考になると思います
メリット・デメリット
このGA4アプリストリームにWebviewの計測イベントも統合するやり方、最大のメリットはもちろんアプリかWebかに関わらずアプリ内の一連のユーザー行動をまとめられることにあります。
あともう1つは、アプリ・Webそれぞれのログイン状態が不明だったり、一致してなかったりしても、それによらず一連の行動として捉えられるという点が挙げられると思います。ユーザー単位ではなくセッション単位で追う考え方だから得られるメリットといえるでしょう。
デメリットの1つは実装がやや複雑な点。アプリ・Webともにこのための追加実装が必要になります。
もう1つのデメリットは、GA4でこれをやってしまうと前回のnoteで書いたようなUser-IDを利用した統合分析をやるのがかなり難しくなることかなと思います。
アプリのデータストリームはFirebaseの仕様上、いまのところ1アプリから1本しか出せないので、そこにWebviewの計測データを流し込んだ上で、さらにウェブのデータストリームも同じプロパティに入れてしまうと、アプリ内ブラウザからのWeb計測が2重に行われてしまいます。
これを避けるためにウェブのデータストリームからアプリ内ブラウザ経由のアクセスを抜く(計測しない) というやり方も考えられます。
ただ、そこまで複雑な計測仕様でGA4にデータを入れたとして、そのあとGA4やBigQueryを使ってどういう方針で分析を行っていくのか、まずそのあたりを慎重に考える必要があると個人的には思います。
計測は一度始めてしまうと、その設計を途中で変えるのはかなりリスクあります。変更によって過去のデータがまるごと失われる(使い物にならなくなる) 可能性が非常に高くなります。
前回のnoteに書いたGA4の仕様に沿った統合分析はユーザーベースの考え方、今回のWebviewイベントをアプリストリームに統合するのはセッションベースの考え方で、そもそも方針が全く異なります。
GA4でアプリの分析だけをやるなら今回のやり方は悪くないでしょう。ただ本来のGA4が目指すようなあらゆるチャネルのイベントを統合して分析していくことを最終的に目指すなら、やめたほうがいいかもしれません。
そういう点を考えても、まずは計測設計を慎重に行うことが大切ではないかなと思います。難しそうだなと思ったら、我々のようなアプリ側の実装面で相談できる会社や、前回のnoteで紹介したGA4のコンサルを行ってくれる会社を頼るほうが安心です。
アプリの行動分析にGA4を活用した事例
2022年10月にMGReを導入いただいているサンリオ様、プリズマティクス様との共催でウェビナーを開催しましたが、その中でSanrio+の顧客像・顧客行動について語られている箇所があります
サンリオ様はアプリの分析に関してGA4がまだGoogleアナリティクス for Firebase と呼ばれていた頃から活用されていらっしゃいます。(GA4以外のツール・サービスも併用されていらっしゃると思います)
上記のレポートでは割愛されていますが、GA4に関する話題もウェビナーでは出ていました。(下のウェビナー録画の26:21あたり)
さいごに
GA4のアプリ活用について3回にわけてnoteに書いてきましたが、いかがでしたでしょうか。
アプリプラットフォーム『MGRe』はGA4に標準対応しているだけでなく、今回紹介したWebviewイベントのアプリストリーム統合のようなカスタマイズ対応も可能になっています。
DX推進には欠かせない様々なシステムやサービス、Webサイトとの連携を実現できる、これからのアプリ開発に最適なプラットフォームとして、MGReは多くの企業にご導入いただいています。
新規のアプリ導入のご相談はもちろん、他社では断られてしまうようなSDKの導入や各社システム・サービスとの連携開発に対応できるとのことで、アプリリニューアルのご相談も多くいただいています。
アプリ開発に関するお悩み、ご相談がありましたどうぞお気軽にご連絡ください。お待ちしております。
