コード日進月歩

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

Google Tag Manager で Google Analytics 4のユーザスコープのカスタムディメンションを設定する場合は変数を使わないとできない

Googleタグになってからの設定方法がわかりにくいものが多かったのでメモとして。

ユーザスコープのカスタムディメンションとは

GoogleAnalytics4(以下GA4)ではユーザの属性情報などを設定できる「ユーザスコープのディメンション」があるが、独自でディメンションを設定したいときにユーザスコープのカスタムディメンションを使うことができる。 イベントのディメンションなどと異なるのは、ユーザそのものの属性なので、逐一イベント情報としてセットしなくても、ユーザ単位で情報を整理することができる。 たとえばユーザディメンションとして性別などの情報をもっているので、わざわざ毎イベントに性別情報をイベントディメンションとしてセットしなくてもユーザに一度付与するだけで探索に扱うことができる。

なお性別などは従来のディメンションとして用意されているので、公式のヘルプに入れたいものがないかを確認すると良いです。

Google Tag Manager(GTM)でのカスタムディメンションの設定方法

Google Tag Manager(以下GTM)でユーザーのカスタムディメンションを送付するには大きく3つのステップを踏みます。

  1. 送りたいユーザーの情報をGTMで取得できるようにDataLayerにpushする記述を追加する
  2. DataLayerの情報を拾い上げて変数として取得できるようにする
  3. GA4を実行するタグ(Googleタグ)の設定値として「Googleタグ:イベントの設定」変数で設定値を作る
  4. 送信の動作確認をする
  5. GA4側のユーザカスタムディメンションの設定を追加する

今回は udemae_rank というユーザスコープのカスタムディメンションをGA4で設定することを想定して例示を付記します。

1. 送りたいユーザーの情報をGTMで取得できるようにDataLayerにpushする記述を追加する

GTMに読み取る情報を設定する仕組みとして「DataLayer」という仕組みが存在している。DataLayerの情報設定は今回の本筋ではないので割愛するが、詳しくは公式のドキュメント を参照していただきたいです。

GTMで読み込む値として datalayer_udemae_rank という値をDataLayerの値として設定する場合、以下の内容を計測したいページに書き込みます。(細かい位置や制約などは公式ドキュメント参照のこと)

dataLayer.push({'datalayer_udemae_rank': 'B+'});

2. DataLayerの情報を拾い上げて変数として取得できるようにする

GTMではdataLayerの値をGTM上の変数として取り扱う設定があります。こちらも本筋ではないので詳しい説明は割愛しますが、「変数」→「ユーザ定義変数」の新規ボタン→鉛筆マークから「データレイヤーの変数」で設定を作ることができます。このとき読み込みたいデータレイヤー変数の名前を設定して取得できるようにします。

先程の例を踏襲すると、データレイヤーの変数名として datalayer_udemae_rank を記述します。名前は自由につけて問題ないのですが、例では「送信用データレイヤ変数」としています。

GTM上でdataLayerから取得した値を「送信用データレイヤ変数」として定義

3.GA4を実行するタグ(Googleタグ)の設定値として「Googleタグ:イベントの設定」タグで設定値を作る

計測をするためのGA4のタグと連動させます。前提としてGTMでGA4のタグを設定しておく必要があります。

従来GTMを使う場合は、GA4のタグの埋め込み自体はページ事に行うのではなくGTM側から埋め込みます。もし、GA4のタグをGA4で発行できるスニペットを使って埋め込んでいる場合はできないためGTM側にGA4の設定をする記述に変更してください。

2024年6月現在、GTMでGA4の設定をする場合は「Googleタグ」を作って設定します。

Google タグを選んで設定を作成する

このGoogleタグはGA4のタグを設定することができる設定情報になります。こちらも本筋ではないので割愛しますが、公式のドキュメントが非常に分かりづらいのでアユダンテさんの「[GTM] 新しいGA4のタグ設定の仕方 | アユダンテ株式会社」を参照にしてみてください。

このGoogleタグを設定すると、GA4の基本的な動作がするようになります。上記の参照ドキュメントにも記載はあるのですが、この「Googleタグ」の設定項目を調整するとユーザースコープのカスタムディメンションが送信されるようになります。

ユーザースコープのカスタムディメンションの設定方法

Googleタグには共通して送信するイベントの設定をする項目があります、それが「共有イベントの設定」です。そこに「イベントの設定変数」という項目があります。 ここにはGTM側の変数として「Googleタグ:イベントの設定」の変数が設定することができます。

Googleタグ:イベントの設定」には通常のイベント送信情報である「イベントパラメータ」の欄もあるのですが、ユーザスコープの内容を設定したい場合は Google Analytics User Properties の欄の方の設定を追記します。

