Referenzhandbuch für Berichte im Admin-Dashboard

[Discourse]

Dies ist ein Referenzhandbuch, das beschreibt, wie die Berichte im Admin-Dashboard funktionieren, welche Daten sie anzeigen, die entsprechenden SQL-Abfragen für den Data Explorer und wo der Ruby-Code für jeden Bericht zu finden ist.

Erforderliche Benutzerebene: Staff

Discourse enthält mehrere eingebaute Berichte im Admin-Dashboard, die nützlich sein können, um Statistiken zu einer Community zu untersuchen. Um auf diese Berichte zuzugreifen, können Sie discourse.example.com/admin/dashboard/reports auf Ihrer Seite aufrufen (oder auf den Link Berichte in der Seitenleiste klicken). Beachten Sie, dass nur Staff-Benutzer Zugriff auf diese Berichte haben.

Die Daten aller Benutzer auf einer Seite sind in diesen Berichten enthalten (einschließlich Staff-Aktivitäten wie dem Besuch von Admin-Seiten). Die einzige Bedingung, die in den Berichten für Benutzer gilt, ist, dass sie „echte“ Benutzer sind, was dazu dient, den system-Benutzer aus den Berichten auszuschließen.

Plugins können auch Berichte mit add_report(name, &block) zum Dashboard hinzufügen.

Die Ruby-Modelle für die meisten Berichte befinden sich unter: discourse/app/models/concerns/reports/. Einige Berichte verweisen auch auf: discourse/app/models/report.rb

Die #dashboard-sql-Themen enthalten alle entsprechenden SQL-Abfragen, die verwendet werden können, um Berichte zu erstellen, die identisch mit den Admin-Dashboard-Berichten sind. Diese Abfragen können innerhalb des Data Explorer-Plugins und für Ausführen von Data-Explorer-Abfragen mit der Discourse API verwendet werden.

Um bestimmte Berichte aus dem Dashboard auszublenden, verwenden Sie die Seiten-Einstellung dashboard_hidden_reports.

Akzeptierte Lösungen

Zeigt die tägliche Anzahl der als Lösung markierten Beiträge an.

Ruby-Code: discourse-solved/plugin.rb at main · discourse/discourse-solved · GitHub

SQL-Abfrage: Dashboard Report - Accepted Solutions

Admin-Logins

Liste der Admin-Login-Zeiten mit Standorten.

Ruby-Code: discourse/app/models/concerns/reports/staff_logins.rb

SQL-Abfrage: Dashboard Report - Admin Logins

Anonym

Anzahl der neuen Seitenaufrufe durch Besucher, die nicht bei einem Konto angemeldet sind.

Ruby-Code: discourse/app/models/concerns/reports/consolidated_page_views.rb

SQL-Abfrage: Dashboard Report - Anonymous

Lesezeichen

Anzahl der neuen Themen und Beiträge, die als Lesezeichen gespeichert wurden.

Ruby-Code: discourse/app/models/concerns/reports/bookmarks.rb

SQL-Abfrage: Dashboard Report - Bookmarks

Konsolidierte API-Anfragen

API-Nutzungsstatistiken nach Datum, die sowohl reguläre API-Anfragen als auch Benutzer-API-Anfragen verfolgen.

Ruby-Code: discourse/app/models/concerns/reports/consolidated_api_requests.rb at main · discourse/discourse · GitHub

SQL-Abfrage: Dashboard Report - Consolidated API Requests

Konsolidierte Seitenaufrufe

Seitenaufrufe für angemeldete Benutzer, anonyme Benutzer und Crawler. Dies ist ein veralteter Bericht, der durch den Bericht Site Traffic ersetzt wurde.

Ruby-Code: discourse/app/models/concerns/reports/consolidated_page_views.rb

SQL-Abfrage: Dashboard Report - Consolidated Pageviews

Konsolidierte Seitenaufrufe mit Browser-Erkennung (Veraltet)

Seitenaufrufe für angemeldete Benutzer, anonyme Benutzer, bekannte Crawler und andere. Dieser Bericht ist veraltet und delegiert nun an den Bericht Site Traffic.

Ruby-Code: discourse/app/models/concerns/reports/consolidated_page_views_browser_detection.rb

