計測タグはサーバー側にも置ける｜取りこぼしを減らす選択

「計測の数字が、実際の申込数と合わなくなってきた」「取りこぼしがあると聞いたが、何を変えればよいのか分からない」——計測を続けている担当者が抱えるようになった不安です。計測の仕組みは、閲覧している側の環境に依存しています。その環境で止められると、こちらには何も届きません。この記事では、取りこぼしが起きる仕組みと、別の置き場所という選択肢を整理します。

数字が合わなくなった背景

計測の数字が合わない状況は、ここ数年で明確に悪化しました。原因は1つではありません。

最も大きいのが、ブラウザ側の制限です。訪問者を識別する仕組みに制限がかかりました。

同じ人の再訪が別人として数えられる場面が増えました。

次に大きいのが、通信を遮断する仕組みの普及です。計測の通信が届かない場合があります。

届かなければ、その訪問は記録されません。数字が実際より少なくなります。

さらに、複数の機器を使い分ける行動も影響します。同じ人が複数に数えられます。

これらが重なり、集計と実態の差が広がりました。差の大きさは業種によって違います。

差があること自体は避けられません。問題は、差が大きすぎて判断に使えない状態です。

どこで判断が狂うのか

数字の取りこぼしは、単に件数が減るだけの問題ではありません。判断が狂います。

たとえば広告の成果が正しく記録されないと、効いている広告が効いていないように見えます。

その結果、止めるべきでない広告を止める判断が生まれます。

また、自動で調整される仕組みに渡す情報も減ります。調整の精度が落ちます。

集計の側でも、経路ごとの貢献が読めなくなります。予算の配分を誤ります。

つまり取りこぼしは、数字の見た目ではなく意思決定の質に影響します。

従来の方式の仕組み

対処を理解するために、まず従来の仕組みを押さえます。ここが出発点です。

従来は、訪問者のブラウザ上で処理が動きます。ブラウザから各サービスへ直接送ります。

送り先は複数あります。集計の仕組み、広告の各サービス、その他の計測の道具です。

それぞれに向けて、ブラウザから別々に通信が出ます。数が多いほど処理も増えます。

この構造には利点があります。設定が簡単で、費用もかかりません。

一方で、弱点もあります。ブラウザ側の制限や遮断の影響を直接受けます。

さらに、通信の内容が訪問者側から見える状態です。何を送っているかが分かります。

処理の量が多いと、表示の速さにも影響します。ここも弱点になります。

サーバー側に置く方式の仕組み

次に、対処の方式を見ます。構造が変わります。

ブラウザと各サービスの間に、自社のサーバーを挟みます。中継の役を置く形です。

ブラウザは、自社のサーバーに向けて1回だけ送ります。送り先が1つになります。

受けたサーバーが、内容を整理して各サービスへ転送します。ここが中心の働きです。

この構造にすると、ブラウザ側の処理が減ります。表示が速くなります。

また、自社の領域から送る形になるため、遮断の影響を受けにくくなります。

さらに、サーバー上で内容を加工できます。ここが後で重要になります。

訪問者側から見えるのは、自社のサーバーへの通信だけです。中身は見えません。

自社の領域から送る意味

この方式の効き方を理解する鍵が、自社の領域から送るという点にあります。

従来は、外部のサービスの領域に向けて通信が出ていました。外部への通信だと分かります。

分かるため、遮断の対象になります。ブラウザ側の制限もかかりやすくなります。

一方、自社のサーバーへ送る通信は、そのサイト自身への通信です。

同じ領域の中でのやりとりになるため、扱いが変わります。ここが取りこぼしの軽減につながります。

設定には、自社の領域の中に中継用の名前を用意する作業が含まれます。

この作業には名前解決の設定の知識が要ります。ここが専門性の要る部分です。

中継が加工の場になる

この方式の要点は、中継の場で内容を加工できることです。

たとえば、個人を識別しうる情報をここで除くことができます。手前で落とせます。

送り先ごとに、渡す項目を変えることもできます。必要なものだけを送ります。

従来の方式では、ブラウザから直接送るため、この加工ができません。

加工の場ができることで、何を外部に渡すかを自社で制御できるようになります。

この点は、預かっている情報の扱いを整えるうえで大きな意味を持ちます。

得られるものを整理する

この方式で得られるものを整理します。5つあります。