今回は udemae_rank を送信したいので先ほど設定した「送信用データレイヤ変数」を値にセットし、プロパティ名を送信したいパラメータ名である udemae_rank に設定します。

GA4側で受け取ってほしいパラメータ名を記述して設定する

変数を作成したら、先程設定したGoogleタグ側の設定にも以下のように設定します。

Googleタグ側の「イベントの設定変数」に先程の設定を追加する

これでdataLayer.pushから拾い上げた値をGA4側へ送信できます。

4.送信の動作確認をする

動作確認をする場合は、「タグマネージャーのプレビュー」と「GA4のDebugView」を使うことで、ユーザープロパティの値として設定されているかを確認できます。事例ベースでの説明は割愛しますが、使い方の説明などは以下のアユダンテさんのサイト参照のこと。

5.GA4側のユーザカスタムディメンションの設定を追加する

GTM側で送信するだけしかしていないので、GA4側で利用できるようにカスタムディメンションの設定を追加してあげる必要がある。詳しくはこちらもアユダンテさんのサイト参照のこと。

Google アナリティクス 4 プロパティ(GA4)にカスタムディメンション / カスタム指標が登場! | アユダンテ株式会社

今回の場合は udemae_rank を追加してあげたいので、以下のスクショのような設定を追記してあげる。

範囲をユーザーにして作成する

なお、このカスタムディメンション設定前に到達したイベントは記録されないのでお気をつけください。

関連リンク

『「データモデリングでドメインを駆動する」読書感想会』を見たよメモ

書籍を完走しきれずイベント日を迎えましたが、『データモデリングでドメインを駆動する』読書感想会を見たのでメモです。

各発表の感想

書籍「データモデリングドメインを駆動する」の感想を各々語るスタイルで実施されたので、今回は感想を記載するスタイルでのひとくちメモになります。(お名前はconnpassやTwitterから拾いましたが間違えてたらご指摘ください。。)


magnoliakさんの感想発表

スライドは見つけたら貼ります

感想

  • 整合性の緩急の話は大変共感しやすい部分だなと改めて感じた。
  • ただ「詳細だけを記録してデータを使えばいいじゃない、と思ったがそうもいかなかった」という事例の話があったが、自分自身明確にこの手の話で打ちのめされた経験がないので具体エピソードを聞いてみたかった。

hidenorigotoさんの感想発表

感想

  • 問題領域と解決領域の部分のピックアップが助かりました。
  • ソフトウェア設計を題材にして考えてみるところは思考の訓練として面白そうでした

MadoWindaheadさんの感想発表

発表のもととなったブログは以下

madowindahead.info

感想

  • 利用者目線を持て、といっても自分本位の方に引きずられがちであるという話があり、刺さるものがあった。
  • プリトランザクションという考えの話は興味深かった
    • トランザクション処理の前(プリ)の情報を指すフレーズで、自身が掌握するシステムに入る前の情報のことを指す考え方、という話でした。
  • スチュワードシップなど普段考えない観点ああったのが学びがあった

masatsugumatsusさんの感想発表

感想

  • 「実装が好きな人は、実装的なシステムのモデルとメンタルモデルを合致させようとしてしまう」という旨の話があり難しい話だなと感じた
    • 普段Rails(というかActiveRecord)を利用して仕事しているとうまい折り合いの付け方は難しいと感じている。
  • マスターデータの話に関してはまだ書籍の読み込みが足らない部分なので、自分が理解しているマスターデータとの差分を埋めたいと思った。

kabanyasuさんの感想発表

発表中紹介されていたブログ 杉本啓さんの『データモデリングでドメインを駆動する』を公認会計士が読んだ感想 | コラム | 合同会社オントロジー

感想


Tanaka9230さんのLT感想発表

感想

  • 普段の生活のなかと今回の書籍を並べて考えるときにわかりやすい事例だった
  • 残と残をつなげるというのはややこしいが向き合わないといけないシーンはあるなと感じた。

関連リンク


yu_mi0825さんのLT感想発表

スライドは見つけたら貼ります

感想

  • RDBやアプリケーションフレームワークに引っ張られてモデリングしてはならないというところは大変共感できた
  • ルールにこそコアドメインが含まれているし、そのあたりがおざなりになりがちという旨の話があり、頭にいれておかないといけない考えだなと感じた

tunemageさんのLT感想発表

感想

  • 「よく言語化してくれた」という話をされていたので、基幹システムに携わる方には暗黙知形式知されたものなんだなという雰囲気が強く感じられた。
  • 私が基幹システムを普段やらないのもあったのだが「基幹システムだからわかりにくい部分が多い」というのは本当に感じたので読み終えた暁には書いていただいたブログを眺めたい

