新しいアカウントは心強い通知です。それは非常に小さな証拠でもあります。
分析製品の場合、アカウントを作成し、Web サイトを追加し、スクリプトをコピーしても、自分のサイトからのアクセスが表示されないことがあります。最初のステップを成功とみなすと、サインアップしてから役立つものを入手するまでのすべての作業が隠れてしまいます。
私たちの 7 月のアクティベーション監査は、そのギャップから始まりました。ワーキングノートによれば、名目上の無料アカウントの約半数がウェブサイトを作成していなかった。ただし、メモには一部の数値が推定であることも記されており、社内用、テスト用、外部ユーザーのアカウントが混在していました。調査を開始するにはこれで十分です。しかし、正確なコンバージョン率として公表できる根拠ではありません。
この検証では、何を確立できるかについて説明します。分離する必要がある段階、現在のコードが実行するインストール チェック、オンボーディングの変更を改善と呼ぶ前に必要な証拠です。
1 つのラベルを共有しない 3 つのステップ
アカウントの作成により、誰かが登録を完了したことがわかります。 Web サイトの作成により、製品内にオブジェクトを構成したことがわかります。最初に記録されたイベントは、データがその Web サイトの分析パイプラインに到達したことを示します。
これらは異なるマイルストーンです。それだけでは、その人が報告書を理解したこと、または来週戻ってくることを証明するものはありません。
この監査の場合、最初に役立つ技術的なチェックポイントは、対象の Web サイトに関して記録された実際のイベントです。これは製品のアクティベーションよりも範囲が狭いですが、「セットアップが完了しました」などの曖昧なラベルよりも検証がはるかに簡単です。
Web サイトを持っていない人は、セットアップの決定について支援が必要です。 Web サイトを持っていてイベントがない人は、インストール診断が必要です。イベントがあり、戻ってこない人は、別の問題を抱えている可能性があります。レポートは、戻ってくる価値のある質問に答えていません。 3 人全員に同じリマインダーを送信すると、診断を行う前に診断が行われたことが前提となります。
スコアだけでなく実装を読む
Zenovay の現在のアクティベーション スコアリング機能は、スクリプトのインストール フラグ、Web サイト作成から 24 時間以内の最初のイベント、チーム作成から 7 日以内の Stripe 接続、およびチーム作成から 1 日目以降および 14 日以内の再ログインの 4 つのマイルストーンを評価します。達成された各マイルストーンは 25 ポイントを獲得します。
関数は、達成されたマイルストーンを個別にカウントします。後のマイルストーンがカウントされる前に、誰かが厳密なシーケンスを完了する必要はありません。スコアを解釈するときはその詳細が重要です。2 つのアカウントが異なる動作を通じて同じ合計に到達する可能性があります。
追跡が機能するようになったとしても、24 時間後に到着する最初のイベントも時間制限されたマイルストーンに達しません。 「アクティベーションウィンドウを見逃した」場合と「インストールが壊れた」場合には、異なる対応が必要です。
以前、基礎となるアクティビティを反映していないインストール フラグ について書きました。スコアはその入力を要約するという、より広範な教訓が引き続き当てはまります。これらの入力が信頼できるかどうかを判断することはできません。
空のチャートにはいくつかの原因が考えられます
現在の追跡ルートは、Web サイトの許可されたドメインに対してリクエストの送信元をチェックします。明示的なリストが存在しない場合は、登録されたドメインにフォールバックします。ドメイン検証が有効になっている場合、不一致のオリジンは運用環境で拒否される可能性があります。
Web サイトの allow_localhost 設定によって制御される明示的なローカルホスト例外もあります。この例外はドメイン チェックに属します。すべてのローカル テストが保存されたイベントを生成するという保証はありません。他のチェックは引き続き適用されます。
「スクリプトを貼り付けました」が検証の終わりではなく、始まりであるのはこのためです。実際のページのホスト名、設定された Web サイト、ブラウザのネットワーク応答、およびイベントが記録されたかどうかを確認します。テストしているユーザー ジャーニーには、実際のブラウザー訪問を使用します。
セットアップ インジケーターを緑色にするためだけにセキュリティ チェックを弱めないでください。まず、拒否されたリクエストを見つけて、拒否された理由を理解します。有用な修復は、構成、インストール手順、またはエラー メッセージである可能性があります。
人と Web サイトを別々にカウントします
サインアップ数から Web サイトの数を引いても、オンボーディングを放棄した人の数はわかりません。 1 人で複数の Web サイトを作成できます。同僚は、チームを作成せずに既存のチームに参加できます。テスト アカウントは小さなサンプルを歪める可能性があります。
有用なコホート レポートは、定義された適格なアカウントまたはチームのセットから始まり、その同じセットを段階的に追跡します。パーセンテージを計算する前に、単位、除外、および観察ウィンドウを選択します。
たとえば、新しいチーム オーナーのレポートでは、各オーナーが少なくとも 1 つの Web サイトを作成したかどうか、およびそれらの Web サイトのいずれかが一定のウィンドウ内で条件を満たす最初のイベントを受信したかどうかを尋ねることができます。各所有者を一度数えます。基礎となる数と割合を報告します。招待されたユーザーと社内テストは分けてください。
これは提案された測定ルールであり、過去の 7 月の推定値が既にそれに従ったという主張ではありません。
何が改善とみなされるでしょうか?
2 つのオンボーディング バージョンを比較する前に、チェックポイントに到達するまでに両方のコホートに同じ時間を与えます。昨日のコホートを、セットアップを完了するために2週間の猶予があったコホートと公平に比較することはできません。
最終的な合計だけでなく、不足しているステップも追跡します。より多くの適格な所有者が Web サイトを作成しましたか?それらの Web サイトの多くでイベントが発生しましたか?データを入手した後、人々は戻ってきましたか?コホート間でどの変更が配布されたかを記録し、流入元を常に把握しておきます。
私たちは、この検証によって測定された改善が得られると主張しているわけではありません。ソースレビューにより、チェックがどのように機能するかを示し、考えられる障害を特定できます。すべての人が去った理由を証明することはできませんし、手順を一つ省くことでより多くの人が留まるようになったということを証明することもできません。
次回サインアップ通知が届いたとき、有益なフォローアップは簡単です。つまり、その人は自分の Web サイトからデータを取得しましたか、そしてそれは何かをするのに役立ちましたか?それに答えるまでは、アカウント数は話の始まりにすぎません。