得られるもの	内容	効き方
取りこぼしの軽減	自社の領域から送るため遮断されにくい	件数が実態に近づく
表示の速さ	ブラウザ側の処理が減る	離脱が減る可能性がある
情報の制御	手前で個人情報を除ける	外部に渡す項目を絞れる
送り先の一元化	1か所から各サービスへ転送する	追加や変更が楽になる
連携との相性	各サービスの連携の仕組みと組みやすい	広告側の精度が上がる

1つ目と3つ目が導入の主な理由になります。

取りこぼしが減ると、判断に使える数字になります。ここが最大の効果です。

情報の制御は、規模の大きい会社ほど重視されます。外部に渡す項目を管理できます。

2つ目の表示の速さは、副次的な効果です。これだけを目的にはしません。

4つ目の一元化は、運用の手間に効きます。道具を増やすときの作業が減ります。

必要になるものを整理する

一方で、必要になるものもあります。ここを軽く見ると失敗します。

1つ目は費用です。クラウドのサーバーの利用料が月に数千円から数万円かかります。

この額は、訪問の量によって変わります。量が多ければ上がります。

2つ目は専門の知識です。クラウドの設定と、名前解決の設定が必要になります。

この2つは、通常の計測の設定とは別の領域です。担当できる人が限られます。

3つ目は、対応していない道具の存在です。すべての計測の道具が使えるわけではありません。

使っている道具が対応しているかを、事前に確かめる必要があります。

4つ目は、運用の負担です。サーバーが止まれば計測も止まります。監視が必要になります。

費用を抑える設定がある

費用については、抑える方法があります。ここを知らないと過大に見積もります。

クラウドの実行環境では、待機の数を0に設定できます。訪問がない時間は停止します。

停止している間は費用が発生しません。訪問の少ないサイトでは効果が大きくなります。

ただし、停止から起動までにわずかな遅れが生じます。最初の1件で影響が出ます。

訪問が常にある規模では、この設定は使いません。停止する時間がないためです。

自社の訪問の分布を見て、どちらの設定が合うかを決めます。

導入すべき規模の目安

導入の判断は、規模で決めます。すべての会社に必要なものではありません。

目安として、月間の訪問が数十万に達する規模から検討の対象になります。

この規模では、取りこぼしの絶対数が大きくなります。判断への影響も大きくなります。

それより小さい規模では、費用と手間に対して得られるものが小さくなります。

ただし、規模が小さくても導入する理由がある場合があります。

1つは、広告の費用が大きい場合です。計測の精度が費用の配分に直接効きます。

もう1つは、外部に渡す情報を厳しく管理する必要がある場合です。

この2つに当たるなら、規模が小さくても検討の価値があります。

逆に、どちらにも当たらず規模も小さいなら、従来の方式で十分です。

先に試すべき別の対処

この方式に進む前に、確かめるべき別の対処があります。順序が大事です。

1つ目は、計測の設定そのものの見直しです。設定の誤りで数字が合わないことがあります。

二重に数えている、逆に数えていない箇所があるという状態です。

2つ目は、集計の期間や定義の違いです。管理画面と自社の集計で定義が違うことがあります。

3つ目は、広告側の連携の設定です。連携の仕組みを使うだけで改善する場合があります。

これらは費用がかからず、数日で確かめられます。先にここを見ます。

順序を飛ばして大きな仕組みに進むと、原因が別だった場合に無駄になります。

差の原因を切り分けてから、この方式の必要性を判断します。

切り分けの具体的な手順

切り分けの手順を具体化します。上から順に当てると原因が絞れます。

最初に、同じ操作を自分で行い、記録されるかを確かめます。1件が通るかを見ます。

通らないなら設定の問題です。通るなら、記録の重複や欠落の割合を見ます。

次に、期間の定義を揃えます。管理画面と自社の集計で、日付の区切りが違うことがあります。

時差の設定が違っているだけで、数字が合わないことは珍しくありません。

最後に、何を1件と数えるかを確かめます。定義が違えば、数字は当然合いません。

この3つで、差の多くは説明が付きます。残った差が方式の対象になります。

進め方の手順

導入する場合の手順を示します。段階を分けて進めます。

4つ目の並行の期間が重要です。一気に切り替えると比較ができません。

並行させると費用は二重になりますが、1か月分なら許容できる範囲です。

比較なしに切り替えると、効果があったのか分からないまま運用が続きます。

