点評注文アプリの開発プロセスにおけるデータ収集の経験を共有する

ミニ プログラム開発の経験とその過程で遭遇した「落とし穴」について、私たちのチームの以前のミニ プログラム開発経験シリーズの記事です。ビッグデータの時代では、製品の成否には大量のデータの分析と検証が必要です。この号では、WeChat アプレットがどのようにデータを収集して分析するのかを一緒に見ていきます。もちろん、そのプロセスには「落とし穴」があります。

この記事のいくつかの例は、「点評注文」ミニ プログラムのメニュー ページからのものです。

著者紹介: Meituan-Dianping のフロントエンド エンジニア、Zou Gongyi は Web フロントエンド開発の経験が 4 年あり、現在は Meituan-Dianping の食品注文チームのメンバーです。

WeChatミニプログラムパブリックプラットフォームは現在利用可能 公式データ収集および分析プラットフォームが開発されました。
公式 API: https://mp.weixin.qq.com/debug/wxadoc/analysis/index.html?t=201726
ミニ プログラムの現在のパブリック ベータ版では、次のデータ分析が公式に提供されます:

• 概要: ミニプログラム開発の概要を素早く理解するために、ミニプログラムの主要な指標の傾向とトップページのアクセスデータを提供します (手動設定は不要、公式のデフォルト収集)

• アクセス分析: ミニプログラムのユーザーアクセスソースを提供します。スケール、頻度、期間、深さ、ページの詳細およびその他のデータ、新しいユーザーの追加とアクティビティの詳細な分析 (手動設定は不要、公式のデフォルト収集)

• リアルタイム統計: へのリアルタイムのアクセスを提供します。リアルタイム監視のニーズを満たすミニ プログラム内のデータ ;(手動構成は不要、公式のデフォルト収集)

• カスタム分析: カスタム レポートを構成し、ミニ プログラムでユーザーの行動を細かく追跡し、ユーザー属性とシステムを組み合わせます。柔軟で多次元のイベントを実行するための属性とイベント属性 分析とファネル分析は、ミニプログラムのパーソナライズされた分析ニーズに対応します (内部では、使用するには別途許可を申請する必要があります)
  

データは https://mp.weixin.qq.com から取得できます。ミニ プログラム管理者アカウントでログインして確認してください。

最初の 3 つのメソッドは小さなプログラムによって自動的に収集され、開発者による手動操作は必要ありません。WeChat の公式ドキュメントで詳細に説明されているため、ここでは説明しません。

この記事では。主に「Dianping Dianping」アプレットと組み合わせて、4 番目のタイプ - カスタム分析でできることを見てみましょう

カスタム分析は、従来の意味での隠れたポイントであり、ユーザーは独自に設定できます。報告されたデータ。このデータを使用して、得たい結果を分析します。

WeChat の公式カスタム分析では、一般的な非埋込みポイント技術が使用されており、アンカー ポイントは WeChat バックグラウンドを通じて設定され、リアルタイムでクライアントに送信され、埋込みポイントを手動で追加する必要はありません。コードにコードを追加し、ミニプログラムのリリースには監査メカニズムがあるため、一度手動でポイントを埋めてしまうと、再度レビューする必要があり、非常にコストがかかります。ミニプログラムのシナリオに適しています。

ただし、現在の「点評注文」ミニプログラムでテストされているように、カスタム分析の現在の内部ベータ版 (2017 年 3 月 2 日現在) には、コード自体の設計と記述、およびデータ収集に関して厳しい要件があります。ページ上のデータは関連している必要がありますが、シナリオによってはこれを満たすことが難しい場合があります。

次に、カスタム イベントを実装する手順を見てみましょう:

クリック時のクリックトリガー、ページと要素を指定する必要があります
ページに入るときにトリガーするようにenterPageを指定する必要があります、ページを指定する必要があります
ページを離れるときにトリガーするようにleavePageを指定する必要があります、ページ
pullDownRefresh はプルダウンして更新するときにトリガーするように指定する必要があります、ページ
launch はアプレットのロード時にトリガーするように指定する必要があります
バックグラウンドに切り替えるときにバックグラウンド トリガー
フォアグラウンドに切り替えるときにフォアグラウンドがトリガーされる
共有するときにトリガーされる Share

アクショントリガーが発生したときのアクションは、システムのデフォルトデータとユーザー定義データ（データで定義）を含む、デフォルトで収集されます

Emptyはデータのみを収集します。
report はデータを収集し、イベント データを報告します
start_and_report は初期化してデータを収集し、それを報告します

注: 各レポートの前に開始操作が必要であり、開始操作がなければ報告されません。 アクションの場合、start_and_report が設定されており、クリック トリガー条件が指定されている場合、タイミングは次のようになります。ページ (pages/index/index、pages/list/list など) の場合、このルールはミニ プログラム app.json のページ フィールドと一致します。ページをトリガーする必要がある場合は、ANY_PAGE を入力します。
要素 トリガーされる要素は、「.」または「#」で始まる必要がある 1 レベルの CSS ID およびクラス セレクターをサポートします。 data 収集されるカスタム データは 0 から複数の項目であり、各項目は「フィールド名フィールド値」で始まります。メソッド; 入力しない場合は、システム データのみが収集されます。

フィールド名: イベント内のフィールド名

フィールド値: イベント内のこのフィールドのデータ値。ページ上の変数名 (つまり、ページ インスタンスのデータ フィールド) を入力します。ページ上の変数を収集します。データ収集が配列内の特定のデータ項目 (list[].id など) である場合、配列の添え字は、現在のトリガー要素がクラスによって取得された NodeList に基づいて決定されます。

さらに、「$」で始まるいくつかの提供されたシステム属性を入力することもできます。 現在、次の属性がサポートされています:

$PAGE_TIME ユーザーがこのページに入ってから、現在の時間 (アクションがトリガーされた時点) 時点)$APP_TIME ユーザーがミニプログラムに入ってからの現在時間 (アクションがトリガーされた時点)$CURRENT_PAGE 現在のユーザーがいるページ

注: データが空の場合、イベント レポートはシステムのデフォルト フィールドからのみデータを収集します

———————————————— — —————————————

赤字で示したデータの値の説明に注目してください。この値は、前述の「点平順序」の一部です。シーンの収集ニーズを満たすことが難しい理由

まずはこのイベントを完了させて、このデータの落とし穴については後ほど説明します。

次に、このテキスト行を注意深く読むと、いくつかの重要な点がわかります:

• 値はページ インスタンス データのみです。フィールド、つまり page.data にない値は使用できません。配列の場合、クラス セレクター内の dom のインデックス インデックスは、その配列に対応するインデックス インデックスと等しくなければなりません。そうしないと、間違ったものを取得してしまいます。

• 
  

  2 番目のポイントは例です:

メニュー ページの追加ボタンは、リスト配列が page.data にあると仮定して、たった今設定した .add です。 menuList の場合、この赤いボックスは page.data.menuList[2] である必要があり、インデックス インデックスは 2

• dom のインデックスは整列する必要があります一部の複雑な状況では、要求を満たすことができません (実際のビジネスでは、メニュー ページと同様に、プラス記号が表示される条件はインデックスを揃えることができないことです)。売り切れていない場合)
  それでは、今のところ、カスタム分析 - 内部テスト段階では、収集できるデータは比較的限られており、完全にオープンした後は、ユーザー設定がより柔軟になることを願っています
• 。

ミニプログラムは Cookie をサポートしておらず、会社の統計システムは Cookie を通じてデータの一部を送信しているため、すべてのデータを考慮することができます。将来 ポイントをコードに手動で埋め込み、ajax を介して会社の統計データベースに送信すると、会社独自の統計システムがミニ プログラムの統計を完全に収集します。