SQL-Abfrage: Dashboard Report - Consolidated Pageviews with Browser Detection

DAU/MAU

Anzahl der Mitglieder, die sich im letzten Tag angemeldet haben, geteilt durch die Anzahl der Mitglieder, die sich im letzten Monat angemeldet haben – ergibt einen Prozentsatz, der die „Bindungskraft“ der Community anzeigt. Streben Sie >20% an.

Ruby-Code: discourse/app/models/concerns/reports/dau_by_mau.rb

SQL-Abfrage: Dashboard Report - DAU/MAU

Tägliche aktive Benutzer

Anzahl der Benutzer, die im letzten Tag „Gefällt mir“-Klicks gesetzt oder Beiträge erstellt haben.

Ruby-Code: discourse/app/models/concerns/reports/daily_engaged_users.rb

SQL-Abfrage: Dashboard Report - Daily Engaged Users

Gesendete E-Mails

Anzahl der neu gesendeten E-Mails.

Ruby-Code: discourse/app/models/concerns/reports/emails.rb

SQL-Abfrage: Dashboard Report - Emails Sent

Flags

Anzahl der neuen Flags.

Ruby-Code: discourse/app/models/concerns/reports/flags.rb

SQL-Abfrage: Dashboard Report - Flags

Flag-Status

Liste der Flag-Status, einschließlich Flag-Typ, Poster, Flaggeber und Zeit bis zur Lösung.

Ruby-Code: discourse/app/models/concerns/reports/flags_status.rb

SQL-Abfrage: Dashboard Report - Flags Status

Likes

Anzahl der neuen Likes.

Ruby-Code: discourse/app/models/concerns/reports/likes.rb

SQL-Abfrage: Dashboard Report - Likes

Angemeldet

Anzahl der neuen Seitenaufrufe von angemeldeten Benutzern.

Ruby-Code: discourse/app/controllers/admin/reports_controller.rb#L5

SQL-Abfrage: Dashboard Report - Logged In

Moderator-Aktivität

Liste der Moderator-Aktivität, einschließlich geprüfter Flags, Lesezeit, erstellter Themen, erstellter Beiträge, erstellter persönlicher Nachrichten und Revisionen.

SQL-Abfrage: Dashboard Report - Moderator Activity

Moderator-Warnung

Anzahl der Warnungen, die von Moderatoren per persönlicher Nachricht gesendet wurden.

Ruby-Code: discourse/app/models/concerns/reports/moderator_warning_private_messages.rb

SQL-Abfrage: Dashboard Report - Moderator Warnings

Neue Mitwirkende

Anzahl der Benutzer, die während dieses Zeitraums ihren ersten Beitrag erstellt haben.

Ruby-Code: discourse/app/models/concerns/reports/new_contributors.rb

SQL-Abfrage: Dashboard Report - New Contributors

Moderatoren benachrichtigen

Anzahl der Male, in denen Moderatoren durch ein Flag privat benachrichtigt wurden.

Ruby-Code: discourse/app/models/concerns/reports/notify_moderators_private_messages.rb

SQL-Abfrage: Dashboard Report - Notify Moderators

Benutzer benachrichtigen

Anzahl der Male, in denen Benutzer durch ein Flag privat benachrichtigt wurden.

Ruby-Code: discourse/app/models/concerns/reports/notify_user_private_messages.rb

SQL-Abfrage: Dashboard Report - Notify User

Gesamtstimmung

Anzahl der Beiträge, die mit der KI „Sentiment“ entweder als positiv oder negativ eingestuft wurden, über einen bestimmten Zeitraum.

Ruby-Code: https://github.com/discourse/discourse-ai/blob/main/lib/sentiment/entry_point.rb

SQL-Abfrage: Dashboard Report - Overall Sentiment

Seitenaufrufe

Anzahl der neuen Seitenaufrufe von allen Besuchern. Gleicht der Gesamtzahl für konsolidierte Seitenaufrufe.

Discourse verwendet die folgende Abfrage, um die Gesamtzahl der Seitenaufrufe zu bestimmen:

SQL-Abfrage: Dashboard Report - Consolidated Pageviews

Beitragsbearbeitungen

Anzahl der neuen Beitragsbearbeitungen.

