| Arsip mwmag | [Files] [Up] | © 2002 PT Masterweb Media |
7 Trik Meningkatkan Pageview Apa Saja yang Dicatat Dalam Statistik Trik 4: [Tidak] Bermain-main Cache |
Anda ingin angka pageview situs Anda naik dua kali lipat? Tiga kali? Tidak perlu menguras kocek untuk beriklan, ada trik-trik untuk mencapainya.
Pemilik situs portal sering mendewakan angka pageview sebagai tolak ukur kinerjanya. Boleh-boleh saja. Tapi ketika angka ini dibawa dan dipamer-pamerkan untuk menarik pengiklan banner dan mengklaim popularitas, maka kita harus mempertanyakan balik: apa pageview sepenting itu? Dan apakah besaran tersebut valid menjadi tolak ukur? Masalah utamanya adalah, pageview terlalu mudah dimanipulasi. Dalam artikel ini kita akan membahas cara-caranya.
Disclaimer: Di setiap seri artikel Hack, penulis akan mengajak pembaca bermain-main dengan sebuah sistem dengan tujuan untuk mengenalnya lebih dalam. Kadang topik dan gaya bahasannya akan sedikit nakal, sesuai konotasi nama serinya, namun percayalah semua ini demi tujuan edukatif. Apa pun yang terjadi akibat penerapan dari apa yang tertulis di sini, baik langsung maupun tak langsung, bukanlah tanggung jawab penulis. Anda harus setuju dulu sebelum melanjutkan. Tekan Cancel dan pilih halaman lain jika tidak setuju.
Beberapa trik yang dijelaskan di sini bisa dikatakan akal-akalan dan sebagian yang lain tidaklah sah. Tujuan trik-trik ini ditampilkan hanyalah untuk tujuan edukatif, bukan untuk dipraktikkan dalam lingkungan produksi. Bahkan jika Anda menerapkan semua trik yang ada tanpa pertimbangan, maka log file, seluruh situs, dan diri Anda dapat kehilangan kepercayaan orang.
Secara konsep, satu pageview artinya sederhana: satu tampilan halaman Web yang Anda lihat di sebuah situs. Misalnya, jika Anda mengakses www.mwmag.com (/index.html), Anda akan melihat halaman depan situs majalah mwmag. Itu satu pageview. Gambar-gambar yang ada di halaman tersebut tidak dihitung sebagai pageview terpisah, karena toh bukan berupa page. Jika Anda lalu mengklik link Panduan Istilah (/standard/term.html) sehingga browser berpindah ke halaman tersebut, maka Anda menambah satu pageview lagi buat mwmag. Jika sebaliknya Anda mengklik salah satu banner yang menuju ke halaman di situs lain, maka Anda menambah pageview bagi situs lain tersebut, tidak bagi mwmag.
Secara teknis, makna pageview dapat tidak jelas, rumit, atau menjadi perdebatan. Pertama-tama, bagaimana dengan halaman yang mengandung frame? Ada berapa pageview di situ? Bagaimana dengan frame yang tersembunyi atau inline frame (<IFRAME>)? Bagaimana dengan window pop up dan pop under? Bagaimana dengan HTTP cache dan reload? Apakah halaman error—seperti 404 atau 500 Internal Server Error—dihitung sebagai pageview? Bagaimana dengan redirect? Kita akan melihat bagaimana implementasi perhitungan pageview dilakukan oleh pengelola situs (dan memanfaatkan bolong implementasi yang ada).
Ironisnya, pageview nyaris tidak pernah diukur dengan eksak. Ada dua metode utama yang dipakai mengukur pageview: web bug dan analisis file log webserver. Keduanya memiliki kekurangan dan kelebihan masing-masing, ada sebagian pageview yang tidak terukur oleh metode yang satu tapi terukur oleh metode lain, dan sebaliknya.
Web bug adalah sebuah imej kecil, umumnya berukuran 1x1 piksel dan transparan, yang ditempelkan di setiap halaman yang ingin diukur pageviewnya. Umumnya situs-situs yang jumlah halamannya banyak memiliki sistem template, sehingga kode HTML web bug ini cukup ditaruh di template agar bisa muncul di setiap halaman. Lokasi penempelan dapat di atas atau di bawah halaman, dengan konsekuensi berbeda.
Prinsip kerja web bug adalah sebagai berikut: jika sebuah halaman yang mengandung web bug dimuat, maka imej web bug pun akan direquest oleh browser pengunjung. URL imej web bug sebetulnya adalah sebuah skrip yang lalu mencatat dari halaman dan situs mana web bug ini dipanggil. Skrip lalu mentotal atau membuat statistik catatan ini dan mengembalikan respon redirect ke sebuah imej 1x1 statik. Biasanya layanan web bug ini diberikan oleh pihak ketiga, seperti hitbox.com atau nedstat.com.
Kerugian web bug adalah tidak dapat menghitung pageview jika opsi Load Images browser dimatikan. Jumlahnya memang relatif sedikit, tapi dapat bervariasi bergantung pada apakah situs Anda lambat dan halaman-halamannya dipenuhi banyak imej, atau apakah pengunjung situs rata-rata memiliki koneksi yang lambat. Dalam situasi seperti itu, peluang Load Images dimatikan semakin besar. Pengguna browser teks lynx atau links sudah pasti tidak mengambil imej saat melihat halaman Web. Karena tool download otomatis seperti wget kadang disuruh mengambil halaman dari host tertentu saja dan sering tidak diinstruksikan mengambil imej, maka pageview yang dihasilkan oleh client seperti wget pun tidak terhitung web bug.
Web bug juga kadang membutuhkan Javascript untuk dapat mengumpulkan informasi secara lengkap. Javascript juga dapat dimatikan oleh pemakai browser, meski insiden ini rata-rata lebih rendah.
Terakhir, karena diukur oleh server yang terpisah, maka ada kemungkinan pageview tidak terukur pada saat tertentu. Bukan saja pada saat server tempat web bug down—yang biasanya lebih jarang—tapi pada saat lain seperti jika pengunjung tidak dapat menghubungi server web bug, misalnya karena jaringan di luar IIX sedang tidak dapat diakses, atau ada kesalahan routing di ISP, atau koneksi ke luar negri sedang amat lambat sehingga time out, dsb. Di sisi lain, pageview juga mungkin dapat terhitung karena web bug dipanggil bukan dari situs Anda. Misalnya, web bug tertentu dapat dibom dengan skrip sehingga pageview situs korban melonjak, padahal hanya web bugnya saja yang ditembaki.
Setiap selesai memroses sebuah request, webserver pada umumnya akan mencatat request tersebut di sebuah baris file log. Semua request, termasuk HTML dan imej, respon sukses dan error, akan dicatat. Yang biasanya tidak dicatat adalah request yang tidak selesai—misalnya karena timeout—redirect internal, dan subrequest.
File log akan bertambah besar terus dan agar tidak memenuhi disk secara berkala perlu dirotasi—artinya, file log lama dipindahkan ke nama atau lokasi lain lalu dikompresi, direkam ke tape/CD, dan/atau dihapus. File log baru kini menjadi kosong dan siap diisi kembali. Rotasi dapat dilakukan per bulan, minggu, hari, atau bahkan lebih sering. Jika sebuah request menghasilkan rata-rata 180 karakter (dengan format log combined yang mencatat Referer) maka situs yang memperoleh 100 ribu hit per hari akan memproduksi log sekitar 17MB per hari. Untuk mengirit tempat Anda dapat memilih format log common, tapi Anda tidak memperoleh informasi Referer.
Di Linux, rotasi biasa dilakukan dengan program logrotate. File log Apache biasanya berada di /var/log/httpd/access_log. Terdapat file log lain yang khusus mencatat kesalahan yang terjadi, yaitu /var/log/httpd/error_log. Setiap virtualhost dapat memiliki file log tersendiri, sehingga tiap situs dicatat terpisah. Ini penting, sebab jika beberapa virtualhost disatukan lognya, maka Anda membuat file log berisi catatan beberapa situs sekaligus. Ini akan sulit dipisahkan nantinya.
File log ini, dalam kondisi terkompresi atau tidak, lalu dianalisis oleh program penganalisis log seperti Webalizer (gratis, GPL) atau WebTrends (komersial). Pekerjaan program-program ini sederhana saja: membaca baris demi baris file log, mentotal jumlah hit, pageview, dsb. lalu mengeluarkan laporan berbentuk HTML atau PDF atau Word. Rata-rata program statistik log melaporkan informasi yang serupa (hit/pageview/visit total dan harian, daftar Referer, daftar kata kunci search engine, detail per host pengakses, jam, negara, dsb). Perbedaannya terutama terletak pada keindahan laporan yang dihasilkan. WebTrends menghasilkan laporan berhalaman-halaman dalam format Word/HTML dengan grafik 3D dan kata-kata indah yang enak dilihat oleh manajer. Sementara Webalizer menghasilkan satu halaman HTML saja per bulan, dengan grafik jenis batang dan pie 2D. Masih ada program statistik lain, tapi Webalizer cukup umum digunakan dan telah disediakan di CD majalah (untuk Unix). Sebagai contoh keluaran Webalizer, Anda dapat melihat halaman berikut: http://mwmag.com/usage/.
Analisis file log dapat menampilkan besaran yang tidak bisa diukur oleh web bug seperti jumlah hit dan jumlah file. Dengan web bug, unit terkecil pencatatan adalah pageview. Imej dan file bukan-halaman lain tidak dapat ditempeli web bug, sehingga tidak bisa dipantau. Sementara di file log tercatat setiap request objek. Tapi metode pengukuran dengan analisis log juga memiliki kekurangan.
Berbeda dengan asumsi umum dan laporan hasil program statistik, analisis log biasanya tidak mengukur pageview yang sebenarnya. Definisi pageview adalah setiap halaman yang dimuat oleh pengunjung. Mayoritas halaman adalah respon dengan Content-Type text/html, tapi respon ini dapat dihasilkan dari berbagai sumber. Mulai dari file HTML statik, PHP (.php3, .php), skrip CGI (.cgi, .pl), dsb. Yang tercatat di file log hanyalah akhiran file yang direquest, bukan Content-Type. Tapi, skrip PHP atau CGI tidak selalu harus memproduksi HTML, melainkan dapat menghasilkan imej, PDF, atau apa pun. Ada dua pilihan yang tersedia di Webalizer: Anda dapat menghitung .php, .cgi, dsb. sebagai pageview atau tidak. Jika dihitung, maka pageview Anda yang sebenarnya mungkin lebih rendah, sebaliknya jika tidak dihitung maka angka pageview dari laporan statistik mungkin seharusnya lebih besar. Ingat, yang tercatat di file log adalah akhiran file, bukan Content-Type.
Perhitungan dengan analisis log juga tidak dapat menghitung pageview yang dihasilkan dari cache. Seperti diketahui, akses HTTP banyak dihiasi dengan cache dan proxy di tengah-tengah antara kita dan server asli. Ini membantu mempercepat respon dan menghemat bandwidth, tapi efeknya, beberapa orang melihat halaman situs Anda hanya dari cache. Akses ini tidak tercatat di log webserver Anda. Hanya saat orang tersebut menekan Refresh dan mem-bypass cache, maka aksesnya akan sampai ke server asli Anda.
Dalam membaca statistik, Anda akan dihadapkan pada beberapa istilah. Berikut arti istilah-istilah tersebut, setidaknya di Webalizer:
Hit. Hit sama dengan request, atau sama dengan jumlah baris di file log—dengan asumsi semua baris di file log adalah valid. Di Unix Anda dapat menghitung hit dengan mudah. Cukup jalankan perintah wc access_log untuk menghitung jumlah baris di file access_log. Ini berarti, hit cukup berbeda dan pasti lebih besar angkanya dibandingkan pageview, karena image atau objek non-halaman lain terhitung juga sebagai hit. Satu pageview sendiri dapat terdiri dari beberapa hit bergantung pada komposisi halaman Anda. Jika halaman Anda penuh dengan gambar-gambar kecil hasil splice misalnya, maka rasio hit : pageview akan semakin besar. Banyak situs “normal” yang hitnya sekitar 3–4 kali pageview, tapi ini tentunya dapat amat bervariasi. Semakin besar rasio, maka kadang bisa dikatakan bahwa halaman situs semakin berat (karena banyak mengandung objek non-halaman).
File. File adalah request yang menghasilkan respon berkode status 2xx dan menghasilkan respon (kolom jumlah byte di file log lebih besar dari 0). Besaran ini hendak mengukur jumlah file yang dikirim keluar oleh webserver. File biasanya lebih kecil daripada pageview karena hanya menghitung respon 2xx, tapi dapat juga lebih besar seandainya ada banyak objek non-halaman.
Pageview. Pageview hasil analisis log dihitung sebagai request ke URL yang memiliki akhiran-akhiran umum sebuah page. Misalnya, .html, .htm, .shtml, dan .phtml. Query string umumnya dilucuti dulu sebelum diperhitungkan, sehingga akhiran untuk URI /view.php?page=index.html adalah .php, bukan .html. Ini tentu saja hanya merupakan pendekatan, karena .php tidak selalu berupa page dan direktori atau file tanpa akhiran pun dapat berupa page (mis: akses ke direktori indeks otomatis Apache /icons/ sebetulnya menghasilkan sebuah pageview.)
Perhitungan pageview umumnya tidak memandang kode status respon. Jadi Internal Server Error (500), Redirect (3xx), atau Not Found (404) pun jika dihasilkan dari URL berakhiran page akan dihitung sebagai satu pageview.
Visit. Besaran ini dimaksudkan untuk menggambarkan jumlah orang yang mengunjungi situs kita. Meskipun ada cara lain seperti dengan menggunakan modul khusus yang melepas cookie, namun file log combined biasa oleh Webalizer dapat dipakai untuk mengukur visit dengan pendekatan sebagai berikut: satu visit adalah kumpulan request yang dilakukan dalam rentang waktu maksimum 30 menit dan dari host yang sama dengan User-Agent yang sama pula. Tentu saja ini tidak sempurna, tapi pada kebanyakan kasus cukup mendekati. Visit praktis hampir selalu lebih kecil daripada pageview, karena setiap orang umumnya minimal membaca 1 halaman di situs Anda, sehingga satu visit rata-rata menghasilkan lebih dari satu pageview. Kecuali misalnya situs Anda hanya berisi gambar-gambar.
Jumlah byte. Ini adalah total jumlah byte respon dan kurang lebih menggambarkan outgoing traffic dari webserver.
Berikut ini sebuah ilustrasi untuk memperjelas keterangan di atas. Situs Anda memiliki dua halaman /index.html dan /news.html. Di index.html dan news.html masing-masing terdapat index.css dan utils.js. Di index.html terdapat 10 imej, namun hanya 7 saja yang unik. Empat gambar adalah sama, yaitu gambar bullet kecil. Sementara news.html hanya mengandung gambar bullet saja. Hari ini ada sepuluh orang berbeda yang mengakses halaman index.html dan hanya lima yang mengklik halaman news.html. Satu orang yang hanya mengakses halaman depan hanya mematikan Load Images di browsernya. Efek cache tidak diperhatikan. Bagaimana Webalizer menghitung ini?
Total pageview yang diakses adalah 10 + 5 = 15 pageview. index.css dan utils.js tidak akan terhitung sebagai pageview kecuali jika Anda set PageType css dan PageType js di konfigurasi Webalizer. Hit adalah sbb: pageview = 15. 1 orang mengakses halaman depan saja tanpa meload Images, tapi mengambil index.css dan utils.js = 2 hit. 9 orang lainnya memuat halaman depan dengan imej, sehingga ada 9 x (2+7) = 81 hit tambahan. Lima orang yang mengakses juga halaman news telah meng-cache imej bullet dan CSS/Javascript, tapi browser biasanya mengirimkan request dengan If-Last-Modified yang akan dijawab dengan 304 oleh webserver. Sehingga ini menambah lagi hit sebanyak 5 x 3 = 15 hit. Total hit adalah 15 + 2 + 81 + 15 = 113 hit. Jika setting Check for newer versions of page di browser pengunjung diset menjadi Never, maka 15 hit terakhir tadi tidak akan terjadi.
Karena program statistik menghitung pageview berdasarkan akhiran URL, maka pastikan Anda memasukkan semua akhiran HTML dan skrip yang Anda pakai untuk halaman Web. Konfigurasi default Webalizer hanyalah memasukkan akhiran .htm* dan .cgi. Lihat bagian PageType di webalizer.conf. Jika Anda menggunakan SSI, masukkan pula .shtml. Jika menggunakan PHP, masukkan .phtml, .php3, .php. Atau jika Anda menggunakan ekstensi lain seperti .p, jangan lupa sertakan pula.
Tidak ada yang melarang Anda memasukkan .gif atau .jpg sebagai akhiran yang dianggap pageview. Tapi cara ini mungkin terlalu murahan dan akan menghasilkan rasio pageview : hit yang mencurigakan. Cara lain adalah sebaliknya, membuat imej-imej Anda—sebagian saja, misalnya elemen-elemen visual yang sering diakses—menjadi berekstensi .html atau .php yang lebih samar. Browser umumnya tetap dapat menampilkan:
<img src=/images/dot.php width=1 height=1>
dengan baik. Hanya saja, lebih baik dot.php ini Anda set agar tidak diproses oleh PHP agar tidak terjadi pemborosan CPU yang sia-sia. Atau, bisa juga Anda membuat variasi lain yang lebih panjang dan kentara seperti:
<img src="/image.php?path=/images/dot.gif" width=1 height=1>
Skrip image.php adalah skrip yang tugasnya hanya melakukan redirect ke imej asli. Request yang tercatat adalah image.php yang akan dianggap sebuah pageview.
Jika Anda melakukan trik seperti ini secara ekstensif, maka pastikan Anda tetap memperhatikan rasio pageview : hit agar tidak terlampau ekstrem. Mengambil contoh sebelumnya, jika kita mengubah semua nama objek imej menjadi berakhiran .php atau sejenisnya, maka pageview akan bertambah dari 15 menjadi 83! Terlalu mencolok bukan?
Ada 3 macam redirect yang dikenal di Apache: yang pertama adalah redirect eksternal permanen dengan kode status 301. Yang kedua adalah redirect eksternal sementara, dengan kode status 302. Yang ketiga redirect internal, yang tidak tercatat sebagai request karena dilakukan Apache melalui mekanisme mirip subrequest. Selain itu, ada redirect via tag <META HTTP-EQUIV=Refresh> yang diinterpretasi oleh browser semata. Dari keempat jenis variasi redirect, hanya 3 yang dihitung sebagai pageview. Redirect internal bahkan tidak akan tercatat di file log webserver.
Redirect eksternal sementara (status 302) terjadi jika kita mengirimkan header Location dari skrip. Misalnya, skrip PHP berikut:
<? header("Location: http://$SERVER_NAME/new.php"); ?>
Redirect ini mengarahkan pengunjung ke situs yang sama tapi ke URI /new.php. Jika pengunjung mengakses skrip PHP ini, maka browsernya akan menerima kode status 302 dan header Location. Browser mengambil nilai header Location untuk mengakses halaman tujuan. Baru kemudian /new.php misalnya mengembalikan konten yang diinginkan.
Tapi jika skrip PHP Anda seperti ini (perhatikan perbedaannya, URL ini tidak absolut karena tidak mengandung protokol dan hostname):
<? header("Location: /new.php"); ?>
Maka Apache akan mengambil header ini lalu meluncurkan “subrequest” baru ke /new.php langsung. Pengunjung yang mengakses skrip ini akan langsung disuguhi kode 200 beserta konten /new.php. Ini yang disebut redirect internal, karena client tidak melihat proses redirect ini.
Dari kenyataan bahwa kode respon non 2xx pun dihitung sebagai pageview, maka Anda dapat bermain-main redirect untuk menambah pageview. Ketimbang menyuguhkan link langsung ke sebuah halaman, Anda melempar pengguna dulu selalu ke skrip view.php misalnya:
<a href="/view.php?p=/2001/11/20/utama.html">Tempo didatangi
Golkar</a>
Link ini sekali diklik akan menghasilkan dua, bukan satu, pageview. Pertama akses ke /view.php, yang akan menghasilkan redirect 302 ke /2001/11/20/utama.html. Jika Anda betul-betul iseng, Anda dapat merancang skema loncat-loncat lebih dari satu kali. Sekali lagi, jika Anda terlalu mencolok, maka ini akan menimbulkan kecurigaan dan rasa jengkel pengunjung.
Pastikan Anda melakukan redirect external (sebutkan URL penuhnya), jangan redirect internal yang tidak menghasilkan pageview.
Kita belum membahas redirect 301. Redirect ini dilakukan otomatis oleh Apache jika menjumpai request ke direktori tanpa tanda / di ujung. Misalnya, Anda memiliki direktori /contact, /staff, /about, dan /news di bawah root situs Web. Jika ada yang mengakses direktori /contact:
GET /contact HTTP/1.1
Host: www.pageview-whore.com
Maka Apache belum akan mencari /contact/index.html atau menampilkan listing otomatis. Melainkan, Apache akan memberikan dulu respon seperti berikut:
HTTP/1.1 301 Moved Permanently
Location: http://www.pageview-whore.com/contact/
Sehingga browser harus mengakses ulang sbb:
GET /contact/ HTTP/1.1
Host: www.pageview-whore.com
Hasilnya? 2 hit ketimbang 1. Bagaimana mengubah hit ini menjadi pageview? Yup, salah satu cara sederhana adalah mengubah nama foldernya menjadi /contact.html.
Tapi sebetulnya apa alasan Apache melakukan ini secara otomatis? Jawabannya adalah untuk menolong agar link-link tidak berantakan. Perhatikan contoh berikut: di halaman depan Anda memiliki link <a href=/contact>. Browser tidak bisa mengetahui apakah ini direktori atau bukan, jadi asumsi browser adalah bahwa ini bukan direktori. Seandainya Apache tidak melakukan redirect dan memberikan langsung isi /contact, maka jika di halaman /contact terdapat link <a href=email.html> apa yang akan terjadi? Browser masih mencatat direktori aktif adalah / sehingga link ini akan beralamat /email.html. Padahal alamat yang benar adalah /contact/email.html. Redirect oleh Apache ke /contact/ akan membantu browser mengetahui bahwa contact adalah direktori.
Sebagai catatan tambahan, URL berakhiran / selalu dianggap sebuah halaman oleh Webalizer, sehingga halaman depan (/) atau direktori (/contact/) dihitung pageview meskipun tidak memiliki akhiran yang dikenali.
Untuk menghasilkan 2 hit dan 2 pageview setiap kali orang mengklik link ke direktori, berikan link tanpa garis miring penutup dan beri nama direktori dengan akhiran halaman. Contoh: <a href=/contact.html>, di mana contact.html adalah nama sebuah direktori. Hal ini paling efektif dilakukan di halaman depan yang menampilkan menu navigasi ke semua seksi-seksi (direktori-direktori).
Teknologi ini beberapa tahun silam disebut dengan istilah keren: Client Pull. Intinya adalah tag <META HTTP-EQUIV=Refresh CONTENT="N"> yang diinterpretasi browser sebagai: “reload setiap N detik.” Dengan tag singkat ini, Anda bisa mendapat bonus pageview secara berkala, terutama dari pemakai kantor yang sering meninggalkan komputernya menyala dan posisi browser masih berada di situs Anda. Tahu-tahu, hingga besok pagi komputer tersebut telah menghasilkan 20–200 pageview, bergantung pada seberapa besar Anda mengeset nilai N.
Fitur ini sebetulnya bisa dibilang bermanfaat juga, sebab menjaga halaman Web tetap baru, terutama untuk situs yang sering sekali diupdate. Coba perhatikan Tabel 2 untuk melihat bagaimana situs-situs portal di Indonesia memanfaatkan autorefresh.
Catatan: jika Anda menggunakan pengukuran dengan web bug, maka autorefresh belum tentu menghasilkan pageview tambahan. Browser tidak selalu mereload imej web bug jika halaman direload. Namun web bug yang ditulis dengan bantuan Javascript dapat mengatasi hal ini.
HTTP/1.1 terkenal memiliki mekanisme cache yang cukup menditel dan lengkap. Mekanisme cache digunakan untuk mempercepat respon dan menghemat bandwidth. Selain cache di browser Anda, di antara server dan komputer kita pun sering terpasang satu atau lebih cache proxy, kadang transparan sehingga tidak bisa di-bypass.
Cache berguna bagi penghematan biaya dan peningkatan kecepatan, tapi menjadi musuh bagi peningkatan pageview. Agar Anda tetap menerima dan merekam pageview, Anda perlu menghindari mekanisme cache ini bekerja. Ada beberapa cara yang dikenal.
Cara ini biasa dilakukan oleh situs berita atau konten lain. Dengan alasan meningkatkan usability karena mengurangi derajat scrolling, pembuat situs-situs ini memecah sebuah cerita yang agak panjang, mis: 1 halaman Web 20 layar, menjadi 5 halaman Web yang masing-masing panjangnya 4 layar. Setelah itu diberikan navigasi Next dan Previous untuk berpindah-pindah halaman.
Alasan usability amat perlu diperdebatkan, karena beberapa survei menunjukkan bahwa halaman yang panjang tidak otomatis mengurangi usability. Sebetulnya pemecahan halaman ini, kalau mau jujur saja, dilakukan semata-mata untuk meningkatkan pageview (dan dengan demikian, meningkatkan konsumsi banner). Dari satu pageview, setelah dipecah maka jumlah konten yang sama menjelma menjadi lima pageview dan pembaca bisa disuguhi lima kali lebih banyak iklan. Namun jika pembuat situs terlalu ekstrem mencacah-cacah kontennya, tentu hasilnya adalah kejengkelan pembaca yang akan meninggalkan situs tersebut untuk selamanya. Cerita yang terpecah-pecah menjadi lebih merepotkan untuk dibaca, disimpan, dan dikirim. Lihat saja AnandTech, www.anandtech.com.
SSI juga menggunakan subrequest untuk <!--#include-->. Jadi jika Anda ingin header, footer, dan file lain yang Anda include muncul di access_log, bagaimana caranya? Salah satunya yaitu dengan mengganti include SSI dengan serangkaian document.write() Javascript. Kerugiannya (atau keuntungannya?), Anda kini membatasi diri hanya bagi browser yang mendukung Javascript. Berikut ini sebuah skrip PHP yang dapat dipakai untuk melakukan include URL tertentu dan menampilkannya sebagai Javascript:
<script>
_=document.write;
<?php
if (preg_match("#^http://#", $url))
$content=file($url);else $content=array();
foreach($content as $line){
$line=
preg_replace("/\n/", "'+'\\n'+'",
preg_replace("/'/","\\'",
preg_replace("/\\\/","\\\\\\",$line)
)
);
echo "_('$line');\n";
}
?>
</script>
Katakanlah skrip ini ditaruh di URI /include_js.php. Maka gantikanlah baris SSI seperti ini:
<!--#include virtual="/header.html" -->
Kini Anda bisa menuliskan:
<script src=
"/include_js.php?url=http://www.pageview-whore.com/header.html">
</script>
Hasilnya di browser yang mendukung Javascript sama saja, hanya kini Anda memperoleh dua bonus pageview dari tiap include! Catatan: Anda masih harus memastikan skrip tersebut agar tidak bisa digunakan sembarang orang. Jika tidak, skrip ini bisa dipakai orang sebagai proxy HTTP manual (Hint: tambahkan pengecekan variabel environment REMOTE_ADDR harus dari server Anda pula).
Trik-trik di sini bisa dibilang kotor dan tak terpuji.
Kita dapat membuat frame dengan tinggi atau lebar 0, lalu menaruh halaman dengan laju autorefresh tinggi di sana. Untuk derajat penambahan pageview yang paling tinggi, Anda bisa membuat skrip yang anticache dengan isi pendek saja, misalnya tag <META> diikuti tanggal hari ini atau sejenisnya. Halaman kecil ini akan menjadi penyumbang pageview yang signifikan. Frame tersembunyi juga sering dipakai untuk memuat halaman situs lain atau halaman berbanner sehingga meningkatkan impresi banner.
Para publisher—pemilik konten yang memajang kode banner pihak ketiga—juga akhir-akhir ini telah menyadari bahwa iklan tidak perlu dilihat pengunjung, dan malah bisa beroperasi meningkatkan impresi lebih baik jika tidak dilihat. Karena itulah, selain penggunaan frame tersembunyi, kini mulai menjamur penggunaan window pop under atau yang ditaruh di luar layar komputer pengunjung. Tanpa sadar, si pengunjung mungkin telah menghabiskan beratus-ratus kilo transfer data untuk mengambil halaman dan banner yang tidak pernah dilihatnya. Tidak mengganggu mata, tapi tetap culas.
Banner atau halaman Web juga dapat diselipkan di dalam <iframe> kecil yang tak terlihat. <iframe> didukung oleh IE dan Mozilla, tapi tidak didukung Netscape 4.x.
Sudah dengar tentang x10.com bukan? Dengan hanya berbekal iklan pop undernya yang tersebar di berbagai situs, ads.x10.com menjadi salah satu situs yang paling besar trafiknya di Internet dalam beberapa bulan terakhir. Jika iklan berupa pop up, maka barangkali trafiknya tidaklah sebesar itu.
Pageview bukanlah patokan popularitas, jumlah pengunjung, apalagi potensi pendapatan sebuah situs. Malah sebetulnya yang pasti hanyalah, pageview berbanding lurus dengan biaya—yakni biaya bandwidth. Seperti telah kita lihat di artikel ini, pageview dan statistik log rentan terhadap manipulasi. Selain cara-cara yang telah diterangkan di sini Anda masih bisa mengutak-atik file lognya langsung atau misalnya mengutak-atik mod_include.c Apache agar subrequest juga masuk ke file log.
Karena itu metode analisis log juga perlu dipadukan dengan web bug dari pihak ketiga untuk membantu memverifikasi hasilnya, terutama bagi pihak luar. Hasil kedua sumber ini akan berbeda, karena ada sebagian pageview yang tidak direkam yang lainnya, tapi keduanya ini bisa dibandingkan terus dari waktu ke waktu untuk melihat apa ada perubahan atau anomali pada saat-saat tertentu.
Ironisnya, meski pageview memiliki kelemahan-kelemahan seperti di atas, saat ini tidak ada patokan lain yang cukup sederhana dan andal untuk bisa dipakai menggantikannya. Besaran trafik/pemakaian bandwidth rentan karena terpengaruh langsung terhadap perubahan-perubahan jaringan seperti serangan DOS. Jumlah pengunjung pun lebih tidak dapat diandalkan karena bergantung pada fitur cookie persisten. Semua data ini masih harus disertai pageview supaya lebih “afdol” jika ingin disajikan kepada pihak yang tertarik.
Kalau saya sendiri disuguhi angka dan laporan Webalizer sebuah situs, maka saya akan teliti dulu dengan melihat rasio-rasionya dengan hit dan pengunjung serta menyelidiki seperti apa struktur dan link situs tersebut. Dan yang pasti saya tidak akan langsung membandingkan angka pageview yang sama dengan situs lain. Karena pageview amat bergantung struktur situs, maka perbandingan pageview antarsitus kurang berguna.
Anda juga sebaiknya sebaiknya melihat statistik situs dengan bijaksana, apalagi jika sedang mempertimbangkan membeli sebuah situs yang diklaim pemiliknya popular. Pernah dengar frase “sex, lies, and statistics”?
mw
| Arsip mwmag | [Files] [Up] | www.master.web.id/mwmag |