@juanin ecco bravo perche io GA4 per ora l'ho aperto solo due volte e sono mooolto indietro , ottimo grazi ancora di più!

Ciao @shazarak

vedrò poi se li inserisce in una categoria automaticamente, o se li devo inserire manualmente, in questo caso gli do categoria necessari giusto?
(su cookiebot ci sono queste categorie: necesssari, preferente, statistici, marketing, non classificati)

Dipende da impostazione stream GA4 in dashboard Host + impostazioni payload :

• In dashboard Host impostato solo measurement_id : Necessari = in tal caso gli endpoint measurement-server GA ricevono solo parametri parziali e compatibili con le indicazioni GPDP per il rientro tra strumenti tecnici/necessari.

• In dashboard Host impostati measurement_id + api_secret : Statistici = in tal caso gli endpoint measurement-server GA ricevono tutti i parametri e devi comunque prevedere la gestione del consenso in merito a raccolta & trattamento dati (ved. anche note relative di Google in pannello creazione/gestione API Secret).

.
Nel secondo caso ovviamente dovrai anche verificare / prevedere le condizioni di esenzione dati per la conformità di trattamento cross-border dati ex GDPR + Schrems II = il disaccoppiamento dell'inoltro payload agli endpoint measurement-server GA è condizione necessaria di conformità, ma non sufficiente.

Tradotto in pratica, verificare p.es. con la checklist delle indicazioni fornite da CNIL per le proxyficazioni GA conformi, rimuovendo / inibendo parametri payload e/o configurazioni di data-sharing / cross-link, che comportino criticità con le attuali disposizioni.

@raw ha detto in Integrazione con cookiebot ( o simili ):

indicazioni fornite da CNIL per le proxyficazioni GA conformi

e da bella giornata di sole sono finito a gran mal di testa allegria ahha

a parte gli scherzi, ok grazie per le precisazioni!

@raw api secret e measurement id sono necessari per poter mandare HIT a GA4. Solo con uno dei due non può funzionare. Diverso invece il connettore Universal.

Sul resto invece passando NPA a true di fatto vengono azzerate tutte le configurazioni di data sharing.

O forse parliamo di due cose diverse.

Ciao @juanin

api secret e measurement id sono necessari per poter mandare HIT a GA4. Solo con uno dei due non può funzionare

Con l'impostazione del solo measurement_id in dashboard Host per GA4 ho riscontrato che arrivano comunque i dati per alcune dimensioni di eventi / pageview.

Con tale impostazione parziale, dopo la response {"status":true} all'invio del payload all'endpoint /v1/ibriditics non vi è infatti stop perentorio di inoltro successivo del payload processato agli endpoint measurement-server GA - come invece avviene se p.es. si procede lato client ad alcuni override dello script js, e.g. personalizzazione dei cid e del loro expiry [1].

.
Lato Host parte comunque un inoltro. Infatti - controllando prima da real-time e poi da report/esplora - risultano e.g.

• URL/Percorsi pagine
• Località livello country (livello city not_set se country != IT, altrimenti geolocalizza su Torino) [2]
• Eventi page_view - session_start - first_visit

Quando l'ho riscontrato, ho pensato che fosse un semplice caso "It's Not a Bug, It's a Feature".

Ho infatti ritenuto fosse comunque intenzionale, onde consentire appunto l'impostazione proxyficata GA in equivalenza categoria strumenti tecnici / necessari senza obbligo richiesta di consenso (cosa che non è possibile invece, impostando API Secret, come indicato anche da Google stessa).

Note :

[1] Visto che - in questa fase della Public Beta - le opzioni di personalizzazione lato Dashboard non sono state ancora implementate, ho comunque effettuato alcuni test di verifica override tramite locally-hosted script (codice d'esempio) per :

• variazione algoritmo generazione cid (onde aumentarne grado di collisione, ved. raccomandazioni EPDB)
• variazione della durata di validità (riduzione da 1 anno ad 1 mese)
• variazione cookie base domain per siti su sottodomini

Se ad esempio la sintassi degli UUID non corrisponde a quella definita dalle function uuid() e uuid4() causa uso di diverso algortimo di codifica hash (tra quelli supportati lato measurement-server GA per la registrazione come e.g. cyrb53), si ha response ok da endpoint Host /v1/ibriditics con inoltro OK per GA4 - KO per UA/GA3.
.
[2] Nell'ambito di controlli dual-tracking UA/GA3+ GA4, verificando tracking UA/GA3 impostati per siti in dashboard Host, tutti gli accessi risultano provenire da IT - Torino...

Come se non venisse comunque processato correttamente il parametro client IP - anonimizzato Lvl2 (azzeramento ultimi 2 ottetti client IP IPv4 / ultimi 5 ottetti IP IPv6) nell'inoltro successivo del payload UA/GA3 processato.

Per i GA4 stream contemporanei si ha invece una situazione simile, ma appunto impostando solo measurement_id in dashboard Host.

In questo caso non so quanto sia intenzionale una tale situazione, per cui aspettavo la disponibilità dei raw-data in uscita da Host verso endpoint GA. onde verificare effettivamente il processo dei payload lato Host.

@raw non mi torna quanto dici.

Forse hai un tag js di Google diretto da qualche parte perché Host analytics non manda in alcun modo eventi come session_start che sono riservati e usabili solo da gtag.js.

Riguardo all'API secret questo è obbligatorio. Senza non può funzionare.

Se ci condividi più dettagli di dove stai testando magari possiamo guardare insieme.

Per l'ip invece questo è completamente strippato oltre a forzare il parametro GA di anonimizzazione.

Quindi il comportamento è corretto.

Inoltre non capisco perché parli di consenso e API secret. L'API secret con il consenso e la privacy non hanno nulla a che vedere.

Ciao @juanin

Forse hai un tag js di Google diretto da qualche parte perché Host analytics non manda in alcun modo eventi come session_start che sono riservati e usabili solo da gtag.js.

Non c'è, ma a questo punto - avendolo comunque strapazzato negli ultimi 3 giorni - faccio prima a non fidarmi più & a creare una nuova istanza vergine .

Vi aggiorno una volta tirata su, associata in dashboard Host e ripetuti i vari controlli con le impostazioni vanilla.

Inoltre non capisco perché parli di consenso e API secret. L'API secret con il consenso e la privacy non hanno nulla a che vedere.

Termini & Condizioni d'uso API Secret di Measurement Protocol prevedono espressamente che i titolari dei siti abbiano ottenuto dagli utenti finali le autorizzazioni necessarie per la raccolta e il trattamento dei loro dati, compresa l'associazione di tali dati alle informazioni sulle visite raccolte da Google Analytics.

Non è una mera questione limitata solo al rapporto tra titolari & Google, a cui infatti basta la registrazione di accettazione T&C ("Ne prendo atto"), ma proprio di conformità alle disposizioni GDPR per raccolta & trattamento dei dati.

.
Pertanto, in caso di configurazione con uso API Secret - necessario/vincolante per il funzionamento della config - non solo serve ovviamente la corrispondenza ai criteri per la conformità della proxyficazione GA per trasferimento cross-border (ved. raccomandazioni EPDB / indicazioni CNIL), ma anche e comunque un consenso esplicito da parte del visitatore del sito per esecuzione codice tracking / memorizzazione cookie in relazione alla raccolta dati.

Ciao @juanin

Non c'è, ma a questo punto - avendolo comunque strapazzato negli ultimi 3 giorni - faccio prima a non fidarmi più & a creare una nuova istanza vergine .

Scoperto l'inghippo mentre stavo procedendo alle verifiche per la creazione delle nuove property UA/GA3 e GA4 per la nuova istanza.

Lo stream GA4 per cui vedevo i dati parziali in ingresso era stato impostato con la massima disabilitazione admin di raccolta dati, ma era comunque ancora collegato alla proprietà UA/GA3. Pertanto i dati spuri registrati derivavano proprio dal link.

Procedendo infatti stavolta a ricontrollo + conferma di unlink, da real-time non risultava più niente in debug / real-time.

:
Ergo, comunque errate sia l'impostazione lato mio che la conclusione "It's not a bug, it's a feature" sul fatto che la dashboard Host non segnalasse la mancata compilazione di api_secret nel campo GA4 in fase di save/update delle impostazioni del dominio.

.

Per l'ip invece questo è completamente strippato oltre a forzare il parametro GA di anonimizzazione.

Come da indicazioni CNIL e GPDP (provvedimenti vs Caffeina ed IlMeteo) - Host dovrebbe inoltrare ad endpoint GA un payload processato con parametro uip del tipo x.y.0.0 nel caso di client IP IPv4 (indipendentemente dal passaggio - a quel punto superfluo - anche del parametro aip = 1 per anonimizzazione lato server GA).

Nel caso di Analytics Host sto riscontrando invece indicazioni spurie di Località client IT - Torino, basate solo sull'IP (DC Host) da cui arriva la collect request ai measurement-server GA... anche quando non vi sono questioni/criticità evidenti di geolocalizzazione per l'uip risultante.

.
Per scrupolo, appena fatto nuovamente un paio di prove veloci su istanza nuova (con sopra solo una pagina HTML blank con Host tracking snippet in head) & associata a 2 nuove proprietà UA/GA3 e GA4 - create indipendentemente.

• Client IP : 167.114.101.64 -> Host dovrebbe passare uip = 167.114.0.0 -> Location rilevata invece in report GA : IT-Turin

• Client IP 45.130.136.162 -> Host dovrebbe passare uip = 45.130.0.0 -> Location rilevata invece in report GA : IT-Turin

In attesa della disponibilità di pannello debug / raw-data lato Host (vedo SuperUser, ma ancora in status 404), fammi sapere obv se vi servono nel frattempo altri check in merito.

@raw secondo me stai facendo un po' di confusione con l'API Secret.

L'informativa che ti mostra Google non è legata all'API Secret, ma al fatto che andrai a collezionare dati e trasferirli a Google nello specifico. Quindi è ovvio e normale che l'utente debba essere informato.

Il punto però è che il dato trasferito è completamente anonimizzato e non c'è alcuna info sensibile dell'utente che viene passata a Google in quanto appunto proxato.

Quindi il tema non è l'API Secret che è un mero strumento tecnico di autenticazione e validazione della hit di misurazione, ma è il trasferimento. Ma questo è ovviamente scontato.

Riguardo l'IP

La scelta per ora è quella di troncarlo totalmente. Non ci interessa cosa intenda Google per anonimizzazione. Non ci interessa cosa dice il CNIL Francese. Per noi ad oggi l'anonimizzazione è la soppressione totale dell'IP perché crediamo che si possano fare ottime analisi dati anche senza sapere dove sta l'utente di casa nella maggior parte dei casi. Per quelle nicchie dove è importante si possono arricchire i dati in autonomia.

L'utente può comunque continuare a fare gelocation e passarla a Google facendo una localizzazione di prima parte e inviando custom dimension apposite.

L'approccio è privacy by design e dunque chi vuole arricchire i dati può farlo sulla base di una sua scelta e non sulla base di una black box che colleziona dati in modo indiscriminato a prescindere.

Oltre a questo attualmente passare a GA4 in metodologia Server Side la Geolocalizzazione via IP è sostanzialmente inutile in quanto non funzionerebbe comunque. Puoi verificare tu stesso nel bug tracker di Google Analytics 4.

Ciao @juanin

Riguardo l'IP

La scelta per ora è quella di troncarlo totalmente

Perfect & grazie per conferma/chiarimento in merito .

Approfitto quindi per chiedere se prevediate (o meno) ulteriori impostazioni di processo in inoltro payload anche per URL/path e user-agent (nelle prove effettuate finora li ho visti arrivare cmq inalterati).

@raw cosa intendi esattamente? Puoi spiegare meglio con qualche esempio di cosa vedi e cosa invece ti aspetteresti di vedere?

Ciao @juanin

Puoi spiegare meglio con qualche esempio di cosa vedi e cosa invece ti aspetteresti di vedere?

Attualmente vedo arrivare url e user-agent non-processati = come vengono trasmessi in header/payload della post request all'endpoint /v1/ibriditics Host, così vengono inoltrati & arrivano lato GA (ved. DebugView/Report).

.
Quindi chiedo semplicemente se prevediate (o meno) di aggiungere misure/opzioni addizionali per ulteriore minimizzazione singling-out (ved. anche rilievi GPDP in provvedimento vs Fastweb per casistica visite da utenze loggate in browser su account Google) come opzioni predefinite e/o personalizzabili da pannello dashboard/superuser, e.g. :

• Strip/edit URL parametri location.search = rimozione totale e/o mantenimento solo di alcuni parametri - e.g. append ?debug_mode=true e/o UTM solo per proxyficazione tracking UA (visto che Measurement cmq non le supporta e tocca andare di dimensioni personalizzate per source/medium/campaign/etc.).

• Strip/edit user-agent = pseudonimizzazione parziale per versione/os/device e/o totale (solo nome browser o estrema/generica stile indicazione Mozilla Compatible Agent)

Quindi chiedo semplicemente se prevediate (o meno) di aggiungere misure/opzioni addizionali per ulteriore minimizzazione singling-out (ved. anche rilievi GPDP in provvedimento vs Fastweb per casistica visite da utenze loggate in browser su account Google) come opzioni predefinite e/o personalizzabili da pannello dashboard/superuser, e.g. :

Non credo che il passaggio User-Agent senza la coppia IP sia considerabile come un dato identificativo.
Inoltre non essendoci il JS diretto di Google Analytics/Tag Manager per Google non c'è modo di fare match con utenti loggati.

Il link fornito riguardo Fastweb recita infatti chiaramente il concetto:

Resta comunque fermo che, indipendentemente dall’accesso all’account Google, l’indirizzo IP può ad ogni modo consentire ‒soprattutto, come sopra già esplicitato, ove associato ad altre informazioni relative al browser utilizzato e alla data e all’ora della navigazione‒ di identificare un dispositivo di comunicazione elettronica e, quindi, indirettamente l’utente.

Ma andiamo avanti con il resto

• Strip/edit URL parametri location.search = rimozione totale e/o mantenimento solo di alcuni parametri - e.g. append ?debug_mode=true e/o UTM solo per proxyficazione tracking UA (visto che Measurement cmq non le supporta e tocca andare di dimensioni personalizzate per source/medium/campaign/etc.).

Lo strip parametri non è previsto, ma volendo si può prevedere anche se onestamente sarebbe un grosso colpo alle capacità di analisi con un effetto di fatto nullo sulla Privacy.

• Strip/edit user-agent = pseudonimizzazione parziale per versione/os/device e/o totale (solo nome browser o estrema/generica stile indicazione Mozilla Compatible Agent)

Questo potenzialmente si può già fare perché tra l'altro lo User Agent completo supera il limite di caratteri di GA4 e di conseguenza viene troncato.

Ti faccio vedere un esempio di come GA4 recepisce lo UA. Se supera 100 caratteri va in errore quindi ora host analytics lo tronca in ingresso, ma in teora per come funziona GA4 si può pure evitare di mandare lo User Agent completo.