Ruby-Code: discourse/app/models/concerns/reports/post_edits.rb

SQL-Abfrage: Dashboard Report - Post Edits

Beiträge

Neue Beiträge, die während des gewählten Zeitraums erstellt wurden

Ruby-Code: discourse/app/models/concerns/reports/posts.rb

SQL-Abfrage: Dashboard Report - Posts

Beitragsemootion

Anzahl der Beiträge, die von der KI mit einer der folgenden Emotionen klassifiziert wurden: Traurigkeit, Überraschung, Angst, Wut, Freude, Ekel – gruppiert nach Poster-Trust-Level, über einen bestimmten Zeitraum.

Ruby-Code: https://github.com/discourse/discourse-ai/blob/main/lib/sentiment/entry_point.rb

SQL-Abfrage: Dashboard Report - Post Emotion

Reaktionen

Liste der neuesten Reaktionen.

Ruby-Code: discourse-reactions/plugin.rb at main · discourse/discourse-reactions · GitHub

SQL-Abfrage: Dashboard Report - Reactions

Registrierungen

Neue Kontoregistrierungen für diesen Zeitraum.

Ruby-Code: discourse/app/models/concerns/reports/signups.rb

SQL-Abfrage: Dashboard Report - Signups

Site Traffic

Seitenaufrufe für angemeldete Browser, anonyme Browser, Crawler und anderen Traffic. Dies ist der primäre Traffic-Bericht, der die veralteten konsolidierten Seitenaufruf-Berichte ersetzt.

Ruby-Code: discourse/app/models/concerns/reports/site_traffic.rb

SQL-Abfrage: Dashboard Report - Site Traffic

Verdächtige Logins

Details zu neuen Logins, die sich verdächtig von vorherigen Logins unterscheiden.

Ruby-Code: discourse/app/models/concerns/reports/suspicious_logins.rb

SQL-Abfrage: Dashboard Report - Suspicious Logins

System

Anzahl der persönlichen Nachrichten, die automatisch vom System gesendet wurden.

Ruby-Code: discourse/app/models/concerns/reports/system_private_messages.rb

SQL-Abfrage: Dashboard Report - System

Zeit bis zur ersten Antwort

Durchschnittliche Zeit (in Stunden) der ersten Antwort auf neue Themen.

Ruby-Code: discourse/app/models/concerns/reports/time_to_first_response.rb + discourse/discourse/blob/main/app/models/topic.rb#L1799-L1844

SQL-Abfrage: Dashboard Report - Time to First Response

Top ignorierte / stummgeschaltete Benutzer

Benutzer, die von vielen anderen Benutzern stummgeschaltet und/oder ignoriert wurden.

Ruby-Code: discourse/app/models/concerns/reports/top_ignored_users.rb

SQL-Abfrage: Dashboard Report - Top Ignored / Muted Users

Top verweisende Themen

Themen, die die meisten Klicks von externen Quellen erhalten haben.

Ruby-Code: discourse/app/models/concerns/reports/top_referred_topics.rb

SQL-Abfrage: Dashboard Report - Top Referred Topics

Top Verweiser

Benutzer, aufgelistet nach der Anzahl der Klicks auf Links, die sie geteilt haben.

Ruby-Code: discourse/app/models/concerns/reports/top_referrers.rb

SQL-Abfrage: Dashboard Report - Top Referrers

Top Traffic-Quellen

Externe Quellen, die am häufigsten auf diese Seite verlinkt haben.

Ruby-Code: discourse/app/models/concerns/reports/top_traffic_sources.rb

SQL-Abfrage: Dashboard Report - Top Traffic Sources

Top Uploads

Liste aller Uploads nach Dateiendung, Dateigröße und Autor.

Ruby-Code: discourse/app/models/concerns/reports/top_uploads.rb

SQL-Abfrage: Dashboard Report - Top Uploads

Top Benutzer nach erhaltenen Likes

Top 10 Benutzer, die Likes erhalten haben.

Ruby-Code: discourse/app/models/concerns/reports/top_users_by_likes_received.rb

SQL-Abfrage: Dashboard Report - Top Users by Likes Received

Top Benutzer nach erhaltenen Likes von Benutzern mit einem niedrigeren Trust Level

