Vertiefung von AMP Analytics

Dieser Leitfaden befasst sich eingehend mit der Komponente amp-analytics und zerlegt eine Beispielkonfiguration für amp-analytics in die folgenden Schlüsselbausteine:

In diesem Leitfaden verwenden wir das folgende Konfigurationsbeispiel, welches die Seitenaufrufe und Benutzerklicks auf Links verfolgt und Analysedaten an den Drittanbieter Google Analytics sendet:

<amp-analytics
  type="googleanalytics"
  config="https://example.com/analytics.account.config.json"
>
  <script type="application/json">
    {
      "requests": {
        "pageview": "https://example.com/analytics?url=${canonicalUrl}&title=${title}&acct=${account}",
        "event": "https://example.com/analytics?eid=${eventId}&elab=${eventLabel}&acct=${account}"
      },
      "vars": {
        "account": "ABC123"
      },
      "extraUrlParams": {
        "cd1": "AMP"
      },
      "triggers": {
        "trackPageview": {
          "on": "visible",
          "request": "pageview"
        },
        "trackAnchorClicks": {
          "on": "click",
          "selector": "a",
          "request": "event",
          "vars": {
            "eventId": "42",
            "eventLabel": "clicked on a link"
          }
        }
      },
      "transport": {
        "beacon": false,
        "xhrpost": false,
        "image": true
      }
    }
  </script>
</amp-analytics>

Der oben angeführte Beispielcode soll dich beim Lernen unterstützen, ist aber keineswegs ein realistisches Beispiel. Wenn du Analytics Anbieter nutzt, macht das obige Beispiel höchstwahrscheinlich keinen Sinn, denn Anbieterkonfigurationen entfernen die Komplexität. In der Dokumentation deines Analytics Anbieters findest du Beispielkonfigurationen.

Bestimmungsort für die Analytics Daten: das Attribut "type"

AMP is designed to support two common patterns of data collection:

• Ingestion by a publisher-owned endpoint for in-house analytics systems.
• Ingestion by a vendor-owned endpoint for interoperability with a vendor solution (for example, Adobe Analytics, Chartbeat, Google Analytics).

To send analytics data to an analytics provider, include the type attribute in the amp-analytics tag and set its value to the appropriate vendor, as defind in the Analytics Vendors list.

For example: <amp-analytics type="googleanalytics"> sends analytics data to the third-party analytics provider, Google Analytics. To send data to a publisher-owned endpoint, simply don’t include the type attribute; the analytics data is sent to the defined endpoints for each request.

Analytics vendor configurations are a quick way to get started with amp-analytics. You should consult your vendor’s documentation and help resources for further guidance. As previously mentioned, the list of vendors who’ve already integrated with AMP, as well as links to their specific documentation can be found in the Analytics Vendors list.

Wenn du Analytics Anbieter bist, findest du hier mehr Informationen über die Integration deiner eigenen Analytics Konfiguration in AMP HTML.

Remote Konfiguration laden: das Attribut "config"

Du musst nicht die gesamte Konfiguration für amp-analytics in deine AMP Seite einbinden. Stattdessen kannst du eine Remote URL aufrufen, um einen Teil oder alle der Konfigurationen abzurufen.

This allows you to do things like vary the configuration based on a specific request. If you as the publisher have control over the remote file, you can do any server-side processing necessary to construct the configuration data.

The first step to loading remote configurations is to include the config attribute in the amp-analytics tag:

<amp-analytics
  config="https://example.com/analytics.account.config.json"
></amp-analytics>

Als Nächstes muss der JSON Inhalt erstellt werden, der sich in der Remote URL befindet. In diesem einfachen Beispiel ist die im JSON Objekt enthaltene Konfiguration lediglich der Variablenwert für den Analytics Account.

Beispielinhalt in https://example.com/analytics.account.config.json:

{
  "vars": {
    "account": "UA-XXXXX-Y"  // Replace with your property ID.
  }
}

Der letzte Schritt besteht darin, sicherzustellen, dass die Inhalte der Remote Datei in der Konfiguration für amp-analytics an die gewünschte Stelle abgerufen werden. Sowohl in der Anforderung pageview als auch in event wird hier der Wert der Variablen account dem Wert des Accounts gleichgesetzt, der in der Remote URL angegeben ist ("account": "UA-XXXXX-Y"):

"requests": {
  "pageview": "https://example.com/analytics?url=${canonicalUrl}&title=${title}&acct=${account}",
  "event": "https://example.com/analytics?eid=${eventId}&elab=${eventLabel}&acct=${account}"
}

Requests, Triggers und Transports

Das Attribut requests definiert, welche Daten gesendet werden (z. B. pageviews, events) und wohin diese Daten gesendet werden (d. h. mit welchen URLs die Daten übermittelt werden).

Das Attribut triggers beschreibt, wann Analysedaten gesendet werden sollen, z. B. wenn Benutzer eine Seite ansehen oder auf einen Link klicken.

