大規模なモバイルアプリケーションでのセグメンテーションの構成と使用

一度モバイルアプリケーションが十分に大きくなり、毎日1万-10万-100万人がモバイルアプリケーションを使用しますが、それは重要ではありません。一般に、生きている人や異なる人がたくさんいます。 開発者としてのあなたにとってこれはどういう意味ですか？



はい。「送信」ボタンを押すと、さらに悪化します。ウェブアプリケーションとは異なり、何かを見過ごした場合、レッドブルキャンやピザで一晩過ごして修正することはできません。モバイルプラットフォームでのレビューには時間がかかり、 iOSについて話す場合-まる1週間。 1週間は、以前は忠実だったユーザーがアプリケーションを開くのを止めるのに十分な時間です。



そして、同じくらい重要なことは、「この画面の外観が好き」というだけでは、この画面が実際にアプリケーションに存在するのに十分な言い訳にならないときが来たことを意味します。







この記事では、私たちが何をしているかについてお話しますので、巨大な実動アプリケーションはそのままです。



注：この記事の資料は、操作にインターネット接続を必要としないアプリケーションにはあまり適していません。 しかし、私たちのモバイル時代では、それらはますます少なくなっています。

パート1. uber allesのセグメンテーション

最初の話：私たちは、1つの大きくて非常に美しいサードパーティとの作業をアプリケーションに統合しました。 彼らは自分たちのチーム、バックエンド、さらには日当たりの良い国にオフィスを持っています。そこで電話して予約をすることができます。 しかし、ある時点で、このサービス全体は、偶然をおかしくして後方互換性に違反する堅実なリファクタリングの後に3日間停止します。 はい、「自分で書いてください」、「もう混乱させないでください」、「できるだけ早く修正するように頼んでください」-もちろん、これらは考えるべき興味深い考えですが、ユーザーがクリックするように何かをさらにすばやく行う必要があります-通常のボタンのいずれかで、「ごめんなさい、昼食を食べます」という定数が表示されないか、さらに悪いことに、真実にあまり関係のない情報が表示されます。



2番目のストーリー：大規模で重要な機能を展開し、もちろん適切にテストしましたが、同時に何かが間違っていることが判明しました！ 誰とどのようにscるのか-後で決定します。



3番目のストーリー：アプリケーションのユーザーについてさらに知るために、多くの有用な情報を専用のログサーバーに送信します。 しかし、誰かが突然数百万個あることを知っていました-そして、ログサーバーは10〜15分ごとに喜んでクラッシュし、2〜3週間で新しいサーバーが到着します。



これらは恐ろしい話であり、それほど怖くない話は他にもたくさんあります。

そして、それらすべてに便利で便利なツールがあります-セグメンテーション。

要するに、アプリケーションのフローは簡単な手順で説明できます。

• 一般的な構成のサーバーから受信する
• サーバーログイン
• セグメンテーションデータの取得
• アプリケーションで作業する

それでは、最初と3番目のステップと、特定の瞬間にどのような問題を解決したかについて詳しく説明しましょう。



一般的な構成とは何ですか？ これは、すべてのユーザーに同じアプリケーション設定のセットです。

含まれるもの：

本番サーバーのアドレス

アプリケーションのエントリポイント。 そして今、別のドメインに移動したり、たとえば、ユーザーをバックアップサーバーに移動したりする必要が生じた場合は、configを使用して行うことができます。 繰り返しますが、モバイル（およびデスクトップ）システム用のWebアプリケーションとは異なり、非常に多くのバージョンが同時に存在する可能性があります。これは、実稼働サーバーの強制変更を実行できることを意味します。あなた）既に働いている顧客を壊すことなく。



したがって、アプリケーションは、構成ファイルに静的URLを1つだけ保存し、何らかの方法で追跡できます。

アプリケーションの最小バージョン（オプション/強制）

一般的に、人々は更新されることを本当に好みません。 また、モバイルプラットフォームで自動更新が行われたとしても、状況は改善されましたが、全体としては改善しませんでした。 たとえば、2週間のリリースサイクルの場合、原則として10〜15のバージョンが同時に使用されます。 しかし、時々、いわゆる重大な変更が発生します-クライアントの古いバージョンで作業することを不可能/不快にする根本的な変更。 この場合、このパラメーターは、ソフトシナリオでは「更新するのが良い」、「更新せずに作業を続けることは不可能」であるということをユーザーに通知します。

ログ設定

これを行うには、別の構成ファイルを使用します。これにより、次のことが可能になります。

