SERVER-SIDE HOSTING

Il contenitore Server stesso ricorda visivamente qualsiasi contenitore di Google Tag Manager.

La differenza principale è il nuovo tipo di asset del cliente che puoi vedere nel menu a sinistra.

Quando si utilizza il termine richiesta HTTP in entrata , ci riferiamo alla richiesta HTTP inviata da un dispositivo o browser al contenitore Server. Quando si utilizza il termine richiesta HTTP in uscita , ci riferiamo invece alla richiesta HTTP creata e inviata dai tag che si attivano nel contenitore.

Tag

In riferimento ai tag attualmente disponibili, ci sono i modelli nativi Universal Analytics, GA4, Google ADS e poco più, tutti configurati per assimilare i dati inviati dai rispettivi “client”; Il tag di richiesta HTTP ti consente di creare una richiesta HTTP in uscita verso qualsiasi destinazione.

Inoltre possiamo trovare tag personalizzati da creare “ad hoc”; quasi tutti i servizi che accettano richieste HTTP possono essere configurati in un modello di tag personalizzato nel contenitore Server.

Trigger

Il contenitore Server contiene i seguenti trigger: “Visualizzazione pagina”, “Evento Personalizzato” e “Personalizzato”.

Un contenitore Server non è inoltre correlato alle etichette lato client come “caricamento pagina” o “carico contenitore”. È sempre in esecuzione – non viene ripristinato quando la pagina viene aggiornata. Quindi non ci sono trigger relativi al ciclo di vita di un contenitore Server, anche se ciò non significa che, prima o poi, non ci saranno.

Questi possono essere usati per analizzare le informazioni sulla richiesta in arrivo e per recuperare i metadati sull’evento che si è attivato e sul contenitore stesso.

Nella configurazione del Cloud Server si consiglia vivamente di eseguire il mapping di un dominio (di terzo livello) personalizzato all’endpoint del contenitore del server.

Il motivo principale è che in questo modo sarà possibile incorporare l’endpoint di raccolta dati lato server dei nomi di dominio proprietario; ad esempio, noi usiamo “gtm.groweb.it” come host del contenitore Server.

Questo diventa significativo se si considerano cose come la prevenzione del rilevamento intelligente (ITP).

Potremmo voler utilizzare i cookie nelle richieste in arrivo, ma se il contenitore del Server è ospitato su un dominio diverso da quello in cui vengono inviate le richieste (come il nostro sito), questi cookie saranno considerati cookie di terze parti e quindi trascurati da molti browser.

Inoltre a seguito degli ultimi aggiornamenti relativi all’ITP, è consigliabile mappare il dominio come un sottodominio appena verificato; in questo modo verrà chiesto di utilizzare i record DNS A/AAAA anziché il CNAME.

Allo stesso modo, avere l’endpoint nello spazio dei nomi di dominio di prima parte significa che sarà possibile impostare i cookie proprietari con le intestazioni di Set-Cookie e quindi evitare che Safari e Firefox li facciano scadere entro 7 giorni.

Il contenitore Server, proprio come un contenitore Web, ha la propria modalità Anteprima e Debug.

Quando si fa clic sul pulsante “anteprima” nell’interfaccia utente, si apre una nuova scheda con l’interfaccia di anteprima.

Proprio come con un contenitore web, la scheda anteprima mostra solo gli hit che provengono dal browser e deve essere la stessa istanza del browser che ha avviato la modalità anteprima.

Nella navigazione a sinistra, troviamo tutte le richieste HTTP in entrata.

Selezionando una richiesta , tutte le schede in modalità anteprima si comporteranno come se avessimo selezionato riepilogo; in altre parole, potremo vedere quante volte un tag è stato attivato per la richiesta, ma non possiamo esaminare le variabili o i dati dell’evento.

Per questo motivo, ogni volta che facciamo il debug, dovremmo scegliere l’oggetto dei dati dell’evento (ad esempio “page_view”) se disponibile.