関連リンク


veilchenさんのLT感想発表

スライドは見つけたら貼ります

感想

  • Salesforceはつらい。
  • ローコードツール共通の概念ではあるが、よいデータの設計の仕方の勘所がない人がつくると後々辛くなるというのは本当にそうだな…と感じました。

smith_30_さんの感想発表

感想

  • SoRからSoEが生まれる瞬間というのが事例を交えて紹介されていたのでわかりやすかった
  • SoRとSoEのあたりも普段のソフトウェア開発と照らし合わせたときの概念がしっくり来てないので、書籍読みながら咀嚼したいなと感じた

全体を通しての感想

  • 「残」に関しての概念に関して感銘を受けた方が多く、みなさん口々に言及されていたように思う
  • 個人的に最後の感想戦で語られていた、自由度に関しての話に関して考えさせられる部分が多かった。
    • 固定する部分は固定し、可変できる部分を考える。可変の部分は個々人の裁量の可能性にも影響するのでガチガチに固めると新しい発想などが出てこない
    • 日本人の国民性みたいな部分として創意工夫するところがあるので、裁量という概念を置くのは重要そう
  • 書籍が時間の都合上完全に読みきれてないので、読み終えたあとに改めて今日の感想を咀嚼したいと思いました。

GA4のカスタムディメンションの設定上限数には限りがあるので注意する

意外と見落としがちなのでメモまで

GA4のカスタムディメンションとは

GA4に関してはすべての記録がイベントとなるため、それぞれのイベント名は必ずつくが、それに対応するパラメータなどは自分でアレンジをする必要がある。そのパラメータとして利用するのがカスタムディメンションとなる。

またカスタムディメンションには以下の3つの種類がある。

  • ユーザの属性などにつかう「ユーザースコープのカスタムディメンション」
  • 各種イベントの拡張につかう「イベントスコープのカスタムディメンション」
  • 商品などのアイテム情報の拡張に使う「アイテムスコープのカスタムディメンション」

なお、カスタムディメンション追加画面では「ユーザ」「イベント」「項目」となっているので気をつける。

カスタムディメンションの上限数に関して

以下のドキュメントに記述がある

[GA4] カスタム ディメンションとカスタム指標について - アナリティクス ヘルプ

関連リンク

緊急度、優先度の4象限のアイゼンハワーマトリクスについてざっくりまとめる

「緊急度と優先度の4象限」と言ってこれ自体の出自よくわかってないなと思ってまとめる

故障について

"Eisenhower Matrix"(アイゼンハワーマトリクス)がよく呼ばれる名称だが、 "Eisenhower Method" や "Eisenhower Principle" などとも呼ばれる。

出自

第34代アメリカ合衆国大統領であったドワイト・デイヴィッド・アイゼンハワー氏の演説にて、とある大学学長の言葉として以下のフレーズが紹介された

「私には2種類の問題があります。緊急な問題と重要な問題です。緊急な問題は重要ではなく、重要な問題は決して緊急ではありません。」

書籍「The 7 Habits of Highly Effective People(7つの習慣)」でこのフレーズにインスパイアされた4象限が紹介されたのが初出とされている。

考え方

タスクを下記の事象のいずれかに分類する

象限1. 緊急かつ重要 象限2. 緊急ではないが重要 象限3. 緊急だが重要ではない 象限4. 緊急ではないし重要でもない

順番が重要とされており、象限1の次は象限2に取り組むべきだが象限3や象限4に取り組んでしまいがちなので見極めるべきということが語られている。

なかでも事象3は「自分自身にとっては重要ではないが、緊急であるということは誰かにとっては重要なので移譲するべき」という考え方なので、事象3のアクションが移譲となる。

関連リンク

ふりかえりの手法に関して困ったときに見ると良いページ『ふりかえりを更に拡張する「ふりかえりカタログ(コミュニティ版)」』

たまに見返したくなるのでそのための道しるべとしてのメモ。

対象となるページ

ふりかえりを更に拡張する「ふりかえりカタログ(コミュニティ版)」 #アジャイル - Qiita

みどころ

様々なふりかえりの手法が紹介されているだけではなく、手法がカテゴライズされており、ざっくりどんなものがあるか眺めるということもできるし、類似のものを探す場合にも重宝する。

またMiroで運用されているので実際に使ってみた人々の感想が記載されており、参考になる部分が多い

関連リンク

Architecture Decision Recordsという用語と事例についてざっくりまとめる

ADRの始まりや各社事例を整理しておきたいのでまとめる

Architecture Decision Records(ADR)とは

ADRについて記述されているadr.github.ioでは下記のように書かれている。

