Chrome propone una nuova esperienza per la scelta dell'utente in merito ai cookie di terze parti. Devi preparare il tuo sito per gli utenti che scelgono di navigare senza cookie di terze parti.
Questa pagina contiene informazioni su cosa potrebbe essere interessato dalle imminenti modifiche.
Percorsi comuni degli utenti
Molti flussi di lavoro di pagamento e acquisto si basano su cookie di terze parti. La tabella seguente elenca alcuni percorsi utente che potrebbero essere interessati se i cookie di terze parti vengono disattivati e suggerisce API alternative che gli sviluppatori possono utilizzare per evitare interruzioni. Questo elenco potrebbe non essere esaustivo e potrebbe essere aggiornato man mano che diventano disponibili altre soluzioni di Privacy Sandbox. Ti invitiamo a condividere il tuo feedback se riscontri altri scenari interessati.
Testa i percorsi degli utenti relativi ai pagamenti
Il modo migliore per verificare se i flussi utente sono interessati dalle limitazioni dei cookie di terze parti è esaminarli con l'indicatore di test dei cookie di terze parti abilitato.
Per assicurarti che il tuo sito web funzioni come previsto, testa il seguente flusso con i cookie di terze parti limitati:
- Pagamento su più siti: testa i flussi di pagamento che si basano su un fornitore di servizi di pagamento di terze parti (ad esempio Paga con <example-provider>). Assicurati che:
- Il reindirizzamento viene eseguito correttamente.
- Il gateway di pagamento viene caricato correttamente.
- La procedura di pagamento può essere completata senza errori.
- L'utente viene reindirizzato al tuo sito web come previsto.
- Dashboard dei pagamenti: verifica che i widget della dashboard delle transazioni funzionino come previsto con i cookie di terze parti limitati. Verifica che l'utente possa:
- Accedi alla dashboard.
- Visualizza tutti i pagamenti come previsto.
- Navigare senza errori tra le diverse sezioni della dashboard (ad es. cronologia transazioni, dettagli pagamento).
- Gestisci metodi di pagamento: verifica che i widget di gestione dei metodi di pagamento funzionino come previsto. Con i cookie di terze parti bloccati, verifica che:
- L'aggiunta o l'eliminazione di un metodo di pagamento funziona come previsto.
- Il pagamento con i metodi di pagamento salvati in precedenza non è interessato.
- Rilevamento delle attività fraudolente: confronta il funzionamento della tua soluzione di rilevamento delle attività fraudolente con e senza cookie di terze parti.
- Il blocco dei cookie di terze parti introduce passaggi aggiuntivi, provocando ulteriore attrito per gli utenti?
- Può comunque rilevare modelli sospetti quando i cookie di terze parti sono bloccati nel browser?
- Pulsante di pagamento personalizzato: verifica se i pulsanti di pagamento vengono visualizzati correttamente con i cookie di terze parti limitati.
- L'utente può comunque completare gli acquisti anche se il pulsante personalizzato non mostra il suo metodo preferito?
Pagamenti cross-site
Alcuni fornitori di servizi di pagamento potrebbero fare affidamento su cookie di terze parti per consentire agli utenti di accedere al loro account su più siti di commercianti senza dover eseguire nuovamente l'autenticazione. Questo percorso dell'utente potrebbe essere interessato per chi sceglie di navigare senza cookie di terze parti.
Moduli di pagamento incorporati
Considera i seguenti domini:
payment-provider.example
fornisce servizi di pagamento ai siti dei commercianti e memorizza i dati di pagamento e sessione degli utenti.merchant.example
è un sito web che incorpora un modulo di pagamento fornito dapayment-provider.example
.
Un utente ha appena eseguito l'accesso a payment-provider.example
(ad esempio, mentre completa il pagamento su un altro sito). L'utente avvia una procedura di pagamento su
merchant.example
.
Se sono disponibili cookie di terze parti, il modulo di pagamento di payment-provider.example
incorporato in merchant.example
avrebbe accesso al proprio cookie di sessione di primo livello impostato su payment-provider.example
nel contesto di primo livello.
Tuttavia, se i cookie di terze parti sono bloccati, l'embed non avrà accesso ai propri
cookie di primo livello.

