📟 📼 😋 Ruby on Rails用のサイト訪問者ソーシングモジュール 🧑 🥃 🌴

この投稿は主にWeb分析に関するものです。サイトへの訪問者のソースを正しく識別する方法、およびこの困難なタスクに役立つRuby on Railsのモジュールについてです。最後に、Railsコミュニティに注意を払うようにお願いする小さな部分があります。それは私とRailsに関するものです。しかし、順番に見てみましょう。

パート1 Web分析と訪問者のソースの決定について

問題

かなり些細な作業があります：私たちのサイトに来た訪問者のソースを特定することです。私はあなたのことは知りませんが、長い間、GoogleアナリティクスのCookieの本体に寄生していました。私たちの分析は、ソースの書き換え、セッションのアカウンティングの問題を解決し、一般に、解析リファラーのすべての費用を排除しました。しかし、良いことはすべて終わります。

GoogleがUniversalのベータ版をリリースしたとき、遅かれ早かれ、Google Cookieに別れを告げ、それを自分で行う方法を学ぶ必要があることが明らかになりました。しかし、それ以来、彼はClassicとUniversalの非互換性を宣言しました。これまでのところ、あなたは正確に座ることができました。Classicは長い間サポートされます。

GA Cookieの新しいバージョンでは、ユーザーIDが1つだけ残っています。分析はそれをサーバーに送信し、そこですべての計算を既に実行します。そして今では、Cookieやjsを介してソースからソースに関する情報を取得することはできません。

しかし最近、Googleはユーザーをスティックで優しく突くようになりました。プロファイルコンバーター-Classic→Universalを展開しました。そして、ここでロールのウィグリングを開始する必要があります。リマーケティングリストがUniversalに追加された時点で、クラシックアナリティクスは最終的なリーダーを受け取ります。そして、これはそれほど遠くないと思います。

この点で、私は自作のutmz cookieジェネレーターに生まれました。そしてそれをソースバスターと呼びました。

最初にフォームについて

ジェネレーターは、 Ruby on Rails用のマウント可能なエンジン形式で作成されています 。すべてのRailsアプリケーションにgemとして素早く調整し、コンソールからの単一コマンドで更新できます。モジュールは独立しており、それ自体ですべてを実行します。ソースに関するデータを使用して、電話番号、サイト上のコンテンツを置き換え、アプリケーションとともに保存し、さらなる分析に使用できます。特定のルールに従って、モジュールはソース（および多数のパラメーター）を計算し、訪問者のCookieに保存します。

GitHubへの直接リンク： https : //github.com/alexfedoseev/sourcebuster

私はまだREADME.rdocの設計を理解していません。その過程で、すぐに修正します。

コンテンツについて

ほとんどのロジックはGAロジックを繰り返しますが、いくつかの違いがあります。

データ構造から始めましょう。

データ構造

合計で、4つの主要な種類のトラフィックがあります。

utm -utmタグでマークされたトラフィック
オーガニック -オーガニック検索エンジンの結果からのトラフィック
紹介 -紹介トラフィック（サードパーティのリソースからのリンク）
typein-直接遷移

以下の画像のフィルタリングロジック：

したがって、訪問者をこれらの4つのバスケットに詰めます。

次に、1人の訪問者が異なるソースから異なる時間にサイトにアクセスできるため、ソースを書き換えるためのルールを作成する必要があります。

ソースを書き換えるロジック

書き換えロジックは、Googleアナリティクスのロジックに従います。

参照リンクは、現在のセッションで何も上書きしないことに注意してください。理由-例で説明しましょう。多くの場合、現在の訪問中に、訪問者は実際のソースではないサードパーティのリソースからサイトにアクセスします。たとえば、登録を有効にするリンクがあったメールサービスからです。

このシステムでは、現在の訪問に関するデータを上書きすることに加えて、最初の訪問に関するデータを保存することにしました。つまり、変換時に、訪問者の最初と現在のソースに関するデータが得られます。

モジュールを使用して正確に引き出すことができるもの：

最初のソースのデータ：

utm_source、utm_medium、utm_campaign、utm_content、utm_term
現在のソースに関する同じデータ

（ユーザーが別のソースから繰り返し移行した場合）
最初の訪問日
エントリーポイント
ソースが書き換えられた完全リファラー
IPおよびユーザーエージェントユーザー

モジュールのインストール

モジュールを固定したいRailsアプリケーションが既にあると仮定します。

Gemfileアプリケーションで、次を追加します。

gem 'sourcebuster', :git => "git@github.com:alexfedoseev/sourcebuster.git"

インストール：

 bundle install