Top 10 Benutzer mit einem höheren Trust Level, die von Personen mit einem niedrigeren Trust Level geliked wurden.

Ruby-Code: discourse/app/models/concerns/reports/top_users_by_likes_received_from_inferior_trust_level.rb

SQL-Abfrage: Dashboard Report - Top Users by Likes Received from a User with a Lower Trust Level

Top Benutzer nach erhaltenen Likes von einer Vielzahl von Personen

Top 10 Benutzer, die Likes von einer breiten Palette von Personen erhalten haben.

Ruby-Code: discourse/app/models/concerns/reports/top_users_by_likes_received_from_a_variety_of_people.rb

SQL-Abfrage: Dashboard Report - Top Users by Likes Received From a Variety of People

Themen

Neue Themen, die während dieses Zeitraums erstellt wurden.

Ruby-Code: discourse/app/models/concerns/reports/topics.rb

SQL-Abfrage: Dashboard Report - Topics

Themen ohne Antwort

Anzahl der neu erstellten Themen, die keine Antwort erhalten haben.

Ruby-Code: discourse/app/models/concerns/reports/topics_with_no_response.rb

SQL-Abfrage: Dashboard Report - Topics with No Response

Themenaufruf-Statistiken

Top 100 Themen nach Aufrufen mit Aufschlüsselung für anonyme und angemeldete Benutzer, filterbar nach Kategorie.

Ruby-Code: discourse/app/models/concerns/reports/topic_view_stats.rb

SQL-Abfrage: Dashboard Report - Topic View Stats

Trendende Suchbegriffe

Beliebteste Suchbegriffe mit ihren Klickquoten.

Ruby-Code: discourse/app/models/concerns/reports/trending_search.rb

SQL-Abfrage: Dashboard Report - Trending Search Terms

Trust-Level-Wachstum

Anzahl der Benutzer, die ihr Trust Level während dieses Zeitraums erhöht haben.

Der Trust-Level-Wachstumsbericht zieht Daten aus der Tabelle user_histories in der Discourse-Datenbank. Insbesondere zählt dieser Bericht die Anzahl der Male, in denen eine user_histories.action für eine Erhöhung des Benutzer-Trust-Levels aufgezeichnet wird.

Ruby-Code: discourse/app/models/concerns/reports/trust_level_growth.rb

SQL-Abfrage: Dashboard Report - Trust Level Growth

Nicht akzeptierte Richtlinien

Dieser Dashboard-Bericht identifiziert Themen mit Richtlinien, die von bestimmten Benutzern nicht akzeptiert wurden.

Ruby-Code: discourse-policy/plugin.rb at main · discourse/discourse-policy · GitHub

SQL-Abfrage: Dashboard Report - Unaccepted Policies

Benutzer-Flag-Verhältnis

Liste von Benutzern, sortiert nach dem Verhältnis der Staff-Antwort auf ihre Flags (Nicht-Einigung zu Einigung).

Ruby-Code: discourse/app/models/concerns/reports/user_flagging_ratio.rb

SQL-Abfrage: Dashboard Report - User Flagging Ratio

Benutzer-Notizen

Liste der neuesten Benutzer-Notizen.

Ruby-Code: discourse-user-notes/plugin.rb at main · discourse/discourse-user-notes · GitHub

SQL-Abfrage: Dashboard Report - User Notes

Benutzerprofil-Aufrufe

Gesamtzahl der neuen Aufrufe von Benutzerprofilen.

Ruby-Code: discourse/app/models/concerns/reports/profile_views.rb

SQL-Abfrage: Dashboard Report - User Profile Views

Benutzerbesuche

Die Gesamtzahl der Besuche angemeldeter Benutzer im Forum für den gewählten Zeitraum (heute, gestern, letzte 7 Tage usw.).

Ein Benutzerbesuch wird gezählt, wann immer ein eindeutiger angemeldeter Benutzer die Seite besucht, bis zu einmal pro Tag. Zum Beispiel, wenn ein Benutzer eine Seite jeden Tag innerhalb einer Woche besuchte, würde Discourse dies als 7 Benutzerbesuche zählen.

Ruby-Code: discourse/app/models/concerns/reports/visits.rb

SQL-Abfrage: Dashboard Report - User Visits

Benutzerbesuche (mobil)

