モバイルアプリ・WEBビュー計測時の注意点

アパレルECでモバイルアプリを導入しているブランドが相当数増えてきているように感じる昨今、理由としてはサービスの利用料が下がり、同時に導入のハードルが下がっていることに起因するでしょうか。アパレルで店舗を出店しているならば、会員登録を物理カードで管理しているケースはほぼ見かけなくなっていますし、店頭でアプリインストールから会員証＋ECでのお買い物に繋げられるモバイルアプリはとても便利です。ポイントもそちらで管理し、店頭とECのポイントを連携。プッシュ通知からECへの送客までやれる、とここまで聞くと良いことしかないですね。

しかし、我々のようなWEB解析を生業とする者からすると計測は悩みの種だったりします。アパレルECでモバイルアプリを導入している事例で多いのは、

【GA4】アプリとECサイト、クロスチャネルで購買分析をどうするか

上記記事にあるようなWEBビューでの表示方法。つまり、アプリはインストールするものの、アプリ内ブラウザでECを表示させる方法ですね。サービス名でよく見かけるのはヤプリさんや上記記事で執筆されているメグリさんでしょうか。（それに対してOSごとに開発する「ネイティブ」はWEBより優れたUI・オフラインでも動作可能、などの利点があります。「ネイティブ WEBビュー 違い」で検索すると記事は山ほど出てくるので気になる方はググってみてください。）

文中にも記載があるように、大概はutmパラメータでアプリ経由のセッションを計測しています。要は、WEBではご法度とされている「内部リンクにutmパラメータを貼り付けている」状態ですね。アプリなら簡易に計測する場合、致し方ない面もあるのですがこれで不明瞭になっている箇所が多く、またヒューマンエラーも起きやすくなっています。

そこで今回は、筆者が現場で感じるWEBビューでの計測による問題点をいくつか書いておきたいと思います。

※筆者はモバイルアプリ計測の専門家ではありませんので、あくまで現場で実験した結果になります。気になった方は専門家へ問い合わせてください。（この人とか。）

■プッシュ通知は厳密にはプッシュ通知のタップではない

まずはプッシュ通知について。WEBビューの計測で、GA4のデータを見ておりますと「app / push」のような参照元メディアをよく見かけます。これは上記記事でも触れられていますように、アプリのプッシュ通知を計測しているデータなのですが方法としては、

プッシュ通知が来る

↓

お知らせのページが開かれる

↓

utmパラメータが設定されているボタンをタップ

という流れかと。以前、現場でもヒアリングした際にこのような回答がありましたので、恐らく間違っていないかと思います。なので、厳密にはプッシュ通知のタップではありませんし、お知らせの一覧ページを開いた際にそちらも同じパラメータを付与している場合は、そこをタップしても同様にプッシュ通知経由としてカウントされます。

■アプリストリームが設定されていない

GA4の管理画面にて「データストリーム」という箇所がありますが、そこを見ると「WEB」と「iOS」「Android」でストリームが分けられています。ここがWEBとアプリのデータを取り込む箇所なのですが、モバイルアプリを導入しているのにアプリのストリームが空のケースが非常に多いです。

WEBビュー計測とは言え、モバイルアプリで表示されているページの中にはネイティブでの表示が複数存在しているケースがほとんどです。（下手したらそっちの表示回数の方が多い事もあります。）これはWEBビューをメインに使っている事業者で、アプリストリームも設定してみるとすぐわかるかと。この場合、カート回りのページは大概がWEBビューなので購買データは取れているのですが、セッションに大幅な乖離があります。また、ページ遷移の際にWEB→ネイティブ→WEB、みたいなケースはネイティブがデータ上入っていません。

また、担当者が「どこからどこまでがWEBビューなのか？」を認識していないことが多く、「急にdirectのセッションが増えた」と言われることもしばしばあります。しかも、更新の際によく変わるので昨対で比較した時にWEBだとセッションがガクッと減る、みたいなこともあるのです。（プラットフォーム別でみたらiOSやAndroidだった、みたいなケースはあるあるです。）

アプリの開発・計測を専門にしている企業の記事を読んでみますと、WEBビューとは言えGA4で計測する際はWEBでの計測をストップして、全てアプリストリームで管理するというのがセオリーのようですが、そのように対応しているケースは過去見たことはありませんね…。

