user_engagementが謎すぎるというメモ
22/09/12 更新
この記事のアクセス数がそこそこ多いので最近の情報を含めて記事を更新します。
user_engagement とは
以下の条件を満たすと自動的に送信されるイベントです
ユーザーがページから移動したとき(ユーザーがタブやウィンドウを閉じたとき、または別のページや画面に移動したとき)です
[GA4] ユーザー エンゲージメント - アナリティクス ヘルプ
このイベントの目的は「そのページの滞在時間(=エンゲージメント時間)を計測」する事であり
ユーザーがページを閲覧したというエンゲージメントに対してその時間を図るために存在しているようです。
エンゲージメントって?
Googleでは以下の定義を行なっていますがここでは 私の解釈で 書きます(参考程度に)
エンゲージメントは以下の2つをGoogleは定義していますが
このエンゲージメントは単純にGoogleが独自解釈して用意しているエンゲージメントなので
自分が運用しているサイトで独自にエンゲージメントを定義することも出来ます(後述)
- ユーザーエンゲージメント
- エンゲージメントしたセッション
ユーザーエンゲージメント
本質的には滞在時間を計測(=エンゲージメント時間)するために動くイベントなので
私はユーザーエンゲージメントを「ページ滞在時間」と読み替えています。
ようはページの滞在時間というエンゲージメントに対してユーザーエンゲージメントと呼んでいるだけかなと思ってます。
エンゲージメントしたセッション
以下の条件を満たした時にGA4では「エンゲージメントした」という判断になります。
10 秒を超えて継続したセッション、コンバージョン イベントが発生したセッション、または 2 回以上のページビューもしくはスクリーン ビューが発生したセッションです。
ここを見てわかることは user_engagement
はエンゲージメントしたセッションの条件には関係が無いということです
なのでユーザーエンゲージメントとは名ばかりで実際にはエンゲージメントとして判断されていないということになります。
※ 1ページ目の滞在時間が10秒を超えた場合は関係があります。ユーザーエンゲージメントという名前からこのイベントの動作=エンゲージメント発生では必ずしもないという意味
例えば初回アクセスのユーザーが1ページ目を5秒で閉じた時は…
- ユーザーエンゲージメント→5秒
- エンゲージメントしたセッションと判定する?→判定しない
といった感じになり、ユーザーエンゲージメントはあったがエンゲージメントしたセッションではなかったという事が発生します。
コンバージョンイベントイベントが発生した時にエンゲージメントとなるということは
自分たちで独自に定義したエンゲージメントをコンバージョンイベントにすればエンゲージメントしたセッションにできるということです。
なのでページを見たことがもはやエンゲージメントであれば、できるか不明ですがpage_viewをコンバージョンイベントにするとか
ページを開いたら自動的に動くコンバージョンイベントを定義してあげればほぼ全てのセッションをエンゲージメントしたセッションにすることができると思います
この記事を書いた時に勘違いをしていたところ
この記事を更新する前はエンゲージメントセッションの条件を満たす = user_engagement
が動くと思っていた。
しかし、エンゲージメントセッションと user_engagement
は関係なく以下の条件を満たしたセッションをエンゲージメントセッションとしているだけでuser_engagement
の動作は関係がありませんでした。
10 秒を超えて継続したセッション、コンバージョン イベントが発生したセッション、または 2 回以上のページビューもしくはスクリーン ビューが発生したセッションです。
[GA4] エンゲージメント率と直帰率 - アナリティクス ヘルプ
参考
- Dimensions and metrics - アナリティクス ヘルプ
- GA4の「エンゲージメント」の意味と関連指標を徹底解説! - ヨロコビーム
- GA4のユーザー定義いろいろ | アジアスターズ 株式会社
- BigQueryでGA4イベントデータをクエリして計算する方法
- Technical overview of new APP+WEB Properties - David Vallejo
- Implementation Guide For Events In Google Analytics 4 | Simo Ahava's blog
- Universal Analytics vs. Google Analytics 4: Alle Unterschiede im Vergleich
- 121WATT | GA4 - Das sind die neuen Metriken in Google Analytics 4
- GA4で直帰率が計測できなくなった!?「エンゲージメント」関連指標と直帰率の関係は? | marketing X by goo
- 【2022年版】Googleアナリティクス(最新GA4)の使い方を徹底解説|ワプ活
- 【Googleアナリティクス 4】「エンゲージメント」とはどんな指標?簡単解説!|Ungifted
GA4のpage_viewイベントはスクリプト読み込み後5秒後に動く?
概要
検証は10~30分ぐらいしかしてないので予想です。
タイトル通りですが、GA4における page_view
イベントは
GAのスクリプト読み込みが終わった5秒後に発火するようです。
その他のイベント( view_item
など)はGAのスクリプト読み込み後即発火されましたが
page_view
だけは5秒後に発火されたので意図した動作でありそうです。
なぜか?
1~2秒で閉じたりF5連打による変な数値は意味のない数値であることがUAでも問題としてあったようです
滞在時間などでディメンションを整えたり、n秒後をビュー数とカウントするなど回避策もいろいろあった。
GA4からは5秒経ったらビュー数とカウントするに統一された?
謎は深まりますが、メモとして残します。
Unitoのメモ
概要
例えばTrelloとJira、JiraとGithub間で
課題の同期をする中間サービスであるUnitoのActiveUserのメモを残します。
ここの情報は2021年5月27日時点のものです
Unitoはアップデートが結構されるのでここの情報が古くなっている可能性があることをご留意ください。
また、ここの情報は経験のメモであるので公式の情報ではありません。
Unitoの詳細は公式HPをご確認ください。
過去の記事でも紹介記事があります。
ActiveUserについて
ActiveUserは例えばTrelloとJiraでAさんが登録していて
このAさんの課題をこの2つのサービスで同期させたいという場合にAさんをUnito側で同期させるユーザーとして登録します。
この登録したユーザーをActiveUserと呼称するようです。
ActiveUserはUnito管理者が設定することができて
特定のサービス(TrelloとかJiraとか)の初回同期時にUnitoがユーザー情報を特定のサービスから取得するみたいです。
なので一度同期していないとActiveUserに設定できないというところは注意です。
(ここ詳しくは未確認です、いつも同期して数時間~1日経つとActiveUser設定画面に出てくる)
サービスの紐付けについて
例えばTrelloとJiraでAさんが登録していて
どちらも同じメールアドレスを利用している場合Unitoがユーザー情報を特定のサービスから取得した時に紐付けされるようです。
もし別々のメールアドレスを登録している場合
Unito側ではAさんは2人いてTrelloとJiraで分かれています、分かれてしまったユーザー情報はUnitoのActiveUser設定画面においてマージする事ができ
マージすることでユーザーがサービスで紐付かれ正しく同期する事ができるようになります。
以下のようにUnitoは判断してしまっている。
- Aさん(Trello)
- Aさん(Jira)
もしAさんが2人いる状態でTrelloとJiraのAさんの課題を同期しようとしても
Unito側ではAさんが2人いてどのサービスと紐付いているか判断できないため同期はできないみたいです。
なので正しい状態というのはUnito側にAさんが1人いてTrelloとJiraで紐付いている状態です。
- Aさん(Trello、Jira)
結論
- Unitoではユーザー1人1人にサービスの紐付けが必要
- 紐付けが完了しているかつそのユーザーの同期が有効な状態がActiveUser
git-filter-repoを利用してGitからファイルを履歴も合わせて削除する
概要
Gitに既にコミットしてプッシュしたデータの中に機密性が高いデータが存在したときに
そのデータの削除コミットをプッシュしただけでは削除されたことにならない。
ここでは git-filter-repo
を利用したデータの削除について解説します。
削除された事にならない理由
Gitは変更履歴を管理するツールなので、削除しても『機密性が高いデータをこの時点で消したよ』という履歴が残るだけでデータ自体は見れなくなるが過去の履歴に『機密性が高いデータが追加されたよ』が残っている限りこの機密性が高いデータは変更履歴を追うことで中身をすべて確認する事ができる。
要は履歴の積み重ねがGitの本質の為、過去に戻って確認できる限りデータは存在する。
ではどうするのか?
git-filter-repo
を利用して機密性の高いデータを全ての履歴から削除する。
履歴から対象データを削除する事で過去に戻っても対象データが存在しないので
結果的にGit管理上から完全削除される。
以前の履歴の消し方
以前は git-filter-branch
を利用していたがこちらは非推奨。
動作速度も git-filter-repo
の方が圧倒的に早いので使う理由は特にないです。
WARNING: git-filter-branch has a glut of gotchas generating mangled history rewrites. Hit Ctrl-C before proceeding to abort, then use an alternative filtering tool such as 'git filter-repo' (https://github.com/newren/git-filter-repo/) instead. See the filter-branch manual page for more details; to squelch this warning, set FILTER_BRANCH_SQUELCH_WARNING=1.
git-filter-repoのインストール
インストール方法は以下、ここではWindowsでのインストールしか確認していないのでWindowsでのインストール方法を記載します。
1. 注意点
WindowsはPythonのPathが正しく通らないとかで git-filter-repo
をインストールした後に書き換えが必要になるため、面倒くさいです。
ただ、これは各人の環境にもよると思うので必ずやるとは限らないかなと思います。
またGit(2.24.0以上)は既にインストールされているものとします。
2. Pythonのインストール
以下のURLからPythonをインストール。理由が無ければ最新版で良いと思います
注意点としてインストールするとき Add Python 3.x to PATH にチェックしてインストールしてください。
もちろんインストーラーを用いず scoop などでインストールするのでもOKです。
Python Releases for Windows | Python.org
3. git-filter-repoのインストール
scoop install git-filter-repo
これだけ。
4. git-filter-repoを動かす
git filter-repo -h
を 動かすとおそらくエラーが出てくると思います。エラーがでなければ次へ進んでください。
エラーが出た場合は原因として以下があげられます
python3 の Pathが通っていない(Windowsだとだいたいがこれ)
どうやらWindowsだと python3
とコマンドラインに打ってもPathが通っていないようです
pyhton
または py
を試してどちらならばPathが通っているか確認してください。
どちらも動かない場合はPythonインストール時に Add Python 3.x to PATH にチェックしてインストールしていない可能性があります。
または再起動してから試してください。
動いた場合は以下のファイルの1行目を python
に書き換える
Windowsでのインストール先はおそらくエラーが出たときにPathが表示されるはずなのでそちらを確認してエクスプローラーで開いて編集してください。
git-filter-repo/git-filter-repo at main · newren/git-filter-repo · GitHub
↑をしてもエラーになる場合
git-filter-repo.ps1
の python
を書き換える。
おそらく py
に書き換えれば大丈夫です。
5. git-filter-repoを利用する
【重要】以下の作業から不可逆です一度行うと取り消せません
利用する前に新しくリポジトリをCloneしましょう
履歴の改変をする時は新しくCloneした物を利用して行うべきです。
その後、masterから適当なブランチを作成してそのブランチで事前作業をして動作を確認できた後に本番を行いましょう。
git-filter-repo
のマニュアルはこちら
GitHub & BitBucket HTML Preview
多分これだけ覚えておけばOK
# 特定のファイルを全ての履歴から削除する git filter-repo --path xxx --invert-paths # 例)dir以下を全て削除する git filter-repo --path dir/ --invert-paths # 例)readme.mdを削除する git filter-repo --path readme.md --invert-paths # ちなみに --invert-paths を書かないと『そのファイルだけ残して後は全て消す』になります
6. プッシュする
履歴の改変をしたブランチはリモートリポジトリにあるブランチと確実に違うので強制プッシュ(force push)する必要があります。
git push --force-with-lease ...
※ --force-with-lease
はプッシュする時にリモートに新しいコミットがあったときに強制プッシュを止める事ができる。ただ履歴の改変をした場合はしっかり動くか不明なのでそもそも誰も操作しないブランチで作業を行うべきです。
GA4で最低限のeコマース設定をする
GA4とは
Google Analyticsの新しいバージョンです。
古いバージョンは俗にユニバーサルアナリティクスと呼ばれています。
Google AnalyticsがGA4になってeコマースの仕様も変わりました
以前のユニバーサルアナリティクスに使い慣れているとGA4の仕様は戸惑うのですが使い慣れるとGA4の方が使いやすそうな印象でした。
自由にできることが増えましたがその代わりに分析する際は自分で分析条件を設定しなければならない事が多くなりました
ただしeコマースや一部の分析はGA4で「このイベントを使って計測すれば自動分析するよ」という仕様のようですので正しくイベントを設定して有効活用しましょう。
今回はeコマースについて最低限必要であろうイベントを取りまとめます
他にもイベントはあるので詳しくはリンク先をご確認ください。
【重要】eコマースを正しく分析するために
一部の分析は自動分析されるとは書きましたが、GA4が推奨しているイベントを送り
なおかつ正しくパラメーターを送信できているときに限るのでご注意ください。
例を上げると xxx_id
と xxx_name
(例えば item_list_id
、item_list_name
)は
基本的にどちらか必須という事になっているのですが2つとも設定することをオススメします。
後、itemsパラメーター内の item_list_id
と item_list_name
は必須では無いのですが出来る限り設定することをおすすめします
例えばどのリストからカートに追加されたのかとか分析できるようになります。
eコマースの分析ページを見るとid毎、name毎に分かれるリストがところどころに出てきて
片方だけしか設定していないと片方のリストだけしか表示されなかったりします。
片方だけでも分析は正しくされるのですが、見にくかったり
分析する物によってはnameのリストからの分析になって、idだけ設定してると意味のない分析結果になります
よって出来る限り2つ設定して両方のリストを見られるようにするのがベストでしょう。
基本的には xxx_id
側は変動しない値を入れるべきです、xxx_name
は変わる可能性があるのでユニークになりません
後々idで分析を見るとnameが変わっていても統計が取れるので非常に重要です。
他、イベントのパラメーター上では必須では無いのに上記のように実質必須な物があるかもしれません
すべて設定できるようであれば設定するのがベストなんでしょうが、システム仕様的に難しいこともあると思うので妥協する部分は必要かなと思います。
商品の表示イベント
商品表示イベントは3つあります。
view_item_list
商品リストが表示された時のイベント。
例えば商品を検索して出てくるリストの場合は「商品検索結果」みたいな名前のリストになり
商品詳細ページにあるリコメンドの商品リストは「類似の商品」みたいな名前のリストになります。
https://developers.google.com/analytics/devguides/collection/ga4/ecommerce?hl=ja#view_item_list
view_item
商品閲覧時のイベント。
基本的には商品詳細ページに設定するイベントかと思います。
https://developers.google.com/analytics/devguides/collection/ga4/ecommerce?hl=ja#view_item
select_item
例えば商品リストから商品詳細ページを開いた時のイベント。
商品検索結果のリストからとある商品を選んだ時に動かすとか
「選択した」の定義に当てはまるのであればわりと自由に設定できるイベントかなと思います。
https://developers.google.com/analytics/devguides/collection/ga4/ecommerce?hl=ja#select_item
商品を購入する前の操作イベント
ほとんどのECサイトではカートに追加して購入するフローになると思いますが
カートを操作した時のイベントとして追加と削除の2つがあります。
add_to_cart
カート追加時のイベント。
https://developers.google.com/analytics/devguides/collection/ga4/ecommerce?hl=ja#add_to_cart
remove_from_cart
カート削除時のイベント。
https://developers.google.com/analytics/devguides/collection/ga4/ecommerce?hl=ja#remove_from_cart
商品購入周りのイベント
商品購入周りのイベントは
決済開始、決済時支払情報追加、決済時配送先情報追加、決済完了、払い戻しの5つあります。
基本的には決済開始と決済完了を使うことになると思うのでこの2つだけ書き出します。
begin_checkout
決済が開始した時のイベント。
決済開始ページを開いた時に動かすもので、決済完了と同じタイミングでは動かないです
要は決済開始ページを開いたけど決済しなかった割合、みたいな分析をするときの母数に使える様にします。
https://developers.google.com/analytics/devguides/collection/ga4/ecommerce?hl=ja#begin_checkout
purchase
決済完了時のイベント。
このイベントはデフォルトでコンバージョンイベントとして計測/設定されます。
https://developers.google.com/analytics/devguides/collection/ga4/ecommerce?hl=ja#purchase