Anzahl der eindeutigen angemeldeten Benutzer, die mit einem mobilen Gerät besucht haben.

Ruby-Code: discourse/app/models/concerns/reports/mobile_visits.rb

SQL-Abfrage: Dashboard Report - User Visits

Benutzer-zu-Benutzer (ohne Antworten)

Anzahl der neu initiierten persönlichen Nachrichten.

Ruby-Code: discourse/app/models/concerns/reports/user_to_user_private_messages.rb

SQL-Abfrage: Dashboard Report - User-to-User

Benutzer-zu-Benutzer (mit Antworten)

Anzahl aller neuen persönlichen Nachrichten und Antworten.

Ruby-Code: discourse/app/models/concerns/reports/user_to_user_private_messages_with_replies.rb

SQL-Abfrage: Dashboard Report - User-to-User

Benutzer pro Trust Level

Anzahl der Benutzer, gruppiert nach Trust Level.

Ruby-Code: discourse/app/models/concerns/reports/users_by_trust_level.rb

SQL-Abfrage: Dashboard Report - Users Per Trust Level

Benutzer pro Typ

Anzahl der Benutzer, gruppiert nach Admin, Moderator, Suspendiert und Stummgeschaltet.

Ruby-Code: discourse/app/models/concerns/reports/users_by_type.rb

SQL-Abfrage: Dashboard Report - Users Per Type

Web-Crawler-Seitenaufrufe

Gesamtzahl der Seitenaufrufe von Web-Crawlern über die Zeit.

Ruby-Code: discourse/app/models/report.rb

SQL-Abfrage: Dashboard Report - Web Crawler Pageviews

Web-Crawler-User-Agents

Liste der Web-Crawler-User-Agents, sortiert nach Seitenaufrufen.

Ruby-Code: discourse/app/models/concerns/reports/web_crawlers.rb

SQL-Abfrage: Dashboard Report - Web Crawler User Agents

[pfaffman (Jay Pfaffman)]

@Sara Devlaeminck

Discourse enthält mehrere integrierte Berichte im Admin-Dashboard, die nützlich sein können, um Statistiken über eine Community zu erkunden. Um auf diese Berichte zuzugreifen, können Sie /admin/dashboard/reports auf Ihrer Website besuchen.

Ich sehe keinen Link dazu unter /admin. Überlese ich etwas? Es scheint, dass dies leichter auffindbar sein sollte. Ich glaube, ich wusste, dass diese Berichte hier waren, habe aber gesucht und sie nicht gefunden.

Obwohl es nur wenige Minuten gedauert hat, sie zu finden, wäre es vielleicht schön, etwas wie Folgendes hinzuzufügen:

Plugins können Berichte mit add_report(name, &block) zum Dashboard hinzufügen.

[maiki]

@pfaffman

Ich sehe keinen Link dazu unter /admin.

@pfaffman

Es scheint, dass dies auffindbarer sein sollte. Ich glaube, ich wusste, dass diese Berichte hier waren, habe aber gesucht und sie nicht gefunden.

Ja, es wäre vielleicht nett, in einer PM an das Personal sie zu erwähnen, wenn eine Website zum ersten Mal erstellt wird.

[pfaffman (Jay Pfaffman)]

Entschuldigung. Ich dachte wirklich, ich hätte es schon einmal irgendwo gesehen.

Man kann die Leute einfach nicht dazu bringen, Dinge zu lesen. . . . Außer ich könnte den Quellcode lesen, um herauszufinden, wie man es in einem Plugin macht?

Aber vielleicht die obige Aktualisierung zu

@SaraDev

. Um auf diese Berichte zuzugreifen, können Sie /admin/dashboard/reports auf Ihrer Website besuchen oder auf den Link Berichte im Dashboard klicken.

Ich glaube, das hat mich wirklich verwirrt. (Aber nein, ich habe keine Entschuldigung.)

[maiki]

@Jay Pfaffman

Aber vielleicht das oben aktualisieren auf

Ich habe das Thema zu einer Wiki gemacht, leg los!

[hello-smile6 (9pfs)]

@Sara Devlaeminck

Streben Sie >30 % an.

Das stimmt nicht mit der Benutzeroberfläche überein (die Benutzeroberfläche verwendet 20 %), welche sollte es sein?