記録の取り方を決めておく

1つ目の工程で取る記録は、後の判断のすべての土台になります。形を決めます。

記録するのは、経路ごとの件数と、管理画面側の件数、その差の割合です。

週単位で1か月分取ります。1日だけでは偏りが出ます。

経路ごとに分けるのは、差の出方が経路によって違うためです。

広告経由の差が大きく、検索経由の差が小さい、といった傾向が見えます。

この傾向が分かると、どこに効くのかを予測できます。判断の材料になります。

やりがちな失敗

この方式で起きやすい失敗を挙げます。多くは順序と体制の問題です。

• 設定の誤りを確かめずに導入する：原因が別なら差は縮まない。先に切り分ける
• 一気に切り替える：比較ができず、効果があったのか分からないまま運用が続く
• 担当を決めずに始める：設定の維持ができず、止まったときに誰も直せない
• 費用の見積もりに訪問の量を入れない：量が増えると費用も上がる
• 対応していない道具を後から見つける：構成をやり直すことになる
• 監視の仕組みを用意しない：サーバーが止まっても気づけず、計測が丸ごと抜ける

最後の項目が最も重大です。計測が止まると、その期間の数字が失われます。

失われた数字は後から復元できません。判断の材料が欠けたままになります。

監視は、簡単な確認でも構いません。毎日1回、数字が入っているかを見る形で足ります。

情報の扱いとの関係

この方式は、預かっている情報の扱いにも関わります。ここを整理します。

中継の場で加工できるため、外部に渡す前に個人を識別しうる情報を除けます。

従来の方式では、ブラウザから直接送るためこの制御ができません。

何を渡しているかを把握していない状態は、それ自体が問題になり得ます。

この方式にすると、渡す項目の一覧を自社で管理できます。説明も可能になります。

一方で、自社のサーバーに情報が通ることになります。管理の責任が増える面もあります。

どちらが自社に合うかは、扱う情報の種類と社内の体制で判断します。

導入を検討する際は、社内の担当部門に相談します。技術だけの判断にしません。

同意の扱いは別に設計する

誤解されやすい点として、この方式は同意の仕組みの代わりにはなりません。

訪問者の同意が必要な計測は、同意を得てから行います。方式とは無関係です。

サーバー側に置いたから同意が不要になる、ということはありません。

同意の状態を中継の場に伝え、同意がなければ転送しない設計にします。

この設計を組み込まないと、同意の管理が抜け落ちます。ここは設計の要点です。

同意の仕組みと計測の方式は、別に設計して組み合わせます。両方が必要です。

効果の測り方

導入の効果は、どこで測るのかを決めておきます。感覚では判断できません。

測るのは、記録した差の割合です。導入前と導入後で差が縮んだかを見ます。

経路ごとに比べます。全体だけを見ると、変化が打ち消されて見えなくなります。

差が縮まなければ、原因が別にあります。設定の誤りや定義の違いを再度確かめます。

表示の速さも測れます。導入前と導入後の読み込みの時間を比べます。

ただし、速さの改善はこの方式だけの効果とは言えません。他の要因も動きます。

主な判定は、差の割合で行います。ここが縮めば目的は達しています。

判定の時期は、切り替えから1か月後です。短いと季節の影響が混ざります。

差が縮まないときに見る箇所

差が縮まなかった場合の確認箇所も決めておきます。ここで打ち切らないためです。

最初に見るのは、中継の設定で項目が落ちていないかです。渡し漏れが起きます。

送り先ごとに必要な項目が違うため、1つの設定で全部を満たせないことがあります。

次に、同意の状態を伝える設計が働いているかを見ます。過剰に止めている場合があります。

さらに、自社の領域の設定が正しく効いているかを確かめます。ここが要点です。

設定が中途半端だと、従来と同じ経路で送られ、効果が出ません。

この3点を確かめれば、原因はほぼ絞れます。切り戻す前に見ておきます。

外部に依頼する場合の確認

社内に担当できる人がいない場合、外部に依頼することになります。確認の項目を挙げます。

• 設定の内容が文書として残されるか
• サーバーの管理を誰が持つか。自社の契約になるかどうか
• 止まったときの連絡と復旧の手順が決まっているか
• 使っている道具すべての対応を確かめてもらえるか
• 同意の状態を伝える設計が含まれているか
• 引き継ぎができる形になっているか

