Dieser Artikel beschreibt die grundsätzliche Funktionsweise des Kategoriebaums. Die Anleitung zur Benutzeroberfläche & Navigation innerhalb der Kategorien gibt es hier.
In Mercury können Organisationsstrukturen mit Hilfe eines flexiblen Kategoriesystems abgebildet werden. Beispielsweise kann man für verschiedene Standorte, Kunden, Produktkategorien oder Produkte eine hierarchische Struktur anlegen. Dabei ist weder die Struktur noch die Anzahl der Ebenen vorgegeben.
Beispiele für Kategoriepfade:
- Frankfurt > Kunde A > Möbel > Tische > Esstische > Modell Rustikal > 2017
- Hamburg > Kunde B > Versicherungen > Kfz-Versicherung
Man kann sich Kategorien auch als Ordner vorstellen. Allerdings haben die Kategorien in Mercury einige Vorteile gegenüber einer reinen Ordnerstruktur.
Bsp. Kategoriebaum in der Pfadansicht
Bsp. Kategoriebaum im DropDown
Vorteile von Kategorien
Die Verwendung einer hierarchischen Kategoriestruktur hat einige Vorteile:
- Kategorien helfen Benutzern, die Übersicht im System zu behalten.
Kategorien ermöglichen es Administratoren, den Zugriff auf bestimmte Daten für Benutzer im System unterschiedlich zu regeln. Weitere Informationen zu Rollen und Berechtigungen finden sich hier.
In Kategorien werden wichtige, spezifische Daten sowohl für ein Media Mix Modelling, als auch für die Mediaplanung hinterlegt, z.B. Honorare, Rechnungsdaten, AdServer-Konditionen. Damit stehen diese wichtigen Daten zentral zur Verfügung. Das erleichtert den Zugriff auf diese Daten für alle und vermindert Fehler. Denn nur Nutzer mit einer entsprechenden Berechtigung dürfen diese Daten verwalten.
Vererbung im Kategoriebaum
Auf einer Kategorie hinterlegte Daten stehen automatisch in allen im Kategoriebaum darunter liegenden Kategorie-Ebenen zur Verfügung, sie werden „vererbt“.
Beispiel 1:
Die folgende Kategoriestruktur ist im System vorhanden:
Kunde A
Produkt 1
Produktkategorie 1
Produkt 2
Kunde B
Produkt 3
In der Kategorie “Kunde A” wird ein Honorarmodell auf Mediakosten von 5% hinterlegt. Dieses Honorarmodell steht automatisch in den Unterkategorien “Produkt 1”, “Produktkategorie 1” und “Produkt 2” zur Verfügung, nicht aber in “Produkt 3” (da diese Kategorie nicht unterhalb von “Kunde A” angesiedelt ist).
Beispiel 2:
In der gleichen Struktur wie in Beispiel 1 erhält der Benutzer “Thomas” in der Kategorie “Produktkategorie 1” die Rolle “Mediaplanung”.
Thomas kann nun in den Kategorien “Produktkategorie 1” und “Produkt 2” alle mit der Rolle “Mediaplanung” verknüpften Tätigkeiten ausüben. In den übrigen Kategorien hat er diese Berechtigung nicht.
Beispiel 3:
In der gleichen Struktur wird für “Produktkategorie 1” ein Kundenskonto von 2% hinterlegt. In “Produkt 2” wird der Skontosatz mit 0% überschrieben.
Nun wird auf Planzeilen in Kampagnen direkt unterhalb von “Produktkategorie 1” ein maximales Skonto von 2% angewendet. In “Produkt 2” gilt ein maximales Kundenskonto von 0%. Der Wert aus “Produktkategorie 1” wurde also in der Unterkategorie überschrieben.
Beispiel 4:
In “Kunde A” ist ein technischer Baustein für das Tracken von Werbemitteln bis 200kB hinterlegt. Dieser Baustein steht nun in allen Kategorien unterhalb von “Kunde A” zur Verfügung.
In “Produkt 1” wird ein weiterer technischer Baustein für Ads bis 500kB hinterlegt. Dieser steht nur in “Produkt 1”, nicht aber in “Produktkategorie 1” oder “Produkt 2” zur Verfügung.
Anmerkung: Die Verwaltung von Kategorierollen, Honorarmodellen, Kundenskonto und technischen Bausteinen ist jeweils an eine Berechtigung geknüpft und wird von dazu berechtigten Personen im System vorgenommen.