[JammyDodger]

Guter Fang. Es wurde kürzlich auf 20 % aktualisiert. Ich werde die Änderung im OP vornehmen.

Is there a difference in target retention rate between a support-first forum and discussion-first forum?

Here’s a PR with that change: Longer term, I think a more nuanced approach could be powerful. I’d love for communities to be able to set their own goals (with some guidance like what you shared above about why they might choose one vs. the other) and use the dashboard or other related features to help them track their results vs. what they are aiming for.

[Yotam_Hagay]

@SaraDev

Top Traffic Sources

Externe Quellen, die am häufigsten auf diese Website verlinkt haben.

Ruby-Code: discourse/app/models/concerns/reports/top_traffic_sources.rb

Hallo @SaraDev Kann diese Berichts-Ausgabe mit einer SQL-Abfrage erzielt werden? Können Sie sie teilen?
Danke

[SaraDev (Sara Devlaeminck)]

@Yotam_Hagay

Hallo @SaraDev Kann dieser Bericht-Output mit einer SQL-Abfrage erzielt werden? Können Sie ihn teilen?
Danke

Ja, Sie können den folgenden SQL-Bericht für Top-Traffic-Quellen verwenden:

-- [params]
-- date :start_date = 01/05/2023
-- date :end_date = 03/06/2023

WITH count_links AS (

SELECT COUNT(*) AS clicks,
       ind.name AS domain
FROM incoming_links il
  INNER JOIN posts p ON p.deleted_at ISNULL AND p.id = il.post_id
  INNER JOIN topics t ON t.deleted_at ISNULL AND t.id = p.topic_id
  INNER JOIN incoming_referers ir ON ir.id = il.incoming_referer_id
  INNER JOIN incoming_domains ind ON ind.id = ir.incoming_domain_id
WHERE t.archetype = 'regular'
  AND il.created_at::date BETWEEN :start_date AND :end_date
GROUP BY ind.name
ORDER BY clicks DESC
),

count_topics AS (

SELECT COUNT(DISTINCT p.topic_id) AS topics,
       ind.name AS domain
FROM incoming_links il
INNER JOIN posts p ON p.deleted_at ISNULL AND p.id = il.post_id
INNER JOIN topics t ON t.deleted_at ISNULL AND t.id = p.topic_id
INNER JOIN incoming_referers ir ON ir.id = il.incoming_referer_id
INNER JOIN incoming_domains ind ON ind.id = ir.incoming_domain_id
WHERE t.archetype = 'regular'
  AND il.created_at > (CURRENT_TIMESTAMP - INTERVAL '30 DAYS')
GROUP BY ind.name
)

SELECT cl.domain,
       cl.clicks AS "Klicks",
       ct.topics AS "Themen"
FROM count_links cl
JOIN count_topics ct ON cl.domain = ct.domain
LIMIT 10

Beachten Sie bei dieser Abfrage, dass die Datumsparameter Daten im Format Tag/Monat/Jahr akzeptieren.

[Yotam_Hagay]

@SaraDev

Ja, Sie können den folgenden SQL-Bericht für Top-Traffic-Quellen verwenden:

Hallo @SaraDev, vielen Dank für das Teilen der Abfrage.
Eine allgemeinere Frage zu diesem Bericht und der Tabelle incoming_links – sie stellt nur den Traffic für Beitragsseiten dar und nicht den Traffic für alle Forenseiten, richtig?

Kontext: Ich möchte Trends im gesamten Forum-Traffic analysieren und hoffte, den gesamten Traffic nach Quellen aus dem Bericht „Top Traffic Sources“ zu erhalten.
Aber während der Gesamtverkehr im letzten Monat bei ~ 272.000 lag (Benutzer und Anonyme), beträgt die Gesamtzahl der Klicks im Bericht „Traffic Sources“ für denselben Zeitraum nur 59.000.
Außerdem sehe ich, dass Sie einen inneren Join mit den Tabellen topics und posts verwenden, was bedeutet, dass Sie ihn nicht zählen, wenn kein post_id mit dem Klick verknüpft ist.

Können Sie meine Schlussfolgerung bitte bestätigen und vielleicht ein wenig über die Logik hinter der Tabelle incoming_links erklären?