これはマウント可能なエンジンであるため、分離された名前空間に存在します。

routes.rbを追加して、アプリケーションにマウントします。

 mount Sourcebuster::Engine => "/sourcebuster"

次に、すべての移行をコピーして実行する必要があります。

コピー：

 bundle exec rake sourcebuster:install:migrations

そして実行：

 bundle exec rake db:migrate

データベースには3つの新しいテーブルがあります。

sourcebuster_referer_sources

カスタムソースデータ。
sourcebuster_referer_types

紹介の種類に関するデータ（紹介トラフィックの場合は基本的にutm_medium）。
sourcebuster_settings

アプリケーション設定（セッション期間とサブドメイン処理）。

それらを使用して何もする必要はありません。既にデータがすぐに使用でき、それらのインターフェイスがあります。

マウント可能なエンジンの詳細-http://guides.rubyonrails.org

モジュールはほとんど接続されていますが、最後のタッチは残ります。アプリケーションのどこにでもCookieを設定できます。これを行うには、 アプリケーションのapplication_controller.rbに追加します。

 class ApplicationController < ActionController::Base include Sourcebuster::CookieSettersHelper before_filter :set_sourcebuster_data helper_method :extract_sourcebuster_data # some code private def set_sourcebuster_data set_sourcebuster_cookies end end

準備完了のようです。エンジンはメインアプリケーションテンプレートを使用するため、スタイルを自分でカスタマイズできます（これを変更する可能性があります）。何かがうまくいかない場合、私は何かを見逃す可能性があります-書き込み。

使用する

モジュールを使用する場合、 これはベータ版であり、かなりの開発経験のある人によって書かれたものであることを考慮してください（投稿の最後にいくつかの段落があります）。

このモジュールは以下のメソッドを提供します（より正確には、メソッドは1つだけですが、異なるデータを引き出します）：

モジュールメソッド

 # C    (utm / organic / referral / typein) extract_sourcebuster_data(:sb_first, :typ) # C  utm_source extract_sourcebuster_data(:sb_first, :src) # C  utm_medium extract_sourcebuster_data(:sb_first, :mdm) # C  utm_campaign extract_sourcebuster_data(:sb_first, :cmp) # C  utm_content extract_sourcebuster_data(:sb_first, :cnt) # C  utm_term extract_sourcebuster_data(:sb_first, :trm) #    (utm / organic / referral / typein) extract_sourcebuster_data(:sb_current, :typ) #  utm_source extract_sourcebuster_data(:sb_current, :src) #  utm_medium extract_sourcebuster_data(:sb_current, :mdm) #  utm_campaign extract_sourcebuster_data(:sb_current, :cmp) #  utm_content extract_sourcebuster_data(:sb_current, :cnt) #  utm_term extract_sourcebuster_data(:sb_current, :trm) #     extract_sourcebuster_data(:sb_first_add, :fd) #   extract_sourcebuster_data(:sb_first_add, :ep) #  ,      extract_sourcebuster_data(:sb_referer, :ref) # ip  extract_sourcebuster_data(:sb_udata, :uip) #   user agent extract_sourcebuster_data(:sb_udata, :uag)

モジュールテストページ： http : //sandbox.alexfedoseev.com/sourcebuster/showoff

さまざまなソースからアクセスして、モジュールが決定した内容を確認できます。

このモジュールでは、いくつかの追加パラメーターを構成することもできます。

デフォルト設定

インターフェース： http : //sandbox.alexfedoseev.com/sourcebuster/settings

セッション期間

ユーザーの最後のアクティビティから、訪問が完了したとみなされるまでの時間。デフォルトでは30分で、分単位で示されます。

サブドメイン処理

これは基本的にGAの_setDomainNameに類似しています。例で説明します。

サブドメインがあるサイトがあるとしましょう：

site.com
blog.site.com
shop.site.com

また、 site.comページからblog.site.comへの遷移を内部的な非参照遷移と見なします（つまり、1つのサブドメインから別のサブドメインに切り替えても、ソースは上書きされません）。これを行うには、設定で「サブドメインがあり、それらの間のトラフィックはリフェラルであってはならない」をチェックする必要があり、 「メインホスト」フィールドでサイトのルートホストを追加します。そのサブドメインはすべて、モジュールによって1つのサイトと見なされます。ここでは、 「site.com」が示されています。

フィールドにblog.site.comを指定すると、 alex.blog.site.comからblog.site.comへの移行は非参照になり、 alex.blog.site.comからshop.site.comへの移行は既に参照になりますトラフィック。

追加のソース

インターフェース： http : //sandbox.alexfedoseev.com/sourcebuster/custom_sources

