GA4で(other)が表示される原因と消す方法｜カーディナリティ制限の仕組みと行がまとめられる時の回避設計

LP別のコンバージョン数を確認しようとレポートを開いたら、上位数十行の下に(other)という行がまとまった数字を抱えて居座っている——広告運用でGA4を触っている人なら、一度はこの画面で手が止まった経験があるはずです。どのLPが効いているのか、どのUTMパラメータの流入が転換しているのか、知りたい内訳がまさにその(other)の中に埋もれてしまう。

先に結論を言うと、(other)はGA4のバグでもデータの欠損でもありません。GA4のother表示は、レポートの行数上限（カーディナリティ制限）を超えた値がひとつの行にまとめられる仕様です。データそのものは収集されており、見え方の問題として切り分ければ対処できます。

この記事では、なぜ(other)が発生するのかという仕組みの理解から、今日できるレポート側の対処、実装側で(other)を出さないための予防設計、そしてBigQueryエクスポートへ判断を切り替える基準までを順に整理します。広告のLP別・UTM別分析で(other)に困っているマーケ責任者・運用担当者が、自分のプロパティでどこから手をつけるべきか判断できる状態を目指します。

この記事のポイント

• GA4のother表示は行数上限超過による集約であり、データ自体は欠損していない
• カーディナリティ（1日あたりのユニーク値数）が500を超えると高基数ディメンションとして扱われやすい
• 原因はユーザーID・フリーテキスト・タイムスタンプ・URLクエリ・連結値の5パターンに大別できる
• 探索レポートは(other)を回避できるがサンプリングとのトレードオフがある
• 1万値を超える高基数ディメンションはBigQueryエクスポートでの分析に切り替えるのが現実的な基準

GA4のレポートに(other)が表示されるのはなぜ？

見えないだけでデータは存在している

GA4の(other)とは、標準レポートの表示行数を超えたディメンションの値が、ひとつの行にまとめて集計されたものを指します。個々の値が消えたわけではなく、上限を超えた分がグループ化されて表示されているだけです。

(other)は不具合ではなくカーディナリティ制限の仕様

GA4の各レポートには、集計テーブルとして保持できる行数に上限があります。ディメンションのユニーク値の種類（カーディナリティ）がこの上限を超えると、上限内に収まらなかった値はまとめて(other)行に押し込まれます。これはUniversal Analyticsのサンプリングとは性質が異なり、あくまで「表示できる行の器の大きさ」に起因する仕様です。運用担当者が設定を間違えたから出るとは限らず、正常に計測できているプロパティでも、ディメンションの組み合わせ次第で発生します。

データは失われていない：見えなくなっているだけ

(other)にまとめられた値は、GA4の生データとしては保持されています。標準レポートの画面上で個別に確認できなくなっているだけで、探索レポートで軸を切り替えたり、BigQueryエクスポートで生イベントデータを直接クエリしたりすれば、個々の値を取り出すことが可能です。この「見えなくなっているだけ」という前提を押さえておくと、後述する対処の優先順位が立てやすくなります。

GA4のカーディナリティとは？行がまとめられる仕組み

図1: 表示レポート・集計テーブル・生データの3層構造

カーディナリティとは、あるディメンションが1日あたりにとりうるユニーク値の種類数のことです。この数が多いディメンションほど「高基数」と呼ばれ、(other)の主因になります。

高基数ディメンションの定義（1日あたりユニーク値500超）

明確な公式基準として文書化されているわけではありませんが、実務上の目安として1日あたりのユニーク値数がおおむね500を超えるディメンションは高基数扱いになりやすく、(other)が発生しやすい傾向があります。たとえば注文IDやセッションごとに変わるトークンのような値をそのままカスタムディメンションに設定すると、1日で数千〜数万のユニーク値が生まれ、あっという間に上限を超えます。

標準レポートの行数上限と(other)への集約

GA4の標準レポートは、内部的にディメンションの組み合わせごとに集計済みテーブルを持っています。このテーブルの行数には上限があり、超えた分は自動的に(other)へ集約されます。上限の具体的な数値は公式に一律で公表されているわけではなく、レポートの種類やディメンションの組み合わせによっても変動するため、「何行までなら安全か」を厳密に見積もるより、そもそも高基数の値を作らない設計を優先するほうが現実的です。

表示レポート・集計テーブル・生データの3層構造で理解する

Optimize Smartでは、GA4のレポート構造を「表示レポート」「集計済みテーブル」「生イベントデータ」の3層で捉える整理が紹介されています。(other)が発生するのは中間層の集計済みテーブルの上限であり、生イベントデータそのものには影響しないため、探索レポートやBigQueryエクスポートのように生データに近い層へアクセスする手段を使えば(other)を回避できる、という説明です。日本のマーケ現場でも、この3層モデルで「なぜ探索なら消えるのか」を理解しておくと、対処法の選択に迷いにくくなります。