[Yotam_Hagay]

@SaraDev

Beiträge

Neue Beiträge, die in diesem Zeitraum erstellt wurden

Hallo @SaraDev, ich habe diese Abfrage ausgeführt und das Ergebnis stimmt nicht genau mit dem Bericht „Beiträge“ im Tab „Allgemein“ überein.
Z.B. für den 30. November:
Abfrage = 112 Beiträge
Bericht = 120 Beiträge
Können Sie bitte die Lücke überprüfen?
Danke

[JammyDodger]

Nur zur Information, @Yotam_Hagay – auch wenn Sara die Erstellerin ist, ist der Leitfaden die Verantwortung von jedem Es ist nicht nötig, jede Nachricht mit @ zu erwähnen.

[Yotam_Hagay]

Danke @JammyDodger für die Klarstellung.
Gibt es noch jemanden, den ich markieren oder an den ich mich wenden kann, um eine Antwort zu erhalten?

[Yotam_Hagay]

@SaraDev

SQL Zeit bis zur ersten Antwort

--[params]
-- date :date_start
-- date :date_end

WITH first_reply AS (
    SELECT 
        p.topic_id, 
        MIN(post_number) post_number, 
        t.created_at
    FROM posts p
    INNER JOIN topics t ON (p.topic_id = t.id)
    WHERE p.deleted_at IS NULL
        AND p.post_number != 1
        AND p.post_type = 1
        AND p.user_id > 0
        AND t.user_id > 0
        AND t.deleted_at IS NULL
        AND t.archetype = 'regular'
        AND t.created_at::date BETWEEN :date_start AND :date_end
    GROUP BY p.topic_id, t.created_at
    ORDER BY 2 DESC
)

SELECT 
    p.topic_id, 
    fr.created_at::date dt_topic_created,
    (p.created_at - fr.created_at) response_time
FROM posts p
INNER JOIN first_reply fr 
    ON fr.topic_id = p.topic_id 
    AND fr.post_number = p.post_number
    AND p.created_at > fr.created_at
ORDER BY response_time

Die Ergebnisse dieser Abfrage unterscheiden sich geringfügig vom Bericht „Zeit bis zur ersten Antwort“:
Am 8. November zum Beispiel:
Abfrage: 93 Stunden
Bericht: 116 Stunden
Kann mir jemand weiterhelfen?

[JammyDodger]

Ich glaube, einige davon könnten einige Zeit für die Recherche in Anspruch nehmen. Ich schaue es mir selbst an, um zu sehen, ob ich herausfinden kann, was los ist (obwohl die Lücke zwischen meinen SQL- und meinen Ruby-Kenntnissen ziemlich groß ist ).

Aber bringen Sie die Ergebnisse weiter, da es großartig wäre, all diese Informationen zu festigen.

[JammyDodger]

@Yotam_Hagay

Hallo @SaraDev Ich habe diese Abfrage ausgeführt und das Ergebnis stimmt nicht genau mit dem Beitragbericht im allgemeinen Tab überein.
Z.B. für den 30. November:
Abfrage = 112 Beiträge
Bericht = 120 Beiträge
Können Sie bitte die Lücke prüfen?
Danke

Für den Beitrag denke ich, dass der Lagerbericht auch Themenbeiträge sowie Beiträge von Systembenutzern zählt, aber auch nur diejenigen mit post_type 1 (d.h. keine Whispers, kleinen Aktionsbeiträge oder Moderationsaktionen) anvisiert.

Ich denke, die SQL würde eher so aussehen:

--[params]
-- date :start_date
-- date :end_date

SELECT 
    p.created_at::date AS "Tag",
    COUNT(p.id) AS "Anzahl"
FROM posts p
INNER JOIN topics t ON t.id = p.topic_id AND t.deleted_at ISNULL
WHERE p.created_at::date BETWEEN :start_date AND :end_date
    AND p.deleted_at ISNULL
    AND t.archetype = 'regular'
    AND p.post_type = 1
GROUP BY p.created_at::date
ORDER BY 1

Könnten Sie das auf Ihrer Website ausführen und sehen, ob es übereinstimmt?

[Yotam_Hagay]

