Top Instagram Posts (Admin)

Admin-Seite unter /admin/instagram-posts zur Validierung der erfassten Instagram-Post-Daten. Sie beantwortet eine Frage: Sieht das, was die Erfassung liefert, plausibel aus? Sie ist kein Reporting-Werkzeug.

Zu finden in der Sidebar unter Daten & Profile → Top Instagram Posts.

Was die Seite zeigt

Die stärksten Posts eines Tages — als Karten in bis zu vier Spalten, mit Vorschaubild, Profil, Likes und Kommentaren, bei Reels zusätzlich Views, einem Verlauf und einem Link zum Original.

Bedienelement	Bedeutung
Tag	Datumsfeld plus Vor/Zurück und „Heute". Gezeigt wird jeweils die jüngste Messung des Tages je Post. Ein Tag ist ein Kalendertag in UTC, wie bei Tops & Flops und Video Trends.
Sortierung	Likes · Kommentare · Views · Follower des Profils
Richtung	Stärkste zuerst · Schwächste zuerst
Post-Alter	7 Tage · 30 Tage · 3 Monate · 6 Monate · 1 Jahr — filtert nach first_seen_at, also danach, wann wir den Post zuerst gesehen haben
Nachladen	automatisch, sobald das Ende der Liste in Sichtweite kommt — je Abschnitt 50 Posts, bis maximal 500

Gibt es für den gewählten Tag keine Messung, sagt die Seite das ausdrücklich, statt eine leere Liste zu zeigen.

Views nur bei Reels

Instagram zeigt Views nur bei Reels. Die Karte trägt die Spalte Views deshalb nur, wenn der Collector den Beitrag als reel meldet; bei post und carousel teilen sich Likes und Kommentare die Breite.

Ein Reel ohne erfassten Wert behält die Spalte und zeigt „—". Auf dieser Seite ist das ein Befund über die Erfassung, und ihn auszublenden hieße, ihn zu verstecken. Nur ein unbekannter Typ entscheidet am Wert selbst.

Was die Liste NICHT zeigt — und warum sie es sagt

Ein Post, dessen sortierte Kennzahl 0 ist oder fehlt, steht nicht in der Liste. In einer Bestenliste hat er nichts verloren; eine Seite, die unter „Sortierung: Likes" zwanzig Karten mit 0 Likes zeigt, beantwortet ihre eigene Frage nicht.

Gefiltert wird die Kennzahl, nicht der Post: ein Beitrag mit 0 Likes und 92 Kommentaren fehlt in der Likes-Sortierung und steht in der Kommentar-Sortierung ganz oben.

⚠️ Das gilt auch für leere Werte, und dieser Teil ist wichtiger als er aussieht. views_count darf leer sein, und PostgreSQL sortiert leere Werte bei absteigender Sortierung ganz nach oben. Ohne diese Bedingung lieferte eine Sortierung nach Views zuverlässig genau die Posts zuerst, über die nichts bekannt ist — also das Gegenteil dessen, wonach gefragt war.

Die Zahl der ausgeblendeten Posts steht über der Liste. Das ist kein Detail: Diese Seite prüft die Erfassung. Würden Posts ohne Wert wortlos verschwinden, wäre „der Collector liefert für diese Kennzahl gar nichts" nicht mehr von „an diesem Tag wurde nichts erfasst" zu unterscheiden. Sind alle Posts eines Tages bei der gewählten Kennzahl leer, sagt die Seite genau das: das ist kein leerer Tag, das ist ein Befund über die Erfassung dieser Kennzahl.

Bei Gleichstand entscheidet die Post-ID. Ohne diese Zweitsortierung dürfte die Datenbank bei gleichen Werten jede Reihenfolge liefern — auch eine andere als beim vorigen Aufbau der Seite, und dann springen Karten beim Nachladen.

Nachladen und Ladezeit

Die Liste lädt in Abschnitten von 50 Posts nach, sobald ihr Ende in Sichtweite kommt — ohne Klick. Der Server rendert dabei nur den neuen Abschnitt, und der Browser hängt ihn an. Bereits geladene Karten bleiben unberührt, samt Bild und Diagramm. Am Ende steht, wie viele Posts geladen sind, oder dass die Seite mehr als 500 nicht zeigt.

