Product Analytics oder Prozess-Monitoring: Funnels gegen Fristen

Was Product Analytics leistet

Product-Analytics-Tools wie PostHog, Mixpanel und Amplitude sammeln Events aus deiner App oder Website und machen daraus Diagramme. Funnels sind ihre Kernansicht auf einen Prozess. In PostHog zeigt ein Funnel, wo Nutzer abspringen, innerhalb eines Konversionsfensters, das du festlegst, und kann Schritte in fester, strikter oder beliebiger Reihenfolge zählen. Mixpanel-Funnels messen die Konversion über eine Folge von Schritten innerhalb eines Zeitfensters und stehen in allen Tarifen zur Verfügung. Die Funnel-Analyse von Amplitude zeigt, wie Nutzer einen festgelegten Pfad durchlaufen und wo sie abspringen.

Alarmieren können diese Tools auch. PostHog-Alerts arbeiten auf Trends, Funnels und SQL-Insights, mit Schwellen oder Anomalie-Erkennung, und benachrichtigen per Slack, Discord, Microsoft Teams oder Webhook; die Dokumentation schlägt sogar einen Alert auf fehlende kritische Events vor. Mixpanel-Alerts gibt es in bezahlten Tarifen, im Growth-Tarif fünf pro Projekt, per E-Mail, Slack oder Webhook, mit Anomalie-Erkennung.

Was Prozess-Monitoring leistet

Prozess-Monitoring schaut auf den einzelnen Fall statt auf die Summe. tiqline verknüpft Events über eine ID, etwa eine Bestellnummer, zu einem Fall, führt den Fall durch die Schritte, die du beschreibst, und prüft jeden Schritt gegen seine Zeitgrenze.

Verstreicht eine Frist, wird dieser Fall als hängend markiert. Alle hängenden Fälle eines Schritts teilen sich einen Vorfall, und ein Alarm geht an Slack oder per E-Mail, mit Links zu genau diesen Fällen. Jemand öffnet den Fall, sieht seine Timeline und handelt.

Die wichtigsten Unterschiede

• Einheit: Analytics zählt Nutzer oder Sitzungen. Prozess-Monitoring verfolgt jeden Fall für sich.
• Frage: Ein Funnel zeigt den Anteil, der konvertiert ist. tiqline zeigt die Liste der Fälle, die jetzt zu spät sind.
• Zeit: Ein Konversionsfenster beendet einen Funnel-Schritt für die Auswertung. Eine Zeitgrenze in tiqline löst für genau diesen Fall einen Alarm aus.
• Alarm: Analytics-Alerts lösen aus, wenn eine Kennzahl eine Schwelle kreuzt. tiqline alarmiert, wenn für einen Fall eine Frist verstreicht.
• Typische Daten: Klicks, Seitenaufrufe und Registrierungen gegen Bestellungen, Erfüllungen, Erstattungen und Lager-Schritte.

Nebeneinander

Wann Product Analytics passt

Nimm Product Analytics, wenn du einen Ablauf für viele Nutzer verbessern willst. Warum verlassen 40 % der Besucher den Checkout? Hat das neue Onboarding die Aktivierung erhöht? Welche Kampagne bringt Nutzer, die bleiben? Das sind Fragen über die Summe, und Funnels, Trends und Experimente beantworten sie gut.

Wann Prozess-Monitoring passt

Nimm Prozess-Monitoring, wenn jeder einzelne Fall zählt und jemand handeln muss. Eine Bestellung, die bezahlt und nicht versendet ist, eine Erstattung, die länger wartet als versprochen, ein Ticket, das seine erste Antwort verpasst hat: In jedem Fall sollte eine Person eine Nachricht mit dem Fall bekommen, nicht ein Diagramm, in dem die Konversion um zwei Punkte gefallen ist.

Beides kombinieren

Viele Teams schicken dieselben Events an beide. Das Analytics-Tool zeigt das langfristige Bild, etwa wie lange eine typische Bestellung von der Zahlung bis zum Versand dauert und wie sich das über Monate ändert. tiqline prüft heute jede offene Bestellung gegen ihre Zeitgrenze und alarmiert, wenn eine zu spät ist.

Über die track-API schickst du die Events, die dein Backend ohnehin erzeugt, etwa gepickt oder erstattet, mit der Bestellnummer als Fall-ID. Die beiden Tools sehen dann dieselben Schritte aus zwei Blickwinkeln.

Beispiel: Konversion passt, eine Kundin nicht

Alle Zahlen in diesem Beispiel sind erfunden. Das Analytics-Dashboard eines Shops zeigt, dass 96 % der bezahlten Bestellungen innerhalb von zwei Tagen erfüllt werden, eine normale Woche. In den restlichen 4 % stecken 11 Bestellungen mit Geschenknotiz, die an einen separaten Packtisch gingen und vergessen wurden.

In tiqline hat der Prozess eine Verzweigung auf einer Eigenschaft des Bezahlt-Events: Geschenkbestellungen gehen in einen Pack-Schritt mit einer Zeitgrenze von 12 Stunden, alle anderen in den normalen Pick-Schritt. Am Mittwoch überschreiten die 11 Geschenkbestellungen ihre Zeitgrenze. Eine Slack-Nachricht nennt den Schritt und sagt, dass 11 Fälle warten, und die E-Mail listet sie auf. Der Funnel hat sich nie genug bewegt, um einen Alert auszulösen.

So richtest du es in tiqline ein

• Schick die Geschäftsereignisse, die dein Backend ohnehin erzeugt, über die track-API oder verbinde Shopify.
• Wähle das ID-Feld, das Events einem Fall zuordnet, zum Beispiel die Bestellnummer.
• Beschreibe die Schritte im Prozess-Editor und setze für jeden Schritt nach dem ersten eine Zeitgrenze. Wo sich Fälle aufteilen, etwa in versendet oder storniert, fügst du eine Verzweigung ein.
• Prüfe den Entwurf in der Vorschau an deinen echten Fällen, bevor du ihn veröffentlichst. So siehst du, welche Fälle heute hängen würden.
• Wähle die Alarmkanäle: einen Slack-Kanal über einen Incoming Webhook, bis zu 20 E-Mail-Adressen oder beides.
• Veröffentliche den Prozess. Änderst du später eine Zeitgrenze, gilt sie sofort, auch für laufende Fälle, und die Änderung landet im Audit-Log.

Wer im Team welches Werkzeug nutzt

Product Analytics gehört meist dem Produktteam und dem Marketing. Sie schauen einmal pro Woche oder pro Release auf Funnels und entscheiden, was sich ändern soll. Prozess-Monitoring gehört dem Team, das Bestellungen bewegt: Operations, Lager und Kundenservice. Diese Leute schauen nicht in Diagramme, sie brauchen eine Nachricht, wenn ein bestimmter Fall wartet.

Deshalb gehen Alarme von tiqline in den Kanal, in dem dieses Team ohnehin arbeitet: einen Slack-Kanal oder bis zu 20 E-Mail-Adressen. Jeder Alarm verlinkt die wartenden Fälle, damit niemand erst suchen muss.

Grenzen von tiqline

tiqline ist kein Analytics-Tool. Es gibt keine Funnels nach Segmenten, keine Retention-Diagramme, keine Experimente und keine Anomalie-Erkennung. tiqline erklärt nicht, warum ein Fall hängt. Es arbeitet mit den Events, die aus Shopify oder über die track-API ankommen, und braucht eine ID, um sie einem Fall zuzuordnen. Für Fragen zum Nutzerverhalten behältst du dein Analytics-Tool.