さらに同記事では、表示中のディメンション自体は低基数でも、同じ集計テーブルを共有する別の高基数ディメンションが原因で(other)が出てしまう落とし穴も指摘されています。見ている軸が単純だからといって(other)と無縁とは限らない点は、覚えておく価値があります。

(other)と(not set)・データしきい値の違いは？

(other)・(not set)・データしきい値は見た目が似ていますが、原因も対処もまったく別物です。混同したまま対処すると的外れな作業になりかねません。

(not set)は値の欠落、(other)は上限超過による集約

(not set)は、そのディメンションに該当する値がそもそも取得・送信されていない状態を指します。一方(other)は、値自体は送信されているものの、行数上限を超えたためにまとめられた状態です。(not set)の対処はタグ実装の見直しや計測漏れの特定が中心になりますが、(other)の対処はカーディナリティの圧縮やレポートの切り替えが中心になり、アプローチが異なります。ランディングページが(not set)になる原因については、GA4のランディングページが(not set)になる原因4パターンで個別に整理しています。

データしきい値はGoogleシグナル由来のプライバシー保護

データしきい値は、Googleシグナルなどのプライバシー保護対象データを含むレポートで、ユーザー数が一定に満たない場合に数値が非表示になる仕組みです。カーディナリティとは無関係で、プライバシー保護の観点から意図的に情報が抑制されている点が(other)と根本的に違います。この二つを同じ現象だと誤解して対処法を探すと迷走しやすいため、切り分けが重要です。詳しい仕組みはGA4のデータしきい値の仕組みと回避設計で解説しています。

表示	原因	主な対処
(other)	カーディナリティ（行数上限）超過	レポート切り替え・実装側での値の圧縮
(not set)	値そのものが未取得・未送信	タグ実装・計測設計の見直し
データしきい値	Googleシグナル由来のプライバシー保護	しきい値を超えるデータ量の確保、対象外レポートの活用

(other)が出やすい原因5パターン｜自社プロパティの診断ポイント

自社プロパティで(other)が出ている場合、まず疑うべきはカスタムディメンションの設計です。Delta V Digitalの記事では、原因をユニークID・フリーテキスト・タイムスタンプ・粒度過剰な日付・連結変数の5パターンに分類しており、この切り口は診断の出発点として使いやすいものです。

ユーザーID・注文IDをカスタムディメンションに入れている

会員IDや注文番号、セッショントークンのような一意性の高い値をカスタムディメンションに設定すると、1日で発生するユニーク値の数がそのままカーディナリティになります。数百人・数千件の規模でも簡単に高基数化するため、真っ先にチェックすべきポイントです。ユーザー単位の分析が目的であれば、カスタムディメンションではなく後述するUser-IDの仕組みを使うほうが適切です。

フリーテキストや生タイムスタンプを送っている

検索窓に入力された検索キーワードそのものや、秒単位までの生タイムスタンプをディメンションとして送っている場合も、値の組み合わせが実質無限に近くなります。フリーテキストは表記ゆれも加わるため、集計上の意味を持たないまま行数だけを消費してしまうケースが少なくありません。

URLクエリパラメータでページ系ディメンションが無限に増えている

ページのURLやページパスのディメンションに、セッションIDや不要なトラッキングパラメータがそのまま付いた状態で計測していると、本来は同じページのはずの値がパラメータの違いごとに別の値として扱われます。結果として想定外の高基数化を招き、ページ別レポートで(other)が目立つ原因になります。

複数の値を連結したカスタムディメンション

「カテゴリ+商品ID」「デバイス+地域」のように複数の値をGTM側で連結してひとつのディメンションに詰め込む設計も要注意です。それぞれの値のユニーク数がそこまで多くなくても、掛け合わせた組み合わせ数は急激に膨らみます。連結する前提でディメンションを設計する場合は、掛け算後のユニーク値数を見積もっておく必要があります。

GA4の(other)を今すぐ消す方法｜レポート側の対処4つ

実装を変えずに今日から試せる対処は複数あります。優先順位としては、まず影響範囲の小さいレポート側の工夫から着手するのが現実的です。

探索レポートで見る（ただしサンプリングに注意）

探索レポートは標準レポートとは別の集計経路を使うため、同じディメンションでも(other)を回避できる場合があります。ただしOnline Metricsの記事が指摘するように、無償版のGA4では一定のイベント数（同記事では1,000万イベントが目安として挙げられています）を超えるデータ量に対してサンプリングが適用され得るというトレードオフがあります。(other)は消えたが数値が標準レポートとズレる、という新たな悩みに直面する読者も多く、そのズレの原因はGA4の標準レポートと探索レポートで数値が合わない原因5パターンで個別に扱っています。