Die Bestenliste wird einmal je Tag, Sortierung, Richtung und Post-Alter berechnet und danach aus dem Cache geschnitten: für den laufenden Tag fünf Minuten lang, für vergangene Tage eine Stunde. Die Seite nennt deshalb den Stand der Rangliste — in UTC und ausdrücklich so beschriftet, passend zu den UTC-Tagen der Seite und zu den übrigen Admin-Seiten. Die Zahl der ausgeblendeten Posts entsteht in derselben Abfrage.

⚠️ Bis v2.11.3 dauerte das Nachladen bis zu einer Minute, und der Grund war nicht eine langsame Abfrage, sondern ihre Anzahl. Die Tagesabfrage war ein #[Computed] und wurde als Methode aufgerufen — je Karte ein weiteres Mal. #[Computed] merkt sich einen Wert aber nur beim Zugriff als Eigenschaft. Ein Aufbau mit N Karten fuhr die Abfrage deshalb N + 3 Mal, und jedes Nachladen baute alle bisherigen Karten mit auf.

Gemessen an erzeugten Daten mit 100.000 Posts je Tag:

Schritt	vorher	nachher
Aufruf	2.119 ms · 24 Tagesabfragen	574 ms · 1 Tagesabfrage
erstes Nachladen	3.718 ms · 44 Tagesabfragen	75 ms · keine
zweites Nachladen	5.346 ms · 64 Tagesabfragen	68 ms · keine
Filterwechsel	2.201 ms · 24 Tagesabfragen	335 ms · 1 Tagesabfrage

Die Millisekunden stammen von einem Entwicklungsrechner; übertragbar ist die Zahl der Abfragen, nicht ihre Dauer.

Während eines Filterwechsels zeigt die Filterleiste „Lädt …", und das Raster ist abgedimmt. Beim Nachladen erscheint unter dem Raster „Weitere Posts werden geladen …".

Die Auflösungs-Angabe — und warum sie dasteht

Unter den Filtern steht ein Satz wie „Verlaufsdaten in diesem Zeitraum liegen wöchentlich vor."

Das ist keine Verzierung. instagram_post_metrics wird gestuft ausgedünnt: Bis 30 Tage bleibt jeder Messpunkt, danach einer je Woche, ab 180 Tagen einer je Monat. Wer den Filter auf ein Jahr stellt, sieht Monatswerte — und soll das wissen, statt eine Genauigkeit anzunehmen, die die Daten nicht haben.

Die Angabe wird aus der Konfiguration abgeleitet, nicht fest verdrahtet: Ändern sich die Retention-Stufen, ändert sich der Satz mit.

Verlauf je Post

Unter den Kennzahlen jeder Karte steht ein kleiner Verlauf: Likes, Kommentare und Views über den gewählten Zeitraum, als Sparkline mit eigenen, ausgeblendeten Achsen — Likes gehen in die Tausende, Kommentare in die Hunderte, auf einer gemeinsamen Skala wäre die kleinere Reihe eine flache Linie.

Jede Kennzahl hat ihre feste Farbe — Likes blau, Kommentare orange, Views türkis —, und eine Legende unter dem Diagramm nennt sie. Die Farbe folgt der Kennzahl, nicht ihrer Position: Fehlt eine Reihe, behalten die anderen ihre Farbe. Die drei Töne sind mit einem Paletten-Validator geprüft, für hellen und dunklen Hintergrund und für Farbfehlsichtigkeit.

Aggregiert wird im Raster der Retention, nicht in einem eigenen: bis 30 Tage je Tag, danach je Woche, ab 180 Tagen je Monat. Ein Chart, der bei einem Jahresfilter Wochen gruppierte, zeichnete Wochen, von denen jeweils drei von vier leer sind.

