Test agevolati da Chrome

Per prepararti al ritiro dei cookie di terze parti, ti forniamo Modalità di test agevolate da Chrome che consentono ai siti di visualizzare l'anteprima del comportamento del sito e le funzionalità sono disponibili senza cookie di terze parti. Questa guida fornisce una panoramica delle modalità di test che Chrome prevede di offrire e su come accedere alle etichette dei gruppi sperimentali.

In questo contesto, il browser Chrome si riferisce a un client Chrome: un'installazione di Chrome su un dispositivo. Ogni singola directory di dati dell'utente costituisce un cliente distinto.

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

Etichetta: in questo contesto, un valore dell'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 tempo il periodo dei test agevolati da Chrome, garantendo che l'etichetta per un rimane coerente tra i tester.

di Gemini Advanced.

Abbiamo offerto due modalità distinte:

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

Dove vengono utilizzati i cookie di terze parti disattivate in modalità B, rimarranno disattivate durante l'eliminazione completa cookie di terze parti.

Abbiamo collaborato con la CMA per garantire che queste modalità di test siano in linea con il framework di test (e con le tempistiche) per terze parti, come stabilito nelle sue linee guida sui test di settore. Di conseguenza, la CMA prevede che i risultati dei test in queste modalità possano essere utilizzati nella valutazione di Privacy Sandbox. La CMA ha indicato che probabilmente darà maggiore peso ai risultati del Design sperimentale 2, che utilizza le etichette della modalità B e le etichette del gruppo di controllo 1 della modalità A. Consulta le Linee guida del CMA del 26 ottobre per ulteriori informazioni sulla progettazione sperimentale 2.

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

Invieremo questa proposta anche tramite la consueta processo di sviluppo di Blink, in cui verranno finalizzati il design tecnico e il traguardo di rilascio di Chrome. Anche se questa è l'implementazione che desideriamo fornire, vi forniremo ulteriori e l'approvazione significa che questi dettagli sono comunque soggetti a modifica. Continueremo aggiornare questa pagina man mano che i piani progrediscono e puoi continuare fornire feedback o domande.

Modalità A: gruppi di browser etichettati

Le organizzazioni che partecipano ai test potranno scegliere di ricevere un un insieme permanente di etichette per un sottoinsieme di browser Chrome, consentendo esperimenti coordinati tra diverse tecnologie pubblicitarie sullo stesso gruppo di browser. Ad esempio, se un browser rientra nel gruppo dell'esperimento label_only_3 (come mostrato nella tabella seguente), tutti i tecnici pubblicitari partecipanti potranno visualizza la stessa etichetta label_only_3 e coordinati di conseguenza: utilizza il PS le API R&M, ma non utilizzare cookie di terze parti. Ci aspettiamo che partecipino pagina per assicurarti che le etichette vengano inoltrate ad altri partecipanti per consentire Sperimentazione coerente durante l'intero processo di selezione degli annunci e misurazione.

Ad esempio, consente a più partecipanti di pubblicare aste Protected Audience senza cookie di terze parti in un gruppo coerente di browser. La i partecipanti all'asta inoltravano l'etichetta osservata agli acquirenti per facilitare test coordinati.

Le etichette non influiscono sul comportamento di queste istanze di Chrome, inclusa la disponibilità dei cookie di terze parti. Le etichette forniscono raggruppamento per esperimenti indipendenti e coordinati, ma la sua responsabilità di 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. Questo significa che dovrebbero essere disponibili sia i cookie di terze parti sia le API PS R&M, una parte degli utenti potrebbe aver utilizzato impostazioni o estensioni per modificarle o disattivarle le funzionalità di machine learning.

In genere, le etichette rimangono invariate per tutta la sessione di navigazione in Chrome e tra una sessione e l'altra. Tuttavia, non è garantito, in quanto esistono rari scenari in cui la reimpostazione completa di un browser può 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 le nostre proposta iniziale divide questa popolazione in nove gruppi. I sottogruppi più piccoli hanno lo scopo di consentire agli ad tech di combinare le etichette per creare esperimenti personalizzati di varie dimensioni. I gruppi non si sovrappongono.

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