期間を短くする・セカンダリディメンションとフィルタを減らす

集計対象の期間を短くしたり、セカンダリディメンションやフィルタの数を減らしたりすると、集計テーブルが扱う組み合わせ数が減り、(other)の発生を抑えられることがあります。応急処置としては手軽ですが、見たい期間や粒度そのものを犠牲にする対処なので、恒常的な解決策にはなりにくい点は理解しておく必要があります。

既定ディメンションのレポートに切り替える

カスタムディメンションではなく、GA4が最初から用意している既定ディメンション（参照元/メディア、ランディングページなど）だけで構成されたレポートに切り替えると、(other)が出にくくなる場合があります。カスタムディメンションを併用しているレポートで(other)が目立つなら、まず既定ディメンションだけの表示に戻して切り分けてみるのが手早い診断方法です。

GA4 360の拡張データセットという選択肢

GA4 360を契約しているプロパティでは、拡張データセットという機能を使うことで、より高いカーディナリティに対応したレポートを構成できます。無償版のGA4で恒常的に(other)に悩まされており、かつBigQueryへの移行までは踏み切りにくい組織にとっては、選択肢のひとつになり得ます。ただし契約規模やコストの制約があるため、多くの中小規模の広告運用チームにとっては次章のBigQueryエクスポートのほうが現実的な着地点になりやすいでしょう。

(other)を発生させない回避設計｜計測実装側の対処

図2: 1日のユニーク値数で分岐する対応フローチャート

レポート側の工夫は対症療法です。根本的に(other)を出しにくくするには、GTMやカスタムディメンションの設計段階で手を打つ必要があります。

カスタムディメンションの棚卸し：1日500値の閾値で判定

既存のカスタムディメンションを一覧化し、それぞれが1日あたり何種類のユニーク値を生んでいるかを確認します。Delta V Digitalが示す判断ツリーを参考にすると、目安として1日500値未満なら概ね安全、500〜1万値程度であれば後述するGTMでの値の丸め込みを検討、1万値を超えるようであればBigQueryエクスポートでの分析に切り替える、という三段階の判断がしやすくなります。

1日あたりのユニーク値数の目安	対応方針
500未満	そのままカスタムディメンションとして運用して問題になりにくい
500〜1万程度	GTMで値を丸める、粒度を落とすなどの圧縮を検討
1万超	GA4レポートでの表示は諦め、BigQueryエクスポートでの分析に切り替える

GTMで値を丸める：日付・金額・IDのバケツ化

日付を「YYYY-MM-DD」のまま送るのではなく「YYYY-MM」に丸めるだけで、1年分の365値が12値まで圧縮できます。金額も1円単位ではなく1,000円刻みなどの区分（バケツ）にまとめる、IDは先頭数桁だけを使うといった加工をGTMのカスタムJS変数で行うことで、分析に必要な粒度を保ちながらカーディナリティを抑えられます。Delta V Digitalではこの日付丸め込みの例が具体的に紹介されており、実装のハードルも比較的低い対処法です。

ユーザー識別はカスタムディメンションではなくUser-IDで

会員IDやログインユーザーを軸にした分析をしたい場合は、カスタムディメンションに詰め込むのではなく、GA4が標準で用意しているUser-ID機能を使うのが本来の設計です。User-IDはユーザー識別のための専用の仕組みとして設計されており、カスタムディメンションの行数上限とは別枠で扱われます。

不要なURLクエリパラメータの除外（UTM・gclidは残す）

Online Metricsが予防策の筆頭に挙げているのが、ページURLからの不要なクエリパラメータの除外です。セッションIDや内部トラッキング用のパラメータをGTMの設定画面やGA4の管理画面で除外することで、ページ系ディメンションの高基数化を防げます。ただし、広告運用の分析で必須となるUTMパラメータやgclidは除外対象に含めないよう注意が必要です。ここを一括で削除してしまうと、今度は媒体別・キャンペーン別の分析ができなくなり、本末転倒になります。

BigQueryエクスポートで根本解決すべきケースの判断基準

図3: GA4で見るかBigQueryに出すかの判断フロー

GA4画面での工夫には限界があります。どこまでGA4のレポート機能で粘り、どこからBigQueryエクスポートに切り替えるかの判断軸を持っておくと、無駄な試行錯誤を減らせます。

GA4に残す分析とBigQueryに出す分析の切り分け

