公開後もスコアを追い続ける

ダッシュボードは、私たちがこのプロダクトの後半部分に組み込んだもののうち、最も重要度の低いものです。ローンチの圧力で、予定通りに他のすべてを出荷するために何か一つを削らなければならないとしたら、真っ先に削るのはこれです——毎日自分たちのダッシュボードを見ている人間として、そう言っています。

理由はこうです。同じパターンを何度も見てきたので、予測できます。誰かが6週間かけて良いものを作り、火曜日にローンチし、初日にAnalyticsを11回チェックし、翌日は2回、その次の日は1回、そしてそれっきり二度と見なくなる。彼らは関心を失ったわけではありません。チェックすることは簡単で、行動することは難しいのです——Search Consoleの40個のクエリのうちどれが本当に重要かを知る必要があり、4,000インプレッションに対するクリック率2.1%がそのランキング順位にとって悪いのか普通なのかを判断する必要があり、そしてローンチ週以来開いていないCMSに入ってメタディスクリプションを書き直しに行く必要があります。3つのステップ、それぞれにループを断ち切るのに十分な摩擦があります。ダッシュボードはそれを解決しません。ダッシュボードこそが、摩擦の存在する場所なのです。

毎日届くもの、そして最初の週にどれだけ信頼すべきか

同期は4つの場所から行われますが、初日の段階ではすべてが同じ重みのシグナルを持っているわけではありません。

Search Consoleは、早く見すぎると誤った情報を伝えてくるツールです。Googleは新しいページを即座にインデックスしたりランク付けしたりするわけではありません。新規ドメインの場合、インプレッションが表示され始めるまでに2〜4週間かかることもあり、Googleがサイトの立ち位置を判断している最初の1か月間は順位データも不安定です。そのため、開設1週目のSearch Consoleの数値をもとにエージェントが変更を提案することをブロックしています。インプレッション3件、クリック0件のページからは統計的に何も読み取れません。それをもとにタイトルを書き換えるのは、手間をかけただけの当て推量にすぎません。Analyticsはこれよりずっと早く信頼できるようになります。クロールの遅延がなく、誰かが訪問した瞬間にセッションが実在するデータとして記録されるからです。

アプリストアは完全に見落とされがちな項目ですが、それはデータが重要でないからではありません。別のポータル、別のログイン、別の用語体系(彼らの「インプレッション」は「ページに表示された」というより「検索結果に表示された」に近い意味です)があり、誰もわざわざそこに意識を切り替えたくないというだけです。これを同じ日次同期に取り込むことで、リスティングのコンバージョン急落が、その原因である可能性が高いウェブトラフィックの低下と並んで表示されるようになります。誰も開こうとしないアプリの中に未読のまま埋もれることがなくなるのです。

キャッシュされたフィルターを信用してはいけないと教えてくれたプロパティの取り違え

あるユーザーは、1つのGoogle Analyticsプロパティに2つのサイトを紐づけていました。プラットフォームに参加するずっと前に、管理するプロパティを1つ減らすためにそう設定していたのです。約1日の間、私たちのダッシュボードは両ドメインの合算トラフィックを、まるで1つのサイトのものであるかのように表示していました。セッション数は好調に見えました。直帰率も、実は不自然なほど良く見えていました。良すぎるほどで、今振り返ればそれこそが違和感に気づくべきサインだったのです。それは実際にはどちらのサイトの数値でもなく、まったく異なる2つのサイトの平均値にすぎなかったのですから。

解決策はこうです。すべてのAnalyticsクエリには、接続時にキャッシュされた設定値ではなく、実際のリクエストに対してホスト名フィルターが適用されます。プロパティは再割り当てされ、サブドメインは追加され続けるため、古いフィルターは静かに失敗する分、フィルターなしよりも厄介です。共有プロパティのケース——1つのGA4プロパティに20のドメインが紐づく状況——を特にテストします。フィルター済みの合計を単一プロパティの対照値と照合するのは、このバグがエラーを出さないからです。ただ静かに、自分のものではない良い数字を報告し続けるだけなのです。

数字を意思決定に変えることこそが本当のプロダクトだ

ダッシュボードはそれ単体では、何かをする義務を負うことなく「把握できている気分」を得るための手段でしかありません。価値が生まれるのは、数字を見た瞬間とそれに基づいて行動する瞬間の間にあるギャップであり、たいていのサイドプロジェクトの最適化作業はこのギャップの中で立ち消えになります。

