New Relic Browser で「検索キーワード」や「キャンペーンID」を分析する方法を解説します。 バックエンドの改修は不要。フロントエンド（JavaScript）のみで URL パラメータを取得し、カスタム属性として送信する手順と、実運用でハマりやすいポイント（SPA 対応・データの正規化）をまとめました。
はじめに
New Relic Browser を導入していると、「特定の検索キーワードでパフォーマンスが落ちていないか？」「広告キャンペーン経由のユーザー体験はどうか？」といった分析をしたくなることがあります。
しかし、New Relic はデフォルトでは URL のクエリパラメータ（?q=xxx など）を収集しません。
この記事では、バックエンドに手を入れず、フロントエンド（JavaScript）のみで URL パラメータを取得し、New Relic のカスタム属性（Custom Attributes）として送信する方法を紹介します。
今回のポイント
この記事で紹介しているポイントは、次の2つです。
-
フロントエンドのみで URL パラメータを収集する方法を知る
バックエンドに手を入れず、JavaScript（URLSearchParamsとsetCustomAttribute）だけで実装する手順を紹介します。 -
実運用でハマらないためのプラクティスがわかる
データの正規化やセキュリティ対策（Allowlist化）、SPAとMPAでの挙動の違いなど、実装時に知っておくべき注意点を紹介します。
最新のアップデートの詳細はこちら
New Relic アップデート一覧
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！
どういうときに使う？
主に以下のようなシーンで役立ちます。
-
サイト内検索の分析
-
?q=New+Relic→ ユーザーがどんなキーワードで検索しているか、その検索結果ページの表示速度はどうかを知りたい
-
-
広告・キャンペーンの効果測定
-
?utm_campaign=spring_sale→ 特定のキャンペーンからの流入ユーザーのエラー率やパフォーマンスを見たい
-
-
トラブルシューティング
- 特定のパラメータがついている時だけエラーが発生していないか確認したい
なぜデフォルトでは収集されないのか？
URL パラメータには、メールアドレス、アクセストークン、個人を特定できる ID など、機密情報が含まれる可能性があります。
そのため、New Relic Browser は セキュリティとプライバシー保護の観点から、デフォルトではクエリパラメータを収集しない 仕様になっています。
したがって、分析に必要なパラメータがある場合は、「安全なものだけ」を「明示的に」選んで送信する実装が必要です。
【実践】3ステップで実装する
では、実際にデータを送るための実装手順を紹介します。
Step 1: 最小の実装（まずはここから）
ブラウザでは URLSearchParams を使うことで、簡単にクエリパラメータを取得できます。
// 例: https://example.com/search?q=New+Relic
// 1. URLパラメータを取得
const params = new URLSearchParams(window.location.search);
const q = params.get('q');
// 2. New Relic Browser エージェントが存在するか確認して送信
// 'search_query' という名前で、値 q を送信
if (q && window.newrelic) {
newrelic.setCustomAttribute('search_query', q);
}
基本的にはこれだけで動きますが、実運用ではもう少しケアが必要です。
Step 2: 実運用に向けたデータの正規化（重要！）
そのままの値を送ると、「不要なスペースが含まれている」「値が長すぎてデータが分析し辛い」といった問題が発生します。
分析しやすくするために、簡単な正規化（クリーニング）処理を入れることを推奨します。
-
デコード:
URLSearchParamsが自動で行うためdecodeURIComponentは不要です -
空白処理:
+や%20、全角スペースを半角スペースに統一してトリムします - 文字数制限: 悪意のある長い文字列や、意図しない長文パラメータをカットします
// 安全に値をきれいにする関数
function normalizeParam(input) {
if (!input) return null;
return input
.trim() // 前後の空白削除
.replace(/[\s\u3000]+/g, ' ') // 連続する空白・全角空白を1つの半角空白に
.slice(0, 128); // 128文字でカット（文字数は要件に合わせて調整）
}
const params = new URLSearchParams(window.location.search);
const rawQ = params.get('q');
const cleanQ = normalizeParam(rawQ);
if (cleanQ && window.newrelic) {
// 第3引数については後述
newrelic.setCustomAttribute('search_query', cleanQ);
}
Step 3: 実行タイミングとスクリプトの配置場所
setCustomAttribute は、呼び出し以降に発生するイベント（PageViewなど）に属性を付与します。
そのため、ページロード時（PageViewイベント）に属性を紐付けるには、Browser エージェント（スニペット）の読み込み直後に実行するのがベストプラクティスです。
配置例 (<head> 内推奨):
<head>
<script type="text/javascript">
window.NREUM||(NREUM={});... (省略) ...
</script>
<script type="text/javascript">
(function() {
// Step 2のコードをここに記述
const params = new URLSearchParams(window.location.search);
// ... (省略) ...
if (cleanQ && window.newrelic) {
newrelic.setCustomAttribute('search_query', cleanQ);
}
})();
</script>
</head>
知っておくべき重要Tips
1. MPAとSPAでの「属性の引き継ぎ（リセット）」の違い
アプリケーションの構成（MPA か SPA か）によって、画面遷移した際に属性がリセットされるかどうかの挙動が決定的に異なります。
-
MPA（従来のページ遷移型）の場合:
- 画面遷移のたびにページ（メモリ）がリロードされます
- そのため、前のページで設定した属性は自動的にリセットされます。次のページには引き継がれません
-
setCustomAttributeの第3引数（永続化フラグ）にtrueを設定すると次のページに遷移しても引き継ぐことが可能です
-
SPA（React, Vue, Next.js など）の場合:
- 画面遷移してもページのリロードは行われず、JavaScript の状態が維持されます
- そのため、
setCustomAttributeでセットした値は、画面遷移してもデフォルトで残り続けます（引き継がれます） - 例えば、検索ページで「検索語」をセットした後、トップページに遷移しても、トップページのデータに「検索語」が付いたままになってしまいます
-
対策: SPA の場合は、コンポーネントのアンマウント時（
useEffectのクリーンアップ関数など）や、次のページへの遷移時に、値をnullに設定して明示的に削除する実装が必要です
// SPAでのリセット例
newrelic.setCustomAttribute('search_query', null);
2. setCustomAttribute の第3引数（永続化フラグ）
setCustomAttribute には第3引数があり、属性の有効範囲を制御できます。
// 第3引数: persistent (boolean)
newrelic.setCustomAttribute('key', 'value', true);
-
true(Persistent): セッション中、その後のページ遷移でもずっと値が保持されます-
向いているもの:
utm_campaign（流入元）、user_type（会員ランク）など、サイト回遊中ずっと紐付けておきたい情報
-
向いているもの:
-
falseまたは省略 (Default): そのページビュー（およびそのページ内で発生するAjaxやError）のみ有効です-
向いているもの:
search_query（検索語）など - ※ 検索語を
trueにすると、検索後にトップページに戻った際、トップページの PV にまで「検索語」が付いてしまい、分析のノイズになることがあります
-
向いているもの:
3. セキュリティとプライバシー（Allowlist方式の推奨）
「URLパラメータを全部ループして送れば楽ではないか？」と思うかもしれませんが、セキュリティ上おすすめしません。
誤って個人情報（メールアドレスや一時的なトークンなど）が URL に含まれていた場合、それも New Relic に送信してしまうリスクがあるからです。
必ず 「取得するパラメータ名はコード内で指定（Allowlist化）する」 ようにしましょう。
New Relic には、システム側ですでに使用されている 「予約語（Reserved words）」 や 「デフォルト属性」 が存在します。これらと同じ名前でカスタム属性を送ろうとすると、データが無視されたり、上書きできなかったりします。
4. 予約語（Reserved Words）との衝突に注意
timestamp や accountId、appId など、New Relic がシステム内部で使用している属性名と重複する名前で setCustomAttribute を実行しても、予期しない結果になる 場合があります。
-
避けるべき名前の例:
timestamp-
accountId,appId -
facet,day,likeなどのNRQLの構文
-
対策:
- 汎用的な名前（
id,type,nameなど）は避け、search_queryやcampaign_idのように具体的で衝突しにくい名前にする - または、
app_category、custom_user_typeのようにプレフィックス（接頭辞）を付ける運用にする
- 汎用的な名前（
New Relic (NRQL) での確認方法
実装してデプロイしたら、実際にデータが取れているか NRQL で確認してみましょう。
FROM PageView
SELECT count(*)
FACET pageUrl, search_query
WHERE search_query IS NOT NULL
SINCE 1 day ago
-
FACET pageUrl, search_query: ページごと、検索語ごとにグルーピングして表示します -
WHERE search_query IS NOT NULL: 検索を行っていない（属性がない）PVを除外して、グラフを見やすくします
これで、どの検索キーワードが多いか、あるいは特定のキーワードでエラーが出ていないかなどを分析できるようになります。
まとめ
New Relic Browser の標準機能では収集されない URL パラメータも、フロントエンドでひと手間加えるだけで貴重な分析データに変わります。
実装自体は URLSearchParams と setCustomAttribute を組み合わせるだけのシンプルなものですが、データの正規化（トリムや文字数制限）や、必要なパラメータのみを指定する Allowlist 方式を徹底することで、安全かつ精度の高い分析が可能になります。
バックエンドに手を入れずに手軽に始められる施策ですので、まずは検索キーワードやキャンペーン効果の可視化から試してみてはいかがでしょうか。
New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！
New Relic株式会社のX(旧Twitter) や Qiita OrganizationOrganizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！