Je Zeitfenster zählt der höchste Wert, nicht der Durchschnitt: Likes und Kommentare sind kumulativ, der höchste Wert eines Fensters ist also der Stand an seinem Ende. Ein Durchschnitt wäre eine Zahl, die zu keinem Zeitpunkt galt.

Der Verlauf eines Abschnitts wird in einer Abfrage geholt.

Gezeichnet wird nur, was ein Signal hat. Eine Reihe braucht mindestens zwei Messpunkte — eine Linie durch einen Punkt ist keine — und mindestens einen Wert über null. Eine Reihe, die durchgehend auf 0 steht, wäre in der flachen Grafik nur ein Strich am unteren Rand.

Entschieden wird das je Reihe. Ein Post mit einem einzigen Likes-Messpunkt und einem vollständigen Kommentar-Verlauf zeigt den Kommentar-Verlauf; früher entschied allein die Zahl der Likes-Punkte darüber, ob überhaupt etwas erschien.

Ein Diagramm wird erst gezeichnet, wenn seine Karte in Sichtweite kommt. 50 Diagramme auf einmal blockierten Safari (WebKit) im Test fast 20 Sekunden, bevor die Seite reagierte; mit verzögertem Zeichnen ist sie dort nach rund drei Sekunden bedienbar. Ein gezeichnetes Diagramm bleibt bei jedem Neuaufbau stehen — bis v2.11.3 verschwanden die Diagramme der geladenen Karten beim Nachladen.

Vorschaubilder

Instagram-CDN-URLs sind signiert und laufen ab — ein direkt eingebundenes Bild ist nach Stunden tot. Das Vorschaubild wird deshalb einmal geholt und liegt danach lokal unter instagram_posts/… (gesharded nach Profil-ID).

Geholt wird bei der Anzeige, nicht beim Erfassen. Das ist eine bewusste Entscheidung mit einer Zahl dahinter: Bei rund 8,26 Millionen erfassten Posts würde ein Download beim Erfassen 165 bis 413 GB belegen. Die Seite zeigt 50 Posts je Abschnitt und lädt bis 500 nach — es werden also nur die Bilder geholt, die wirklich jemand ansieht.

⚠️ Aber nicht WÄHREND die Seite aufgebaut wird. Genau das war es bis zum 2026-09-04, und es hat die Seite unbenutzbar langsam gemacht: je Karte ein Abruf gegen Instagrams Bild-Server mit 15 Sekunden Zeitlimit, zwanzig davon nacheinander, im Web-Request. Das Nachladen läuft als Hintergrund-Auftrag auf der Warteschlange default.

Die Karte wartet auf ihr Bild und setzt es selbst ein, sobald der Auftrag fertig ist. Die Seite fragt dafür alle drei Sekunden in einer Abfrage nach dem Stand aller wartenden Bilder. Sie fragt nicht, solange nichts wartet, und gibt nach zwei Minuten ohne ein einziges neues Bild auf. Bis v2.11.3 erschien ein Bild erst beim nächsten Aufbau der Seite — beim Nachladen also die Bilder des vorigen Abschnitts, nie die des neuen.

Ein Auftrag je Post, mit einer Stunde Sperrfrist — ohne diese Sperre stünde derselbe Post nach drei Aufrufen dreimal in der Warteschlange.

Schlägt ein Download fehl (abgelaufener Link, gelöschter Post), wird das vermerkt und nicht bei jedem Seitenaufruf erneut versucht. Die Karte zeigt dann einen Platzhalter; alle übrigen Angaben bleiben sichtbar.

Aufgeräumt wird an zwei Stellen automatisch:

• Beim Löschen eines Profils gehen seine Post-Bilder mit — sie liegen im selben Shard-Verzeichnis.
• storage:purge-orphans --prefix=instagram_posts entfernt Dateien, auf die keine Zeile mehr zeigt. Der Lauf steht wöchentlich im Zeitplan.

Grenzen

• Kein Suchfeld. Wer einen bestimmten Post sucht, ist auf dieser Seite falsch.
• Maximal 500 Posts je Tag und Filter.
• Ein Tag, keine Zeitreihe. Für den Verlauf eines einzelnen Posts ist die Seite nicht gemacht.