Core Reporting API – Segmente

In diesem Dokument werden die Syntax und Überlegungen zur Verwendung von Segmenten in der Core Reporting API beschrieben.

Es gibt eine aktualisierte Version der Google Analytics Reporting API. Wir empfehlen Ihnen, Ihren Code noch heute zu migrieren, um von den wichtigsten Funktionen der neuen API zu profitieren.

Einleitung

Wenn Sie die Segmentierungsfunktion der Core Reporting API verwenden, haben Sie zwei Möglichkeiten, ein Segment in der Core Reporting API anzufordern:

1. Segmente nach ID: Abfrage mithilfe der numerischen ID eines integrierten oder benutzerdefinierten Segments.
2. Dynamische Segmente: Geben Sie das Segment zum Zeitpunkt der Anfrage dynamisch an.

Weitere Informationen zur Funktionsweise von Segmenten und zu ähnlichen Konzepten finden Sie in der Referenz zu Segmentfunktionen und in der Hilfe zu Segmenten.

Segmentierung nach ID

Sie können ein Segment in der Core Reporting API über die ID eines integrierten oder benutzerdefinierten Segments anfordern. Alle für einen Nutzer verfügbaren Segmente können mit der Methode list der Segmentsammlung in der Google Analytics Management API abgerufen werden. Für jedes Segment ist die ID im Attribut id der Segmentressource verfügbar.

Weitere Informationen zur Verwendung von Segment-IDs in API-Anfragen finden Sie in der Core Reporting API-Referenz.

Dynamische Segmente

Sie können ein Segment auch dynamisch erstellen und verwenden, wenn Sie eine API-Anfrage stellen. In der Regel sollten Sie beim Erstellen eines dynamischen Segments Folgendes berücksichtigen:

1. Unterschied zwischen „Nutzer“ und „Sitzungen“
2. Bedingungen und Sequenzen im Vergleich
3. Messwertbereiche verwenden

Jeder Aspekt beim Erstellen eines dynamischen Segments wird im Folgenden zusammenfassend beschrieben. Die vollständige Syntax für dynamische Segmente finden Sie in der Syntaxreferenz für dynamische Segmente.

Dimensionen und Messwerte, die in Segmenten zulässig sind.
Nicht alle Dimensionen und Messwerte können in Segmenten verwendet werden. Welche Dimensionen und Messwerte in Segmenten zulässig sind, sehen Sie im Dimensions and Metrics Explorer.

1. Auswahl von „Nutzer“ und „Sitzungen“

Geben Sie an, ob Sie Nutzer oder Sitzungen (oder beides) auswählen möchten.

• Verwenden Sie users::, um Nutzer auszuwählen.
• sessions:: verwenden, um Sitzungen auszuwählen.
• Wenn Bedingungen sowohl für users:: als auch für sessions:: angegeben sind:
  1. Die Nutzerbedingungen werden zuerst angewendet, um die Sitzungen für die übereinstimmenden Nutzer auszugeben.
  2. Sitzungsbedingungen werden nur auf Sitzungen von Nr. 1 angewendet.

Hinweis: Nutzer- und Sitzungsbedingungen können nur mit dem UND (also ';')-Operator.

Beispiel:

• Wählen Sie Nutzer aus, die in mindestens einer Sitzung den Chrome-Browser verwendet haben.
  • users::condition::ga:browser==Chrome
• Wählen Sie Sitzungen aus, in denen der Chrome-Browser verwendet wurde.
  • sessions::condition::ga:browser==Chrome
• Wählen Sie Sitzungen aus der Stadt London von Nutzern aus, die mindestens eine Sitzung mit dem Chrome-Browser hatten.
  • users::condition::ga:browser==Chrome;sessions::condition::ga:city==London

Weitere Informationen zur Auswahl von Nutzern und Sitzungen finden Sie im Abschnitt conditionScope der Syntaxreferenz.

2. Bedingungen im Vergleich zu Sequenzen verwenden

Nachdem Sie festgelegt haben, ob Sie Nutzer oder Sitzungen segmentieren möchten, geben Sie eine oder mehrere Bedingungen und/oder Sequenzen an.

Bedingungen

Für Bedingungen wird das Präfix condition:: verwendet. Beispiel:

• Wählen Sie Nutzer aus London aus, die Ihre Website mit dem Chrome-Browser besucht haben.
  • users::condition::ga:city==London;ga:browser==Chrome

Sequenzen

Sequenzbedingungen bestehen aus einem oder mehreren Schritten, wobei jeder Schritt durch eine oder mehrere Dimensions-/Messwertbedingungen definiert wird.

Geben Sie sequenzbasierte Bedingungen mit dem Präfix sequence:: und den Operatoren gefolgt von (;–>>) oder unmittelbar (;–>) an. Beispiel:

• Wählen Sie Nutzer aus, die zuerst einen Computer und dann ein Mobilgerät verwendet haben. Da wir Nutzer segmentieren, wird in allen Sitzungen eines Nutzers gesucht und es wird geprüft, ob ein Nutzer in einer Sitzung einen Computer und in einer der nachfolgenden Sitzungen ein Mobilgerät verwendet hat.
  • users::sequence::ga:deviceCategory==desktop;->>ga:deviceCategory==mobile
• Sie können für jeden Schritt auch mehrere Bedingungen verwenden.
  • users::sequence::ga:deviceCategory==desktop;ga:operatingSystem==Windows->>ga:deviceCategory==mobile;ga:operatingSystem==Android
• Bedingungen und Sequenzen lassen sich auch mithilfe von UND (d.h. „;“).
  • users::condition::ga:totalEvents>10;sequence::ga:deviceCategory==desktop->>ga:deviceCategory==mobile

Weitere Informationen zu einfachen und sequenzbasierten Bedingungen finden Sie im Abschnitt conditionType der Syntaxreferenz. Weitere Beispiele finden Sie in den Abschnitten Bedingungen und Sequenzen der Referenz zu Segmentfunktionen.

3. Messwertbereiche verwenden

Der Umfang eines Messwerts definiert die Ebene, auf der dieser Messwert definiert ist – HIT, SESSION oder USER. Beispielsweise sind ga:pageviews und ga:transactions Messwerte auf HIT-Ebene, da sie in einem Treffer vorkommen. ga:sessionDuration und ga:bounces sind Messwerte auf SESSION-Ebene, da pro Sitzung ein einzelner Wert dafür vorhanden ist. Konzeptionell ist USER der Bereich der höchsten Ebene und HIT die unterste Ebene.

Messwerte können auch in Bereichen gemeldet werden, die größer als der primäre Bereich sind. Beispiel: ga:pageviews und ga:transactions können auf SESSION- und NUTZERebene erfasst werden. Dazu werden sie einfach für jeden Treffer in diesen Sitzungen oder für diese Nutzer addiert.

Sie können den Umfang für jede Messwertbedingung angeben, um die Ebene festzulegen, auf der diese Bedingung angewendet wird. Messwertbereiche werden mit dem Präfix perUser::, perSession:: oder perHit:: angegeben.

Beispiel:

• Wählen Sie Nutzer aus, die mindestens 10 € auf einer Website ausgegeben haben (z.B. Lifetime-Wert eines Nutzers mindestens 10 € beträgt).

  users::condition::perUser::ga:transactionRevenue>=10
  

• Wählen Sie Nutzer aus, die bei einer Sitzung mindestens 10 $ausgegeben haben.

  users::condition::perSession::ga:transactionRevenue>=10
  

Bereichseinschränkungen

Die Core Reporting API führt eine Validierung für Messwertbereiche durch, um sicherzustellen, dass die angegebene Abfrage gültig ist. Für die Überprüfung des Bereichs gelten folgende Regeln:

1. Der angegebene Messwertbereich muss immer gleich oder kleiner als der übergeordnete Bedingungsbereich sein (wie durch das Präfix users:: oder sessions:: angegeben).
2. Der angegebene Messwertbereich muss gleich oder größer als der primäre Bereich sein, der im Datenmodell definiert ist. Eine vollständige Liste der Messwerte mit ihren primären Bereichen finden Sie unter Messwerte: Referenz für primären Bereich.

Beispiele für gültige Messwertbereiche:

• Sowohl Bedingungs- als auch Messwertumfang sind gleich (d.h. NUTZERebene).
  • users::condition::perUser::ga:transactionRevenue>10
