Membangun alat untuk memahami kinerja konten

Konten adalah salah satu kekuatan utama yang mendorong strategi pemasaran masuk, dan SEO adalah bagian integral dari membuatnya bekerja. Secara umum, ini akan mencakup dasar-dasar SEO pada halaman: struktur artikel, penempatan kata kunci, tag meta, tag judul, teks alternatif, judul, data terstruktur, dan penggunaan pemformatan untuk membuat data terstruktur informal dalam daftar dan tabel.

Mengaudit SEO pada halaman sebagai bagian dari manajemen konten, menggunakan OnCrawl.

Ini berada di bawah payung SEO teknis ketika Anda mulai mengoptimalkan atau memantau secara massal, baik melalui audit situs atau perayapan reguler, melalui deskripsi meta bahasa alami yang dihasilkan mesin, tag kontrol cuplikan, atau injeksi data terstruktur.

Namun, persimpangan SEO teknis dan pemasaran konten bahkan lebih besar dalam hal kinerja konten: kami melihat data primer yang sama, seperti peringkat halaman pada SERP, atau jumlah klik, tayangan, dan sesi. Kami mungkin menerapkan solusi yang sama, atau menggunakan alat yang sama.

Apa itu kinerja konten?

Performa konten adalah hasil terukur dari bagaimana audiens berinteraksi dengan konten. Jika konten mendorong lalu lintas masuk, maka ukuran lalu lintas tersebut mencerminkan seberapa baik atau seberapa buruk konten tersebut melakukan tugasnya. Setiap strategi konten harus, berdasarkan tujuan konkret, menentukan KPI khususnya. Sebagian besar akan menyertakan metrik berikut:

• Seberapa terlihat konten dalam pencarian (tayangan di SERPs)
• Bagaimana mesin pencari yang bersangkutan berpikir tentang konten tersebut (peringkat pada SERPs)
• Bagaimana menurut para pencari terkait tentang daftar pencarian konten (klik dari SERPs)
• Berapa banyak orang yang melihat konten (kunjungan atau sesi dalam solusi analitik)
• Berapa banyak orang yang berinteraksi dengan konten dengan cara yang meningkatkan sasaran bisnis (pelacakan konversi)

Sejauh ini baik.

Kesulitannya adalah dalam menempatkan kursor: angka apa yang berarti Anda memiliki kinerja konten yang baik? Apa itu normal? Dan bagaimana Anda tahu ketika sesuatu tidak berjalan dengan baik?

Di bawah ini, saya akan membagikan eksperimen saya untuk membangun "bukti konsep" alat berteknologi rendah untuk membantu menjawab pertanyaan-pertanyaan ini.

Mengapa memerlukan standar untuk kinerja konten?

Berikut adalah beberapa pertanyaan yang ingin saya jawab sebagai bagian dari tinjauan saya sendiri tentang strategi konten:

• Apakah ada perbedaan antara konten internal dan posting tamu dalam hal kinerja?
• Apakah ada mata pelajaran yang kami dorong yang tidak berkinerja baik?
• Bagaimana saya bisa mengidentifikasi posting "hijau" tanpa menunggu tiga tahun untuk melihat apakah mereka masih menarik lalu lintas mingguan?
• Bagaimana saya bisa mengidentifikasi peningkatan kecil dari promosi pihak ketiga, seperti ketika sebuah posting diambil di buletin yang tidak ada dalam radar promosi kami, untuk segera menyesuaikan strategi promosi kami sendiri dan memanfaatkan peningkatan visibilitas?

Namun, untuk menjawab semua pertanyaan ini, Anda perlu mengetahui seperti apa kinerja konten "normal" di situs yang sedang Anda kerjakan. Tanpa garis dasar itu, tidak mungkin untuk mengatakan secara kuantitatif apakah bagian atau jenis konten tertentu berkinerja baik (lebih baik dari garis dasar) atau tidak.

Cara termudah untuk menetapkan garis dasar adalah dengan melihat sesi rata-rata per hari setelah publikasi, per artikel, di mana hari nol adalah tanggal publikasi.