日常的なモニタリング、たとえば全体のセッション数やコンバージョン数の推移、既定ディメンションでの大まかな傾向把握は、GA4の標準レポートや探索レポートで十分に対応できます。一方、注文ID単位の突合、ユーザーIDと広告媒体データを掛け合わせた高度な分析、1万値を超える高基数ディメンションでの内訳確認といった用途は、GA4の画面上での解決が構造的に難しく、BigQueryエクスポートで生データを直接扱うほうが早道です。Online Metricsも、探索レポートのサンプリングと(other)の両方を同時に回避できる手段はBigQueryエクスポートのみだと整理しています。BigQuery連携が広告計測にもたらす実務インパクトの詳細はGA4×BigQuery連携の実務インパクトと導入判断にまとめています。

SQLが書けないチームの現実解

BigQueryエクスポート自体は無償で有効化できますが、そこからSQLでデータを取り出すスキルがないと宝の持ち腐れになります。社内にSQLを書ける人材がいない場合は、いきなり複雑な分析基盤を組もうとせず、まずは基本的なSELECT文でイベントデータを眺めるところから始めるのが現実的です。BigQueryでGA4生データを触る最初の一歩のように、小さく始めて必要な分析だけを外部委託やツール活用で補うアプローチのほうが、途中で頓挫しにくいと言えます。

広告運用の実務で(other)を放置するとどうなる？

不透明なデータの上で下される意思決定のリスク

(other)を「よくある表示」として放置すると、広告の意思決定に直接影響します。特にLP別・UTM別の分析を日常的に行うチームほど、影響は無視できません。

ランディングページ別・参照元別レポートの内訳が崩れる

複数のLPを運用し、UTMパラメータでキャンペーンごとに流入を分けて計測している場合、ページパスやUTMパラメータの組み合わせ自体がカーディナリティを押し上げる要因になりやすくなります。上位のLPは正しく表示されても、テスト中の新規LPや小規模配信のLPがまとめて(other)に埋もれ、「効果が出ているのか判断できない」という状況に陥りがちです。意思決定に使う軸ほど(other)の影響を強く受ける、という逆説的な構造がここにあります。

媒体管理画面との突き合わせ精度が落ちる

広告媒体側の管理画面が示すクリック数・コンバージョン数と、GA4側のセッション数・コンバージョン数を突き合わせて予算配分を判断している運用チームは多いはずです。GA4側の内訳が(other)にまとめられてしまうと、どのキャンペーン・どの広告グループがGA4上のどのセッションに対応するのかが特定できなくなり、突き合わせの精度そのものが落ちます。結果として、本来は削るべきでない配信を止めてしまう、逆に伸ばすべき配信を見逃す、といった判断ミスにつながりかねません。

よくある質問

Q：GA4の(other)とはどういう意味ですか？消えたデータはどこに行くのですか？ (other)は、レポートの行数上限（カーディナリティ制限）を超えた値がひとつにまとめられて表示されている状態です。データ自体は削除されておらず収集済みで、探索レポートやBigQueryエクスポートを使えば個別の値として確認できます。

Q：(other)と(not set)は何が違いますか？ (not set)はディメンションの値そのものが取得・送信されていない状態を指し、(other)は値は送信されているものの行数上限を超えて集約された状態を指します。原因が異なるため、対処法もタグ実装の見直しとカーディナリティの圧縮という別のアプローチになります。

Q：GA4のカーディナリティとは何ですか？上限はいくつですか？ カーディナリティとは、あるディメンションが1日あたりにとりうるユニーク値の種類数のことです。明確な公式上限は一律で公表されていませんが、実務上は1日あたり500を超えると高基数ディメンションとして扱われやすく、(other)の主因になりやすいとされています。

Q：探索レポートにすれば(other)は完全になくなりますか？ 探索レポートは(other)を回避できる場合がありますが、無償版のGA4では一定のイベント数を超えるとサンプリングが発生し得るというトレードオフがあります。(other)を消すことと数値の正確さを両立させたい場合は、最終的にBigQueryエクスポートを検討する必要があります。

Q：(other)はどれくらいの割合まで放置してよいですか？ 割合の一律の基準はなく、意思決定に使っているディメンションに(other)が出ているかどうかで判断すべきです。LP別レポートや参照元別レポートといった、広告の予算配分判断に直結する軸に(other)が目立つ場合は、放置せず優先的に対処したほうがよいと言えます。

---

GA4の(other)は、原因を切り分けさえすれば決して手に負えない現象ではありません。真策堂では、広告運用の現場で実際に困りやすいLP別・UTM別分析の内訳崩れという観点から、GA4のレポート設計とカスタムディメンションの棚卸しについて相談を受けています。自社プロパティで(other)がどのレポートに、どの程度出ているのか整理したい場合は、まずは現状のディメンション設計を一度見直してみることをおすすめします。