• 特定のログメッセージで送信されるフィールドを追加/除外します。
• サーバーへのこれらのログメッセージを具体的に処理する必要があるユーザーの割合を決定します（さらに、どのサーバー-一部のメッセージはGoogleAnalyticsなどのサードパーティの分析サービスに記録され、一部は内部サービスに記録されます）。
• システムログのログレベルを設定します。

1つ目は、かなりコンパクトなログメッセージを作成するのに役立ちます-必要に応じて、不足している情報を追加します。



2番目は、ログサーバーの負荷を分散するのに役立ちます。 すでに多くのユーザーがいるので、たとえそれらの1パーセントがこれらのメッセージをサーバーに送信しても-すでにかなり代表的な画像を取得できます。



3番目の利点はわずかに異なります-クラッシュ分析システムではクラッシュが発生することがあり、その状況はstackTraceからの回復が困難な場合があります。その後、システムログの最後の数行をクラッシュレポートに追加するだけでログレベルを制限まで下げます。ユーザーアクションを復元し、問題を特定できます（興味がある場合は、cocoalumberjackロガーとHockeyApp分析を使用してこれを実現します）。

サードパーティライブラリのキーおよびその他の設定

はい、私はこれがfufufuであることを理解していますが、それにもかかわらず、これらのライブラリのあいまいな状況の場合-サードパーティのアカウントを数回再作成する必要がありました-これは再び、古い顧客の仕事を壊しませんでした。 さらに、これらのキーは非常に「ソルト化」され、十分に安全に作成できます。 （ただし、害虫がターゲットを設定する場合-バイナリアプリケーションから静的に定義されたキーを抽出することもできることを覚えています-したがって、これらの保存方法はそれほど悪くありません-特に単一のキーよりも暗号化アルゴリズムを引き出すのが難しいためです）。

さらに、サードパーティで特に不快な重大な変更が発生した場合、古いクライアントの古い形式を維持しながら、サーバーを介してそれらとの作業をプロキシする余裕があります。

グローバルA / Bオプション

システムにまだ登録されていないユーザーについて、いくつかの決定を行う必要があります（たとえば、登録ウィンドウの外観、登録を行うパスなど、その他）。 この場合、そのようなパラメーターとして、一部の機能を有効/無効にする必要があるユーザーの割合を格納することがあります。 テストグループが含まれているかどうかを判断するには、いくつかの一意のデバイス識別子が適切であり（原則として、各オペレーティングシステムで1つ見つけることができます）、そこから2桁のハッシュを取得しました。



さらに、次の概念は私たちにとって非常に有用な買収であることが判明しました。

デバイスとユーザーは、「実」と「テスト」に分かれています。 2番目の方法を決定するために、さまざまな方法を試しました（たとえば、UDID、その使用が禁止されているとき、広告の識別子によって、しかし、私たちはそれに制限を課しました、そして実際、そのような識別子の使用は、いつか実際のユーザーが見るべきでないものを見る競合を排除しません）、しかし、最終的に彼らは簡単なスキームに決めました：デバイスで起動された小さなユーティリティは、デバイス上の暗号化されたストレージにいくつかのキーを書き込みます-これはすべてのモバイルシステム、たとえばiOSで、これはキーチェーンです。 メインアプリケーションは、起動時にこのキーの存在を確認し、利用可能な場合はユーザーがテストであると見なします。



重要：この種の分離を導入する場合は、次の2つのことを確認してください。

• 実際のユーザーは、「偶然」テストになるべきではありません。 見た情報は彼を混乱させる可能性があります。
• テストユーザーのもとで作業することは、アプリケーションを操作する際の設定や危険なアクションの可能性を与えません（特にゲーム開発に関して-保護を回避するという目標を設定した攻撃者は遅かれ早かれこれを行い、さらにこれを共有できるため方法）

そして今、親しいユーザーがいたとき-なぜそれらを使用したのですか？

• テスターのアクションを容易にするデバッグパネル（サーバーからの応答の置き換え、ログレベルの変更、UIのフレームレートとラグの表示）
• 「ステージ」-またはテストサーバー-テストユーザーの場合、アプリケーションをロードする開始構成を、実稼働から、またはテストサーバーの1つから選択できます。これにより、サーバーとセグメンテーションの両方のさまざまな設定でアプリケーションをテストできます。

それでは、メインのセグメンテーション構成に移りましょう。

より実用的なタスクに焦点を当てています-クラシックA / Bとしてコミュニティで一般的に受け入れられているもの

この構成は、id_fichi：{dictionary of parameters}の形式で、何らかの辞書（JSONなど）の形式で構造化されています。

