ブログやSNSの運営データを一か所へ集め、将来的にAIで分析する「全媒体データ分析基盤」を作っています。
WordPress、GA4、Google Search Console、Bing、YouTubeなどからデータを取得できるようになると、次に問題になったのが「この数字は、どの記事についてのデータなのか」でした。
WordPressには投稿ID、Search ConsoleやGA4にはURL、YouTubeには動画IDがあります。XやPinterestなどを加えれば、それぞれ別の投稿IDが増えていきます。
そこで今回、外部サービスのIDとは別に「記事No」を用意し、ブログ・検索・SNS・動画をつなぐ基準として使うことにしました。
この記事で分かること
- WordPress投稿IDとは別に記事Noを作った理由
- URLやタイトルを識別子にしない考え方
- 検索・GA4・SNS・動画を記事へ紐付ける方法
- UTMを使ってSNS投稿からブログ流入まで追う仕組み
- AIによる全媒体分析で記事Noが果たす役割
WordPress投稿IDだけでは全媒体を管理できない
WordPressでは、各記事に投稿IDが自動的に割り当てられます。
ブログだけを管理するなら、それでも大きな問題はありません。
しかし、記事からPinterest画像やX投稿、YouTube Shortsなどを作っても、外部サービスはWordPress投稿IDを知りません。
そこで、
WordPress投稿ID＝WordPress内の識別子
記事No＝自分のコンテンツ全体を管理する識別子
と役割を分けました。
例えば「記事No.0065」であれば、WordPress上の投稿IDが何番でも、SNSや動画では別のIDが付いていても、内部では「0065から派生したコンテンツ」として扱えます。
記事Noは、いわばコンテンツの背番号です。
タイトルやURLをID代わりにしない
記事タイトルで紐付ける方法も考えられますが、タイトルはリライトによって変わります。
ブログでは「SEOキーワードとは？」でも、Xでは「SEOキーワードの基本」、YouTubeでは別の動画タイトルになるかもしれません。
URLも同様です。
パーマリンクの変更、末尾スラッシュ、クエリパラメータ、UTMなどによって表記が変化します。
そのため、タイトルやURLそのものを記事の識別子にはせず、変更されない記事Noを中心に置き、タイトル・URL・WordPress投稿IDを属性として管理する形にしました。
記事マスタを全媒体分析の基準にする
中心になるのが「記事マスタ」です。
記事No、WordPress投稿ID、タイトル、URL、公開日、カテゴリー、テーマ、ステータス、最終更新日などを管理します。
例えば、
記事No.0065
→ WordPress投稿ID
→ タイトル
→ URL
→ カテゴリー
という基本情報を確定させます。
記事マスタは単なる記事一覧ではありません。
各サービスに散らばった数字を、同じコンテンツのデータとして再び集めるための基準になります。
Search Console・GA4・Bingを記事Noへ戻す
Search Consoleは、記事Noではなく主にURLを基準として検索パフォーマンスを返します。
そこで、
Search ConsoleのURL
→ 記事マスタのURL
→ 記事No.0065
という形で紐付けます。
GA4も同様に、取得したページ情報を記事マスタと照合します。
これによって0065について、
検索表示 → クリック → ブログ流入 → サイト内行動
という流れを横断して確認できます。
Bingについても数字自体はGoogleとは別に保存しますが、「どの記事についてのデータなのか」という関係は同じ記事Noへ戻します。
つまり記事Noは、異なる媒体の数字を無理に統一するためではなく、別々に観測されたデータが同じコンテンツに関係していることを示すために使います。
一つの記事から複数のSNS投稿・動画へつなぐ
SNSや動画を加えると、関係はさらに広がります。
例えば0065から、
X投稿を3件、Pinterest投稿を2件、YouTube Shortsを5本作ったとします。
この場合は、
記事0065 → 複数のSNS投稿・動画
という1対多の関係になります。
SNS投稿を記事マスタの横へ列として追加するのではなく、SNS投稿は別のデータとして保存し、「元記事が0065」という関係だけを持たせます。
一方、すべてのSNS投稿がブログ記事から生まれるとは限りません。
SNSだけの投稿や動画独自の企画も考えられるため、記事Noがない投稿も保存できる構造にしています。
記事Noは中心的な軸ですが、すべてのコンテンツを無理にブログへ従属させるための番号ではありません。
UTMで「SNS投稿→ブログ流入」をつなぐ
さらに重要になるのがUTMです。
例えば0065を紹介するX投稿AにUTM付きURLを設定すると、
記事0065
→ X投稿A
→ UTM付きリンク
→ GA4流入
という関係を作れます。
これによって「Xで何回表示されたか」だけでなく、そこから何人がブログへ来て、その後どう行動したのかまで分析できる可能性があります。
ここでもUTM文字列から後で推測するのではなく、リンクを作った時点でどの投稿と関係するのかを記録する方針です。
分かっている関係は最初からデータとして残しておきます。
分からない関係は無理につながない
外部データをすべて記事Noへ自動的に紐付けられるとは限りません。
古いURLやパラメータ付きURLなど、どの記事なのか確定できないデータもあります。
その場合は、
resolved＝記事との関係を確認できた
unresolved＝まだ確認できない
として区別します。
「たぶん0065だろう」と無理に結び付けません。
未解決のまま保存しておけば、URL履歴や照合ルールを改善した後に再判定できます。
AI分析を前提にするほど、分からない関係を推測で確定しないことが重要になります。
記事NoがAI分析の共通軸になる
記事Noを中心に関係を保存できれば、AIへの質問も変わります。
「0065についてGoogle・Bing・GA4の推移を比較する」「検索では弱いがSNSで反応が良い記事を探す」「同じ記事から作った動画の反応を比較する」といった媒体横断の分析が可能になります。
さらに、記事公開後の検索流入、SNS投稿、動画制作、リライト、再投稿などを同じ記事Noへ蓄積すれば、一つの記事が時間とともにどう育ったのかも追えるようになります。
長いタイトルやURLではなく「0065」と指定できるため、人間側のコンテンツ管理にも使いやすい仕組みです。
まとめ
全媒体データ分析基盤では、媒体ごとに数字を取得するだけでは十分ではありませんでした。
本当に必要だったのは、別々の場所から取得した数字が、どのコンテンツに関係しているのかを記録する仕組みです。
そこで、WordPress投稿IDやURLとは別に記事Noを用意しました。
記事Noを基準として、WordPress、Search Console、Bing、GA4、SNS投稿、動画、UTM、ブログ流入をつなげていきます。
ただし、各媒体のデータそのものを一つに混ぜるわけではありません。それぞれの意味や外部IDを残しながら、「同じコンテンツに関係している」という関係だけを正しく管理します。
AIに全媒体のデータを分析させるには、大量の数字だけでなく、どの数字とどの数字が同じコンテンツについてのものなのかを理解できる構造が必要です。
一見地味な記事Noですが、実際にシステムを作ってみると、検索・アクセス・SNS・動画をつなぐ全媒体分析の背骨になってきました。
