SaraDev
(Sara Devlaeminck)
2023 年 12 月 18 日午後 10:55
1
これは、Anonymous のダッシュボードレポートの SQL バージョンです。
このレポートは、指定された期間にわたって、匿名ユーザー(アカウントにログインしていないユーザー)がサイトで 1 日あたりに受け取ったページビュー数を示します。
--[params]
-- date :start_date = 2023-12-01
-- date :end_date = 2024-01-01
SELECT
date,
SUM(count) AS pageviews
FROM
application_requests
WHERE
req_type = 8
AND date BETWEEN :start_date AND :end_date
GROUP BY
date
ORDER BY
date
SQL クエリの説明
パラメータ定義 : クエリは、:start_date と :end_date という 2 つのパラメータを定義することから始まります。これらは、データを目的の期間にフィルタリングするために使用されます。両方の日付パラメータは、YYYY-MM-DD の日付形式を受け入れます。
データ選択 : date と count の合計(pageviews としてエイリアス付けされる)の 2 つの列を選択します。count は、各レコードのページビュー数を示します。
データソース : データは、アプリケーションへのさまざまな種類の要求を記録する application_requests テーブルから取得されます。
フィルタリング : WHERE 句は、page_view_anon (req_type = 8) のタイプのレコードのみを含み、指定された日付範囲内にあるレコードをフィルタリングします。
集計 : GROUP BY 句は、結果を date 列でグループ化します。これにより、SUM 関数を使用して各日付の合計ページビューを計算できます。
並べ替え : 最後に、結果は date で昇順に並べ替えられ、匿名ページビューの時系列ビューが提供されます。
結果例
date
pageviews
2023-12-01
12345
2023-12-02
11346
2023-12-03
18344
2023-12-04
15344
2023-12-05
12890
…
…
req_type に関する注記
application_requests テーブルの req_type 列は、要求の種類を分類します。このクエリでは、req_type = 8 に関心があります。これは匿名ページビューに対応します。
他の req_type 値は、クローラーのページビュー、ログイン済みページビュー、さまざまな HTTP レスポンス ステータスなど、さまざまな種類の要求を表します。
すべての req_type 値:
0. http_total
1. http_2xx
2. http_background
3. http_3xx
4. http_4xx
5. http_5xx
6. page_view_crawler
7. page_view_logged_in
8. page_view_anon
9. page_view_logged_in_mobile
10. page_view_anon_mobile
11. api
12. user_api
「いいね!」 3
これもモバイル番号を含めるために req_type IN (8,10) にすべきでしょうか?
「いいね!」 1
SaraDev
(Sara Devlaeminck)
2023 年 12 月 18 日午後 11:46
3
私も当初はそれを検討していましたが、管理ダッシュボードのレポートには page_view_anon のみが含まれており、page_view_anon_mobile は含まれていません。
現在のクエリの方法では、ダッシュボードレポートを完全に反映しており、クエリを実行してダッシュボードレポートの結果と比較することで確認できます。
これは、別の関連する質問を提起しますが、ダッシュボードレポートには匿名モバイルページビューを含めるべきでしょうか?
直感的にはそうだと思いますが、これについて他の意見を聞くのは興味深いです。
「いいね!」 1
ああ、すみません。コメントでより具体的に説明すべきでした。これが完全に同じものであることは認識していましたが、ダッシュボードレポート自体にそれが含まれるべきだという意味でした。
「いいね!」 1
Jagster
(Jakke Lehtonen)
2023 年 12 月 19 日午前 7:30
6
申し訳ありませんが、こちらは朝で、もっとコーヒーが必要なので、言語の壁にぶつかってしまいました。
今、モバイルも合計に含めるべきだと考えていますか?それとも、実際の合計ビューとモバイルビューの2つの指標を表示すべきですか?
現在、ダッシュボードレポートには req_type (8) のみが含まれているようで、デスクトップの匿名ビューのみをカウントしています。
モバイルデータもカウントされない理由(合計として、または詳細を確認できるように2つの数値として)を知りたいと思っています。
Jagster
(Jakke Lehtonen)
2023 年 12 月 19 日午前 8:57
8
それは真実ではないか、それともボットもカウントしているということですね。そうすると、1日あたり約1000件となり、それは妥当な数字に聞こえます。しかし、私のデスクトップは非常に少ないです。そして、デスクトップが1000件でモバイルが9000件(はい、その比率です)という状況は、真実ではありえません。
うーん、よくわかりません。コードはここにあると思います。
# Update the documentation for the `add_request_rate_limiter` plugin API if this list changes.
default_rate_limiters = [
RequestTracker::RateLimiters::User,
RequestTracker::RateLimiters::IP,
]
stack = RequestTracker::RateLimiters::Stack.new
default_rate_limiters.each { |limiter| stack.append(limiter) }
stack
end
end
def self.rate_limiters_stack
@@stack ||= reset_rate_limiters_stack
end
def initialize(app, settings = {})
@app = app
page_view_anon_mobile が page_view_anon のサブセットである可能性があります。これを読める人がチップインしてアドバイスしてくれることを願っています。
「いいね!」 3
jericson
(Jon Ericson)
2023 年 12 月 21 日午前 12:18
10
ふむ。確かにそのロジックだと、ページビューがモバイルデバイスからのものとして分類されているかどうかに関わらず、page_view_anon がインクリメントされることになりますね。クエリをいくつか更新する必要があると思います。。。
「いいね!」 1