Test agevolati da Chrome

Per prepararci al ritiro dei cookie di terze parti, stiamo fornendo modalità di test agevolate da Chrome che consentono ai siti di visualizzare l'anteprima del funzionamento del comportamento e delle funzionalità del sito senza cookie di terze parti. Questa guida fornisce una panoramica delle modalità di test che Chrome prevede di fornire e di come accedere alle etichette dei gruppi dell'esperimento.

In questo contesto, il browser Chrome fa riferimento a un client Chrome, ovvero un'installazione Chrome su un dispositivo. Ogni directory dei dati di un singolo utente costituisce un client distinto.

Gruppo sperimentale: un insieme di browser Chrome per cui sono attivate, disattivate o configurate determinate funzionalità. Nel contesto dei test agevolati da Chrome, un insieme di browser per cui vengono impostate le etichette.

Etichetta: in questo contesto, un valore di intestazione della richiesta impostato per un browser che appartiene a un gruppo sperimentale. Ogni browser di un gruppo sperimentale rimarrà in quel gruppo per tutto il periodo dei test agevolati da Chrome, garantendo che l'etichetta per un browser rimanga coerente per tutti i tester.

Abbiamo offerto due modalità distinte:

• Modalità A: da novembre 2023, le organizzazioni che testano le API PS R&M hanno la possibilità di attivare la ricezione di etichette coerenti su un sottoinsieme di browser Chrome per consentire test coordinati tra tester diversi.
• Modalità B: a partire dal 4 gennaio 2024, Chrome ha disabilitato a livello globale i cookie di terze parti per una parte dei browser Chrome.

Se i cookie di terze parti vengono disabilitati in modalità B, rimangono disattivati anche durante l'eliminazione completa dei cookie di terze parti.

Abbiamo collaborato con la CMA per assicurarci che queste modalità di test siano in linea con il framework di test (e la tempistica) per le terze parti come indicato nelle linee guida sui test di settore. Di conseguenza, la CMA prevede che i risultati dei test in queste modalità possano essere utilizzati nella sua valutazione di Privacy Sandbox. La CMA ha indicato che probabilmente attribuiranno maggiore peso ai risultati del progetto sperimentale 2, che utilizza le etichette Modalità B e Controllo modalità A 1. Consulta le indicazioni del CMA del 26 ottobre per ulteriori informazioni sulla progettazione sperimentale 2.

È possibile accedere alle etichette utilizzando il valore temporaneo Cookie-Deprecation disponibile da un'intestazione HTTP o dall'API JavaScript. Per i dettagli sull'implementazione, consulta la sezione successiva Accesso alle etichette utilizzando il valore Ritiro dei cookie.

Inoltre, invieremo questa proposta tramite il consueto processo di sviluppo di Blink, in cui saranno finalizzati la progettazione tecnica e il traguardo di rilascio di Chrome. Anche se questa è l'implementazione che vogliamo offrire, ulteriori discussioni e approvazioni significano che questi dettagli sono comunque soggetti a modifica. Continueremo ad aggiornare questa pagina man mano che i piani procedono e puoi continuare a fornire feedback o domande.

Modalità A: gruppi di browser etichettati

Le organizzazioni che partecipano ai test potranno attivare la ricezione di un insieme permanente di etichette per un sottoinsieme di browser Chrome, in modo da poter eseguire esperimenti coordinati tra diverse tecnologie pubblicitarie sullo stesso gruppo di browser. Ad esempio, se un browser rientra nel gruppo sperimentale label_only_3 (come mostrato nella tabella seguente), tutti i tecnici pubblicitari partecipanti potranno vedere la stessa etichetta label_only_3 e coordinarsi di conseguenza: utilizzare le API R&M PS, ma evitare di utilizzare cookie di terze parti. Ci aspettiamo che i partecipanti nella pagina garantiscano l'inoltro delle etichette ad altri partecipanti per consentire una sperimentazione coerente durante l'intero processo di selezione e misurazione degli annunci.