ここで、パーセンテージやその他の分岐点はもう必要ありません-思い出すように、この時点ですでにシステムに登録されています-したがって、明らかに一意のuser_idに基づいて、利用可能な値に基づいてユーザー固有のパラメーターを返しますセグメンテーションモジュールサーバー。 その中で私たちは頼ることができます：

• ユーザーがアプリケーションを使用している期間（新人、ロイヤルティなど）。
• これはユーザーに支払いますか。
• ユーザーが使用するデバイス、オペレーティングシステムのバージョン、および直接アプリケーション。
• ユーザーはどの国のどのタイムゾーンで、どのローカリゼーションを使用しますか。

そして、他の多くのデータ。

それは何のために使われますか？

セグメンテーションの有効化/無効化

記事の冒頭で説明したように、優れた機能を見つけるのは非常に怖いので、この方法では、まず、期待どおりに動作しない機能を無効にすることができます。 そして第二に、この機能をユーザーに段階的に開放するために（5％開放-その後、10、20、50、そして最後に全員に開放）。

パラメータのセグメンテーション

A / V向けに設計された各機能では、ポップアップウィンドウのテキスト、アニメーション時間、ショー間の時間、ボタンの色、可能な動作のオプションの1つなど、多くの変数を配置できます。 これらのパラメータが多ければ多いほど、最適なソリューションを探してより多くの実験を実行できます。 あなたはあなたの想像力によってのみ制限されます。 一方、この機能に必要なテストの量が多くなるほど。 （確かに、このボリュームは時間の経過とともに十分に広がる可能性があります-アプリケーションの主な作業能力をテストすることにより、将来的にはロールアウトするパラメーターのセットのテストサーバーで簡単なテストを簡単に実行できます）



したがって、この部分を要約すると、次の点に注意したいと思います。

• A / Bテストをアーキテクチャに組み込む必要があります-設計されている各機能は、非常にモノリシックなものを除き、完全に無効になる可能性を想定する必要があります。 余分な分岐は、リファクタリング中に機能が本番環境ですでに証明されている場合に削除するのが最適です。 さらに、機能には事前に「埋め込みポイント」が必要です。これには、サーバーから取得した有効な値を使用できます。
• 前の段落に加えて、各機能にはデフォルトの設定が必要です。まず、転送される設定のサイズが最小になるように（再定義されたパラメータのみ）、次に、他のすべてと同様にセグメンテーションが簡単にできるためちょうど落ちる。
• この種のロジックを維持するのは非常に高価です-コードが複雑になります。 時々、かなり。
• アプリケーションの受け入れテストの量は増加しています-設計エラーまたは単純に関連する機能により、1つのグループのパラメーターではなく、いくつかのパラメーターの相互接続の値を確認する必要があります。
• これらすべてにより、アプリケーションは、追加機能の開発者やイデオロギー家の間違いに対してアプリケーションの抵抗力を大幅に高めることができます。

パート2.こんにちは、元気ですか？

私がでたらめではないかどうか自問してください。

最初の部分では、私たちがやっていることを書きましたが、同じことを説明しようとしますが、実際、どうやって私たちがやっていることを理解するのでしょうか。

クラッシュ分析。

何かが間違っていることを理解する最も簡単な方法は、新しい機能の導入後、アプリケーションが動作を停止したことを発見することです。

HockeyAppを使用します-既存のクラッシュを処理するのに非常に便利なツールがあり、さらに、さまざまな展開システムに統合されているため、情報を自動的に保持できます。 しかし、実際には、現時点では非常に多くのそのようなツールがあります-すべての味と色に対して、自分で選択してください。 少し上に書いたように、デバイスのログからクラッシュログにピースを添付する機能を導入した瞬間から、それを使った作業がさらに快適になりました。

セッションと支払いの監視。

おそらく、ビジネスにとって関心のある主要なツールです。 彼にとっては、非常に多くの異なるツールがありますが、私たちは自己記述と既存のツールを組み合わせて使用​​します。 すべての企業が支払いに関する情報をサードパーティのサービスと共有するわけではないからです。 そして当然です。 既存のシステムでは、アプリケーションの品質の最短および最長の傾向の背後にある非常に快適に検出できます。 重要な監視機能を展開する場合、次のメトリックに値します。

• セッション数-劇的に変化した場合-は何かがおかしいことを意味します。
• 収益-または支払い回数-短期的に-実装された機能がユーザーに与える影響を理解し、そこに移動するかどうかを戦略的に理解できるようにします。
• セッションの長さも非常に重要な指標です。 彼女にとっては、ビジネスアプリケーションではもっと多くのことがあれば常に優れていると言うことはできません（これはゲームプロジェクトの場合に当てはまります）。彼女は予測からそれほど遠くないはずです（セッションが長すぎる場合は、ユーザーは多くの時間を費やしていますか？）
• 1日あたりのセッション数-さて、ここで、一般に、すべてが明確です。