Optimizeチームの仕事は、このギャップを埋めることです。私たち自身のドメインの1つで、「セルフホスト型アナリティクス構築」に関するクエリ群で週1,800インプレッションを獲得しているページがありましたが、クリック率はわずか1.4%——検索順位6〜8位あたりの情報系クエリとして期待される3〜5%を大きく下回る数値でした。エージェントは単に問題を指摘するだけではありませんでした。人々が実際に検索する際の悩みどころを、検索結果画面で省略されない最初の60文字に盛り込んだタイトルの書き換えを提案し、具体的なクエリとインプレッション数を根拠として提示しました。実際に適用すると、その後2週間でクリック率は3.8%まで上昇しました。実在のページに対する本物の改善です。グラフの色が赤から緑に変わっただけの話ではありません。

そのうちどれだけを自分が何も手を動かさずに実現できるかは、性格の問題ではなくダイヤルの問題です。

• レポートのみ。 検出結果は根拠付きの読みやすいレポートとして届きます。実行するかどうかはあなた次第です。特に大切にしているドメインや、まだロジックを確認しておきたい立ち上げ初期のドメインに向いています。
• 提案。 エージェントが実際の変更案——本物のタイトルタグ、本物の段落——を作成し、承認を待ちます。ほとんどの人は、提案の信頼性が高まった1か月後にこのモードに落ち着きますが、それでも最終判断は自分で下したいという方が多いです。
• 自律実行。 承認済みの変更タイプは自動的に適用され、1〜2週間後に数値をもとに再検証されます。指標が悪い方向に動いた場合は、あなたが気づくのを待って悪化したページを公開したままにするのではなく、自動的にロールバックされます。

私たち自身のサイトでは、メタタグやタイトルの変更には自律実行モードを、ページ構造や新規コンテンツに関わるものには提案モードを使っています。タイトルが間違っていても2秒で直せますが、コンテンツの書き換えを誤ると、何か月もかけて獲得した検索順位を一気に落としかねません。そういうミスは公開前に人間が気づく方がいいと私は考えています。あなたのリスク判断は別の場所に落ち着くかもしれませんし、それで構いません。収入の全てを支えるドメインは、自動化をどれだけ理屈の上で信頼していようと、趣味のプロジェクトよりも慎重さが求められて当然です。

実際に自律実行モードを無謀ではなく妥当な選択にしているのは、このロールバック機能です。変更が公開されると、プラットフォームは指標に応じたサイズの測定期間——低トラフィックなページのクリック率であれば、固定日数ではなく数百インプレッション分のデータが蓄積されるのを待つ場合もあります——を経てから、前後を比較します。数値が悪化していれば、変更を差し戻して理由を記録します。これは実験組み込み型の変更であり、正直なところ、慎重な人が本来行うべき最適化のあり方に近いものです。ただ、たいていの人はそれだけの忍耐力を持って確認し続けられないだけなのです。

批判派が正しい部分

ここで一つ譲歩しておきます。自律実行モードに懐疑的な人たちは、「可視性そのものに価値がある」という点で間違っていません。自分のサイトで何が変わったのかを見失うことは、実際にコストのかかることであり、私自身もそれを実感したことがあります。提案モードが存在するのは、まさにその流れを見失わないためです。犠牲になるのは、変更を適用するタイミングではなく、レポートを読むタイミングを自分で決める、というだけのことです。そしてダッシュボードは、価値が生まれる場所ではないとしても、深夜3時に静かに実行されたロールバックに気づき、その理由を確認しに行く場所であることに変わりはありません。私なら、その下にある同期パイプラインより先にダッシュボードを削るでしょう。しかし、ゼロにはしません。あなたもそうすべきではないでしょう。

セットアップをあえて簡素にしているのは、この部分の摩擦こそが、公開後のデータパイプラインの多くが結局構築されずに終わる原因だからです。マイドメインでSearch ConsoleとAnalyticsを連携させれば——1つのGoogleサービスアカウントで両方カバーでき、OAuthフローも1回で済みます——日次同期が始まり、エージェントが実際に参照するダッシュボードにデータが流れ込みます。プラットフォームのビルドパイプラインを通じて公開されたものについては、ストアの分析データが自動的に紐付けられます。