Ad esempio, questo consente a più partecipanti di eseguire aste Protected Audience senza cookie di terze parti in un gruppo coerente di browser. I partecipanti al venditore dell'asta inoltreranno l'etichetta osservata agli acquirenti per facilitare i test coordinati.

Le etichette non influiscono sul comportamento in queste istanze di Chrome, inclusa la disponibilità dei cookie di terze parti. Le etichette consentono di raggruppare gli esperimenti indipendenti e coordinati, ma spetta alle parti partecipanti applicare i parametri pertinenti per l'esperimento. Se stai testando l'effetto della rimozione dei cookie di terze parti, ogni partecipante è responsabile dell'esclusione dei dati dei cookie di terze parti per i browser con quell'etichetta.

L'obiettivo è avere gruppi rappresentativi del normale traffico di Chrome. Ciò significa che dovrebbero essere disponibili sia i cookie di terze parti sia le API PS R&M, sebbene alcuni utenti possano aver utilizzato impostazioni o estensioni per modificare o disabilitare le funzionalità.

In genere le etichette sono permanenti per tutta la durata di una sessione di navigazione in Chrome e tra una sessione e l'altra. Tuttavia, questo non è garantito, poiché esistono rari casi in cui la reimpostazione completa di un browser potrebbe comportare anche la reimpostazione dell'etichetta corrente.

Abbiamo in programma di includere l'8, 5% dei browser stabili di Chrome per la modalità A e la nostra proposta iniziale suddivide questa popolazione in nove gruppi. I sottogruppi più piccoli hanno lo scopo di consentire ai tecnici pubblicitari di combinare le etichette per creare i propri esperimenti di varie dimensioni. I gruppi non si sovrappongono.

Tieni presente che le etichette control_1.* sono destinate a essere utilizzate come "Controllo 1" come illustrato nelle linee guida sui test di settore della CMA, quindi i partecipanti ai test non devono utilizzare l'API Topics o eseguire aste Protected Audience per questo traffico. Poiché le etichette non influiscono sul comportamento del browser, i partecipanti non devono trasmettere argomenti osservati o eseguire aste Protected Audience quando rilevano le etichette del gruppo control_1.*.

Siamo lieti di ricevere feedback per sapere se questa selezione di gruppi soddisfa le esigenze delle organizzazioni partecipanti.

Etichetta	% di traffico stabile
control_1.1	0,25
control_1.2	0,25
control_1.3	0,25
control_1.4	0,25
label_only_1	1,5
label_only_2	1,5
label_only_3	1,5
label_only_4	1,5
label_only_5	1,5

I gruppi di browser in modalità A label_only_ sono disponibili da novembre 2023, mentre i gruppi di modalità A control_1_* sono stati resi disponibili a partire dal 4 gennaio 2024.

Modalità B: disattiva l'1% dei cookie di terze parti

Dal 4 gennaio 2024, Chrome ha disattivato i cookie di terze parti per circa l'1% dei browser stabili di Chrome (e anche nei browser Dev, Canary e Beta nel quarto trimestre del 2023). Le organizzazioni che testano le API PS R&M non devono attivare questa modalità, poiché verrà applicata in modo uniforme all'intera popolazione del browser. Esiste, ovviamente, la possibilità che alcune funzionalità del sito siano interessate se il sito non ha ancora adottato una soluzione alternativa, come i CHIPS o gli insiemi di siti web correlati.

Inoltre, prevediamo di fornire una piccola porzione di traffico all'interno della modalità B con le API PS R&M disabilitate. Le altre API, come insiemi di siti web correlati, CHIPS e FedCM, non verranno disattivate. Prevediamo che questa combinazione sarà utile per stabilire una base di prestazioni per i browser senza cookie di terze parti e senza le API PS R&M.