アーキテクチャ上の決定(Architectural Decision:AD)アーキテクチャ上重要な機能的または非機能的要件に対応する、正当な設計上の選択である。アーキテクチャ上の重要な要件(Architecturally Significant Requirements:ASR)はソフトウェアおよびハードウェアシステムのアーキテクチャと品質に測定可能な影響を与える要件である。ADR(Architectural Decision Record)は、1つのADとその根拠を記録するもので、プロジェクトで作成・維持されるADRの集合は、その決定ログを構成する。これらはすべてアーキテクチャナレッジマネジメント(Architectural Knowledge Management:AKM)のトピックに含まれるが、ADRの使用は設計やその他の決定(「あらゆる決定記録」)に拡張できる。

上記のように「アーキテクチャ上の決定に関して根拠を記録するもの」として紹介されている。また呼び方にはブレがあるが上記サイトでは Architectural Decision に連動して Architectural Decision Record と呼ばれているが意味合いとしては同じ様子。

提唱されたブログ

書籍「ソフトウェアアーキテクチャの基礎」によるとMichael Nygard氏が「Documenting Architecture Decisions」にて提唱した方法論がはじまりとされています。

このPostそのものがADRのフォーマットを体現した状態での内容になっている。提唱されているフォーマットは以下の5つの要素を持つ.

  • Title(タイトル)
  • Context(コンテキスト)
  • Decision(決定)
  • Status(ステータス)
  • Consequences(結果/影響)

各要素と記述内容は以下

要素名 意味
Title(タイトル) 決定に対してのタイトル、例では「ADR:Ruby on Rails3.0.10へのデプロイ」など通し番号とドキュメントの端的な説明の文となっている
Context(コンテキスト) この決定に関しての前提となる事実など、決定に作用している予備情報を記述する
Decision(決定) 具体的に決定した内容を記述する。能動態の文章とするべきで「私達は◯◯します」と記述する。
Status(ステータス) このADR文章自体の取り扱い状況について記述する。例では「提案」「承認」「非推奨」「置換」の4つを持つ。「提案」がされ、合意形成がなされて同意を得られた場合は「承認」となり、その後別のADRに取ってかわわれた場合は廃止を意味する「非推奨」や他のADRに置き換えられた旨の「置換」のいずれかになる。
Consequences(結果/影響) この決定を適用したあとに対する結果や影響を記述する。例ではポジティブなものもネガティブなものも含めて結果を記述することが望まれている。

参考リンク

各社原典の内容を基軸にアレンジが加えられて運用がされている。事例なども含めてリンクをまとめる。

ADRそのものについて

ADRを運用してみての体験談

RailsでViewからControllerのメソッドを呼び出したいときはhelper_methodで定義するとできるが利用には気を払う

便利そうだが、いとも簡単に複雑化してしまうので備忘としてメモ。

環境

$ bin/rails -v
Rails 7.1.2
$ ruby -v
ruby 3.2.1 (2023-02-08 revision 31819e82c8) [aarch64-linux]

helper_methodの使い方

Controllerに存在するメソッドをViewで呼び出したいときに、helperのように扱えるようにするメソッド。またメソッドの呼び出し制限がprivateでも適用可能。

例えば下記のように設定する

▼app/controllers/users_controller.rb

class UsersController < ApplicationController
  helper_method :test_text

  def index
  end

  private
  
  def test_text
    "テストテキストです"
  end

end

▼app/views/users/index.html.erb

<h1>Users#index</h1>
<%= test_text %>

というように定義すると以下のようなhtmlが出力される。

<!DOCTYPE html>
<html>
  <head>
    <!-- 中略 -->
  </head>

  <body>
    <h1>Users#index</h1>
テストテキストです

  </body>
</html>

利用しないほうがいいポイント

予測がし難い

helper自体が定義の仕方によっては定義場所の特定がわかりにくいので、view側から特定するのが難しくなります。 また、superクラスやconcernで読み込んだメソッドも同じように扱えてしまうので、より特定がしづらくなります。

Controllerでの記述がViewにも影響を受けやすくなる

多くの場合は以下のようにインスタンス変数を取得したい場合などで使う

class UsersController < ApplicationController
  helper_method :access_user
  
  def index
  end
  
  private

  def access_user
    @user ||= User.find(params[:id])
  end
end

上記のようにcontroller上でインスタンス化された値などを再利用するケースでは一見便利なように見える。

しかしながら、上記のような記述だと一見してこのcontrollerでしか使わないように見える access_user メソッドが helper_method の影響でpublicメソッドと同じ扱いになるので、メソッドの露出範囲がわかりにくくなる。

そのため利用するときは影響範囲を気を払う必要がある。

関連リンク