SEOプラットフォームには、スタックの最下層に共通する依存関係が一つある。それは、多数のキーワードについて、多数の地域にわたって、毎日、検索結果を確実に取得できる仕組みだ。そして、これを構築するあらゆる創業者は、その供給を自社で構築するか購入するかという同じ初期判断に直面する。
この判断は通常コスト比較として捉えられがちだが、それは誤った捉え方だ。正しい問いは、収集が自社の製品の一部であるかどうかであり、ほとんどすべてのSEOプラットフォームにとって、正直な答えは「否」である。顧客が対価を払うのは、分析、ワークフロー、レポート、インターフェースに対してだ。ベンダーが結果ページのパースに長けていたという理由で契約を更新した顧客は、これまで一人もいない。
実際に購入しているもの
SERP APIは、収集を自前で行う際に何が伴うかを列挙してみるまでは、単なる便利機能に見える。
パース処理の保守。 結果ページのレイアウトは予告なく変わり、その変化のたびに自社側でデータ品質のサイレントな事故が起きる。これはチームを驚かせる恒常的なコストであり、決して終わることがなく、常に都合の悪いタイミングで発生する。
地理的カバレッジ。 ローカライズされた結果を得るには各市場の内部からリクエストを送る必要があり、それには国・都市単位のターゲティングが可能なレジデンシャルネットワークか、それを処理してくれるAPIのいずれかが必要になる。その理由の詳細は正確な順位追跡にレジデンシャルプロキシが必要な理由にある。
スループットとペーシング。 検索エンジンはスロットリングを行うため、スループットはワーカー数の問題ではなく、分散と節度の問題になる。
自社ではコントロールできない稼働率。 自社製品が毎日の更新を約束しているなら、その約束は収集レイヤーにそのまま引き継がれる。
SERP APIを購入することは、これらすべてをリクエストとレスポンスに変換することを意味する。自前で構築することは、それをチームの継続的な責任に変換することを意味する。どちらも正当な選択だが、後者が正しいのは、収集が自社にとって真に差別化要因である場合に限られ、インサイトを販売するプラットフォームにとっては、通常そうではない。
モデルを決定づける単位経済性
どちらの道を選ぶにせよ、事業を左右する数字は「追跡キーワード1件・チェック1回あたりのコスト」であり、これがあらゆる要素に乗算されるからだ。
具体的に計算してみよう。500キーワードを毎日、2つの地域と2つのデバイスで追跡する顧客であれば、1日2,000回のチェック、月間60,000回になる。これが1アカウント分だ。同規模のアカウントが100あれば、月間600万回のチェックとなり、1回あたりわずか1セントの何分の一かの差が、粗利益を左右する項目になる。
この算術は、ほとんどの創業者が暗黙のうちに下し、本来は意図的に下すべき3つの製品判断を導く。
プランの料金体系が実際に何を計測するか。 追跡キーワード数は販売する単位として自然だが、コストを左右するのはチェック回数、つまりキーワード数に地域数、デバイス数、頻度を掛け合わせたものだ。キーワード数を販売基準にしながら地域数を無制限にするプランは、まさに製品を最も活用してくれる顧客において利益率を逆転させてしまう。
デフォルトのチェック頻度。 毎日というのが期待値だが、追跡対象キーワードのかなりの割合はほとんど動かない。変動の大きいキーワードはより頻繁に、安定したキーワードはより少なく確認する適応型頻度は、顧客が重要な違いに気づくことなくコストを大幅に削減する。変動性を特定するには結果セット全体が必要であり、これはSERPの変動性を検知するで論じている論点だ。
テナント間の重複排除。 複数の顧客が同じ地域で同じキーワードを追跡することは頻繁に起こる。アーキテクチャが結果を顧客単位ではなく、キーワード・地域・デバイスをキーとして保存していれば、1回のチェックで全員に対応できる。規模が大きくなるほど、これはしばしば得られる最大のコスト削減であり、後から作り直すのは非常に困難なため、最初のスキーマに組み込むべきものだ。
成長に耐えるアーキテクチャ
うまく機能する構造は地味だが、早い段階で正しく設計する価値がある。
収集レイヤーと顧客レイヤーを分離する。収集はキーワード、地域、デバイス、タイムスタンプという測定単位でキー付けされ、顧客はその測定に対して購読する。この分離があるからこそ重複排除が可能になり、レート制限が顧客ごとの問題ではなくグローバルな問題として扱えるようになる。
各顧客の順位だけでなく、結果セット全体を保存する。競合の動きこそが、顧客自身の順位変動を解釈可能にするものであり、AIオーバービューのような機能は順位の価値そのものを変えてしまう。そして先週の火曜日のSERPを後から取得することはできない。ストレージは安価だが、失われた履歴はそうではない。
単一の日次ジョブではなく、鮮度ティアでスケジューリングする。エンタープライズアカウントには朝の配信が必要な場合があり、セルフサーブ層は一日を通して分散させることができ、分散させることは無料でスループットを稼ぐことになる。
失敗を明示的に記録する。マルチテナント製品では、欠落がサポートチケットになるからだ。安定した日と見分けがつかない欠測日は、自社の数値への信頼を最も早く損なう要因であり、そのパイプラインパターンは日次キーワード順位監視の自動化に記載している。
規模拡大で実際に破綻するもの
創業者が報告する苦労のほとんどは、4つの障害パターンに起因する。
特定市場でのサイレントな劣化。 ある国で収集が機能しなくなっても、ダッシュボードにはエラーではなく横ばいの順位として表示される。市場ごとの成功率モニタリングと、取得したページが本物の結果ページであることの検証で防御する。詳細はブロックされたコンテンツや偽のコンテンツを検知するにある。
測定のドリフト。 デフォルトの地域、デバイス、タイミングの変更は、全顧客に一斉に順位変動を発生させ、サポートはそれを本物の順位変動と区別できない。これらは定数として固定し、バージョン管理する。詳細は正確なキーワード順位の測定にある。
単一アカウントによるコストの予想外の増大。 20の地域にわたって数千のキーワードを追加する1件のエンタープライズ顧客が、1日で収集コストを倍増させることがある。チェック単位で計測し、アカウントレベルの増加にアラートを設定する。
見解の不一致によるサポート負荷。 顧客が自社の数値を他のツールと比較し、チケットを開く。答えは測定契約の文書化であり、これは同時に自社データを擁護可能にするものでもある。使用している地域、デバイス、言語、パーソナライゼーションモデルを明記すること。異なる方法で測定する2つのツールが一致しないのは当然だからだ。
代わりに競争すべき場所
収集がコストセンターであるならば、差別化はその上のあらゆる層にある。順位をインサイトに変える分析、シェア・オブ・ボイスと競合の動き、顧客の他のスタックとの統合、顧客が実際にクライアントへ送るレポート、そして次に何をすべきかを教えてくれるワークフローだ。これらは顧客が「なぜ使い続けるのか」を説明するときに挙げるものであり、そのどれもパーサーを自社で保有することでは改善されない。
収集を自前で構築すべきなのは、自社製品の価値提案に、一般的なAPIにはできない何かが本当に含まれている場合、つまり特殊な情報源、取得時点での独自の後処理、あるいは経済性が逆転するほどの規模がある場合に限る。そうしたケースは存在するが、構築したいという本能が示唆するよりもずっと稀だ。
結論
製品がインサイトであるプラットフォームにとって、検索データは差別化要因ではなく入力にすぎない。したがって、構築か購入かという問いは、収集が自社の販売するものの一部であるかどうかにかかっている。購入することで、パース処理の保守、地理的カバレッジ、ペーシング、稼働率をAPIコールに変換できる。自前で構築すれば、それらはチームの恒久的な責任になる。いずれにせよ、キーワード単位ではなくチェック単位でコストをモデル化すべきだ。地域、デバイス、頻度は利益率を左右する乗数だからだ。そして、テナント間の重複排除を最初のスキーマに設計しておくべきだ。それが得られる最大の節約であり、後から作り直すのが最も困難だからだ。収集と顧客を分離し、結果セット全体を保存し、失敗を明示的に記録し、測定契約を文書化しておけば、他のツールとの見解の不一致も、気まずいものではなく説明可能なものになる。
購入が答えであれば、SERP APIが地理的カバレッジをすでに処理済みのパース済み結果を提供してくれる。構築が答えであれば、その下にある収集レイヤーは、国・都市単位のターゲティングを備えたレジデンシャルプロキシであり、GB単位で課金されることで、自社の単位経済性を明瞭に保つことができる。