1.シーンの説明
Cエンドユーザー向けの製品の作成は、ユーザーデータの収集に大きく依存しています。以下のようなデータ分析チャートを確認しました。リンク上のさまざまなリンクのデータ収集を通じて、公開された製品のトランザクション量を分析および比較します。
製品-クリック-トランザクションページ-支払いと購入などを参照して、製品のトランザクションシナリオを分析します。これは、大企業の側面からデータを観察するためのリンクです。実際、分析する際には多くの詳細を考慮する必要があります。
2.データソース
ユーザーデータは、ユーザーや製品のあらゆる側面の緯度を測定するのに最も説得力があります。したがって、インターネット製品のその後の開発と最適化では、データの収集と管理は常に非常に重要な操作でした。
今日、製品の一般的なクライアントは、PC、H5、APP、小さなプログラムなどのさまざまなシナリオへの入り口を持っています。いくつかのIoTデバイスや特別なデータ収集メカニズムもあります。さまざまなシナリオのデータ型は区別されます。さまざまなポートの下にあるさまざまなデータ埋め込みポイントを通じて製品の長所と短所を分析し、各シナリオのさまざまなイベントのデータを取得して、構成的分析結果を取得します。
たとえば、モジュール1の場合：ポートの分析を通じて、APP側の製品Aの推奨とトランザクション率が最も高いが、ミニ端末での推奨効果が良くない場合は、使用を検討できます。 APPとミニ端末のさまざまな推奨メカニズム。
3、イベントタイプの分割
データを収集する必要があり、さまざまなポートからデータを区別することは基本的な意識レベルにすぎません。データを収集するイベントの種類を考えることが最も基本的な操作です。ここでは、製品の特性を考慮し、別の方法で一般化する必要があります。以下に、いくつかの基本的な収集データといくつかの一般的なケースを示します。コアビジネスデータは比較的詳細で完全であり、基本的にライブラリを直接分析するための条件があります。
基本情報
| 属性 | フィールド | の種類 | 説明 |
|---|---|---|---|
| オペレーションターミナル | app_client | ストリング | Android / IOS /小さなプログラム/ H5など |
| ターミナルバージョン | app_version | ストリング | バージョン番号の識別 |
| ユーザーID | ユーザーID | 整数 | ユーザーID |
| ウェブサイトアドレス | IPアドレス | ストリング | ユーザーIP情報 |
この情報は、収集したポイントデータに保存されます。この基本的な情報収集により、異なるポートのユーザーの特性を分析し、差別化された管理と運用を行うことができます。
ログイン情報
| 属性 | フィールド | の種類 | 説明 |
|---|---|---|---|
| ログイン時間 | login_time | 日付 | ユーザーのログイン時間 |
| オンライン時間 | online_time | 長いです | システムをオンラインで使用する時間 |
ログイン時間とオンライン時間、およびいくつかの使用情報を通じて、このタイプのユーザーアクティビティにキー操作またはマーケティングアクティベーションが必要かどうかを判断します。
事業基盤
| 属性 | フィールド | の種類 | 説明 |
|---|---|---|---|
| サービスの種類 | service_id | 整数 | さまざまなビジネスサービス |
| モジュール分割 | model_type | 整数 | たとえば、注文/支払い/ロジスティクスなど。 |
これをビジネスデータ収集の基本情報として使用し、ビジネスデータ全体を分割して分析します。詳細なデータは、特定のシナリオに従って設計する必要があります。
商品ケース
| 属性 | フィールド | の種類 | 説明 |
|---|---|---|---|
| 製品情報 | 製品番号 | 整数 | 製品情報 |
| 表示位置 | position_id | 整数 | 例：リスト/推奨スポット/広告スポット |
| 店舗情報 | shop_id | 整数 | 店舗情報 |
| 検索情報 | キーワード | ストリング | キーワードを検索する |
| 現在の単価 | 単価 | ダブル | 現在の単価 |
| 現在の売上高 | sales_num | 長いです | 商品の現在の販売 |
これは、ユーザーのブラウジング行動に基づく簡単なデータ収集情報です。このメカニズムは、実際のeコマースアプリでは非常に一般的です。クリックまたは検索を生成する製品が推奨されます。そのようなアクションがない場合は、毎日のブラウジング情報に基づいて行われます。 。推奨メカニズムを作成します。実際の開発では、収集したデータはここよりもはるかに複雑であり、実際のビジネスニーズに応じて検討する必要があります。
マーケティングケース
| 属性 | フィールド | の種類 | 説明 |
|---|---|---|---|
| 活動場所 | location_id | 整数 | エントリー/ガイドページ/レコメンデーション/シェアリンクなど |
| マーケティング製品 | 製品番号 | 長いです | マーケティング活動の主な製品タイプ |
| 製品詳細フロー | detail_num | 長いです | アクティビティ製品のページビュー統計 |
| 注文確認ページ | detail_num | 長いです | アクティビティ製品のページビュー統計 |
| アクティビティトランザクション統計 | trade_num | 長いです | イベントの最終的なコンバージョン統計 |
製品のマーケティングは、運用活動を通じて実施されます。イベント後、データが再記述され、活動の軌跡データの分析に基づいて、マーケティングによって生成された価値とコストのバランスが取られ、活動戦略が継続的に調整されます。操作のアイデアを最適化する。
四、実現方法
1.ビジネスレベル
ビジネスの観点からは、ユーザーが気付かない収集操作に加えて、アンケート調査に基づくこともできます。たとえば、多くのAPPは、一定期間の使用後、またはコメントの入力後に、ユーザーレビュー用に同様のスコアリングシステムをポップアップします。より直接的なコメントユーザーフィードバック情報を収集します。
2.技術レベル
最も一般的なのはSDK埋め込みテクノロジーです。これは、特定のユーザーの行動やイベント、およびその実装プロセスをキャプチャして処理し、サーバーに送信します。この方法は、一部の非中核事業を処理するために非常に一般的です。それがコアビジネスである場合、データ漏洩を回避するためにカスタマイズされた方法でデータを収集する必要があるかもしれません。
3.データの蓄積
ビジネスが発展し続けると、分析が必要なシナリオはますます複雑になり、収集されたデータの量が一定の規模に達すると、データの管理と分析の難しさが増し、特殊なプロセスとインテリジェントなツールが使用されます。 BIなどが必要になります。ツール、視覚化コンポーネント、大規模なデータ画面、マルチシーン共同分析など。
5、ソースコードアドレス
GitHub·地址
https://github.com/cicadasmile
GitEE·地址
https://gitee.com/cicadasmile
推奨読書：プログラミングシステムの仕上げ
| シリアルナンバー | プロジェクト名 | GitHubアドレス | GitEEアドレス | 推奨 |
|---|---|---|---|---|
| 01 | Javaは、デザインパターン、アルゴリズム、およびデータ構造を記述します | GitHub・ここをクリック | GitEE・ここをクリック | ☆☆☆☆☆ |
| 02 | Javaの基礎、並行性、オブジェクト指向、Web開発 | GitHub・ここをクリック | GitEE・ここをクリック | ☆☆☆☆ |
| 03 | SpringCloudマイクロサービスの基本コンポーネントケースの詳細な説明 | GitHub・ここをクリック | GitEE・ここをクリック | ☆☆☆ |
| 04 | SpringCloudマイクロサービスアーキテクチャの実際の戦闘の包括的なケース | GitHub・ここをクリック | GitEE・ここをクリック | ☆☆☆☆☆ |
| 05 | SpringBootフレームワークの基本的なアプリケーションから高度なものまで | GitHub・ここをクリック | GitEE・ここをクリック | ☆☆☆☆ |
| 06 | SpringBootフレームワークは、一般的なミドルウェアを統合および開発します | GitHub・ここをクリック | GitEE・ここをクリック | ☆☆☆☆☆ |
| 07 | データ管理、配布、アーキテクチャ設計の基本的なケース | GitHub・ここをクリック | GitEE・ここをクリック | ☆☆☆☆☆ |
| 08 | ビッグデータシリーズ、ストレージ、コンポーネント、コンピューティング、その他のフレームワーク | GitHub・ここをクリック | GitEE・ここをクリック | ☆☆☆☆☆ |