Accogliamo con favore il feedback su come 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 label_only_ modalità A sono disponibili da novembre 2 2023, mentre i gruppi label_only_ modalità A sono stati resi disponibili a partire dal 4 gennaio 2024.

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

Chrome ha disattivato i cookie di terze parti per circa l'1% della versione stabile di Chrome browser dal 4 gennaio 2024 (e anche nelle versioni Dev, Canary e Beta durante il quarto trimestre del 2023). Le organizzazioni che testano le API PS R&M non devono attivare questa modalità, poiché viene applicata in modo uniforme all'intero browser popolazione. Alcune funzionalità del sito potrebbero essere messe in discussione se il sito non ha ancora adottato una soluzione alternativa, come CHIPS o Set di siti web correlati.

Inoltre, prevediamo di fornire una piccola parte del traffico nella modalità B per la quale sono disattivate le API di R&M di Play Console. Altre API, come Set di siti web correlati, CHIPS e FedCM, non verranno disattivate. Prevediamo che questa combinazione sarà utile per stabilire un benchmark del rendimento per i browser senza cookie di terze parti e senza le API R&M di Privacy Sandbox.

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

Per facilitare il debug dell'API Attribution Reporting e dell'aggregazione privata integrazioni dell'API e per aiutare i partecipanti al test a comprendere meglio il rumore l'impatto, i report di debug ARA e i report di debug di aggregazione privata essere ancora disponibile per i browser in modalità B, purché l'utente non abbia bloccare 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 continueranno a essere ritirati insieme all'eliminazione dei cookie di terze parti.

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

La modalità A continua a funzionare e questi gruppi sono distinti dai gruppi della modalità A, poiché un utente sarà in modalità A, in modalità B o in nessuna delle due. I partecipanti ai test devono utilizzare il traffico control_1.* come gruppo di controllo che rappresenta lo stato attuale 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 è garantito che le API di R&M per la privacy siano disponibili, poiché gli utenti possono disattivarle dalle impostazioni Privacy e sicurezza di Chrome. Analogamente, la disabilitazione dei cookie di terze parti non è garantita per ogni membro del Gruppo control_2, poiché gli utenti possono accedere all'UI del browser per consentire servizi di terze parti cookie per un sito.

Monitoraggio degli esperimenti

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

Ti consigliamo di usare cautela in merito al traffico contenente etichette provenienti da versioni di Chrome precedenti alla 120. Se il team che gestisce in genere il traffico non valido identifica gli agenti utente che presentano caratteristiche di traffico non valido, ha senso escluderli dai risultati dei test.

Etichette pre-periodi

Fino a gennaio 2024, abbiamo eseguito periodi precedenti per più gruppi sperimentali. Questi pre-periodi volte a consentire a Chrome di selezionare e selezionare le dimensioni con precisione i gruppi imparziali. Questi preperiodi sono stati eseguiti per tutti i gruppi pianificati per iniziare a gennaio: i gruppi Mode B e i gruppi Control_1.*. Non è necessario per lo sviluppatore o l'azione sul sito, questi gruppi pre-periodi non sperimenteranno di comportamento o disponibilità dell'API, ma tieni presente che potresti notare un'etichetta preperiod restituita in alcune situazioni. Sebbene i browser che ricevono l'etichetta preperiod possano passare a uno dei gruppi sperimentali, non è garantito, pertanto è consigliabile non presumere che i browser con questa etichetta siano inclusi nell'esperimento.

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

Per quanto riguarda le modalità A e B, abbiamo introdotto un Valore Sec-Cookie-Deprecation accessibile tramite un'intestazione HTTP di attivazione e JavaScript API, che fornisce l'etichetta per la modalità A o B del browser applicabile gruppo sperimentale (come definito dalle percentuali sopra), se rientra in uno di questi elementi.

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

