Segment Builder für Fortgeschrittene

Nachdem wir die Funktionsweise der Segmente bereits vorgestellt haben, wollen wir heute etwas tiefer gehen und beschreiben, wie man Container schachteln und damit fast beliebig komplizierte Segmente erstellen kann.

Ganz schnelle Zusammenfassung:

1. ziehe ich einen Container auf den Canvas,
2. definiere ich innerhalb des Containers Rules.

Klingt ganz einfach, wo genau also kann man das kompliziert machen?

Wer sich das Fenster für die Regeldefinition genauer ansieht, wird dort zwei Elemente sehen, die auf mehr Möglichkeiten hindeuten.

Oben Links unter „This Visitor must match:“ kann man definieren ob alle oder nur mindestens eine Regel greifen müssen bzw. muß. Aha! Man kann also mehr als eine Regel definieren!

Genau. Der „Add“ Knopf neben der Regeldefinition verschwindet nicht, wenn man eine Regel eingefügt hat. Man kann damit nämlich mehr als eine Regel in die Liste setzen. Das sieht dann so aus:

 Mit mehreren Regeln in einem Container kann ich schon ganz interessante Segmente bauen: „Traffic aller Benutzer, die den Newsletter abonniert oder am Gewinnspiel teilgenommen haben“, oder „Alle Visits, in denen gekauft wurde, und zwar per Kreditkarte“.

Es geht aber noch viel spezifischer und komplexer, denn man kann Container schachteln. Obendrein gibt es noch den „Exclude“ Canvas, in dem man ebenfalls mehrere Container mit Rules definieren kann, was dann den Traffic wieder weiter limitieren würde.

Container kombinieren kann man auf zwei Arten: ineinander schachteln oder nebeneinander stellen.

Unterhalb eines Containers kann ich einen spezifischeren Container schachteln, also z.B. einen Visits Container in einen Visitors Container. Anwendungsbeispiel: Traffic für alle Visitors, die gekauft haben, aber nur für Visits, in denen ein bestimmtes Produkt angesehen wurde.

Discoanalogie

Das funktioniert ein bißchen so, als gäbe es vor einem Club mehrere Türsteher, die sich die Gäste nach immer detaillierteren Kriterien ansehen. Wer einen Türsteher (die Regeln in einem Container) passiert, ist noch lange nicht drin denn der nächste legt vielleicht ganz andere Kriterien an.

Nebeneinanderstehende Container sind hingegen laxer. Wenn ein Hit die Rules in einem Container nicht passiert, hat er immer noch die Möglichkeit, durch die Regeln in einem anderen Container durchzuschlüpfen. Anwendungsbeispiel: Traffic aller Visitors, die dem Link einer Kampagne gefolgt sind bzw. aller Visits, in denen das beworbene Produkt angesehen wurde.

Wir haben hier also einen Club mit zwei Eingängen. Die Türsteher entscheiden individuell, ohne sich abzustimmen. Damit hat man als Gast mehrere Chancen: Wer an einer Tür abgelehnt wurde kann es einfach an der anderen nochmal probieren.

Der „Exclude“ Canvas erlaubt weitere Regeln zu definieren, diesmal aber Regeln, die Teile der Daten ausschließen. Technisch werden zunächst die Regeln der Container im „Include“ Canvas angewendet. Die resultierenden Daten werden dann gegen die Regeln aus dem „Exclude“ Canvas getestet.

Testen! Testen! Testen!

Lange Zeit waren Segmente ein Thema für Fortgeschrittene.

Man konnte Segmente mit Data Warehouse benutzen, zum Befüllen von ASI Slots oder in Discover. SiteCatalyst konnte ansonsten nicht mit Segmenten umgehen, die meisten Analysten kamen also nie damit in Berührung.

Das hat sich mit SiteCatalyst 15 gründlich geändert: Segmente sind jetzt „ein Feature für Alle“ und daher in den Blickpunkt eines viel größeren Publikums gerückt.

Da es außerhalb von Discover nicht ganz einfach ist, auf Anhieb die Validität eines Segmentes zu kontrollieren, stellt sich natürlich die Frage: Wie macht man das am besten?

Die beste Möglichkeit ist sicher, Testdaten in eine separate Report Suite zu senden und das Segment darauf anzuwenden. Bei Testdaten weiß man natürlich genau, was man getrackt hat und man kann daher auch genau sagen, welche dieser Daten Teil des Segments sein sollen und welche nicht.

Wie macht man das genau?

Eine Report Suite zum Testen kann man sich einfach selber in SiteCatalyst anlegen. Wahrscheinlich hat man sowieso eine, die sollte nämlich bei der Implementierung angelegt worden sein. (Wichtig: wer später Einstellungen in seiner Produktionsreportsuite ändert, muß die natürlich auch für die Entwicklungsumgebung nachziehen!) Ansonsten kann man seinen Account Manager oder ClientCare bitten, eine Kopie der Produktionsumgebung anzulegen.

Testdaten sendet man z.B., indem man sich lokal Webseiten macht. Dazu kann man auf Windows oder Mac XAMPP heranziehen, eine sehr schnell installierte Kombination von Webserver und anderen Tools.

Wie immer beim Testen einer Hypothese („Dieses Segment tut das, was ich erwarte“) ist es sinnvoll, sich vor dem Test zu überlegen, wie das Resultat aussehen sollte. Es ist viel zu einfach, sich hinterher jedes beliebige Ergebnis „zurechtzuerklären“.

Und was tut man, wenn man keine Tests machen kann oder will?

In dem Falle würde man wahrscheinlich zwei Dinge tun:

1. Die Beschreibung der Regeln für das Segment aufschreiben und sie mit einem Kollegen diskutieren. Das könnte ein Entwickler sein, ein anderer Analyst oder meinetwegen der Pförtner. Vier Augen sehen immer mehr als zwei.
2. Zeitraum einschränken. Wer aus dem Wust an Daten einen Tag herauspicken kann, an dem das Segment Daten enthalten müßte, hat einen klaren Vorteil. Wer dann noch einen Tag finden kann, an dem keine Daten im Segment sein dürften, hat zwei Meßpunkte und damit schon gute Chancen, daß der Test aussagekräftig ist, obwohl er auf echten (und damit unkontrollierbaren) Daten stattfindet.

Selbstverständlich ist es immer besser, die Segmente tatsächlich zu testen. Schon meine Großmutter wußte: „Versuch macht kluch!“