コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

Google Analytics4における高基数ディメンションとは何かをざっくりまとめる

公式のヘルプはピンと来にくいので用語を順に整理する。なおGoogleAnalytics4のことをGA4と略してこの記事内では記述する。

出典元

[GA4] 基数 - アナリティクス ヘルプ

用語別整理

ディメンション

イベントに関するイベントパラメータをGA4で探索できるようにしたものがディメンション。ディメンションに関しては別記事でまとめたので下記参照。

Google Analytics4におけるディメンションのパターンをざっくり整理する - コード日進月歩

基数

ディメンションにおける基数とは、そのディメンションのパターンバリエーションの数ことを指す。たとえば「イベント発生させたユーザの性別」のバリエーションを "男性" "女性" ”その他" とするのであれば3つが基数となる。

高基数ディメンション

GA4では1日の中で記録する基数の数が500以上を超えるものを高基数ディメンションという。

たとえば「商品コード」などをディメンションとして設定したときに、品数が1000点など取り扱うECサイトの場合は高基数ディメンションとなってしまう。

高基数ディメンションは何が問題か

GA4側ではディメンション単位で集約して計算を行うので、多すぎる高基数ディメンションはGA4のUI上からは集計ができないケースが発生する。もし高基数ディメンションを使ってグルーピングなどしたい場合はBigQueryExportを活用する必要が出てくる。

例外的にユーザを一意に特定する識別子のディメンションとしてはUser-IDという概念を用意してくれており、こちらを使うと高基数にあたる500以上のパターンになっても対応してくれる。

参考リンク

Google Analytics4におけるディメンションのパターンをざっくり整理する

Google Analytics4(GA4)のディメンションに関するパターンが自分自身でわからなくなったので改めて整理する

出典

ディメンションとイベントパラメータ

GA4のイベントにはイベント単位でイベントパラメータ(event_params)がある。そのうち、集計などに使うためのキー値のことをディメンションと定義している。そのため、イベントパラメータのなかでも、GA4の探索などに利用できるものがディメンションと考えると良い。

ディメンションとはどのようなものがあるのか

ディメンションにはGA4側であらかじめ設定されているものと、独自に設定できるカスタムディメンションが存在する。

自動的に入るディメンション

GA4側で自動的に付与されるディメンション、イベントがおきたURLの情報である ページパスとスクリーン クラスページパス + クエリ文字列 、アクセスした地域情報である 地域 などの情報がある。

また、Googleの他のサービスを使ったり、GA4の設定次第で自動的に入るものもある。どのような設定で入るかは アナリティクスのディメンションと指標のヘルプページ にリストがあるので、そちらを参考のこと。

また、こちらの自動的に入るディメンションに関しては利用者側からの上書きに関しては言及がなく、やろうとしてもできないとされている。

カスタムディメンション

GA4のイベントを送信するときに「イベントパラメータ」として自由に、keyと値のセットを送信することができる。ただしこれらのパラメータは取得されるだけで、GA4上のUIには表示されない。そのためGA4上のUIで適切に使えるようにするためには「カスタムディメンション」として定義をしてあげる必要がある。

推奨イベントとディメンション

GA4側で一般的に利用するであるイベントに関しては、推奨イベントとして、イベント名とイベントパラメータの値のガイドを紹介している。

推奨イベント  |  Google Analytics  |  Google for Developers

このドキュメントに記載しているとおりにイベントパラメータをセットすると、GA4のUI上ではすでにディメンションとして定義されているので、別途カスタムディメンションと定義しなくてもGA4のUI上で確認できる。

たとえば「検索がされた」というアクションをGA4上で計測する場合はイベント名は search 、検索に利用したフレーズを search_term というキーでイベントパラメータとして設定すると、GA4上のUIでは「検索キーワード」というディメンションとして使える。

ディメンションの考え方

GA4のUI上の探索を行いたい場合はディメンションとしての定義が必要になるため、分析したいものをカスタムディメンションで定義する必要がある。

ただし、そのディメンションを取りたいイベントが推奨イベントにあるようなものであれば、推奨イベントとセットで定義されているイベントパラメータを使ったほうがGA4側で定義されているので楽になる。

関連リンク

プロセス管理の技術であるSupervisorについてざっくりまとめる

スーパバイザモードの話とよくわからなくなるので。

Supervisorとは

2004年頃からある、プロセスを常時起動するデーモン化のためのツール。python製。 Supervisor: A Process Control System — Supervisor 4.2.5 documentation

どういうときに使われるものなのか

デーモン化はsystemdのserviceを使う方法などがありますが、それよりも簡単に行えるのがsupervisorです。 とくにdockerの場合などは、systemdなどを使って複数プロセスを立ち上げることもできないわけではないのですが、supervisorでカバーできるケースがほとんどなので、よく使われる傾向にあります。

参考リンク

トークンバケットとはなにかをざっくりまとめる

言葉からは動きが想像できなかったのでざっくりまとめる。なおパケット(Packet)ではなくバケットBucket)。

トークバケット(Token Bucket)とは

