Penandaan "sebelah pelayan": Adakah saya pergi ke sana atau saya tidak pergi ke sana?

Dengan timbulnya isu yang dikaitkan dengan Data, Privasi dan "Pihak Pertama" dalam pemasaran digital, subjek pengetegan "sebelah pelayan" sering muncul di atas meja. Persoalan asas, di bahagian pemanduan, ialah: "Perlukah saya pergi ke sana atau tidak?" atau, “Perlukah saya pergi sekarang atau nanti?” Dalam artikel ini, kami akan mencuba pendekatan sintetik untuk membantu dalam membuat keputusan.

Mise: 

Takrifan berguna: 

  • kuki pihak pertama: kuki yang dikaitkan dengan nama domain yang sama seperti tapak web yang dilawati. 
  • Kuki pihak ketiga (atau kuki pihak ketiga): kuki yang dikaitkan dengan domain yang berbeza daripada tapak web yang dilawati (selalunya domain platform pengiklanan).
  • DSB (Pencegahan Penjejakan Pintar) : Ciri privasi yang diperkenalkan oleh Apple pada Safari pada 2017.
  • TMS (Sistem Pengurusan Tag): sistem pengurusan tag

3 isu utama

Mula-mula, mari kita bincangkan tiga isu utama yang sering dibangkitkan dalam konteks strategi "sebelah pelayan". Untuk setiap isu ini, kami akan menangani impaknya dan perkara yang boleh dibawa oleh teknologi sebelah pelayan.

Masalah 1: Keyakinan terhadap Data (kualiti data)

Keputusan penting dibuat berdasarkan hasil yang diperhatikan dalam laporan Analitis Web. Kempen pengiklanan juga dilaraskan dan dioptimumkan berdasarkan data yang dikumpul. La kebolehpercayaan data oleh itu adalah a isu utama.

Dalam beberapa tahun kebelakangan ini, pelbagai peristiwa teknikal atau kawal selia telah memberi kesan kepada pengumpulan data:

  1. RGPD (peraturan) : kami kehilangan sebahagian daripada data.
  2. Penyekat iklan (teknikal) : kita kehilangan sebahagian lagi data.
  3. Safari / iOS / Firefox(teknikal) : kami masih kehilangan data (dengan ITP, sistem pencegahan penjejakan yang sangat mengehadkan penggunaan kuki)
  4. Kuki pihak ketiga Chrome (teknikal): dalam keadaan bersedia buat masa ini, tetapi kami menjangkakan perkembangan masa depan yang pastinya akan membawa kepada kehilangan data selanjutnya 

Mari kita lihat perkara yang berbeza ini dengan lebih dekat: 

1 – GDPR

Dari segi peraturan, sesetengah pelawat tidak memberikan persetujuan mereka. Biasalah, dah jadi. Dan kita mungkin juga jelas dari awal, idea sebelah pelayan bukanlah untuk mengatasi persetujuan !

ℹ️  Di Perancis, dianggarkan kira-kira 35% pengguna Internet tidak memberikan kebenaran mereka.
(sumber: Barometer Digital Credoc – 2022)

⚠️ Kesan: Sebahagian daripada data tidak dikumpul. KPI volumetrik dalam laporan Analitis Web kehilangan maknanya (perkadaran dan perkembangan kekal boleh digunakan Fungsi penyasaran pengiklanan adalah kurang tepat.

2 – Penyekat iklan

Sebilangan besar pengguna melengkapkan pelayar mereka alat tambah, dipanggil Penyekat iklan (penghalang iklan). Peranan alat ini adalah terutamanya untuk menghalang fungsi proses pemasaran/pengiklanan di tapak yang dilawati. Kadangkala, alatan ini malah boleh melangkaui objektif ini, sehingga menghalang Pengurus Teg daripada dimuatkan sama sekali.

Seperti yang telah kami katakan, pada asasnya, ini sudah tentu persoalan menghormati pilihan pengguna dari segi GDPR. Untuk ini, tapak web anda mungkin telah dilengkapi dengan pengurus persetujuan (Axeptio, Cookiebot, Didomi, dll.). 

Tetapi dengan memuatkan Pengurus Teg, menjalankan teg dan mengumpul data dengan mematuhi peraturan, anda hanya menjalankan tugas anda sebagai pengendali tapak web dan anda boleh menyasarkan matlamat untuk tidak membiarkan alat pematuhan anda menghalang.

ℹ️  Di Perancis, sekitar 30 hingga 40% pengguna Internet (desktop) menggunakan penyekat iklan

⚠️ Kesan: sebahagian tambahan data tidak dikumpul. Kesan titik sebelumnya (GDPR) diperkuatkan.

3 – ITP (Safari / Firefox…)

Sistem ITP (Pencegahan Penjejakan Pintar), yang dilancarkan pada 2017, bertujuan untuk menyekat penggunaan kuki. Ia hadir dalam pelayar Safari dan Firefox, antara lain.

Ia terutamanya menyekat kuki pihak ketiga dan membersihkan kuki pihak pertama selepas 1 hari.

ℹ️  Di Perancis, sekitar 32% pengguna Internet menggunakan Safari (sumber Statista)

⚠️ Kesan: Di sini, terutamanya keupayaan penyasaran atau model atribusi sistem pengiklanan pihak ketiga yang terjejas (kuki pihak ketiga disekat). Di bahagian Analitis Web, mereka tidak lagi dapat mengenali pengguna berulang dengan berkesan (kuki pihak pertama dibersihkan dalam masa 1 hingga 1 hari).

4 – Menyekat kuki pihak ketiga pada Chrome

Idea yang sama di sini: Selepas pertama kali menyebut a penangguhan susut nilai kuki pihak ketiga kepada 2025, Google baru-baru ini mengumumkannya kuki pihak ketiga pada Chrome akhirnya tidak akan ditamatkan (22/07/24). Walaupun segala-galanya, penyekatan kuki pihak ketiga ini masih menjadi masalah yang perlu ditangani. Walaupun perkembangan Chrome pada masa hadapan tidak akan terdiri daripada penyekatan secara terang-terangan, kami boleh menjangkakan bahawa ia akan memberikan lebih kawalan kepada pengguna dengan, sebagai akibatnya, perubahan pada fungsi semasa.

Terutamanya buzz sekitar titik ini yang menjana peningkatan minat baru-baru ini dalam teknologi bahagian pelayan.

ℹ️  Di Perancis, sekitar 57% pengguna Internet menggunakan Chrome (sumber Statista)

⚠️ Kesan: Ini akan menguatkan kesan titik sebelumnya (ITP) pada kuki pihak ketiga. Jadi terutamanya untuk perkara yang berkaitan dengan penyasaran kempen pengiklanan dan model atribusi (kejatuhan pulangan ke atas pelaburan pengiklanan atau ROAS).

secara ringkas, dengan mengurangkan kuantiti data yang dikumpul, jisim statistik secara semula jadi menjadi lemah. Kepercayaan terhadap data goyah dan strategi pemasaran kehilangan beberapa ketepatan dan keberkesanannya. 

Sumbangan pihak pelayan atas kepercayaan terhadap data: 

Mengenai isu pertama ini, pelaksanaan bahagian pelayan akan mengurangkan kesan had teknikal:

  • Kurangkan kesan penyekat Iklan (bergantung kepada penyelesaian teknikal yang digunakan).
  • Kurangkan kesan pengehadan pada Safari / Firefox (ITP).
  • Kurangkan kesan penyekatan pihak ketiga pada Chrome.

⚠️ Sila ambil perhatian, terdapat pelbagai cara untuk melaksanakan bahagian pelayan, memastikan kecekapan yang lebih atau kurang. Kami akan membincangkan cadangan kami dalam bidang ini pada akhir artikel.

👍 Dengan bahagian pelayan, pengumpulan data akan menjadi lebih luas dan lebih kualitatif, yang akan menguntungkan untuk mengoptimumkan strategi kempen pemasaran dan meningkatkan kualiti analisis khalayak.

 

Masalah 2: Kawal data yang dikumpul (tadbir urus data)

Di sisi pelanggan, skrip teg boleh mengumpul data tertentu tanpa ia benar-benar telus dan terkawal. Malah, agak sukar untuk menyemak apa yang sebenarnya ditangkap dan dihantar oleh tag.

Di bahagian pelayan, melaksanakan pengetegan melibatkan proses di mana setiap data yang ditangkap di sisi klien ditakrifkan dan dihantar ke teg bahagian pelayan.

Sumbangan pihak pelayan pada tadbir urus Data: 

Mengenai isu kedua ini, bahagian pelayan menyediakan: 

  • Jumlah keterlihatan data yang disampaikan oleh tag
  • Kawalan penuh bagi data ini yang disampaikan oleh tag (tanpa nama / pengubahsuaian data peribadi)
  • "Vendor" (Meta, Google, dll.) hanya mengakses data yang dikonfigurasikan pada teg dalam Pengurus Teg.

👍 Bahagian pelayan membolehkan anda mendapatkan semula kawalan ke atas data yang terlibat dalam Analitis Web dan proses Pemasaran Digital.

 

Isu 3: Kekalkan prestasi tapak web

Dalam sistem penandaan sisi klien, teg dimuatkan dan dilaksanakan oleh penyemak imbas pengguna.

Sesetengah teg, diambil secara individu, sudah agak berat (cth: Facebook Pixel). Tetapi jika digabungkan, kadangkala kami mempunyai caj terkumpul yang ketara dan memberi kesan untuk pelawat.

© Senyum

Sumbangan bahagian pelayan kepada prestasi tapak web: 

Mengenai isu prestasi, bahagian pelayan menyediakan: 

  • Pengoptimuman/penghadan kuantiti elemen yang diproses di sisi Klien.
  • Sesuai untuk pengalaman pengguna (UX).
  • Sesuai untuk SEO.

👍 Bahagian pelayan menggalakkan prestasi laman web dan SEO.

 

The "sebelah pelayan", kézako?

Tetapi Jamy, apakah itu teg "sebelah pelayan"?

Biasanya teg penjejakan dilaksanakan pada penyemak imbas pelanggan. Pertukaran data adalah terus antara penyemak imbas pelawat dan platform pemasaran atau analitik. Kami kemudian bercakap tentang teg "sebelah pelanggan".

Bahagian pelanggan: 

  • Setiap teg dimuatkan/dilaksanakan oleh penyemak imbas.
  • Setiap teg mengumpul datanya (selalunya sama seperti teg lain).

Dalam kes teg sisi pelayan, maklumat dihantar dari sisi klien ke bekas lain yang dihoskan pada pelayan di awan, melalui teg tunggal yang bertindak sebagai "pengangkut". Teg kemudiannya dilaksanakan dengan data ini daripada pelayan ke platform pemasaran atau analitik.

Di sisi pelayan: 

  • Hanya satu teg koleksi dimuatkan oleh penyemak imbas.
  • Teg koleksi tunggal mengambil data dan menjadikannya tersedia untuk teg sisi pelayan.

© Senyum

Ok, tapi apa gunanya?

Terima kasih kepada fakta bahawa tag dilaksanakan daripada pelayan dan bukannya penyemak imbas/pelanggan, kami memperoleh ciri-ciri berikut: 

  • Teg sebelah pelayan tidak meletakkan kuki pihak ketiga pada penyemak imbas pelawat. Walau bagaimanapun, kuki yang diletakkan oleh pelayan menjadi pihak pertama. 
  • Teg sebelah pelayan hanya boleh menghantar data yang diterima oleh titik masuk tunggal daripada klien.
  • Teg sebelah pelayan tidak dijalankan pada pelayar pelawat. 

Ini kemudiannya memberikan kelebihan utama ini: 

  • Kualiti data yang dipertingkatkan
    Dengan mengehadkan kesan Penyekat iklan atau pengehadan yang dikaitkan dengan kuki pihak ketiga, kami mengumpul lebih banyak data.
  • Kawalan data yang dikumpul
    Dengan menguruskan paip data ke teg sisi pelayan, anda memperoleh semula kawalan ke atas perkara yang dihantar dan oleh itu dikumpulkan.
  • Pengoptimuman des temps de chargement
    Dengan menjalankan bahagian pelayan tag, kami mengurangkan kerja penyemak imbas. Ini menuju ke arah meningkatkan pengalaman pengguna dan pengoptimuman SEO.
  • Kaedah yang lebih mampan
    Evolusi peraturan dan teknologi cenderung untuk meningkatkan minat bahagian pelayan. Dengan menyertai kapal yang cukup awal, kami boleh mengharapkan kemampanan yang baik, berbanding segala-galanya yang berkisar tentang kuki dan pihak pelanggan

 

Beberapa idea prasangka

  • Bahagian pelayan membolehkan anda memintas Penyekat iklan

Pada pendapat saya, ini sedikit benar dan sedikit palsu :cIni bukan tujuan utama bahagian pelayan. Namun begitu, memang benar

Ini bukan tujuan utama bahagian pelayan. Walau bagaimanapun, sebenarnya, secara logiknya dengan menghantar teg sisi pelayan, ini tidak lagi akan dihalang.

Tetapi untuk menjadikan pengetegan sebelah pelayan berfungsi, tapak anda mesti terus menggunakan bekas Pengurus Teg sebelah klien dengan teg yang dipautkan ke bahagian pelayan. Teg "jambatan" ini mungkin kekal disekat oleh penyekat Iklan. Dalam kes ini, kami tidak boleh mengatakan bahawa bahagian pelayan memintas Penyekat Iklan. Perkara yang sama jika Penyekat Iklan menyekat sepenuhnya Pengurus Teg.

Ringkasnya, bahagian pelayan itu sendiri tidak mencukupi untuk memintas Penyekat Iklan.

Kami akan menyebut sedikit kemudian dalam artikel ini bahawa teknik pelaksanaan lanjutan memungkinkan untuk mengehadkan kesan Penyekat Iklan.

  • Bahagian pelayan membolehkan anda untuk tidak memuatkan apa-apa pada bahagian pelanggan

Di sini juga, ia adalah untuk layak dan patas sebab yang sama: Malah, kebanyakan masa apabila kita bercakap tentang penandaan sisi pelayan, kita sebenarnya bercakap tentang "Pelanggan ke Pelayan ke Pelayan". Ambil perhatian bahawa terdapat jenis pelaksanaan lanjutan yang membenarkan Pelayan ke Pelayan (dengan Protokol Pengukuran, dikhaskan untuk pakar).

Untuk menjadikan pengetegan sebelah pelayan "klasik" berfungsi, tapak anda mesti terus menggunakan bekas Pengurus Teg sebelah klien dengan teg yang menjadikan "jambatan" ke bahagian pelayan. Jadi, dalam semua kes, masih terdapat proses di bahagian pelayar/pelanggan.

Tetapi sebenarnya, tag tertentu akan dipindahkan ke bahagian pelayan. 

Ringkasnya, bahagian pelayan (klasik) boleh mengurangkan beban pihak pelanggan, tetapi tidak menghapuskannya sepenuhnya.

  • Bahagian pelayan bagus, tetapi mahal

Jadi, mengenai subjek kos, semuanya adalah relatif (sekali lagi!?): Jika kita hanya melihat kos langsung penyelesaian dan masa pakar yang diperlukan untuk pelaksanaan, ia boleh menjadi sejuk (jika tidak, kita tidak melakukan apa-apa dan kita jangan membelanjakan apa-apa tambahan).

Tetapi jelas sekali, saya akan mencadangkan di sini untuk meluaskan sedikit refleksi: Saya menjalankan pengiraan pantas pada sudut alas meja (ok... saya menggunakan hamparan) yang saya ingin kongsikan dengan anda: 

Mari kita mulakan dengan hipotesis e-peruncit yang menjalankan kempen SEA menggunakan penyasaran semula. Kami mempunyai beberapa KPI yang tersedia:

  • Dia membelanjakan €5/bulan di SEA.
  • Purata CPCnya ialah €1,5/klik.
  • Bakul puratanya ialah €140 dengan margin kasar 40%.
  • Beliau memerhatikan purata kadar penukaran daripada SEA sebanyak 3%.

Segala-galanya berjalan lancar dalam dunia yang terbaik dan semuanya berjalan lancar dengan sekitar 100 penukaran sebulan dan jumlah margin kasar yang dijana sebanyak €7 / bulan. Kesan langsung SEA adalah positif pada + €000 / bulan (margin kasar – perbelanjaan CPC). Dan kemudian satu "hari yang baik", kami mengurangkan keupayaan penyasarannya kerana kemas kini Chrome yang menyekat kuki pihak ketiga… Dari situ, kempennya menjadi kurang berkesan, dia melihat kadar penukarannya menurun kepada 2%. Dia kemudian kehilangan €2 dalam margin setiap bulan, hanya untuk -1% kadar penukaran… 

Saya akan membenarkan anda merancang lebih awal dan membayangkan senario lain. Tetapi secara ringkasnya, meletakkan kos bahagian pelayan dalam perspektif, ia secara amnya agak meyakinkan. Apa yang mungkin mahal tidak melakukan apa-apa.

Bagaimana kita melakukannya?

Jadi, persoalannya agak luas. Memandangkan saya telah menghabiskan banyak masa berharga anda (dan pakar yang jauh lebih berpengetahuan daripada saya mengenai subjek itu sudah menawarkan sumber yang sangat baik), saya akan cuba meringkaskan cara saya melihat sesuatu dengan cara yang ringkas dan ringkas:

  • Kaedah 1: "sekolah lama"

Pelanggan membuka instance pelayan untuk kami di awan (selalunya di Google Cloud Platform kerana ia ditawarkan secara langsung oleh Google Tag Manager), kami menyediakan segala-galanya untuk mengangkut data dari bahagian klien ke bahagian pelayan... Kami melakukannya ujian, kami melihat tag sebelah pelayan pergi... semuanya baik-baik saja. Kami melakukan bahagian pelayan!

Tetapi... tanpa disedari serta-merta, kami mempunyai teg 'jambatan' pihak pelanggan yang disekat oleh penyekat iklan... kami mempunyai pengurus teg kontena pihak pelanggan yang disekat oleh Penyekat iklan... kami mungkin menghadapi masalah pada contoh Google Cloud untuk isu pengebilan yang tidak diuruskan oleh pelanggan… kami mungkin menghadapi masalah dengan data yang kurang dikumpul… dsb.

Kami dengan cepat mendapati diri kami mempunyai risiko kuat yang dikaitkan dengan kekurangan pemantauan dan kesan 'kotak hitam'. Ringkasnya, kami akan sampai ke sana, tetapi hei, ia penuh dengan sedikit kerumitan, selalunya agak licik dan memberi kesan untuk prestasi operasi "sebelah pelayan" anda.

  • Kaedah 2: Bergantung pada penyelesaian/rakan kongsi pakar

Dan kemudian, satu hari yang baik, kami mendapati di forum data/pemasaran, atau dalam artikel blog, bahawa syarikat Perancis menawarkan platform dan perkhidmatan yang bertindak balas terhadap isu ini.

Kami tidak lagi bersendirian, pakar sebenar ada untuk menyokong anda. Alat sangat memudahkan pelaksanaan. Platform sentiasa berubah.

Pendek kata, semuanya sangat mengatasi kaedah "sekolah lama".

Rakan kongsi teknologi ini ialah Addingwell. Dan tidak, saya tidak mempunyai tindakan dengan mereka (terlalu buruk). Memang ada jurang (yang tidak logik). Kami dengan cepat melihat bahawa mereka tahu subjek mereka dengan baik dan semua yang mereka letakkan secara langsung bertindak balas kepada isu konkrit. Kami mendapat keuntungan yang besar dalam masa pemasangan, kemungkinan dan kebolehpercayaan.

Kesimpulan

Adakah saya perlu pergi ke sana atau tidak?

  • Teruskan! Memandangkan isu data dan prestasi yang sudah wujud, dan isu yang akan datang, anda perlu meletakkan diri anda pada teknologi ini (kecuali jika anda tidak melakukan sebarang pemerolehan/pengiklanan trafik langsung).

Adakah saya perlu pergi sekarang atau nanti?

  • Anda melihatnya, tetapi jangan tunggu terlalu lama: Apabila perubahan seterusnya pada Chrome yang berkaitan dengan kuki pihak ketiga tiba (2025?), terdapat risiko kesesakan lalu lintas permintaan pelaksanaan bahagian pelayan.

Dan bagaimana saya melakukannya?

  • Anda memanggil UX-Republic (secara rawak).
    • Kami akan mengkaji keperluan dan mungkin mencadangkan agar rakan kongsi kami Addingwell menyertai kami untuk menghasilkan projek yang sesuai untuk anda.

    Walau apa pun, kami tidak mengesyorkan pergi ke sana tanpa ditemani. Kerumitan menyediakan pengetegan sebelah pelayan adalah satu langkah di atas pelaksanaan pihak klien (yang mungkin agak rumit).

 

 


Laurent Neuville, Perunding Analitis Web Kanan di Smile