Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

【ITニュース解説】First-touch attribution on a cookieless static Nuxt site

2026年09月21日に「Dev.to」が公開したITニュース「First-touch attribution on a cookieless static Nuxt site」について初心者にもわかりやすく解説しています。

作成日: 更新日:

ITニュース概要

クッキーを使わず、訪問者が初めてサイトに来た経路を把握する技術を紹介。LocalStorageに参照元やUTMパラメータを保存し、問い合わせ時にその情報を紐付ける。これにより、プライバシーに配慮しつつ、各リードがどこから来たか正確に特定し、マーケティングに活用できる。

ITニュース解説

このニュース記事は、プライバシー保護を重視したウェブサイト運営において、訪問者がどこから来たのか(リードの獲得経路)を知るための具体的な解決策を紹介している。特に、システムエンジニアを目指す初心者にとって、ウェブサイトの動作原理やデータの扱いの基礎を理解する上で非常に参考になる内容だ。

まず、背景にある課題を理解しよう。近年、ウェブサイトではユーザーのプライバシー保護がますます重視されている。その流れで、ウェブサイトの閲覧履歴を追跡するために広く使われてきた「クッキー」という仕組みを使わない「クッキーレス」なアクセス解析が注目されている。クッキーを使わないことで、ユーザーはサイトを訪れた際に「クッキー利用に同意しますか?」といったバナーを見る必要がなくなり、サーバー側にも個々の訪問者に関する情報が保存されないため、プライバシー保護の面では非常に優れている。

しかし、このクッキーレスの取り組みには課題がある。特にフリーランスや中小企業のように、ウェブサイトから問い合わせ(リード)を獲得することがビジネスに直結する場合、「この問い合わせはどこから来たのか?」「Google検索からか、それとも他のサイトからの紹介か、特定の広告キャンペーンからか?」といった具体的な情報が得られなくなってしまうのだ。クッキーレスなアクセス解析ツール(例えばPostHogのインメモリモードやUmamiなど)は、サイト全体の参照元を集計して教えてくれるが、特定の「この」問い合わせがどの経路から来たのかを個別に紐付けるのは難しい。これが、このニュース記事で解決しようとしている問題の核心である。

ここで提案されているのが、「ファーストタッチアトリビューションレイヤー」というシンプルな仕組みだ。「ファーストタッチアトリビューション」とは、訪問者がウェブサイトに「最初に接触した」経路を特定し、その情報を記録することだ。例えば、あるユーザーが先週Google検索を通じてサイトに訪れ、今週はサイトのURLを直接入力して再訪したとする。この場合、ファーストタッチアトリビューションでは「Google検索」がそのユーザーの最初の接触経路として記録される。これにより、ユーザーが最終的にサイトで何らかのアクション(例えば問い合わせフォームの送信)を行った際に、その行動がどの最初の接触経路に起因するのかを正確に把握できる。

この解決策の重要な点は、クッキーや外部ライブラリを一切使わず、約40行程度のJavaScriptコードで実現していることだ。具体的には、ウェブブラウザに標準で備わっている「localStorage(ローカルストレージ)」という機能を使って、初回アクセス情報を保存している。

では、具体的な実装の流れを見ていこう。

最初のステップは、訪問者がサイトに初めてアクセスした際に、その初回アクセス情報を取得してlocalStorageに保存することだ。この処理はuseLeadSourceというcomposable(Nuxt.jsで再利用可能なロジックをまとめるための機能)として定義されている。

captureLeadSourceOnce()という関数がその役割を担う。 この関数は、まずlocalStorageにすでに初回アクセス情報が保存されているかをチェックする。もし保存されていれば、それがファーストタッチの情報なので、それ以上何もしないで処理を終了する。これにより、一度記録された情報が後のアクセスで上書きされることを防ぎ、「ファーストタッチ」を確実に保持できる。

次に、保存すべき情報を取得する。 一つ目はdocument.referrerだ。これは、ユーザーが現在のページにたどり着く直前に閲覧していたページのURLを示す。もしGoogle検索から来たならGoogleのURLが、別のウェブサイトからのリンクならそのサイトのURLが記録される。ここで重要なのは、isExternalというチェックだ。これは、document.referrerが自分のサイトのURLでないことを確認する。なぜなら、サイト内を移動した際にもdocument.referrerは自分のサイトのURLになるため、それでは外部からの参照元とは言えないからだ。外部からの参照元でなければnull(直接アクセス)として扱う。 二つ目はwindow.location.pathnameだ。これは、ユーザーが最初にアクセスしたページのパス(URLのドメインより後の部分)を示す。 三つ目はUTMパラメータだ。UTMパラメータとは、URLの末尾に付加されるutm_source、utm_medium、utm_campaignなどの情報で、広告キャンペーンの効果測定によく使われる。例えば、https://example.com/?utm_source=google&utm_medium=cpc&utm_campaign=summer-saleのようなURLでアクセスした場合、Googleからの有料広告でサマーセールキャンペーン経由で来たことがわかる。これらのパラメータはURLSearchParamsを使ってURLから簡単に抽出できる。 これらの取得した情報をJSON形式に変換し、localStorage.setItem(KEY, JSON.stringify(...))でlocalStorageに保存する。KEYはlead_sourceという名前で、このキーを使って情報を保存・取得する。