システムには、多数の追加ソースの処理をカスタマイズする機能があります。

設定は、次のパラメーターに従って行われます。

ドメイン

処理しているソースはそれに一致します。
エイリアス

美しい/わかりやすいソース名。
チャンネル

referral 、 organic、またはsocialを指定できます。
リクエストパラメータ

検索エンジンのURLのキーワードパラメーター。

この表の例は、例で説明する最も簡単な方法が必要です。

例1

システムでBing検索からオーガニックトラフィックへの移行を検討する必要があります（これは事実です）。

bing.comにアクセスし、検索ボックスに「apple」というクエリを入力すると、次の形式のアドレスを含む検索ページにリダイレクトされます。

www.bing.com/search ？ q = apple ＆go =＆qs = n＆form = QBLH＆pq = apple＆sc = 8-5＆sp = -1＆sk =＆cvid = 718ad07527244c319ecebf44aa261f64

それに基づいて、新しい特別なソースを作成します。

ドメイン： bing.com
エイリアス： bing

または、必要に応じて、何も記述しなくても、リファラーホストが置き換えられます。
チャンネル： オーガニック
キーワードパラメータ： q

これは、検索結果を含むページのURLにある「？」と「= your_query」の構造の間の記号です。

これで、そのようなページに由来するすべてのものがオーガニックトラフィックと見なされます。

例2

ソーシャルからの移行を強調する必要があります。別のグループのネットワーク。

同様のパターンに従います。

ドメイン： facebook.com
エイリアス： facebook
チャンネル： ソーシャル
キーワードパラメータ：不要

できたこれで、facebookからのすべてのクリックリンク（utmタグでマークされたものを除く）は、ソーシャルチャネルの価値を持つようになります。

ドメインフィールドでは、ゾーン（.com、.com.ruなど）を完全に指定する必要があります。値facebook.comを指定すると、ドメインfacebook.com.ruからのトラフィックはこのフィルターに該当しません。そして、ドメインm.facebook.comから-取得します。

テスト

ソース： https : //github.com/alexfedoseev/sourcebuster/blob/master/test/integration/navigation_test.rb

テストの大部分は、ソースが正しく識別および書き換えられていることを確認するためのセレンテストです。これらはRubyで作成されましたが、モジュールのコードだけでなく、原則としてすべての実装（たとえば、誰かがphpまたはjsに移植した場合）をチェックできるように実装されています。つまり、メソッドをテストするのではなく、作業の結果をテストします。また、ここでは代理リファラーは使用されませんが、実際のリソースからの実際の遷移がテストされます。また、Yandexが発行中に何かを変更した場合（たとえば、httpsに切り替えるとリファラーが強制終了されます）、テストでそれが表示されます。すべてが本当に短いです。

これで、テストは非常に重要であり、テスト自体が記述されていますが、必要に応じて理解できます。

書き換えられたコードをテストするには、次のものが必要です。

特定のルールに従って構成されたページ

（テストページのコードを参照し、データブロックのIDを見つけます。もしあれば、質問します）
検索エンジンでインデックス化

（Yandex、Google、3番目の追加（たとえば、ランブラー））
特定のリクエストのトップ5
+ソーシャルからこのページへのリンク。ネットワークおよびサードパーティ（参照）サイト

上部のコードブロックには、テストを実行する前に構成する必要がある定数が含まれています。それらから、何を正確に準備する必要があるかが明確です。

はい、テストの実行には約20〜30分かかります。

私は繰り返します：モジュールの操作中、 これはベータ版であり、かなりの開発経験を持つ人 （これについては以下のいくつかの段落） によって書かれたことを考慮してください。

パート2 私とRailsについて

私は3.5年インターネットマーケティングに携わってきましたが、それほど昔ではありませんが、トラフィックの生成は私のものではないという結論に達しました。トラフィックではなく意味を生成したい。そして、コードを書き始めました。それは約9ヶ月前に起こりました。私はIT数学の背景を持っていません。最初から自分自身ですべてを掘り下げなければなりませんでした。クリス・パイン、マイケル・ハートル、その他のインターネットの本は私を助けてくれました。

その結果、私は自分でブログを書きましたが、約5か月前に休憩を余儀なくされ、このモジュールはダウンタイム後に最初に書いたものです。 Railsコミュニティのメンバーに、実装を批判し、明確でそれほど悪くない学校を指摘するようお願いします。この間ずっと、Rubyで書いている生きている人に会うことはできませんでした。すべてを理解することは非常に困難です。

批判を事前に感謝し、この投稿が誰かに役立つことを願っています。がんばって。

Ruby on Rails用のサイト訪問者ソーシングモジュール