Das Attribut transport gibt an, wie – also über welches Protokoll – eine Anforderung gesendet werden soll.

Lies weiter, um mehr über diese Konfigurationen zu erfahren. (Informationen zu den Konfigurationen findest du auch in der Referenz zu amp-analytics.

Welche Daten werden gesendet: das Attribut "request"

Das Attribut request-name in der Konfiguration für "trigger" gibt an, welche Anforderung als Antwort auf ein bestimmtes Event gesendet werden soll. Der Wert request-value ist eine https URL. Diese Werte können Platzhaltertoken enthalten, die auf andere Anforderungen oder Variablen verweisen können.

"requests": {
  "pageview": "https://example.com/analytics?url=${canonicalUrl}&title=${title}&acct=${account}",
  "event": "https://example.com/analytics?eid=${eventId}&elab=${eventLabel}&acct=${account}"
}

Einige Analytics Anbieter (einschließlich Google Analytics) stellen bereits eine Konfiguration bereit, die du mithilfe des Attributs type verwenden kannst. Wenn du einen Analytics Anbieter nutzt, musst du möglicherweise keine Informationen in Form von requests einbinden. In der Dokumentation deines Anbieters erfährst du, ob und wie requests konfiguriert werden müssen.

Anhang an die URL der Anforderung: das Attribut "extraURLParams"

Das Attribut extraUrlParams gibt zusätzliche Parameter an, die an die Zeichenfolge der Abfrage in der URL der Anforderung angehängt werden. Dazu wird wie gewohnt die Konvention "&foo=baz" verwendet.

Das Beispiel zu amp-analytics fügt der Anforderung den zusätzlichen Parameter cd1 hinzu und setzt den Parameterwert auf "AMP":

  "extraUrlParams": {
    "cd1": "AMP"
  }

Wann Daten gesendet werden: das Attribut "triggers"

Das Attribut triggers beschreibt, wann eine Analytics Anforderung gesendet werden soll. Es enthält das Schlüssel-Wert-Paar "trigger-name" und "trigger-configuration". Der Name des Triggers kann eine beliebige Zeichenfolge sein, die aus alphanumerischen Zeichen besteht (a-zA-Z0-9).

So wird z. B. das folgende Element amp-analytics konfiguriert, um eine Anforderung an https://example.com/analytics zu senden, wenn das Dokument zum ersten Mal geladen wird, und dann jedes Mal beim Anklicken eines Tags a:

"triggers": {
  "trackPageview": {
    "on": "visible",
    "request": "pageview"
  },
  "trackAnchorClicks": {
    "on": "click",
    "selector": "a",
    "request": "event",
    "vars": {
      "eventId": "42",
      "eventLabel": "clicked on a link"
    }
  }
}

AMP unterstützt die folgenden Triggerkonfigurationen:

Wie Daten gesendet werden: das Attribut "transport"

Das Attribut transport gibt an, wie eine Anforderung gesendet werden soll. Die folgenden drei Methoden sind standardmäßig aktiviert:

Es wird nur eine Methode für Transport verwendet: die Methode mit der höchsten Priorität, die aktiviert, zulässig und verfügbar ist. Die Rangfolge ist wie folgt: beacon > xhrpost > image. Wenn der User Agent des Clients eine Methode nicht unterstützt, wird die aktivierte Methode mit der nächsthöheren Priorität verwendet.

Include the transport attribute in your configuration only if you want to limit the transport options, otherwise, you may stop requests.

In the example below, beacon and xhrpost are set to false, so they will not be used even though they have higher precedence than image. If the client's user agent supports the image method, then it will be used; otherwise, no request gets sent.

'transport': {
  'beacon': false,
  'xhrpost': false,
  'image': true
}

Reihenfolge der Variablensubstitution

AMP populates variables with values in an order of precedence:

1. Remote Konfigurationen (über config)
2. vars, verschachtelt in einem Trigger innerhalb von triggers
3. vars der höchsten Ebene, verschachtelt in amp-analytics
4. Von der Plattform bereitgestellte Werte

In this example, there’s a remote configuration, variables defined at the top-level, in triggers, and at the platform level:

<amp-analytics config="http://example.com/config.json">
  <script type="application/json">
    {
      "requests": {
        "pageview": "https://example.com/analytics?url=${canonicalUrl}&title=${title}&acct=${account}&clientId=${clientId(cid-scope)}",
      },
      "vars": {
        "account": "ABC123",
        "title": "Homepage"
      },
      "triggers": {
        "some-event": {
          "on": "visible",
          "request": "pageview",
          "vars": {
            "title": "My homepage",
            "clientId": "my user"
          }
      }
    }
  </script>
</amp-analytics>

When the same var is defined in multiple locations, the variable order of precedence sets its value once. Thus, if the remote configuration defined account as UA-XXXXX-Y in the example above, the values of various vars will be as follows: