Divi dažādi uzdevumi

Kad apmeklētājs izdara piekrišanas izvēli, jānotiek divām atsevišķām lietām. Pirmkārt, pārlūkam izvēle ir jāatceras, lai baneris neparādītos atkal katrā lapā un tagi zinātu, ko tiem atļauts darīt. Otrkārt, vēlāk jums var būt nepieciešams pierādīt, ka izvēle tika izdarīta, ko apmeklētājam rādīja un kad. Šos uzdevumus bieži veic dažādi glabāšanas mehānismi, un to sajaukšana rada reālas problēmas: banerus, kas turpina parādīties, izvēles, kas dažos pārlūkos pazūd, vai ierakstu trūkumu, ko uzrādīt, kad kāds to prasa.

Šis salīdzinājums aplūko trīs izplatītās iespējas — pirmās puses sīkdatnes, pārlūka glabātuvi, piemēram, localStorage, un servera puses piekrišanas ierakstus — un to, kur katra der.

1. iespēja: pirmās puses sīkdatnes

Sīkdatnes ir tradicionālā piekrišanas stāvokļa vieta. TCF CMP parasti glabā piekrišanas virkni pirmās puses sīkdatnē, un daudzi CMP tajā glabā arī savus preferenču datus.

Stiprās puses

• Serveris tās var nolasīt. Sīkdatne tiek nosūtīta ar katru pieprasījumu, tāpēc servera puses kods, malas loģika un servera puses tagošana var nolasīt izvēli, negaidot JavaScript.
• Koplietojamas starp apakšdomēniem. Sīkdatne, kas iestatīta jūsu reģistrējamajā domēnā, var aptvert www, blog un shop apakšdomēnus.
• Plaši sagaidītas. Daudzas reklāmu tehnoloģiju integrācijas meklē piekrišanu sīkdatnēs.

Vājās puses

• Izmēra ierobežojumi. Pārlūki ierobežo sīkdatnes izmēru līdz aptuveni 4 KB, un TCF virkne ar daudziem piegādātājiem plus citas vērtības var tam tuvoties.
• Pieprasījumu slodze. Katrs pieprasījums jūsu domēnam nes sīkdatni, ieskaitot attēlu un skriptu pieprasījumus.
• Darbības laika ierobežojumi dažos pārlūkos. Safari Intelligent Tracking Prevention ierobežo ar JavaScript izveidotu sīkdatņu maksimālo darbības laiku līdz septiņām dienām. Sīkdatnes, ko iestata jūsu pašu serveris HTTP atbildē, parasti tiek vērtētas labvēlīgāk, lai gan ir izņēmumi.

2. iespēja: localStorage un cita pārlūka glabātuve

Daži CMP detalizētas preferences glabā localStorage, dažkārt līdzās mazākai sīkdatnei.

Stiprās puses

• Vairāk vietas. Vairāki megabaiti uz izcelsmi, pietiekami detalizētām izvēlēm piegādātāju līmenī.
• Nav pieprasījumu slodzes. Serverim nekas netiek sūtīts automātiski.

Vājās puses

• Serverim neredzama. Servera puses kods un malas loģika to nevar nolasīt, tāpēc jebkuram servera puses lēmumam jāgaida pārlūks.
• Piesaistīta vienai izcelsmei. Glabātuve vietnē www.example.com nav pieejama vietnē shop.example.com, tāpēc apmeklētājs baneri var redzēt atkal katrā apakšdomēnā.
• Pakļauta dzēšanai. Safari var dzēst ar skriptu ierakstāmu glabātuvi, ieskaitot localStorage, vietnēm, ar kurām lietotājs septiņas pārlūkošanas dienas nav mijiedarbojies, un privātās pārlūkošanas režīmi to parasti iztīra, kad sesija beidzas.

3. iespēja: servera puses piekrišanas ieraksti