Ini akan menghasilkan kurva yang terlihat seperti ini, menunjukkan puncak minat awal (dan mungkin hasil dari setiap promosi yang Anda lakukan, jika Anda tidak membatasi analisis Anda pada sesi dari mesin pencari saja), diikuti dengan ekor panjang bunga yang lebih rendah:

Data nyata untuk posting biasa: puncak pada atau segera setelah tanggal publikasi, diikuti oleh ekor panjang yang, dalam banyak kasus, akhirnya menghasilkan lebih banyak sesi daripada puncak aslinya.

Setelah Anda mengetahui seperti apa kurva setiap posting, Anda dapat membandingkan setiap kurva dengan yang lain, dan menetapkan apa yang "normal" dan apa yang tidak.

Jika Anda tidak memiliki alat untuk melakukan ini, ini adalah rasa sakit di leher.

Ketika saya memulai proyek ini, tujuan saya adalah menggunakan Google Sheets untuk membangun bukti konsep-sebelum berkomitmen untuk mempelajari cukup Python untuk mengubah cara saya memeriksa kinerja konten.

Kami akan memecah proses menjadi beberapa fase dan langkah:

1. Temukan dasar Anda
   – Cantumkan konten yang ingin Anda pelajari
   – Cari tahu berapa banyak sesi yang diterima setiap konten setiap hari
   – Ganti tanggal dalam daftar sesi dengan jumlah hari sejak publikasi
   – Hitung kurva “normal” untuk digunakan sebagai garis dasar
2. Identifikasi konten yang tidak terlihat seperti garis dasar
3. Tetap up to date

Temukan baseline kinerja konten Anda

Cantumkan konten yang ingin Anda pelajari

Untuk memulainya, Anda perlu membuat daftar konten yang ingin Anda periksa. Untuk setiap bagian konten, Anda memerlukan URL dan tanggal publikasi.

Anda bisa mendapatkan daftar ini sesuka Anda, apakah Anda membuatnya dengan tangan atau menggunakan metode otomatis.

Saya menggunakan Skrip Aplikasi untuk menarik setiap URL konten dan tanggal publikasinya langsung dari CMS (dalam hal ini, WordPress) menggunakan API, dan menulis hasilnya ke Google Sheet. Jika Anda tidak nyaman dengan skrip atau API, ini masih relatif mudah; Anda dapat menemukan beberapa contoh online tentang cara melakukan ini untuk WordPress.

Ingatlah bahwa Anda ingin membandingkan data ini dengan data sesi untuk setiap posting, jadi Anda harus memastikan bahwa "siput" pada lembar ini cocok dengan format jalur URL yang disediakan oleh solusi analitik Anda.

Saya merasa lebih mudah untuk membuat slug lengkap (jalur URL) di sini, di kolom E di atas, daripada memodifikasi data yang diambil dari Google Analytics. Ini juga tidak terlalu berat secara komputasi: ada lebih sedikit baris dalam daftar ini!

