Analyse von Veränderungen mit historischen Daten (Snapshotting)
Die Analyse der neuesten Daten und Änderungen bei GoodData ist einfach. In diesem Artikel ist ein Verkaufsszenario beschrieben, aber Sie können damit auch die Daten in Ihrem Helpdesk, der Qualitätssicherung oder der Konstruktion und Entwicklung analysieren.
In diesem Artikel möchten wir eine Analysetechnik vorstellen, die wir als Snapshotting bezeichnen. In dem folgenden Beispiel arbeiten Sie mit Begriffen wie Opportunities (Gelegenheiten), Sales Stages (Umsatzstufen) und Change (Veränderung).
Verkaufsanalyse
Bei der Verkaufsanalyse geht es um Verkaufsgelegenheiten, die durch Ihre Geschäftsaktivitäten zustande kommen. Jede Gelegenheit hat einen Status. Dieser beschreibt, ob die Gelegenheit offen (in der Pipeline) ist oder ob sie gewonnen (Erlöse) oder verloren (verlorene Erlöse) wurde.
In diesem Artikel versuchen wir, eine typische Verkaufsfrage zu beantworten: „Wie sah die Pipeline zu Quartalsbeginn aus und wie hat sie sich seither verbessert?“
Snapshotting - die Grundelemente
Um diese Fragen zu beantworten, verwenden Sie die so genannte Snapshotting-Technik. Die Grundidee ist, dass wir alle Gelegenheiten weiterhin jede Woche (oder entsprechend Ihren Anforderungen jeden Tag bzw. Monat) aus Ihrem CRM zu GoodData übertragen. Den wöchentlichen Set von Gelegenheiten bezeichnen wir als Snapshot. Jedem Snapshot ist ein Datum und eine eindeutige ID zugeordnet.
Wenn wir also ein Projekt mit Snapshots von 118 Wochen haben, werden die meisten unserer Gelegenheiten 118 mal im Projekt kopiert. Einige davon, die erst nach Beginn der Erstellung von Snapshots entstanden sind, haben weniger als 118 Versionen. Jeder Version ist ein Snapshot-Datum (etwa Montag jeder Woche) und die Snapshot-ID zugeordnet. Snapshot-IDs in lückenloser Folge zu verwenden, hat erhebliche Vorteile. Wir können dann nämlich vorherige/nächste Snapshots als aktuelle ID minus/plus Eins erkennen.
Hier ist der erste Haken. Eine einfache Metrik SELECT SUM(Amount) WHERE Status = Open
misst Ihre Pipeline und ergibt eine Zahl, die etwa 118 mal höher liegt, als wir erwartet haben. Der Grund hierfür ist, dass wir alle zehn Versionen jeder Gelegenheit addieren. Stattdessen können wir eine Metrik definieren, die nur den Gesamtbetrag für einzelne Snapshots zeigt:
Pipeline [vor 118 Wochen]:
SELECT SUM(Amount) WHERE Status = Open AND SnapshotId = 1
Pipeline [Now]:
SELECT SUM(Amount) WHERE Status = Open AND SnapshotId = 118
Sie brauchen jedoch nächste Woche eine neue Metrik und eine weitere in der übernächsten. Praktisch wäre eine Metrik, die den Gesamtbetrag für den letzten Snapshot ergibt. Wir wollen so eine Metrik mit ID des letzten Snapshots erstellen:
Snapshot [Most Recent]:
SELECT MAX(SnapshotId)
Diese Definition klingt einfach genug. Sie ist jedoch in gewisser Hinsicht problematisch. Angenommen, der Handelsvertreter John wurde während Snapshot 25 entlassen. Wir belassen alle von ihm abgeschlossenen Gelegenheiten bei ihm und ordnen alle offenen Gelegenheiten anderen Handelsvertretern zu.
Wenn wir nun die Metrik Snapshot [Most Recent] nach Handelsvertreter aufschlüsseln, sehen wir, dass die Metrik für alle Handelsvertreter 118 ergibt, außer für John, bei dem das Ergebnis von Snapshot [Most Recent] = 25 ist. Dies ist problematisch, da wir unsere Summe mit dem Snapshot 25 für John und für alle anderen mit dem Snapshot 118 berechnen würden. Wir müssen die Definition der Metrik [Most Recent] verbessern:
Snapshot [Most Recent]:
SELECT MAX(SnapshotId) BY ALL IN ALL OTHER DIMENSIONS WITHOUT PARENT FILTER`
Diese Metrik ergibt den MAX-Snapshot ohne Berücksichtigung irgendwelcher Dimensionen. Der letzte Snapshot (=118) für alle Handelsvertreter, auch John, für alle Regionen, für alle Produkte, etc. Wenn Sie die Aussage BY ALL IN ALL OTHER DIMENSIONS zu Ihrer Metrik hinzufügen, erhalten Sie die Gesamtsumme (MAX) der Zeit und aller Dimensionen Das Ergebnis ist eine Konstante.
Wozu dient die Klausel WITHOUT PARENT FILTER? Angenommen, Sie verwenden die Metrik in einem Bericht, der den Filter SalesRep = John enthält. Diesen Filter anzuwenden, würde dieselben Probleme verursachen, die wir mit BY ALL IN ALL OTHER DIMENSIONS behoben haben. Die Klausel WITHOUT PARENT FILTER ignoriert die Filter der höheren Ebene ganz einfach.
Ausführliche Beispiele und Aggregationskonzepte finden Sie unter MAQL - Analytische Abfragesprache.
Dann können wir die Metrik Snapshot [Most Recent] in unserer Pipeline-Metrik verwenden und den neuesten Betrag folgendermaßen berechnen:
Pipeline [Now]:
SELECT SUM(Amount) WHERE Status = Open AND SnapshotId = Snapshot [Most Recent]
Genauso können wir die Pipeline für den ersten Snapshot (den ältesten) berechnen. Die Metrik lautet:
Snapshot [Oldest]:
SELECT MIN(SnapshotId) BY ALL IN ALL OTHER DIMENSIONS
und wird in der folgenden Pipeline-Metrik verwendet:
Pipeline [Oldest]:
SELECT SUM(Amount) WHERE Status = Open AND SnapshotId = Snapshot [Oldest]
Veränderung der Pipeline in einem Quartal bestimmen
Der älteste und der neueste Snapshot sind hervorragend, aber wir brauchen etwas anderes. Wir möchten die Pipeline für den ersten und den letzten Snapshot in einem Quartal berechnen. Dies erreichen wir mit den folgenden Metrikdefinitionen:
Snapshot [First in Period]:
SELECT MIN(SnapshotId) BY ALL IN ALL OTHER DIMENSIONS EXCEPT SnapshotDate WITHOUT PARENT FILTER
Snapshot [Last in Period]:
SELECT MAX(SnapshotId) BY ALL IN ALL OTHER DIMENSIONS EXCEPT SnapshotDate WITHOUT PARENT FILTER
Konzentrieren wir uns auf die Ausnahmeanweisung BY ALL IN ALL OTHER DIMENSIONS
. Mit diesem Konzept können Sie die MAX/MIN-Summe für die SnapshotId berechnen, ohne Dimensionen zu berücksichtigen, jedoch mit Ausnahme des speziellen Attributs. Die Ausnahme ist ein Attribut hinter dem Ausdruck EXCEPT
. Damit ist die sich ergebende Zahl keine Konstante mehr. Sie ist vom Wert des SnapshotDates abhängig. Mit anderen Worten: Diese Metrik ergibt die maximalesSnapshotId für den SnapshotDate-Zeitraum.
Wenn Sie die obige Metrik in einem Bericht mit dem Snapshotquartal einfügen, sehen Sie die erste und die letzte Snapshot-ID, die wir für jedes Quartal haben. Siehe folgenden Bericht.
Daher sieht die Pipeline zu Beginn eines Zeitraums folgendermaßen aus:
Pipeline [First in Period]:
SELECT SUM(Amount) WHERE Status = Open AND SnapshotId = Snapshot [First in Period]
Und die neueste und höchste Pipeline-Nummer ist:
Pipeline [Last in Period]:
SELECT SUM(Amount) WHERE Status = Open AND SnapshotId = Snapshot [Last in Period]
Jetzt brauchen Sie diese beiden Metriken nur noch in einen Bericht mit dem Snapshot-Quartal einzufügen und Sie erhalten die Pipeline zu Beginn jedes Quartals sowie die letzte bekannte Pipeline jedes Quartals.
Je nach Ihren Anforderungen können Sie diese Zahlen dividieren oder subtrahieren, um das absolute oder relative Wachstum zu erhalten.