最新のサービスを使用すると、この分析を（デバイス、アプリケーションバージョン、地理位置情報、および一連の機能ごとに）セグメント化することができ、予測をより正確に行うことができます。

レビューの監視。

残念ながら、このプロセスは形式化が非常に不十分であり、自動化を受け入れられませんが、その重要性と説明の必要性は（大規模なだけでなく）アプリケーションには必要ありません。 多数のレビューでは見落とされる可能性があるため、何らかのフィードバック提案を会社に直接書く機会を与えるのは良い口調になります。

機能とストーリーの寿命を監視します。

このため、残念ながら、十分に便利で機能的なシンプルなパブリックツールを見つけることができませんでした。そのため、ほとんどのアプリケーションログと専用のログサーバーは専用ツールです。

次の理由により、このためにHadoop（および他のいくつかのサービス）を使用します。

• NoSQLである-ログサーバー上のデータベースの構造を変更することなく、ログメッセージにフィールドを簡単に追加/削除できるため、必要な柔軟性が得られます。
• 情報の最も正確なカットを取得するために、興味のある一連のパラメーターの本格的な統計サンプルを作成する機会があります。
• このようなエンティティを「履歴」として使用します。これは内部セッションでもあり、漏斗でもあります。比較的言えば、アプリケーションを使用するセッションの一意の識別子です。
  
  これに基づいて、関心のあるセッション内のユーザーアクションのシーケンス全体を示す選択を取得できます。 （たとえば、何らかの理由で支払いが行われなかったユーザーを選択し、その後、これらのユーザーのいずれかで漏斗を選択し、これが発生する理由の必要なコンテキストを取得します）
• 一部のタイムスクリプトで一時停止する「通知」を設定することができます。たとえば、1時間に1回、エラーのあるセッションの数の割合をセッションの総数と見なすサンプルを作成します。これに関するメッセージを送信し、問題のより詳細な分析に進みます。

これらの要件はすべて非常に重要であり、それらを満たすツールは複数あると思います。



そしておそらく、そのようなツールが利用可能になった後の最も重要なポイントは、機能の品質と関連性を評価するための正式な（かなり正確な）メトリックを構築する機能を提供することです。 ボタンが押されていない場合は、たとえ非常に美しい場合でも、削除する必要があります。 超便利な機能の導入後、ユーザーがアプリケーションについて不満を言い始め、使用量を減らし、支払いを減らした場合、この機能は非常に便利ではありません。 などなど。



上記のすべてを要約すると、次のいくつかの点に注意したいと思います。

• おそらく、この記事のほとんどの資料は明らかなように見えますが、それでも、最初の試みですべてに到達したわけではなく、この一連のアプローチは問題を解決し解決します。
• このインフラストラクチャはすべて、健康の開発と維持に非常に費用がかかるため、数百万人が興味を持つと思われる小さなアプリケーションの作成を開始する場合は、すべてを実装しないでください。 少なくとも統計的手法は、一部の聴衆の規模には絶対に適用できないためです。
• しかし、同時に、いくつかのレシピは保守が簡単であり、まともな神経を節約します。
• すべてをすべて記録する価値はありません。 それはすぐに消化できないおridgeに変わります。 仮説に基づいたロギングをお勧めします。 つまり、新しい機能の設計を開始するとき、オプションは間違ったペシミストとして書き留め、これに基づいて、これらの仮説を分析でカバーできる最小限のフィールドセットで最小限のログメッセージセットを作成します。 また、ログメッセージのレビューを行って、関連性がなくなったものを削除することもあります。
• ただし、同時に、セッションのエラーや画面を開く頻度から、アプリケーションのロード時間や特定のタスクに費やした時間まで、非常に多様なメトリックとイベントを記録できることを忘れないでください。
• セグメンテーションを整理するためのさまざまなツールを試してください-理想的には、セグメントの変更に関与するプログラマーではなく、マーケティングおよび製品チームになるようにこれを行う必要があります。 セグメントを整理する機会を増やします。
• インフラストラクチャの整理に時間を節約したい場合は、市場のモバイルアプリケーションでA / Bセグメンテーションを整理するための既製のソリューションがいくつかあります。たとえば、leanplum
• あなたは非常に幸運であり、人々に興味深いプロジェクトに取り組んでいます:-)ありがとうございました。