Contoh rumus untuk membuat URL lengkap untuk situs ini: cari nomor kategori yang disediakan oleh CMS dalam tabel dan kembalikan nama kategori, yang ditempatkan sebelum slug artikel, cocok dengan pola URL untuk situs ini (https://site .com/categoryName/articleSlug/)

Jika Anda tidak memiliki akses ke backend, Anda dapat membuat daftar Anda dengan menggores informasi ini dari situs web Anda sendiri, misalnya, selama perayapan. Anda kemudian dapat mengekspor CSV dari data yang Anda inginkan, dan mengimpornya ke dalam Google Spreadsheet.

Menyiapkan bidang data di OnCrawl untuk mengikis tanggal publikasi dari blog situs web.

Data, termasuk URL dan tanggal publikasi tergores, di Penjelajah Data OnCrawl, siap untuk diekspor.

Cari tahu berapa banyak sesi per hari yang diperoleh setiap konten

Selanjutnya, Anda memerlukan daftar sesi per konten dan per hari. Dengan kata lain, jika sebuah konten berumur 30 hari dan menerima kunjungan setiap hari selama periode tersebut, Anda ingin memiliki 30 baris untuk konten tersebut–dan seterusnya untuk konten Anda lainnya.

Anda akan memerlukan lembar terpisah dalam dokumen yang sama untuk ini.

Add-on Google Analytics ke Google Sheets membuat ini relatif mudah.

Dari tampilan Google Analytics dengan data yang Anda inginkan, Anda dapat meminta laporan tentang:

Menggunakan segmen data Google Analytics Anda sangat membantu pada tahap ini. Anda dapat, misalnya, membatasi laporan Anda ke segmen yang hanya berisi URL konten yang ingin Anda analisis, bukan seluruh situs. Ini secara signifikan mengurangi jumlah baris dalam laporan yang dihasilkan, dan membuat data lebih mudah digunakan di Google Spreadsheet.

Selain itu, jika Anda hanya ingin melihat kinerja organik untuk tujuan SEO yang ketat, segmen Anda harus mengecualikan saluran akuisisi yang tidak dapat dikaitkan dengan pekerjaan SEO: rujukan, email, sosial…

Jangan lupa untuk memastikan bahwa batasnya cukup tinggi sehingga Anda tidak akan memotong data Anda secara tidak sengaja.

Hitung jumlah hari sejak publikasi

Untuk menghitung jumlah hari sejak publikasi untuk setiap titik data dalam artikel, kami harus menggabungkan (atau, jika Anda adalah pengguna Data Studio, "mencampur") data dari laporan sesi ke data dalam daftar bagian konten Anda .

Untuk melakukannya, gunakan URL atau jalur URL sebagai kunci. Ini berarti jalur URL harus diformat dengan cara yang sama di tabel CMS dan laporan Google Analytics.

Saya membuat tabel terpisah sehingga saya dapat menghapus parameter apa pun dari halaman arahan di laporan Analytics saya. Inilah cara saya mengatur kolom saya:

• Halaman arahan
  Menggosok parameter dari siput URL di laporan Analytics
  Contoh rumus:

• Tanggal
  Tanggal sesi dicatat, dari laporan Analytics
  Contoh rumus:

• Sesi
  Tanggal sesi dicatat, dari laporan Analytics
  Contoh rumus:

• Hari setelah publikasi
  Cari tanggal publikasi untuk URL ini di kolom tabel CSM yang baru saja kita buat dan kurangi dari tanggal sesi ini direkam. Jika URL tidak dapat ditemukan di tabel CMS, laporkan string kosong, bukan error.
  Contoh rumus:

Perhatikan bahwa kunci pencarian saya–jalur URL lengkap–bukanlah kolom paling kiri dalam data saya; Saya harus menggeser kolom E sebelum kolom C untuk keperluan VLOOKUP.

Jika Anda memiliki terlalu banyak baris untuk diisi dengan tangan, Anda dapat menggunakan skrip seperti di bawah ini untuk menyalin konten di baris pertama dan mengisi 3450 berikutnya atau lebih:

 fungsi IsiDown() {
    var spreadsheet = SpreadsheetApp.getActive();
    spreadsheet.getRange('F2').aktif();
    spreadsheet.getActiveRange().autoFill(spreadsheet.getRange('F2:F3450), SpreadsheetApp.AutoFillSeries.DEFAULT_SERIES);
};

Hitung jumlah sesi "normal" per hari setelah publikasi

Untuk menghitung nomor sesi normal, saya telah menggunakan tabel pivot yang cukup sederhana, dipasangkan dengan grafik. Demi kesederhanaan, saya mulai dengan melihat jumlah rata -rata sesi per hari setelah publikasi.

Berikut rata-rata versus median sesi selama 1000 hari setelah publikasi. Di sini kita mulai (?) untuk melihat batasan Google Spreadsheet sebagai proyek visualisasi data:

Ini adalah situs B2B dengan puncak sesi hari kerja di seluruh situs penuh; itu menerbitkan artikel beberapa kali per minggu, tetapi selalu pada hari yang sama. Anda hampir dapat melihat pola mingguan.

Dalam hal ini, untuk tujuan visualisasi, mungkin akan lebih baik untuk melihat rata-rata 7 hari bergulir, tetapi inilah versi cepat yang hanya diperhalus beberapa minggu sejak publikasi:

Terlepas dari pandangan jangka panjang ini, untuk langkah selanjutnya saya akan membatasi grafik hingga 90 hari setelah publikasi agar tetap dalam batas Google Sheets nanti:

Pencarian anomali

Sekarang setelah kita mengetahui seperti apa rata-rata postingan pada hari tertentu, kita dapat membandingkan postingan apa pun dengan baseline untuk mengetahui apakah performanya berlebihan atau kurang.

Ini akan cepat keluar dari "tangan" jika Anda melakukannya secara manual. Selain permainan kata-kata, setidaknya mari kita coba mengotomatiskan beberapa hal ini.

Setiap posting (yang berumur kurang dari 90 hari), perlu dibandingkan dengan garis dasar yang baru saja kita buat untuk setiap hari di jendela 90 hari kita.

Untuk pembuktian konsep ini, saya menghitung persentase perbedaan dari rata-rata harian.

Untuk analisis yang ketat, Anda akan ingin melihat standar deviasi sesi per hari, dan menetapkan berapa banyak standar deviasi kinerja masing-masing konten dari baseline. Jumlah sesi yang merupakan tiga standar deviasi dari kinerja rata-rata lebih cenderung menjadi anomali daripada sesuatu yang berbeda dari rata-rata untuk hari itu lebih dari X%.

Saya menggunakan tabel pivot untuk memilih setiap bagian konten (dengan sesi dalam 90 hari terakhir) yang memiliki setidaknya satu hari anomali selama periode tersebut:

Di Google Spreadsheet, tabel pivot tidak diperbolehkan membuat lebih dari 100 kolom. Oleh karena itu batasan 90 hari untuk analisis ini.

Saya memetakan tabel ini. (Idealnya, saya ingin memetakan seluruh kurva 90 hari untuk setiap artikel ini, tetapi saya juga ingin sheet merespons jika saya mengklik kurva.)

Menjaga segala sesuatunya tetap up to date: Mengotomatiskan pembaruan

Ada tiga elemen utama di sini:

1. Garis dasar
2. Potongan konten yang ingin Anda lacak
3. Performa konten ini

Sayangnya, tidak ada yang statis.

Secara teoritis, kinerja rata-rata akan berkembang saat Anda menjadi lebih baik dalam menargetkan dan mempromosikan konten Anda. Ini berarti Anda harus sering menghitung ulang baseline.

Dan jika situs web Anda memiliki puncak dan penurunan musiman, mungkin ada baiknya untuk melihat rata-rata selama periode waktu yang lebih singkat, atau periode yang sama setiap tahun, daripada membuat penggabungan seperti yang kami lakukan di sini.

Saat Anda menerbitkan lebih banyak konten, Anda juga ingin melacak konten baru.

Dan ketika kami ingin melihat tanggal sesi untuk minggu depan, kami tidak memilikinya.

Dengan kata lain, model ini perlu diperbarui lebih sering atau lebih jarang. Ada beberapa cara untuk mengotomatiskan pembaruan, daripada membangun kembali seluruh alat dari awal setiap kali Anda tertarik untuk melihatnya.

Yang paling mudah untuk diterapkan mungkin menjadwalkan pembaruan mingguan sesi analitik, dan menarik posting baru (dengan tanggal publikasinya) pada saat yang bersamaan.

Laporan Google Analytics yang kami gunakan dapat dengan mudah dijadwalkan untuk berjalan secara otomatis secara berkala. Kelemahannya adalah ia menimpa laporan sebelumnya. Jika Anda tidak ingin menjalankan dan mengelola laporan lengkap, Anda dapat membatasinya untuk jangka waktu yang lebih singkat.

Untuk tujuan saya, saya telah menemukan bahwa melihat jendela 7 hari memberi saya informasi yang cukup untuk dikerjakan tanpa terlalu ketinggalan zaman.

Mengawasi posting yang selalu hijau di luar jendela 90 hari

Dengan menggunakan data yang kami hasilkan sebelumnya, katakanlah mungkin untuk menentukan bahwa sebagian besar posting rata-rata sekitar 50 sesi per minggu.

Oleh karena itu masuk akal untuk mengawasi setiap pos yang sesi mingguannya lebih dari 50, terlepas dari tanggal publikasi:

Artikel diwarnai oleh periode publikasi: 90 hari terakhir (biru), tahun lalu (oranye), dan warisan (abu-abu). Total mingguan diberi kode warna dengan membandingkannya dengan sasaran sesi 50.

Membagi sesi total per hari dalam seminggu memudahkan untuk membedakan dengan cepat antara posting yang selalu hijau dengan kinerja yang cukup konsisten versus aktivitas yang didorong oleh peristiwa dengan kinerja yang tidak merata:

Konten evergreen (kinerja konsisten ±20/hari)

Kemungkinan promosi di luar (kinerja rendah secara umum di luar puncak jangka pendek)

Apa yang Anda lakukan dengan informasi ini akan bergantung pada strategi konten Anda. Anda mungkin ingin memikirkan bagaimana posting ini mengonversi prospek di situs web Anda, atau membandingkannya dengan profil backlink Anda.

Batasan Google Spreadsheet untuk analisis konten

Google Sheets, seperti yang mungkin telah Anda perhatikan pada saat ini, adalah alat yang sangat kuat—namun terbatas—untuk analisis semacam ini. Keterbatasan ini adalah alasan mengapa saya memilih untuk tidak membagikan template dengan Anda: mengadaptasinya ke kasus Anda akan membutuhkan banyak pekerjaan–tetapi hasil yang bisa Anda dapatkan masih hanya perkiraan yang dilukis dengan sapuan lebar.

Berikut adalah beberapa poin utama di mana model ini gagal memberikan:

• Ada terlalu banyak formula.
  Jika Anda memiliki banyak (misalnya, ribuan) URL konten aktif, itu bisa sangat lambat. Dalam skrip pembaruan mingguan saya, saya mengganti banyak rumus dengan nilainya setelah dihitung sehingga file benar-benar merespons ketika saya membukanya nanti untuk analisis.
• Dasar statis.
  Saat kinerja konten saya meningkat, saya hanya memiliki lebih banyak konten yang "berperforma tinggi". Garis dasar perlu dihitung ulang setiap beberapa bulan untuk memperhitungkan evolusi. Ini akan mudah diselesaikan dengan menggunakan model pembelajaran mesin tanpa pengawasan untuk menghitung rata-rata (atau bahkan untuk melewati langkah ini dan mengidentifikasi anomali secara langsung).
• Dasar yang "tidak akurat".
  Garis dasar tidak memperhitungkan perubahan musiman atau insiden di seluruh situs. Ini juga sangat sensitif terhadap kejadian ekstrim, terutama jika Anda membatasi perhitungan Anda untuk periode waktu yang lebih singkat:

Analisis outlier yang tidak sehat secara statistik.
Terutama jika Anda tidak memiliki banyak sesi per hari per item konten, mengklaim perbedaan 10% dari rata-rata merupakan kinerja yang tidak biasa agak samar.

Batas sewenang-wenang hingga 90 hari analisis.
Batas sewenang-wenang apa pun adalah masalah. Dalam hal ini, ini mencegah saya memahami kinerja konten yang selalu hijau dan membuat saya buta terhadap puncak kinerjanya–meskipun saya tahu dari Google Analytics bahwa karya yang sangat lama kadang-kadang mendapat lonjakan perhatian yang tiba-tiba, atau bahwa beberapa artikel terus mendapatkan perhatian sebagai mereka menua. Ini tidak terlihat di alat, tetapi jika Anda memetakan kurvanya:

• Masalah panjang lembar.
  Beberapa rumus dan skrip saya memerlukan rentang sel. Seiring bertambahnya situs dan baris dalam laporan sesi, rentang ini perlu diperbarui. (Tetapi mereka tidak dapat melebihi jumlah baris yang ada di lembar, atau beberapa di antaranya membuat kesalahan.)
• Ketidakmampuan untuk membuat grafik kurva penuh untuk setiap bagian konten.
  Ayo, aku ingin melihat semuanya!
• Interaktivitas terbatas dengan hasil grafik.
  Jika Anda pernah mencoba untuk memilih satu titik (atau kurva) pada grafik multi-kurva di Google Sheets… Anda tahu apa yang saya bicarakan. Ini bahkan lebih buruk ketika Anda memiliki lebih dari dua puluh kurva pada grafik yang sama, dan warnanya mulai terlihat sama.
• Kemungkinan mengabaikan konten yang berkinerja buruk tanpa sesi.
  Menggunakan metode yang saya sajikan di sini, sulit untuk mengidentifikasi konten yang secara konsisten tidak memiliki sesi. Karena tidak pernah muncul di laporan Google Analytics, itu tidak diambil di sisa alur kerja (belum). Konten yang secara konsisten tidak berkinerja memberikan nilai yang kecil, jadi kecuali jika Anda mencari halaman untuk dipangkas, konten yang tidak berkinerja bisa dibilang tidak memiliki tempat di laporan kinerja.
• Ketidakmampuan untuk beradaptasi dengan analisis waktu nyata.
  Meskipun tidak terlalu padat karya untuk menjalankan kembali skrip pelaporan, rata-rata, dan pasca pembaruan, ini masih merupakan tindakan manual di luar pembaruan terprogram mingguan. Jika pembaruan mingguan pada hari Rabu dan Anda bertanya kepada saya pada hari Selasa bagaimana keadaannya, saya tidak bisa hanya berkonsultasi dengan lembar.
• Keterbatasan ekspansi.
  Menambahkan sumbu analisis–seperti peringkat atau pelacakan kata kunci, atau bahkan opsi filter menurut wilayah geografis–ke laporan ini akan sulit. Tidak hanya akan memperburuk beberapa masalah yang ada, tetapi juga akan sangat sulit untuk menerapkan visualisasi yang dapat dibaca dan dapat ditindaklanjuti.

Kesimpulannya?

Menjalankan jenis penghitungan yang sama dalam pembelajaran mesin atau lingkungan terprogram akan mengatasi hampir semua masalah ini. Ini akan menjadi cara yang jauh lebih baik untuk menjalankan operasi semi-kompleks pada kumpulan data yang besar. Selain itu, ada perpustakaan luar biasa yang menggunakan pembelajaran mesin untuk mendeteksi anomali secara andal berdasarkan kumpulan data yang diberikan; ada alat yang lebih baik untuk visualisasi data.

Takeaways kinerja konten

Analisis kinerja konten, bahkan dengan metode primitif dan cacat, memperkuat pengambilan keputusan berbasis data dan waspada dalam strategi konten.

Secara konkret, memahami kinerja konten memungkinkan Anda untuk:

• Pahami nilai promosi awal vs aktivitas ekor panjang
• Temukan postingan yang berkinerja buruk dengan cepat
• Memanfaatkan kegiatan promosi luar untuk meningkatkan jangkauan
• Kenali dengan mudah apa yang membuat postingan tertentu begitu sukses
• Identifikasi penulis tertentu atau topik tertentu yang secara konsisten mengungguli orang lain
• Tentukan kapan SEO mulai berdampak pada sesi

Data ini yang mendorong keputusan yang tepat untuk mempromosikan konten–dan kapan dan bagaimana–, pilihan materi pelajaran, profil audiens, dan banyak lagi.

Terakhir, eksperimen seperti ini menunjukkan bahwa domain apa pun yang datanya dapat Anda peroleh memiliki potensi penggunaan untuk keterampilan pengkodean, pembuatan skrip, dan pembelajaran mesin. Tapi Anda tidak harus meninggalkan membuat alat Anda sendiri jika Anda tidak memiliki semua keterampilan ini.