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.

dobbiamo aspettare la primavera prossima per vedere se c'è un accordo politico USA-UE in merito