もう一つ、非常に重要な実装上の注意点として、「try/catchによるエラーハンドリング」が挙げられる。localStorageは、ブラウザのプライベートモードで開かれている場合や、ストレージの利用がブロックされている場合に、データの書き込みや読み込みに失敗してエラーを発生させることがある。このようなエラーによってウェブページ全体がクラッシュしてしまわないよう、try/catchブロックを使って、エラーが発生してもページの動作には影響が出ないようにしている。これは堅牢なシステムを作る上で非常に重要な考え方だ。

次に、このcaptureLeadSourceOnce()関数をウェブサイト上でいつ、どのように実行するかだ。 このサイトはNuxt.jsというフレームワークで作られており、SSG(Static Site Generation:静的サイト生成)という方法でウェブページを生成している。SSGは、サーバー側で事前にHTMLファイルを生成してからユーザーに配信するため、ブラウザで実行されるJavaScriptのコードとは動作環境が異なる。localStorageやdocument.referrerはブラウザに固有の機能なので、SSGの段階では存在しない。 そのため、app/plugins/lead-source.client.tsというファイルとして「クライアントサイドプラグイン」を定義している。Nuxtの.client.tsという拡張子のプラグインは、ブラウザ側でのみ実行されるため、localStorageやdocument.referrerが確実に利用可能な環境でcaptureLeadSourceOnce()関数が呼び出される。このプラグインはサイトが読み込まれると一度だけ実行され、前述のcaptureLeadSourceOnce()のロジックによって、初回アクセス情報が適切にlocalStorageに保存される。SPA(Single Page Application:シングルページアプリケーション)方式のサイト内遷移やページのリロードが発生しても、captureLeadSourceOnce()が冪等性(何度実行しても同じ結果になる性質)を持つため、ファーストタッチ情報が誤って上書きされる心配はない。

最後に、この情報を実際に活用するステップだ。 ウェブサイトの問い合わせフォームでは、ユーザーが名前、メールアドレス、メッセージなどを入力して送信する。この送信処理の際に、先ほどlocalStorageに保存しておいた初回アクセス情報を取得し、フォームの送信データ(payload)に含めてサーバーに送る。具体的には、getLeadSource()関数を呼び出してlocalStorageから情報を読み出し、source: getLeadSource()のようにpayloadに追加する。 サーバー側では、このsource情報を受け取ると、それを人間が読みやすい形式の文字列に変換するformatAcquisitionSource()という関数を使って整形する。例えば、UTMパラメータがあれば「Google / cpc (Summer Campaign)」のように、参照元URLがあれば「google.com」のように表示される。もし情報がなければ「Direct / unknown」と表示される。この整形された文字列を、問い合わせがあったことを知らせる通知メールの本文に含めることで、サイト運営者は「どのリードが、どこから来たのか」を個別に、そして即座に把握できるようになる。

なぜ既存の分析ツールでは不十分で、このような自作ソリューションが必要だったのか、という点も重要だ。 Google AnalyticsやPostHogのようなクッキーレス分析ツールも、参照元やUTMパラメータなどの情報は収集しており、サイト全体の集計データを見る分には非常に有用だ。しかし、これらは主に「集計(Aggregate)」のためのデータであり、個々の問い合わせ(「この」問い合わせ)がどの経路から来たのかを分析ツールのUIで紐付けて確認するのは手間がかかる。この自作ソリューションでは、問い合わせメールに直接その情報が記載されるため、確認の手間が大幅に削減される。 また、多くのクッキーレスツールやインメモリモードのツールでは、一度サイトを離れて再訪したユーザーの「初回アクセス元」を追跡し続けるのが難しい場合がある。localStorageを使うことで、特定のユーザーの「ファーストタッチ」をブラウザ内に比較的安価に、そして永続的に保持し、再訪時に問い合わせがあった際にも最初の流入経路を正しく把握できるというメリットがある。

まとめると、このニュース記事で紹介されている方法は、プライバシーを重視しつつもビジネスに必要な情報を得るための、非常に実用的で賢い解決策だ。クッキーや複雑な外部ライブラリに頼らず、ウェブ標準のlocalStorageと少しのJavaScriptコードで、ファーストタッチアトリビューションという高度なマーケティング分析の課題を解決している。システムエンジニアを目指す者にとって、既存の技術を組み合わせて新しい価値を生み出す良い例であり、堅牢性(エラーハンドリング)やフレームワーク(Nuxt.jsのプラグインシステム)の活用方法を学ぶ上で貴重なインサイトを与えてくれるだろう。このようなアプローチは、限られたリソースで最大限の効果を出すための、実践的なエンジニアリングの知恵と言える。

関連コンテンツ

関連IT用語