Do you build things with AMP? Fill out the AMP Developer Survey!
AMP

Głębokie zanurzenie w analitykę AMP

Ten przewodnik zanurza się głęboko w składnik amp-analytics, rozkładając jego przykładową konfigurację na kluczowe elementy konstrukcyjne.``

W pozostałej części tego przewodnika używana jest ta próbka konfiguracji, śledząca odsłony stron i kliknięcia linków przez użytkownika, a następnie wysyłająca dane analityczne do usługodawcy zewnętrznego, Google Analytics:

<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>

Powyższy przykładowy kod ma pomóc w nauce, ale w żadnym wypadku nie jest to realistyczna próbka. Jeśli pracujesz z dostawcami usług analityki, jest prawdopodobne, że powyższa próbka nie będzie miała sensu; konfiguracje usługodawców usuwają złożoność. Zapoznaj się z konfiguracjami próbek w dokumentacji dostawcy usług analityki.

Dokąd mają być wysyłane dane analityczne: atrybut type

AMP jest przeznaczony do obsługi dwóch popularnych wzorców gromadzenia danych:

  • Przyjęcie przez należący do wydawcy punkt końcowy wewnętrznych systemów analitycznych.
  • Przyjęcie przez należący do dostawcy punkt końcowy na potrzeby współdziałania z rozwiązaniem dostawcy (np. Adobe Analytics, Chartbeat, Google Analytics).

Aby wysyłać dane analityczne do dostawcy usług analityki, należy dodać atrybut type do znacznika amp-analytics i ustawić jego wartość na odpowiedniego dostawcę, zgodnie z definicją na liście Dostawcy usług analityki.

Przykład: znacznik <amp-analytics type="googleanalytics"> wysyła dane analityczne do zewnętrznego dostawcy usług analityki, Google Analytics. Aby wysłać dane do punktu końcowego należącego do wydawcy, po prostu nie dodawaj atrybutu type; dane analityczne będą wysyłane do punktów końcowych zdefiniowanych dla danego żądania.

Konfiguracje dostawców usług analityki to szybki sposób na rozpoczęcie pracy ze składnikiem amp-analytics. W celu uzyskania dalszych wskazówek należy zapoznać się z dokumentacją dostawcy i zasobami pomocy. Jak już wcześniej wspomniano, lista dostawców, którzy już zintegrowali się z AMP, jak również linki do ich dokumentacji znajdują się na liście Dostawcy usług analityki.

Jeśli jesteś dostawcą rozwiązań analitycznych, dowiedz się więcej o integrowaniu własnej konfiguracji analityki z AMP HTML.

Ładowanie konfiguracji zdalnej: atrybut config

Nie musisz dodawać całej konfiguracji składnika amp-analytics jedynie na stronie AMP. Można zamiast tego wywoływać zdalny adres URL całości lub części konfiguracji.

Pozwala to na przykład na zmianę konfiguracji odpowiednio do danego żądania. Jeśli jako wydawca masz kontrolę nad plikiem zdalnym, możesz wykonać dowolne przetwarzanie po stronie serwera niezbędne do skonstruowania danych konfiguracyjnych.

Pierwszym krokiem do ładowania konfiguracji zdalnych jest umieszczenie atrybutu config w znaczniku amp-analytics:

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

Następnym krokiem jest utworzenie zawartości JSON, która znajduje się w zdalnym adresie URL. W tym prostym przykładzie, konfiguracja zawarta w obiekcie JSON jest tylko wartością zmiennej konta analityki.

Przykładowa zawartość w pliku https://example.com/analytics.account.config.json:

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

Ostatnim krokiem jest upewnienie się, że to, co znajduje się w pliku zdalnym, zostanie wciągnięte w odpowiednie miejsce konfiguracji składnika amp-analytics. Tutaj, zarówno w żądaniu pageview i event, automatycznie ustawiana jest wartość zmiennej account równa wartości account w zdalnym adresie URL ("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}"
}

