Approfondimenti su AMP Analytics
Important: this documentation is not applicable to your currently selected format ads!
Questa guida si addentra nella sfera del amp-analytics
, scomponendo una configurazione campione di amp-analytics
in questi blocchi predefiniti:
Il resto di questa guida usa il campione di configurazione, che consente di monitorare le visualizzazioni di pagina e i clic dell’utente sui link e inviare i dati di analisi al fornitore di terze parti, 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>
Nota: il codice dell’esempio sopra è stato creato per aiutarti a capire ma non costituisce assolutamente un campione realistico. Se collabori con fornitori di strumenti di analisi, è probabile che il campione sopra non abbia senso, in quanto le configurazioni dei fornitori eliminano le complessità. Per le configurazioni di esempio fai riferimento alla documentazione del tuo fornitore di strumenti di analisi.
Dove inviare i dati di analisi: attributo 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.
If you’re an analytics vendor, learn more about integrating your own analytics configuration into AMP HTML.
Caricamento della configurazione remota: attributo config
Non hai bisogno di includere tutta la configurazione per amp-analytics
nella tua pagina AMP. Al contrario, puoi richiamare un URL remoto per la totalità o per parte delle configurazioni.
Questo ti consente di eseguire operazioni come la modifica della configurazione in base a una richiesta specifica. Se in quanto editore hai il controllo sul file remoto, puoi eseguire qualsiasi operazione di elaborazione necessaria sul lato server per costruire i dati di configurazione.
Il primo passo per caricare le configurazioni remote è quello di includere l’attributo config nel tag amp-analytics
:
<amp-analytics
config="https://example.com/analytics.account.config.json"
></amp-analytics>
Il passo successivo è quello di creare il contenuto JSON che risiede nell’URL remoto. In questo semplice esempio, la configurazione contenuta nell’oggetto JSON è semplicemente il valore della variabile per l’account di analisi.
Contenuto di esempio in https://example.com/analytics.account.config.json
:
{
"vars": {
"account": "UA-XXXXX-Y" // Replace with your property ID.
}
}
Il passo finale è quello di verificare che il contenuto del file remoto sia inserito nel punto corretto nella configurazione amp-analytics
. Qui, in entrambe le richieste pageview
e event
, il valore della variabile account
è automaticamente impostato sul valore dell’account nell’URL remoto ("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}"
}
Importante. AMP non consente la convalida rispetto a più usi della stessa variabile. I valori vengono inseriti seguendo un ordine di preferenza di sostituzione delle variabili e i valori negli URL remoti sono all’inizio di tale ordine (vedi Ordinamento della sostituzione delle variabili).
Richieste, attivazioni e trasferimenti
L’attributo requests
definisce ‘quali dati vengono inviati’ (ad esempio, pageviews
, events
) e dove vengono inviati (gli URL utilizzati per trasmettere i dati).
L’attributo triggers
indica quando devono essere inviati i dati di analisi, ad esempio, quando un utente visualizza una pagina o quando un utente fa clic su un link.
L’attributo transport
specifica come inviare una richiesta, più in particolare, il protocollo.
Più avanti puoi ottenere ulteriori informazioni su queste configurazioni (puoi anche approfondire queste configurazioni nel riferimento amp-analytics
.
Quali dati vengono inviati: attributo requests
Il valore request-name
viene utilizzato nella configurazione di attivazione per specificare quale richiesta deve essere inviata in risposta a un particolare evento. Il valore request-value
è un URL https
. Questi valori possono includere token segnaposto che fanno riferimento ad altre richieste o variabili.
"requests": {
"pageview": "https://example.com/analytics?url=${canonicalUrl}&title=${title}&acct=${account}",
"event": "https://example.com/analytics?eid=${eventId}&elab=${eventLabel}&acct=${account}"
}
Alcuni fornitori di strumenti di analisi (compreso Google Analytics) hanno già fornito la configurazione da utilizzare tramite l’attributo type
. Se stai usando un fornitore di strumenti di analisi, è possibile che non sia necessario includere le informazioni requests
. Fai riferimento alla documentazione del tuo fornitore per sapere se occorre configurare l’attributo requests
ed eventualmente come configurarlo.
Aggiunta di URL di richiesta: Extra URL Params
L’attributo extraUrlParams specifica i parametri supplementari da aggiungere alla stringa di query dell’URL di richiesta tramite la solita convenzione "&foo=baz".
L’esempio amp-analytics
aggiunge un ulteriore parametro cd1
alla richiesta e imposta il valore del parametro su "AMP":
"extraUrlParams": {
"cd1": "AMP"
}
Quando vengono inviati i dati: attributo triggers
L’attributo triggers
descrive quando deve essere inviata una richiesta di analisi. Contiene una coppia chiave-valore di nome-trigger e configurazione-trigger. Il nome trigger può essere qualsiasi stringa costituita da caratteri alfanumerici (a-zA-Z0-9).
Ad esempio, il seguente elemento amp-analytics
è configurato per inviare una richiesta a https://example.com/analytics
quando il documento viene caricato per la prima volta e ogni volta che viene fatto clic su un tag a
:
"triggers": {
"trackPageview": {
"on": "visible",
"request": "pageview"
},
"trackAnchorClicks": {
"on": "click",
"selector": "a",
"request": "event",
"vars": {
"eventId": "42",
"eventLabel": "clicked on a link"
}
}
}
AMP supporta le seguenti configurazioni di attivazione:
Trigger Config | Descrizione |
---|---|
on (obbligatorio) | L’evento per cui invocare il listener. I valori validi sono click , scroll , timer e visible . |
request (obbligatorio) | Nome della richiesta da inviare (come specificato nelle richieste). |
vars | Un oggetto contenente le coppie chiave-valore usate per eseguire l’override delle vars definite nella configurazione di primo livello o per specificare vars univoche a questo trigger (vedi anche Ordinamento della sostituzione delle variabili). |
selector (obbligatorio quando on è impostato su click ) | Un selettore CSS utilizzato per definire meglio quali elementi devono essere monitorati. Usa il valore * per monitorare tutti gli elementi. Questa configurazione viene utilizzata insieme al trigger click . Scopri come usare il selettore per monitorare i clic di pagina e per le interazioni sui social. |
scrollSpec (obbligatorio quando on è impostato su scroll ) | Controlla in base a quali condizioni viene attivato l’evento scroll quando l’utente scorre la pagina. Questo oggetto può contenere verticalBoundaries e horizontalBoundaries . Per l’attivazione di un evento scroll è necessaria almeno una delle due proprietà. I valori per entrambe le proprietà devono essere serie di numeri contenenti i limiti entro i quali viene generato un evento di scorrimento. Vedi questo esempio sul monitoraggio dello scorrimento. |
timerSpec (obbligatorio quando on è impostato su timer ) | Controlla quando viene attivato l’evento timer . Il timer si attiva immediatamente e successivamente a intervalli specifici. Questa configurazione viene utilizzata insieme al trigger timer . |
Come vengono inviati i dati: attributo transport
L’attributo transport
specifica come inviare una richiesta. I seguenti tre metodi sono abilitati per impostazione predefinita: Viene utilizzato solo un metodo di trasferimento ed è quello abilitato, consentito e disponibile con la precedenza più alta. La precedenza è beacon
> xhrpost
> image
. Se l’agente utente del client non supporta un metodo, viene utilizzato il metodo successivo abilitato con la precedenza più alta.
Metodo di trasferimento | Descrizione |
---|---|
beacon | Indica che navigator.sendBeacon può essere utilizzato per trasmettere la richiesta. Viene inviata una richiesta POST , completa di credenziali, con il corpo del testo vuoto. |
xhrpost | Indica che XMLHttpRequest può essere utilizzato per trasmettere la richiesta. Viene inviata una richiesta POST , completa di credenziali, con il corpo del testo vuoto. |
image | Indica che la richiesta può essere inviata generando un tag Image . Questo invia una richiesta GET . |
Include l’attributo transport
nella configurazione solo se si desidera limitare le opzioni di trasferimento, in caso contrario si possono interrompere le richieste.
Nell’esempio di seguito, beacon
e xhrpost
sono impostati su false, in modo tale da non essere utilizzati anche se hanno una precedenza più alta rispetto a image
. Se l’agente utente del client supporta il metodo image
, verrà utilizzato, in contrario non sarà inviata alcuna richiesta.
AMP inserisce le variabili con i valori in ordine di precedenza:
'transport': {
'beacon': false,
'xhrpost': false,
'image': true
}
Ordinamento della sostituzione delle variabili
In questo esempio sono presenti una configurazione remota, variabili definite al primo livello, nei trigger e a livello della piattaforma:
- Configurazioni remote (tramite
config
). vars
nidificate all’interno di un trigger intriggers
.vars
al primo livello nidificate inamp-analytics
.- Valori forniti dalla piattaforma.
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:
var | Valore | Definito da |
---|---|---|
canonicalUrl | http://example.com/path/to/the/page | Piattaforma |
title | My homepage | Trigger |
account | UA-XXXXX-Y | Configurazione remota |
clientId | my user | Trigger |