Danke Jammy, ich werde das prüfen!
Ich arbeite gerade an einer Analyse der Antwortzeit, daher wäre es toll, wenn du dir auch diese hier ansehen könntest.

[JammyDodger]

Ich glaube, in der SQL-Version fehlt AND p.user_id <> t.user_id, um Antworten vom OP auszuschließen. Wenn ich das hinzufüge, erhalte ich die genaue Zeit zwischen dem OP und der ersten Antwort von jemand anderem:

--[params]
-- date :date_start
-- date :date_end

WITH first_reply AS (
    SELECT 
        p.topic_id, 
        MIN(post_number) post_number, 
        t.created_at
    FROM posts p
    INNER JOIN topics t ON (p.topic_id = t.id)
    WHERE p.deleted_at IS NULL
        AND p.user_id <> t.user_id
        AND p.post_number != 1
        AND p.post_type = 1
        AND p.user_id > 0
        AND t.user_id > 0
        AND t.deleted_at IS NULL
        AND t.archetype = 'regular'
        AND t.created_at::date BETWEEN :date_start AND :date_end
    GROUP BY p.topic_id, t.created_at
    ORDER BY 2 DESC
)

SELECT 
    p.topic_id, 
    fr.created_at::date dt_topic_created,
    (p.created_at - fr.created_at) response_time
FROM posts p
INNER JOIN first_reply fr 
    ON fr.topic_id = p.topic_id 
    AND fr.post_number = p.post_number
    AND p.created_at > fr.created_at
ORDER BY response_time

Ich glaube auch, dass der Lagerbericht in Dezimalzahlen und nicht in Stunden und Minuten wie SQL ist. Ich werde noch einmal versuchen, ihn anzupassen.

---

Nur ein kleines Update, um AVG einzuschließen, damit es dem Ergebnis des Lagerberichts ähnlicher ist:

--[params]
-- date :date_start
-- date :date_end

WITH first_reply AS (
    SELECT 
        p.topic_id, 
        MIN(post_number) post_number, 
        t.created_at
    FROM posts p
    INNER JOIN topics t ON p.topic_id = t.id
    WHERE p.deleted_at IS NULL
        AND p.user_id <> t.user_id
        AND p.post_type = 1
        AND p.user_id > 0
        AND t.user_id > 0
        AND t.deleted_at IS NULL
        AND t.archetype = 'regular'
        AND t.created_at::date BETWEEN :date_start AND :date_end
    GROUP BY p.topic_id, t.created_at
)

SELECT 
    fr.created_at::date dt_topic_created,
    AVG(p.created_at - fr.created_at) response_time
FROM posts p
INNER JOIN first_reply fr 
    ON fr.topic_id = p.topic_id 
    AND fr.post_number = p.post_number
    AND p.created_at > fr.created_at
GROUP BY fr.created_at::date
ORDER BY response_time

Dies scheint mit dem Lagerbericht übereinzustimmen, solange man berücksichtigt, dass das eine Dezimalzahlen und das andere HH:MM ist. Ich bin sicher, es gibt eine Möglichkeit, die SQL response_time in Dezimalzahlen umzuwandeln, aber HH:MM scheint eine intuitivere Methode zu sein. (Ich glaube, es gibt auch einige zusätzliche Kriterien, die möglicherweise nicht notwendig sind, aber auch als Schutz gegen ungewöhnliche Umstände dienen könnten, daher habe ich diese Teile letztendlich so belassen, bis ich sicher sagen kann, ob oder ob nicht )

Könnten Sie diese hier ausführen und sehen, wie sie übereinstimmt?

[Yotam_Hagay]

Ja, das stimmt jetzt mit den Zahlen im Lagerbericht überein, danke!
Nur eine Anmerkung -
Ich habe festgestellt, dass die unten stehende AVG-Funktion fehlende Ergebnisse zurückgibt, falls die Zeit > 24 Stunden beträgt (ein Abschnitt für die Anzahl der Tage fehlt vermutlich).

AVG(p.created_at - fr.created_at)::time response_time

[JammyDodger]

Ja, die Umwandlung in time war eine schlechte Wahl. Wenn Sie ::time entfernen, wird es zur genaueren (wenn auch schwerer zu lesenden) Version zurückkehren.

Ich werde auch die obige bearbeiten.