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 is designed to support two common patterns of data collection:
- Przyjęcie przez należący do wydawcy punkt końcowy wewnętrznych systemów analitycznych.
- 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.
If you’re an analytics vendor, learn more about integrating your own analytics configuration into 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"
></amp-analytics>
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}"
}
Żą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"
}
}
}
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 . |
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:
- Konfiguracje zdalne (za pomocą elementu
config
). - Zmienne
vars
osadzone w wyzwalaczu w atrybucietriggers
. - Zmienne
vars
na najwyższym poziomie zagnieżdżone w elemencieamp-analytics
. - 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>
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:
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 |