Una soluzione personalizzabile con FedCM
payment-provider.example
dovrebbe valutare la possibilità di implementare
FedCM per fungere da
un provider di identità. Questo approccio può essere adatto quando:
payment-provider.example
è incorporato in siti di terze parti non correlati.payment-provider.example
è incorporato in più di cinque siti correlati.
Il vantaggio principale di FedCM è che l'interfaccia utente può fornire agli utenti più contesto per le loro scelte. Con l'autorizzazione dell'utente, FedCM consente la condivisione di dati personalizzati tra la Relying Party (merchant.example
) e l'Identity Provider (payment-provider.example
). La Relying Party può scegliere di supportare uno o più Identity Provider e l'interfaccia utente di FedCM verrà visualizzata solo condizionatamente.
A seconda delle esigenze, gli sviluppatori possono scegliere tra la modalità passiva, in cui la richiesta di FedCM viene visualizzata automaticamente quando l'utente accede con l'identity provider, o la modalità attiva, in cui la procedura di accesso deve essere attivata dopo un'azione dell'utente, ad esempio il clic su un pulsante di pagamento.
FedCM funge anche da indicatore di attendibilità per l'API Storage Access (SAA), che consente all'embed di accedere ai suoi cookie non partizionati di primo livello dopo che l'utente accetta di accedere con il provider dell'embed, senza bisogno di un prompt aggiuntivo per l'utente.
Soluzione incentrata sull'accesso allo spazio di archiviazione
Un'altra API da prendere in considerazione è l'API Storage Access (SAA).
Con l'ASA, all'utente verrà chiesto di consentire all'embedding di payment-provider.example
di accedere ai propri cookie di primo livello. Se l'utente approva l'accesso, il modulo può essere visualizzato come quando sono disponibili i cookie di terze parti.
Come per FedCM, l'utente dovrà approvare la richiesta su ogni nuovo sito
in cui è incorporato payment-provider.example
. Guarda la demo di SAA per capire come funziona l'API.
Se il prompt SAA predefinito non soddisfa le tue esigenze, ti consigliamo di implementare FedCM per un'esperienza più personalizzata.
Ridurre le difficoltà degli utenti su un numero limitato di siti correlati
Se sia il sito del commerciante sia il fornitore di servizi di pagamento appartengono alla stessa azienda, puoi utilizzare l'API Related Website Sets (RWS) per dichiarare le relazioni tra i domini. In questo modo, puoi ridurre le difficoltà degli utenti: ad esempio, se insurance.example
e
payment-portal-insurance.example
si trovano nella stessa RWS,
payment-portal-insurance.example
avrà automaticamente accesso ai propri
cookie di primo livello quando viene richiesto l'accesso allo spazio di archiviazione all'interno del
payment-portal-insurance.example
incorporato.
Altre soluzioni sperimentali
Un'altra API sperimentale che potrebbe essere utile in questo scenario è Partitioned Popins. L'API è attualmente in fase di sviluppo attivo.
Con i popup suddivisi, all'utente può essere chiesto di inserire le proprie credenziali per accedere a payment-provider.example
in un popup aperto da merchant.example
. Lo spazio di archiviazione verrà
partizionato
dall'aprifile merchant.example
. In questo caso, l'embed payment-provider.example
avrà accesso ai valori di archiviazione impostati nel popup. Con questa
soluzione, l'utente dovrà accedere al fornitore di servizi di pagamento su ogni sito.
Pagamenti tramite link
Alcuni fornitori di servizi di pagamento offrono un servizio che genera un link di pagamento, che mostra una pagina di pagamento personalizzata per il sito di un commerciante. Un servizio di collegamento dei pagamenti e un portale utente per il fornitore di servizi di pagamento vengono spesso implementati in domini diversi, ad esempio payment-provider.example
e payment-link.example
.
payment-link.example
incorpora un modulo di pagamento fornito da
payment-provider.example
. Si tratta di una variante del pattern
modulo di pagamento incorporato.
Anche FedCM,
SAA
e
RWS
sono ottime opzioni da prendere in considerazione per questo caso.
Dashboard pagamenti
Alcune applicazioni mostrano ai propri utenti dashboard delle transazioni su più siti, fornendo una visione centralizzata delle loro attività finanziarie. Per questo, la dashboard deve accedere ai dati specifici degli utenti in più domini.
Considera i seguenti domini:
earnings.example
fornisce una dashboard dei pagamenti che può essere incorporata in varie applicazioni web. Questo servizio memorizza i dati sugli utili degli utenti e le informazioni sulle sessioni.catsitting.example
edogsitting.example
sono siti web distinti che incorporano entrambi la dashboardearnings.example
.
Un utente accede al proprio account earnings.example
. Quando visitano catsitting.example
o dogsitting.example
, possono visualizzare i propri utili. La dashboard earnings.example
incorporata si basa sui cookie di primo livello e mostra le informazioni personalizzate sugli utili dell'utente.
Come in altri esempi, l'embed di earnings.example
non avrà accesso ai suoi cookie di primo livello se i cookie di terze parti sono disattivati.

