バックリンクとサーチコンソールエクスポートの結合手順

セットアップと、結合がもたらす利点

サーチコンソールはリンク元サイトを表示しますが、順位付けはしません。

上位リンク元サイトをCSVとしてエクスポートすると、ドメインの列は得られますが、重み（権威値）の情報は含まれません。このギャップを埋めるのが結合の役割です。生エクスポートは単なるリストであり、論理的な根拠ではないからです。

当社のbulk_drアクションは、1回の呼び出しで列全体のDRをスコアリングします。結合はドメインをキーとした単なるleft_join()で済みます。サーチコンソールは認識しているリンクの一部しか表示しないため、エクスポートを総数ではなく下限値として扱ってください。

この例から読み取れること、および読み取れないこと

フォーラムの行を注意深く読んでください。DR 9のリンクが40件あっても、それは重みを持たないボリュームに過ぎません。

この架空のケースでは、1リンクずつの2行が、薄型サイトからの67リンクよりも上位にランクインしています。これは実際のデータで狙うべきパターンであり、DRの仕組みを反映したものであり、ランキングを保証するものではありません。

因果関係を過度に読み取らないでください。Googleはリンクを多数あるシグナルの一つと述べており、2024年3月のコアアップデート以降、その状況はさらに複雑になっています。

複数のエクスポートを1つのテーブルに積み重ねる

バックリンクとサーチコンソールエクスポートを結合する前に、ファイルを積み重ねてください。実際の業務では、クライアント別や四半期別など、複数のエクスポートを扱うことが多く、結合先が1つのテーブルである方が処理がクリーンになります。

ファイルが本当に一致しているか確認する

複数人から送られた複数のCSVファイルは、列名、列の順序、日付形式、エンコーディングが一致している場合にのみクリーンに結合できます。クライアントごとに1つのエクスポートを受け取る場合を想定します。結合する前に、各ファイルのヘッダー行を比較し、いずれかが異なる場合は処理を停止してください。

素早いチェックとして、ファイルごとの列名のリストと、スクリプト内の単一の停止条件を用意します。これは数行のコードで済み、静かな位置ずれを防ぎます。

区切り文字と小数点

異なるマシンからのエクスポートは、区切り文字がセミコロンだったり、小数点の表記が異なったりすることがあります。カンマ区切りファイルと仮定する前に各ファイルの区切り文字を確認し、小数点の表記が異なる場合は明示的なロケールを設定してください。

単一列にパースされるファイルは、最も安価な失敗検知の対象です。各ファイルの列数を出力し、1列になった場合は停止してください。

パースの選択をデフォルトではなく明示的な引数としてスクリプトに書き込み、次の人がデータを開かずにそれらを確認できるようにしてください。

ソース列付きの1つの長いテーブル

ファイルを読み込み、ソースファイルとエクスポート日付を記録する列を持つ1つの長いテーブルに積み重ねます。このテーブルは、手動でステップごとに管理されるシート群に取って代わります。

サマリーは、クライアントごとのシートではなく、1回のgroup_by()呼び出しで実行できます。生ファイルをそのままにしておけば、積み重ねステップを最初から再実行できます。

シート間のルックアップは結合である

「列2を列1と一緒に移動する」というリクエストは、隠れた結合です。キー（ここではドメイン）を選択し、left_join()を使って2列目を横断させてください。スプレッドシート版は行が移動すると壊れますが、キー付き結合は壊れません。

2番目のテーブルが異なるキー形式を使用している場合、結合後に修正するのではなく、結合前にキーを修正してください。不一致は通常、ケースやプレフィックスの問題です。

結合で解決できないこと

結合はキーに基づいて2つのテーブルを並べます。しかし、2つのソースを一致させることはできず、エクスポートされなかったドメインを救うこともできません。2つのエクスポートでカウントが異なる場合、結合はその不一致を解決するのではなく、表示するだけです。

レポートでその差異を可視化し、両方のソース名を隣に配置してください。そうすれば、読者はその数値がどのエクスポートに由来するかを確認できます。

結合は、2つのソースが不一致である理由も教えてくれません。生行を確認する必要があり、これもエクスポートをそのままにしておく理由の1つです。

テーブルにソース名を保持する

ソース列は安価な保険です。6ヶ月後に数値が間違っているように見える場合、最初の質問は「それがどのエクスポートに由来するか」であり、その列は古いフォルダを検索することなくそれに応えます。

クライアントがなぜ1つのドメインが2回表示されているのかと尋ねた場合、ソース列はそれが春のエクスポートと夏のエクスポートに由来していることを示します。これは1文で説明できる事実です。

結合を成功させるクリーニングルール

キーが最初に壊れ、静かに壊れます。

呼び出し前に、すべてのドメインを小文字に変換し、先頭のwwwを削除し、末尾のドットとスラッシュを削除し、重複を結合してください。1文字の大文字の誤りが、良い一致をNAに変え、クライアントが質問するまで気づかない可能性があります。

生エクスポートは独自のファイルとしてそのままにしておき、クリーニング済みのテーブルをその隣に書き出し、ファイル名にエクスポート日付を記録します。月次ランブックは日付付きファイルがなぜ重要かを説明し、一括スコアリングページには再利用可能なリクエストコードがあります。

最後に、エクスポートに1,200件の一意なドメインがあり、スコアリング済みテーブルに1,150件ある場合、グラフ化する前にその50件を見つけてください。用語集はアクションの戻り値をリストし、意思決定ツリーは他のソースがより良い答えとなる場合を示しています。

結合を再構築せずに2番目のエクスポートを追加する

2番目の期間を追加する際に、多くの結合が静かに失敗します。解決策は、スコアに触れる前にスナップショットを決定することです。

スナップショットをキーの一部として考えてください。同じドメインで異なるスナップショット日付を持つ2つの行は、数値が似ていても異なる事実です。

異なる月からの2つのエクスポートは、スナップショットの問題が解決されるまでトレンドではありません。まずそれを解決し、その後に線を描いてください。

両方の期間を1パスでスコアリングする

今四半期と先四半期のエクスポートがあると仮定します。両方を日付とともに積み重ね、2つのファイル全体で一意なドメインを1パスでスコアリングします。そうすれば、両方の四半期が1つのスナップショットを共有することになります。

別々のタイミングで別々にスコアリングすると、2つのインデックス状態が1つの比較に混入します。チャートにスナップショット日付を記載し、読者が両方の数値が1つのパスに由来することを確認できるようにしてください。

両方に出現するドメイン

両方のエクスポートに存在するドメインは、スコアテーブルでは1回、積み重ねテーブルでは2回表示されるはずです。これにより、スコアと四半期ごとのリンク数が正確に保たれます。

結合する前にスコアテーブルをドメインごとに1行にしてください。そうすれば、結合によって行が増殖するのを防げます。行数が一意なドメインの数と一致することを確認してください。

スコアリングと結合を別々のステップに保つ

スコアリングステップを別々のスクリプトに、結合を別のスクリプトに保ってください。スコアが変更された場合、どのステップを再実行すべきかが明確になり、結合を手動で再実行する必要がなくなります。

スナップショット日付とエクスポート名を記録した小さなファイルがあれば、後で2つのステップを簡単に一致させることができます。