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.
di Gemini Advanced.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.
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 campidebug_key
(per i report sull'attribuzione riuscita) e i campidebug_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.
Accedi alle etichette utilizzando il valore Ritiro dei cookie
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.
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 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](https://developers.google.cn/static/privacy-sandbox/assets/images/cft-flag.png?authuser=0000&hl=it)
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:
- 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 "Test facilitati da Chrome" modello.