2つ目が最も重要です。サーバーの契約が誰の名義かで、後の自由度が変わります。

依頼先の契約になっていると、取引が終わったときに移せません。

自社の契約にして、設定を依頼する形が望ましくなります。

6つ目も確かめます。担当者が変わっても運用が続く形にしておきます。

費用の内訳も分けて確かめます。設定の作業の費用と、毎月のサーバーの費用は別です。

毎月の費用が誰の請求になるかを明確にします。ここが曖昧だと後で揉めます。

また、訪問の量が増えたときに費用がどう変わるかも聞きます。上限の目安が要ります。

見積もりの段階でこの2点を確かめておけば、運用が始まってから慌てません。

導入しない判断も正しい

最後に、導入しない判断についても触れます。これも正しい選択になり得ます。

規模が小さく、広告の費用も大きくないなら、費用と手間が見合いません。

その場合は、差があることを前提に数字を読む形で足ります。

大事なのは、差の大きさを把握していることです。把握していれば判断できます。

経路ごとの差の割合を記録しておけば、補正して読めます。

この補正は、簡単な計算で足ります。仕組みを入れるより早く着手できます。

差の記録は、この方式を導入する場合でも必要です。まずここから始めます。

• 導入しない場合も、経路ごとの差の割合は記録しておく。補正して読めば判断はできる
• 設定の誤りや定義の違いを先に切り分ける。原因が別なら差は縮まらない

記録があれば、必要になった時点で判断できます。記録が判断の前提になります。

実務での目安

最後に、判断の目安をまとめます。

• まず設定の誤りと定義の違いを切り分ける。ここで解決する場合がある
• 月間の訪問が数十万に達する規模から検討の対象になる
• 広告の費用が大きい場合は、規模が小さくても検討の価値がある
• 費用は月に数千円から数万円。訪問の量で変わる
• 並行して1か月動かし、経路ごとの差が縮んだかを確かめる
• 監視の仕組みを必ず用意する。止まると数字が丸ごと失われる

1つ目を飛ばさないことが最も重要です。原因が別なら効果は出ません。

切り分けには数日しかかかりません。ここを丁寧に行う価値があります。

そのうえで規模と広告の費用を見て、導入の判断をします。

判断は一度で決めなくても構いません。差の記録を続けながら様子を見る選択もあります。

差が広がる傾向にあるなら、導入の必要性は上がっていきます。

逆に、差が一定で判断に使える範囲に収まっているなら、急ぐ理由はありません。

記録を持っていることが、この判断を可能にします。まずここを整えます。

導入後の運用で見るもの

導入した後の運用についても、見る項目を決めておきます。

毎日見るのは、数字が入っているかどうかだけです。止まっていないかの確認です。

週に一度は、経路ごとの件数が前週と大きく違わないかを見ます。

大きく違う場合、サーバーの側か設定の側に問題が起きている可能性があります。

月に一度は、費用を確かめます。訪問の量が増えると費用も上がります。

四半期に一度は、渡している項目の一覧を見直します。不要な項目が残っていることがあります。

この4つの周期で見れば、運用の負担は小さく収まります。

負担が小さいことを確かめてから導入するほうが、続けやすくなります。

担当が変わっても続く形にする

運用で最も危ういのは、担当が変わる場面です。ここに備えます。

必要なのは、設定の内容が文書として残っていることです。頭の中だけでは引き継げません。

残す項目は、サーバーの契約の場所、設定の変更の手順、送り先ごとに渡している項目です。

加えて、止まったときの連絡先と復旧の手順も書きます。ここが最も急を要します。

この文書は、外部に依頼した場合も必ず受け取ります。納品物に含めてもらいます。

文書がないと、担当が変わった時点で誰も触れない仕組みになります。

触れない仕組みは、止まったときに戻せません。引き継ぎの文書が運用の土台です。

まとめ

計測の数字が合わない状況は、ブラウザ側の制限によって広がりました。対処として、計測の処理を自社のサーバーへ移す方式があります。得られるのは取りこぼしの軽減と、外部に渡す情報を手前で制御できることです。一方で、月に数千円から数万円の費用と、専門の知識、監視の体制が必要になります。ただし、その前に確かめるべきことがあります。設定の誤りや定義の違いです。原因が別なら、仕組みを変えても差は縮みません。まずは経路ごとの差の割合を1か月分記録するところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。