
PostHog から Zenovay への移行ガイド
乗り換える前にお読みください。PostHog がプロダクト分析の基盤になっているなら、そのまま使い続けてください。主にウェブサイト分析のために導入し、9 つの製品が一体となった構成が必要以上に重いと感じているなら、このガイドが役に立ちます。
移行手順
そもそも移行すべきかを判断する
深いプロダクト分析、大規模なフィーチャーフラグ主導のリリース運用、あるいは PostHog のデータウェアハウスに依存しているチームは、PostHog を使い続けるか、両方を併用するのが賢明です。移行して得をするのは、ウェブサイト分析のために PostHog を導入したものの、9 製品のバンドルが必要以上に重いと感じ、エンジニア以外でも扱えるツールを求めているチームです。
PostHog と並行して Zenovay を設置する
無料アカウントを作成し、サイトを追加して、スクリプトタグを 1 つ貼り付けます。計測はすぐに始まり、設置全体で約 2 分です。比較のあいだは PostHog もそのまま動かし、両方のツールが同じトラフィックを見る状態にしてください。
PostHog のページビュー履歴をインポートする
Zenovay は Pro プラン以上で PostHog のページビュー・トラフィックをインポートできます。対象サイトで「データ」から「インポート」を開き、PostHog のタイルを選んでください。必要なのは、PostHog の数値のプロジェクト ID、phx_ で始まる個人用 API キー(プロジェクト用の API キーでは 403 が返ります)、そしてリージョン(US Cloud、EU Cloud、またはセルフホストのホスト名)です。app.posthog.com は各リージョンのホストへリダイレクトされるため使えません。既定では昨日までの過去 365 日分を取り込み、期間を指定することもできます。カスタムイベント、フィーチャーフラグ、実験、アンケート、セッション録画はインポートされないため、解約前に PostHog のバッチエクスポートで書き出すか、参照用にプロジェクトを読める状態で残しておいてください。
実際に見ている指標だけを作り直す
多くのチームは計測している項目のごく一部しか見ていません。目標、ファネル、カスタムイベントを Zenovay で作り直し、収益アトリビューションのために Stripe を連携し、稼働監視を追加します。A/B テストとフィーチャーフラグは Pro プラン以上で利用でき、割り当てられたバリアントを読み取る JavaScript を 1 行だけ開発者に追加してもらいます。
2 週間ほど比較してから決める
両方を並行して運用してください。ボット判定、セッションの扱い、イベント定義が異なるため、数値は完全には一致しません。それは想定内です。そのうえで完全に移行するか、多くのチームが落ち着く分担、つまりプロダクト内の行動は PostHog、マーケティング・トラフィック・収益アトリビューションは Zenovay という形にするかを選びます。
移行前と移行後
PostHog の場合
- 9 つの製品が 1 つの画面にまとまっている
- 実験機能とフィーチャーフラグはより成熟し、より高機能
- MIT ライセンスのコアをセルフホストできる
- 外部データと結合できるデータウェアハウスを内蔵
- 無料プランで月 100 万イベント
- クラウドは既定で米国ホスティング(EU も選択可能)
Zenovay の場合
- ウェブトラフィックと収益に絞った 1 つのダッシュボード
- 頻度論に基づく A/B/n テストとフィーチャーフラグ(Pro 以上)
- マネージドサービスのみ、セルフホストは不可
- Scale プランで S3 互換の自社ストレージへエクスポート
- 無料プランで月 10,000 イベント
- チューリッヒとアムステルダムでホスティング、Cookie レスモードも利用可能
引き続き利用できる機能
- カスタムイベントの計測
- ファネル、目標、リテンション
- セッションリプレイとヒートマップ
- A/B テストとフィーチャーフラグ(Pro 以上)
- 識別済みユーザーとドメイン横断の識別
新たに得られる機能
- Stripe と連動した収益アトリビューション
- 稼働監視とエラートラッキング
- スイスとEUでのデータホスティング
- Cookie もローカルストレージも使わない Cookie レスモード
- イベント従量課金ではなく定額のプラン料金
- SQL を書かずにマーケターが使えるダッシュボード
よくある質問
本当に PostHog をやめるべきですか?
多くの場合、やめる必要はありません。深いプロダクト分析、大規模なフィーチャーフラグ主導のリリース運用、あるいはデータウェアハウスを PostHog に頼っているなら、そのまま使い続けてください。Zenovay はその代わりにはなりません。移行して得をするのは、主にウェブサイト分析のために PostHog を導入し、バンドルが必要以上に重いと感じているチームです。
PostHog と Zenovay を併用できますか?
はい、多くのチームがまさにそうしています。プロダクト内の行動は PostHog、マーケティング・トラフィック・収益アトリビューションは Zenovay という分担です。どちらか一方を選ばなければならないわけではありません。どちらもスクリプトタグ 1 つで動くため、併用は妥協ではなく普通の構成です。
PostHog の履歴は失われますか?
ページビューの履歴は引き継げます。Zenovay の PostHog インポーターは、PostHog の $pageview イベントをもとに、日別の訪問者数とページビュー数に加えて、上位ページ、参照元、国、デバイス、ブラウザ、OS を取り込みます。一方で、カスタムイベント、フィーチャーフラグ、実験、アンケート、セッション録画は引き継げません。移行できるのはデータの一部だけなので、解約する前に PostHog のバッチエクスポートで履歴を書き出すか、参照用に読み取り専用の状態で残しておいてください。
PostHog のインポートはどのように動き、なぜ「部分的」で終わることがあるのですか?
PostHog の HogQL クエリエンドポイント経由でデータを読み取っています。PostHog 自身のドキュメントはイベント API を非推奨とし、大量データの取り出しはバッチエクスポートへ誘導していますが、その出力先は利用企業自身の S3、BigQuery、Snowflake であり、Zenovay が読み取れる場所ではありません。そのためエクスポートではなくクエリで取得しています。このエンドポイントにはレート制限があり、古いプロジェクトでは 1 時間あたり 120 クエリ、新しいプロジェクトでは 2,400 クエリです。そのため、データ量の多いインポートは途中で止まり「部分的」として報告されることがあります。これは失敗ではなく想定内の動作です。残りの期間を指定して再実行してください。
移行にエンジニアは必要ですか?
設置には必要ありません。サイトの head にスクリプトタグを 1 つ入れるだけで、約 2 分です。開発者の手が必要になるのは 1 点だけで、A/B テストを行う場合に割り当てられたバリアントを JavaScript で読み取る部分です。なお Cookie レスモードではバリアントの割り当てはウィンドウ単位で、タブを閉じるとリセットされます。そのため、複数セッションにまたがる長期の実験よりも、ページ内で完結する短いテストに向いています。