Come parte della modalità B, forniamo anche le etichette per i browser interessati. Le etichette sono disponibili contemporaneamente alle API disabilitate. Proporremo di dividere la popolazione in tre gruppi treatment_1.* in cui i cookie di terze parti sono disabilitati, ma sono disponibili le API PS R&M e un gruppo control_2 in cui sia i cookie di terze parti sia le API PS R&M sono disabilitati.

Per facilitare il debug delle integrazioni dell'API Attribution Reporting e dell'API Private Aggregation e per aiutare i partecipanti al test a comprendere meglio l'impatto del rumore, i report di debug ARA e i report di debug di aggregazione privata rimarranno disponibili per i browser in modalità B, a condizione che l'utente non abbia bloccato esplicitamente i cookie di terze parti. I report di debug non saranno disponibili in control_2, poiché le API PS R&M non sono disponibili in questa sezione. I report di debug verranno comunque eliminati insieme all'eliminazione graduale dei cookie di terze parti.

• Per l'API Attribution Reporting, poiché i cookie di terze parti sono disabilitati, l'origine report non potrà impostare il cookie ar_debug e dovrebbe basarsi sull'impostazione dei campi debug_key (per i report sull'attribuzione riuscita) e dei campi debug_reporting (per i report dettagliati) per attivare o disattivare la ricezione dei report di debug.
• Per l'API Private Aggregation, l'origine report deve basarsi sulla chiamata a enableDebugMode() per controllare l'attivazione della ricezione dei report di debug. Le aziende dovrebbero continuare a considerare in che modo gli obblighi normativi potrebbero applicarsi all'utilizzo dell'API Attribution Reporting e dell'API Private Aggregation, compresi i report di debug.

La modalità A continua a essere eseguita e questi gruppi sono distinti dai gruppi in modalità A, perché un utente si troverà in modalità A, modalità B o nessuna delle due. I partecipanti al test devono utilizzare il traffico control_1.* come gruppo di controllo che rappresenta lo status quo con i cookie di terze parti.

Etichetta	% di traffico stabile
treatment_1.1	0,25
treatment_1.2	0,25
treatment_1.3	0,25
control_2	0,25

Chrome ha inoltre limitato i cookie per il 20% dei client Chrome Canary, Dev e Beta.

Etichetta	% di traffico prestabile
prestable_treatment_1	10%
prestable_control_2	10%

L'inclusione in uno di questi gruppi sperimentali avrà lo stesso effetto dei gruppi stabili equivalenti.

Come per la modalità A, non è garantita la disponibilità delle API PS R&M, in quanto gli utenti possono disattivarle dalle impostazioni di privacy e sicurezza di Chrome. Allo stesso modo, non è garantita la disattivazione dei cookie di terze parti per tutti i membri del gruppo control_2, poiché gli utenti possono accedere all'interfaccia utente del browser per consentire i cookie di terze parti per un sito.

Monitoraggio degli esperimenti

Assicurati di monitorare il volume di traffico relativo di ogni etichetta sperimentale e di controllo. treatment_1.1 dovrebbe avere circa la stessa quantità di traffico di treatment_1.2 e treatment_1.3.

Ti consigliamo di procedere con cautela in merito al traffico contenente etichette provenienti da versioni di Chrome precedenti alla versione 120. Se il tuo team che in genere gestisce il traffico non valido identifica user agent che presentano caratteristiche di traffico non valido, avrebbe senso filtrarli dai risultati dei test.

Etichette pre-periodi

Fino a gennaio 2024, abbiamo eseguito pre-periodi per più gruppi sperimentali, ovvero un periodo di tempo per consentire a Chrome di dimensionare e selezionare con precisione i gruppi statisticamente imparziali. Questi pre-periodi sono stati eseguiti per tutti i gruppi il cui inizio era programmato a gennaio: i gruppi Modalità B e i gruppi Control_1.* In questo caso non è necessario alcun intervento da parte dello sviluppatore o del sito: questi gruppi di pre-periodi non riscontreranno alcun cambiamento nel comportamento o nella disponibilità dell'API, ma tieni presente che in alcune situazioni potresti visualizzare un'etichetta preperiod. Anche se i browser che ricevono l'etichetta preperiod potrebbero passare a uno dei gruppi sperimentali, questa operazione non è garantita, pertanto è consigliabile non presumere che i browser con questa etichetta siano inclusi nell'esperimento.

