I cookie di terze parti potrebbero essere bloccati dalle limitazioni del browser, dalle impostazioni utente, dai flag per sviluppatori o dai criteri aziendali.
Devi assicurarti che il tuo sito o servizio offra un'esperienza ottimale a tutti gli utenti, indipendentemente dalla disponibilità o meno dei cookie di terze parti.
Questa pagina contiene informazioni sui percorsi utente comuni che potrebbero essere interessati dal blocco dei cookie di terze parti.
Percorsi dell'utente comuni
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 sono 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.
Testare i percorsi degli utenti correlati ai pagamenti
Il modo migliore per verificare se i tuoi flussi utente sono interessati dalle limitazioni dei cookie di terze parti è esaminarli con il flag di test dei cookie di terze parti attivato.
Per assicurarti che il tuo sito web funzioni come previsto, testa il seguente flusso con i cookie di terze parti limitati:
- Pagamento cross-site: 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 avviene 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.
- Spostarsi senza errori tra le diverse sezioni della dashboard (ad es. cronologia delle transazioni, dettagli di 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 frodi: confronta il funzionamento della tua soluzione di rilevamento delle frodi
con e senza cookie di terze parti.
- Il blocco dei cookie di terze parti introduce passaggi aggiuntivi, causando ulteriori attriti per gli utenti?
- Può comunque rilevare pattern 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 proprio account su più siti commercianti senza dover eseguire nuovamente l'autenticazione. Questo percorso dell'utente potrebbe essere interessato per coloro che scelgono di navigare senza cookie di terze parti.
Moduli di pagamento incorporati
Considera i seguenti domini:
payment-provider.examplefornisce servizi di pagamento ai siti dei commercianti e memorizza i dati di pagamento e di 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.
Con i cookie di terze parti disponibili, il modulo di pagamento 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'incorporamento non avrà accesso ai propri
cookie di primo livello.
Una soluzione personalizzabile con FedCM
payment-provider.example dovrebbe prendere in considerazione l'implementazione di
FedCM per fungere da
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 la UI può fornire agli utenti un contesto più ampio per le loro scelte. Con l'autorizzazione dell'utente, FedCM consente la condivisione di
dati personalizzati
tra la parte autorizzata (merchant.example) e il fornitore di identità
(payment-provider.example). La parte autorizzata può scegliere di supportare uno o più
fornitori di identità e l'interfaccia utente FedCM verrà visualizzata
in modo condizionale.
A seconda delle esigenze, gli sviluppatori possono scegliere tra la modalità passiva per la visualizzazione automatica del prompt FedCM quando l'utente ha eseguito l'accesso con il provider di identità o la modalità attiva, quando la procedura di accesso deve essere attivata dopo un'azione dell'utente, ad esempio un clic su un pulsante di pagamento.
FedCM funge anche da indicatore di attendibilità per l'API Storage Access (SAA), che consente all'incorporamento di accedere ai cookie non partizionati di primo livello dopo che l'utente accetta di accedere con il provider dell'incorporamento, senza la necessità di un ulteriore prompt 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'API Storage Access, all'utente verrà chiesto di consentire l'incorporamento di payment-provider.example per accedere ai propri cookie di primo livello. Se l'utente approva l'accesso, il modulo può
essere visualizzato come quando sono disponibili 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
SAA per capire come funziona l'API.
Se il prompt SAA predefinito non soddisfa le tue esigenze, valuta la possibilità di implementare FedCM
per un'esperienza più personalizzata.
Ridurre i problemi 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 società,
puoi utilizzare l'API
insiemi di siti web correlati (RWS)
per dichiarare le relazioni tra i domini. Ciò può contribuire a ridurre l'attrito per gli utenti: ad esempio, se insurance.example e payment-portal-insurance.example si trovano nello stesso insieme di siti web correlati, payment-portal-insurance.example otterrà automaticamente l'accesso ai propri cookie di primo livello quando viene richiesto l'accesso allo spazio di archiviazione all'interno dell'incorporamento di payment-portal-insurance.example.
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 pop-in partizionati, all'utente può essere chiesto di inserire le proprie credenziali per
accedere a payment-provider.example all'interno di un pop-in aperto da
merchant.example. Lo spazio di archiviazione verrà
partizionato
dall'apertura merchant.example. In questo caso, l'incorporamento 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.
Checkout con link per i pagamenti
Alcuni fornitori di servizi di pagamento offrono un servizio che genera un link di pagamento, che visualizza una pagina di pagamento personalizzata per il sito di un commerciante. Un servizio di link di pagamento e un portale utente per il fornitore di servizi di pagamento vengono spesso implementati su 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.
FedCM,
SAA
e
RWS
sono buone opzioni da prendere in considerazione anche in questo caso.
Dashboard dei pagamenti
Alcune applicazioni mostrano ai propri utenti dashboard delle transazioni su più siti, fornendo una visione centralizzata delle loro attività finanziarie. Ciò richiede che la dashboard acceda a dati specifici dell'utente in più domini.
Considera i seguenti domini:
earnings.examplefornisce 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.exampleedogsitting.examplesono siti web separati che incorporano entrambi la dashboardearnings.example.
Un utente accede al proprio account earnings.example. Quando visitano catsitting.example o dogsitting.example, possono visualizzare i loro utili. La dashboard
earnings.example incorporata si basa sui cookie di primo livello e mostra
le informazioni sugli utili personalizzate dell'utente.
Come negli altri esempi, l'incorporamento earnings.example non avrà accesso ai
cookie di primo livello con i cookie di terze parti disattivati.
Dashboard proprietarie
Nei casi in cui tutti e tre i domini appartengono alla stessa parte, valuta la possibilità di utilizzare
SAA
insieme a
RWS.
Con l'API Storage Access, earnings.example può accedere al suo 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ù fluida.
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, in quanto l'insieme di siti web correlati supporta solo fino a 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 per fungere da 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 a earnings.example di condividere autorizzazioni personalizzate, ad esempio per accedere ai dati delle transazioni.
FedCM funge anche da
indicatore di attendibilità per l'API Storage Access
e l'incorporamento earnings.example riceverà l'accesso allo spazio di archiviazione ai propri
cookie di primo livello senza un ulteriore prompt utente nella chiamata API SAA.
Impostazioni della dashboard specifiche del sito
Se i dati non devono essere condivisi su più siti, valuta la possibilità di partizionare i cookie con CHIPS. CHIPS può essere utile per memorizzare le preferenze specifiche del sito, ad esempio il layout della dashboard o i filtri.
Gestisci i metodi di pagamento
Un altro flusso comune è quello in cui l'utente visualizza e modifica i propri metodi di pagamento all'interno di un incorporamento senza uscire dal sito host.
Considera il seguente flusso:
payments.examplefornisce 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.exampleper consentire agli utenti di visualizzare, modificare o scegliere i metodi di pagamento preferiti associati al proprio accountshop.example.
I fornitori di servizi di pagamento che implementano la gestione dei metodi di pagamento devono anche
valutare la possibilità di diventare un provider di identità con
FedCM. Con
FedCM, l'utente potrà accedere alla Relying Party (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 parte autorizzata e il provider di identità. Il vantaggio principale dell'utilizzo di FedCM è che la UI può fornire agli utenti un maggiore contesto per le loro scelte. Funge anche da indicatore di attendibilità per l'API Storage Access, che consente all'incorporamento di accedere ai cookie di primo livello.
Con i cookie di terze parti disabilitati, l'incorporamento di payments.example non avrà
accesso ai 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 nell'incorporamento non devono essere condivise con
altri siti di incorporamento. payments.example potrebbe dover memorizzare preferenze utente diverse per ogni sito di incorporamento specifico. In questo caso, valuta la possibilità di partizionare i cookie utilizzando CHIPS. Con
CHIPS, il cookie impostato all'interno di 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 è
Partitioned Popins.
Quando l'utente esegue l'accesso a payments.example all'interno di un pop-in aperto da
shop.example, l'archiviazione verrà partizionata in base all'apertura e l'incorporamento di
payments.example avrà accesso ai valori di archiviazione impostati all'interno del
pop-in. 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 pattern che si discostano dalla norma. Ad esempio, se un utente cambia improvvisamente il proprio indirizzo di spedizione ed effettua diversi acquisti di grandi dimensioni utilizzando un nuovo dispositivo, il potenziale punteggio di frode potrebbe aumentare. I cookie di rilevamento delle frodi sono generalmente cookie di terze parti, impostati sui siti dei commercianti da fornitori di servizi di pagamento o widget di servizi di prevenzione delle frodi.
Sebbene le limitazioni dei cookie di terze parti non debbano interrompere i sistemi di rilevamento delle frodi, potrebbero creare ulteriori attriti per gli utenti. Se il sistema non riesce a verificare con certezza che un utente sia legittimo a causa dei cookie bloccati, potrebbe richiedere controlli aggiuntivi, ad esempio il completamento della verifica dell'identità.
Per supportare il rilevamento delle frodi 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 frodi. Con 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 poi essere riscattati sui siti dei commercianti per verificare se l'utente è affidabile. Per i dettagli di implementazione, consulta la documentazione per gli sviluppatori di PST.
Privacy Sandbox sta sperimentando altre API antifrode.
Pulsante di pagamento personalizzato
I pulsanti di pagamento (ad esempio Paga con <metodo di pagamento preferito>) incorporati nei siti dei commercianti spesso si basano su informazioni cross-site impostate dal fornitore di servizi di pagamento. Ciò consente la personalizzazione e gli utenti possono usufruire di un pagamento senza problemi con il metodo di pagamento preferito. Se i cookie di terze parti sono bloccati nel browser dell'utente, ciò può influire sul rendering del pulsante di pagamento personalizzato.
Sebbene SAA possa consentire l'accesso allo spazio di archiviazione, il prompt richiesto potrebbe non portare a un'esperienza utente ideale.
Stiamo esplorando una potenziale soluzione che ha come target specifico questo caso d'uso: Fenced Frame con accesso ai dati locali non partizionati. L'API è attualmente in fase di sviluppo attivo e puoi contribuire a plasmare il suo futuro. Prova tu e fornisci un feedback.
Guida e feedback
Se hai domande o feedback sui percorsi utente o sulle API descritti in questa guida, puoi condividere il tuo feedback.