コンテンツのパフォーマンスを理解するためのツールの構築
公開: 2020-09-03コンテンツはインバウンドマーケティング戦略を推進する主要な力の1つであり、SEOはそれを機能させるための不可欠な部分です。 一般的に、これはページ上のSEOの基本をカバーします：記事の構造、キーワードの配置、メタタグ、タイトルタグ、代替テキスト、見出し、構造化データ、およびリストとテーブルで非公式に構造化されたデータを作成するためのフォーマットの使用。
OnCrawlを使用して、コンテンツ管理の一部としてページ上のSEOを監査します。
これは、サイトの監査や定期的なクロール、マシンで生成された自然言語のメタ記述、スニペット制御タグ、構造化データの挿入など、大量の最適化や監視を開始するときに、技術的なSEOの傘下に入ります。
ただし、コンテンツのパフォーマンスが懸念される場合、技術的なSEOとコンテンツマーケティングの交差点はさらに大きくなります。SERPのページランク、クリック数、インプレッション数、セッション数など、同じプライマリデータを調べます。 同じ種類のソリューションを実装したり、同じツールを使用したりする場合があります。
コンテンツパフォーマンスとは何ですか？
コンテンツのパフォーマンスは、視聴者がコンテンツをどのように操作したかによって測定可能な結果です。 コンテンツがインバウンドトラフィックを促進している場合、そのトラフィックの測定値は、そのコンテンツがその仕事をどれだけうまく行っているか、またはどれだけうまく行っていないかを反映します。 すべてのコンテンツ戦略は、具体的な目的に基づいて、特定のKPIを定義する必要があります。 ほとんどの場合、次のメトリックが含まれます。
- 検索でのコンテンツの視認性（SERPでの表示回数）
- 関連する検索エンジンがコンテンツをどのように考えているか（SERPでのランキング）
- 適切な検索者がコンテンツの検索リストをどのように考えているか（SERPからのクリック）
- コンテンツを表示する人の数（分析ソリューションの訪問またはセッション）
- ビジネス目標を促進する方法でコンテンツを操作する人の数（コンバージョントラッキング）
ここまでは順調ですね。
カーソルを置くのが難しいのは、コンテンツのパフォーマンスが良いことを意味する数字は何ですか？ 何が正常ですか？ そして、何かがうまくいかないときをどうやって知るのですか？
以下では、これらの質問に答えるのに役立つローテクツールの「概念実証」を構築するための実験を共有します。
コンテンツパフォーマンスの標準が必要なのはなぜですか？
コンテンツ戦略の私自身のレビューの一部として私が答えたかった質問のいくつかはここにあります：
- 社内コンテンツとゲスト投稿のパフォーマンスに違いはありますか？
- 私たちが推進している、うまく機能しない科目はありますか？
- 「常緑樹」の投稿を、3年も待たずに、まだ毎週のトラフィックを集めているかどうかを確認するにはどうすればよいですか。
- 独自のプロモーション戦略を即座に適応させ、可視性の向上を活用するために、プロモーションレーダーに載っていなかったニュースレターで投稿が取り上げられた場合など、サードパーティのプロモーションによるマイナーなブーストを特定するにはどうすればよいですか？
ただし、これらの質問のいずれかに答えるには、作業しているサイトでの「通常の」コンテンツパフォーマンスがどのように見えるかを知る必要があります。 そのベースラインがなければ、特定のコンテンツまたはコンテンツのタイプが（ベースラインよりも優れている）パフォーマンスが高いかどうかを定量的に判断することは不可能です。
ベースラインを設定する最も簡単な方法は、公開後の1日あたり、記事ごとの平均セッションを確認することです。ここで、0日目は公開日です。
これにより、次のような曲線が生成され、最初の関心のピーク（および、分析を検索エンジンのみからのセッションに限定していない場合は、プロモーションの結果）が表示され、その後にロングテールが続きます。低金利：
典型的な投稿の実際のデータ：公開日またはその直後のピークと、それに続くロングテール。多くの場合、最終的には元のピークよりも多くのセッションが発生します。
各投稿の曲線がどのように見えるかがわかれば、各曲線を他の曲線と比較して、何が「正常」で何がそうでないかを確認できます。
これを行うためのツールがない場合、これは首の痛みです。
このプロジェクトを開始したときの目標は、コンテンツのパフォーマンスの調査方法を変更するのに十分なPythonを学習する前に、Googleスプレッドシートを使用して概念実証を構築することでした。
プロセスをフェーズとステップに分割します。
- ベースラインを見つける
–学習したいコンテンツをリストします
–各コンテンツが1日に受信したセッション数を確認します
–セッションリストの日付を公開からの日数に置き換えます
–ベースラインとして使用する「正規」曲線を計算します - ベースラインとは異なるコンテンツを特定する
- 最新の状態に保つ
コンテンツパフォーマンスベースラインを見つける
勉強したいコンテンツをリストアップ
まず、調べたいコンテンツのリストを作成する必要があります。 コンテンツごとに、URLと公開日が必要になります。
このリストは、手動で作成する場合でも、自動化された方法を使用する場合でも、好きなように取得できます。
Apps Scriptを使用して、APIを使用してCMS（この場合はWordPress）から各コンテンツのURLとその公開日を直接取得し、その結果をGoogleスプレッドシートに書き込みました。 スクリプトやAPIに慣れていない場合でも、これは比較的簡単です。 WordPressでこれを行う方法の複数の例をオンラインで見つけることができます。
このデータを各投稿のセッションデータと比較する必要があることに注意してください。そのため、このシートの「スラッグ」が分析ソリューションによって提供されるURLパスの形式と一致することを確認する必要があります。
Google Analyticsから取得したデータを変更するよりも、上記の列Eで完全なスラッグ（URLパス）を作成する方が簡単だと思います。 また、計算量も少なくなります。このリストの行数は少なくなります。
このサイトの完全なURLを作成する式の例：CMSによって提供されたカテゴリ番号をテーブルで検索し、このサイトのURLパターンと一致する記事スラッグの前に配置されたカテゴリ名を返します（https：// site .com / categoryName / articleSlug /）
バックエンドにアクセスできない場合は、クロール中など、Webサイト自体からこの情報を取得してリストを作成できます。 次に、必要なデータのCSVをエクスポートして、Googleスプレッドシートにインポートできます。
OnCrawlにデータフィールドを設定して、Webサイトのブログから発行日を取得します。
OnCrawlのデータエクスプローラーにあるURLやスクレイプされた公開日などのデータは、エクスポートの準備ができています。
各コンテンツが獲得した1日あたりのセッション数を確認します
次に、コンテンツごとおよび1日ごとのセッションのリストが必要です。 つまり、コンテンツの一部が30日経過していて、その期間中に毎日訪問を受けた場合、残りのコンテンツには30行を含める必要があります。
これには、同じドキュメントに別のシートが必要です。
GoogleスプレッドシートへのGoogleAnalyticsアドオンにより、これは比較的簡単になります。
必要なデータを含むGoogleAnalyticsビューから、次のレポートをリクエストできます。
| 日付 | 指標 | 寸法 |
|---|---|---|
| 1000日前から 昨日まで。今日のデータはまだ終わっていないのでまだ完成していません。 これを含めると、「通常の」完全な1日のようには見えず、すべての統計がダウンします。 | セッション セッション数に関心があります。 | ランディングページ これにより、各ランディングページのセッションが個別に一覧表示されます。日付 これは、合計1000日ではなく、各日付のセッションを個別に一覧表示します。 |
この段階では、GoogleAnalyticsデータのセグメントを使用すると非常に役立ちます。 たとえば、サイト全体ではなく、分析したいコンテンツURLのみを含むセグメントにレポートを制限できます。 これにより、結果のレポートの行数が大幅に削減され、Googleスプレッドシートでのデータの操作がはるかに簡単になります。
さらに、厳密にSEOの目的でオーガニックパフォーマンスのみを確認する場合は、SEO作業に起因しない取得チャネル（紹介、メール、ソーシャルなど）をセグメントから除外する必要があります。
誤ってデータを切り捨てないように、制限が十分に高いことを確認することを忘れないでください。
公開からの日数を計算する
記事の各データポイントの公開からの日数を計算するには、セッションレポートのデータをコンテンツリストのデータに参加させる（または、Data Studioユーザーの場合は「ブレンド」する）必要があります。 。
これを行うには、URLまたはURLパスをキーとして使用します。 つまり、URLパスは、CMSテーブルとGoogleAnalyticsレポートの両方で同じ方法でフォーマットする必要があります。
アナリティクスレポートのランディングページからパラメータを削除できるように、別のテーブルを作成しました。 列の設定方法は次のとおりです。
- ランディングページ
AnalyticsレポートのURLスラッグからパラメーターをスクラブします
サンプル式：
- 日にち
アナリティクスレポートからのセッションが記録された日付
サンプル式：
- セッション
アナリティクスレポートからのセッションが記録された日付
サンプル式：
- 出版後の日数
作成したCSMテーブルの列でこのURLの公開日を検索し、これらのセッションが記録された日付からそれを差し引きます。 URLがCMSテーブルに見つからない場合は、エラーではなく空の文字列を報告します。
サンプル式：
ルックアップキー（完全なURLパス）は、データの左端の列ではないことに注意してください。 VLOOKUPの目的で、列Cの前に列Eをシフトする必要がありました。
行が多すぎて手作業で入力できない場合は、次のようなスクリプトを使用して、最初の行のコンテンツをコピーし、次の3450程度に入力できます。
関数FillDown（）{
var Spreadsheet = SpreadsheetApp.getActive（）;
Spreadsheet.getRange（'F2'）。activate（）;
Spreadsheet.getActiveRange（）。autoFill（spreadsheet.getRange（'F2：F3450）、SpreadsheetApp.AutoFillSeries.DEFAULT_SERIES）;
};公開後の1日あたりの「通常の」セッション数を計算します
通常のセッション数を計算するために、グラフと組み合わせた非常に単純なピボットテーブルを使用しました。 簡単にするために、私は公開後の1日あたりの平均セッション数を調べることから始めました。
これは、公開後1000日間のセッションの平均と中央値です。 ここから始めて（？）、データ視覚化プロジェクトとしてのGoogleスプレッドシートの限界を確認します。
これはB2Bサイトであり、平日のセッションはサイト全体でピークになります。 週に数回、ただし常に同じ日に記事を公開します。 ほぼ毎週のパターンを見ることができます。
この場合、視覚化の目的で、7日間のローリング平均を確認するのがおそらく最善ですが、公開から数週間でスムーズになるクイックバージョンを次に示します。
この長期的な見方にもかかわらず、次のステップでは、後でGoogleスプレッドシートの制限内にとどまるために、グラフを公開後90日に制限します。
異常の検索
特定の日の平均的な投稿がどのように見えるかがわかったので、任意の投稿をベースラインと比較して、パフォーマンスが高いか低いかを確認できます。
手動で行うと、これはすぐに「手に負えない」状態になります。 駄洒落はさておき、少なくともこれのいくつかを自動化してみましょう。
すべての投稿（90日未満）は、90日ウィンドウで毎日設定したベースラインと比較する必要があります。
この概念実証のために、私は1日の平均からのパーセント差を計算しました。
厳密な分析を行うには、1日あたりのセッションの標準偏差を調べ、個々のコンテンツのパフォーマンスがベースラインからどれだけ標準偏差であるかを確認する必要があります。 平均パフォーマンスから3標準偏差のセッション数は、その日の平均とX％以上異なるものよりも異常である可能性が高くなります。
ピボットテーブルを使用して、その期間中に少なくとも1日異常があったすべてのコンテンツ（過去90日間のセッションを含む）を選択しました。
Googleスプレッドシートでは、ピボットテーブルで100を超える列を作成することはできません。 したがって、この分析には90日の制限があります。
この表をグラフ化しました。 （理想的には、これらの記事ごとに90日間の曲線全体をグラフ化したいと思いますが、曲線をクリックした場合のシートの応答も必要です。）
物事を最新に保つ：更新の自動化
ここには3つの主要な要素があります。
- ベースライン
- 追跡するコンテンツの断片
- これらのコンテンツのパフォーマンス
残念ながら、これらはいずれも静的ではありません。
理論的には、コンテンツのターゲティングと宣伝が上手になると、平均的なパフォーマンスは向上します。 これは、ベースラインを頻繁に再計算する必要があることを意味します。
また、Webサイトに季節的な山と谷がある場合は、ここで行ったように融合を作成するのではなく、より短い期間または毎年同じ期間の平均を調べる価値があるかもしれません。
より多くのコンテンツを公開すると、新しいコンテンツも追跡する必要があります。
そして、来週のセッションの日付を見たいときは、それはありません。
つまり、このモデルは多かれ少なかれ頻繁に更新する必要があります。 確認するたびにツール全体を最初から再構築するのではなく、更新を自動化する方法は複数あります。
実装するのが最も簡単なのは、おそらく分析セッションの毎週の更新をスケジュールし、同時に新しい投稿（公開日を含む）を取得することです。
使用したGoogleAnalyticsレポートは、定期的に自動的に実行されるように簡単にスケジュールできます。 欠点は、過去のレポートが上書きされることです。 レポート全体を実行および管理したくない場合は、レポートをより短い期間に制限できます。
私の目的では、7日間のウィンドウを見ると、古くなりすぎずに作業するのに十分な情報が得られることがわかりました。
90日間のウィンドウ外の常緑樹の投稿に注目する
以前に生成したデータを使用して、ほとんどの投稿の平均が1週間あたり約50セッションであると判断できたとします。
したがって、公開日に関係なく、毎週のセッションが50を超える投稿を監視することは理にかなっています。
記事は発行期間によって色分けされています：過去90日（青）、過去1年（オレンジ）、およびレガシー（灰色）。 週ごとの合計は、セッションの目標である50と比較することで色分けされています。
週の1日あたりの合計セッション数を分類すると、パフォーマンスがかなり一貫している常緑樹の投稿と、パフォーマンスが不均一なイベント駆動型のアクティビティをすばやく簡単に区別できます。
エバーグリーンコンテンツ（±20 /日の一貫したパフォーマンス）
可能性のある外部プロモーション（短期的なピーク以外の一般的なパフォーマンスの低下）
この情報をどのように扱うかは、コンテンツ戦略によって異なります。 これらの投稿がWebサイトのリードをどのように変換するかを考えたり、バックリンクプロファイルと比較したりすることをお勧めします。
コンテンツ分析のためのGoogleスプレッドシートの制限
この時点でお気づきかもしれませんが、Googleスプレッドシートは、この種の分析には非常に強力ですが、限られたツールです。 これらの制限により、テンプレートを共有しないことをお勧めします。テンプレートをケースに適合させるには多くの作業が必要ですが、得られる結果は、依然として広いストロークで描かれた近似値にすぎません。
このモデルが提供できない主なポイントのいくつかを次に示します。
- 数式が多すぎます。
アクティブなコンテンツのURLがたくさんある場合（たとえば、数千）、非常に遅くなる可能性があります。 毎週の更新スクリプトでは、計算後に多くの数式をそれらの値に置き換えて、後で分析のためにファイルを開いたときにファイルが実際に応答するようにします。 - 静的ベースライン。
コンテンツのパフォーマンスが向上するにつれて、「パフォーマンスが優れている」コンテンツが増えています。 ベースラインは、進化を説明するために数か月ごとに再計算する必要があります。 これは、教師なし機械学習モデルを使用して平均を計算することで簡単に解決できます（または、このステップをスキップして異常を直接特定することもできます）。 - 「不正確な」ベースライン。
ベースラインは、季節的な変化やサイト全体のインシデントを考慮していません。 また、特に計算をより短い期間に制限する場合は、極端なイベントに非常に敏感です。
統計的に不健全な外れ値分析。
特に、コンテンツアイテムごとに1日あたりのセッション数が少ない場合、平均との差が10％であると主張することは、異常なパフォーマンスを構成します。
分析の90日までの任意の制限。
任意の制限が問題になります。 この場合、常緑のコンテンツのパフォーマンスを理解できなくなり、パフォーマンスのピークが見えなくなります。ただし、Googleアナリティクスから、非常に古い作品が突然注目を集めることがあることや、一部の記事が着実に注目を集めていることはわかっています。彼らは年をとります。 これはツールには表示されませんが、曲線をグラフ化すると表示されます。
- シートの長さの問題。
私の数式やスクリプトの中には、さまざまなセルが必要なものがあります。 セッションレポートのサイトと行が大きくなるにつれて、これらの範囲を更新する必要があります。 （ただし、シートに存在する行数を超えることはできません。超えない場合、エラーが発生する場合があります。） - コンテンツの各部分の完全な曲線をグラフ化できない。
さあ、私はすべてを見たいです！ - グラフ化された結果との限られた双方向性。
Googleスプレッドシートのマルチカーブグラフで1つのポイント（またはカーブ）を選択しようとしたことがある場合は、私が何を話しているかご存知でしょう。 同じグラフに20を超える曲線があり、色がすべて同じに見え始める場合、これはさらに悪化します。 - セッションなしでパフォーマンスの低いコンテンツを見落とす可能性。
ここで紹介した方法では、一貫してセッションがないコンテンツを特定するのは困難です。 Google Analyticsレポートには表示されないため、ワークフローの残りの部分では（まだ）検出されません。 一貫してパフォーマンスが低下するコンテンツはほとんど価値をもたらさないため、整理するページを探しているのでない限り、パフォーマンスの低いコンテンツはパフォーマンスレポートにその場所を持たないことは間違いありません。 - リアルタイム分析に適応できない。
レポート、平均化、および更新後のスクリプトを再実行することは特に労働集約的ではありませんが、これらは毎週プログラムされた更新以外の手動のアクションです。 毎週の更新が水曜日で、火曜日に状況がどうなっているのかと聞かれたら、シートを参照するだけでは不十分です。 - 拡張の制限。
このレポートに、ランキングやキーワードトラッキングなどの分析軸を追加したり、地理的な地域でオプションをフィルタリングしたりするのは面倒です。 既存の問題の一部を悪化させるだけでなく、読みやすく実用的な視覚化を実装することも非常に困難になります。
結論？
機械学習またはプログラム環境で同じタイプの計算を実行すると、これらの問題のほとんどすべてに対処できます。 これは、大量のデータセットに対して半複雑な操作を実行するためのはるかに優れた方法です。 さらに、機械学習を使用して、特定のデータセットに基づいて異常を確実に検出する優れたライブラリがあります。 データを視覚化するためのより優れたツールがあります。
コンテンツパフォーマンスのポイント
コンテンツパフォーマンス分析は、原始的で欠陥のある方法であっても、コンテンツ戦略におけるアラートとデータ主導の意思決定を強化します。
具体的には、コンテンツのパフォーマンスを理解することで、次のことが可能になります。
- 初期プロモーションとロングテール活動の価値を理解する
- パフォーマンスの低い投稿をすばやく見つける
- リーチを拡大するために外部のプロモーション活動を活用する
- 特定の投稿が成功する理由を簡単に認識できます
- 一貫して他の人よりも優れている特定の著者または特定のトピックを特定する
- SEOがセッションに影響を及ぼし始める時期を特定する
このデータは、コンテンツを宣伝するための情報に基づいた決定を推進し、いつ、どのように、主題の選択、視聴者のプロファイリングなどを促進します。
最後に、このような実験では、データを取得できるドメインには、コーディング、スクリプト、機械学習のスキルが使用できる可能性があることが示されています。 ただし、これらのスキルをすべて持っていない場合は、独自のツールの作成を放棄する必要はありません。