Un gruppo sperimentale è un sottoinsieme della popolazione analizzata: in questo caso, uno dei gruppi etichettati.

Accedi alle etichette utilizzando il valore Ritiro dei cookie

Per la durata delle modalità A e B abbiamo introdotto un valore Cookie-Deprecation temporaneo accessibile tramite un'intestazione HTTP attivabile e un'API JavaScript, che fornisce l'etichetta per il gruppo di esperimenti Modalità A o B applicabile del browser (come definito dalle percentuali sopra), se rientra in una di queste.

L'accesso alle etichette comporta l'accesso alle informazioni memorizzate sul dispositivo dell'utente. In alcune giurisdizioni (come UE e Regno Unito), siamo consapevoli che questa attività è analoga all'uso dei cookie e che quindi l'accesso alle etichette richiede probabilmente il consenso dell'utente finale. Prima di iniziare a richiedere le etichette, ti consigliamo di chiedere una consulenza legale per sapere se questo obbligo di consenso si applica al tuo caso.

Accedi all'intestazione HTTP Sec-Cookie-Deprecation

Per ricevere l'intestazione della richiesta Sec-Cookie-Deprecation, un sito deve prima impostare il cookie receive-cookie-deprecation. Questo cookie deve utilizzare l'attributo Partitioned, il che significa che l'attivazione della ricezione dell'intestazione deve essere effettuata per ogni sito di primo livello.

Ad esempio, se 3p-example.site vuole ricevere l'intestazione Sec-Cookie-Deprecation nelle sue risorse incorporate in example.com, 3p-example.site deve impostare il seguente cookie in quel contesto.

Set-Cookie: receive-cookie-deprecation=1; Secure; HttpOnly; Path=/; SameSite=None; Partitioned;  Max-Age=15552000

Gli attributi dei cookie Secure, HttpOnly, SameSite e Partitioned sono obbligatori. Gli altri attributi Domain, Path, Expires e Max-Age possono essere impostati in base alle tue esigenze, anche se Path=/ è un buon valore predefinito. In questo esempio, il valore Max-Age=15552000 viene impostato in modo che il cookie non scada prima di 180 giorni.

Ti consigliamo di iniziare a impostare il cookie receive-cookie-deprecation=1 prima dell'inizio del periodo di test agevolato da Chrome per assicurarti che i browser in un gruppo sperimentale includano l'intestazione della richiesta Sec-Cookie-Deprecation non appena diventa disponibile.

Ad esempio, supponendo che il browser sia nel gruppo example_label_1, le richieste successive che includono questo cookie includeranno anche l'intestazione Sec-Cookie-Deprecation.

Sec-Cookie-Deprecation: example_label_1

Se il browser non fa parte di un gruppo, non verrà inviata alcuna intestazione. Le etichette sono legate alla presenza del cookie, quindi se il cookie viene eliminato, bloccato completamente o bloccato per il sito specifico, le etichette non verranno inviate. Poiché l'attributo Partitioned è destinato a continuare a essere utilizzato dopo il ritiro completo dei cookie di terze parti, ciò significa che i cookie di Partitioned potrebbero essere impostati quando i cookie di terze parti sono bloccati.

Accedi all'API cookieDeprecationLabel JavaScript

È possibile accedere al valore Cookie-Deprecation anche utilizzando l'API JavaScript navigator.cookieDeprecationLabel.getValue(). Verrà restituita una promessa che si risolve in una stringa contenente l'etichetta di gruppo applicabile. Ad esempio, se il browser si trovava nel gruppo example_label_1:

// Feature detect temporary API first
if ('cookieDeprecationLabel' in navigator) {
 // Request value and resolve promise
 navigator.cookieDeprecationLabel.getValue().then((label) => {
   console.log(label);
   // Expected output: "example_label_1"
 });
}

Se il browser non fa parte di un gruppo, l'API non sarà disponibile o il valore sarà una stringa vuota, quindi assicurati di eseguire il rilevamento delle funzionalità.

L'API JavaScript può essere chiamata indipendentemente dalla presenza del cookie receive-cookie-deprecation. Tuttavia, se i cookie vengono bloccati completamente o in modo specifico per il sito, l'API non sarà disponibile o restituirà una stringa vuota.

Come per qualsiasi valore fornito dal client, assicurati di sanificare e convalidare il valore dall'intestazione o dall'API JavaScript prima dell'uso.

Demo e test

A partire da Chrome 120, sono disponibili flag per consentire agli sviluppatori locali di testare la richiesta e la lettura delle etichette.

Il flag chrome://flags/#tpc-phase-out-facilitated-testing consente di abilitare una selezione di etichette di test. Queste etichette sono precedute dal prefisso fake_ per differenziarle dalle etichette reali. L'attivazione del flag non comporta l'attivazione del browser in alcun gruppo sperimentale.

Puoi vedere le etichette in azione all'indirizzo goo.gle/cft-demo.

Poiché la registrazione viene applicata per le API di misurazione e pertinenza di Privacy Sandbox, potresti dover eseguire l'override dell'applicazione per i test locali utilizzando chrome://flags/#privacy-sandbox-enrollment-overrides e fornendo l'origine della demo. In alternativa, includi il seguente flag della riga di comando se esegui Chrome da un terminale: --args --disable-features=EnforcePrivacySandboxAttestations

Il menu a discesa con la bandierina include più opzioni. I tester saranno interessati principalmente alle voci contrassegnate come "Forza", in quanto assicurano che il comportamento dell'esperimento sia abilitato indipendentemente dalle altre configurazioni del dispositivo.

Per testare solo le etichette del gruppo sperimentale, seleziona "Abilitata forzata Controllo forza 1" o "Forza Solo LabelOnly attivata". In questo modo il browser invierà le etichette "fake_control_1.1" o "fake_label_only_1.1".

In Chrome M120 o versioni successive puoi utilizzare anche le voci che seguono.

Per testare il blocco dei cookie di terze parti, seleziona "Attivato il trattamento forzato". Verrà inviata l'etichetta del gruppo sperimentale "fake_treatment_1.1", ma verrà modificata anche la pagina delle impostazioni dei cookie e l'impostazione corrente dei cookie per bloccare i cookie di terze parti.

Per testare il blocco dei cookie di terze parti senza API per gli annunci privati, seleziona "Forza controllo 2". Questa operazione invierà l'etichetta del gruppo sperimentale "fake_control_2", aggiornerà la pagina delle impostazioni dei cookie, bloccherà i cookie di terze parti ed eliminerà anche le nuove API per gli annunci privati.

Tieni presente che esiste un problema per cui il browser rimane con la nuova pagina di impostazione dei cookie e la nuova impostazione che blocca i cookie di terze parti anche se disattivi il flag. Stiamo lavorando per risolvere il problema, ma nel frattempo puoi testare i valori di questi flag in una directory di dati di Chrome separata avviando Chrome con il flag della riga di comando --user-data-dir=<new dir>.

Feedback

Per gestire le domande, utilizziamo l'etichetta "chrome-testing" nel repository di assistenza per gli sviluppatori su GitHub. Apprezziamo il tuo feedback e le tue discussioni sulle domande iniziali:

• Hai intenzione di eseguire il test utilizzando la modalità A, la modalità B o entrambe?
• Scegliere le dimensioni delle etichette per i test agevolati da Chrome
• Utilizzo di client hint per i test agevolati da Chrome

Puoi anche sollevare nuove domande o discussioni nel repository utilizzando il modello "Test facilitati da Chrome".