私たちのブログでは、ゲームの統計に関する多くの記事を既に公開しています。それらの記事では、主に主要な指標と指標 、およびアナリストが市場に出ているツールについて説明しました。
また、本日の記事では、モバイルゲームの統計情報を収集および処理するための技術ツールを直接構築した経験を共有したいと考えています。
市場には、 FlurryやKontagentなどの既製のツールがあります。 彼らのために、メインプラットフォーム用の既製のSDKと、レポート/グラフ/ファンネルなどの形式でデータを操作するためのいくつかのツールがあります。 ただし、これらのツールにはいくつかの欠点もあります。
たとえば、Flurryでは情報の処理に大幅な遅延が発生し、さらに悪いことに、重大なデータ損失の存在が実験的に確立されました（推定によると、Flurryはデータの30〜60％で「失われます」）。 しかし、Kontagentの重大な欠点は、Kontagentを使用するためのライセンスのコストです。すべての人に適しているわけではないからです。 また、ほとんどすべての既製のソリューションは、レポートを操作するときに必要な柔軟性と透明性を提供しません。
Flurry + splunk
一連の実験、試行、エラーの後、さまざまな種類の情報を処理するためのかなり強力なツールであるSplunkに基づいて独自の統計処理システムを構築することにしました。 Splunk自体は、あらゆる種類のグラフ、レポート、ダッシュボードなどを構築する絶好の機会を提供します。 など 私たちに合った以上のもの。
統計を処理するツールを選択した後、実際にゲームからデータを受信する方法に関して論理的な疑問が生じました。 興味のある指標であるゲームは既に公開されており、Flurryモジュールは既に統合されていました（その時点ではFlurryからのデータ損失についてはまだ知りませんでした）ので、 Raw Data APIを使用してFlurryからデータを汲み上げることにしました。
これはRaw Data APIであり、実際、非常に物議を醸すツールであり、別の投稿に値することが判明しました。 しかし、「痛みにもかかわらず」、それにもかかわらず、Flurryから統計を受信し、Splunkにアップロードするように設定しました。 その後、システムは戦闘操作に投入されました。データのインデックスが作成され、アナリストがレポートを作成し、誰もが満足し、観客は拍手、花、音楽、シャンパンを受け取ります。
幸福は長続きしませんでした。 文字通り数個の数値の調整までは、少なくとも他の何かと比較できますが、利用可能な統計に加えて、確かに信頼性があります-Splunkでのゲーム内支払いに関連するデータであり、モバイル側が示しています。 データが一致しなかったことを疑う人は誰もいませんでした（データの受信には常に遅延要因、作成されたレポートのエラー、詐欺師からの統計の潜在的な「バックグラウンド」などがあります）。まさにそのようなものです：統計のデータは、ストアのデータのほぼ半分（金額と支払い回数の両方）で表示されました。 詳細な分析により、レポートとサンプルにエラーはなく、Splunkのデータは正しく解釈され、ゲームアプリケーションは統計をFlurry SDKに正しく送信し、必要に応じて、Flurryからの生データは実際よりも「やや」少なくなります。 前述のとおり、データ損失の推定値は30〜60％です。
Kontagent
しばらくして、Flurry + Splunkバンドルのライブ作業をKontagentシステムと比較する機会もありました。 Kontagentははるかに幅広い機能を提供し、ほぼリアルタイムで動作し、多くのマーケティングツールと統合されており、一般的にそのようなすべてのnyashkaと言われています。
実際、すべてがほぼ真実ですが、繰り返しますが、モバイルプラットフォームのライセンスのコストは小さなチームを満足させることはほとんどありません。コストは視聴者の量に直接依存し、会話は年間数万ドルから始まります。 比較分析により、Flurry側でのデータ損失の仮説が確認されました。 どうやら、データの完全性を含めて、Kontagentは価格タグも要求しています。
だから私たちは次のジレンマに直面しています-Kontagentに移動するか、Flurryにとどまるのですか？ Kontagentへの完全な移行は、主にゲームでの変更の必要性に関連するいくつかのポイントによって複雑になりましたが、これは本当に避けたいと思っていました。 同時に、Flurryにとどまるということは、重要な決定が下されたことに基づいて、意図的に不完全な状況を把握することを意味しました。
最終決定
その結果、「ソロモンの決定」が行われました-FlurryをSplunkのゲームからの独自のデータトランスポートに置き換え、データ形式を最大限に保存し、ゲームコードを最小限に変更しました。
システムが必要でした：
- 最高の信頼性
- 最大の軽さ/高負荷に対する耐性
- クライアントからデータを受信してからSplunkインデックスに取り込むまでの最小遅延時間
これらの要件を確実にするために、次のシステム運用スキームが提案されました。
- GET要求行ですべてのパラメーターをサーバーに渡します
- この場合、Webサーバーのaccess.logは、サーバー負荷データウェアハウスの観点から最も単純で、最も信頼性が高く、安価になります。nginxを使用します
- 最小限の機密性を確保するために、リクエストのmd5署名が使用されます。これは、nginxのHTTPSecureLinkモジュールを使用して実装されます
- スケーラビリティを提供するために、フロントエンドにバランサーが配置されます。バランサーは、「リボルバー」を使用してノードロガーのクラスターにリクエストを「分散」できます
- 遅延を最小限に抑えるために、access.logは1時間に1回ローテーションされ、最も「新鮮な」ローテーションされたログがSplunkに送信され、インデックスのデータの1時間ごとの遅れが提供されます。
- Splunkホストインスタンスにデータを転送するには、各ロガーノードにSplunk Universal Forwarderがインストールされます-Splunkからの「ネイティブ」トランスポートで、データ転送のみに従事しています。 ノードに最小限の追加負荷を与える
- ノードロガーのクラスターに分散された1人のユーザーからのデータの一貫性を確保するために、各要求には、ユーザーデバイスの時間から取得された一意のユーザー識別子とタイムスタンプが含まれます
その結果、Splunkで統計データを収集および転送するための、安定した軽量でスケーラブルなシステムが得られました。 並行して、クライアントSDKはiOSおよびAndroid用に実装されました。統合を容易にするために、Flurry SDKが提供するAPIを複製しました。 つまり 新しいSDKへの移行には、テストを含めて30時間のプログラマー時間がかかりました。
比較分析により、この方法で取得されたデータの量はKontagentによって収集された量と同じであり、ゲーム内での支払いについて別に説明すると、モバイルストアの情報も関連していることがわかりました。 Flurryからの開発、保守、および移行のコストは、Kontagentへの移行に比べて数桁ではないとしても、数倍になりました。