帯域制御の方法のひとつ。トークン(送信権)を一定時間のペースで発行し貯蓄され、流れていくるトラフィックのパケットに関して、対応できる量のトークンがあれば処理を行う。対応する量がなければトークンがあてがわれなかったトラフィックは破棄される仕組み。トークンの貯蓄は無限に行うことではなく、一定量貯まるとそれ以上はたまらないため、波がある場合でもすべてのトラフィックが処理されるわけではない。

送信権であるトークンをためるバケツを用意し、そのバケツが一杯になったら新たなトークンの追加がされない考え方。

特徴

トークンの量が一定量確保されている状態であれば、流れてきた通りの処理ができる。そのため、いわゆるバーストのような一時的にトラフィック流量が跳ね上がる状態でも等しくカットされるわけではなく、トークンが貯まっていれば対応はできることになる。

参考リンク

通信経路におけるポリシング(Policing)とシェーピング(Shaping)についてざっくりまとめる

トークバケットを整理するときに、前提として気になった部分だったので切り出してまとめる。なおシェービング(shaving)ではない。

それぞれの言葉の意味

いずれも通信における帯域制御に使われることばで、帯域などを占有しないように制限値を設ける場合にその制限値を超えるトラフィックが発生したときの考え方の分類。

ポリシング(Policing)

ポリシングは制限値を超えるトラフィックがある場合に超えた部分を切り捨てる考え方。制限量を超えたタイミングだと相手まで到達しないものが出てくる。

シェーピング(Shaping)

シェーピングは制限値を超えるトラフィックが来た場合に、蓄積を行い順次処理をしていくようなやり方。制限量を超えるトラフィックを超える場合は遅延して処理していくことにはなる。

イメージ比較

制限値を超えたときの処理イメージを比較すると以下のようになる。

ポリシングとシェービングのイメージ図

手法 超過したトラフィックの処理方法 長所 短所
ポリシング 破棄する 超過分を破棄するの変化がない 破棄されてしまうので情報が損失してしまう可能性がある
シェーピング 遅延させる 損失がすくない 遅延をするのでリアルタイム性が失われる

関連リンク

リモートコミュニケーションを見直すときに読みたい記事『チームで仕事をするなら、リアクションし続けよ』

適宜振り返りたい記事なのでメモとして。

対象記事

チームで仕事をするなら、リアクションし続けよ|森 一貴(Mori Kazuki)

みどころ

リアクションが重要なことを説いているのだが、なかでも一番下のフレーズが印象深く残るポイント

議論において黙って静かにしていることは、実は透明になることではない。それは黙っていようがなんだろうが、「そのアイデアに賛同しません」という意味である、「そのアイデアはそこまでおもしろくないですね」と発言しているのと全く同じ意味である。だから、黙って静かにしていることは、それそのものが、議論を後ろに引っ張ることなのだ。

リモートミーティングの場合は、ビデオOFFや音声がうまく乗らないなどで、リアル対面よりはリアクションが薄れる。そのため、肯定なのか否定なのか思考中なのかが判断つきづらいのだが、何も反応がないことはマイナスに働くことは自分自身の無意識化にある体験を言語化されたようで非常によかった。

関連リンク

脆弱性周りの略語をざっくり整理する

自身の理解のためによく聞くものだけでも、の整理

CVE(Common Vulnerabilities and Exposures)

CVEは脆弱性を識別するための共通脆弱性識別子。要するに個々の脆弱性に関してわかりやすく管理するために振られるユニークなID。

管理しているのはアメリカ政府の支援を受けている非営利団体のMITRE社。またこのCVEを採番する権利がある機関のことをCNA(CVE Numbering Authorities)と呼ぶ。

https://www.cve.org/

JVN(Japan Vulnerability Notes)

日本国内で報告された脆弱性を共有するためのポータルサイト。国内で提供されているソフトウェアの脆弱性情報の流通を目的にしている。

前述のCVEの運用とともパートナーシップを結んでおり、JVN内で報告された脆弱性とCVEで互換性のあるものはわかるように扱わている。

https://jvn.jp/

NVD(National Vulnerability Database)

アメリカ国立標準技術研究所(NIST)が管理している脆弱性管理のデータベース。CVEや後述のCVSSなどが記載されるデータベースだが、2024年時点では運用が停滞している。

KEV(Known Exploited Vulnerabilities catalog)

実際に悪用が確認された脆弱性の一覧。CVEと連動して実際に悪用が発生したものを取り扱っている。

CVSS(Common Vulnerability Scoring System)

CVSSは脆弱性の深刻度に関しての指標を出すための手法。算出すされた指標の値はCVSSスコアと呼ばれる。

このCVSSスコア自体はバージョンによって異なり、現在最新のバージョンはv3となっている。

SSVC(Stakeholder-Specific Vulnerability Categorization)

CVSS同様に脆弱性を図る指標としてカーネギーメロン大学ソフトウェア工学研究所で考えられた指標。CVSSが脆弱性自体を数値化するのに対し、対応すべき方針が提示されるのが特徴

参考リンク