Dashboard proprietarie
Se tutti e tre i domini appartengono alla stessa parte, ti consigliamo di utilizzare
SAA insieme a
RWS.
Con l'autorizzazione dell'utente, earnings.example
può accedere al proprio cookie di primo livello con l'autorizzazione dell'utente. Se questa parte utilizza earnings.example
su quattro o meno domini,
la dichiarazione delle relazioni tra questi con RWS può offrire un'esperienza utente più scorrevole.
Se la stessa parte incorpora il widget in più di cinque domini, non può dichiarare relazioni tra tutti i siti di incorporamento e il dominio del widget, poiché RWS supporta solo sei siti in un insieme: uno principale e cinque associati.
Distribuzione delle dashboard su larga scala
Nei seguenti casi, SAA e RWS potrebbero non essere la soluzione ottimale:
- Distribuisci una soluzione di dashboard per siti di terze parti.
- Hai più di cinque siti che incorporano il widget della dashboard.
In questo caso, earnings.example
dovrebbe prendere in considerazione l'implementazione di FedCM come provider di identità. Ciò significa che l'utente dovrà accedere a
dogsitting.example
con un account gestito da earnings.example
.
FedCM offre un'interfaccia utente personalizzabile che può aiutare a comunicare chiaramente all'utente quali informazioni vengono condivise. Con FedCM, dogsitting.example
può richiedere
earnings.example
di condividere
autorizzazioni personalizzate,
ad esempio per accedere ai dati sulle transazioni.
FedCM funge anche da
indicatore di attendibilità per l'API Accesso allo spazio di archiviazione,
e all'embed di earnings.example
verrà concesso l'accesso allo spazio di archiviazione per i suoi
cookie di primo livello senza un'ulteriore richiesta all'utente nella chiamata dell'API SAA.
Impostazioni della dashboard specifiche del sito
Se i dati non devono essere condivisi su più siti, valuta la possibilità di suddividere i cookie con CHIPS. I CHIP possono essere utili per memorizzare preferenze specifiche del sito, ad esempio il layout della dashboard o i filtri.
Gestisci i metodi di pagamento
Un altro flusso comune è che l'utente possa visualizzare e modificare i propri metodi di pagamento all'interno di un'integrazione senza uscire dal sito host.
Considera il seguente flusso:
payments.example
fornisce uno strumento di gestione dei pagamenti che può essere incorporato nei siti web. Questo servizio memorizza i dati di pagamento e le informazioni sulla sessione dell'utente.shop.example
è un sito web che incorpora lo strumentopayments.example
per consentire agli utenti di visualizzare, modificare o scegliere i metodi di pagamento preferiti associati al loro accountshop.example
.
I fornitori di servizi di pagamento che implementano la gestione dei metodi di pagamento dovrebbero anche considerare la possibilità di diventare fornitori di servizi di identità con FedCM. Con FedCM, l'utente potrà accedere alla terza parte attendibile (shop.example
) utilizzando l'account gestito dal provider di identità (payments.example
).
Con l'autorizzazione dell'utente, FedCM consente la condivisione di dati personalizzati tra la relying party e l'identity provider. Il vantaggio principale dell'utilizzo di FedCM è che l'interfaccia utente può fornire agli utenti più contesto per le loro scelte. Inoltre, funge da indicatore di attendibilità per l'API Storage Access, che consente all'embed di accedere ai suoi cookie di primo livello.
Con i cookie di terze parti disattivati, l'embed di payments.example
non avrà accesso ai suoi cookie di primo livello. In questo caso,
SAA
può contribuire a garantire il corretto funzionamento richiedendo l'accesso allo spazio di archiviazione.
A volte le informazioni impostate all'interno dell'embed non devono essere condivise su altri siti che lo incorporano. payments.example
potrebbe dover memorizzare solo preferenze degli utenti diverse per ogni sito di incorporamento specifico. In questo caso, valuta la possibilità di suddividere i cookie utilizzando CHIPS. Con
CHIPS, il cookie impostato in payments.example
incorporato in shop.example
non sarà
accessibile da payments.example
incorporato in another-shop.example
.
Un'altra API sperimentale che può essere potenzialmente utilizzata in questo flusso utente è Popup suddivisi.
Quando l'utente accede a payments.example
in un popup aperto da
shop.example
, lo spazio di archiviazione verrà partizionato da chi ha aperto il popup e il
embed avrà accesso ai valori dello spazio di archiviazione impostati nel
popup.payments.example
Tuttavia, questo approccio richiede agli utenti di inserire le credenziali per accedere al fornitore di servizi di pagamento su ogni sito.
Rilevamento di frodi
I sistemi di analisi del rischio possono analizzare i dati memorizzati nei cookie per identificare modelli che si discostano dalla norma. Ad esempio, se un utente cambia improvvisamente il proprio indirizzo di spedizione ed effettua diversi acquisti di importo elevato utilizzando un nuovo dispositivo, il punteggio di potenziale attività fraudolenta potrebbe aumentare. I cookie per il rilevamento delle attività fraudolente sono solitamente cookie di terze parti, impostati sui siti dei commercianti da fornitori di servizi di pagamento o widget di servizi di prevenzione delle attività fraudolente.
Sebbene le limitazioni dei cookie di terze parti non debbano compromettere i sistemi di rilevamento delle attività fraudolente, potrebbero creare ulteriori difficoltà per gli utenti. Se il sistema non riesce a verificare con certezza che un utente è legittimo a causa dei cookie bloccati, potrebbe richiedere controlli aggiuntivi, come la verifica dell'identità.
Per supportare il rilevamento delle attività fraudolente quando i cookie di terze parti sono bloccati, valuta la possibilità di integrare l'API Private State Tokens (PST) nella tua soluzione di rilevamento delle attività fraudolente. Con la PST, un fornitore di servizi di pagamento può registrarsi come emittente di token e concedere agli utenti token che non si basano su cookie di terze parti. Questi token possono essere utilizzati sui siti dei commercianti per verificare se l'utente è affidabile. Per i dettagli sull'implementazione, consulta la documentazione per gli sviluppatori di PST.
Privacy Sandbox sta conducendo esperimenti con altre API antifrode.
Pulsante di pagamento personalizzato
I pulsanti di pagamento (ad esempio Paga con <metodo di pagamento preferito>) incorporati sui siti dei commercianti spesso si basano su informazioni cross-site impostate dal fornitore di servizi di pagamento. In questo modo è possibile personalizzare l'esperienza e gli utenti possono effettuare un pagamento agevole con il metodo che preferiscono. Se i cookie di terze parti sono bloccati nel browser dell'utente, questo può influire sul rendering del pulsante di pagamento personalizzato.
Anche se SAA potrebbe consentire l'accesso allo spazio di archiviazione, la richiesta obbligatoria potrebbe non portare a un'esperienza dell'utente ideale.
Stiamo valutando una potenziale soluzione che abbia come target specifico questo caso d'uso: Frame delimitati con accesso ai dati locali non partizionati. L'API è attualmente in una fase di sviluppo attiva e puoi dare forma al suo futuro. Prova tu stesso e fornisci feedback.
Ricevi assistenza
Segnala eventuali malfunzionamenti all'indirizzo goo.gle/report-3pc-broken. Puoi anche compilare un modulo di feedback o segnalare un problema su GitHub nel repository di assistenza per gli sviluppatori di Privacy Sandbox.