@lucaf7 ha detto in Ma quindi questa conversion API è legale o no?:

Poichè c'è un processo di passaggio di un dato personale per finalità di marketing, che avverrebbe anche se l'utente rifiuta la classica barra dei cookie.
E' corretto?

È corretto.

Legalmente la puoi passare solo se hai il consenso esplicito dell'utente.

Che poi nessuno possa verificare quello che fai sul tuo server, è un altro discrorso (ed è quello che permette a moltissimi di farlo lo stesso, in barba a ogni legalità).

Ad ogni modo, non devi "farlo digerire al DPO", quello che devi fare è:

motivare la necessità di passare questo dato inserire la cosa in privacy policy ottenere il consenso esplicito dell'utente

Se fai così, il DPO non potrà che dirti di sì.

(almeno per ora che il trasferimento negli USA è "tornato" legale... e di certo rimarrà così fino alla Schrems III )

@kal Yep

@lucaf7 al netto di quello che sappiamo, ad essere bloccati automaticamente saranno i parametri che passano ID univoci (o qualunque cosa che gli assomigli).

Non sono difficili da sgamare. Sono valori molto lunghi, alfanumerici, apparentemente casuali.

Quello che passi nel modello che hai linkato sono semplici, generiche, stringhe di testo e non dovrebbero essere bloccati (sempre al netto di quello che è stato dichiarato, naturalmente).

@lucaf7 per farla brevissima, se gli utenti NON hanno rilasciato il consenso nelle app in ambiente iOS:

i click in uscita perdono i parametri di ID del click (fbcid, etc.) i click in uscita MANTENGONO comunque i parametri anonimi di campagna (utm_source, etc.)

La tua capacità di identificarli correttamente dipende da questo.

Se ho capito bene, l’utilizzo di termini “custom” negli UTM potrebbe alterare la sorgente di traffico? Io sto notando una notevole discrepanza tra alcune Sorgenti UA3 (googleads e google_shopping) che in GA4 vengono segnate con sorgente Google e mezzo Cpc... potrebbe essere la stessa problematica riscontrata da @lucaf7? O sto sbagliando io qualcos'altro?

@lucaf7 dipende quali dati passi... se non passi dati personali il problema non si pone.

Va tuttavia notato che in tutti i casi di Conversion API, quello che fai è associare il parametro gclid/fbclid alla conversione... ed il parametro gclid/fbclid di fatto è un dato personale, perché è effettivamente un identificatore univoco (del clic fatto da quello specifico utente).

La soluzione per il momento è futuribile e passa per queste (per ora solamente a livello di proposta di standard):

https://webkit.org/blog/11529/introducing-private-click-measurement-pcm/

https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting/

Che sono simili nel concetto, ovvero la conversione viene associata non al gclid/fbclid a livello di clic utente, ma ad un ID "anonimo" a livello di campagna.

E questo evidentemente non è un dato personale, quindi sarebbe rispettoso della privacy e delle normative.

Rimangono delle proposte e non sono ancora applicabili.

Riguardo al discorso della API server side, c'è una cosa da dire: non sono auditabili dall'esterno. Puoi usarle senza documentarle e nessuno ufficialmente sa niente.

Come dire: aumma aumma e sacrfichiamo scientemente la privacy sull'altare della performance, minimizzando al tempo stesso il rischio che l'azienda si trovi sotto esame dell'Autorità Garante.

Però se la policy del cliente è super-strict (è nella sua facoltà e a dire il vero non ha torto nell'applicarla) non c'è alcun modo di farci il giro.

@lucaf7 e allora non credo proprio ci siano problemi.

@lucaf7 le rimuovo proprio. Non ha senso in Ads avere doppioni della stessa conversione.

@lucaf7 esatto. Nel prossimo futuro il remarketing sarà solo possibile:

Su piattaforme Che offrono un sistema di tagging server side

@lucafranca io, ed i miei colleghi che stiamo lavorando da casa, quindi anche anche diversi rumori di sottofondo di bambini, abbiamo provato gli AirPods, ma poi abbiamo ripiegato su delle cuffie professionali Jabra.

La qualità del microfono è decisamente superiore, chi ti ascolta non sente minimanente se intorno a te c'è confusione.

Per la comodità lo sono di sicuro, almeno per noi poi sono gusti.

Non abbiamo preso quelle con la riduzione del rumore attiva, avendo i padigliono auricolari e ben imbottiti fanno già abbastanza.

Inoltre la comodità di mettere il muto semplicemente alzando l'asta del microfono, le batterie che durano giorni e le luci che indicano a chi ti sta intorno se sei in conversazione o meno sono strumenti utili.

BROFIST

Credo che almeno all'inizio la strategia "massimizza i clck" sai indispensabile, specialmente se si vogliono ottenere risultati in tempi rapidi. Lo staff di Google consiglia di utilizzare come cpc massimo il 10% del budget giornaliero.

Il metodo ufficiale per tracciare le app con Google Analytics è ancora Firebase Analytics.

Non l'ho fatto direttamente perché non sviluppo app, ma ho seguito almeno un progetto come consulente.

Ha un suo grado di complicazione perché devi mappare correttamente tutto PRIMA di rilasciare la app, e non c'è nulla di automatico come nel GA classico per i siti web, quindi ha un certo costo in fase di progetto.

Anche la GUI di Analytics è differente e si basa tantissimo sull'analisi degli eventi e soprattutto dei Goal.

In questo, è molto simile l'approccio app+web, ma quello è ancora in beta.

Sarà certamente quello utilizzato in futuro, ma a quanto mi risulta la roadmap è ancora lunga.

Indi per cui: studiati bene Firebase Analytics e prendi confidenza con quel sistema. Imparato quello, il salto ad app+web non dovrebbe essere traumatico.

Ciao e benvenuto nel Forum GT.

@Raffaele Conte said:

Ciao

si conviene sempre separarle

2)prova con +matrimonio +marche se anche cosi non ci saranno visualizzazioni credo che ci siano problemi, in questo caso contatta il centro di assistenza googe

Grazie

Benvenuto nel forum !