I. 概要
1.プロジェクトの価値と成果
グループの統合された POS 収集機能と POS プラットフォームを使用して、Dada の 7 つの事業分野と合計 43 のサイト アプリケーションの POS 移行を完了し、自社の R&D 投資と機械コストを削減しました。 - 収集ツールとプラットフォームを開発し、データリンクをオープンし、より多くのデータ分析価値を生み出します。具体的なコスト削減と効率向上の数値は以下の通りです。
1.1 データ分析の価値: JD.com のトラフィック データと接続し、データ標準を調整し、トラフィックを連続的に接続する
1) 情報島: Kuaishou と JD のトラフィック データが分離されており、データベース テーブルへのアクセス コストが高く、統合分析が実行できません。
2) データの口径: 埋め込みポイントの仕様の調整: たとえば、広告スペースの露出、ページビューなどの隠れたポイントのレポート ルールは、データの口径を調整して精度を向上させるために JD.com のロジックと調整されます。
3) ユーザー情報の連結: device_id、ユーザー pin/supplier_id などのユーザーの基本情報を連結することで、ユーザーが JD 入口から入るトラフィック リンク、JD トラフィックのアクセス深度などを分析できます。 。
1.2 反復/保守の人件費の削減: 0.5 人/年
1) Tianhe プラットフォームの反復コスト
2) 交通伝送リンクの運営維持費
1.3 マシン/ミドルウェアのコストを節約: 年間 2 ワット以上
1) 2 つのクラウド ホスト + 見積もられる年間約 20,000 のミドルウェア コストを削減
2.プロジェクトのリズム
2. 調査と選択を計画する
1. プログラム測定
当初、移行計画1を策定しましたが、移行コストが膨大であることを考慮し、総合評価を経て移行計画2を策定し、移行コストの最小化などを総合的に考慮し、移行計画1を選択しました。
| プラン詳細 | 仕事量 | |
|---|---|---|
| オプション 1 | APP、ミニプログラム、PC&H5 の各事業ラインはそれぞれ変革および移行されます。 | 43 のサイト アプリケーションに対して SDK レイヤーの適応を行う必要がある |
| オプション II | 1) APP は SDK にカプセル化されており、他のビジネスラインはそれにアクセスするだけで済みます 2) PC&H5 は SDK 層で適応されており、他の 35 のアプリケーションはそれにアクセスするだけで済みます。 | 3 SDK レイヤーの適応が必要であり、他のビジネスラインを接続できます。 |
3. プロジェクトの実現
1. 上流および下流の移行プロセス
2. 技術アーキテクチャを移行する
プロジェクトに参加する前に、2 つの点を考慮する必要があります
安定性: プロジェクトが全体としてスムーズに実行される必要がある一方で、移行前後のデータの差異が妥当な誤差範囲内に保たれる必要があります。
効率的: この移行には、クライアント、アプレット、h5 などの数十のプロジェクトが含まれます。開発コストを節約することも重要です
(1) プランの選択
1. 直接置き換え：プロジェクトの数が多く、各プロジェクトのポイントも多いため、ビジネスに埋もれているポイントを直接置き換えることはできないのは明らかであり、作業量が膨大になり、問題のリスクが高くなります。
2. アスペクト置換: 埋め込みポイント レポートの特定のリンクにおける統合置換。この利点は、変更が 1 回だけで済むこと、コードの侵入が少なく、リスクが制御可能であることです。最も重要なことは、ワークロードが軽減されることです。大幅に軽減されます。
(2) スキーム設計
クライアントを例にとると、古い追跡フレームワークには、追跡収集、保存、レポートの 3 つのプロセスが含まれており、それぞれが独立しています。追跡収集と保存の間の側面を簡単に傍受し、元のポイント データを変換することができます。 、以下に示すように
古いフレームのアーキテクチャ図
(3) 計画の実施
具体的な計画を決定した後、置き換えが必要なプロジェクトが多数あることを考慮して（クライアントを例にとると、Dada Knight、Dada Express、Hongliu、Kongming などのプロジェクトがあります）、具体的なコード実装の計画を開始しました。 、各プロジェクトを実装する必要がありますこれは間違いなくリソースの無駄です。プロジェクトを終了ごとに Android、ios、アプレット、および h5 に分割します。このようにして、元の数十のプロジェクトは、ソリューションのセットと 4 つの終了コードに単純化されます各プロジェクトは簡単な統合のみで済むため、人的リソースを大幅に節約できます
3.技術的なハイライト
1. アスペクトのインターセプトおよび移行ソリューションを使用して人件費を節約する
2. ユニファイドカプセル化と多端末多重化により埋め込みポイント仕様を統一
3. データ ウェアハウス層: JD.com からのリアルタイム トピックを直接利用してデータベースにドロップし、データベース表層で JD.com と Dada のデータ構造に互換性を持たせ、下流のレポート層で「無意識の移行」を実現します。 、ビジネスレポートと下流の移行コストの影響を最小限に抑えます。
4. 踏まれた穴
1. iOS は、隠れたポイントのバックグラウンド レポートをサポートしていません。
問題: アプリがフォアグラウンドを終了してバックグラウンド モードになっているときに、騎士や商人が隠れたポイントを報告することがありますが、Meridian は当初、長い間バックグラウンドでの隠れたポイントの報告をサポートしていませんでした。
解決策: Meridian は、時間制限なしのバックグラウンド レポートおよび埋め込み機能をサポートする構成を追加しました。
2. iOS ネットワークの問題
問題: アプリが初めてインストールされ、ユーザーがネットワーク権限に同意しない場合、Meridian SDK は DAU ポイントをレポートします。レポートが失敗すると 3 回再試行され、失敗すると 2 分間のタイムアウトがトリガーされます。 2分以内はポイントが反映されません。
解決策: Meridian では、2 分の制限のない個別のパッケージを提供しています。
3. APP がポリシーの問題を報告する
問題: Meridian のデフォルトのレポート戦略は 15 秒、10 項目であるため、一部のユーザーはレポート条件をトリガーせず、アプリを終了した後に既存の非表示ポイントをレポートできません。
解決策: Meridian 更新構成は 2s2 です。
4. uid が空であるため、埋め込まれたポイントがテーブルに含まれません。
問題: 新規ユーザーは、プライバシー契約に同意する前にユーザーのデバイス情報を取得しないため、appUniqueID が空で渡され、Meridian オフライン テーブルに分類されません。
解決策: 新しいユーザーがプライバシー契約に同意する前に、文字列をランダムに生成して暗号化し、それをデバイス ID として Meridian に渡し、すべての埋め込まれたポイントが確実に記録されるようにします。
5. ミニプログラム報告メカニズムの問題
問題: ミニ プログラム Dada SDK はバッチでレポートされますが、Meridian SDK は個別にレポートされるため、データに差異が生じます。
ソリューション: Meridian SDK はバッチ レポートをサポートします
6. H5 埋め込みポイントは、その大きさが大きすぎる場合には破棄されます。
問題: torrent アプリケーションでは、session_id が 10,000 回を超えると、データが Meridian オフライン テーブルによって破棄されます。
解決策: 同じ都市にあるデータ ウェアハウスは、リアルタイム トピックからデータを直接消費し、session_id の数量制限を追加せずにオフライン テーブルにドロップします。
Microsoft、新しい「Windowsアプリ」 .NET 8を正式にGAリリース、最新LTSバージョン XiaomiはXiaomi Velaが完全にオープンソースであり、基盤となるカーネルはNuttXであることを正式に発表 Alibaba Cloud 11.12 障害の原因が明らかに：Access Key Service（アクセスKey) 例外 Vite 5 が正式にリリースされた GitHub レポート : TypeScript が Java に取って代わり、3 番目に人気のある言語になる Rust で Prettier を書き換えるために数十万ドルの報酬を提供 オープンソース作者に「プロジェクトはまだ生きていますか?」と尋ねる 非常に失礼で、失礼な バイトダンス: AI を使用して Linux カーネル パラメータ 演算子を自動的に調整する 魔法の操作: バックグラウンドでネットワークを切断し、ブロードバンド アカウントを無効化し、ユーザーに光モデムの変更を強制する著者: JD Retail プリシラ・ジョウ
出典：JD Cloud Developer Community 転載の際は出典を明記してください