• Der Bedingungsumfang ist größer als der Messwertumfang (d.h. NUTZER > SITZUNG).
  • users::condition::perSession::ga:transactionRevenue>10
• ga:totalEvents ist ein Messwert auf HIT-Ebene. Daher sind die möglichen Bereiche dafür in einer Bedingung perHit::, perSession:: oder perUser:: (da alle größer oder gleich dem Bereich auf HIT-Ebene sind).
  • users::condition::perHit::ga:totalEvents>5
  • users::condition::perSession::ga:totalEvents>5

Beispiele für ungültige Messwertbereiche:

• Das folgende Segment ist ungültig, da der übergeordnete Bedingungsumfang kleiner ist als der Messwertbereich (d.h. SESSION < USER).
  • sessions::condition::perUser::ga:transactionRevenue>10
• Verwendung eines Umfangs auf HIT-Ebene für einen Messwert auf der SESSION-Ebene und mit einem HIT-Level < SESSION-Ebene.
  • users::condition::perHit::ga:sessionDuration>60

Bei allen Abfragen mit ungültigen Bereichen wird der Fehler 400 Bad Request zurückgegeben.

Standardbereich

Wenn ein Bereich für eine Messwertbedingung nicht explizit angegeben ist, wird standardmäßig der Bedingungsbereich verwendet. Das folgende Segment verwendet beispielsweise einen Umfang auf NUTZER-Ebene für alle Messwertbedingungen: users::condition::ga:transactionRevenue>=10;ga:sessionDuration>60

Syntaxreferenz für dynamische Segmente

Basissyntax

Die Syntax zum Definieren eines Segments lautet: segment=<segmentCondition>+. Mit anderen Worten: Ein Segment besteht aus einer oder mehreren segmentCondition-Anweisungen.

Ein <segmentCondition> ist so definiert: <conditionScope><conditionType><dimensionOrMetricConditions>

Dabei gilt:
conditionScope gibt den obersten Geltungsbereich der Bedingung(en) an.
conditionType gibt den Typ der Bedingung(en) an.
dimensionOrMetricConditions gibt Dimensions-/Messwertbedingungen oder Sequenzschritte an.

conditionScope

Gibt den übergeordneten Geltungsbereich der Bedingung(en) an. Die möglichen Werte sind:

• users:: zum Auswählen von Nutzern.
• sessions:: zum Auswählen von Sitzungen.

Einschränkungen und Überlegungen für conditionScope:

• Sind in einem Segment mehrere Bedingungen vom Typ „Nutzer“ und „Sitzungen“ angegeben, müssen diese mit einem UND-Operator kombiniert werden.
• Bedingungen, bei denen sowohl Nutzer als auch Sitzungen ausgewählt werden, müssen außerdem mit einem UND-Operator kombiniert werden. Wenn Bedingungen sowohl für Nutzer als auch für Sitzungen angegeben sind, werden zuerst alle Nutzerbedingungen angewendet, um die übereinstimmenden Nutzer zu finden, gefolgt von allen Sitzungsbedingungen in den Sitzungen, die zu diesen übereinstimmenden Nutzern gehören.
• Wenn Sie Bedingungen auf Nutzerebene verwenden, darf der Zeitraum nicht länger als 90 Tage sein.
• Der Bedingungsumfang bestimmt auch die Standardebene für alle Messwertbedingungen darunter. Weitere Informationen zu den Bereichsebenen finden Sie unter Messwerte: Referenz zum primären Bereich.

conditionType

Gibt den Typ der Bedingung(en) an. Die möglichen Werte sind:

• condition:: zum Angeben einfacher (d.h. nicht sequenzbasierter) Bedingungen.
• sequence:: zum Angeben sequenzbasierter Bedingungen.

Einschränkungen und Überlegungen für conditionType:

• Wenn mehrere „einfache Bedingungen“ und „Sequenzen“ angegeben sind, müssen diese immer mit einem UND-Operator kombiniert werden.
• Pro Segment sind maximal 10 Schritte für sequenzbasierte Bedingungen zulässig.

Einfache Bedingungen

Einfache Bedingungen bestehen aus einer oder mehreren Dimensions-/Messwertbedingungen, die kombiniert werden können.

Gültige Bedingungsoperatoren für einfache Bedingungen sind:

• Bedingungen mit AND- oder OR-Operatoren kombinieren.
• Operatoren von Dimensionen und Messwerten

