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 intende offrire e come accedere le etichette del gruppo sperimentale.

In questo contesto, il browser Chrome fa riferimento al client Chrome, ovvero su un dispositivo. I dati di ogni singolo utente Google Cloud 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, l'intestazione di una richiesta valore 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 è stato disattivato a livello globale cookie di terze parti 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 CMA per garantire che queste modalità di test siano in linea con il framework di test (e tempistiche) per le terze parti come indicato nelle relative indicazioni sui test di settore. Di conseguenza, la CMA prevede che i risultati dei test in queste modalità può essere utilizzato nella sua valutazione di Privacy Sandbox. La CMA ha indicato che dia maggiore peso ai risultati della Progettazione sperimentale 2, che utilizza le etichette Modalità B e Controllo Modalità A 1. 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 Cookie-Deprecation da un'intestazione HTTP o dall'API JavaScript. Vedi la sezione successiva Accesso alle etichette utilizzando il valore Ritiro dei cookie per i dettagli dell'implementazione.

Invieremo questa proposta anche tramite il solito processo di sviluppo di Blink, in cui verranno finalizzati il design tecnico e il traguardo del 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 ad 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, in questo modo più partecipanti possono 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 delle 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 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 che dispongono di tale dell'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 sono permanenti per tutta la durata di una sessione di navigazione in Chrome. tra una sessione e l'altra. Tuttavia, questo non è garantito, poiché si verificano rari casi in cui la reimpostazione completa del 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 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 o 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.*.

Diamo il benvenuto feedback per capire se questa selezione di gruppi soddisfa le esigenze di le tue organizzazioni.

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

In modalità A i gruppi di browser label_only_ sono disponibili da novembre 2023 e I gruppi control_1_* in 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 attiva questa modalità, che verrà applicata in modo uniforme all'intero browser popolazione. Esiste, naturalmente, la possibilità che alcune funzionalità del sito vengano colpito se il sito non ha ancora adottato una soluzione alternativa, come CHIPS o Insiemi di siti web correlati.

Inoltre, prevediamo di fornire una piccola porzione di traffico nella modalità B che ha le API PS R&M disabilitate. Altre API, come insiemi di siti web correlati, CHIPS e FedCM non verrà disattivato. Prevediamo che questa combinazione sarà utile per stabilire una base di riferimento per le prestazioni dei 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. La le etichette sono disponibili contemporaneamente alle API disabilitate. Stiamo propone di dividere la popolazione in tre gruppi treatment_1.* dove i cookie di terze parti sono disabilitati, ma sono disponibili le API PS R&M e Gruppo control_2 dove sia i cookie di terze parti sia le API PS R&M disattivata.

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. Report di debug verrà comunque eliminata insieme alla rimozione dei cookie di terze parti.

  • Per l'API Attribution Reporting, poiché i cookie di terze parti sono disabilitati, la classe l'origine di segnalazione 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.

L'esecuzione della modalità A continua e questi gruppi sono distinti dai gruppi della modalità A, in un utente si troverà in modalità A, modalità B o nessuna delle due. Partecipanti al test deve utilizzare il traffico control_1.* come gruppo di controllo che rappresenta lo stato 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 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. La quantità di traffico di treatment_1.1 deve essere circa la stessa di treatment_1.2 e treatment_1.3.

Ti consigliamo di usare discrezione in merito al traffico contenente etichette provenienti Versioni di Chrome precedenti alla 120. Se il tuo team che solitamente gestisce traffico non valido identifica user agent che presentano caratteristiche di non valido traffico, allora avrebbe senso escluderli dai risultati dei test.

Etichette pre-periodi

Fino a gennaio 2024, abbiamo eseguito pre-periodi per più gruppi sperimentali: un periodo di tempo per consentire a Chrome di dimensionare e selezionare con precisione i gruppi imparziali. Questi pre-periodi sono stati eseguiti per tutti i gruppi pianificati inizieranno a gennaio: i gruppi Modalità 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. Mentre i browser che ricevono L'etichetta preperiod potrebbe passare a uno dei gruppi sperimentali, non è pertanto, raccomandiamo di non presupporre che i browser con questa etichetta nell'esperimento.

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

Per quanto riguarda le modalità A e B, abbiamo introdotto un Valore 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. Nella giurisdizioni (come UE e Regno Unito), comprendiamo che questa attività analoghi all'uso dei cookie e quindi l'accesso alle etichette richiede probabilmente consenso dell'utente. Prima di iniziare a richiedere le etichette, ti consigliamo di cercare consulenza legale se questo obbligo di consenso si applica alla tua persona.

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 a 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. Gli altri attributi: Domain, Path, Expires e Max-Age possono essere impostato in base alle tue esigenze, anche se Path=/ è un buon valore predefinito. L'esempio qui imposta Max-Age=15552000 in modo che il cookie non scada prima che 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, supponendo che il browser sia nel gruppo example_label_1, le successive le richieste che includono questo cookie includeranno anche Sec-Cookie-Deprecation intestazione.

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, bloccati completamente o bloccati per un sito specifico, le etichette non saranno 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.

Accedi all'API cookieDeprecationLabel JavaScript

È possibile accedere al valore Cookie-Deprecation anche utilizzando il metodo API navigator.cookieDeprecationLabel.getValue() JavaScript. Verrà restituito che si risolve in una stringa contenente l'etichetta di gruppo applicabile. Per Ad esempio, se il browser è 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 oppure il valore sarà una stringa vuota, quindi assicurati di eseguire il rilevamento delle caratteristiche.

L'API JavaScript può essere chiamata a prescindere dalla presenza del componente receive-cookie-deprecation cookie. 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 viene applicata per la pertinenza e la misurazione di Privacy Sandbox API, potresti dover eseguire l'override dell'applicazione forzata per i test locali utilizzando chrome://flags/#privacy-sandbox-enrollment-overrides e la fornitura della demo origine dati. 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 per i test agevolati 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". Ciò comporterà l'invio da parte del browser "controllo_fake_1.1" o "fake_label_only_1.1" etichette.

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". 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 API per gli annunci privati, seleziona "Forza Controllo 2". Il comando "fake_control_2" verrà inviato etichetta gruppo sperimentale, aggiorna la pagina delle impostazioni dei cookie, bloccare i cookie di terze parti ed eliminare anche il nuovo le API di annunci privati.

Nota: 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

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

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