Servera puses ieraksts ir ieraksts, ko jūs vai jūsu CMP nodrošinātājs saglabā ikreiz, kad tiek izdarīta izvēle. Tas parasti satur pseidonīmu identifikatoru, laika zīmogu, izvēles, parādīto banera vai politikas versiju un kontekstu, piemēram, reģionu.

Stiprās puses

• Ilgtspējīgs pierādījums. Tas pārdzīvo sīkdatņu tīrīšanu un pārlūka ierobežojumus, kas padara to par piemērotu rīku, lai parādītu, ka piekrišana tika saņemta.
• Auditējams. Varat ziņot par izvēlēm laika gaitā un atbildēt uz jautājumiem par konkrētiem notikumiem.
• Starpierīču potenciāls. Pieteikušamies lasītājiem servera ieraksts var sinhronizēt izvēles starp ierīcēm, ja to viņiem paskaidrojat.

Vājās puses

• Nav vietējā stāvokļa aizstājējs. Pārlūkā esošajiem tagiem joprojām vajadzīgs ātrs, lokāls signāls; servera izsaukšana katrā lapas skatījumā, lai meklētu piekrišanu, pievieno latentumu.
• Tie paši ir personas dati. Ierakstiem nepieciešams glabāšanas periods, piekļuves kontrole un vieta jūsu privātuma paziņojumā.
• Atkarība no identifikatora. Anonīmus apmeklētājus var sasaistīt ar ierakstu tikai ar identifikatoru, kas glabājas viņu ierīcē, kas jūs atgriež pie vietējās glabātuves.

Salīdzinājums blakus

• Labākais izvēles atcerēšanai tīmeklī: pirmās puses sīkdatnes, ideālā gadījumā jūsu servera iestatītas ar stabilu darbības laiku.
• Labākais detalizētiem preferenču datiem pārlūkā: localStorage, pārī ar sīkdatni, ko serveris var nolasīt.
• Labākais izvēles pierādīšanai: servera puses ieraksti.
• Sliktākā vienas iespējas izvēle: paļauties tikai uz localStorage, kas atstāj serveri aklu un izvēli trauslu dažos pārlūkos.

Praktiska kombinēta pieeja

1. Glabājiet autoritatīvo vietējo signālu — piemēram, TCF virkni un kompaktu preferenču ierakstu — pirmās puses sīkdatnē, kas aptver jūsu reģistrējamo domēnu.
2. Izmantojiet localStorage tikai papildu datiem, kuriem nav jānonāk serverī.
3. Rakstiet servera puses ierakstu par katru izvēli, ieskaitot parādīto banera un politikas versiju.
4. Ja saglabātā izvēle pazūd, rādiet baneri atkal, nevis pieņemiet iepriekšēju atbildi.
5. Iestatiet saglabāto izvēļu atkārtotas pieprasīšanas periodu un reģistrējiet to savā politikā.

Paša apmeklētāja piekrišanas izvēles glabāšana parasti tiek uzskatīta par nepieciešamu, lai sniegtu apmeklētāja pieprasīto pakalpojumu — atcerēties viņa lēmumu — taču pārbaudiet norādījumus, kas piemērojami jūsu galvenajos tirgos.

Galvenie secinājumi

• Izvēles atcerēšanās un izvēles pierādīšana ir atšķirīgi uzdevumi, kam vajadzīga atšķirīga glabātuve.
• Sīkdatnes serveris var nolasīt un tās var koplietot starp apakšdomēniem, taču tās ir ierobežotas izmērā un Safari pārlūkā — darbības laikā, ja iestatītas ar skriptu.
• localStorage piedāvā vietu, bet ir serverim neredzama, un pārlūki to var iztīrīt.
• Servera puses ieraksti ir pierādījumu slānis, nevis vietējā signāla aizstājējs.
• Apvienojiet servera iestatītu pirmās puses sīkdatni, izvēles pārlūka glabātuvi un servera ierakstus.