Die Syntax für einfache Bedingungen lautet:

condition::<dimensionOrMetricConditions>

Beispiele für einfache Bedingungen:

• users::condition::ga:transactionRevenue>10;ga:sessionDuration>60
• Es kann ein Negationsoperator der obersten Ebene angegeben werden, um die Komplementärzahl einer einfachen Bedingung zu ermitteln, die mehrere Dimensions-/Messwertbedingungen enthalten kann. Beispiel: users::condition::!ga:transactionRevenue>10;ga:sessionDuration>60

Bedingungen ausschließen

Eine Ausschlussbedingung wird verwendet, um ein Segment zu erstellen, das die definierte Bedingung nicht erfüllt.

In der Syntax wird der NOT-Operator (das Zeichen !) verwendet, um eine Bedingung zu negieren und die Sitzungen auszuschließen, die dieser Bedingung entsprechen.

Sitzungen ausschließen, bei denen die Ausstiegsseite genau mit dem Pfad der Stammseite übereinstimmt:
sessions::condition::!ga:exitPagePath==/

Mehrere Bedingungen

Sie können entweder alle Bedingungen auf Nutzerebene unter einem einzigen users::-Präfix gruppieren oder für jede Bedingung ein separates users::-Präfix verwenden. Dasselbe gilt für Bedingungen auf Sitzungsebene.

Die folgenden Segmente sind beispielsweise gleichwertig. In beiden Fällen werden condition1 und condition2 AND, um Nutzer auszuwählen:
users::<condition1>;<condition2>
users::<condition1>users::<condition2>

Sequenzbedingungen

Sequenzbedingungen bestehen aus einem oder mehreren Schritten, wobei jeder Schritt durch eine oder mehrere Dimensions-/Messwertbedingungen definiert wird. Mehrere Schritte können mit speziellen Sequenzoperatoren kombiniert werden.

Gültige Sequenzoperatoren für Sequenzbedingungen sind:

• Der Operator –>> gibt an, dass der vorherige Schritt dem nächsten Schritt vorgeht.
• Der Operator –> gibt an, dass der vorherige Schritt dem nächsten Schritt unmittelbar vorausgeht.

Die Syntax für Sequenzbedingungen lautet:

sequence:: NOT? FIRST_HIT_MATCHES_FIRST_STEP? (AND (PRECEDES|IMMEDIATELY_PRECEDES) <step>)*

Wo:

NOT wird dargestellt durch: !

FIRST_HIT_MATCHES_FIRST_STEP wird dargestellt durch: ^

PRECEDES wird dargestellt durch: ;–>>

IMMEDIATELY_PRECEDES wird dargestellt durch: ;–>

step wird dargestellt durch: <dimensionOrMetricConditions>

Beispiele für Sequenzbedingungen:

• users::sequence::ga:deviceCategory==desktop;->ga:deviceCategory==tablet
• Es kann auch ein Negationsoperator der obersten Ebene angegeben werden, um das Komplement einer bestimmten Sequenz zu ermitteln, die mehrere Schritte und/oder Dimensions-/Messwertbedingungen enthalten kann. Beispiel: users::sequence::!ga:deviceCategory==desktop;->ga:deviceCategory==tablet
• Mit dem Operator ^ lässt sich angeben, dass der erste Schritt dem ersten Treffer der ersten Sitzung im angegebenen Zeitraum entspricht. Beispiel: users::sequence::^ga:deviceCategory==desktop;->ga:deviceCategory==tablet

Datum der Sitzungsbedingungen

Segmente unterstützen eine Art von Analyse, bei der die Syntax dateOfSession verwendet wird. In Kombination mit dem Operator „zwischen <>“ können Sie ein Segment auf eine Gruppe von Nutzern beschränken, die eine Sitzung in einem bestimmten Zeitraum gestartet haben. Der maximale Zeitraum für dateOfSession beträgt 31 Tage. Unten finden Sie ein Beispiel für das Datum der Sitzung.

Der Operator „zwischen“ <> wird nur in „dateOfSession“-Ausdrücken unterstützt.

Dimensions- und metrische Bedingungen

Bedingungen kombinieren

Sie können eine oder mehrere Dimensionsbedingungen mit UND kombinieren (d.h. ';') und OR (d.h., „,“), wobei der Operator OR eine höhere Priorität hat.