Per ricevere l'intestazione della richiesta Sec-Cookie-Deprecation, un sito deve prima impostare il cookie receive-cookie-deprecation. Questo cookie deve utilizzare la proprietà Partitioned , il che significa che l'attivazione della ricezione dell'intestazione deve avvenire in base sito di primo livello.

Ad esempio, se 3p-example.site vuole ricevere Sec-Cookie-Deprecation sulle relative risorse incorporate in example.com, allora 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 obbligatorio. Puoi impostare gli attributi Domain, Path, Expires e Max-Age in base alle tue esigenze, anche se Path=/ è un'opzione predefinita valida. L'esempio riportato di seguito imposta Max-Age=15552000 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 garantire browser di un gruppo sperimentale includono Sec-Cookie-Deprecation non appena diventa disponibile.

Ad esempio, se il browser fa parte del 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 un'intestazione. Le etichette sono legate alla presenza del cookie, pertanto se il cookie viene eliminato, bloccato completamente o bloccato per il sito specifico, le etichette non verranno inviate. Poiché l'attributo Partitioned è destinato all'uso continuativo dopo i cookie di terze parti sono stati completamente deprecati. Ciò significa che i cookie Partitioned potrebbero possono essere impostati quando i cookie di terze parti sono bloccati.

Accedere all'API JavaScript cookieDeprecationLabel

È possibile accedere al valore Sec-Cookie-Deprecation anche utilizzando il metodo API navigator.cookieDeprecationLabel.getValue() JavaScript. Questo restituisce un che si risolve in una stringa contenente l'etichetta di gruppo applicabile. Per Ad esempio, se il browser fa parte del 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 del tutto, o specificamente per il sito, l'API non sarà disponibile oppure restituiscono una stringa vuota.

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

Demo e test

A partire da Chrome 120, sono disponibili flag per abilitare gli sviluppatori locali di richiedere e leggere le etichette.

Il flag chrome://flags/#tpc-phase-out-facilitated-testing ti consente di attivare una selezione di etichette di test. Queste etichette sono precedute dal prefisso fake_ a per distinguerli dalle etichette reali. L'attivazione del flag non consente di browser in uno qualsiasi dei gruppi sperimentali.

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

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

chrome://flags/#tpc-phase-out-facilitated-testing
Impostazioni dei flag di test facilitati da Chrome

Il menu a discesa con la bandierina include più opzioni. I tester saranno principalmente interessato alle voci contrassegnate con "Force" poiché assicurano che l'esperimento viene attivato indipendentemente dalle altre configurazioni del dispositivo.

Per testare solo le etichette del gruppo sperimentale, seleziona "Controllo forzato 1 attivato" o "Attivato Forza solo Etichetta". Di conseguenza, 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 seguenti voci.

Per testare il blocco dei cookie di terze parti, seleziona "Trattamento forzato abilitato". Questo invierà l'errore "fake_treatment_1.1" l'etichetta del gruppo sperimentale, ma modifica anche pagina delle impostazioni dei cookie e impostazione dei cookie corrente per bloccare i cookie di terze parti.

Per testare il blocco dei cookie di terze parti senza le API di annunci privati, seleziona "Forza gruppo di controllo 2". Verrà inviata l'etichetta del gruppo sperimentale "fake_control_2", aggiornata la pagina delle impostazioni dei cookie, bloccati i cookie di terze parti e rimosse le nuove API per gli annunci privati.

Tieni presente che si è verificato un problema per cui il browser rimarrà con il nuovo la pagina di impostazione dei cookie e l'impostazione che blocca i cookie di terze parti anche se disabilita il flag. Stiamo cercando di risolvere il problema, ma nel frattempo puoi puoi testare questi valori di flag in una directory di dati di Chrome separata avviando Chrome con il flag della riga di comando --user-data-dir=<new dir>.

Feedback

Utilizziamo l'etichetta "chrome-testing" nel repository di assistenza per gli sviluppatori su GitHub per gestire le domande. Diamo il benvenuto il tuo feedback e la discussione sulle domande iniziali:

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