WAŻNE — AMP nie wykonuje walidacji wielokrotnego użycia tej samej zmiennej. Wartości są zapełniane zgodnie z wybraną kolejnością podstawiania zmiennych, a wartości w zdalnych adresach URL są na początku tej kolejności (patrz Kolejność podstawiania zmiennych).

Żądania, wyzwalacze i transporty

Atrybut requests definiuje „które dane są wysyłane” (na przykład pageviews, events) i dokąd dane te są wysyłane (adresy URL używane do przesłania danych).

Atrybut triggers opisuje, kiedy dane analityczne mają być wysyłane, na przykład, gdy użytkownik wyświetli stronę, gdy użytkownik kliknie link.

Atrybut transport określa sposób wysyłania żądania, a dokładniej — protokół.

Czytaj dalej, aby dowiedzieć się więcej o tych konfiguracjach. (Możesz również przeczytać o tych konfiguracjach w dokumentacji referencyjnej składnika amp-analytics

Wysyłane dane: atrybut requests

Wartość atrybutu request-name jest używana w konfiguracji wyzwalacza w celu określenia żądania, które ma zostać wysłane w odpowiedzi na dane zdarzenie. Wartością atrybutu request-value jest adres URL protokołu https. Wartości te mogą zawierać tokeny zastępcze, które mogą odnosić się do innych żądań lub zmiennych.

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

Niektórzy dostawcy usług analityki (w tym Google Analytics) dostarczyli już konfigurację, której używasz za pomocą atrybutu type. Jeśli korzystasz z usług dostawcy usług analityki, dodanie atrybutu requests może nie być konieczne. Sprawdź w dokumentacji dostawcy czy atrybuty requests muszą być skonfigurowane i w jaki sposób.

Dołączanie adresu URL żądania: dodatkowe parametry adresu URL

Atrybut extraUrlParams określa dodatkowe parametry, które należy dołączyć do ciągu znaków żądania w adresie URL zgłoszenia, w zwykłej konwencji "&foo=baz".

Przykładowy składnik amp-analytics dodaje dodatkowy parametr cd1 do żądania i ustawia wartość parametru równą „AMP”:

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

Moment wysyłania danych: atrybut triggers

Atrybut triggers opisuje, kiedy należy wysłać zapytanie analityczne. Zawiera on parę klucz-wartość nazwy wyzwalacza i konfiguracji wyzwalacza. Nazwa wyzwalacza może być dowolnym ciągiem znaków alfanumerycznych (a-zA-Z0-9).

Na przykład następujący element amp-analytics jest skonfigurowany do wysyłania żądania do https://example.com/analytics po pierwszym załadowaniu dokumentu i po każdym kliknięciu znacznika a:

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

WAŻNE — powyższe podejście jest zalecane tylko w przypadku stron AMP, a nie reklam AMPHTML. Priorytet analityki jest niższy w porównaniu z treścią na stronie, więc zalecane jest śledzenie kliknięć przy użyciu przekierowania przeglądarki, aby uniknąć utraty kliknięć.

AMP obsługuje następujące konfiguracje wyzwalaczy:

Konfiguracja wyzwalacza Opis
on (wymagany) Zdarzenie do nasłuchiwania. Prawidłowe są wartości click, scroll, timer i visible.
request (wymagany) Nazwa żądania do wysłania (określona w atrybucie requests).
vars Obiekt zawierający pary klucz-wartość służące do zastępowania zmiennych z sekcji vars zdefiniowanych w konfiguracji górnego poziomu lub do określania zmiennych z sekcji vars unikalnej dla danego wyzwalacza (patrz też Kolejność podstawiania zmiennych).
selector (wymagany, gdy on ma ustawienie click) Selektor CSS używany do zawężania wyboru elementów, które mają być śledzone. Aby śledzić wszystkie elementy, użyj wartości *. Ta konfiguracja jest używana w połączeniu z wyzwalaczem click. Dowiedz się, jak używać selektora do śledzenia kliknięć stron i interakcji społecznościowych.
scrollSpec (wymagany, gdy on ma ustawienie scroll) Kontroluje, w jakich warunkach po przewinięciu strony następuje wygenerowanie zdarzenia scroll. Ten obiekt może zawierać właściwości verticalBoundaries i horizontalBoundaries. Do wygenerowania zdarzenia scroll wymagana jest co najmniej jedna z tych dwóch właściwości. Wartościami obu właściwości powinny być tablice liczb zawierające granice, na których generowane jest zdarzenie przewijania. Zobacz ten przykład śledzenia przewijania.
timerSpec (wymagany, gdy on ma ustawienie timer) Kontroluje moment generowania zdarzenia timer. Zdarzenie timer jest generowane natychmiast, a następnie w określonych odstępach czasu. Ta konfiguracja jest używana w połączeniu z wyzwalaczem timer.

WAŻNE — wyzwalacze z konfiguracji o niższym priorytecie są zastępowane przez wyzwalacze o tych samych nazwach z konfiguracji o wyższym priorytecie (patrz Kolejność podstawiania zmiennych).

Jak są wysyłane dane: atrybut transport

Atrybut transport określa sposób wysyłania żądania. Domyślnie włączone są następujące trzy metody:

Metoda transportu Opis
beacon Wskazuje, że do przesłania żądania można użyć metody navigator.sendBeacon. Wysyłanie jest wówczas żądanie POST z poświadczeniami i pustą treścią.
xhrpost Wskazuje, że do przesłania żądania można użyć metody XMLHttpRequest. Wysyłanie jest wówczas żądanie POST z poświadczeniami i pustą treścią.
image Wskazuje, że żądanie można wysłać, generując znacznik Image. Wysyłanie jest wówczas żądanie GET.

Używany jest tylko jeden sposób transportu i jest to ten o najwyższym priorytecie, który jest włączony, dozwolony i dostępny. Pierwszeństwo: beacon > xhrpost > image. Jeśli program użytkownika klienta nie obsługuje danej metody, używana jest następna włączona metoda o najwyższym priorytecie.

Atrybut transport dodaj do konfiguracji tylko wtedy, gdy chcesz ograniczyć opcje transportu, w przeciwnym razie możesz zatrzymać żądania.

W poniższym przykładzie meotdy beacon i xhrpost mają ustawienie false, więc nie będą one używane, mimo że mają wyższy priorytet niż metoda image. Jeśli program użytkownika klienta obsługuje metodę image, zostanie ona użyta; w przeciwnym razie nie zostanie wysłane żadne żądanie.

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

Kolejność podstawiania zmiennych

AMP wypełnia zmienne wartościami w kolejności ich pierwszeństwa:

  1. Konfiguracje zdalne (za pomocą elementu config).
  2. Zmienne vars osadzone w wyzwalaczu w atrybucie triggers.
  3. Zmienne vars na najwyższym poziomie zagnieżdżone w elemencie amp-analytics.
  4. Wartości dostarczone przez platformę.

Ten przykład zawiera konfigurację zdalną, zmienne zdefiniowane na najwyższym poziomie, w wyzwalaczach i na poziomie platformy:

<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>

Gdy ta sama zmienna var jest zdefiniowana w wielu miejscach, kolejność pierwszeństwa raz ustawia wartość zmiennej. Tak więc, jeśli konfiguracja zdalna zdefiniowała account jako UA-XXXXX-Y w powyższym przykładzie, wartości różnych zmiennych będą następujące:

var Wartość Definiowana przez
canonicalUrl http://example.com/path/to/the/page Platformę
title My homepage Wyzwalacz
account UA-XXXXX-Y Konfigurację zdalną
clientId my user Wyzwalacz