Die Syntax entspricht der zum Kombinieren von Filtern verwendeten Syntax. Weitere Informationen finden Sie in der Core Reporting API-Referenz unter Filter kombinieren.

Operatoren

In der folgenden Tabelle werden alle verfügbaren Operatoren beschrieben, die in Segmenten verwendet werden können. Außerdem wird angegeben, ob sie für Dimensionen und/oder Messwerte unterstützt werden.

Operator	Beschreibung	In Dimensionsbedingungen unterstützt?	In Messwertbedingungen unterstützt?
==	Gleich oder genau passend.	Ja Z.B.: ga:city==London	Ja Z.B.: ga:adCost==10
!=	Ungleich oder keine genaue Übereinstimmung.	Ja Z.B.: ga:city!=London	Ja Z.B.: ga:adCost!=10
<	Kleiner als.	Ja (nur für numerische Werte). Beispiel: ga:hour<12	Ja Z.B.: ga:adCost<10
<=	Kleiner als oder gleich.	Ja (nur für numerische Werte). Beispiel: ga:hour<=12	Ja Z.B.: ga:adCost<=10
>	Größer als.	Ja (nur für numerische Werte). Beispiel: ga:hour>12	Ja Z.B.: ga:adCost>10
>=	Größer als oder gleich.	Ja (nur für numerische Werte). Beispiel: ga:hour>=12	Ja Z.B.: ga:adCost>=10
<>	Dazwischen (Wert liegt im angegebenen Bereich).^1	Ja (nur für numerische Werte). Beispiel: ga:hour<>1_12	Ja Z.B.: ga:adCost<>10_20
[]	In der Liste (Wert ist einer der aufgeführten Werte).^2	Ja Z.B.: ga:browser[]Chrome|Firefox|Opera	Nein
=@	Enthält eine Teilzeichenfolge.	Ja Z.B.: ga:keyword=@shoes	Nein
!@	Enthält keine Teilzeichenfolge.	Ja Z.B.: ga:keyword!@shoes	Nein
=~	Enthält eine Übereinstimmung mit einem regulären Ausdruck.	Ja Z.B.: ga:keyword=~shoes	Nein
!~	Enthält keine Übereinstimmung mit dem regulären Ausdruck.	Ja Z.B.: ga:keyword!~shoes	Nein

¹Zwischen Operator <>
Ermöglicht das Abfragen von Werten in einem bestimmten Bereich. Die Bereichswerte sind einschließlich und können sowohl für Messwerte als auch für Dimensionen mit numerischen Werten verwendet werden (z.B. ga:hour). Die Mindest- und Höchstwerte im Bereich müssen durch einen Unterstrich getrennt werden.

Syntax:
{dimensionOrMetricName}<>{minValue}_{maxValue}

Beispiel:
Sitzungen auswählen, die zwischen 12 und 23 Stunden stattgefunden haben.
sessions::condition::ga:hour<>12_23

² Im Listenoperator []
Ermöglicht Ihnen das Abfragen von Werten aus einer bestimmten Liste. Sie kann nur mit Dimensionen verwendet werden. Die Liste der Werte muss durch ein „|“-Zeichen getrennt werden. Wenn der Wert ein „|“ enthält, muss er maskiert werden.

Syntax:
{dimensionName}[]{value1}|{value2}|...

Einschränkungen:
Pro in Liste aufgeführten Dimensionsbedingung sind maximal 10 Werte zulässig (z.B. ga:city[]city1|city2|...|city10).

Beispiel:
Sitzungen über die Browser Chrome, Firefox oder Opera auswählen.
sessions::condition::ga:browser[]Chrome|Firefox|Opera

Escapezeichen für Sonderzeichen verwenden

Die Sonderzeichen „,“ und „;“ müssen maskiert werden, wenn sie in Wertausdrücken vorkommen. Beispiel: ga:keyword==nike\,shoes

Weitere Informationen zu Dimensions- und Messwertbedingungen finden Sie in der Referenz zur Core Reporting API.

Einschränkungen

Für Dimensions- und Messwertbedingungen gelten folgende Einschränkungen:

• Maximal 10 Dimensions- oder Messwertbedingungen pro Segment.
• Die maximale Ausdruckslänge für Dimensionsbedingungen beträgt 1.024 Zeichen.

Ältere dynamische Segmente migrieren

Dynamische Legacy-Segmente mit dem Präfix dynamic:: entsprechen Segmenten auf Sitzungsebene mit Dimensions- und Messwertbedingungen in der aktuellen Syntax. Wenn Sie dynamische Legacy-Segmente verwenden, sollten Sie zur neuen Syntax migrieren. Ersetzen Sie dazu das Präfix dynamic:: durch das Präfix sessions::condition::. Die beiden folgenden Segmente sind beispielsweise äquivalent:

dynamic::ga:browser==Chrome
ist gleich:
sessions::condition::ga:browser==Chrome

Hinweis: Das Präfix dynamic:: wurde am 27. März 2014 eingestellt. Es wird empfohlen, so schnell wie möglich zur neuen Syntax zu migrieren.

Beispiele für Segmente

1. Demografisch: Männliche Sprachen sind EN-US, interessieren sich für Spiele und stammen aus Nord-, Mittel- und Südamerika.

Nutzerbasierte Segmente werden zuerst angewendet. Die nutzerbasierte Bedingung gibt also männliche Nutzer mit Interesse an Spielen zurück. Sitzungen, die zu diesen Nutzern gehören, unterliegen dann sitzungsbasierten Bedingungen, um Sitzungen aus Nord-, Mittel- und Südamerika in der Sprache EN-US abzurufen.

users::condition::ga:userGender==Male;users::condition::ga:interestAffinityCategory==Games ; sessions::condition::ga:region==Americas;sessions::condition::ga:language==en-u

2. Verhalten: Nutzer mit mehr als 100 Sitzungen, die in den letzten 7 Tagen nicht besucht wurden, mehr als 2 Transaktionen pro Sitzung ausgeführt und pro Sitzung mehr als 100 Sekunden auf der Website verbracht haben.

users::condition::ga:sessions>100;ga:daysSinceLastSession>=7; perSession::ga:transactions>2;perSession::ga:sessionDuration>100

3. Sitzungen: Wählen Sie Sitzungen aus, bei denen der Browser „Chrome“, das Land „USA“ und die Ausnahmen pro Treffer > 1 UND die Anzahl der Nutzer, deren Ausstiege pro Sitzung < 2 ist.

sessions::condition::ga:browser==Chrome;ga:country==US;perHit::ga:exceptions>1; users::condition::perSession::ga:exits<2

4. Sitzung mit einer Sequenz: Wählen Sie Sitzungen mit „Schritt“ aus: Chrome und Ereignisse pro Treffer insgesamt > 5 UND Nutzer auswählen mit „Schritt“, gefolgt von Schritten: Auf Mobilgeräten.

sessions::sequence::ga:browser==Chrome;condition::perHit::ga:totalEvents>5;users::sequence::ga:deviceCategory==desktop->>ga:deviceCategory=mobile

5. Sitzungsdatum: Wählen Sie Nutzer aus, die zwischen dem 20. Mai 2014 und dem 30. Mai 2014 ihre erste Sitzung hatten und mehr als 600 Sekunden auf der Website verbracht haben.

users::sequence::^ga:sessionCount==1;dateOfSession<>2014-05-20_2014-05-30;->>ga:sessionDurationBucket>600

Messwerte: Referenz für primären Bereich

Messwert	Primärer Bereich
ga:adClicks	HIER
ga:adCost	HIER
ga:adsenseAdsClicks	HIER
ga:adsenseAdsViewed	HIER
ga:adsenseAdUnitsViewed	HIER
ga:adsenseCTR	HIER
ga:adsenseECPM	HIER
ga:adsensePageImpressions	HIER
ga:adsenseRevenue	HIER
ga:avgDomainLookupTime	HIER
ga:avgDomContentLoadedTime	HIER
ga:avgDomInteractiveTime	HIER
ga:avgEventValue	HIER
ga:avgPageDownloadTime	HIER
ga:avgPageLoadTime	HIER
ga:avgRedirectionTime	HIER
ga:avgScreenviewDuration	HIER
ga:avgSearchDepth	HIER
ga:avgSearchDuration	HIER
ga:avgSearchResultViews	HIER
ga:avgServerConnectionTime	HIER
ga:avgServerResponseTime	HIER
ga:avgUserTimingValue	HIER
ga:costPerConversion	HIER
ga:costPerGoalConversion	HIER
ga:costPerTransaction	HIER
ga:CPC	HIER
ga:CPM	HIER
ga:CTR	HIER
ga:domainLookupTime	HIER
ga:domContentLoadedTime	HIER
ga:domInteractiveTime	HIER
ga:domLatencyMetricsSample	HIER
ga:eventValue	HIER
ga:exceptions	HIER
ga:exceptionsPerScreenview	HIER
ga:fatalExceptions	HIER
ga:fatalExceptionsPerScreenview	HIER
ga:goalAbandonRateAll	HIER
ga:goalAbandonsAll	HIER
ga:goalCompletionsAll	HIER
ga:goalStartsAll	HIER
ga:goalValueAll	HIER
ga:goalValueAllPerSearch	HIER
ga:goalXXAbandonRate	HIER
ga:goalXXAbandons	HIER
ga:goalXXCompletions	HIER
ga:goalXXStarts	HIER
ga:goalXXValue	HIER
ga:impressions	HIER
ga:itemQuantity	HIER
ga:itemRevenue	HIER
ga:itemsPerPurchase	HIER
ga:localItemRevenue	HIER
ga:localTransactionRevenue	HIER
ga:localTransactionShipping	HIER
ga:localTransactionTax	HIER
ga:margin	HIER
ga:metricXX	HIER
ga:pageDownloadTime	HIER
ga:pageLoadSample	HIER
ga:pageLoadTime	HIER
ga:pageValue	HIER
ga:pageviews	HIER
ga:percentSearchRefinements	HIER
ga:redirectionTime	HIER
ga:revenuePerItem	HIER
ga:revenuePerTransaction	HIER
ga:ROI	HIER
ga:RPC	HIER
ga:screenviews	HIER
ga:searchDepth	HIER
ga:searchDuration	HIER
ga:searchGoalConversionRateAll	HIER
ga:searchGoalXXConversionRate	HIER
ga:searchRefinements	HIER
ga:searchResultViews	HIER
ga:searchUniques	HIER
ga:serverConnectionTime	HIER
ga:serverResponseTime	HIER
ga:socialActivities	HIER
ga:socialInteractions	HIER
ga:socialInteractionsPerSession	HIER
ga:speedMetricsSample	HIER
ga:timeOnScreen	HIER
ga:totalEvents	HIER
ga:totalValue	HIER
ga:transactionRevenue	HIER
ga:transactions	HIER
ga:transactionShipping	HIER
ga:transactionTax	HIER
ga:uniqueAppviews	HIER
ga:uniqueEvents	HIER
ga:uniquePageviews	HIER
ga:uniquePurchases	HIER
ga:uniqueScreenviews	HIER
ga:uniqueSocialInteractions	HIER
ga:userTimingSample	HIER
ga:userTimingValue	HIER
ga:adsenseExits	ÜBUNG
ga:avgTimeOnPage	ÜBUNG
ga:avgSessionDuration	ÜBUNG
ga:bounces	ÜBUNG
ga:entranceBounceRate	ÜBUNG
ga:entranceRate	ÜBUNG
ga:entrances	ÜBUNG
ga:eventsPerSessionWithEvent	ÜBUNG
ga:exitRate	ÜBUNG
ga:exits	ÜBUNG
ga:goalConversionRateAll	ÜBUNG
ga:goalValuePerSession	ÜBUNG
ga:goalXXConversionRate	ÜBUNG
ga:organicSearches	ÜBUNG
ga:pageviewsPerSession	ÜBUNG
ga:percentSessionsWithSearch	ÜBUNG
ga:screenviewsPerSession	ÜBUNG
ga:searchExitRate	ÜBUNG
ga:searchExits	ÜBUNG
ga:searchSessions	ÜBUNG
ga:sessionDuration	ÜBUNG
ga:transactionRevenuePerSession	ÜBUNG
ga:transactionsPerSession	ÜBUNG
ga:bounceRate	ÜBUNG
ga:sessions	ÜBUNG
ga:sessionsWithEvent	ÜBUNG
ga:newSessions	USER
ga:percentNewSessions	USER
ga:users	USER