■アプリ・WEB共にuser_idが取得されているかどうか

WEBビュー計測、且つアプリストリームを設定している事業者のケースも経験はありますが、この場合WEB・アプリ双方でuser_idを取得しているか？が問題になります。アプリはログインが前提なので、user_idさえ取得できていればWEBとアプリのセッションをつなげることが可能になり、結構な問題が解決します。

ですが、双方でuser_idが取得されていないケースがあります。どちらも取得していない・どちらか一方だけが取得されている、みたいな感じですね。この場合、WEBビューとネイティブを行き来すると別ユーザーとしてカウントされ、セッションがやや水増しされるかと。

実際にBigQueryで双方のuser_idを確認してみますとすぐ判明しますが、筆者は双方共に取得できているケースを見たことがありません…。（リクエストはしますが対応してもらえないことばかり。）

■セッションが切れた後の計測について

モバイルアプリをよく使う方ならおわかりかと思いますが、ユーザーの購買行動はアプリを起動してそのまま一直線で購入、なんてケースばかりではありません。もちろん、起動させてから非アクティブにすることもよくあるでしょうし、その度にセッションは切れます。これが要因で何が発生するか？ですが、utmで計測していた参照元がDirectに切り替わるという点ですね。

GA4ではセッションが切れても、Directで購入が発生した場合はその一つ前のチャネルを引き継ぐという仕様ですが、2回非アクティブでセッションが切れるとDirect経由での購入が増えます。アプリストリームで購入が計測されているなら「プラットフォーム」というディメンションからアプリ経由のセッション・購入は絞り込めますが、カート回りはWEBビューでの計測なのでWEB且つDirectでの購入になっているケースが出てきます。これ、結構なブラックボックス化ですしutm経由だとアプリ経由売上は正しく計測できていないでしょう。

現場からも「WEBのdirect経由の購入が急に増えた」と言われることもありますが、同時にアプリ（utm）経由の売上が下がっていることがしばあります。user_idが取得されている場合、BigQueryでアプリのutm経由で購入が発生しているuser_idを絞り込み（普段、アプリで購入されるユーザーとしてカウント）、WEB且つDirectで購入しているuser_idと突合させたところ、結構な重複が確認できました。なので、普段からDirectに分散しているケースは多いと考えています。

■utmパラメータが設定されていない箇所がある場合

最後はこちら。アプリでユーザーが最初にタップされるであろう箇所には全てutmパラメータが設置されている…、はずなのですが、そうでもないケースがあります。

これは事業者側と、GA4の「セッションの参照元/メディア」の文字列がどこに該当しているかを確認している際に発覚することが多いです。ここのタップはどれに該当しますか？という話の中で、「そこにはutmが設定されていません」みたいな回答があった際、場が凍りつきます…。要はこちらもDirect経由のセッションになるので、分散がより多くなってしまうのです。

■上振れしていることはほぼ無い？

これらが現場でよく発生している事でしょうか。主にWEBのDirect経由で計測されることが多いので、アプリ経由の売上が上振れして報告されるケースがあまり無いのが救いでしょうか。WEBビューはアプリ側の更新が楽ですし、悪い面ばかりではないのですが、これらを前提として分析しないと色々と間違った対策を実行してしまいます。

Shopifyをお使いなら、安価でモバイルアプリの導入が可能なAppifyを使っている事例がほとんどでしょうし、Appifyは基本的にはネイティブを推奨しているサービスなので、こちらで計測しているならまだ安心ではありますね。（ストア分析の「販売チャネル」でアプリ経由の売上は確認できますし。）

筆者もアプリの専門家に話を聞きながら、ここ数年でいくつか検証をしてみましたが、もしこの記事をご覧になられたアプリ計測の専門家がいらっしゃいましたら、ベストな対策をアンサーとしてご教示いただけますと幸いです。「WEBビューもアプリストリームで管理」が最適解かと思いつつ、サービス側が対応してくれない感じなのは如何ともし難いですが…。（専門家に確認しましたが、ベストではありつつもGA4でこれを実現できているケースは見た事がないそうです。運用面・技術面で断念するケースが多いとの事。）